500 Internal Server Error - バックエンド サーバー

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

動画

動画 説明
500 内部サーバーエラー - 原因: バックエンド バックエンド サーバーに起因するリアルタイムの 500 Internal Server Error と、エラーのトラブルシューティングと解決手順を示します。

内容

クライアント アプリケーションが、API 呼び出しのレスポンスとして、HTTP ステータス コード 500 とメッセージ Internal Server Error を受け取ります。

HTTP ステータス コード 500 は、一般的なエラー レスポンスです。これは、サーバーで予期しない状況が発生し、リクエストの処理が妨げられたことを意味します。このエラーは通常、他に適切なエラーコードがない場合にサーバーによって返されます。

エラー メッセージ

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

HTTP/1.1 500 Internal Server Error

また、以下のようなエラー メッセージが表示される場合もあります。

サンプル 1

バックエンド サーバーのレスポンス #1 の例

{"errorMessage":"Sorry either your e-mail or password didn't match.",
"errorParameters":"{}",
"errorCode":"500",
"errorKey":"INVALID_EMAILPASSWORD"}

サンプル 2

バックエンド サーバーのレスポンス #2 の例

<Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
   <Body>
      <Error>
         <code>500</code>
         <message xml:lang="en-US">Not Authorised(e4138fa0-ec57).</message>
      </Error>
   </Body>
</Envelope>

考えられる原因

さまざまな原因により、バックエンド サーバーから 500 Internal Server Error が返される場合があります。このハンドブックでは、一般的な手順でトラブルシューティングを行い、原因に関係なくこのエラーを解決する方法について説明します。

この問題の考えられる原因は次のとおりです。

原因 説明 トラブルシューティングの実施対象
バックエンド サーバーのエラー バックエンド サーバーで障害が発生することがあります。 Edge Private Cloud ユーザーと Public Cloud ユーザー

共通の診断手順

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

API Monitoring

手順 1: API Monitoring の使用

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

  1. 適切なロールを持つユーザーとして Apigee Edge UI にログインします。

  2. 問題を調査する組織に切り替えます。

  3. [Analyze] > [API Monitoring] > [Investigate] ページに移動します。
  4. エラーが発生した期間を選択します。

  5. [Time] に [Fault Code] をプロットします。

  6. 次のように、障害コード messaging.adaptors.http.flow.ErrorResponseCode を含むセルを選択します。

    （ 拡大画像を表示）

  7. 障害コード messaging.adaptors.http.flow.ErrorResponseCode に関する情報が次のように表示されます。

    （ 拡大画像を表示）

  8. [ログを表示 ] をクリックし、失敗したリクエストの行を開きます。

    （ 拡大画像を表示）

  9. [ログ] ウィンドウで、次の詳細をメモします。
    • リクエスト メッセージ ID
    • ステータス コード: 500
    • 障害ソース: target
    • 障害コード: messaging.adaptors.http.flow.ErrorResponseCode

Trace

手順 2: Trace ツールを使用する

Trace ツールを使用してエラーを診断するには:

  1. トレース セッションを有効にして、次のいずれかを行います。
    • 500 Internal Server Error エラー（エラーコード: messaging.adaptors.http.flow.ErrorResponseCode）が発生するまで待ちます。
    • 問題を再現できる場合は、API を呼び出して問題を再現します 500 Internal Server Error

  2. [Show all FlowInfos] が有効になっていることを確認します。

  3. 失敗したリクエストの 1 つを選択し、トレースを調べます。
  4. トレースのさまざまなフェーズを順に確認し、エラーが発生した場所を見つけます。

  5. エラーは通常、以下に示すように「Response received from target server」フェーズの後のフローで確認できます。

    （ 拡大画像を表示）

  6. トレースの [AX（Analytics Data Recorded）] フェーズに移動してクリックします。

  7. [Phase Details Response Headers] セクションまで下にスクロールし、次のように X-Apigee-fault-code、X-Apigee-fault-source、X-Apigee-Message-ID の値を確認します。

    （ 拡大画像を表示）

  8. X-Apigee-fault-code、X-Apigee-fault-source、X-Apigee-Message-ID の値をメモします。
    9. レスポンス ヘッダー 値
    X-Apigee-fault-code messaging.adaptors.http.flow.ErrorResponseCode
    X-Apigee-fault-source target
    X-Apigee-Message-ID MESSAGE_ID

NGINX

手順 #3: NGINX アクセスログの使用

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

  1. Private Cloud ユーザーの場合、NGINX アクセスログを使用して HTTP 500 Internal Server Error に関する重要な情報を特定できます。

  2. NGINX のアクセスログを確認します。

    /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log

  3. 特定の期間にエラーコード messaging.adaptors.http.flow.ErrorResponseCode の 500 エラーがあったかどうか（問題が過去に発生していた場合）、または 500 で失敗するリクエストがあるかどうかを検索します。

  4. X-Apigee-fault-code が X-Apigee-fault-code の値と一致する 500 エラーが見つかった場合は、X-Apigee-fault-code の値を特定します。

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

    （ 拡大画像を表示）

    上記の NGINX アクセスログのエントリ例では、X-Apigee-fault-code と X-Apigee-fault-code に次の値が入っています。

    ヘッダー 値
    X-Apigee-fault-code messaging.adaptors.http.flow.ErrorResponseCode
    X-Apigee-fault-source target

原因: バックエンド サーバーでエラーが発生しました

診断

バックエンド サーバーから応答される 500 Internal Server Error は、さまざまな理由で発生する可能性があります。それぞれの状況を個別に診断する必要があります。

  1. 一般的な診断手順で説明されているように、API Monitoring、Trace ツール、または NGINX アクセスログを使用して確認されたエラーの障害コード、障害ソースを特定します。
  2. 障害ソースが target で障害コードが messaging.adaptors.http.flow.ErrorResponseCode の場合は、バックエンド サーバーからエラーが返されたことを示します。
  3. 次のいずれかの方法で問題の原因を診断します。

    Trace

    Trace の使用:

    障害の Trace セッションがある場合は、次の操作を行います。

    1. [トレース] で、500 Internal Server Error で失敗した API リクエストを選択します。

    2. 次の図に示すように、失敗した API リクエストから [Response received from target server] フェーズを選択します。

      （ 拡大画像を表示）

    3. [Phase Details] セクションまで下にスクロールし、バックエンド サーバーからのレスポンスを含む [Response Content] を確認します。

      回答例:

      <Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
   <Body>
      <Error>
         <code>500</code>
         <message xml:lang="en-US">Not Authorised(e4138fa0-ec57).</message>
      </Error>
   </Body>
</Envelope>

      上記のレスポンスで、バックエンド サーバーからのエラー メッセージが「Not Authorizeified」であることに注意してください。これは、ユーザーが無効な認証情報を渡した可能性があるため、このエラーが表示されていることを示します。

    バックエンド サーバーを呼び出す

    バックエンド サーバーを直接呼び出します。

    バックエンド サーバーを直接呼び出し、次のことができます。

    • Apigee Edge からリクエストが送信されたときに受信したのと同じ 500 Internal Server Error レスポンスを受け取っているかどうかを検証します。
    • バックエンド サーバーから受信したエラー メッセージ（レスポンス）を確認する

    次の手順でバックエンド サーバーを直接呼び出します。

    1. リクエストの一部としてバックエンド サーバーに渡すために必要なすべてのヘッダー、クエリ パラメータ、認証情報があることを確認します。
    2. バックエンド サービスが一般公開されている場合は、curl コマンド、Postman、その他の REST クライアントを使用して、バックエンド サーバー API を直接呼び出すことができます。

    3. バックエンド サーバーに Message Processor からのみアクセスできる場合は、curl コマンド、Postman、その他の REST クライアントを使用して、Message Processor から直接バックエンド サーバー API を呼び出すことができます。

    4. バックエンド サービスが実際に 500 Internal Server Error を返しているかどうかを確認し、バックエンド サーバーから返されたエラー メッセージ（レスポンス）を確認して、エラーの原因を特定します。

    バックエンド サーバーのログ

    バックエンド サーバーログの使用

    1. バックエンド サーバーのログを確認し、エラーとその原因に関する詳細情報を取得します。
    2. 可能であれば、バックエンド サーバーでデバッグモードを有効にして、エラーと原因に関する詳細情報を取得します。

  4. 失敗した API プロキシの特定のターゲット エンドポイントで プロキシ チェーンを使用しているかどうか、つまり、ターゲット サーバー/ターゲット エンドポイントが Apigee Edge で別のプロキシを呼び出していないかどうかを確認します。これを確認するには:

    1. 失敗したリクエストのトレースを取得している場合は、[Request sent to target server] フェーズに移動して [Show Curl] をクリックします。

    2. [Curl for Request Sent to Target Server] ウィンドウが開き、ターゲット サーバーのホスト エイリアスを確認できます。
    3. API プロキシのターゲット エンドポイントを確認して、ターゲット サーバーのバックエンド サーバーの URL またはホスト名が別のプロキシまたは独自のバックエンド サーバーを指していないか確認します。
    4. ターゲット サーバーのホスト エイリアスが仮想ホスト エイリアスを参照している場合、これはプロキシ チェーンです。この場合、実際に 500 Internal Server Error の原因を特定するまで、チェーンされたプロキシに対して上記の手順をすべて繰り返す必要があります。このような場合、このハンドブックまたは 500 Internal Server Error ハンドブックに記載されている手順に沿って、他の段階のチェーンされたプロキシで 500 Internal Server Error が発生する可能性もあります。
    5. ターゲット サーバーのホスト エイリアスがバックエンド サーバーを参照している場合は、解決策に進みます。

解像度

500 エラーがバックエンド サーバーから発生していることがわかっている場合は、バックエンド サーバーチームと協力して問題を適切に修正してください。

上記の例では、この問題を解決するために有効な認証情報を渡すようユーザーにリクエストしなければならない場合があります。

重要なポイント

  1. 500 Internal Server Error に対してバックエンド サーバーから返された実際のエラー メッセージは、失敗したリクエストのトレース セッションをキャプチャした場合にのみ表示されます。
  2. バックエンド サーバーのレスポンスは、セキュリティ上の理由から、API Monitoring、NGINX アクセスログ、Message Processor ログに記録されません。
  3. バックエンド サーバーログを確認するか、バックエンドでデバッグモードを有効にして、500 Internal Server Error の詳細を取得したり、バックエンド サーバーから返されたエラー メッセージを確認したりできます。

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

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

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

  • 組織の名前
  • 環境名
  • API プロキシ名
  • curl コマンドを完了して 500 エラーを再現する
  • 500 Internal Server Error を含むリクエストを含むトレース ファイル
  • 500 エラーが現在発生していない場合は、過去に 500 エラーが発生していたときの時間帯とタイムゾーンをお知らせください。

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

  • 失敗したリクエストについて確認された完全なエラー メッセージ
  • 500 エラーが発生している組織、環境名、API プロキシ名
  • API プロキシ バンドル
  • 500 Internal Server Error を含むリクエストを含むトレース ファイル
  • NGINX アクセスログ /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log

    ここで、ORG、ENV、PORT# は実際の値に置き換えられます。

  • Message Processor のシステムログ /opt/apigee/var/log/edge-message-processor/logs/system.log
  • 500 エラーが発生したときのタイムゾーン情報の期間。