The evolution of SQL-based Observability

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

Bài của nhà cung cấp, cập nhật một năm sau bài "state of SQL-based observability" (2023). Mọi nhận định là theo ClickHouse. Phần đáng giữ là các bài học khi khách dựng stack OTel + ClickHouse và chỗ yếu của cách lưu thuộc tính động.

Bối cảnh

• Luận điểm từ 2023: observability là một bài toán dữ liệu, nên SQL và hệ OLAP giải được; nén tốt, object storage gần như không giới hạn, không phải lấy mẫu log để tiết kiệm. OpenTelemetry biến việc thu thập thành hàng phổ thông, giảm phụ thuộc nhà cung cấp.
• Danh sách "không hợp với bạn" do họ đưa ra: team không muốn dùng SQL, cần trải nghiệm trọn gói, dữ liệu nhỏ (dưới khoảng 150 GiB) và không tăng, nặng về metric và cần PromQL, hoặc muốn chờ hệ sinh thái chín hơn.

Thay đổi chính

• Vấn đề của Map cho thuộc tính động: schema mặc định của exporter OTel để LogAttributes, ResourceAttributes, ScopeAttributes ở kiểu Map(String, String). Hệ quả: mất kiểu (số thành chuỗi, phải ép kiểu lúc query); đọc một khoá phải nạp cả map và quét tuyến tính; không biết có những khoá nào nếu không quét; chỉ một cấp lồng. Cách chữa tạm là cột materialized lúc insert.
• Kiểu JSON viết lại từ đầu (24.8): bản thử nghiệm cũ suy kiểu từ lần đầu gặp và hợp nhất kiểu, theo họ là sai thiết kế. Bản mới tạo một cột con cho mỗi cặp đường dẫn + kiểu, lưu dày (không lưu giá trị mặc định cho đường dẫn vắng), liệt kê được các đường dẫn (cho autocomplete), và khi số đường dẫn vượt giới hạn thì dồn vào một cột chung có thống kê, tránh bùng nổ cột con. Họ vẫn khuyên giữ các trường hay lọc ở cột gốc để dùng codec và index.
• Hệ sinh thái: exporter ClickHouse cho log và trace của OTel Collector lên beta; plugin Grafana v4 có query builder cho log/trace và "log context" (bỏ filter, lấy các dòng quanh một dòng theo service/host/container).
• Bài học khi khách triển khai:
  • Chọn primary/ordering key theo cách lọc ngay từ đầu (cột hay lọc nhất đứng đầu, theo thứ tự drill-down); quét tuyến tính không đủ cho truy vấn dưới một giây khi dữ liệu lớn.
  • Materialized view là bắt buộc: ghi vào bảng engine Null, view biến đổi rồi đẩy sang bảng phục vụ; dùng để trích trường từ Body, tạo bảng có ordering key khác cho từng nhóm truy vấn, lọc tập con để chạy alert, tính trước aggregation. Theo họ, biến đổi trong ClickHouse rẻ hơn trong collector.
  • Không phải dữ liệu nào cũng theo OTel: nội bộ, LogHouse quản lý hơn 43 PB (10/2024) và SysEx gom bảng system.*_log của mọi service ClickHouse Cloud, gần 100 nghìn tỉ dòng (11/2024).
• TimeSeries engine (thử nghiệm): ClickHouse làm storage cho Prometheus qua remote write/read, chuẩn hoá thành ba bảng (metric, tag, data point) nên đọc phải join. Hạn chế họ tự nêu: Prometheus kéo toàn bộ dữ liệu thô về rồi mới tính PromQL, không đẩy aggregation xuống, nên query dài và cardinality cao còn kém.

Vì sao

• Thuộc tính tuỳ ý theo nguồn là bản chất của dữ liệu observability; kiểu lưu nào bắt quét cả khối để đọc một khoá sẽ đắt dần theo số khoá (Observability và monitoring).

Bài học cho SWE

• Với kho log dạng cột, ordering key là quyết định hiệu năng lớn nhất; nó phải theo cách người dùng lọc chứ không theo schema chuẩn.
• Dời chi phí từ lúc đọc sang lúc ghi (view materialized, aggregation tính trước) cho các truy vấn lặp lại như alert và dashboard.
• Tích hợp qua giao thức (remote read) mà không đẩy được phép tính xuống kho thì chỉ dùng được cho truy vấn nhỏ.

Liên quan

• ClickHouse 2025 (LogHouse) · ClickHouse 2026 (schema OTel làm lại theo benchmark) · Memgraph 2026 (dùng cột JSON cho telemetry) · Prometheus 2019
• Observability và monitoring