API リクエストが Edge UI でキャプチャされない

<ph type="x-smartling-placeholder"></ph> 現在、Apigee Edge のドキュメントが表示されています。
Apigee X のドキュメント。 詳細

症状

次の図は、トレース セッションの開始時に Edge UI で API リクエストがキャプチャされないことを示しています。

エラー メッセージ

この問題が発生しても、Edge UI にエラー メッセージは表示されません。

考えられる原因

次の表に、Edge UI トレースで API リクエストのキャプチャが失敗する場合に考えられる原因を示します。

原因: リクエストが Message Processor で処理されない

診断

Trace セッションで API リクエストをキャプチャするには、API リクエストを Edge コンポーネントの Message Processor で処理する必要があります。Trace トランザクションで API リクエストがキャプチャされない理由はいくつかあります。

たとえば、API リクエストが Apigee Edge に到達できない場合、Edge へのエントリ ポイント（つまり、Router など）か、そのスレッドが Message Processor で処理される前に障害が発生した場合、トレースをキャプチャできません。それぞれのシナリオについて、以下で詳しく説明します。

シナリオ 1: リクエストが Apigee Edge に到達しない

• 原因

  このシナリオでは、DNS の解決またはネットワーク接続の問題が原因で、エラーが発生している可能性があります。その場合、このコマンドを実行すると、次のエラーが表示されることがあります。

  curl https://hostName:port/apiProxyBasePath/requestPath
  

  curl: (6) Could not resolve host: hostName
  

• 解決策

  DNS 構成は、次のコマンドで確認できます。

  dig hostName

  次のコマンドでネットワーク接続を確認できます。

  telnet hostName port

シナリオ 2: Apigee Edge Router でリクエストが失敗する

• 原因

  このシナリオでは、TLS/SSL handshake の失敗がエラーの原因である可能性があります。その場合、次のいずれかのエラーが表示されることがあります。

  Received fatal alert: handshake_failure
  

  HTTP/1.1 400 Bad Request
  

  SSL 証明書エラーが表示されることもあります。

• 解決策

  これらの問題のトラブルシューティングと解決については、次のハンドブックをご覧ください。

  TLS/SSL handshake の失敗

  400 Bad Request - SSL Certificate Error

シナリオ 3: Message Processor でリクエストを処理できない

• 原因

  このシナリオでは、Apigee Message Processor が API プロキシを検出できません。 仮想パスで作成されます。その結果として、 次のエラーが表示されます。

  HTTP/1.1 404 Not Found
  

  {
    "fault":{
      "faultstring":"Unable to identify proxy for host: default and url: \/apiProxyBasePath/requestPath",
      "detail":{
        "errorcode":"messaging.adaptors.http.flow.ApplicationNotFound"
      }
    }
  }
  
  

• 解決策

  この問題をトラブルシューティングして解決するには、ハンドブック（404 Unable toidentify proxy for host）を参照してください。

原因: 分類ツリーに API プロキシが見つからない

診断

Message Processor の分類ツリーで API プロキシが見つからない場合、そのプロキシへの API リクエストは Edge UI のトレース セッションに表示されません。

これを確認するには、次の手順を行います。

1. 次のコマンドを使用して、各 Message Processor にログインし、リクエストされた API の特定のリビジョンが Message Processor の関連環境にデプロイされているかどうかを確認します。

   curl -v http://localhost:8082/v1/runtime/organizations/orgName/environments/envName/apis/apiName/revisions
   

   出力例:

   上記のコマンドは、デプロイされたリビジョンのリストを出力します。たとえば、リビジョン 12 がデプロイされている場合、次の出力が表示されます。

   [ "12" ]
   

   断続的な HTTP 404 エラーが発生しない限り、通常は特定のリビジョンがデプロイされています。

2. 次のコマンドを使用して、分類ツリーを読み、API プロキシ名が存在するかどうかを確認します。

   curl -i http://localhost:8082/v1/classification/tree | grep apiName
   

3. Message Processor ごとにステップ 1 と 2 を繰り返します。指定された API プロキシ名がいずれかの Message Processor の分類ツリーにない場合は、以下の解決策に従ってください。

解決策

この問題を解決するには、次の手順を行ってください。本番環境の停止を避けるために、必要な対策を講じてください。リクエストの負荷が高いときに Message Processor を再起動することで発生する可能性があります。

1. 分類ツリーに特定の API プロキシがない各 Message Processor ホストにログインし、以下のコマンドを使用して Message Processor を再起動します。

   /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
   

2. 再起動したら、以下のコマンドを使用して、アクティブになるまで待ちます。

   /opt/apigee/apigee-service/bin/apigee-service edge-message-processor wait_for_ready
   

3. Message Processor の準備ができたら、次のコマンドを使用して API プロキシの可用性を確認します。

   curl -v http://localhost:8082/v1/runtime/organizations/orgName/environments/envName/apis/apiName/revisions
   

   出力例:

   上記のコマンドは、デプロイされたリビジョンのリストを出力します。たとえば、リビジョン 12 がデプロイされている場合、次の出力が表示されます。

   [ "12" ]
   

   断続的な HTTP 404 エラーが発生しない限り、通常は特定のリビジョンがデプロイされています。

4. 分類ツリーを読み、次のコマンドを使用して API プロキシ名が存在することを確認します。

   curl -i http://localhost:8082/v1/classification/tree | grep apiName
   

   問題が解決しない場合は、診断情報の収集が必要な場合をご覧ください。

診断情報の収集が必要な場合

上記の手順でも問題が解決しない場合は、次の診断情報を収集して Apigee Edge サポートと共有してください。

curl -v management-server-host:8080/v1/runtime/organizations/orgName/environments/envName/apis/apiProxyName/revisions/revisionNumber/debugsessions -u user

/opt/apigee/var/log/edge-management-server/logs/system.log

/opt/apigee/var/log/edge-message-processor/logs/system.log

telnet MessageProcessor_IP 8082

nc -vz MessageProcessor_IP 8082

netstat -an > netstat.txt

curl -v http://localhost:8082/v1/runtime/organizations/orgName/environments/envName/apis/apiName/revisions

curl -i http://localhost:8082/v1/classification/tree