HyperDXでログとトレースを同じ画面から調べる
生産上の問題を迅速に解決します。 ClickHouse と OpenTelemetry を利用して、セッション リプレイ、ログ、メトリクス、トレース、エラーを統合するオープンソースの可観測性プラットフォーム。
ひと目でわかる
- これは何？
- OpenTelemetryを軸にログ、メトリクス、トレースを集約するHyperDXの構成と導入判断を整理します。
- 誰に向いている？
- アプリケーションのログと分散トレースを一つの調査画面で結びたいチームに向きます。最初はREADMEのDocker Compose手順で隔離環境を起動し、OpenTelemetryのサンプルを送って検索結果とトレース相関を確認してください。
- 商用利用できる？
- できます。MIT は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。直近 1 日以内に新しいコミットがあります。
- 何の言語で書かれている？
- 主に TypeScript です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
HyperDXが扱う観測データ
HyperDXは開発者向けのオブザーバビリティ基盤として説明され、ログ、メトリクス、トレースを調査対象にします。サービスごとに別の画面へ移る代わりに、エラーが発生した時刻のログから関連するリクエストを追い、トレース上の処理へ移る流れを目指します。READMEの説明は機能の方向性を示しますが、保存容量や検索速度の保証ではありません。
導入時に見るべきなのは、アプリケーションがどの形式でデータを出し、HyperDX側でどの属性が検索キーになるかです。サービス名、環境名、trace_idのような値が欠けると、相関表示の価値も下がります。まず一つのAPIと一つのエラーを対象にします。
OpenTelemetryとの接続点
READMEはOpenTelemetryを利用する入口を示しています。SDKやCollectorから送られるイベントを受ける構成なら、既存アプリケーションの計装を全て作り直さず、試験対象だけを選べます。ログ本文だけを集めるのではなく、属性とトレース識別子を揃えることが調査結果を左右します。
確認では、HTTPリクエストを一回発生させ、アプリのログ、親スパン、子スパンが同じ時刻と識別子で表示されるかを見ます。READMEにない既定のポート、認証、保持期間は環境ごとに確認し、公開ネットワークへ直接出す前にアクセス制御を設定します。
Dockerで作る最初の環境
HyperDXのREADMEはDockerを使った起動方法を案内しています。Composeファイル、環境変数、依存サービスの定義を読み、どのコンテナがデータを保存するかを先に確認します。単に画面が開くことだけでは、取り込み、検索、削除、再起動後の保持が動いた証拠になりません。
検証用のComposeプロジェクトを本番データから分け、短いログと既知のtrace_idを送ります。コンテナ再起動後に同じイベントが見えるか、時刻のタイムゾーンが一致するか、エラー画面から該当ログへ戻れるかを記録します。Dockerイメージのタグも固定し、更新時に差分を確認します。
検索画面を運用へ結び付ける
HyperDXの調査価値は、データが入ることより絞り込みが成立することにあります。サービス名、レベル、時間範囲、例外内容で検索し、同じ障害に関するログとトレースを辿れるかを試します。READMEが説明するUIの便利さをそのまま性能評価に置き換えず、チームが実際に使うクエリを登録します。
個人情報や認証トークンをログへ出している場合、収集前のマスキングを検討します。READMEだけでは、組織のデータ分類、監査ログ、SAML、バックアップ運用の詳細までは判断できません。必要な機能がHyperDXの版と構成で提供されるか、公式文書と実環境で確認します。
MITと採用範囲
リポジトリのライセンスはMITです。ソフトウェアを使用、変更、組み込み、配布する際の条件は比較的簡潔ですが、現状提供であり、品質や特定目的への適合性は保証されません。MITライセンスを根拠に、観測データの取り扱い、障害対応、第三者サービスの契約条件まで許可されたとは解釈できません。
採用判断は、Docker ComposeでHyperDXを起動し、OpenTelemetryのサンプルを送り、ログ検索からtrace_idのトレースへ移れることを確認してから行います。保持期間、ストレージ量、ユーザー権限、アップグレード時のマイグレーションを自組織の条件で測り、満たせない部分を運用手順に明記します。
HyperDX は観測データを集める経路と画面での調査を一緒に確認すると判断しやすくなります。まず README の Docker Compose またはローカル起動手順を使い、テスト用のサービスからログ、メトリクス、トレースを少量送ります。取り込み後に検索画面で trace_id や service 名を指定し、ログからトレースへ遷移できるか、タイムスタンプと属性が失われていないかを見ます。OpenTelemetry を使う構成では、collector の endpoint、認証ヘッダー、サンプリング設定を実環境と分離して記録します。アラートやダッシュボードの使い勝手を評価するときは、README にない性能保証を推測せず、同じ期間とイベント数で検索時間、保持期間、失敗時の再送を測ります。クラウド版とセルフホスト版でデータの保存場所やアクセス権が異なる可能性があるため、個人情報を含むログを最初の試験入力にしないことも採用条件です。
試験では意図的に一件のエラーを発生させ、HyperDX 上で同じ request や trace_id を追跡できるかを確認します。検索条件を保存する場合は、個人情報を含む属性を画面や共有ダッシュボードへ出さない設計にします。保持期間を超えたデータが本当に検索対象から外れるかは README の説明だけでは分からないため、検証環境で確認します。
編集部の結論
アプリケーションのログと分散トレースを一つの調査画面で結びたいチームに向きます。最初はREADMEのDocker Compose手順で隔離環境を起動し、OpenTelemetryのサンプルを送って検索結果とトレース相関を確認してください。READMEの対応範囲や運用規模の主張は、実際の保持期間、権限、保存先を設定してから評価します。
コミュニティノート