ハクソク

世界を動かす技術を、日本語で。

Show HN: ClickStack – ClickHouseとHyperDXによるオープンソースのDatadog代替品

354日前原文(github.com)

概要

HyperDXはClickStackの中心的コンポーネントで、ClickHouse上でログ・トレースの検索と可視化を高速かつ簡単に実現。 KibanaのClickHouse版ともいえる存在で、直感的なUIと柔軟なスキーマ対応が特徴。 OpenTelemetry対応で多様な言語・環境に対応し、APMやアラート、ダッシュボード機能も充実。 DockerやClickHouse Cloudで手軽に導入可能、既存環境との連携も容易。 OSSとしてMITライセンスで公開、活発なコミュニティと貢献の機会を提供。

HyperDXとは

  • ClickStack の中核を担う 可観測性ツール
  • ClickHouseクラスタ 上で ログ・トレースの検索と可視化 を実現
  • Kibana のClickHouse版という位置付け
  • 直感的なUI と Luceneライクな検索構文 （例：level:err）を提供
  • SQL不要、必要ならSQLモードも利用可能
  • スキーマ非依存 で既存のClickHouseスキーマにそのまま対応
  • 高速な検索・可視化 をClickHouseのパフォーマンスで実現
  • アノマリー分析 や イベントデルタ によるトレンド解析
  • アラート設定 や ダッシュボード機能 も数クリックで利用可能
  • ネイティブなJSONクエリ、 ライブテール 機能で常に最新のイベントを確認
  • OpenTelemetry標準対応、多様な言語・プラットフォームをサポート

主な機能

  • ログ・メトリクス・トレース・セッションリプレイ を一元管理
    • ブラウザ、Node.js、Python など多彩なSDK・インテグレーション
  • APM機能 でHTTPリクエストからDBクエリまでのパフォーマンス監視
  • 高カーディナリティイベント のダッシュボード化
  • アラート や 異常検知 で障害の早期発見
  • ライブデモ や ドキュメント、 Discordコミュニティ でのサポート

導入・デプロイ方法

  • Dockerコマンド一発 でHyperDXを起動可能
    • docker run -p 8080:8080 -p 4317:4317 -p 4318:4318 docker.hyperdx.io/hyperdx/hyperdx-all-in-one
    • UIはhttp://localhost:8080 でアクセス
  • ClickStack 構成：ClickHouse、HyperDX、OpenTelemetry Collector、MongoDBを含む
  • 既存ClickHouseインスタンス への接続や 本番環境用デプロイ にも対応
  • ファイアウォール 設定：8080（UI）、8000（API）、4318（OTel Collector）ポートを開放
  • 最低4GB RAM/2コア を推奨
  • ClickHouse Cloud でも利用可能、数分でセットアップ完了

アプリケーションのインストルメント

  • アプリからのテレメトリデータ送信 が必要
    • SDK/インテグレーション を利用して簡単に導入
    • OpenTelemetry 互換、 Kubernetes/Javascript/Python/Java/Go/Ruby/PHP/.NET/Elixir/Rust など幅広く対応
  • OpenTelemetry Collector （http://localhost:4318）へのデータ送信で連携完了

貢献とコミュニティ

  • OSS（MITライセンス） で公開、誰でも貢献可能
  • PR、バグ報告、ドキュメント改善、機能要望 など多様な貢献方法
  • GitHub、Discord、メール での連絡手段
  • 匿名の利用データ収集 （USAGE_STATS_ENABLEDで無効化可）、多様な環境対応のため協力を推奨

開発の動機・背景

  • エンジニアが信頼性の高いソフトウェアを迅速に出荷 できることを支援
  • 既存の可観測性ツールの課題
    • コスト高騰、大容量テレメトリ時代にスケールしない
    • 導入・運用が難解、専任SREや専門知識が必要
    • ツール間の連携不足、情報の断片化
  • ClickStack でこれらの課題を一括解決、OSSならではのコスト効率と柔軟性を実現

参考リンク・リソース

  • GitHubリポジトリ: https://github.com/hyperdxio/hyperdx
  • ライブデモ: https://play.hyperdx.io/
  • 公式ドキュメント: https://clickhouse.com/docs/use-cases/observability/clicksta...
  • Discordコミュニティ: https://hyperdx.io/discord
  • ランディングページ: https://clickhouse.com/o11y

まとめ

  • HyperDX/ClickStack は ClickHouse のパワーを活用し、 可観測性の民主化 を目指す
  • 低コスト・高性能・OSS でエンジニアの運用負荷とコストを大幅に削減
  • 多機能・直感的UI・高い拡張性 で現場のニーズに即応
  • コミュニティ主導で進化中、フィードバック歓迎

Hackerたちの意見

HyperDXを使ってるんだけど、すごく気に入ってるよ。チームがClickhouseと統合してくれたのも素晴らしいね。HyperDXに切り替えたら、コスト効率がかなり良くなったから、経済的にも大きな価値があったと思う。もしかして、元のHyperDX製品が廃止される準備を始めた方がいいのかな？それともClickStackに移行するべき？

└

まず最初に、私たちのプロダクションユーザーからの声を聞くのはいつもすごく楽しみなんだ。プラットフォームから良い価値を得てるって聞けて嬉しいよ！HyperDXは廃止されるわけじゃないし、マーケティングページでもまだ重要な部分としてしっかり紹介されてるから、そこは変わらないよ。もちろん、ユーザーをHyperDX v2や全体のClickStackパターンに移行させたいと思ってる。これがHyperDXが消えるって意味じゃなくて、HyperDXはエンドユーザー体験にもっとフォーカスしてるし、ClickStackの意図である、よりオープンなClickHouseを活用した柔軟性や学び、パフォーマンスを活かせるんだ。エンジニアリングの面では、オープンソースとクラウドの両方でスムーズな道を確保するために取り組んでるよ。ちなみに、これに返信したと思ってたけど、今日はWi-Fiが不安定で苦労してるんだ :)

Signozとは何が違うの？あっちもClickhouseを使って観測性を提供してるYCの会社だよね。

└

ここでの「You」はClickHouseのことね。

└

下のコメントに同意するけど、明らかに一つのことは、私たちはClickHouseのチームで、公式のファーストパーティ製品があるってことだね。これはつまり、- どんなClickHouseインスタンスの上でも柔軟に使えるってこと。ほぼどんなスキーマでもClickHouseで動くし、カスタムスキーマは高パフォーマンスを調整するためや、Anthropicのようなスケールに達したときに重要なんだ。これによって、特にClickHouseにデータが既にある場合、すぐに始めやすくなる。 - 上記はOTelを購入する必要がないことも意味してる。OTelは好きだけど、いくつかの企業はVector、Cribl、S3、カスタム書き込みスクリプトなどを使うことを選んでる理由がある。これらはすべてClickHouseのさまざまな統合によってネイティブにサポートされていて、そのシナリオでもClickStack/HyperDXを使えるってことだ。 - 大規模なテレメトリを扱うためのクールなツールもいくつかあって、Event Deltas（遅いスパンと通常のスパンの間の高カーディナリティ相関）からEvent Patterns（類似のログやスパンを自動的にMLでクラスタリング）まで、これらはすべてユーザーがデータに簡単にアクセスするのを助けるんだ。 - セッションリプレイ機能もあって、クリックからインフラメトリックスまでを真に統一できる。私たちはClickHouse Cloudのモニタリングのために内部で運用している100PB以上のスケールで動作するように作られてるけど、サポートケースで持ち上がった特定のユーザーの問題をエンドツーエンドで特定するのにも柔軟なんだ。多分、もっとたくさんのことを見逃してるかも。最終的には、製品哲学の観点から、私たちは「3つの柱」コンセプトをあまり信じていない。これは「ログ」、「メトリクス」、「トレース」のための3つのサイロ/タブとして現れることが多いから（これはSignozだけじゃなくて、業界全体に言えること）。私は、信号や手がかりを一つの場所に統一して集中させ、エンジニアに適切なデータポイントを適切なタイミングで提供するツールを作っていると信じてる。インシデントの時は、問題の根本原因を探るための次の手がかりを考えるだけで、ログ製品やトレース製品にいるかどうかは気にしないんだ。

Otelはトレースには良かったし、ログにも使えそうだけど、Otelのメトリクスはちょっと過剰だと思う。ClickStackはstatsdデータを取り込む方法がある？できればDatadogの拡張機能（タグ付けができるやつ）と一緒に。ClickStackはトレース、ログ、メトリクスを統一サービスタグで関連付けることができるのかな？UIは関連するトレースやログ、メトリクスにリンクする機能がある？ElixirのSDKがotelライブラリじゃなくてhyperdxライブラリを使ってる理由は何？ノートブックはロードマップに入ってる？

└

Otelのメトリクスはちょっと過剰だと思う。何が難しいの？他のメトリクスソース、例えばstatsdやDDエージェントのためのレシーバーを設定できるから、すぐにメトリクススタックを置き換える必要はないよ。

└

いい質問だね！OTelメトリクスについてだけど、みんなのお気に入りのメトリクス基準のほぼスーパーセットとして指定されてるのが分かるよ。プッシュ/プルの設定や、単調 vs デルタ、指数的/"ネイティブ"ヒストグラムとかね。私も基準のサブセットとしての好みがあるけど、統一基準が柔軟である必要がある理由は理解できる。Statsdについては、OTelコレクターの素晴らしいところは、さまざまなデータフォーマットを取り込めることなんだ。だから、statsdを取り込んでOTelに出力したり、直接ClickHouseに書き込んだりできるよ。https://github.com/open-telemetry/opentelemetry-collector-co... トレース/スパンIDやリソース属性を通じて相関を取ってるし、ログ/トレース間の相関もかなり使われてるよ。メトリクスはリソース属性を通じてネイティブに処理されていて、主にK8sベースのワークロードの相関を公開してるけど、もっと増やす予定だよ。メトリクスの一般的な相関ケースを解決するためのエグゼンプラはまだやってないけど（statsdがエグゼンプラを送信できるかは分からないけど）。Elixirについては、ユーザーがどこにいてもサポートするように頑張ってる。OTel SDKと私たちのは時間とともに並行して変わってきたから、Elixir用の基本OTel SDKに向かうべきか再評価したいと思ってる。OTel SDKの側ではかなり早い段階から進めてきたから、まだ進化し続けてるよ。例えば、私たちのDeno OTel統合は、Denoが公式にネイティブHyperDXドキュメントと共にローンチする1年以上前に出たと思う <3 ノートブックについては、すぐに実験的な状態でリリースされるはずだから、楽しみにしててね :) ノートブックで解放したいエキサイティングなワークフローがたくさんあるんだ。もしこの方向で何か考えがあれば、ぜひ教えてほしい。初回リリース前にもっとユーザーの意見を聞きたいから。

ログ集約ツールが多すぎて、完全に把握できなくなっちゃった。Datadogを使ってたけど、高すぎてUIもすごく混乱してた。

└

何かが必要になると、こういうことが起こるんだよね。提供されるものが爆発的に増えて、最終的には生き残るのがほんの数個になる。

└

みんなDatadogが高すぎるって感じてるみたい！だからPrometheusとGrafanaに切り替えて、今度はPrometheusクラスターを管理しなきゃいけなくなった。ずっと安くなるけど、めっちゃ面倒だよね。

└

Datadogは良い製品だけど、使った中で一番明らかに高すぎるものの一つだな。

これは本当に面白いね。Clickhouseはこのスタックの唯一のステートフルな部分なの？Rotel[0]（OTELコレクターのRust実装）との互換性があれば、サーバーレスのランタイム環境でも使えるようになるから見てみたいな。Datadogの一つの強みは、OTELコレクターの独自の代替品を持っていて、パフォーマンスがかなり良いことなんだ。[0]: https://github.com/streamfold/rotel

└

そうだね、rotelはOTelの軽量なラムダ統合にすごく合ってると思う。もちろん、OTelの取り込みエンドポイントを立ててるから、データを送るのもスムーズにできるはず！(これがOTelの魅力の一つだよね) MikeとRayとも少し連絡を取ってて、最近ClickHouseのサポートを追加したって聞いたから、さらに良くなりそうだね :)

Kibanaの代わりになる新しいログソリューションを探してるんだ。ClickHouseの経験はすごく良いし、HyperDXはそれに合ったUIに見える。主にログに興味があるんだけど、既存のログ送信パイプラインはKubernetes上のVectorを使ってる。確かにVectorにはOTelシンクがベータであるけど、元のデータがアプリからプレーンJSONとして出てくることを考えると、それがログを送信する最良かつ最速の方法なのか気になる。現在のシステムは毎日数TBを処理していて、かなりのスループットが必要なんだ。

└

幸いなことに、ClickHouseと真剣なスループットはほぼ同義だよ。内部では、私たちのモニタリングシステムに100PB以上のテレメトリが保存されてる。VectorはClickHouseへの直接書き込みをサポートしていて、いくつかの企業はこれをスケールで使ってる（確かAnthropicもこれをやってるって、最近のユーザー会議で話してた）。ぜひ試してみて、どうだったか教えてね！手伝うよ :)

すごく興味深いね。残念ながら、HyperDXはMongoに依存してるみたい？これと連携できるオープンソースのドキュメントストア（Mongo互換のものとか）があるか気になるな。

└

理論的には、FerretDBを試してみるのがいいかもね。中期的なロードマップには、Ferretのような互換性レイヤーの適切なサポートを調査することが含まれてるけど、実際にはClickHouse自体を運用データストアとして使う可能性が高いかな。

└

FerretDBは素晴らしい代替手段に見えるね、ありがとう！FerretとClickStackはチェックしておくよ！

Dockerコンテナを使うときにサインインする必要ある？

└

ローカルデバッグワークフローの一環としてエンジニア向けに設計されたローカルモードというバージョンがあるよ。詳しくはここを見てね: https://clickhouse.com/docs/use-cases/observability/clicksta... それ以外は、他のバージョンに対してメールアドレスとパスワードで認証できるよ（実際にはオープンソース版ではメールは特に意味がないけど、一応ユーザー識別子として残してるんだ）。

DataDogがこんなに高いことを考えると、これは本当にクールだね。私はLogLayerの作者なんだけど（https://loglayer.dev）、これはTypeScript用の構造化ロガーで、複数のロガーを一緒に使えるんだ。pinoやDataDogのようなクラウドプロバイダーに送信するためのトランスポートも書いたよ。この投稿を見てHyperDXの統合を作るのに少し時間をかけたから、ぜひ手伝ってほしいな！LogLayerとHyperDXの使い方を説明するドキュメントにリンクする新しい「統合」セクションをページに追加したいんだ。 https://github.com/hyperdxio/hyperdx-js/pull/184

Datadogは高いのは確かだけど、遅いと感じたことはないな。スピードは彼らの売りではないし、ログやメトリクスが流れ込んでからできることが全てだよ。ダッシュボードの作成は直感的だし、Airflowのログからアラートを作るのも彼らのDSLを使えば簡単だよ。Slackみたいなところに通知を送るのもスムーズにできるしね。だから、エンジニアリングの時間（エンジニアはまだ高いし、AIが私たちを置き換えたわけじゃない）を節約できるから、Datadogのコストを正当化できるんだ。生のログやメトリクスから有用なインサイトに素早く移行できるのが大きいよ。