Scaling our Observability platform beyond 100 Petabytes by embracing wide events and replacing OTel

ClickHouse · 2025 · 3. Quy mô lớn · Độ khó: Khó — bài gốc

Bài của nhà cung cấp về hệ log nội bộ (LogHouse, giám sát ClickHouse Cloud); có quảng bá sản phẩm (ClickStack, HyperDX). Số liệu và nhận định là theo ClickHouse.

Bối cảnh

• LogHouse là nền tảng log nội bộ dựng trên ClickHouse, ban đầu để thay hoá đơn Datadog mà theo ClickHouse "ngày càng không kham nổi". Khoảng giữa 2024 nó giữ 19 PiB (dữ liệu chưa nén), khoảng 37 nghìn tỉ dòng; giữa 2025 là hơn 100 PB, gần 500 nghìn tỉ dòng.
• Ban đầu 100% telemetry đi qua OpenTelemetry (OTel): ClickHouse ghi JSON ra stdout → kubelet lưu file → OTel collector trên mỗi node đọc, parse, đổi sang định dạng OTel → gateway (cũng là collector) xử lý thêm → chuyển sang định dạng native của ClickHouse để ghi.
• Hai vấn đề khi lớn lên: (1) tốn CPU cho chuỗi chuyển đổi lặp lại (kiểu native → JSON → OTel → native) và mất độ trung thực; (2) collector bị giới hạn CPU/RAM theo Kubernetes, lúc traffic tăng thì bỏ log ngay ở edge. Theo ước tính của ClickHouse, ship 20 triệu dòng/giây qua OTel mà không rơi cần khoảng 8.000 core.
• Thêm nữa, phần telemetry giá trị nhất của ClickHouse nằm trong system tables (query log, I/O, tác vụ nền), không phải stdout.

Thay đổi chính

• SysEx (System Tables Exporter), viết bằng Go: một pool scraper, hash ring gán mỗi pod khách cho một scraper; scraper chạy SELECT trên system tables của pod nguồn và stream byte nguyên bản sang LogHouse, không deserialize (đóng góp thay đổi vào Go client để bỏ marshalling).
  • Pull theo cửa sổ thời gian, trễ khoảng 5 phút so với hiện tại để buffer bên nguồn kịp flush; LogHouse tạm sập hay nguồn có spike thì không mất dữ liệu, chỉ cần scrape lại cửa sổ cũ (backfill tự nhiên, không cần buffer retry phức tạp).
  • Schema system table đổi thường xuyên: SysEx hash schema, chưa có thì tạo bảng phiên bản mới (text_log_6), lúc đọc gộp mọi phiên bản bằng Merge table engine.
  • Snapshot định kỳ các bảng trạng thái trong bộ nhớ (system.processes, schema, settings) để "du hành thời gian" khi điều tra.
  • Chạy cùng câu truy vấn chẩn đoán của khách trên toàn fleet, dùng trong phân tích trước-sau mỗi release.
• Kết quả theo ClickHouse: OTel collector dùng hơn 800 core cho 2 triệu log/giây; SysEx dùng 70 core cho 37 triệu log/giây; tức gấp 20 lần lượng sự kiện với dưới 10% CPU, và không còn rơi dữ liệu ở edge.
• OTel vẫn giữ cho mọi service, vì SysEx cần service còn sống để query, còn OTel đọc stdout/stderr được cả khi service crash-loop. Nhưng chỉ thu info trở lên (bỏ trace-level), nên pipeline OTel nhỏ lại.
• Chuyển hướng sang wide event, high cardinality: lưu từng sự kiện với đủ chiều (pod, version, bảng, cửa sổ...) thay vì tiền tổng hợp thành metric; tổng hợp lúc truy vấn bằng SQL. Theo ClickHouse, Prometheus sẽ bùng cardinality với hàng chục nghìn pod name, còn histogram tiền tổng hợp thì không trả lời được "spike này là insert nào".
• UI: chuyển dần từ Grafana tự dựng sang HyperDX (ClickHouse mua lại); Grafana vẫn giữ cho dashboard/alert dựa trên metric Prometheus và cho định tuyến truy vấn theo namespace tới đúng cụm theo region.
• Nguồn mới: kubenetmon (luồng mạng, chi phí egress liên region), sự kiện Kubernetes, control plane, access log Istio.
• Việc tiếp theo: "zero-impact scraping", đọc thẳng bảng log trên S3 thay vì query cụm đang chạy, vì khách đôi khi thấy query scrape trong log của họ và lo lắng.

Vì sao

• Collector đa dụng trả giá cho tính tổng quát (parse, chuyển định dạng nhiều lần); khi nguồn và đích cùng một hệ, đường riêng rẻ hơn hàng chục lần.
• Push qua agent có giới hạn tài nguyên thì rơi dữ liệu khi spike; pull theo cửa sổ có độ trễ cố định thì tự điều tốc và backfill được.

Bài học cho SWE

• Ở quy mô lớn, chi phí của chính pipeline quan sát (CPU collector) có thể là khoản lớn; đo nó như mọi hệ khác (Chi phí hạ tầng và build vs buy, Observability và monitoring).
• Chuẩn chung (OTel) hợp cho đa số nguồn và cho lúc service hỏng; nguồn lớn nhất, có cấu trúc thì đáng một đường riêng. Hai đường bổ sung nhau.
• Pull có độ trễ cố định so với thời gian thực đổi độ tươi lấy độ đầy đủ và khả năng backfill.
• Wide event + kho cột thay cho metric tiền tổng hợp khi câu hỏi điều tra không biết trước; đổi lại cần kho lưu và truy vấn đủ rẻ.

Liên quan

• Tracing phân tán và log theo request
• Cùng công ty: ClickHouse 2026
• Observability và monitoring · Chi phí hạ tầng và build vs buy