Vì sao ClickHouse đang dẫn trước trong cuộc chiến Observability

• Khác với trải nghiệm dùng grep trên các hệ thống nhỏ, khi số lượng dịch vụ và người tiêu thụ tăng lên, log trở thành loại dữ liệu khó xử lý nhất trong Observability do khối lượng lớn, phi cấu trúc và các truy vấn khó dự đoán chồng lên nhau
• ClickHouse khởi đầu là DB dành cho phân tích clickstream, nhưng rất phù hợp với mẫu sử dụng của log: khối lượng lớn, thiên về ghi bổ sung, theo thứ tự thời gian, đọc dạng tổng hợp
• Cách lưu trữ hướng cột cho phép chỉ đọc các cột cần thiết; với dữ liệu Observability thực tế, ClickHouse cho thấy tỷ lệ nén 10–14x, tương phản với 2–3x của Elasticsearch
• Ở quy mô 1 TB/ngày, nhiều stack đều khả thi, nhưng khi tăng lên 5 TB/ngày và 10 TB/ngày, Elasticsearch, LGTM và Datadog thay đổi mạnh về kiến trúc hoặc chi phí, còn ClickHouse chủ yếu mở rộng bằng cách thêm shard
• ClickHouse đòi hỏi thiết kế schema ban đầu và phải chấp nhận độ phức tạp của query engine, nhưng ngay cả khi dữ liệu tăng theo bội số một hoặc hai chữ số, mô hình vận hành cũng không bị xáo trộn nhiều

---

Vì sao log khó trong Observability

• Nhà phát triển thường kỳ vọng cao vào tìm kiếm log vì từng có trải nghiệm xử lý log nhanh bằng grep, jq, tail -f trên các hệ thống nhỏ
• Cách đó hoạt động tốt khi hệ thống nhỏ, lượng log ít, và người truy vấn cũng chính là người viết ra các dòng log
• Khi quy mô tăng lên, schema drift, bùng nổ cardinality, người tiêu thụ giữa các đội và nhu cầu dashboard xuất hiện đồng thời
• Người sử dụng log không chỉ là nhà phát triển
  • Đội hỗ trợ khách hàng cần tìm các sự kiện như một lần thanh toán thất bại của một người dùng cụ thể
  • Đội dữ liệu có thể xây dashboard nghiệp vụ dựa trên các dòng log mà kỹ sư backend có thể thay đổi
  • Người trực on-call kỳ vọng ô tìm kiếm hoạt động ngay, không cần học ngôn ngữ truy vấn mới hay index pattern
• Về mặt kỹ thuật, khối lượng dữ liệu lớn, hình dạng dữ liệu không đều, và rất khó dự đoán truy vấn nào sẽ được gửi vào
• Nhà phát triển muốn tính tức thời, phép toán tùy ý và schema lỏng; người dùng không chuyên kỹ thuật muốn dashboard ổn định và UI dễ dùng, khoan dung với lỗi

Kiến trúc của ClickHouse phù hợp với log

• ClickHouse được tạo ra tại Yandex để xử lý các truy vấn phân tích quy mô lớn trên dữ liệu clickstream
• Dù không được thiết kế riêng cho Observability, clickstream và dữ liệu Observability có nhiều điểm giống nhau
  • Dữ liệu khối lượng lớn
  • Ghi thiên về bổ sung
  • Lấy trục thời gian làm trung tâm
  • Chủ yếu đọc dạng tổng hợp
  • Thỉnh thoảng cần tìm một bản ghi cụ thể
• Cách vận hành cũng có nhiều lựa chọn
  • Có thể tự chạy bằng Helm chart
  • Có thể dùng plugin ClickHouse của Grafana, web UI riêng, hoặc frontend tự xây
  • Có thể đưa dữ liệu OTLP trực tiếp vào bằng ClickHouse exporter của OpenTelemetry Collector và để nó đảm nhiệm quản lý schema ban đầu
• Được thiết kế để quét hàng chục tỷ dòng và thu thập lượng dữ liệu rất lớn
• Ngôn ngữ truy vấn không phải một ngôn ngữ chuyên dụng mới, mà là SQL

Khác biệt do lưu trữ hướng cột và nén tạo ra

• Về bản chất dữ liệu, log gần như là append-only
  • Không cập nhật dòng log
  • Hầu như không xóa từng bản ghi riêng lẻ; khi hết thời hạn lưu giữ thì xóa hàng loạt
  • Thường đến theo thứ tự thời gian, nhưng không được sắp xếp hoàn toàn
• Mẫu đọc thay đổi bùng nổ khi có sự cố hoặc khi phân tích
  • Có thể nhiều ngày không ai xem, nhưng trong lúc sự cố lại muốn lướt qua hàng chục tỷ bản ghi trong vài giây
  • Thường xem nhiều trường trong một khoảng thời gian hẹp, hoặc tổng hợp trên khoảng thời gian rộng với vài bộ lọc
  • Mẫu tìm một dòng theo một ID cụ thể như trong DB giao dịch là hiếm
• Các DB hướng hàng như Elasticsearch, Postgres, MySQL lưu tất cả trường của một dòng log cùng nhau
  • Dù chỉ cần 3 trong 40 trường, trên đĩa vẫn phải đọc cả 40 trường
• ClickHouse lưu từng cột riêng biệt
  • Truy vấn chỉ dùng timestamp, service, status_code thì chỉ đọc các cột đó
  • Với dữ liệu Observability có hàng chục thuộc tính nhưng một truy vấn cụ thể chỉ dùng 3–4 cột, chênh lệch lượng đọc trở nên rất lớn
• Dữ liệu dạng cột nén tốt vì các giá trị trong cùng một cột thường giống nhau
  • Cột service_name có thể chỉ có vài trăm chuỗi duy nhất dù có hàng chục tỷ dòng
  • Với dữ liệu Observability thực tế, thường thấy tỷ lệ nén 10–14x
  • Điều này tương phản rõ với mức 2–3x của Elasticsearch

Ở mức 1 TB/ngày, hầu hết stack đều khả thi

• Ở quy mô 1 TB/ngày, các stack Observability hiện đại nhìn chung đều dùng được; có khác biệt nhưng chưa đến mức gây đau đớn

• Elasticsearch

  • Có thể vận hành bằng một cụm Elasticsearch tương đối cơ bản và buffer Logstash
  • Tìm kiếm toàn văn bản là điểm mạnh của Elasticsearch và hoạt động tốt ở quy mô này
  • Với dữ liệu hỗn hợp, có rủi ro mapping explosion nên cần tắt dynamic mapping hoặc thiết lập template cẩn thận
  • Chính sách ILM hot → warm → delete là bắt buộc ngay cả ở quy mô này
  • Chi phí khoảng $6–9K/tháng

• LGTM

  • Alloy hợp nhất việc thu thập vào một daemon duy nhất
  • Loki hoạt động tốt khi nhà phát triển được đào tạo để gắn các label hữu ích
  • Mimir và Tempo nhìn chung làm đúng vai trò kỳ vọng
  • Chi phí khoảng $3.5–5K/tháng

• Datadog

  • Ở mức 1 TB/ngày, trải nghiệm sử dụng tốt ở mức chỉ cần cài agent và xem dashboard
  • Các vấn đề về metered pipeline, phân biệt indexed-vs-ingested logs, và chi phí cardinality của custom metrics bắt đầu lộ diện, nhưng vẫn quản lý được ở quy mô này
  • Chi phí khoảng $45–75K/tháng; do giá thương lượng chênh lệch lớn nên con số chỉ nên xem ở mức đại khái
  • Lập luận về giá của Datadog là theo kiểu tiết kiệm được một kỹ sư chuyên trách

• ClickHouse

  • Ở mức 1 TB/ngày, ClickHouse không hẳn ít phức tạp hơn các lựa chọn khác
  • Ban đầu cần thiết kế schema, và khóa ORDER BY cực kỳ quan trọng
  • Có thể đạt nén 10–14x với ZSTD và codec phù hợp
  • Altinity Operator xử lý keeper coordination, và toàn bộ chạy với khoảng 7 pod
  • Không có PromQL native; workflow metrics đi qua plugin Grafana hoặc chproxy và adapter
  • Chi phí khoảng $1.5–2.5K/tháng

Ở mức 5 TB/ngày, khác biệt kiến trúc bắt đầu nới rộng

• Ở mức 5 TB/ngày, đường cong tăng trưởng của hầu hết stack trở nên dốc hơn, và khoảng cách với ClickHouse hiện rõ hơn

• Elasticsearch

  • Kafka gần như trở thành bắt buộc
  • Nếu ghi trực tiếp vào Elasticsearch, các đợt tăng đột biến lưu lượng có thể khiến cụm sập do bulk reject và backpressure
  • Với target shard 50GB, tính cả replica sẽ tạo ra khoảng 200 shard mỗi ngày, và bản thân kích thước cluster state trở thành vấn đề
  • Do searchable snapshot và frozen tier, gần như cần giấy phép thương mại của Elastic
  • Chi phí trước giấy phép khoảng $40–55K/tháng

• LGTM stack

  • Chuyển sang chế độ microservices, vận hành hơn 65 pod và ba hệ thống riêng biệt
  • Mỗi hệ thống có compaction pipeline, hash ring và memcached tier riêng
  • Gossip/memberlist ring trở thành mối quan tâm vận hành thực tế
  • Khi rollout ingester cần tinh chỉnh -ingester.autoforget-unhealthy; làm sai có thể gây mất dữ liệu hoặc trùng lặp
  • Chi phí khoảng $22–32K/tháng

• Datadog

  • Vì không trực tiếp vận hành server, độ phức tạp vận hành thấp
  • Nhưng sẽ cần một đội pipeline chuyên trách để giảm chi phí Datadog
  • Xuất hiện các cơ chế như exclusion filter, sampling rule, cardinality cap, tag allow-list
  • Chi phí khoảng $180–350K/tháng tùy mức độ quyết liệt của đội pipeline
  • Mối quan hệ trở thành việc nhìn tài liệu billing của nhà cung cấp SaaS để cắt giảm chi phí

• ClickHouse

  • Thay đổi lớn nhất là thêm shard
  • Operator, query engine, query language và mental model vẫn giữ nguyên
  • Sau khi thêm shard, việc tái cân bằng là thủ công; phần lớn đội né bằng cách provision trước hoặc dùng weighting của Distributed table
  • Materialized view cho dashboard rollup chuyển từ “có thì tốt” sang gần như bắt buộc
  • Chi phí khoảng $7–11K/tháng

Ở mức 10 TB/ngày, mô hình vận hành tách hướng

• 10 TB/ngày là quy mô mà nhiều giải pháp bắt đầu khó gánh nổi tải vận hành

• Elasticsearch

  • Sẽ vận hành 3 cụm Elasticsearch riêng cho logs, metrics và APM, rồi ghép bằng Cross-Cluster Search
  • Chi phí NVMe của hot-tier chi phối hóa đơn
  • Ở quy mô này, các đội bắt đầu đánh giá nghiêm túc các lựa chọn thay thế, và nhiều ca migration sang ClickHouse gần đây cũng xuất phát từ đây
  • Chi phí khoảng $95–140K/tháng ngoài giấy phép thương mại
  • Vận hành Elasticsearch ở quy mô này cần chuyên gia thực thụ

• LGTM

  • Cần hơn khoảng 180 pod, cấu hình zone-aware, split-and-merge compaction, limit theo tenant, và shuffle sharding để tránh noisy neighbor
  • Gần như cần một đội Observability platform chuyên trách 3–5 người
  • Chi phí khoảng $55–85K/tháng

• Datadog

  • Vẫn dễ theo nghĩa không có server phải tự vận hành, nhưng hóa đơn hằng tháng có thể lên 6–7 chữ số
  • Tổ chức nhiều khả năng sẽ lập đội pipeline tiền xử lý để giảm hóa đơn
  • Nhiều công ty ở quy mô này dùng Datadog cho APM và metrics giá trị cao, còn logs thì đưa sang tự host theo cấu hình hybrid
  • Đích tự host ngày càng thường là ClickHouse
  • Kết quả là sự đơn giản của Datadog, độ phức tạp của pipeline và một stack tự host thứ hai cùng tồn tại
  • Chi phí rất khác nhau và có thể trên $1M/tháng

• ClickHouse

  • Bức tranh cơ bản giống cấu hình 1 TB/ngày, khác biệt là có nhiều shard hơn
  • Materialized view cho rollup không còn là lựa chọn mà là bắt buộc
  • Sai lầm thiết kế schema từ 2 năm trước có thể lộ ra rất đau ở quy mô này
  • Sau khi thêm shard, việc tái cân bằng vẫn là thủ công
  • Phần lớn đội provision trước hoặc dùng clickhouse-copier, dual-write migration
  • Với ingest rất bursty, Kafka trở nên hữu ích làm buffer nhưng không bắt buộc
  • Chi phí khoảng $18–28K/tháng

Tiêu chí lựa chọn

• Ở mức 1 TB/ngày, stack nào nhìn chung cũng chạy được, nên hãy chọn thứ đội đã biết
• Câu hỏi quan trọng không phải là hôm nay nó có chạy không, mà là sau 2 năm, khi dữ liệu tăng 5 lần, đội tăng gấp đôi và người thiết kế ban đầu đã rời đi, nó có giữ được cùng hình dạng không
• Elasticsearch và LGTM thay đổi kiến trúc khi quy mô tăng
• Datadog đơn giản về vận hành, nhưng về chi phí thì chuyển thành dạng cần một đội kế toán/pipeline riêng
• ClickHouse mở rộng theo cách thêm shard
• Cái giá phải trả là cần chấp nhận thiết kế schema ban đầu và độ phức tạp của query engine
• Nếu trả cái giá đó, ngay cả khi dữ liệu tăng hơn một bậc độ lớn, trải nghiệm của nhà phát triển và người vận hành nhìn chung vẫn được giữ nguyên

[GN⁺]

Ý kiến trên Lobste.rs

• Startup nơi tôi từng làm một thời gian ngắn vào năm 2019 đã tạo ra khá nhiều thứ ấn tượng, và lúc đó họ có cho tôi xem qua ClickHouse, để lại ấn tượng rất mạnh
  Trước đó tôi nghĩ hiếm khi nào lại cần thứ gì ngoài PostgreSQL, nhưng ClickHouse khiến tôi muốn thử dùng
  Tôi cũng đã dùng ElasticSearch, InfluxDB các kiểu nhưng lúc nào cũng thấy không ổn lắm, có lẽ vì mỗi bên đều tự tạo lại ngôn ngữ truy vấn từ đầu. Trong khi đó ClickHouse chọn SQL quen thuộc và chỉ mở rộng hợp lý ở những phần cần thiết
  Giống như nhiều sản phẩm thành công khác, ClickHouse cho thấy chất lượng triển khai tốt và sự quan tâm tới người dùng, với cả những chi tiết nhỏ cũng được đặt mặc định rất chuẩn
  Ở công ty hiện tại tôi đang dùng HyperDX; phần biểu đồ metric hơi phiền một chút nhưng tracing thì hoạt động khá tốt. Tôi từng nghĩ tracing sẽ nhanh chóng trở thành công cụ thiết yếu và giúp tăng năng suất rất lớn, nhưng nhìn vào việc nó không được tiếp nhận mạnh như kỳ vọng thì có vẻ đây không hẳn là tính năng làm thay đổi cục diện như tôi tưởng. Dù vậy, việc ClickHouse trở thành một tay chơi cốt lõi trong mảng này để mình bớt phải đụng vào những thứ khác vẫn là điều đáng mừng

  • Theo kinh nghiệm của tôi, đưa tracing vào một tổ chức vốn chỉ sống bằng metric và log là một con dốc khá gắt
    Cần rất nhiều hoạt động truyền bá, thu thập use case, và cả công việc vất vả là trực tiếp cho mọi người thấy giờ họ có thể làm những việc trước đây không làm được, cũng như những việc từng khó nay đã dễ hơn thế nào
    Về mặt kỹ thuật nữa, việc triển khai cũng phải càng trơn tru càng tốt, nhưng tùy stack và hoàn cảnh mà bản thân chuyện đó đã có thể là một nỗ lực lớn, và thường gánh nặng ấy rơi vào người đang thúc đẩy việc áp dụng
    Nó không khác mấy với một sáng kiến cấp tổ chức trải rộng, nên sẽ hữu ích nếu có một hai tín đồ thực sự có uy tín cá nhân và có thể lan tỏa nó trong công ty
  • Không rõ bạn đang nói đến ngôn ngữ truy vấn JSON của ElasticSearch phải không. ElasticSearch hỗ trợ multiple query languages, bao gồm cả một phương ngữ SQL
    Tôi không rõ chất lượng hỗ trợ đó thế nào, nhưng thứ tôi từng dùng trực tiếp chỉ là ngôn ngữ truy vấn JSON, còn mấy cái kia thì vừa mới biết
    Với tư cách là ngôn ngữ truy vấn thì SQL không hoàn hảo. Việc không thể lặp lại mệnh đề và không thể viết theo thứ tự tùy ý khá khó chịu, nhưng dù vậy SQL vẫn là một ngôn ngữ rất tốt

• Trải nghiệm của tôi cũng khá giống tác giả. Khả năng mở rộng của ClickHouse tốt đến mức đáng kinh ngạc, và ngay cả khi tự vận hành thì cũng gần như chỉ cần thêm nhiều core hơn
  Chi phí thiết lập ban đầu có thể cao hơn đôi chút, nhưng schema thì gần như đã được OTel export quyết định sẵn nên cứ bắt đầu từ đó, rồi khi cần hiệu năng truy vấn cao hơn thì tách thêm cột và materialized view là được
  Đổi lại, bạn bớt phải lo về mở rộng, có thể trực tiếp dùng toàn bộ dữ liệu cho phân tích, và cũng có thể suy ra metric từ trace
  Tuy vậy, mảnh ghép còn lại của bài toán là trực quan hóa vẫn cần được cải thiện nhiều. Grafana không phải là lựa chọn tối ưu để hiển thị và phân tích trace nếu so với những công cụ như Honeycomb. Hy vọng một trong các tay chơi hiện có sẽ sớm giải quyết được chuyện này, có thể là HyperDX

• Bài này lúc đầu tạo cảm giác mở màn rất mạnh với phần dẫn nhập thuyết phục, nhưng đến đoạn phân tích nhiều công ty thì lại sụp xuống thành một bài viết kiểu liệt kê mang văn phong LLM ít công sức rất rõ
  Đọc lại phần mở đầu một cách phê phán hơn thì tôi cũng ngày càng thấy những dấu vết như vậy
  Đây là kiểu mẫu tôi thấy ngày càng thường xuyên trong các bài trên Lobsters gần đây, nên tôi muốn để lại như một suy nghĩ ngắn về một quan sát chung hơn là nhằm công kích bài cụ thể nào
  Cá nhân tôi không có nhiều kinh nghiệm với công cụ observability, nên một số phần của bài vẫn thấy thú vị bất kể cách nó được viết ra sao. Nhưng tôi không muốn mắc lỗi là tin LLM ở những chủ đề mình không quen, rồi lại bảo bài do LLM viết là flawed ở những chủ đề mình quen
  Vì thế tôi không thật sự biết liệu có nên tin bài này hay phần lớn các bài tương tự về mặt факt hay không. Có vẻ khá rõ là tác giả đã giao phần lớn việc suy nghĩ cho máy, nhưng bản thân ý tưởng khởi đầu có vẻ cũng khá rõ ràng
  Ngay cả khi lập trình, những ý nghĩ tưởng như rõ ràng trong đầu tôi cũng chỉ thực sự khiến tôi chấp nhận rằng mình đang thiếu sót điều gì đó căn bản khi tôi bắt tay viết chương trình, để rồi thất bại ở các bài test edge case hoặc không qua được kiểm tra kiểu
  Viết lách cũng vậy; nếu không tự xây dựng lập luận, lắp ráp toàn bộ bài viết và cẩn thận cân nhắc phản biện, thì tôi không nghĩ giá trị truyền tải sẽ vượt quá cái ý tưởng rõ ràng ban đầu
  Có lẽ đây cũng chính là điểm mà những người muốn viết code theo kiểu chỉ lưu lại prompt cho các LLM tương lai đang muốn nói tới
  Nhưng nếu lập trình hay viết lách đều thành như vậy, thì không chỉ tư duy mà cả tính chặt chẽ, sự tận tâm và sự tôn trọng cũng bị từ bỏ
  Tôi không rõ Lobsters nên làm gì về việc này. Tag vibecoding có vẻ đã là một giải pháp quá tải. Nhưng có lẽ một tag kiểu mùi LLM như tín hiệu cảnh báo thiếu tính chặt chẽ cũng sẽ hữu ích

  • Tôi cũng không muốn đăng chuyện này thành bình luận cấp cao nhất, nhưng khi bấm vào bài thì đúng là toàn sáo ngữ kiểu LLM, nên tôi hơi tiếc thời gian đã bỏ ra để đọc phần đầu
  • Với góc nhìn của người từng dùng công cụ observability một chút, bài này trông khá rõ ràng và hợp lý
    Luận điểm cốt lõi là mỗi sản phẩm mở rộng theo cách khác nhau, và bài cho thấy điều gì xảy ra ở từng quy mô bằng biểu đồ cùng các giải thích cụ thể
    Nếu có đoạn nào khiến bạn cảm thấy tác giả rõ ràng đã từ bỏ việc suy nghĩ, tôi khá tò mò muốn xem ví dụ
  • Ít nhất thì Matthew là người khá am hiểu về observability. Anh ấy từng là tech lead ở Braintree và hiện là Principal tại SYBO, công ty nổi tiếng với Subway Surfers
    Những chỗ có chửi thề cũng phần nào cho thấy giọng điệu riêng của anh ấy
    Nếu cho vào GPTZero thì nó ra 71% khả năng là LLM, 28% là trộn lẫn. Tuy vậy, do giới hạn số ký tự nên phần dẫn nhập nghe giống con người nhất lại bị cắt mất
    Tôi hiểu sự khó chịu đó, nhưng đây có vẻ là một bài thực sự đã được rà soát và chỉnh sửa lặp đi lặp lại, chỉ là không quá cố lọc bỏ những cách diễn đạt mang màu LLM hay tối ưu lại giọng văn. Giờ đây chỉ riêng việc không dùng em dash cũng không còn đủ để tránh bị nghi ngờ nữa

• Tôi muốn nghe từ những người có kinh nghiệm với Honeycomb xem nó khớp vào bối cảnh này như thế nào
  Theo tôi biết, Honeycomb cũng dùng định dạng lưu trữ dạng cột, và phụ thuộc nhiều vào nén cùng bucketing để bỏ qua lượng lớn dữ liệu khi đọc. Tôi không nghĩ nó dùng cách lập chỉ mục ngược như Elastic hay Datadog, và tôi cũng hiểu là Datadog nội bộ có chạy Elastic

  • Tôi nhớ vài năm trước, đồng sáng lập Honeycomb là Charity Majors từng nói trên Twitter rằng nếu hồi họ bắt đầu công ty mà đã có ClickHouse thì có lẽ họ đã cứ thế dùng nó rồi
    Dù vậy, tôi không chắc hai hệ thống thực sự chồng lấn nhau về mặt ý tưởng đến mức nào. Sẽ khá thú vị nếu biết liệu chính miền bài toán này đã tự nhiên dẫn tới những cách tiếp cận tương tự hay không; cá nhân tôi đoán là có

• Có thể một số người sẽ thấy khó chịu, nhưng tôi thấy cách dùng một số từ nhất định quá mức gây phân tâm, nên tôi chỉ tìm và thay thế chúng bằng những từ không gây chú ý, và bài viết trở nên tốt hơn hẳn
  Tôi sẽ không nói đó là từ nào, nhưng đó là kiểu diễn đạt ngày càng bị dùng thiếu chính xác nên khiến tôi khó chịu. Thật tốt khi chỉ với thao tác search-and-replace đơn giản là tôi đã có thể đọc bài thoải mái hơn nhiều