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

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

動画

動画 説明
500 Internal Server Error - バックエンドが原因 バックエンド サーバーによって発生したリアルタイムの 500 Internal Server Error と、エラーのトラブルシューティングと解決の手順を示します。

症状

クライアント アプリケーションが、メッセージを使用して HTTP ステータス コード 500 を取得します。 API 呼び出しのレスポンスとしての 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>
<ph type="x-smartling-placeholder">

考えられる原因

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

この問題の原因としては、次のことが考えられます。

原因 説明 トラブルシューティングの実施対象
バックエンド サーバーでのエラー バックエンド サーバーでなんらかの理由で障害が発生している可能性があります。 Edge Private Cloud と Public Cloud のユーザー

共通の診断手順

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

API Monitoring

手順 #1: API Monitoring を使用する

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

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

  1. <ph type="x-smartling-placeholder"></ph> Apigee Edge UI にログインするユーザーとして、 付与します。

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

  3. [Analyze] >API モニタリング >Investigate ページをご覧ください。
  4. エラーが発生した期間を選択します。

  5. 障害コードを Time に対してプロットします。

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

  6. 障害コードが含まれているセルを選択してください messaging.adaptors.http.flow.ErrorResponseCode: この図にあるとおり 下にあります。

    ( 拡大画像を表示）

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

    ( 拡大画像を表示）

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

    ( 拡大画像を表示）

  9. [ログ] ウィンドウで、次の詳細をメモします。 <ph type="x-smartling-placeholder">
      </ph>
    • リクエスト メッセージ ID
    • ステータス コード: 500
    • 障害の発生元: target
    • 障害コード: messaging.adaptors.http.flow.ErrorResponseCode

トレース

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

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

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

  1. トレース セッションを有効にし、以下のいずれかを行います。 <ph type="x-smartling-placeholder">
      </ph>
    • エラーコードを含む 500 Internal Server Error エラーを待つ messaging.adaptors.http.flow.ErrorResponseCode が発生する、または
    • 問題を再現できる場合は、API 呼び出しを行って問題を再現してください。 500 Internal Server Error

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

  3. 失敗したリクエストのいずれかを選択し、トレースを調べます。
  4. トレースのさまざまなフェーズを移動して、エラーが発生した場所を特定します。

  5. このエラーは通常、[Response received from target server] の後のフローで発生します。 示されます。

    ( 拡大画像を表示）

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

  7. [Phase Details Response Headers] セクションまで下にスクロールし、 X-Apigee-fault-codeX-Apigee-fault-code と X-Apigee-fault-sourceX-Apigee-fault-code の値 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 アクセスログを使用する

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

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

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

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

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

    <ph type="x-smartling-placeholder">
  3. エラーコードを含む 500 エラーがないか検索します 特定の期間にmessaging.adaptors.http.flow.ErrorResponseCode （ または、まだ 500 で失敗しているリクエストがあるかどうか。

  4. X-Apigee-fault-code が一致する 500 エラーがある場合 messaging.adaptors.http.flow.ErrorResponseCode の値、 X-Apigee-fault-source. の値を確認します。

    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. [Fault Source] が target で [Fault Code] の場合 messaging.adaptors.http.flow.ErrorResponseCode の場合、これは バックエンド サーバーからエラーが返されます。
  3. 問題の原因を診断するには、次のいずれかの手順を使用します。

    トレース

    Trace を使用する場合:

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

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

    2. [Response received from target server] フェーズを [ API リクエストが失敗していることがわかります。

      ( 拡大画像を表示）

    3. [Phase Details] セクションまで下にスクロールし、 レスポンス コンテンツ。バックエンド サーバーからのレスポンスが含まれます。

      レスポンスの内容の例:

      <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>

      上記のレスポンスには、バックエンド サーバーからのエラー メッセージが 承認されていません。これは、ユーザーが無効な操作を渡した可能性があることを示しています。 このエラーが表示されるのはそのためです。

    で確認できます。 <ph type="x-smartling-placeholder">

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

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

    バックエンド サーバーに対して直接呼び出しを行い、次のことが可能です。

    • 同じ 500 Internal Server Error が表示されるかどうかを検証する Apigee Edge を介してリクエストが行われたときに受信したレスポンス
    • バックエンド サーバーから受信したエラー メッセージ（レスポンス）を確認する

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

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

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

      <ph type="x-smartling-placeholder">
    4. バックエンド サービスが実際に 500 Internal Server Error を返しているかどうかを検証し、バックエンド サーバーから返されるエラー メッセージ（レスポンス）を確認する。 このエラーの原因を特定します

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

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

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

  4. 以下については、 <ph type="x-smartling-placeholder"></ph> 失敗した API プロキシの特定のターゲット エンドポイントでのプロキシ チェーン接続 つまり、ターゲット サーバー/ターゲット エンドポイントが Apigee Edgeこれを判断するには:

    1. 失敗したリクエストのトレースを取得したら、[Request sent] フェーズ> [Curl を表示] をクリックします。

    2. [Curl for Request Sent to Target Server] ウィンドウが開き、ここから次の処理を実行できます。 ターゲット サーバーのホスト エイリアスを判別できます。
    3. API プロキシのターゲット エンドポイントを確認し、バックエンド サーバーが URL またはターゲット サーバーのホスト名が、別のプロキシまたは独自のプロキシを指しています。 バックエンドサーバーと通信します
    4. ターゲット サーバーのホスト エイリアスが仮想ホストのエイリアスを指している場合、 プロキシ チェーンです。この場合は、キャンペーンに対して上記のすべての手順を繰り返す必要があります。 500 Internal Server Error の実際の原因を特定するまで、チェーンされたプロキシを使用します。この場合、500 Internal Server Error は次の可能性があります。 他のステージにある他のチェーン プロキシでも発生し、 このハンドブックまたはに記載されている手順に沿って解決した 500 内部サーバーエラーのハンドブックをご覧ください。
    5. ターゲット サーバーのホスト エイリアスがバックエンド サーバーを指している場合は、 解決策。

解決策

500 エラーがバックエンド サーバーから発生していることが確認できた場合は、次のようになります。 バックエンド サーバー チームと協力して問題を適切に修正してください。

上記の例では、ユーザーに有効な認証情報を渡すようリクエストする必要があります。 できます。

主な注意点

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

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

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

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

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

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

  • 失敗したリクエストについて観測された完全なエラー メッセージ
  • 監視対象の組織、環境名、API プロキシ名 500 件のエラー
  • 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 エラーが発生したときのタイムゾーン情報の期間。