ClickStack – giải pháp thay thế Datadog mã nguồn mở được xây dựng với ClickHouse và HyperDX

 (clickhouse.com)
4 điểm bởi GN⁺ 2025-06-07 | 1 bình luận | Chia sẻ qua WhatsApp
  • ClickStack là một nền tảng quan sát (Observability) mã nguồn mở dựa trên ClickHouse và HyperDX, tích hợp xử lý log, metric, trace và session replay tại một nơi
  • Hỗ trợ tìm kiếm và trực quan hóa log và trace dễ dàng, nhanh chóng trên cụm ClickHouse, đồng thời có thể áp dụng với mọi schema mà không cần thao tác bổ sung
  • Cung cấp tìm kiếm trực quan, cảnh báo dựa trên sự kiện và tính năng dashboard để kỹ sư có thể nhanh chóng xác định và xử lý sự cố
  • Hỗ trợ tiêu chuẩn OpenTelemetry mặc định và cung cấp tích hợp SDK cho nhiều ngôn ngữ và nền tảng
  • So với các giải pháp thương mại hiện có, nó rẻ hơn và dễ cấu hình hơn, đồng thời cho phép xử lý toàn bộ quy trình trên một nền tảng mà không cần phải chuyển qua lại giữa nhiều công cụ quan sát

Tính năng chính

  • Có thể xử lý phân tích tương quan và tìm kiếm log, metric, session replay và trace tại một nơi
  • Tận dụng nguyên trạng schema sẵn có của ClickHouse với cấu trúc không phụ thuộc schema
  • Phù hợp với dữ liệu dung lượng lớn nhờ tốc độ tìm kiếm nhanh và tối ưu trực quan hóa
  • Hỗ trợ cả full-text search và tìm kiếm theo thuộc tính, việc dùng SQL là tùy chọn
  • Có thể phân tích xu hướng thay đổi của sự kiện và thiết lập cảnh báo đơn giản, tạo dashboard
  • Hỗ trợ truy vấn chuỗi JSON native
  • Có thể kiểm tra các sự kiện mới nhất bằng tính năng tail log và trace theo thời gian thực
  • Hỗ trợ tích hợp OpenTelemetry và môi trường APM (giám sát hiệu năng)

Triển khai và cách bắt đầu

  • Gói ClickStack có thể được triển khai tích hợp cùng ClickHouse, HyperDX, OpenTelemetry Collector và MongoDB
  • Có thể truy cập giao diện HyperDX từ trình duyệt
  • Cũng có thể tích hợp với môi trường ClickHouse Cloud và dễ dàng triển khai trong nhiều môi trường khác nhau

Đo lường ứng dụng và tích hợp

Để thu thập dữ liệu log, metric, trace và session replay bằng HyperDX, ứng dụng cần gửi dữ liệu telemetry đến HyperDX

  • Cung cấp SDK và tùy chọn tích hợp: có SDK cho nhiều ngôn ngữ/môi trường như trình duyệt, Node.js, Python nên có thể tích hợp dễ dàng
  • Hỗ trợ tiêu chuẩn OpenTelemetry: tương thích với nhiều ngôn ngữ và runtime như Kubernetes, JavaScript, Python, Java, Go, Ruby, PHP, .NET, Elixir, Rust
  • Trình thu thập OpenTelemetry mặc định có thể kết nối tại địa chỉ http://localhost:4318

Cách đóng góp

  • Hoan nghênh cộng đồng đóng góp theo nhiều cách như gửi PR, đăng ký issue, cải thiện tài liệu, bỏ phiếu cho issue mở hoặc cung cấp các use case mới

Động lực phát triển và triết lý

Mục tiêu của đội ngũ phát triển HyperDX là giúp mọi kỹ sư có thể tận dụng telemetry trong môi trường vận hành để giải quyết sự cố nhanh chóng

Các vấn đề chính hiện có:

  • Công cụ quan sát cho môi trường vận hành đắt đỏ và chi phí tăng theo mức mở rộng dữ liệu
  • Độ khó cấu hình và sử dụng cao, cần đến SRE và chuyên gia
  • Các chức năng như log, session replay, APM bị tách rời, khiến việc liên kết thông tin trở nên bất tiện

Để vượt qua những giới hạn này, ClickStack và HyperDX được cung cấp dưới dạng mã nguồn mở

  • HyperDX đã được ClickHouse mua lại

Bài viết liên quan

1 bình luận

 
GN⁺ 2025-06-07
Ý kiến trên Hacker News

  • Thắc mắc vì sao lại làm frontend tùy chỉnh thay vì dùng Grafana vốn đã có sẵn

  • Chia sẻ rằng giá DataDog quá đắt nên HyperDX thực sự rất hấp dẫn; LogLayer(https://loglayer.dev) mà người này đang vận hành là một structured logger cho TypeScript, hỗ trợ gửi log đến nhiều loại logger và dịch vụ đám mây khác nhau (như DataDog), đồng thời cho biết đang phát triển tính năng tích hợp cho HyperDX và sẽ sớm phát hành; bày tỏ mong muốn thêm liên kết tài liệu về cách tích hợp HyperDX và LogLayer vào mục "integrations" trên site của mình; chia sẻ liên kết PR liên quan(https://github.com/hyperdxio/hyperdx-js/pull/184)

    • Yêu cầu thêm cả tính năng gửi log đến VictoriaLogs, đồng thời đề xuất kèm liên kết tài liệu về các giao thức ingest dữ liệu đa dạng(https://docs.victoriametrics.com/victorialogs/data-ingestion/)
    • Phản hồi tích cực rằng phần tích hợp giữa LogLayer và HyperDX trông rất hay, và sẽ tự kiểm tra thử

  • Đang dùng HyperDX trong production thực tế và rất hài lòng với khả năng tích hợp với ClickHouse cũng như hiệu quả chi phí; thắc mắc liệu có cần chuẩn bị migration từ HyperDX sang ClickStack hay không

    • Bày tỏ vui mừng và luôn rất mong chờ phản hồi từ người dùng production; giải thích rằng HyperDX chắc chắn sẽ không biến mất và trên trang marketing vẫn được nhấn mạnh là phần cốt lõi của stack; cho biết sắp tới sẽ tập trung hơn vào HyperDX v2 và mô hình ClickStack, nhưng bản thân HyperDX vẫn sẽ tiếp tục đặt trọng tâm vào trải nghiệm người dùng cuối; giải thích thêm rằng mục tiêu của ClickStack là tận dụng nhiều hơn tính linh hoạt và hiệu năng của phần lõi dựa trên ClickHouse; chia sẻ rằng đang tập trung vào engineering để quá trình thay đổi diễn ra mượt mà ở cả bản open source lẫn cloud; nói thêm bên lề rằng gần đây Wi‑Fi không ổn định nên trả lời hơi chậm

  • Chia sẻ rằng trace và logging của Otel thì ổn, nhưng tính năng metrics của Otel có cảm giác được thiết kế quá phức tạp; hỏi liệu ClickStack có thể ingest dữ liệu statsd (đặc biệt có cả phần mở rộng tagging của Datadog) hay không, có hỗ trợ gắn thẻ dịch vụ thống nhất và liên kết giữa trace/log/metric hay không, UI có tính năng liên kết dữ liệu liên quan hay không, vì sao Elixir SDK lại dùng thư viện hyperdx, và tính năng Notebooks có nằm trong roadmap không

    • Hưởng ứng rằng đây là những câu hỏi hay, đồng thời đồng cảm với việc chuẩn OTel metrics trở nên quá đa dạng và đáng tiếc ở điểm đó; cho biết OTel collector có thể thu thập nhiều định dạng như statsd và ghi thẳng vào ClickHouse nên có thể dùng statsd(liên kết tài liệu statsdreceiver); nhắc rằng log/trace có thể liên kết bằng trace/span id và resource attributes, còn trong workload k8s thì hiện cũng có cung cấp tương quan tới metrics; nói rằng hiện chưa hỗ trợ exemplars cho metrics correlation nhưng có kế hoạch trong tương lai; Elixir SDK được chọn theo hướng hỗ trợ phù hợp với môi trường người dùng, thư viện này đã phát triển độc lập và hiện đang cân nhắc có nên chuyển sang OTel SDK chính thức hay không; chia sẻ trường hợp đã nhanh chóng tự tích hợp OTel cho Deno; Notebooks sẽ sớm được công bố ở trạng thái thử nghiệm để mở ra nhiều workflow khác nhau; bày tỏ mong muốn nhận thêm phản hồi từ người dùng
    • Hỏi thêm vì sao Otel metrics lại tạo cảm giác phức tạp, đồng thời cho biết một ưu điểm là không nhất thiết phải dễ dàng thay thế các pipeline metrics hiện có như statsd hay DD agent

  • Nhận xét rằng Signoz có vẻ giống HyperDX ở chỗ đều dựa trên ClickHouse và đều có phiên bản open source lẫn cloud; thắc mắc điểm khác nhau là gì, đồng thời quan sát thấy UI cũng khá giống

    • Muốn nghe thêm so sánh trực tiếp với Signoz

  • Đang tìm một giải pháp logging mới để thay Kibana, và vì có trải nghiệm tốt với ClickHouse nên quan tâm đến UI của HyperDX; chia sẻ rằng pipeline log hiện tại là Vector chạy trên Kubernetes, Vector đang hỗ trợ OTel sink (beta), nên đang cân nhắc cách gửi log tốt nhất khi dữ liệu ở dạng JSON; nhấn mạnh đây là môi trường traffic lớn, hiệu năng cao, quy mô TB

    • Cho biết ClickHouse rất phù hợp với xử lý quy mô lớn và throughput cao; nhắc đến các trường hợp dùng ghi trực tiếp từ Vector vào ClickHouse (ví dụ bài nói chuyện của Anthropic); đề nghị cứ thử thực tế rồi để lại ý kiến, họ sẽ hỗ trợ
    • Cho rằng việc chuẩn hóa định dạng truyền dữ liệu sang otel là lựa chọn tốt về mặt chiến lược cho tương lai; chia sẻ cảm giác như bớt được hai mối bận tâm

  • Thắc mắc sự khác nhau giữa Signoz và HyperDX (hoặc ClickHouse), quan sát rằng cả hai đều xuất thân từ YC và đều dùng ClickHouse

    • Giải thích rằng như đã nói ở dưới, điểm khác biệt lớn nhất là đây là sản phẩm 1st-party do chính đội ngũ ClickHouse phát triển; nó hoạt động linh hoạt trên gần như mọi instance ClickHouse và còn hỗ trợ schema tùy chỉnh, điều này quan trọng cho việc tinh chỉnh hiệu năng hoặc các môi trường quy mô lớn cụ thể (ví dụ Anthropic); nếu đã có sẵn dữ liệu trong ClickHouse thì việc áp dụng sẽ rất dễ; không ép buộc phải dùng otel mà còn hỗ trợ native cho Vector, Cribl, S3, script tùy chỉnh...; cũng có các tính năng telemetry wrangling (delta sự kiện có độ phân biệt cao, tự động gom cụm log/span bằng ML, v.v.) giúp việc khám phá dữ liệu dễ hơn; có cả session replay để hỗ trợ tích hợp toàn diện từ click đến metrics hạ tầng; đang vận hành ở quy mô 100PB+ trong hệ thống giám sát nội bộ của ClickHouse Cloud và có đủ linh hoạt để theo dõi end-to-end đến cả các vấn đề của từng người dùng cụ thể; về mặt triết lý, họ tin rằng thay vì tách biệt kiểu "3 pillars" (logs/metrics/traces), việc xây dựng một công cụ khám phá manh mối thống nhất/tập trung sẽ phù hợp hơn với công việc debug thực tế
    • Làm rõ rằng “You” ở đây là ClickHouse

  • Chia sẻ trải nghiệm rằng sau khi đăng ký, widget "Was this search result helpful?" đã hiện ra trên UI ngay cả trước khi tìm kiếm nên UX khá rối; phát hiện bug là bấm nút Hide thì hiện nút phản hồi, rồi bấm phản hồi lần nữa thì mọi thứ quay lại như cũ; đánh giá tổng thể rằng font monospace được dùng xuyên suốt, chữ lại nhỏ, màu trắng đậm và xanh lá sáng phối với nền tối trông không hài hòa; ngay cả khi đổi sang font hệ thống cũng không cải thiện nhiều nên khuyến nghị một phong cách UI truyền thống hơn; phản hồi rằng thiết kế khó đọc khiến họ ngần ngại sử dụng

  • Hỏi liệu ClickHouse có phải là thành phần stateful duy nhất trong stack này hay không; quan tâm đến khả năng tương thích với Rotel(https://github.com/streamfold/rotel), một OTEL collector viết bằng Rust; nhắc rằng Datadog có một giải pháp thay thế OTEL collector do họ tự phát triển với hiệu năng tốt hơn

    • Cho biết họ đánh giá Rotel phù hợp với việc tích hợp OTel trong các môi trường nhẹ như lambda; vì endpoint ingest OTel của HyperDX đã là tiêu chuẩn nên nhiều khả năng sẽ tương thích ngay; cũng đã trao đổi với các nhà phát triển Rotel, và việc hỗ trợ ClickHouse mới được thêm gần đây khiến toàn bộ câu chuyện trở nên vững chắc hơn