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

現在、Apigee Edge のドキュメントを表示しています。
Apigee X のドキュメントをご確認ください。 情報

内容

クライアント アプリケーションが API リクエストのタイムアウト エラーを受け取ったか、Apigee で API リクエストの実行中にリクエストが突然終了した。

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

エラー メッセージ

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

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

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

次の図に示すように、Edge プラットフォームでの API リクエストの一般的なパスは、[Client] > [Router] > [Message Processor] > [Backend Server] です。

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. [Time] に [Status Code] をプロットします。
  4. 499 エラーを含むセルを以下から選択します。

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

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

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

    • リクエスト:呼び出しに使用されるリクエスト メソッドと URI を提供します。
    • レスポンス Time:リクエストの合計経過時間。

    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. [Response Time] でその他の 499 エラーを確認し、すべての 499 エラーで [Response Time] に一貫している時間（たとえば 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 エラーについて、次の点に注意してください。
    • 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. 合計応答時間とユーザー エージェントが、すべての 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 のアクセスログからユーザー エージェントを特定します。これは、特定のクライアント アプリケーションを特定する際に役立ちます。
  4. また、Apigee の前に Akamai、F5、AWS ELB などのロードバランサが存在する場合もあります。Apigee がカスタム ロードバランサの背後で実行されている場合は、ロードバランサのリクエスト タイムアウトを Apigee API タイムアウトよりも長く構成する必要があります。デフォルトでは、Apigee Router は 57 秒後にタイムアウトするため、ロードバランサでは 60 秒のリクエスト タイムアウトを構成するのが適切です。

Trace

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

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

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

    次に示すのは、リクエストがターゲット サーバーに送信された後のゲートウェイ タイムアウトを示す 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）