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

Apigee Edge のドキュメントを表示しています。
Apigee X のドキュメントに移動します。 情報

症状

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

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

エラー メッセージ

クライアント アプリケーションに次のようなエラーが表示されることがあります。

curl: (28) Operation timed out after 6001 milliseconds with 0 out of -1 bytes received

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

Edge プラットフォーム上の API リクエストの一般的なパスは、次の図に示すように、クライアント > Router > Message Processor > バックエンド サーバーです。

Apigee Edge プラットフォーム内の Router と Message Processor は、API リクエストの完了に時間がかかりすぎないように、適切なデフォルトのタイムアウト値で設定されます。

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

クライアント アプリケーションは、ニーズに基づいて適切なタイムアウト値を設定できます。

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

Router のタイムアウト

ルーターに構成されているデフォルトのタイムアウトは 57 秒です。これは、Edge で API リクエストが受信されてからレスポンスが返送されるまでの API プロキシの最大実行時間です。これには、バックエンド レスポンスと実行されるすべてのポリシーが含まれます。デフォルトのタイムアウトは、 Router の I/O タイムアウトを構成するで説明されているように、Router と仮想ホストでオーバーライドできます。

Message Processor のタイムアウト

Message Processor で構成されているデフォルトのタイムアウトは 55 秒です。これは、バックエンド サーバーがリクエストを処理して Message Processor に応答するまでに許容される最大時間です。デフォルトのタイムアウトは、 Message Processor の I/O タイムアウトを構成するで説明されているように、Message Processor または API プロキシ内でオーバーライドできます。

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

考えられる原因

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

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

共通の診断手順

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

  • API Monitoring
  • NGINX アクセスログ

API Monitoring

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

  1. [Analyze] > [API Monitoring] > [Investigate] ページに移動します。
  2. 4xx エラーでフィルタし、期間を選択します。
  3. ステータス コードと時間をプロットします。
  4. 次のように、499 エラーのあるセルを選択します。

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

  6. 右側のペインで、[ログを表示] をクリックします。

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

    • Request:呼び出しを行うために使用されるリクエスト メソッドと URI を提供します。
    • 応答 時間:リクエストの合計経過時間を示します。

    API Monitoring の GET logs 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. レスポンス時間で 499 エラーを確認し、すべての 499 エラーでレスポンス時間が一定（30 秒など）かどうかを確認します。

NGINX アクセスログ

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

  1. Private Cloud をご利用の場合は、NGINX アクセスログを使用して、HTTP 499 エラーに関する重要な情報を特定できます。
  2. NGINX アクセスログを確認します。
    /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log
  3. 特定の期間に 499 エラーが発生したかどうか（問題が過去に発生した場合）、または 499 で失敗しているリクエストがまだあるかどうかを検索します。
  4. 499 エラーの一部について、次の点に注意してください。
    • 合計レスポンス時間
    • リクエスト 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. すべての 499 エラーで合計レスポンス時間とユーザー エージェントが一致しているかどうかを確認します。

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

診断

  1. ブラウザまたはモバイル アプリケーションで実行されているシングルページ アプリから API が呼び出されると、エンドユーザーが突然ブラウザを閉じたり、同じタブで別のウェブページに移動したり、 [読み込みを停止] をクリックまたはタップしてページの読み込みを停止したりすると、ブラウザはリクエストを中止します。
  2. この場合、HTTP 499 ステータスのトランザクションでは、通常、リクエストごとにリクエスト処理時間（レスポンス時間）が異なります。
  3. この原因かどうかを判断するには、レスポンス時間を比較し、一般的な診断手順で説明されているように、API Monitoring または NGINX アクセスログを使用して、各 499 エラーでレスポンス時間が異なるかどうかを確認します。

解決策

  1. これは正常であり、HTTP 499 エラーの発生数が少ない場合は、通常は心配する必要はありません。

  2. 同じ URL パスで頻繁に発生する場合は、そのパスに関連付けられている特定のプロキシが非常に遅く、ユーザーが待機を望んでいない可能性があります。

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

    1. この場合は、共通の診断手順の手順に沿って、影響を受けるプロキシを特定します。
    2. レイテンシ分析ダッシュボードを使用して、プロキシ レイテンシの原因をさらに調査し、問題を解決します。
    3. 特定のプロキシでレイテンシが想定される場合は、このプロキシの応答に時間がかかることをユーザーに通知する必要があります。

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

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

  1. 通常、リクエストの完了には一定の時間がかかります（たとえば 10 秒）。ただし、クライアント アプリケーションには誤ったタイムアウト値（5 秒など）が設定されているため、API リクエストが完了する前にクライアント アプリケーションがタイムアウトし、499 が発生します。この場合、クライアント タイムアウトを適切な値に設定する必要があります。
  2. ターゲット サーバーまたはコールアウトに通常より時間がかかっています。この場合、適切なコンポーネントを修正し、タイムアウト値も適切に調整する必要があります。
  3. クライアントがレスポンスを必要としなくなったため、中止されました。これは、オートコンプリートやショート ポーリングなどの高頻度 API で発生する可能性があります。

診断

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

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

  1. 一般的な診断手順で説明されているように、API Monitoring ログまたは NGINX アクセスログで HTTP 499 トランザクションを確認します。
  2. すべての 499 エラーでレスポンス時間が一貫しているかどうかを確認します。
  3. その場合は、特定のクライアント アプリケーションが固定タイムアウトを構成している可能性があります。API プロキシまたはターゲット サーバーの応答が遅い場合、プロキシがタイムアウトする前にクライアントがタイムアウトするため、同じ URI パスに対して大量の HTTP 499s が発生します。この場合、NGINX アクセスログから User Agent を特定します。これにより、特定のクライアント アプリケーションを特定できます。
  4. Apigee の前に Akamai、F5、AWS ELB などのロードバランサが存在する可能性もあります。Apigee がカスタム ロードバランサの背後で実行されている場合は、ロードバランサのリクエスト タイムアウトが Apigee API タイムアウトよりも大きくなるように構成する必要があります。デフォルトでは、Apigee Router は 57 秒後にタイムアウトするため、ロードバランサでリクエスト タイムアウトを 60 秒に構成することをおすすめします。

トレース

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

問題が引き続き発生する場合（499 エラーが引き続き発生する場合）は、以下の手順を行います。

  1. Edge UI で、影響を受けた API のトレース セッションを有効にします。
  2. エラーが発生するのを待つか、API 呼び出しがある場合は、API 呼び出しを行い、エラーを再現します。
  3. 各フェーズの経過時間を確認し、ほとんどの時間が費やされているフェーズをメモします。
  4. 次のフェーズのいずれかの直後に最も長い経過時間を持つエラーが発生した場合は、バックエンド サーバーが遅いか、リクエストを処理するのに時間がかかることを示します。
    • ターゲット サーバーに送信されたリクエスト
    • ServiceCallout ポリシー

    次に、リクエストがターゲット サーバーに送信された後に Gateway Timeout が発生したことを示す UI トレースの例を示します。

解決策

  1. Apigee Edge を介した API リクエスト フローに関与するさまざまなコンポーネントに設定するタイムアウト値については、 I/O タイムアウトの構成に関するベスト プラクティスをご覧ください。
  2. ベスト プラクティスに従って、クライアント アプリケーションに適切なタイムアウト値を設定してください。

問題が解決しない場合は、診断情報の収集が必要な場合に進みます。

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

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

Public Cloud をご利用の場合は、次の情報を提供してください。

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

Private Cloud をご利用の場合は、次の情報を提供してください。

  • 失敗したリクエストで確認されたエラー メッセージの全文
  • 環境名
  • 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）