Our Journey to a Near Perfect Log Pipeline

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

Bối cảnh

• Log của ứng dụng lõi Salesforce trong các data center phục vụ nhiều nhóm (Product Intelligence, Security, điều tra sự cố), nên phải tới "Secure Zone" gần như đầy đủ. Pipeline cũ (agent tự viết + LFTP + SAN) ngày càng mong manh trong khi lượng log tăng khoảng 100%/năm (gấp đôi từ 2015 tới 2017).
• Kiến trúc mới (làm từ cuối 2015): Logstash trên mỗi host → Kafka cục bộ ở mỗi data center (Ajna Local) → MirrorMaker qua WAN → Kafka tổng ở Secure Zone (hàng trăm broker; theo bài là cụm Kafka lớn nhất họ biết) → Camus (MapReduce) → HDFS (DeepSea). Mục tiêu: 99,999% đầy đủ, trễ tối đa 5 ngày.

Thay đổi chính (theo từng tháng đo)

• 12/2016, khoảng 25% (lấy mẫu khoảng 1% host): Camus làm rơi dữ liệu: một thread mỗi partition không theo kịp, một job MapReduce cho mọi partition nên lỗi một chỗ chặn cả pipeline. Sửa: nhiều thread mỗi partition co giãn theo lượng log, chịu tới 50% map lỗi.
• 3/2017, 90–99%: hai quyết định: đo toàn bộ fleet thay vì lấy mẫu (lấy mẫu dao động 10% mỗi ngày, không kết luận được), và MirrorMaker ack = all cho at-least-once.
• 5/2017, 98–99% (toàn fleet): Logstash bỏ sót nội dung khi pipeline cũ xoay file log (đổi sang luôn đọc từ đầu file); Logstash "zombie" khi tắt (hard kill + replay buffer). Gắn id băm 4 byte vào mỗi bản ghi, kết hợp host + timestamp để khử trùng và đếm chính xác.
• 7/2017, 99,999%: đạt mục tiêu; thêm quy trình replay log tay cho host bị thiếu vào những ngày xấu.
• 8/2017, tụt xuống 99,9–99,99%: cùng lúc chuyển sang cụm lớn hơn và topic chi tiết hơn. Batch tối đa 1 MB trên đường ống bị vượt: MirrorMaker đặt quá sát 1 MB (giảm còn 250 KB), Logstash dùng client cũ đếm theo số message (nâng client). Topic chi tiết làm lộ lỗi vì nhóm máy sinh message lớn không còn được trộn với message nhỏ.
• 9/2017, 99,99999%: đều mỗi ngày; đầu 10/2017 giữ 5 số 9 được 100 ngày, khách nội bộ ký nhận, chuẩn bị tắt pipeline cũ.
• Đo: đếm ở host (A), ở Kafka tổng (B), ở HDFS (C); so A–B khoanh vùng thượng nguồn, B–C khoanh Camus; dashboard tín hiệu sớm (host nào mất log, host nào nên replay) và dashboard SLO cho khách.
• Không đi tới 100%: log sai định dạng làm đếm lệch, khoảng 5.000–7.000 "superlog" mỗi ngày vượt 1 MB bị từ chối, và theo Salesforce mỗi bậc số 9 thêm cần công lớn mà nhu cầu không đòi.

Bài học cho SWE

• Với pipeline dữ liệu, đo độ đầy đủ đầu-cuối là tiêu chí nghiệm thu; theo Salesforce, bài học lớn nhất là đáng lẽ phải đo toàn fleet ngay từ đầu (Observability và monitoring).
• At-least-once kéo theo trùng lặp; cần định danh duy nhất trên từng bản ghi để vừa khử trùng vừa đếm đúng (Event-driven, message queue và Kafka).
• Giới hạn cấu hình phải nhất quán trên cả đường ống và có khoảng dư; một thay đổi tưởng vô hại (topic chi tiết hơn) có thể làm lộ giới hạn cũ.

Liên quan

• Cùng công ty: Salesforce 2026
• Observability và monitoring · Event-driven, message queue và Kafka