Thay thế OTel và mở rộng nền tảng quan sát với Wide Events

• LogHouse đã mở rộng từ 19PiB lên hơn 100PB dữ liệu log chỉ trong 1 năm, xử lý tới gần 500 nghìn tỷ hàng
• Do các vấn đề về giới hạn xử lý dữ liệu và hiệu quả của OpenTelemetry(OTel), hệ thống đã chuyển sang pipeline tùy biến (SysEx) phù hợp với hệ thống cốt lõi
• Việc chuyển đổi này mang lại hiệu quả với thông lượng xử lý sự kiện tăng 20 lần nhưng mức sử dụng CPU vẫn dưới 10%
• Việc áp dụng HyperDX và ClickStack của ClickHouse đã xây dựng được môi trường tích hợp UI và dữ liệu, độ linh hoạt schema, cùng khả năng khám phá dữ liệu mạnh mẽ
• Thông qua việc áp dụng mô hình wide events và high-cardinality, hệ thống có thể lưu trữ và phân tích mọi sự kiện mà không cần tổng hợp trước

---

Bối cảnh và thay đổi

• LogHouse, nền tảng logging nội bộ cho ClickHouse Cloud, đã phát triển thành một hệ thống quy mô lớn chỉ trong 1 năm, với dữ liệu tăng từ 19PiB lên hơn 100PB và từ 37 nghìn tỷ hàng lên gần 500 nghìn tỷ hàng
• Ban đầu, toàn bộ telemetry được thu thập qua OpenTelemetry(OTel), nhưng trong môi trường dữ liệu khối lượng lớn, các vấn đề về hiệu năng, giới hạn tài nguyên, cùng tình trạng lãng phí CPU và mất dữ liệu trong quá trình chuyển đổi dữ liệu ngày càng nổi bật

Giới hạn của OTel và lý do đưa vào pipeline tùy biến

• Pipeline của OTel hoạt động rất kém hiệu quả vì log bị chuyển sang JSON, sau đó lại được ánh xạ về định dạng OTel, với nhiều lần chuyển đổi và marshalling lặp đi lặp lại
• Trên thực tế, để xử lý 20 triệu hàng mỗi giây bằng nền tảng OTel cần tới khoảng 8.000 lõi CPU
• Khi lưu lượng tăng đột biến, Collector bị quá tải dẫn đến hiện tượng rơi log, làm phát sinh dữ liệu không được thu thập

Triển khai SysEx và kiến trúc

• SysEx(System Tables Exporter) chuyển dữ liệu từ system tables của ClickHouse trực tiếp sang LogHouse với đúng kiểu dữ liệu gốc, không qua chuyển đổi
• Hệ thống đáp ứng SLA nội bộ bằng cơ chế scraping phân tán qua hash ring, buffer trễ thời gian và cửa sổ trượt để tránh mất dữ liệu
• Sử dụng Go và các khả năng tùy biến của ClickHouse client để truyền byte-to-byte mà không cần marshalling dữ liệu
• Để xử lý schema biến đổi, hệ thống áp dụng schema hash và quản lý schema động, đồng thời dùng Merge table engine để hợp nhất nhiều phiên bản schema thành một góc nhìn logic duy nhất
• Hỗ trợ thu thập bảng bộ nhớ theo snapshot, phục vụ các tác vụ chẩn đoán và phân tích nâng cao

Cải thiện hiệu năng và hiệu quả

• Sau khi đưa SysEx vào, OTel Collector xử lý 2 triệu log/giây với 800 CPU, trong khi SysEx có thể xử lý 37 triệu log với 70 CPU
• Mức cải thiện hiệu quả này giúp giảm mạnh mức sử dụng tài nguyên, ngăn mất sự kiện và hiện thực hóa môi trường hỗ trợ thời gian thực

Vai trò tiếp tục của OTel

• OTel vẫn quan trọng vì cung cấp nền tảng tiêu chuẩn, trung lập với nhà cung cấp, và vẫn là thành phần thiết yếu khi có sự cố dịch vụ hoặc trạng thái bất thường
• Ngay cả trong các tình huống crash hoặc bất thường mà SysEx không thể xử lý, OTel vẫn có thể ghi lại log
• Hiện tại hệ thống chỉ loại bỏ log dưới mức trace và thu thập từ mức info trở lên để tối ưu tài nguyên

Tích hợp UI, HyperDX và ClickStack

• Hệ thống đang dần chuyển từ UI Grafana tùy biến cũ sang UI native của ClickHouse dựa trên HyperDX
• HyperDX cung cấp khả năng tương thích hoàn toàn với nhiều kiểu dữ liệu phong phú của ClickHouse nhờ không phụ thuộc schema, hỗ trợ truy vấn Lucene và hỗ trợ SQL
• Dữ liệu từ nhiều cấu trúc bảng khác nhau và từ các exporter tùy biến cũng có thể được tích hợp mà không cần thay đổi UI
• Grafana tiếp tục đảm nhiệm metric dựa trên Prometheus và các dashboard cố định, giúp hai giải pháp bổ sung cho nhau

Tiếp nhận mô hình Wide Events và high-cardinality

• Wide events là cách tiếp cận đột phá, trong đó mỗi hàng chứa nhiều ngữ cảnh như query ID, tên Pod, thông tin phiên bản..., cho phép lưu toàn bộ dữ liệu mà không cần tổng hợp
• Khác với Prometheus và các hệ thống tương tự, cách này cho phép phân tích sâu và truy vấn linh hoạt mà không phải lo tổng hợp trước, giới hạn label hay bùng nổ cardinality
• Bằng cách chỉ thực hiện tổng hợp vào thời điểm phân tích dữ liệu, hệ thống có thể tối ưu đồng thời hiệu năng và chi phí ngay cả trong môi trường dữ liệu cực lớn

Trực quan hóa dữ liệu và độ linh hoạt truy vấn

• ClickHouse tích hợp rất tốt với Plotly, Jupyter notebook và nhiều công cụ trực quan hóa khác, cho phép sử dụng linh hoạt nhiều công cụ
• Ngoài khả năng khám phá nhanh qua HyperDX dựa trên Lucene, ClickHouse còn cho phép phân tích nguyên nhân chuyên sâu trực tiếp bằng các truy vấn quan hệ và điều kiện phức tạp như SQL, JOIN

Gia tăng các nguồn dữ liệu dựa trên Wide Event

• kubenetmon: mã nguồn mở giám sát mạng Kubernetes, dùng để phân tích lưu lượng L3/L4, kết nối và chi phí
• Kubernetes Event Exporter: sử dụng bản fork có thêm ClickHouse sink để theo dõi thay đổi trạng thái trong các cụm lớn, đồng thời đang thử nghiệm snapshot toàn bộ object
• Control Plane Data, RUM(Real User Monitoring), Istio Access Log và nhiều lớp dữ liệu khác giúp mở rộng đáng kể phạm vi diễn giải và khả năng phân tích tương quan

Các cân nhắc vận hành và hướng đi sắp tới

• SysEx có thể bị lộ trong log hoặc metric khi đang truy vấn, nhưng được thiết kế với giới hạn bộ nhớ và cấu trúc giảm thiểu tác động khi lỗi xảy ra
• Zero-impact scraping: đang nghiên cứu cách tiếp cận loại bỏ tận gốc cả tác động lên cluster, thông qua kiến trúc tách rời hoàn toàn, chẳng hạn sử dụng plain rewritable disk dựa trên S3
• OTel vẫn là thành phần quan trọng để đảm bảo thu thập log ở giai đoạn đầu dịch vụ hoặc trong trạng thái bất thường, nhưng khi cách tiếp cận zero-impact ổn định hơn, mức độ phụ thuộc dự kiến sẽ tiếp tục giảm

Sự phát triển và ứng dụng của kiểu JSON trong ClickHouse

• Kiểu JSON đã chính thức GA, cho phép tạo cột động theo từng field, hỗ trợ nhiều kiểu dữ liệu và linh hoạt ứng phó với bùng nổ schema
• Do việc tối ưu truy vấn JSON với số lượng cột lớn chưa hoàn hảo, hệ thống đang tiếp tục tinh chỉnh cách tiếp cận như lưu song song theo từng dạng và tái khẳng định tính thực tiễn của Map type
• Kết hợp với HyperDX, hệ thống có thể tự động trích xuất và phân tích các field Map và JSON, với kế hoạch mở rộng sử dụng JSON hơn nữa trong tương lai

Kết luận và thay đổi về văn hóa

• LogHouse giờ đây đã trở thành nền tảng quan sát cốt lõi cho vận hành ClickHouse Cloud, từ phân tích hiệu năng đến debugging thời gian thực
• Dù mục tiêu ban đầu là cắt giảm chi phí, việc đưa vào các công cụ tùy biến như SysEx, phối hợp với OTel và mở rộng UI linh hoạt dựa trên HyperDX đã tạo ra một sự chuyển đổi kỹ thuật và văn hóa
• Mô hình dữ liệu dựa trên Wide Event ở quy mô lớn với độ chính xác cao đang mang lại giá trị và hiệu quả mới cho kỹ thuật, hỗ trợ và phân tích dữ liệu
• Trong tương lai, dựa trên kinh nghiệm thu được ở quy mô 100PB và 500 nghìn tỷ hàng, hệ thống sẽ tiếp tục dẫn dắt tương lai của observability

[GN⁺]

Ý kiến trên Hacker News

• Thành thật mà nói, tôi không nghĩ đây là điều gì đáng để khoe. Việc đang lưu tới 100PB log là bằng chứng cho thấy họ vẫn chưa xác định được thứ gì thực sự cần giữ lại. Phần lớn thông tin cốt lõi hoàn toàn có thể nắm được bằng metric và event có cấu trúc. Còn phần còn lại? Toàn là trace log chi tiết mà chẳng ai đọc, chỉ lôi ra xem khi sự cố thực sự nổ ra. Cách làm tốt hơn ư? Áp dụng “chính sách lưu trữ dựa trên mức độ quan tâm”, kiểu như tự động xóa những log chưa từng được dùng cho cảnh báo, hoặc không xuất hiện trong truy vấn nào suốt 3 tháng. Nếu không đi theo hướng đó, thì đây chỉ là một đống rác số cực kỳ cao cấp được nén lại đôi chút mà thôi
  • Tôi thì ngược lại, thích thu thập toàn bộ dữ liệu rồi lọc khi không cần hơn. Debug log bình thường không cần đến, nhưng lúc cần thì lại tuyệt đối không thể thiếu. Nếu có một sự kiện hiếm đến mức không thể tái hiện, thì lúc đó không thể quay lại để thu thập dữ liệu lần nữa. Nếu mọi thứ đã được lưu sẵn thì chỉ cần tìm ra là xong, tôi thấy như vậy tốt hơn nhiều
  • Tôi từng làm ở nhiều công ty dùng Datadog, và khi chi phí gia hạn tăng vô lý thì lúc nào cũng bị ép chỉ giữ metric và một lượng event hạn chế, còn log thì phải cắt giảm. Vấn đề là, nếu biết trước chuyện gì sẽ xảy ra thì đã sửa từ lâu rồi. Khi có gì đó bất thường và phải lần mò xem rốt cuộc đã xảy ra chuyện gì, thì log chi tiết cực kỳ cần thiết. Nhưng thực tế là nếu tình huống không lặp đi lặp lại, ta không có cách nào biết trước log nào sẽ quan trọng
  • “Chính sách lưu trữ dựa trên mức độ quan tâm” đúng là một ý tưởng rất hay. Chỉ cần đếm số lần truy cập qua truy vấn/cảnh báo theo từng mẫu log là cũng có thể xây dựng chính sách TTL (thời gian lưu trữ). Thực tế đội của chúng tôi đã áp dụng cách này, giảm 70% chi phí lưu trữ mà vẫn giữ lại toàn bộ dữ liệu quan trọng
  • Chi phí gửi log cũng không phải miễn phí. Đặc biệt với các ngôn ngữ cố ghi log ra đĩa nhanh nhất có thể để phục vụ việc tìm nguyên nhân crash thì chi phí còn lớn hơn. Thông tin quá nhiều cũng khiến việc tìm ra tương quan thực sự quan trọng khó hơn, và log của các bug đã được xử lý thì giá trị giảm rất nhanh. Tôi thích dữ liệu thống kê hơn. Dữ liệu thống kê có cách tổng hợp hiệu quả hơn, và nhất là với các ngôn ngữ dựa trên GIL thì dùng OTEL đôi khi tạo overhead quá lớn
  • Nếu dữ liệu đã được lưu rồi, thì chuyện lọc hay dọn dẹp sau này vẫn giải quyết được. Lưu hết tất cả rồi dùng khi cần vẫn tốt hơn là đến lúc cần lại không có. Tất nhiên, điều đó chỉ đúng khi bạn có đủ tài nguyên để vận hành hạ tầng lớn như vậy
• Thực ra chuyện này chỉ áp dụng cho log của ClickHouse. Với các loại log khác thì không liên quan lắm. Dù sao thì bản thân ClickHouse vẫn là một giải pháp tôi rất thích
  • Chắc là kiểu người rất vui ở các bữa tiệc
• Tôi muốn nhắc một điểm cần chú ý. Khi dịch vụ rơi vào crash loop hoặc bị down vì sự cố, với SysEx bạn không thể truy cập các system table cần thiết nên không thu thập được log. Nhưng OpenTelemetry (OTel) là cách tiếp cận thụ động, nên ngay cả khi dịch vụ chưa phục hồi hoàn toàn, nó vẫn có thể lấy các log đi ra stdout, stderr. Nhờ vậy có thể thu thập log trong trạng thái lỗi và phân tích tới tận nguyên nhân gốc
  • Các dự án OTel tôi từng làm đều là cách tiếp cận chủ động. Vì vậy đoạn đó với tôi không hẳn là thông tin mới, mà giống như mô tả sai hoặc chưa đầy đủ hơn
• Tôi nghi ngờ chuyện “wide event” thực sự phải tốn nhiều dung lượng lưu trữ đến vậy. Về bản chất, observability là một bài toán lấy mẫu. Chỉ cần với dung lượng tối thiểu mà vẫn tái dựng được trạng thái ở một thời điểm nào đó tốt nhất có thể là đủ. Có thể giảm số mẫu hoặc tăng hiệu quả nén. Nhưng tôi cũng không nghĩ công nghệ nén đã đi tới giới hạn. Với dữ liệu đầy trùng lặp như thế này, chắc chắn phải tồn tại cấu trúc low rank rất lớn. Dĩ nhiên người ta đã dùng inverted index và đủ loại cây khác nhau, nhưng tôi vẫn thấy có triển vọng ở các phương pháp mang tính nghiên cứu hơn như phân rã tensor low rank. Tôi cũng không làm trong ngành này nên có thể đang bỏ sót điều gì đó
• Tôi chưa từng trải nghiệm quy mô như ClickHouse. Log ở mức dung lượng như vậy có thực sự tìm kiếm được không? Tôi biết ElasticSearch truy vấn khá tốt ở quy mô nhỏ. Vậy vì sao nên dùng ClickHouse cho historical log thay vì chỉ lưu file json?
  • Tôi đang làm ở quy mô này. Nói ngắn gọn là có thể. Nhưng chi phí xử lý có thể vượt xa sức tưởng tượng. Nếu chiến lược indexing, sorting, clustering tệ, thì chỉ một lần tìm “bản ghi có chứa chuỗi này” cũng có thể tốn $1~$10. Theo kinh nghiệm của tôi, với dữ liệu lớn thì nguyên tắc quan trọng nhất luôn là “đụng vào ít dữ liệu nhất có thể” và “di chuyển ít nhất có thể”. Chỉ cần thêm một lần serialization/deserialization hoặc disk, network IO là chi phí có thể tăng vọt. Với OTel, việc cho dữ liệu đi qua thêm một collector có thể mâu thuẫn trực diện với hiệu quả vận hành. Nhưng ở quy mô petabyte, số tiền tiết kiệm được từ những tối ưu nhỏ như vậy vẫn dư sức trả lương cho kỹ sư viết mã serialization phức tạp
  • Vì sao dùng ClickHouse cho historical log thay vì file json? Có vài lý do. (1) Các DB log như ClickHouse dùng nén theo cột, nén riêng từng field nên tốn ít dung lượng hơn rất nhiều so với file json thông thường, kể cả đã nén. (2) DB log truy vấn nhanh hơn nhiều. Nhanh hơn 1000 lần cũng là chuyện có thể, vì nó không đọc những dữ liệu không cần thiết. Liên kết liên quan. (3) Tìm kiếm bằng grep trên 100PB file json về mặt thực tế là bất khả thi. Còn DB log có thể scale ngang bằng cách tăng số node lưu trữ và dung lượng lưu trữ
  • Đây là vấn đề về quy mô và chi phí. Công ty chúng tôi cũng đụng trần về volume log. Nếu cứ đổ thẳng json vào Splunk thì sẽ tốn hơn 6 triệu USD mỗi năm. Trong khi ngân sách được duyệt chỉ bằng 5~10% con số đó. Bài viết nói rằng xử lý json log cần 8.000 CPU, nhưng sau tối ưu thì chỉ còn cần 90 CPU
  • Cách đây 2~3 năm, ClickHouse còn hơi yếu về hiệu năng full text search. Nó nhanh và cũng xử lý được dữ liệu lớn cỡ ElasticSearch, nhưng tùy theo mục đích sử dụng, nếu không index trước thì tôi thấy ES nhanh hơn nhiều ở các tác vụ batch, grouping và FTS
• Chủ nghĩa cực đoan observability đúng là có cảm giác như một tôn giáo mới nổi. Mà lại còn rất nhiều tiền nữa
  • Nếu muốn đào sâu cả những bất thường chưa từng được biết tới, thì thực sự cũng chẳng có lựa chọn sắc bén nào khác
  • Điều buồn cười là chính họ tạo ra các vấn đề kiểu này để người khác phải khổ sở, rồi cuối cùng lại bán chiến lược “chỉ cần trả phí thuê bao hàng tháng là giải quyết hết”
• Trong bài không nói retention của log là bao lâu. Sau một khoảng thời gian nhất định, tôi nghi ngờ việc vẫn giữ raw data là cần thiết; có lẽ chỉ cần để lại dữ liệu tóm tắt/tổng hợp
• Mỗi lần quay lại Postgres sau khi dùng ClickHouse đều như một cú sốc văn hóa. Tôi không thể hiểu nổi vì sao import một bản dump 20GB lại mất đến vài phút. Chuyện đó lẽ ra phải xong trong vài giây chứ?
  • Mỗi lần dùng ClickHouse là tôi lại thấy rất mệt. Tất nhiên ClickHouse có những trường hợp sử dụng mà Postgres không thể thay thế hết, nhưng bằng cách nào đó tôi vẫn thấy ClickHouse có quá nhiều “yếu tố rủi ro”, và trừ những mục đích rất đặc thù, thì gần như ở mọi mặt Postgres đều tốt hơn
• Những người cổ vũ dùng wide event không nói nhiều về chuyện chi phí dữ liệu log bùng nổ. So với cách làm truyền thống (metric + trace + log dựa trên lấy mẫu), nó rõ ràng tốn tiền hơn nhiều. Chắc chắn có lợi ích, nhưng vấn đề chi phí thì lúc nào cũng bị bỏ qua
  • Một cấu trúc wide event được thiết kế đúng cách thực ra có thể giảm chi phí lưu trữ so với log truyền thống. Một external request sẽ được ghi lại thành một wide event duy nhất, nên về sau lúc debug hay phân tích cũng đã có đủ thông tin cần thiết. Xem thêm bài này: A practitioner's guide to wide events
• Tôi tò mò về mánh khóe cốt lõi của các hệ thống như ClickHouse hay Dynamo. Về bản chất nó có giống một hash table khổng lồ không?
  • Có hai mánh khóe chung ở các DB quy mô lớn như ClickHouse. Thứ nhất, bố trí dữ liệu trên đĩa một cách thông minh để có thể bỏ qua phần lớn dữ liệu và chỉ đọc những khối cần thiết thôi, ví dụ như lưu trữ dạng cột và các kiểu LSM tree. Đồng thời nén toàn bộ dữ liệu lưu trữ để giảm cả disk IO. Thứ hai, tinh chỉnh tới cực hạn để tận dụng tối đa mọi tài nguyên như CPU, RAM, đĩa và mạng. Ví dụ ClickHouse có thể xử lý hơn 1 tỷ row mỗi giây trên mỗi lõi CPU, và scale tuyến tính theo số lượng lõi