How We Built a Logging Stack at Grab

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

Bối cảnh

• Một năm trước đó, Grab không có trực quan hoá hay metric cho log service; tìm một chuỗi trong log ba ngày qua là "chạy query rồi đi pha nước". Cách cũ là một mớ: log trên storage cloud (mất hàng giờ mới lấy được), một nhà cung cấp SaaS hay timeout, hoặc nhờ SRE vào từng máy lấy log.
• Khi bắt đầu: 25 TB log mỗi ngày. Theo bài, câu hỏi "có thật cần ngần ấy log không" có lẽ là "không", nhưng không thể quyết thay cho dev khác. Yêu cầu được hỏi nhiều nhất: tìm theo user ID trên giao diện web, có kết quả dưới 5 giây.

Thay đổi chính

• ELK tự vận hành, bắt đầu POC 5 node, ước khoảng 80 node; sau hơn 400 node. Cài bằng Ansible. Ban đầu mỗi node làm cả bốn vai (ingest, coordinator, master, data) và dùng ingest node thay Logstash cho đơn giản; nhìn lại thì vai trò trộn lẫn làm khó điều tra (mất master vì ai đó làm đầy field data cache khi search) và ingest node lỗi kiểu lạ gây ảnh hưởng cả cụm.
• Giám sát heap theo node bằng Datadog là cứu cánh: Kibana không đủ cho 400 node.
• Các vấn đề ở quy mô này:
  • Field data cache: mặc định có thể chiếm tới 70% heap cho một lần search. Một user sort theo trường id (Kibana mặc định cho phép) nạp mọi ID của 14 ngày index vào heap: hơn 20 GB trước khi circuit breaker ngắt; hai query đồng thời là một node chết. Tắt sort id trong Kibana và hạ mạnh giới hạn field data.
  • Nén khi chuyển shard giữa node: segment Lucene vốn đã nén; tắt nén thì chuyển một shard 50 GB từ 1 giờ còn 20 phút.
  • Segment memory: OOM vì quá nhiều shard trên một node; tính ra khoảng 8 TB shard cho node heap 32 GB nếu giữ segment memory khoảng 50%. Node data 16 TB là cấu hình sai.
  • Mapping: đo bộ nhớ theo từng trường, sửa trường lẽ ra là integer mà để keyword, bỏ index trường không ai tìm.
  • Analyzer: Standard Analyzer tách chuỗi chữ-số (ví dụ ID) thành nhiều token, trong khi không ai tìm một phần ID; chuyển sang khớp nguyên chuỗi bớt 1 GB index memory, tương đương bỏ 8 node. Đổi analyzer trên production làm user bối rối vì kết quả đổi.
  • Phí traffic giữa AZ: chuyển shard nóng → ấm → lạnh liên tục giữa các AZ chiếm khoảng 30% tổng chi phí cụm. Tạo index riêng cho mỗi zone và ghim log ở zone sinh ra nó: giảm mạnh chi phí, và khoanh vùng sự cố theo zone.

Vì sao

• Log là một hệ dữ liệu cỡ PB với kiểu truy vấn ad-hoc; mặc định của công cụ (field data, analyzer, nén) dành cho quy mô nhỏ hơn (Observability và monitoring, Hạ tầng tìm kiếm).
• Chi phí ẩn lớn nhất không phải phần cứng mà là traffic giữa AZ do cách sắp dữ liệu (Chi phí hạ tầng và build vs buy).

Bài học cho SWE

• Hỏi user cần gì nhất (tốc độ tìm theo ID) và đo thông số (dung lượng/ngày, thời gian giữ, latency chấp nhận) trước khi spec cụm.
• Tách vai trò node từ đầu; đặt giới hạn circuit breaker chặt hơn mặc định khi user có thể chạy query tuỳ ý.
• Kiểm phí giữa AZ trong mọi thiết kế di chuyển dữ liệu theo tầng.

Liên quan

• eBay 2019 · Fly.io 2020 · Grab 2022 · WarpStream 2025
• Observability và monitoring · Chi phí hạ tầng và build vs buy · Hạ tầng tìm kiếm