499 クライアントが閉じている接続

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

症状

クライアント アプリケーションが API リクエストのタイムアウト エラーを受け取るか、リクエストが終了する API リクエストが Apigee で実行中の間に突然突然表示されることがあります。

API Monitoring で、このような API リクエストのステータス コード 499 を確認できます。 NGINX アクセスログ。API Analytics で異なるステータス コードが表示されることがあります。これは、この Message Processor から返されたステータス コードを示します。

エラー メッセージ

クライアント アプリケーションでは、次のようなエラーが発生することがあります。 

curl: (28) Operation timed out after 6001 milliseconds with 0 out of -1 bytes received
<ph type="x-smartling-placeholder">

クライアント タイムアウトの原因

Edge プラットフォームでの API リクエストの一般的なパスは次のとおりです。 クライアント >ルーター >Message Processor >バックエンド サーバーを起動します。

Apigee Edge プラットフォーム内の Router と Message Processor は、適切なリソースを使用して API リクエストの完了に時間がかかりすぎないように、デフォルトのタイムアウト値を設定しておく必要があります。

クライアントのタイムアウト

クライアント アプリケーションには、必要に応じて適切なタイムアウト値を構成できます。

ウェブブラウザやモバイルアプリなどのクライアントには、オペレーティング システムによって定義されたタイムアウトがあります。

Router のタイムアウト

Router に構成されるデフォルトのタイムアウトは 57 秒です。この期間は API リクエストが Edge で受信されてからレスポンスが受信されるまで、API プロキシを実行できる バックエンド レスポンスと実行されたすべてのポリシーを含むメッセージを返します。デフォルト ファイアウォール ルールでオーバーライドできます。詳細については、 <ph type="x-smartling-placeholder"></ph> ルーターの I/O タイムアウトの構成をご覧ください。

Message Processor のタイムアウト

Message Processor で構成されるデフォルトのタイムアウトは 55 秒です。これは上限額です バックエンド サーバーがリクエストを処理し、Message への応答に要した時間。 データ処理者。デフォルトのタイムアウトは Message Processor または API 内でオーバーライドできます。 プロキシ（ <ph type="x-smartling-placeholder"></ph> Message Processor での I/O タイムアウトの構成をご覧ください。

API プロキシがタイムアウトする前にクライアントが Router との接続を終了した場合、 特定の API リクエストのタイムアウト エラーを確認できます。このようなリクエストのステータス コード 499 Client Closed Connection が Router に記録されます。このログは API で確認できます。 Monitoring と NGINX Access のログ。

考えられる原因

Edge では、499 Client Closed Connection エラーの一般的な原因は次のとおりです。

原因 説明 トラブルシューティングの実施対象
クライアントが接続を突然閉じた これは、エンドユーザーが接続をキャンセルしたためにクライアントが接続を閉じた場合に発生します。 完了するまで待つ必要はありません。 Public Cloud ユーザーと Private Cloud ユーザー
クライアント アプリケーションのタイムアウト これは、API プロキシが処理時間を確保する前にクライアント アプリケーションがタイムアウトした場合に発生します。 レスポンスを送信します。通常これは、クライアントのタイムアウトが短い場合に発生します。 タイムアウトまでの時間が長くなります。 Public Cloud ユーザーと Private Cloud ユーザー

共通の診断手順

このエラーを診断するには、次のいずれかのツールまたは手法を使用します。

  • API モニタリング
  • NGINX アクセスログ

API Monitoring

<ph type="x-smartling-placeholder">

API Monitoring を使用してエラーを診断するには:

  1. [Analyze] >API モニタリング >Investigate ページをご覧ください。
  2. 4xx エラーでフィルタし、期間を選択します。
  3. Status Code と Time をプロットします。
  4. 次のように、499 個のエラーがあるセルを選択してください。

  5. 右側のペインに 499 エラーに関する情報が表示されます。 下に示します。

  6. 右側のペインで、[View logs] をクリックします。

    [トラフィック ログ] ウィンドウで、一部の 499 について次の詳細をメモします。 エラー:

    • リクエスト:呼び出しに使用されるリクエスト メソッドと URI が提供されます。
    • レスポンス 時間:リクエストの合計経過時間を示します。
    で確認できます。 <ph type="x-smartling-placeholder">

    API Monitoring を使用してすべてのログを取得することもできます。 GET ログ API。対象 たとえば、org、env、 timeRange、status の場合は、 クライアントがタイムアウトしたトランザクションのログです。

    API Monitoring は HTTP 499 のプロキシを - に設定するため API を使用して （Logs API）を使用して、ログの取得方法を取得します。 プロキシとして作成されます。

    次に例を示します。 

    curl "https://apimonitoring.enterprise.apigee.com/logs/apiproxies?org=ORG&env=ENV&select=https://VIRTUAL_HOST/BASEBATH" -H "Authorization: Bearer $TOKEN"
  7. [Response Time]（応答時間）で他の 499 エラーを確認し、 応答時間がすべての応答時間で一貫している（たとえば 30 秒） 499 件のエラーがあります。

NGINX アクセスログ

<ph type="x-smartling-placeholder">

NGINX アクセスログを使用してエラーを診断するには:

  1. プライベート クラウド ユーザーの場合、NGINX アクセスログを使用して HTTP 499 エラーに関する重要な情報。
  2. NGINX アクセスログを確認します。
    /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log
  3. 特定の期間に 499 エラーがないか検索する （過去に発生した場合）か、引き続き失敗するリクエストがあるかどうかを 499。
  4. 499 エラーの一部については、次の点に注意してください。 <ph type="x-smartling-placeholder">
      </ph>
    • Total Response Time（合計応答時間）
    • リクエスト URI
    • ユーザー エージェント

    NGINX アクセスログの 499 エラーの例:

    2019-08-23T06:50:07+00:00       rrt-03f69eb1091c4a886-c-sy      50.112.119.65:47756
10.10.53.154:8443       10.001  -       -       499     -       422     0
   GET /v1/products HTTP/1.1        -       okhttp/3.9.1    api.acme.org
rrt-03f69eb1091c4a886-c-sy-13001-6496714-1
    50.112.119.65   -       -       -       -       -       -       -       -1      -       -       dc-1  router-pod-1
rt-214-190301-0020137-latest-7d
36       TLSv1.2 gateway-1     dc-1  acme    prod  https   -

    この例では、次の情報が表示されます。

    • 合計応答時間: 10.001 秒。これは、この値が クライアントが 10.001 秒後にタイムアウトした
    • リクエスト: GET /v1/products
    • ホスト:api.acme.org
    • ユーザー エージェント:okhttp/3.9.1
  5. [Total Response Time]（合計応答時間）と [User Agent]（ユーザー エージェント）が一致しているかどうかを確認する （全 499 件のエラーで）

原因: クライアントが接続を突然閉じた

診断

  1. ブラウザまたはモバイルアプリで実行されているシングルページ アプリから API を呼び出すと、 エンドユーザーがブラウザを閉じ、 クリックまたはタップしてページが読み込まれないようにしたり、 は読み込みを停止します。
  2. この場合、通常、HTTP 499 ステータスのトランザクションに変動が生じます リクエストごとのリクエスト処理時間（応答時間）で表します。
  3. [Response Time]（応答時間）を比較し、 API Monitoring または NGINX Access を使用する 499 エラーごとに異なります。 一般的な診断手順で説明されているとおりにログに記録されます。

解決策

  1. これは正常な動作であり、通常、HTTP 499 エラーが問題になることはありません。 少量のデータだからです

  2. 同じ URL パスで頻繁に発生する場合は、特定のプロキシ 非常に時間がかかり、ユーザーは待機するつもりはありません。

    どのプロキシが影響を受ける可能性があるかを特定したら、 遅延 分析ダッシュボードを使用して、プロキシ レイテンシの原因をさらに調査できます。

    1. この場合は、次の手順を使用して、影響を受けるプロキシを特定します。 一般的な診断手順。
    2. <ph type="x-smartling-placeholder"></ph> Latency Analysis ダッシュボード: プロキシ レイテンシの原因をさらに調査し、 問題を解決します。
    3. 特定のプロキシで想定されるレイテンシが判明した場合は、 このプロキシの応答に時間がかかることをユーザーに通知します。

原因: クライアント アプリケーションのタイムアウト

これは、さまざまなシナリオで発生する可能性があります。

  1. リクエストが完了するまでに一定時間（たとえば 10 秒）かかることが予想されます。 通常の動作条件下で使用してください。ただし、クライアント アプリケーションの クライアント アプリケーションがタイムアウト値（たとえば 5 秒）を API リクエストが完了し、499 につながります。この場合は、ファイアウォール ルールで タイムアウトを適切な値に変更できます。
  2. ターゲット サーバーまたはコールアウトに通常より時間がかかっています。この場合は タイムアウト値を適切に調整する必要があります。
  3. クライアントはレスポンスが不要となったため、中止しました。これは、 予測入力やショート ポーリングなどの頻度 API を使用します。

診断

API Monitoring または NGINX アクセスログ

API Monitoring または NGINX アクセスログを使用してエラーを診断します。

  1. API Monitoring ログまたは NGINX アクセスログで、HTTP 499 トランザクションを確認します。 一般的な診断手順
  2. すべての 499 エラーの [Response Time] が一貫しているかどうかを確認します。
  3. 「はい」の場合、特定のクライアント アプリケーションが固定タイムアウトを構成している可能性があります あります。API プロキシまたはターゲット サーバーのレスポンスが遅い場合、クライアントがタイムアウトする プロキシがタイムアウトします。その結果、HTTP 499s が 同じ URI パスですこの場合、NGINX アクセスログから、どのユーザー エージェントが 特定のクライアント アプリケーションを判断するのに役立ちます。
  4. また、Apigee の前に Akamai、 F5、AWS ELB などApigee がカスタム ロードバランサの背後で実行されている場合、 Apigee API タイムアウトよりも長くなるように構成する必要があります。方法 デフォルトでは、Apigee Router は 57 秒後にタイムアウトするため、リクエストを構成するのに適しています。 タイムアウトを 60 秒に設定しています。

トレース

Trace を使用してエラーを診断する

問題がまだアクティブな場合（499 個のエラーが引き続き発生する）は、次の手順を行います。 手順は次のとおりです。

  1. [ トレース セッション を参照してください。
  2. エラーが発生するのを待つか、API 呼び出しがある場合は、いくつかの API 呼び出しを行います。 エラーを再現します。
  3. 各フェーズの経過時間を確認し、時間が最も多いフェーズをメモします。 できます。
  4. いずれかのイベントが検出された直後に、経過時間が最も長いエラーが バックエンド サーバーが遅いか、時間がかかっていることを示します を使用してリクエストを処理します。 <ph type="x-smartling-placeholder">
      </ph>
    • ターゲット サーバーにリクエストを送信しました
    • ServiceCallout ポリシー

    以下は、リクエストの発生後のゲートウェイ タイムアウトを示すサンプル UI トレースです。 ターゲット サーバーに送信されます。

解決策

  1. <ph type="x-smartling-placeholder"></ph>をご覧ください I/O タイムアウトを構成するためのベスト プラクティスをご覧ください。 Apigee Edge を介した API リクエスト フローに関連するさまざまなコンポーネントで行われます。
  2. クライアント アプリケーションで適切なタイムアウト値を ベストプラクティスを確認します

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

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

問題が解決しない場合は、次の診断情報を収集して Apigee Edge サポートに連絡してください。

Public Cloud ユーザーの場合は、次の情報を提供してください。

  • 組織名
  • 環境名
  • API プロキシ名
  • タイムアウト エラーを再現するための完全な curl コマンド
  • クライアント タイムアウト エラーが発生している API リクエストのトレース ファイル

プライベート クラウド ユーザーの場合は、次の情報を提供してください。

  • 失敗したリクエストについて観測された完全なエラー メッセージ
  • 環境名
  • API プロキシ バンドル
  • クライアント タイムアウト エラーが発生している API リクエストのトレース ファイル
  • NGINX アクセスログ（/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log）
  • Message Processor システムログ（/opt/apigee/var/log/edge-message-processor/logs/system.log）