データの違いについてこのデータセットは毎日午前 0 時から再生されるため、デモを確認するタイミングによって表示される可視化は異なる場合があります。
デモシナリオ
OpenTelemetry デモ
デモアーキテクチャ
デモの手順
デモサーバーに接続する
ローカル専用モードLocal Mode でデプロイする際に
Connect to Demo Server をクリックしている場合は、この手順は省略できます。このモードを使用すると、ログソースには Demo_ のプレフィックスが付きます。例: Demo_LogsTeam Settings に移動し、Local Connection の Edit をクリックします。接続名を Demo に変更し、続いて表示されるフォームに、デモサーバーの以下の接続情報を入力します。Connection Name:DemoHost:https://sql-clickhouse.clickhouse.comUsername:otel_demoPassword: 空欄のままにする
ログソースを変更する
ローカル専用モードローカルモードでデプロイする際に
Connect to Demo Server をクリックした場合、この手順は省略できます。このモードを使用すると、ログソースには Demo_ というプレフィックスが付きます (例: Demo_Logs) 。Sources まで上にスクロールし、各ログソース (Logs、Traces、Metrics、Sessions) が otel_v2 データベースを使用するように変更します。各ログソースでデータベースの一覧全体が表示されるようにするには、ページの再読み込みが必要な場合があります。
時間範囲を調整する
右上の時間ピッカーを使って、直前の1 day のすべてのデータが表示されるように時間範囲を調整します。概要の棒グラフでは、エラー数にわずかな差が見られ、いくつかの連続した棒で赤色が少し増えている場合があります。棒の位置は、データセットをクエリするタイミングによって異なります。
エラーパターンを特定する
HyperDX のクラスタリング機能を使うと、エラーを自動的に特定し、それらを意味のあるパターンにグループ化できます。これにより、大量のログやトレースを扱う際の分析を効率化できます。使用するには、左側のパネルのAnalysis Mode メニューから Event Patterns を選択します。エラークラスターからは、Failed to place order という名前のパターンを含め、支払い失敗に関連する問題が明らかになります。さらに、別のクラスターからは、カード請求の問題や cache がいっぱいになっていることも示されています。これらのエラークラスターは、異なるサービスに由来している可能性が高いことに注意してください。エラーパターンを調査する
最も明らかなエラークラスターのうち、ユーザーが支払いを完了できるという報告済みの問題と相関しているFailed to place order をクリックします。すると、frontend サービスに関連付けられたこのエラーの発生一覧がすべて表示されます。表示されたエラーのいずれかを選択します。ログのメタデータが詳細に表示されます。概要 と Column Values の両方をスクロールしていくと、cache が原因でカード請求に問題が発生していることが示唆されます。failed to charge card: could not charge the card: rpc error: code = Unknown desc = Visa cache full: cannot add new item.インフラストラクチャを調査する
支払いの失敗を引き起こしている可能性が高い、cache 関連の error を特定しました。次は、この問題がマイクロサービス アーキテクチャのどこで発生しているのかを突き止める必要があります。cache の問題を踏まえると、基盤となるインフラストラクチャを調査するのが妥当です。関連するポッドでメモリの問題が発生している可能性もあります。ClickStack では、ログとメトリクスが統合され、コンテキストの中で表示されるため、根本原因をすばやく特定しやすくなります。Infrastructure タブを選択し、frontend サービスの基盤となるポッドに関連するメトリクスを表示して、時間範囲を 1d に広げます。この問題はインフラストラクチャに関連しているようには見えません。error の前後を通しても、どのメトリクスにも期間内で目立った変化はありません。Infrastructure タブを閉じてください。トレースを調べる
ClickStack では、トレースはログとメトリクスの両方に自動的に相関付けられます。原因となっているサービスを特定するため、選択したログにひも付いたトレースを確認してみましょう。関連するトレースを可視化するには、Trace を選択します。続いて表示されるビューを下にスクロールすると、各サービス内のスパンをつなぎながら、HyperDX がマイクロサービス全体にまたがる分散トレースをどのように可視化しているかがわかります。支払い処理には、チェックアウト処理や通貨換算など、複数のマイクロサービスが関与していることがはっきりと確認できます。ビューの一番下までスクロールすると、payment サービスがエラーの原因となっており、その影響が呼び出しチェーンをさかのぼって伝播していることがわかります。トレースを検索する
payment サービスのcache の問題により、ユーザーが購入を完了できていないことがわかりました。根本原因についてさらに詳しく確認するため、このサービスのトレースを詳しく見ていきましょう。Search を選択して、メインの Search view に切り替えます。Traces のデータソースに切り替え、Results table ビューを選択します。時間範囲が引き続き過去 1 日間になっていることを確認してください。このビューには、過去 1 日間のすべてのトレースが表示されます。問題の発生元は payment サービスであることがわかっているため、ServiceName に payment フィルターを適用します。Event Patterns を選択してトレースにイベントクラスタリングを適用すると、payment サービスの cache の問題をすぐに確認できます。トレースのインフラストラクチャを調査する
Results table をクリックして結果ビューに切り替えます。StatusCode フィルターと Error 値を使ってエラーに絞り込みます。Error: Visa cache full: cannot add new item. エラーを選択し、Infrastructure タブに切り替えて、時間範囲を 1d まで広げます。トレースとメトリクスを関連付けると、payment サービスではメモリと CPU が増加した後に 0 まで低下していることがわかります (これはポッドの再起動によるものと考えられます) 。このことから、cache の問題がリソース面の問題を引き起こしたことが示唆されます。支払い完了時間にも影響している可能性があります。イベントデルタで原因特定を迅速化
イベントデルタは、パフォーマンスやエラー率の変化を特定のデータのサブセットに結び付けることで異常を浮かび上がらせ、根本原因をすばやく特定しやすくします。payment サービスに cache の問題があり、その結果リソース消費が増加していることはわかっていますが、根本原因はまだ完全には特定できていません。結果テーブル表示に戻り、エラーを含む期間を選択してデータを絞り込みます。可能であれば、エラー発生前の数時間分と発生後の時間帯も含めて選択してください (問題がまだ継続している可能性があります) 。errors フィルタを削除し、左側の Analysis Mode メニューから Event Deltas を選択します。上部のパネルには所要時間の分布が表示され、色はイベント密度 (スパン数) を示しています。主な集中領域の外側にあるイベントのサブセットは、通常、調査する価値があります。1ms より大きい duration のイベントを選択し、Filter by selection フィルタを適用すると、「通常」のイベントと、所要時間が約 0ms の高密度グループのスパンとの差異を分析できます。データのサブセットに対して分析を行うと、選択範囲の外側にある「background」スパンの大半が visa トランザクションであり、cache エラーによって 0ms のレスポンスに関連していることがわかります。より多くのコンテキストを得るためのチャートの活用
ClickStack では、より多くのコンテキストを得るために、ログ、トレース、またはメトリクスの任意の数値をチャート化できます。ここまでで、次のことが分かりました。- 問題は payment サービスにある
- cache がいっぱいになっている
- これによりリソース消費が増加した
- この問題により Visa の支払いが完了しなくなった、あるいは少なくとも完了までに非常に長い時間がかかるようになった
左側のメニューから
Chart Explorer を選択します。支払いの完了にかかる時間をチャートタイプ別に表示するため、次の値を入力します。Data Source:TracesMetric:MaximumSQL Column:DurationWhere:ServiceName: paymentTimespan:Last 1 day
▶️ をクリックすると、時間の経過とともに支払いのパフォーマンスがどのように低下したかが表示されます。Group By を SpanAttributes['app.payment.card_type'] に設定すると (オートコンプリートを使うには card と入力するだけです) 、Mastercard と比較して Visa トランザクションでサービスのパフォーマンスがどのように低下したかを確認できます。なお、エラーが発生すると、レスポンスは 0s で返るようになります。より多くのコンテキストを得るためにメトリクスを詳しく調べる
最後に、cache size をメトリクスとしてプロットし、時間の経過とともにどのように推移したかを確認して、より多くのコンテキストを得ましょう。次の値を入力します。Data Source:MetricsMetric:MaximumSQL Column:visa_validation_cache.size (gauge)(オートコンプリートするにはcacheと入力するだけです)Where:ServiceName: paymentGroup By:<empty>
100,000 に達したことがわかります。Sample Matched Events からは、cache がこの上限に達したことと error が相関しており、その後は size が 0 と記録され、レスポンス時間も 0s になっていることが確認できます。要約すると、ログ、トレース、そして最後にメトリクスを調査した結果、次のことがわかりました。- 問題は payment service にあります
- おそらくデプロイメントに伴う service の動作変化により、4～5 時間かけて visa cache が徐々に増加し、最大サイズ
100,000に達しました - これにより、cache のサイズ増加に伴ってリソース消費も増大しました。おそらく実装上の問題が原因です
- cache が増大するにつれて、Visa payments のパフォーマンスは低下しました
- 最大サイズに達すると、cache は payments を拒否し、自身の size を
0と報告しました。
セッションの使用
セッションを使うとユーザー体験をリプレイでき、ユーザーの視点でエラーがどのように発生したかを視覚的に確認できます。通常、根本原因の特定にはあまり使われませんが、カスタマーサポートに報告された問題の確認には有効で、より詳しい調査の出発点としても役立ちます。HyperDX では、セッションはトレースやログに紐付けられており、原因を全体像として把握できます。たとえば、サポートチームから支払いの問題に遭遇したユーザーのメールアドレスRonny.Windler@gmail.com が共有された場合、ログやトレースを直接検索するよりも、そのユーザーのセッションから見始めるほうが効果的なことがよくあります。左側のメニューから Client Sessions タブに移動し、データソースが Sessions、時間範囲が Last 1 day に設定されていることを確認します。SpanAttributes.userEmail: Ronny.Windler を検索して、対象ユーザーのセッションを見つけます。セッションを選択すると、左側にそのユーザーのセッションにおけるブラウザーイベントと関連するスパンが表示され、右側にはユーザーのブラウザーでの操作が再生されます。セッションのリプレイ
▶️ ボタンを押すと、セッションをリプレイできます。Highlighted と All Events を切り替えることで、span の粒度を調整できます。前者では、主要なイベントとエラーが強調表示されます。span の一番下までスクロールすると、/api/checkout に関連付けられた 500 エラーを確認できます。この特定の span の ▶️ ボタンを選択すると、リプレイがセッション内のこの時点に移動するため、顧客が実際にどのように見えていたかを確認できます。支払いはエラーが表示されないまま、単に機能していないようです。span を選択すると、これが内部エラーによって発生したことを確認できます。Trace タブをクリックし、関連する span をスクロールしながらたどることで、この顧客が実際に cache の問題の影響を受けていたことを確認できます。