distributed-tracing

分散トレーシング

使用する場面

サービスをまたいでリクエストを追跡する場合、レイテンシやエラーの伝播を診断する場合、または新しい統合に可観測な境界を追加する場合に使用します。

入力と前提条件

インストールされている SDK とバックエンドのバージョン、許可されたコレクターのエンドポイント、サービスグラフ、およびステージングリクエストを記録します。エクスポーター API やデプロイ構成を選択する前に、インストールされているバージョンの主要なドキュメントを確認してください。このバンドルはトレーシングバックエンドをインストールしません。

手順

1. resources/implementation-playbook.md を読み、1 つのユーザージャーニーを特定します。
2. 計装されたフレームワークを読み込む前に、対応する OpenTelemetry SDK と OTLP エクスポーターを構成します。伝播、シャットダウン、プライバシーのチェックには references/instrumentation.md を使用します。
3. references/jaeger-setup.md を使用して Jaeger を構成するか、既存の Tempo/コレクターのデプロイでサポートされている構成を使用します。デプロイの前に、リスナー、認証、トランスポート保護、ストレージ、保持期間を確認してください。
4. HTTP と非同期メッセージを介してコンテキストを伝播します。安定した操作名と許可リストに登録された属性を使用します。認証情報、生のリクエストボディ、機密性の高いクエリ値をログに記録しないでください。
5. 成功するステージングリクエストと失敗するステージングリクエストを送信し、バックエンドで接続されたスパンを検証します。サービスの識別情報、親子関係、期間の単位、エクスポーターのエラーを記録します。
6. キューの損失とオーバーヘッドを測定します。これらの観測結果に基づいてサンプリングを選択します。固定のパーセンテージがカバレッジやパフォーマンスを保証するものではありません。

例

チェックアウトが在庫と支払いを呼び出します。ルートリクエストと両方のダウンストリーム操作が同じトレースを共有していること、シミュレートされた支払いタイムアウトが記録されていること、カードデータが存在しないことを検証します。エクスポーターの接続が利用できない状態で繰り返します。リクエスト処理はアプリケーションで定義された動作を維持する必要があります。

検証

• キューコンシューマーを含む、実行された各境界の実際のトレース証拠。
• 許可されたフィールドのみ。属性のカーディナリティが制限されていること。
• シャットダウン時のフラッシュとエクスポーター障害の動作が確認されていること。
• アクセス、ストレージ、保持期間が UI の可用性とは独立して確認されていること。

制限事項

ヘッドサンプリングは、テールサンプリングがエラーを確認する前にそれらを破棄する可能性があります。インメモリのデモは永続的なストレージを証明しません。コンテキストの伝播とサービス間のクロックには実際の統合テストが必要です。このガイドは実行可能なマルチサービスアプリケーションではありません。

出典

• OpenTelemetry エクスポータードキュメント — インストールされている SDK に対応するドキュメントを使用してください。