Fly Behind The Scenes: Fresh Logging

Fly.io · 2020 · 2. Tăng trưởng · Độ khó: Dễ — bài gốc

Bài phỏng vấn ngắn người làm dự án; ít số liệu.

Bối cảnh

Fly.io gom log của mọi app trên nền tảng (flyctl logs). Hệ cũ là 7 server Graylog lớn tập trung; với 20.000–30.000 log/giây, có lúc trong ngày không xử lý kịp và log bị rơi. Log tới user bằng cách poll API của Graylog.
Có thể tăng sức các server, hoặc thêm Kafka (thêm một công cụ lớn vào chuỗi).

Vector (Rust) chạy trên mọi server, đọc từ journald và ứng dụng, parse và biến đổi (bỏ trường không cần, regex, đổi tên), rồi gửi thẳng vào Elasticsearch, bỏ Graylog ở giữa. Ban đầu định dùng Vector gửi vào Graylog, nhưng Vector không hỗ trợ giao thức Graylog, từ đó thấy Graylog thừa.
Chuyển sang Elastic Common Schema: trường chung (nguồn, đích, HTTP, TLS...) cộng trường riêng (tên app, alloc, region), để tìm một IP nguồn trên nhiều app không phải đoán tên trường.
Đánh đổi: luật biến đổi nằm phân tán trong cấu hình Vector trên từng máy (phân phối qua hệ quản lý cấu hình) thay vì tập trung ở Graylog; bù lại có unit test và validate cấu hình trước khi deploy, tải xử lý chia ra mọi máy gần như không đáng kể, và phần cứng cũ của Graylog dồn cho Elasticsearch.
Khoảng hai tuần làm song song việc khác; phần lớn là gỡ các vấn đề nhỏ (mapping, mã hoá, nội dung trường). API vẫn poll Elasticsearch như trước, nhưng đủ nhanh để log của lần deploy hỏng đã có sẵn khi flyctl truy vấn.

Xử lý log ở nguồn (trên từng máy) bỏ được một tầng tập trung vừa là nút thắt vừa là điểm rơi dữ liệu (Observability và monitoring).

Trước khi scale một tầng trung gian, hỏi xem nó có còn cần thiết nếu việc xử lý dời về nguồn.
Schema chung cho log làm việc tìm kiếm xuyên ứng dụng khả thi.
Cấu hình pipeline phân tán cần test và validate tự động như code.