500 Internal Server Error - ストリーミングが有効

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

症状

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

エラー メッセージ

クライアント アプリケーションが、次のようなエラー レスポンスを受け取ることがあります。 

HTTP/1.1 500 Internal Server Error

その後に、次のようなエラー メッセージが表示されることがあります。 

{
   "fault":{
      "faultstring":"Expecting } at line 1"
      "detail":{
         "errorcode":"Internal Server Error"
      }
   }
}

OR

{
   "fault":{
      "faultstring":"Expecting ] at line 1"
      "detail":{
         "errorcode":"Internal Server Error"
      }
   }
}

考えられる原因

500 Internal Server Error（内部サーバーエラー）は、さまざまな原因で発生します。このハンドブック ここでは、リクエスト/レスポンスへのアクセスが原因で発生する 500 Internal Server Error（内部サーバーエラー）に焦点を当てています。 追加のペイロード が有効になっていることを確認します。

原因 説明 トラブルシューティングの手順を実施できるユーザー
ペイロードへのアクセス ストリーミング有効 ストリーミングが有効になっているときにリクエスト/レスポンス ペイロードにアクセスするため、エラーが発生しました。 Edge Private Cloud と Public Cloud のユーザー

原因: ストリーミングを有効にしてペイロードにアクセスする

診断

手順 1: Trace を使用する

  1. トレースを有効にする セッションを確認し、API 呼び出しを行って問題を再現します（500 Internal Server Error）
  2. 失敗したリクエストのいずれかを選択し、トレースを調べます。
  3. トレースのさまざまなフェーズを移動して、エラーが発生した場所を特定します。
  4. このエラーは、ポリシーがリクエスト/レスポンス ペイロードを解析しているときに発生した可能性があります。
  5. 次のトレースのスクリーンショット例は、JSONThreatProtection ポリシー が "Expecting } at line 1" で失敗する:

    alt_text

    上記に示すように、トレース出力の次の情報を記録します。 スクリーンショット:

    不合格のポリシー: JSONThreatProtection

    フロー: プロキシ リクエスト

  6. 失敗したポリシーの定義を調べ、解析中のペイロードを確認します。

    サンプル シナリオでは、次の JSONThreatProtection ポリシーを調べます。 JSON-Threat-Protection で失敗した場合は、<Source> 要素を確認してください。 

    <JSONThreatProtection async="false" continueOnError="false" enabled="true" name="JSON-Threat-Protection">
   <DisplayName>JSON Threat Protection</DisplayName>
   <ArrayElementCount>20</ArrayElementCount>
   <ContainerDepth>10</ContainerDepth>
   <ObjectEntryCount>15</ObjectEntryCount>
   <ObjectEntryNameLength>50</ObjectEntryNameLength>
   <Source>request</Source>
   <StringValueLength>1000</StringValueLength>
</JSONThreatProtection>

    <Source> 要素が request. を指しています。これは、 リクエスト ペイロードの解析中にエラーが発生した。

  7. API リクエストを確認して、解析するペイロードのタイプを特定します。

    8. リクエスト ペイロードと Content-Type ヘッダーの内容は、 作成されます。次の curl コマンドの例では、JSON ペイロードを使用しています。 

    curl -i https://VIRTUAL_HOST_ALIAS/BASEPATH -H "Content-Type: application/json" \
-X POST -d @request-payload.json

    また、エラーが発生しているポリシーを確認し、エラーが発生しているペイロードのタイプを特定することもできます。 表示されます。上記のシナリオでは、JSON-Threat-Protection ポリシーが失敗しています。 これは、ペイロードが JSON 形式である必要があることを示しています。

  8. ペイロードの形式が正しいことを確認します。ペイロードが有効でない場合、このエラーが発生します。

  9. ペイロードが有効であるにもかかわらず、 [Error Messages] セクションに移動し、これらのエラーの原因 ストリーミングが有効になっているときに ペイロードにアクセスされる点です

    ポリシーによって解析されるペイロード（ステップ 6 で特定）に応じて、 適切なフェーズで、Trace ツールでペイロードの内容を調べる。

    サンプル シナリオでは、リクエスト ペイロードが解析中であるため、 トレースの [Request Received from Client] フェーズで、 コンテンツの要求。

    alt_text

    上記のスクリーンショットのように [Request Content] が空欄の場合、 有効なペイロードを送信済みの場合、この問題の原因として考えられるのは リクエスト ストリーミングが有効になります。

    これは、ストリーミングが有効になっている場合、リクエストのペイロードがトレースに表示されないためです。

    同様に、エラーが発生したときにレスポンス ペイロードが解析されている場合は、 「Response received from target server」フェーズのレスポンス コンテンツ。

  10. 次に、障害が発生した場所に応じて、プロキシとターゲット エンドポイントの定義を調べます。 ポリシーが API プロキシフローで使用されます。ストリーミングが有効になっているかどうかを確認します。

    このシナリオでは、失敗したポリシーがプロキシ リクエスト フローで実行されています （上記のステップ 5 で確認）プロキシ エンドポイントを調べます。 

    <ProxyEndpoint name="default">
...
  <HTTPProxyConnection>
    <BasePath>/v1/weather</BasePath>
    <VirtualHost>secure</VirtualHost>
    <Properties>
      <Property name="response.streaming.enabled">true</Property>
      <Property name="request.streaming.enabled">true</Property>
    </Properties>
  </HTTPProxyConnection>
</ProxyEndpoint>

    上記の例に示されているように、リクエスト ストリーミングは プロパティ "request.streaming.enabled" を true に設定します。

    したがって、エラーの原因は API プロキシの JSONThreatProtection ポリシーの使用です。 リクエスト ペイロードにアクセスする API 呼び出しを示しています。エラーの原因は API プロキシでバッファリングがトリガーされ、Apigee Edge でストリーミングを使用する目的が果たされません。

    このエラーはペイロードのサイズが小さいと表示されない場合がありますが、ペイロードのサイズを大きくすると、 これらのエラーを確認できます。

  11. 値を確認することで、ポリシーに起因する 500 エラーであることを確認できます &quot;X-Apigee-fault-source&quot; （記録されたアナリティクスデータ）以下の手順で、トレースのフェーズを設定します。 <ph type="x-smartling-placeholder">
      </ph>
    1. [AX]（アナリティクス データを記録済み）フェーズをクリックします。 次のスクリーンショットのようになります。

      alt_text

    2. [Phase Details] で [Error Headers] まで下にスクロールします。セクションと 「X-Apigee-fault-code」の値を確認します。 &quot;X-Apigee-fault-source&quot;と 「X-Apigee-fault-policy」 を使用します。

      alt_text

    3. &quot;X-Apigee-fault-source&quot; の値が "policy" の場合: 上の図に示されている場合は、ポリシーが Compute Engine インスタンスにアクセスしていることが原因で ペイロードを使用できます。

解決策

ストリーミングを有効にしてペイロードにアクセスすることはアンチパターンです。 アンチパターン: ストリーミングが有効な場合にリクエスト/レスポンス ペイロードにアクセスする。

  1. ペイロードを処理する場合は、プロキシ/ターゲットでストリーミングを無効にする必要があります。 以下の ProxyEndpoint の例に示すように、プロパティを削除してエンドポイントを設定します。"request.streaming.enabled" and "response.streaming.enabled" 
    <ProxyEndpoint name="default">
...
  <HTTPProxyConnection>
    <BasePath>/v1/weather</BasePath>
    <VirtualHost>secure</VirtualHost>
  </HTTPProxyConnection>
</ProxyEndpoint>

    または

  2. API プロキシにストリーミングを使用する場合は、 リクエスト/レスポンス ペイロードにアクセスする API プロキシ。

注:

  • このハンドブックでは、JSONThreatProtection ポリシーを使用して、リクエストのペイロードを ストリーミングが有効になっているためです。これにより、さまざまなエラーが発生した 500 Internal Server Error（内部サーバーエラー）が発生しました。
  • これらのエラーは、JSON to XML や XMLToJSON などのポリシーで発生し、 リクエストまたはレスポンスのペイロードを返します。
  • このようなポリシーは、Compute Engine インスタンスへのアクセスを必要とするプロキシでは使用しないことを強くおすすめします。 ペイロードを使用できます。
  • これは、 アンチパターン: ストリーミングが有効な場合にリクエスト/レスポンス ペイロードにアクセスする。

API Monitoring を使用した問題の診断

Private Cloud をご利用の場合は、この手順をスキップしてください。

API Monitoring を使用すると、問題領域をすばやく分離して、エラー、パフォーマンス、レイテンシの問題とその原因（デベロッパー アプリ、API プロキシ、バックエンド ターゲット、API プラットフォームなど）を診断できます。

API Monitoring を使用して API に関する 5xx の問題をトラブルシューティングする方法を示すサンプル シナリオの手順を確認する。たとえば、500 エラーの数が特定のしきい値を超えたときに通知されるようにアラートを設定できます。

ポリシーから 500 エラー レスポンスがスローされたときに通知を受け取るには、障害発生元を [プロキシ] として、500 ステータス コードのアラートを設定する必要があります。

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

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

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）
  • Message Processor のログ（/opt/apigee/var/log/edge-message-processor/logs/system.log）
  • 500 エラーが発生したときのタイムゾーン情報の期間。