ClickStack – ClickHouseとHyperDXで構築されたオープンソースのDatadog代替

 (clickhouse.com)
4 ポイント 投稿者 GN⁺ 2025-06-07 | 1件のコメント | WhatsAppで共有
  • ClickStack は ClickHouse と HyperDX を基盤とするオープンソースの オブザーバビリティ（Observability） プラットフォームで、ログ、メトリクス、トレース、セッションリプレイを1か所で統合的に扱える
  • ログおよびトレースの検索と可視化 を ClickHouse クラスター上で簡単かつ高速に実現し、どのようなスキーマでも追加作業なしで適用可能
  • 直感的な検索、イベントベースのアラート、ダッシュボード機能を提供し、エンジニアが迅速に問題を把握して対応できる
  • OpenTelemetry 標準をデフォルトでサポートし、多様な言語およびプラットフォーム 向け SDK 統合を提供
  • 既存の商用ソリューションに比べて 低コストで設定が簡単 であり、複数の観測ツールを行き来することなく、1つのプラットフォームで一連の作業を処理できる

主な機能

  • ログ、メトリクス、セッションリプレイ、トレースの 相関分析 と検索を1か所で実行可能
  • ClickHouse の既存スキーマをそのまま活用できる スキーマに依存しない構造
  • 高速な検索性能 と可視化の最適化により、大規模データにも適している
  • 全文検索と属性検索 の両方をサポートし、SQL の使用は任意
  • イベント変化の推移分析や 簡単なアラート設定、ダッシュボード の作成が可能
  • Native JSON 文字列クエリ をサポート
  • リアルタイムのログ、トレース tail 機能により最新イベントを確認可能
  • OpenTelemetry 統合および APM（性能モニタリング） 環境をサポート

デプロイと開始方法

  • ClickStack パッケージは ClickHouse、HyperDX、OpenTelemetry Collector、MongoDB を含めて統合デプロイ可能
  • HyperDX UI はブラウザからアクセス可能
  • ClickHouse Cloud 環境とも連携でき、多様な環境へ容易にデプロイしやすい

アプリケーション計測と統合

HyperDX でログ、メトリクス、トレース、セッションリプレイのデータを収集するには、アプリケーションからテレメトリデータを HyperDX に送信する必要がある

  • SDK および統合オプション を提供: ブラウザ、Node.js、Python など多様な言語/環境向け SDK があり、簡単に連携可能
  • OpenTelemetry 標準をサポート: Kubernetes、JavaScript、Python、Java、Go、Ruby、PHP、.NET、Elixir、Rust など多様な言語およびランタイムに対応
  • OpenTelemetry Collector はデフォルトで http://localhost:4318 で接続可能

貢献方法

  • PR 提出、Issue 登録、ドキュメント改善、オープン Issue への投票、新しいユースケースの提供など、さまざまな形でのコミュニティ貢献を歓迎

開発の動機と哲学

HyperDX 開発チームの目標は、すべてのエンジニアが本番環境のテレメトリを活用して素早く問題を解決できるようにすること である

従来の主な問題点:

  • 運用オブザーバビリティツールは 高価で、データ拡張に応じてコストが増加する 問題が大きい
  • 設定や利用の難易度 が高く、SRE や専門家が必要
  • ログ、セッションリプレイ、APM など 各機能が分離されて おり、情報の連携が煩雑

こうした限界を克服するため、ClickStack と HyperDX はオープンソースとして提供されている

  • HyperDX は ClickHouse に買収された

関連記事

1件のコメント

 
GN⁺ 2025-06-07
Hacker Newsのコメント

  • 既存のGrafanaではなく、なぜカスタムフロントエンドを作ったのか気になる

  • DataDogの価格が高いため、HyperDXが本当に魅力的に感じられるという状況の共有。自分が運営するLogLayer(https://loglayer.dev)はTypeScript向けの構造化ロガーで、複数種類のロガーやクラウドサービス（DataDogなど）へログを送信できる機能をサポートしている。HyperDX向けの統合機能を開発しており、まもなくリリース予定とのこと。HyperDXとLogLayerの連携方法に関するドキュメントへのリンクを、自分のサイトの「integrations」セクションに追加したいという希望を伝え、関連PRへのリンク(https://github.com/hyperdxio/hyperdx-js/pull/184)も共有

    • VictoriaLogsへログを送信できる機能も追加してほしいという要望。さまざまなデータインジェストプロトコルのドキュメントへのリンク(https://docs.victoriametrics.com/victorialogs/data-ingestion/)とともに提案
    • LogLayerとHyperDXの連携機能は良さそうなので、自分でも確認してみるという前向きなフィードバック

  • HyperDXを実際に本番環境で使用しており、Clickhouseとの統合やコスト効率に非常に満足している。HyperDXからClickStackへの移行準備が必要なのか気になる

    • 本番ユーザーからのフィードバックはいつも非常にありがたいという歓迎の言葉。HyperDXがなくなることは決してなく、マーケティングページでも引き続きスタックの中核として強調されていると説明。今後はHyperDX v2とClickStackパターンにより注力する計画だが、HyperDX自体は引き続きエンドユーザー体験を重視していく予定との案内。ClickHouseベースのコアの柔軟性と性能をさらに活用することがClickStackの目標だという補足説明もあり、オープンソースとクラウドの両方でスムーズに移行できるようエンジニアリングに注力していると共有。余談として、最近Wi‑Fiが不安定で返信が遅れたことにも触れている

  • Otelのトレースとロギングは良いが、Otel metrics機能は複雑すぎる設計だと感じる点を共有。ClickStackでstatsdデータ（特にDatadogのタグ拡張を含む）をインジェストできるか、トレース/ログ/メトリクスの統合サービスタグ付けと関連付け機能があるか、UIに関連データへのリンク機能があるか、Elixir SDKがなぜhyperdxライブラリを使っているのか、Notebooks機能がロードマップにあるかを質問

    • 良い質問だと応じつつ、OTel metrics標準が非常に多様化した理由や残念な点への共感を示す。OTel collectorはstatsdなど多様なフォーマットを収集し、ClickHouseへ直接書き込めるためstatsdも活用可能との案内(statsdreceiverドキュメント)。ログ/トレースはtrace/span idとresource attributesで関連付け可能で、k8s workloadではメトリクスまで相関を提供していると言及。metrics correlationについてはまだexemplars機能をサポートしていないが、今後の予定として言及。Elixir SDKはユーザー環境に合わせてサポートしたいという方針で選択しており、ライブラリは独立して進化してきたが、今後公式OTel SDKへ移行するか検討中とのこと。Deno向けOTel integrationを迅速に導入した事例も共有。Notebooksはまもなく実験的な状態で公開予定で、さまざまなワークフローを有効化する予定、さらに多くのユーザーフィードバックに関心があるという意思表示
    • なぜOtel metricsが複雑だと感じるのかを尋ねつつ、statsdやDD agentなど既存のメトリクスパイプラインを簡単に置き換えなくてもよいのが利点だと案内

  • SignozのようにClickHouseベースで、オープンソース版とクラウド版を提供している点がHyperDXと似て見えるという意見と、違いは何かという疑問。UIも似ているという観察の共有

    • Signozとの直接比較について、さらに詳しく聞きたいという追加の疑問

  • Kibanaを置き換える新しいロギングソリューションを探しており、ClickHouseの使用経験が良かったためHyperDXのUIに関心がある。現在のログパイプラインはKubernetes上のVectorで、VectorがOTel sink（ベータ）をサポートしているので、データがJSONである状況で最適なログ送信方法を考えているという共有。TB単位の大規模・高性能トラフィック環境であることも強調

    • ClickHouseは大容量処理と高スループットに特化しており、VectorからClickHouseへ直接書き込むユースケース（例: Anthropicの発表）にも言及。実際に試して感想を残してくれれば支援したいという提案
    • データ転送フォーマットをotelで標準化するのは、将来に向けて戦略的に良い選択だという意見。2つの悩みが減ったように感じるという共有

  • SignozとHyperDX（あるいはClickHouse）との違いが気になる。どちらもYC出身で、ClickHouseを活用しているという観察

    • 下で言及されているように、最大の差別化要因はClickHouseチームが公式に開発している1st-party製品であること。ほぼすべてのClickHouseインスタンスで柔軟に動作し、カスタムスキーマもサポートしている。これは高性能チューニングや特定の大規模環境（例: Anthropic）で重要。すでにClickHouseのデータを持っている場合、導入が非常に容易という利点もある。otelを無理に強制せず、Vector、Cribl、S3、カスタムスクリプトなどもネイティブにサポート。Telemetry wrangling（高カーディナリティイベント差分、MLベースの自動ログ/スパンクラスタリングなど）機能もあり、データ探索がしやすい。session replay機能により、クリックからインフラメトリクスまで全方位で統合をサポート。社内のClickHouse Cloud監視では100PB+規模で運用され、特定ユーザーの問題までend-to-endで把握できる柔軟性がある。思想的には、一般的な「3 pillars」（logs/metrics/traces）の分離よりも、単一化・中央集約された手がかり探索ツールを作る方が実務のデバッグに適していると考えているとの共有
    • 「You」がClickHouseを指していることを明確化

  • サインアップ後、UIで"Was this search result helpful?"ウィジェットが検索前から表示されていてUXが混乱したという体験の共有。Hideボタンを押すとフィードバックボタンになり、再びフィードバックを押すと元に戻るというバグも発見。全体的にフォントがモノスペースで文字も小さく、太い白や明るい緑が暗い背景と調和していないと評価。システムフォントに変えても大きく改善せず、より伝統的なUIスタイルを勧めたいとのこと。読みにくいデザインのため利用をためらってしまうというフィードバック

  • Clickhouseがこのスタックで唯一のstateful要素なのか気になる。RustベースのOTEL collectorであるRotel(https://github.com/streamfold/rotel)との互換性にも関心がある。Datadogには自社開発の、より高性能なOTEL collector代替があるとも言及

    • Rotelはlambdaなどの軽量環境でのOTel連携に適していると考えている。HyperDXのOTelインジェストエンドポイントはすでに標準的なので、そのまま互換性があるはずだとの見解。Rotel開発者たちともやり取りしており、Clickhouseサポートが最近追加されたことで全体のストーリーがより強固になった点も強調