Thay thế OTel và mở rộng nền tảng observability bằng wide events

• LogHouse nội bộ của ClickHouse đã tăng từ 19PiB và khoảng 40 nghìn tỷ hàng lên quy mô lưu trữ hơn 100PB log chưa nén và gần 500 nghìn tỷ hàng chỉ sau 1 năm
• Đường thu thập dữ liệu trước đây xoay quanh OpenTelemetry phải đi qua JSON, định dạng OTel và định dạng ClickHouse Native, làm tăng chi phí CPU và rủi ro rớt log
• Với SysEx (System Tables Exporter), ClickHouse sao chép theo từng byte các bảng hệ thống vào LogHouse và xử lý 37M logs/s bằng 70 lõi CPU
• OTel vẫn tiếp tục hữu ích cho log sự cố dựa trên stdout·stderr và định dạng chuẩn trung lập nhà cung cấp, nhưng telemetry cốt lõi của ClickHouse đang chuyển sang SysEx và wide events
• Sau khi áp dụng HyperDX, ClickHouse đang kết hợp UI native, tìm kiếm theo cú pháp Lucene, phân tích SQL và khám phá không phụ thuộc schema để thay thế một phần vai trò của UI tùy biến dựa trên Grafana

---

LogHouse đã tăng lên quy mô 100PB và 500 nghìn tỷ hàng

• LogHouse là nền tảng logging nội bộ được xây dựng để giám sát ClickHouse Cloud, trước đây cũng đóng vai trò thay thế chi phí Datadog ngày càng tăng
• Một năm trước, hệ thống xử lý 19PiB dữ liệu chưa nén và 37 nghìn tỷ hàng; hiện nay đang lưu trữ hơn 100PB dữ liệu chưa nén và gần 500 nghìn tỷ hàng
• Thành phần chính của dữ liệu đang lưu trữ hiện nay gồm:
  • SysEx: 93.6PB, 431 nghìn tỷ hàng
  • OTel: 14.5PB, 16.7 nghìn tỷ hàng
• Trước đây mọi telemetry đều đi qua OpenTelemetry, nhưng giờ phần lớn dữ liệu đến từ SysEx, một exporter chuyên biệt do ClickHouse xây dựng

Giới hạn của pipeline OpenTelemetry

• OpenTelemetry phù hợp làm pipeline chuẩn ban đầu để gửi log của mọi Pod trong môi trường Kubernetes vào ClickHouse
• Chỉ log văn bản từ stdout của ClickHouse là không đủ cho phân tích vận hành; để phân tích thực tế còn cần log có cấu trúc từ bảng system, metric, chi tiết thực thi, disk I/O và trạng thái tác vụ nền
• Đường đi log OTel trước đây phải qua nhiều bước chuyển đổi:
  • Instance ClickHouse của khách hàng ghi log ra stdout dưới dạng JSON
  • kubelet lưu log vào /var/log/…
  • OTel collector đọc log từ đĩa, parse JSON và chuyển sang biểu diễn trong bộ nhớ
  • collector lại chuyển đổi sang định dạng log OTel
  • ClickHouse Go client tiếp tục chuyển đổi sang định dạng ClickHouse Native rồi chèn vào LogHouse
• Trong thực tế, pipeline OTel còn bao gồm edge collector, truyền OTLP, gateway collector và xử lý bổ sung, nên mỗi bước đều làm tăng overhead, độ trễ và độ phức tạp
• Khi quy mô tăng lên, hai vấn đề trở nên rõ rệt:
  • Các kiểu dữ liệu ClickHouse Native bị đi qua JSON và định dạng OTel nên lãng phí CPU và làm giảm độ trung thực dữ liệu
  • OTel agent trên node Kubernetes bị chạm giới hạn CPU và bộ nhớ, khiến log line bị rớt khi lưu lượng tăng đột biến
• Ước tính để xử lý 20M rows/s bằng OTel mà không mất dữ liệu, toàn bộ agent và collector sẽ cần khoảng 8.000 lõi CPU

SysEx: bộ thu thập chuyên cho truyền ClickHouse-to-ClickHouse

• ClickHouse đã tạo System Tables Exporter (SysEx) để truyền trực tiếp dữ liệu từ bảng hệ thống ClickHouse trong Pod khách hàng sang các bảng trong LogHouse
• SysEx thực hiện sao chép theo từng byte giữa nguồn và đích, giữ nguyên kiểu ClickHouse Native và loại bỏ các bước chuyển đổi trung gian
• Nhờ cấu trúc này, các truy vấn mà kỹ sư từng dùng để debug live instance có thể dễ dàng đổi sang truy vấn dữ liệu lịch sử trên toàn fleet trong LogHouse
  • Schema bảng là như nhau, chỉ thêm các cột enrichment như tên Pod hay phiên bản ClickHouse
• Kiến trúc gồm pool SysEx scraper và hash ring
  • hash ring gán Pod khách hàng cho các replica scraper cụ thể để phân tán tải
  • scraper chạy SELECT trên bảng system của Pod nguồn và stream dữ liệu về LogHouse
  • scraper điều phối việc truyền byte giữa nguồn và đích mà không cần giải tuần tự hóa
• Để tránh bỏ lỡ các lần flush buffer của bảng hệ thống, SysEx dùng cửa sổ thời gian trượt và thường truy vấn chậm hơn thời gian thực khoảng 5 phút
• Vì hành vi mặc định của Go ClickHouse client là chuyển dữ liệu sang kiểu native của Go, ClickHouse đã đóng góp vào clickhouse-go tính năng bỏ qua marshalling nội bộ
• Vì SysEx là mô hình pull, nó không cần buffering nặng như OTel; nếu LogHouse tạm thời không khả dụng hoặc telemetry nguồn tăng vọt, hệ thống có thể scrape lại các window cũ để backfill

Schema động và snapshot trạng thái

• SysEx yêu cầu schema nguồn và đích phải khớp nhau, nhưng schema của các bảng hệ thống ClickHouse thay đổi thường xuyên khi có metric và cột mới được thêm vào
• Để xử lý điều này, khi gặp một bảng hệ thống, SysEx sẽ kiểm tra schema, băm nó rồi xác nhận xem LogHouse đã có bảng với schema đó hay chưa
  • Nếu có, dữ liệu được chèn vào bảng hiện có
  • Nếu chưa có, hệ thống tạo một phiên bản schema mới như text_log_6
• Khi truy vấn, ClickHouse dùng Merge table engine để gom nhiều vòng lặp schema thành một view logic duy nhất
• Merge table engine cho phép chỉ chọn các cột tương thích hoặc giới hạn truy vấn vào các bảng có cột được yêu cầu, nhờ đó vẫn có thể truy vấn qua các thay đổi schema mà không cần quản lý thủ công
• ClickHouse cũng định kỳ chụp snapshot các bảng system trong bộ nhớ như system.processes và lưu vào LogHouse
• Các snapshot này được dùng để phân tích trạng thái cụm, schema bảng và cấu hình cụm tại một thời điểm cụ thể trong quá khứ

Phân tích toàn fleet và các chỉ số hiệu quả

• Nhờ SysEx, các Advanced Dashboard queries mà khách hàng dùng để giám sát từng instance ClickHouse riêng lẻ có thể chạy đồng thời trên toàn bộ fleet instance của khách hàng
• Trong phân tích bản phát hành, hệ thống chạy truy vấn chẩn đoán trước và sau khi triển khai để kiểm tra theo thời gian thực trên quy mô toàn fleet các mẫu hiệu năng truy vấn, xu hướng sử dụng tài nguyên và thay đổi về tỷ lệ lỗi
• Dashboard hỗ trợ còn cho phép tương quan hóa Advanced Dashboard queries với log mạng, sự kiện Kubernetes và các sự kiện data plane·control plane trong cùng một giao diện
• So sánh hiệu quả theo LogHouse như sau:
  • OTel Collectors: hơn 800 lõi CPU để truyền 2M logs/s
  • LogHouse Scrapers (SysEx): 70 lõi CPU để truyền 37M logs/s
• Từ nguồn dữ liệu quan trọng nhất, SysEx đã tăng khối lượng sự kiện lên 20 lần trong khi giảm CPU footprint xuống dưới 10% trước đây, đồng thời loại bỏ việc rớt sự kiện ở edge

Những phần OpenTelemetry vẫn còn cần thiết

• OpenTelemetry vẫn là lựa chọn mặc định của ClickStack vì cung cấp định dạng trung lập nhà cung cấp đã được chuẩn hóa và trải nghiệm onboarding cho người dùng mới
• SysEx gắn chặt với nội bộ ClickHouse và là kiến trúc pull truy vấn trực tiếp bảng system đang chạy; nếu dịch vụ đang crash loop hoặc bị down thì không thể scrape dữ liệu
• OpenTelemetry thụ động thu thập log được emit ra stdout và stderr, nên vẫn có thể lấy log trong lúc xảy ra sự cố ngay cả khi dịch vụ chưa ở trạng thái hoàn toàn healthy
• ClickHouse tiếp tục chạy OpenTelemetry trên mọi dịch vụ ClickHouse nhưng thay đổi phạm vi thu thập
  • Trước đây ingest cả log mức trace
  • Hiện nay chỉ thu thập từ mức info trở lên
• Sau thay đổi này, OTel collector và gateway hoạt động với tài nguyên ít hơn nhiều, và được duy trì như pipeline nhỏ hơn ở quy mô 2M log lines/s đã nêu ở trên

HyperDX và trải nghiệm khám phá native của ClickHouse

• UI đầu tiên của LogHouse là một trải nghiệm observability tùy biến xây trên Grafana, nhưng khi SysEx và telemetry wide-column tăng lên, nhu cầu về một UI tích hợp sâu hơn với ClickHouse cũng xuất hiện
• HyperDX là UI native của ClickHouse, hỗ trợ khám phá log và trace, tương quan hóa và phân tích ở quy mô lớn
• Việc có thể truy vấn bằng cú pháp Lucene giúp việc khám phá dữ liệu đơn giản hơn, còn SQL vẫn được dùng cho các phân tích sự kiện phức tạp
• Cách tiếp cận không phụ thuộc schema của HyperDX v2.0 không yêu cầu cấu trúc một bảng log cố định duy nhất
  • Nó xử lý được định dạng dữ liệu đã chuẩn hóa nhưng vẫn thay đổi của pipeline OpenTelemetry
  • Nó cũng xử lý được các bảng wide-column chuyên biệt từ SysEx và các custom exporter khác mà không cần biết schema trước hay dùng grok pattern phức tạp
• Grafana vẫn còn vai trò trong LogHouse
  • Ứng dụng nội bộ dựa trên Grafana yêu cầu chỉ định namespace để biết dữ liệu dịch vụ nằm ở đâu và định tuyến truy vấn tới instance ClickHouse phù hợp
  • Các dashboard và cảnh báo cũ dựa trên metric Prometheus vẫn được giữ lại trong Grafana
  • Các metric cấp cao như kube_state_metrics có thể không phù hợp để điều tra sâu, nhưng vẫn phù hợp cho alerting

Wide events và observability có cardinality cao

• Việc đưa SysEx vào sử dụng đã thúc đẩy chuyển đổi từ thu thập tập trung vào log stdout sang mô hình dựa trên wide events từ bảng system và dữ liệu có cardinality cao
• ClickHouse gọi cách làm này là sự kết hợp giữa LogHouse và ClickStack thay vì Observability 2.0
• Mô hình này lưu telemetry có cardinality cao từ nhiều nguồn vào một warehouse trung tâm, thay cho mô hình ba trụ cột truyền thống
• Mỗi hàng chứa context phong phú như query identifier, tên Pod, metadata phiên bản và chi tiết mạng, thay vì phải tổng hợp trước hoặc bỏ bớt dimension để phù hợp với giới hạn của metric store
• Dữ liệu được giữ nguyên bản khi ingest và việc tổng hợp được dời sang thời điểm truy vấn
• Điểm khác biệt với Prometheus là mọi data point đều được lưu lại
  • Các trường như insertDuration không bị tổng hợp trước mà từng giá trị được giữ lại cùng các dimension liên quan
  • Nếu Prometheus lưu mọi timeseries cho mọi tổ hợp label thì cardinality sẽ bùng nổ
  • Việc tổng hợp trước histogram giúp kiểm soát tài nguyên nhưng khiến khó trả lời những câu hỏi như spike cụ thể đó là insert của instance nào, bảng nào và trong khoảng thời gian nào
• Elasticsearch cũng khuyến khích wide events và cấu trúc document linh hoạt, nhưng thiết kế columnar của ClickHouse giúp lưu trữ và truy vấn hiệu quả dữ liệu sự kiện cardinality cao, khối lượng lớn ở quy mô lớn

Công cụ khoa học dữ liệu và phân tích SQL

• Từ một wide event, có thể trực quan hóa nhiều đặc tính khác nhau và quay ngược từ một điểm cụ thể trên biểu đồ về log thô
• ClickHouse cung cấp tích hợp trực quan hóa dữ liệu và language clients, nên có thể dùng các công cụ dựa trên SQL như Plotly, Jupyter notebook, Hex, Bokeh và Evidence
• Tìm kiếm theo cú pháp Lucene của HyperDX phù hợp cho tra cứu và lọc nhanh, nhưng các câu hỏi phức tạp vẫn cần SQL
• SQL của ClickHouse có thể biểu đạt join, phép toán theo thời gian và các biến đổi
  • Ví dụ, từ event stream của Kubernetes có thể ghép sự kiện Killing và Created của cùng một container bằng ASOF JOIN để tính thời gian từ lúc dừng đến lúc khởi động lại
  • Truy vấn ví dụ đã xử lý 17.78M hàng và 581.49MB trong 0.099 giây, với peak memory là 272.88MiB
• Thay vì phải tạo sẵn và triển khai từng metric dưới dạng component, có thể suy ra chúng tại thời điểm truy vấn từ warehouse wide events

Các nguồn dữ liệu được bổ sung vào LogHouse

• Theo yêu cầu từ các nhóm kỹ thuật và hỗ trợ, LogHouse đã thêm nhiều sink dữ liệu dựa trên wide event hơn
• kubenetmon: công cụ mã nguồn mở để giám sát mạng Kubernetes, sử dụng Linux conntrack để ghi lại dữ liệu kết nối L3/L4 cùng số byte và packet
  • Nó hỗ trợ forensics, workload·pod attribution và metering để theo dõi chi phí như cross-region egress
  • Dự án: https://github.com/ClickHouse/kubenetmon
• Kubernetes Event Exporter: ClickHouse fork một exporter phổ biến và thêm sink native cho ClickHouse để phân tích sự kiện Kubernetes ở quy mô lớn
  • fork: ClickHouse/kubernetes-event-exporter
  • Trong tương lai, kế hoạch là không chỉ ingest sự kiện mà còn ingest toàn bộ object model của Kubernetes vào LogHouse và lưu snapshot tại mọi thời điểm thay đổi
• Control Plane Data: thu thập dữ liệu vận hành từ bộ phận Control Plane vốn trước đây chưa được onboard vào LogHouse
• Real User Monitoring (RUM): dự án đang triển khai, gửi metric hiệu năng frontend từ trình duyệt người dùng qua public gateway vào pipeline OTel
• Istio Access Log: ingest dữ liệu lưu lượng ở cấp HTTP của Istio service mesh để ghi lại mẫu request·response, độ trễ và quyết định định tuyến
  • Kết hợp với system.query_log và network flow từ kubenetmon, hệ thống có thể phân tích chéo giữa truy vấn SQL, request HTTP và luồng packet

Bước tiếp theo: zero-impact scraping và JSON

• Truy vấn scrape của SysEx bị giới hạn bởi strict memory limit, nhưng điều này có thể gây lo ngại cho khách hàng khi họ nhìn thấy nó trong log và metric
• ClickHouse đang khám phá zero-impact scraping, tức là không chạy truy vấn trên hệ thống đang hoạt động
  • Một hướng hứa hẹn là tận dụng plain rewritable disk trên S3 nơi ClickHouse đã ghi service log
  • Nếu worker pool của SysEx có thể mount trực tiếp bảng log dựa trên đĩa, hệ thống sẽ tránh được việc truy vấn instance ClickHouse đang chạy
• Nếu cách tiếp cận này thành công, nó sẽ giữ được các ưu điểm hiện tại như định dạng native, độ trung thực cao và ít chuyển đổi, đồng thời giảm cả cảm nhận về tác động vận hành
• Kiểu JSON của ClickHouse đã đạt GA trong 25.3, có thể tự động tạo cột với kiểu phù hợp khi xuất hiện trường mới, đồng thời xử lý trường nhiều kiểu và cả schema explosion
• LogHouse đang đánh giá mức độ phù hợp của JSON với các mẫu truy cập observability ở quy mô lớn
  • Việc tìm chuỗi trong toàn bộ JSON blob có thể khiến phải quét hàng nghìn cột
  • Có một cách vòng là lưu chuỗi JSON thô cùng với dữ liệu có cấu trúc
  • Phần lớn log và resource attribute nhỏ và ổn định, nên kiểu Map vẫn phù hợp
  • HyperDX tự động chuyển map access thành hàm JSONExtract