Lessons from Building Observability Tools at Netflix

Netflix · 2018 · 3. Quy mô lớn · Độ khó: Trung bình — bài gốc

Bối cảnh

• Netflix có 125 triệu thành viên, xem trên hơn 1.000 loại thiết bị (2018). Đội làm công cụ observability (log, trace, metric) cho cả thiết bị lẫn server, để người dùng vào một công cụ thay vì nhiều công cụ theo loại dữ liệu hay đăng nhập vào từng server.

Thay đổi chính

• Log: lưu hết không scale. Đến một mức tăng trưởng, lưu toàn bộ log thiết bị và server làm chi phí lưu trữ phình và query chậm. Ngoài việc giảm thời gian giữ, họ chuyển sang Mantis (stream processing realtime): log chảy trong bộ nhớ, chỉ giữ dòng khớp tiêu chí kiểu SQL, người dùng tuỳ chọn biến đổi và lưu phần khớp. Cách dùng là lặp: lấy mẫu (ví dụ sự kiện bắt đầu phát trên iPad), thu hẹp dần (theo quốc gia).
• Tracing: call graph chưa đủ. Lấy cảm hứng từ Dapper, họ gắn interceptor cho HTTP và gRPC, đẩy dữ liệu trace qua Kafka rồi một consumer ghi xuống kho. Theo Netflix, call graph và latency chỉ có ích cơ bản; phần riêng của họ là cho ứng dụng thêm định danh để gom nhiều trace thành một khái niệm (mọi request của một phiên phát dùng chung playback session ID), và analyzer trả lời câu hỏi hay gặp (vì sao phiên này không được 4K hay HDR). Họ bắt đầu gom cụm log lỗi bằng ML để hiện thuộc tính chung (ví dụ cùng phiên bản app) cạnh trace; có trường hợp hiện luôn nguyên nhân bằng tiếng Anh.
• Metric: đẩy số đếm lỗi từ log vào Atlas để thấy xu hướng theo nhiều chiều (thiết bị, địa lý); metric cũng định nghĩa được từ log khớp trong Mantis. Thêm thuật toán thống kê so xu hướng hiện tại với baseline để phát hiện bất thường, và đang tương quan metric giữa các microservice liên quan, để alert có ích hơn ngưỡng tĩnh.
• Chọn kho theo cách đọc và tốc độ ghi: dữ liệu luôn đọc theo khoá chính + khoảng thời gian thì Cassandra; cần query theo nhiều trường thì Elasticsearch; dữ liệu cũ (người dùng chủ yếu xem tuần gần nhất) giữ lâu hơn trong Hive. Một tập dữ liệu ban đầu để ở Elasticsearch cho dễ index nhiều trường, nhưng khi tốc độ ghi tăng, thời gian index dài tới mức dữ liệu chưa có khi người dùng query hoặc trả về quá chậm; họ chuyển sang Cassandra và định nghĩa sẵn ba khoá đọc cho các use case hiện có. Theo Netflix: Hive rẻ nhất (nhiều bản ghi một file, không nhân bản) nhưng đọc chậm vì phải quét; Elasticsearch tốn node khi ghi tăng; Cassandra có lẽ đắt nhất vì nhân bản mỗi bản ghi.
• Giao diện theo nhóm người dùng (dev thiết bị, dev server, chăm sóc khách hàng): lưu tuỳ chọn cột hiển thị, chỉ nạp loại log nặng khi người dùng bật, nối định danh với dữ liệu nó trỏ tới và giải thích mã lỗi để giảm kiến thức chuyên môn cần có.

Vì sao

• Chi phí lưu log tăng theo lưu lượng, còn giá trị nằm ở phần nhỏ người ta thật sự hỏi; lọc trên luồng trước khi lưu đổi chi phí theo dữ liệu thành chi phí theo câu hỏi (Observability và monitoring).
• Trace có giá trị khi gắn với khái niệm nghiệp vụ (phiên phát), không chỉ với request đơn lẻ (Tracing phân tán và log theo request).
• Kho theo cách đọc: index linh hoạt phải trả bằng chi phí ghi (Chọn database theo workload).

Bài học cho SWE

• Trước khi mở rộng kho log, hỏi xem có thể lọc trên luồng và chỉ lưu thứ khớp hay không.
• Cho ứng dụng gắn định danh nghiệp vụ vào trace để gom nhiều request thành một câu chuyện.
• Elasticsearch tiện lúc đầu nhưng đường ghi có thể thành nút thắt khi tốc độ ghi tăng; khi đã biết khoá đọc, kho khoá–giá trị rẻ hơn về latency.

Liên quan

• Netflix 2021 (ba năm sau, cùng hướng gom theo khái niệm nghiệp vụ) · Netflix 2018 · Pinterest 2017
• Observability và monitoring · Tracing phân tán và log theo request · Chọn database theo workload