502 Bad Gateway（不正なゲートウェイ）

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

内容

クライアント アプリケーションが、HTTP ステータス コード 502 と、API 呼び出しのレスポンスとして「Bad Gateway」というメッセージを受け取ります。

HTTP ステータス コード 502 は、クライアントが、実際にリクエストを実行するバックエンド サーバーから有効なレスポンスを受信していないことを意味します。

エラー メッセージ

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

HTTP/1.1 502 Bad Gateway

加えて、以下のエラー メッセージが表示される場合があります。

<html>
<head>
<title>Error</title>
<style>
body {
width: 35em;
margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif;
}
</style>
</head>
<body>
<h1>An error occurred.</h1>
<p>Sorry, the page you are looking for is currently unavailable.<br/>
Please try again later.</p>
</body>
</html>

エラーがバックエンド サーバーで発生した場合は、次のように表示されます。バックエンドからのエラー メッセージは実装によって異なります。

<html>
<head><title>502 Bad Gateway</title></head>
<body bgcolor="white">
<center><h1>502 Bad Gateway</h1></center>
</body>
</html>

考えられる原因

Apigee Edge を経由する API で 502 Bad Gateway エラーが発生する可能性があります。考えられる原因は次のとおりです。

原因 説明 対象となるトラブルシューティング手順
プールで使用できる MP がない このエラーは、プール内のすべての MP が利用できない場合、つまり、ダウンしているかビジー状態で応答しない場合に発生します。 Edge Private Cloud ユーザー
Router と MP 間の SSL 構成が正しくない このエラーは、クライアントの CA 署名済みルート証明書が Edge の Router のトラストストアにない場合に発生します。 Edge Private Cloud ユーザー
バックエンド サーバーからのエラー このエラーは、バックエンド サーバーで障害が発生し、このレスポンスが送信されると発生します。 Edge Public Cloud ユーザーと Private Cloud ユーザー

原因: プールに使用可能な MP がない

このエラーは、特定のリージョン/データセンター内のすべての Message Processor が使用不能であるなど、Router が検出した場合に発生します。

Apigee Edge は、特定のリージョン/データセンターへの受信 API トラフィック（リクエスト）が常に Router から同じリージョン/データセンター内の Message Processor（MP）にルーティングされるように構成されています。Apigee Edge コンポーネントが 1 つのリージョン/データセンターにのみ設定される場合もあれば、複数のリージョン/データセンターに設定される場合もあります。各リージョン/データセンターには、2 つ以上の Router と Message Processor が構成されます。

診断

  1. API リクエストが 502 Bad Gateway エラーで失敗しているリージョン/データセンターを特定します（複数のリージョン/データセンターが存在する場合）。これを確認するには、ユーザーが 502 エラーが発生しているリージョンを特定するか、異なるリージョンに属する各 Router の /opt/apigee/var/log/edge-router/nginx/ ディレクトリにある NGINX アクセスログを確認します。
  2. NGINX Error ログ（/opt/apigee/var/log/edge-router/nginx/ORG-Env._error_log）に次のエラーが表示されます。
    2019/06/24 15:26:00 [error] 4796#4796: *56357443 no live upstreams while connecting to upstream, client: <Router_IP_address>, server: <HostAlias>, request: "PUT <BasePath> HTTP/1.1", upstream: "http://<ListOfMP-IP_R-MP-Port>/<BasePath>", host: "<HostAlias>"

シナリオ 1: すべての Message Processor がダウンしている

  1. 特定のリージョン/データセンターで Message Processor が稼働していることを確認します。
  2. すべての Message Processor が停止している場合は、再起動します。

解像度

次のコマンドを使用して、すべての Message Processor を再起動します。

/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart

シナリオ 2: すべての Message Processor が、進行中のリクエストの処理によりビジー状態となる

このエラーは、特定のリージョン/データセンター内のすべての Message Processor が進行中のリクエストの処理でビジー状態となり、アクセス不能な状態であることを Router が検出した場合に発生します。

  1. 特定のリージョン/データセンターで Message Processor が稼働していることを確認します。
  2. すべての Message Processor が稼働中でアクティブな場合は、Message Processor の CPU 使用率が高くなっているかどうかを確認し、次のコマンドを使用して 30 秒ごとに 3 つのスレッドダンプを生成します。
    <JAVA_HOME>/bin/jstack -l <pid> > <filename>
  3. Message Processor のメモリ使用量が多い場合は、次のコマンドを使用してヒープダンプを生成します。
    sudo -u apigee /bin/jmap -dump:live,format=b,file=
  4. 次のコマンドを使用して、Message Processor を再起動します。これにより、CPU とメモリが解放されます。
    /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
  5. API 呼び出しをモニタリングして、問題が解決しないかどうかを確認します。
  6. CPU/メモリ使用率が高い原因を調査するため、Apigee サポートに連絡し、スレッドダンプ、ヒープダンプ、Message Processor のログ（/opt/apigee/var/log/edge-message-processor/logs/system.log）を提供してください。

原因: Router と MP の間の SSL 構成が正しくない

診断

  1. NGINX のアクセスログ（/opt/apigee/var/log/edge-router/nginx/ORG-Env._access_log）を確認します。次のような 502 レスポンスが返されます。
        2019-07-23T12:13:42+03:00	sc-10-254-226-23	10.X.X.X:53634	10.X.X.X:8998	0.000	-	-	502	502	189	344	GET <path> curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.27.1 zlib/1.2.3 libidn/1.18 libssh2/1.4.2	<host alias>	mp-10-254-226-23-23706-8552529-1	10.129.107.101	-	-	-1	-	-	dc-2	gateway-2	green	-	gateway-2	dc-2	op	pilot	http	-
  2. NGINX エラーログ（/opt/apigee/var/log/edge-router/nginx/ORG-Env._error_log）を確認します。次のようなエラーが表示されます。
    	2019/07/30 17:02:24 [error] 7691#7691: *11753633 peer closed connection in SSL handshake while SSL handshaking to upstream, client: X.X.X.X, server: <HostAlias>, request: "GET /no-target HTTP/1.1", upstream: "https://X.X.X.X:8998/no-target", host: "<HostAlias>"
  3. これは、Router と Message Processor 間の SSL handshake が失敗することを示しています。
  4. 手順 1 と手順 2 のエラー メッセージをよく見た場合、Message Processor との通信に使用するポート番号は 8998 です。これはセキュア ポートではありませんが、プロトコルは SSL（https）です。通常、使用されるセキュア ポート番号は 8443 です。セキュアでないポートがセキュアな通信に使用されるため、SSL handshake の失敗が発生します。
  5. これは通常、Router と Message Processor 間の SSL の構成時に、手順を実行していないか、誤った値を設定した場合に発生します。こちらに記載されている手順を参照してください。
    たとえば、
    1. /opt/apigee/customer/application/message-processor.properties as shown below でポート番号に 8443 ではなく 8998 を指定している
              conf/message-processor-communication.properties+local.http.port=8998
    2. SSL 構成の実行中、/opt/nginx/conf.d/* ディレクトリの下にある Router 構成ファイルは削除されていません。このシナリオでは、構成ファイル内の Message Processor のポート番号が 8998 のままになっていることがわかります。

解像度

  1. Router と Message Processor 間の TLS の構成に記載されているすべてのステップが適切に行われていることを確認します。
  2. 問題が解決しない場合は、診断情報の収集に進みます。

原因: バックエンド サーバーのエラー

診断

  1. エラーが毎回発生する場合は、失敗したリクエストの UI トレースをキャプチャできます。失敗したリクエストを選択し、トレース内のさまざまなフェーズを確認します。バックエンド サーバー自体から「502 Bad Gateway」というメッセージが表示された場合、バックエンド サーバーでなんらかの障害が発生した可能性があります。
    バックエンド サーバーから 502 Bad Gateway が発生していることを示すトレース
  2. 問題が断続的に発生し、トレースをキャプチャできない場合は、
    1. Public Cloud をご利用の場合は、API Monitoring を使用して 502 エラーの詳細を確認できます。
      1. 障害コードが messaging.adaptors.http.flow.ErrorResponseCode で、障害ソースが target の場合、エラーの原因はバックエンド サーバーです。
    2. Private Cloud ユーザーであれば、NGINX のアクセスログを分析できます。
      /opt/apigee/var/log/edge-router/nginx/ORG-Env._access_log.
      失敗したリクエストのエントリは、次のように表示されます。
      2017-02-24T14:42:12+00:00	rt-01	192.8.155.2:18118	192.168.84.166:8998	10.225	-	-	502	502	440	0	GET /adv-eadlg-test/documents?type=doctype HTTP/1.1	rt-02efawae234-1234	Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36	myorg-dev.apigee.net	 rt-02efawae234-1234	6	-	false	target	messaging.adaptors.http.flow.ErrorResponseCode	null/null	-	/organizations/myorg/environments/dev/apiproxies/api123
      1. 障害コードが messaging.adaptors.http.flow.ErrorResponseCode で、障害ソースが target の場合、エラーの原因はバックエンド サーバーです。

解像度

  1. バックエンド サーバー チームと連携して、バックエンドでこの問題を修正してください。

診断情報の収集

  1. NGINX アクセスログ
    （/opt/apigee/var/log/edge-router/nginx/ORG-Env._access_log）
    とエラーログ
    （/opt/apigee/var/log/edge-router/nginx/ORG-Env._error_log）。
  2. Message Processor のログ
    （/opt/apigee/var/log/edge-message-processor/logs/system.log）。