503 Service Unavailable - バックエンド サーバーによる早期終了

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

症状

クライアント アプリケーションが、メッセージを含む HTTP レスポンス ステータス 503 を取得します。 API プロキシ呼び出しの後の Service Unavailable

エラー メッセージ

クライアント アプリケーションは次のレスポンス コードを受け取ります。

HTTP/1.1 503 Service Unavailable

また、次のエラー メッセージが表示される場合があります。

{
   "fault": {
      "faultstring": "The Service is temporarily unavailable",
      "detail": {
           "errorcode": "messaging.adaptors.http.flow.ServiceUnavailable"
       }
    }
}

考えられる原因

原因 説明 トラブルシューティングの実施対象
ターゲット サーバーが接続を早期に終了する Message Processor が動作している間に、ターゲット サーバーが接続を早期に終了する リクエストペイロードを送信します。 Edge Public Cloud ユーザーと Edge Private Cloud ユーザー

共通の診断手順

失敗したリクエストのメッセージ ID を特定する

Trace ツール

Trace ツールを使用して、失敗したリクエストのメッセージ ID を確認するには:

  1. 問題がまだ解決しない場合は、を有効にします トレース セッションを参照してください。
  2. API 呼び出しを行い、問題を再現する - 503 Service Unavailable (エラーコード messaging.adaptors.http.flow.ServiceUnavailable.
  3. 失敗したリクエストのいずれかを選択します。
  4. AX フェーズに進み、メッセージ ID を特定する (X-Apigee.Message-ID)をクリックします。 [Phase Details] セクション(次の図を参照)。

    [フェーズの詳細] セクションのメッセージ ID

NGINX アクセスログ

NGINX アクセスログを使用して、失敗したリクエストのメッセージ ID を確認するには:

また、NGINX Access ログを参照して、503 エラーのメッセージ ID を特定することもできます。 この方法は、問題が過去に発生した場合や、問題が断続的に発生する場合に特に便利です。 UI でトレースをキャプチャできません。次の手順で NGINX アクセスログからこの情報を特定します。

  1. NGINX アクセスログを確認します(/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log)。
  2. 特定の期間に特定の API プロキシで 503 エラーがあったかどうかを確認する (過去に発生した場合)、または 503 でまだ失敗しているリクエストがあるかどうか。
  3. X-Apigee-fault-code Messaging.adaptors.http.flow.ServiceUnavailable503 エラーが発生した場合、 次の例に示すように、1 つ以上のこのようなリクエストのメッセージ ID をメモします。

    503 エラーを示すエントリの例

    ステータス コード、メッセージ ID、障害ソース、障害コードを示すサンプル エントリ

原因: ターゲット サーバーが接続を早期に終了する

診断

  1. Public Cloud または Private Cloud ユーザーの場合: <ph type="x-smartling-placeholder">
      </ph>
    1. Trace ツールを使用する(一般的な診断手順を参照) また、[Analytics Data Recorded] ペインに次の両方が設定されていることを確認します。 <ph type="x-smartling-placeholder">
        </ph>
      • X-Apigee.fault-code: messaging.adaptors.http.flow.ServiceUnavailable
      • X-Apigee.fault-source: target

      alt_text

    2. Trace ツールを使用する(一般的な診断手順を参照) 直後の [Error] ペインで、次の両方が設定されていることを確認します。 TARGET_REQ_FLOW state プロパティ:
      • error.class: com.apigee.errors.http.server.ServiceUnavailableException
      • error.cause: Broken pipe

      alt_text

    3. さらに詳しく調べるには、tcpdump の使用をご覧ください。
  2. Private Cloud ユーザーの場合: <ph type="x-smartling-placeholder">
      </ph>
    • <ph type="x-smartling-placeholder"></ph> 失敗したリクエストのメッセージ ID を特定する
    • Message Processor ログでメッセージ ID を検索する (/opt/apigee/var/log/edge-message-processor/logs/system.log)。
    • 次のいずれかの例外が表示されます。

      例外 1: java.io.IOException: チャンネル ClientOutputChannel への書き込み中にパイプ破損が発生した

      2021-01-30 15:31:14,693 org:anotherorg env:prod api:myproxy
      rev:1 messageid:myorg-opdk-test-1-30312-13747-1  NIOThread@1
      INFO  HTTP.SERVICE - ExceptionHandler.handleException() :
      Exception java.io.IOException: Broken pipe occurred while writing to channel
      ClientOutputChannel(ClientChannel[Connected:
      Remote:IP:PORT Local:0.0.0.0:42828]@8380 useCount=1
      bytesRead=0 bytesWritten=76295 age=2012ms  lastIO=2ms  isOpen=false)
      

      または

      例外 2: onExceptionWrite 例外: {}
      java.io.IOException: パイプの破損

      2021-01-31 15:29:37,438 org:anotherorg env:prod api:503-test
      rev:1 messageid:leonyoung-opdk-test-1-18604-13978-1
      NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context$2.onException() :
      ClientChannel[Connected: Remote:IP:PORT
      Local:0.0.0.0:57880]@8569 useCount=1 bytesRead=0 bytesWritten=76295 age=3180ms  lastIO=2
      ms  isOpen=false.onExceptionWrite exception: {}
      java.io.IOException: Broken pipe
      
    • どちらの例外も、Message Processor がメッセージの書き込み中に リクエスト ペイロードがバックエンド サーバーに送信されると、サーバーによって接続が早期に閉じられました。 バックエンドサーバーと通信しますこのため、Message Processor から例外 java.io.IOException: Broken pipe がスローされます。
    • Remote:IP:PORT は、解決されたバックエンド サーバーを示します。 IP アドレスとポート番号。
    • 上記のエラー メッセージの属性 bytesWritten=76295 は、 Message Processor が 76295 バイトのペイロードをバックエンドに送信したことを サーバーに負荷がかかりました。
    • 属性 bytesRead=0 は、Message Processor がメッセージを バックエンド サーバーからデータ(レスポンス)を受信した場合。
    • この問題をさらに調査するには、バックエンドまたはバックエンドで tcpdump を収集します。 Message Processor を使用してデータをストリーミングし、以下で説明するように分析できます。

tcpdump の使用

  1. 次のコマンドを使用して、バックエンド サーバーまたは Message Processor で tcpdump をキャプチャします。 次のコマンドを実行します。

    バックエンド サーバーで tcpdump を収集するコマンド:

    tcpdump -i any -s 0 host MP_IP_ADDRESS -w FILE_NAME
    

    Message Processor で tcpdump を収集するコマンド:

    tcpdump -i any -s 0 host BACKEND_HOSTNAME -w FILE_NAME
    
  2. キャプチャした tcpdump を分析します。

    (Message Processor で収集された)tcpdump の出力例:

    alt_text

    上記の tcpdump で、次のようになります。

    1. パケット 4 で、Message Processor が POST リクエストを次のアドレスに送信しました。 バックエンドサーバーと通信します
    2. パケット 58 910 では、 11 の場合、Message Processor はリクエスト ペイロードを バックエンドサーバーと通信します
    3. パケット 67 で、バックエンド サーバーが応答しました。 Message Processor から受信したリクエスト ペイロードの一部に対する ACK
    4. ただし、パケット 12 では、ACK で応答する代わりに、 アプリケーション データパケットを受信し、その後、その応答で バックエンド サーバーは代わりに FIN ACK を返し、 閉じます。
    5. これは、バックエンド サーバーが接続を早期に閉じようとしていることを明確に示しています リクエスト ペイロードを送信していました。
    6. これにより、Message Processor が IOException: Broken Pipe クライアントに 503 を返す

解決策

  1. アプリケーション チームとネットワーキング チームのいずれかまたは両方と協力して、 バックエンド サーバー側で早期の接続解除に関する事象が発生しました。
  2. バックエンド サーバー アプリケーションがタイムアウトまたは接続をリセットしていないことを確認してください 渡す必要があります。
  3. Apigee とバックエンド サーバーの間に中間ネットワーキング デバイスやレイヤがある場合は、 リクエストのペイロード全体を受信する前にタイムアウトにならないようにします。

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

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

上記の手順でも問題が解決しない場合は、以下の情報を収集します。 Apigee Edge サポートにお問い合わせください。

Public Cloud ユーザーの場合は、次の情報を提供します。

  • 組織名
  • 環境名
  • API プロキシ名
  • 503 エラーを再現するために curl コマンドを完成させる
  • 503 Service Unavailable エラーのあるリクエストを含むトレース ファイル
  • 503 エラーが現在発生していない場合は、その期間に 過去に 503 エラーが発生した場合のタイムゾーン情報。

Private Cloud ユーザーの場合は、次の情報を提供します。

  • 失敗したリクエストについて観測された完全なエラー メッセージ
  • 組織、環境名、監視対象の API プロキシ名 503 件のエラー
  • API プロキシ バンドル
  • 503 Service Unavailable エラーのあるリクエストを含むトレース ファイル
  • 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
  • 503 エラーが発生したときのタイムゾーン情報の期間
  • Tcpdumps が、Message Processor とバックエンド サーバーで収集され、 エラーが発生しました