メインコンテンツへスキップ
メインコンテンツへスキップ

ClickStack - サンプルのログ、トレース、メトリクス

このガイドでは、サンプルデータセットを使用して、ClickStack Open Source と Managed ClickStack の両方を対象とした手順を説明します。

サービスを選択してください​

メインのClickHouse Cloudランディングページから、Managed ClickStackを使用するサービスを選択します。

サービスを選択

ClickStack UI（HyperDX）に移動する​

左側のメニューからClickStackを選択し、ClickStack UIに移動します。自動的に認証が行われます。

ClickStack UI

サンプルデータのダウンロード​

UIにサンプルデータを投入するには、次のファイルをダウンロードしてください:

サンプルデータ

# curl
curl -O https://storage.googleapis.com/hyperdx/sample.tar.gz
# or
# wget https://storage.googleapis.com/hyperdx/sample.tar.gz

このファイルには、当社の公開OpenTelemetry demoからのログ、メトリクス、トレースのサンプルが含まれています。これはマイクロサービスで構成されたシンプルなeコマースストアです。このファイルを任意のディレクトリにコピーしてください。

サンプルデータのロード​

このデータをロードするには、デプロイ済みのOpenTelemetry(OTel)コレクターのHTTPエンドポイントに送信するだけです。

次のコマンドを実行して、OTel collectorにデータを送信します。

for filename in $(tar -tf sample.tar.gz); do
  endpoint="http://localhost:4318/v1/${filename%.json}"
  echo "loading ${filename%.json}"
  tar -xOf sample.tar.gz "$filename" | while read -r line; do
    printf '%s\n' "$line" | curl -s -o /dev/null -X POST "$endpoint" \
    -H "Content-Type: application/json" \
    -H "authorization: ${CLICKSTACK_API_KEY}" \
    --data-binary @-
  done
done

これは、OTLP ログ、トレース、メトリクスのソースから OTel collector へデータを送信する動作をシミュレートします。本番環境では、これらのソースは言語クライアントまたは他の OTel collector である可能性があります。

Search ビューに戻ると、データの読み込みが開始されていることを確認できます(データが表示されない場合は、時間枠を Last 1 hour に調整してください):

HyperDX の検索

データの読み込みには数分かかります。次の手順に進む前に、読み込みが完了するまで待機してください。

セッションを確認する​

ユーザーが商品の支払い時に問題を経験しているという報告があるとします。HyperDXのセッションリプレイ機能を使用して、そのユーザー体験を確認できます。

左側のメニューから Client Sessions を選択します。

セッション

このビューを使用すると、eコマースストアのフロントエンドセッションを確認できます。セッションは、ユーザーがチェックアウトして購入を完了しようとするまで匿名として扱われます。

メールを含む一部のセッションには関連するエラーがあり、失敗したトランザクションの報告を裏付けている可能性があります。

失敗と関連するメールを含むトレースを選択します。次の画面では、ユーザーのセッションを再生して問題を確認できます。再生ボタンを押してセッションを視聴してください。

セッションリプレイ

リプレイには、ユーザーがサイトを閲覧し、カートに商品を追加する様子が表示されます。セッション後半の支払い完了を試みる箇所まで、自由にスキップしてください。

ヒント

エラーはタイムライン上に赤色で表示されます。

ユーザーは注文を完了できませんでしたが、明確なエラーは表示されませんでした。左パネルの下部までスクロールして、ユーザーのブラウザからのネットワークイベントとコンソールイベントを確認してください。/api/checkout の呼び出し時に500エラーが発生していることが確認できます。

セッション内のエラー

この500エラーを選択します。Overviewもカラム値も、エラーが予期しないものでありInternal Errorを引き起こしているという事実以外、問題の原因を示していません。

トレースを探索する​

Traceタブに移動して、完全な分散トレースを確認します。

セッショントレース

トレースを下にスクロールして、エラーの発生元である checkout サービススパンを確認します。次に、Payment サービススパンを選択してください。

スパン

Column Valuesタブを選択し、下にスクロールします。キャッシュが満杯になっていることが原因であることが確認できます。

カラム値

上にスクロールしてトレースに戻ると、先ほどの設定のおかげで、ログがスパンと相関付けられていることが確認できます。これにより、さらなるコンテキストが提供されます。

相関付けられたログ

決済サービス内のキャッシュが満杯になり、決済処理の完了を妨げていることが確認されました。

ログを確認する​

詳細については、Searchに戻ります:

ソースからLogsを選択し、paymentサービスにフィルターを適用します。

ログ

この問題は最近発生したものですが、影響を受けた決済の件数が多いことが確認できます。さらに、Visa決済に関連するキャッシュが問題の原因となっているようです。

チャートのメトリクス​

コードに明らかにエラーが混入していますが、メトリクスを使用してキャッシュサイズを確認できます。Chart Explorerビューに移動します。

データソースとしてMetricsを選択します。チャートビルダーでvisa_validation_cache.size (Gauge)のMaximumをプロットし、再生ボタンを押します。キャッシュは最大サイズに達するまで増加し続け、その後エラーが発生していることが確認できます。

メトリクス