現在、Apigee Edge のドキュメントを表示しています。
Apigee X のドキュメントをご確認ください。 情報
内容
クライアント アプリケーションが、API 呼び出しに対する HTTP レスポンス ステータス コード 500 と「内部サーバーエラー」メッセージを受け取ります。
エラー メッセージ
クライアント アプリケーションは、次のようなエラー レスポンスを受け取ることがあります。
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 の使用
- トレース セッションを有効にし、API 呼び出しを行って問題（500 内部サーバーエラー）を再現します。
- 失敗したリクエストの 1 つを選択し、トレースを調べます。
- トレースのさまざまなフェーズを確認し、エラーが発生した場所を特定します。
- このエラーは、ポリシーでリクエストやレスポンスのペイロードを解析しているときに発生した可能性があります。
- 以下は、JSONThreatProtection
ポリシーがJSONThreatProtection
「Expecting } at line 1」JSONThreatProtection
というエラーで失敗しているトレースのスクリーンショットです。
上のスクリーンショットに示すように、トレース出力の次の情報をメモします。
失敗したポリシー: JSONThreatProtection
フロー: プロキシ リクエスト
- 失敗したポリシーの定義を調べて、解析されているペイロードを確認します。
サンプル シナリオでは、失敗した JSON-Threat-Protection という名前の JSONThreatProtection ポリシーを調べて、
<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.を指していることに注目してください。これは、リクエスト ペイロードの解析中にエラーが発生したことを意味します。 - API リクエストを確認して、解析するペイロードのタイプを判断します。
- ペイロードが適切な形式になっているかどうかを検証します。ペイロードが有効でない場合、このエラーが発生する可能性があります。
ペイロードは有効ですが、エラー メッセージセクションにあるエラーが引き続き表示される場合、このエラーの原因は、ストリーミングが有効になっているときにペイロードがアクセスされていることです。
ポリシーで解析されるペイロード（手順 6 で決定）に応じて、適切なフェーズの Trace ツールでペイロードの内容を調べます。
このシナリオでは、リクエスト ペイロードが解析されているため、トレースの「Request Received from Client」フェーズを確認し、「Request Content.
上のスクリーンショットに示すように、有効なペイロードを送信しているにもかかわらず、リクエスト コンテンツが空になっている場合、この問題の考えられる原因は、リクエストのストリーミングが有効になっていると考えられます。
これは、ストリーミングが有効になっている場合、リクエスト ペイロードがトレースに表示されないためです。
同様に、エラーが発生したときにレスポンス ペイロードの解析が行われている場合は、「Response received from target server」フェーズでレスポンスの内容を確認します。
次に、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 プロキシでのバッファリングがトリガーされ、Apigee Edge でストリーミングを使用する目的が果たされないため、エラーが発生します。
このエラーは、ペイロードが小さいと発生しない場合がありますが、より大きなペイロードを使用すると、このようなエラーが確認できます。
- 次の手順に沿って、トレースの "AX" (Analytics Data Recorded) フェーズの "X-Apigee-fault-source" の値をチェックすることで、ポリシーが原因で 500 エラーが発生していることを確認できます。
- 次のスクリーンショットに示すように、[AX]（Analytics Data Recorded）フェーズをクリックします。
- [Phase Details] を [Error Headers] セクションまで下にスクロールし、次のように 「X-Apigee-fault-code」 、「X-Apigee-fault-source」 、「X-Apigee-fault-policy」 の値を確認します。
- 上の図のように、"X-Apigee-fault-source" の値が "policy" の場合、ストリーミングが有効になっているときに、ペイロードにアクセスするポリシーが原因でエラーが発生したことを示します。
- 次のスクリーンショットに示すように、[AX]（Analytics Data Recorded）フェーズをクリックします。
API リクエストのペイロードと 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 形式である必要があることを示します。
解像度
ストリーミングが有効になっているペイロードへのアクセスは、アンチパターン: ストリーミングが有効な場合にリクエスト/レスポンス ペイロードにアクセスするで説明されているように、アンチパターンです。
- ペイロードを処理する場合は、以下の ProxyEndpoint の例に示すように、プロパティ
"request.streaming.enabled" and "response.streaming.enabled"を削除して、プロキシ/ターゲット エンドポイントでのストリーミングを無効にする必要があります。<ProxyEndpoint name="default"> ... <HTTPProxyConnection> <BasePath>/v1/weather</BasePath> <VirtualHost>secure</VirtualHost> </HTTPProxyConnection> </ProxyEndpoint>または
- API プロキシでストリーミングを使用する場合は、リクエスト/レスポンス ペイロードにアクセスする API プロキシ内のポリシーを使用しないでください。
注:
- このハンドブックでは、サンプル シナリオで JSONThreatProtection ポリシーを使用して、ストリーミングを有効にしてリクエスト ペイロードを処理しました。これにより、さまざまなエラーとともに 500 Internal Server Error が発生しました。
- これらのエラーは、ストリーミングが有効な場合にリクエストまたはレスポンスのペイロードを処理する JSONToXML や XMLToJSON などのポリシーでも確認できます。
- ストリーミングが有効になっている場合、ペイロードへのアクセスを必要とするプロキシでは、このようなポリシーを使用しないことを強くおすすめします。
- これは、アンチパターン: ストリーミングが有効な場合にリクエスト/レスポンス ペイロードにアクセスするで説明されているように、アンチパターンになります。
API Monitoring を使用して問題を診断する
Private Cloud ユーザーの場合は、この手順をスキップしてください。
API Monitoring を使用すると、問題領域をすばやく分離して、エラー、パフォーマンス、レイテンシの問題とその原因（デベロッパー アプリ、API プロキシ、バックエンド ターゲット、API プラットフォームなど）を診断できます。
サンプル シナリオを実行し、API Monitoring を使用して API での 5xx 問題のトラブルシューティング方法を確認します。たとえば、500 件のエラーの数が特定のしきい値を超えたときに通知されるようにアラートを設定できます。
ポリシーから 500 エラー レスポンスがスローされたときに通知を受け取るには、500 ステータス コードのアラートを、障害ソースを [プロキシ] として設定する必要があります。
診断情報の収集が必要な場合
上記の手順でも問題が解決しない場合は、次の診断情報を収集してください。Apigee サポートに連絡し、共有してください。
Public Cloud をご利用の場合は、次の情報をご入力ください。
- 組織名
- 環境名
- API プロキシ名
- リクエスト ペイロード（存在する場合）を指定して、curl コマンドを完了し、500 エラーを再現します。
- 500 内部サーバーエラー リクエストを含むトレース ファイル
- 500 エラーが現在発生していない場合は、過去に 500 エラーが発生していたときの時間帯とタイムゾーンをお知らせください。
Private Cloud をご利用の場合は、次の情報を提供してください。
- 失敗したリクエストについて確認された完全なエラー メッセージ
- 500 エラーが発生している組織、環境名、API プロキシ名
- API プロキシ バンドル
- リクエストで使用されるペイロード（存在する場合）
- 500 内部サーバーエラー リクエストを含むトレース ファイル
- 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 エラーが発生した期間。