クライアント、APIゲートウェイ・ログおよびバックエンドに表示されるopc-request-id値が期待どおりに一致しません

問題の症状

次の症状が1つ以上表示される場合があります。

• クライアントに返されたopc-request-idレスポンス・ヘッダーが、クライアントが送信した値と一致しません。

• バックエンド・サービスは、クライアントに返された値とは異なるopc-request-id値をログに記録します。

• クライアント提供のopc-request-idにスラッシュ(/)が含まれている場合、Application Performance Monitoring (APM)またはバックエンド・ログに予期しない衝突、欠落値または切捨てが表示されます。

• 単一ヘッダー値を使用して、クライアント・レスポンス、APIゲートウェイ・アクセス・ログ、APIゲートウェイ実行ログおよびバックエンド・ログ全体で同じリクエストを見つけることはできません。

考えられる理由

値は、次の理由で異なる場合があります。

• APIゲートウェイは、opc-request-idを不透明なパススルー値として扱いません。

• APIゲートウェイは、受信値をスラッシュ(/)文字で分割し、顧客IDおよびトレースID部分のみを使用します。

• APIゲートウェイは、リクエストごとに新しいスパンIDを生成します。

• クライアントに返されたレスポンス・ヘッダーには、生成されたスパンIDが含まれますが、バックエンド・サービスに送信されたヘッダーにはスパンIDが含まれません。

• スパンIDなどのクライアント提供の3番目のセグメントは、伝播では無視されます。

opc-request-id解析の理解

APIゲートウェイは、受信したopc-request-id値をスラッシュ(/)文字で最大3つの部分に分割します。解析された最初の2つのパーツを使用し、3番目のパーツを無視します。

APIゲートウェイは、解析されたパートを次のように解釈します。

• 第1部:顧客ID。

• 2番目の部分:トレースID。

• 3番目の部分:無視された値。

その後、APIゲートウェイによってリクエストのスパンIDが生成され、次の値が構築されます:

• クライアントに返されたレスポンス・ヘッダー: customerId/traceId/spanId。

• バックエンド・サービスに送信されるリクエスト・ヘッダー: customerId/traceId。

APIゲートウェイ・ログを検索する場合は、完全なレスポンス・ヘッダー値を使用します。バックエンド・ログを検索する場合は、2つの部分からなるダウンストリーム値を使用します。

共通入力パターンのレビュー

これらの例を使用して、APIゲートウェイが共通のopc-request-id値をどのように変更するかを理解します。

opc-request-id: abcdef

opc-request-id: /abcdef

opc-request-id: customer/trace

opc-request-id: customer/trace/span

opc-request-id: customer/trace/span/extra

要求ID値の比較

テスト・リクエストを送信し、次の場所にあるopc-request-id値を比較します。

• クライアントが送信するヘッダー値。

• APIゲートウェイがクライアントに返すレスポンス・ヘッダー値。

• バックエンド・サービスがAPIゲートウェイから受信するリクエスト・ヘッダー値。

たとえば、既知のopc-request-id値を含むリクエストを送信します。

curl -i https://<gateway-hostname>/<deployment-path-prefix>/<api-route-path> \
-H "opc-request-id: <your-request-id>"

少なくとも次の値をテストします。

• opc-request-idヘッダーがありません。

• opc-request-id: abcdef.

• opc-request-id: /abcdef.

• opc-request-id: customer/trace.

• opc-request-id: customer/trace/span.

ログ・エントリのレビュー

APIゲートウェイのアクセス・ログおよび実行ログを検索する場合は、クライアント・レスポンス・ヘッダーに返される完全なopc-request-id値を使用します。

次のログ・エントリを確認します。

• リクエストのAPIゲートウェイ・アクセス・ログ・エントリ。

• リクエストのAPIゲートウェイ実行ログ・エントリ。

• 転送されたリクエストのバックエンド・ログ・エントリ。

APIゲートウェイがクライアントに返すのと同じフル値をバックエンド・サービスがログに記録するとはかぎりません。バックエンド・サービスは、クライアントに表示可能な形式customerId/traceId/spanIdではなく、ダウンストリーム形式customerId/traceIdを受け取ります。

相関問題の修正

相関の問題を回避するには、次の演習を使用します。

• クライアント提供のopc-request-id値をスラッシュ(/)で開始しないでください。ただし、空の顧客IDと明示的なトレースIDが必要な場合を除きます。

• 保持されるクライアント提供の3番目のセグメントに依存しないでください。

• バックエンド・サービスまたはAPMツールで単一の不透明な相関文字列が想定される場合は、その相関値に別のアプリケーション・ヘッダーを使用します。

• APIゲートウェイのログ相関には、クライアントが表示可能な完全なレスポンス・ヘッダー値を使用します。

• バックエンド・ログをチェックする場合は、2つの部分からなるダウンストリーム値を使用します。

リクエストID相関の検証

リクエスト・フォーマットまたは相関戦略を更新した後、結果を確認します:

• 同じ要求を再度送信します。

• opc-request-idレスポンス・ヘッダーに必要な構造があることを確認します。

• アクセス・ログおよび実行ログに同じリクエストがあることを確認します。

• バックエンド・サービスが、予想される2つの部分からなるopc-request-id値を受け取ることを確認します。

• APMツールまたはバックエンド・ログ・パーサーで、レスポンス・ヘッダー値とダウンストリーム・リクエスト値が同一である必要がないことを確認します。

詳細情報

詳細は、次を参照してください:

• APIデプロイメントへのロギングの追加

• APIゲートウェイ・ロギングの詳細

• APIの呼出し時のその他のエラー