<ph type="x-smartling-placeholder"></ph>
現在、Apigee Edge のドキュメントが表示されています。
Apigee X のドキュメント。 詳細
症状
クライアント アプリケーションは、HTTP ステータス コード 502 Bad Gateway を受け取り、
コード ECONNRESET を使用します。
エラー メッセージ
クライアントには次のレスポンス コードが表示されます。
HTTP/1.1 502 Bad Gateway
レスポンスには、次のエラー メッセージが含まれます。
{"message":"socket hang up","code":"ECONNRESET"}
考えられる原因
| 原因 | 説明 | トラブルシューティングの実施対象 |
|---|---|---|
| キープアライブ タイムアウトが正しく構成されていない | Edge AppSheet とターゲット サーバーの間でキープアライブ タイムアウトが正しく構成されていない。 | Edge Public Cloud ユーザーと Edge Private Cloud ユーザー |
| ターゲット サーバーが接続を早期に終了する | ターゲット サーバーは、Edge AppSheet が送信している間に接続を早期に閉じます。 呼び出すことができます。 | Edge Public Cloud ユーザーと Edge Private Cloud ユーザー |
共通の診断手順
- Edge Appliance のログを確認します。
/var/tmp/edgemicro-`hostname`-*.log
- コード
ECONNRESETで502エラーがないか検索します 特定の期間（過去に問題が発生した場合は）、 まだ502で失敗しています。2021-06-23T03:52:24.110Z [error][0:8000][3][myorg][test] [emg_badtarget/flakey/hangup][][][6b089a00-d3d6-11eb-95aa-911f1ee6c684] [microgateway-core][][GET][502][socket hang up][ECONNRESET][]
- ロギングレベルを
warnまたはinfoに設定している場合、それらも記録されます。 2 つ目の部分は、ターゲット サーバーのホスト名とポートを含む[warn]メッセージです。 要素です。この例ではX.X.X.X:8080です。これを使用できます。 後でtcpdumpをキャプチャします。2021-06-23T03:52:24.109Z [warn][X.X.X.X:8080][3][myorg][test][emg_badtarget/flakey/hangup] [][][6b089a00-d3d6-11eb-95aa-911f1ee6c684][plugins-middleware] [targetRequest error][GET][][socket hang up][ECONNRESET][395]
- エラーコード
[socket hang up][ECONNRESET]は、ターゲット サーバーが 接続が終了しました。これはログで検索して、 発生頻度を確認できます
原因: キープアライブ タイムアウトが正しく構成されていない
<ph type="x-smartling-placeholder">診断
tcpdump の使用
- Edge Appliance とバックエンド サーバーの間で
tcpdumpをキャプチャします。 次のコマンドを実行して、Edge API ホスト オペレーティング システムを起動します。tcpdump -i any -s 0 host TARGET_SERVER_HOSTNAME -w FILENAME.pcap
- キャプチャした
tcpdumpを分析します。tcpdump の出力例: ( 拡大画像を表示）
上記のサンプル
tcpdumpでは、次のようになります。- パケット 250288 で、クライアントが
POSTリクエストを送信します。 - パケット 250371 で、サーバーが
200 OKを返します。 - パケット 250559 で、クライアントが
ACK.を送信します。 - パケット 250560 で、サーバーは
Continuationを送信します。 表示されます。 - パケット 250561 で、クライアントが
ACK.を送信します。 - パケット 262436 で、サーバーは
FIN, ACKを クライアントが接続の閉鎖を開始します。約 5 分の 1 ですが、 前のパケットから経過した秒数（250561）。 - パケット 262441 で、クライアントが別の
POSTを送信します。 リクエストできます。ただし、サーバーがすでにコンテナのクローズを開始しているため、これは失敗します。 接続しますパケットでRSTを返します。 262441。
この例では同じ接続が少なくとも 1 回正常に再利用されていますが、 最後のリクエストでは、サーバーは 5 秒後に接続の切断を開始します。 このアイドル時間はクライアントが新しいリクエストを送信した時間と同時に発生します。この は、バックエンド サーバーのキープアライブ タイムアウトが クライアントで設定された値を使用します。これを検証するには Edge AppSheet とバックエンド サーバーでのキープアライブ タイムアウトを比較する。
- パケット 250288 で、クライアントが
キープアライブ タイムアウトを比較する
- Edge Appliance には、特定のキープアライブ タイムアウト プロパティはありません。内容 動作しているオペレーティング システムによって決まります。一般的な例としては、Windows、 コンテナ化されたアプリケーションを実行します
- オペレーティング システムでカスタマイズされている可能性があります。詳しくは、 必要ありません。デフォルトでは、Linux オペレーティング システムには 2 時間のタイムアウトになります
- 次に、バックエンド サーバーで構成されているキープアライブ タイムアウト プロパティを確認します。では、 バックエンド サーバーが 10 秒に構成されているとします。
- オペレーティング システムのキープアライブ タイムアウトの値が
バックエンド サーバーのキープアライブ タイムアウト プロパティの値よりも大きくすることができます。
その場合、それが
502エラーの原因です。
解決策
Edge を使用するオペレーティング システムで、キープアライブ タイムアウト プロパティが常に小さくなるようにします。 バックエンド サーバーで実行されている場合と比較して、mTLS は動作しています。
- バックエンド サーバーでキープアライブ タイムアウトに設定された値を確認します。
- オペレーティング アプリケーションのキープアライブ タイムアウト プロパティに適切な値を キープアライブ タイムアウト プロパティがバックエンドで設定された値よりも小さくなるように オペレーティング システムに応じた手順に沿って操作してください。
ベスト プラクティス
ダウンストリーム コンポーネントのキープアライブ タイムアウトは常に短くすることを強くおすすめします。
構成したしきい値よりも高く設定して、このような競合状態や
502 エラー。各ダウンストリーム ホップは、各アップストリーム ホップよりも小さくする必要があります。エッジ内
次のガイドラインを使用することをおすすめします。
クライアント アプリケーションまたはロードバランサのキープアライブ タイムアウトは、 Edge Appliance のキープアライブ タイムアウト。
Edge Appliance でキープアライブ タイムアウトを構成するには、
keep_alive_timeoutの価値を~/.edgemicro/org-env-config.yamlファイル。edgemicro: keep_alive_timeout: 65000
<ph type="x-smartling-placeholder">- Edge AppSheet オペレーティング システムのキープアライブ タイムアウトは、ターゲットよりも短くする必要があります サーバー キープアライブ タイムアウト。
- Edge AppSheet の前または背後に他のホップがある場合、同じルールが適用されます。 適用されます。クローズはダウンストリーム クライアントの責任として常に任せる 内部 IP アドレスを使用して通信できます
原因: ターゲット サーバーが接続を早期に終了する
<ph type="x-smartling-placeholder">診断
- 一般的な診断手順に記載されている手順に沿って、以下を確認します。
[socket hang up][ECONNRESET]エラーが発生しました。 - 「はい」の場合は、以下で説明する
tcpdumpを使用してさらに調査します。エラー メッセージ
[targetRequest error][GET][][socket hang up][ECONNRESET]上の例は、このエラーが発生したことを、Edge Appliance の バックエンド（ターゲット）サーバーにリクエストを送信していました。つまり、Edge API は API リクエストをバックエンド サーバーに送信し、レスポンスを待機していました。ただしバックエンドは サーバーがレスポンスを受信する前に、接続を突然終了しました。 - バックエンド サーバーのログを調べて、エラーや情報がないか確認します。 バックエンド サーバーが接続を突然終了させます。エラーまたは に進み、解決策に進み、問題を適切に修正する バックエンドサーバーにインストールし
- バックエンド サーバーにエラーや情報がない場合は、
Edge Appliance サーバーの
tcpdump出力:tcpdump -i any -s 0 host TARGET_SERVER_HOSTNAME -w FILENAME.pcap
- キャプチャした
tcpdumpを分析します。tcpdump の出力例: ( 拡大画像を表示）
上記のサンプル
tcpdumpでは、次のようになります。- パケット 4 で、Edge API が
GETリクエストをターゲットに送信しました。 あります。 - パケット 5 で、ターゲット サーバーは
ACKで応答し、 リクエストできます。 - ただし、パケット 6 では、ターゲットはレスポンス ペイロードで応答する代わりに、
サーバーが
FIN, ACKを送信して接続の終了を開始します。 - 7 以降のパケットでは、接続が相互に閉じられます。この接続は
レスポンスが送信される前に閉じられた場合、Edge AppSheet は HTTP
502を返します。 クライアントにエラーを返します。 - パケット 8 のタイムスタンプ
2021-06-23T03:52:24.110Zは、Edge API でエラーがログに記録されたタイムスタンプに対応していることに注意してください。 できます。ログファイルとtcpdumpのタイムスタンプは、 エラーと実際のパケットとの相関関係があります。
解決策
バックエンド サーバーで問題を適切に修正してください。
問題が解決せず、
502 Bad Gateway Errorのトラブルシューティングでサポートが必要な場合 または、それが Edge Dataproc 内の問題だと思われる場合は、 診断情報の収集が必要な場合。診断情報の収集が必要な場合
上記の手順でも問題が解決しない場合は、以下の情報を収集します。 Apigee Edge サポートにお問い合わせください。
- ログファイル: デフォルトのフォルダは
/var/tmpですが、オーバーライドされる可能性があります。 が、メインのconfig.yamlファイル（logging > dir parameter）で設定されます。内容 指定する前にlog > levelをinfoに変更することをおすすめします Apigee サポートにログファイルを提供します。 - 構成ファイル: Edge Migration の主な構成は
デフォルトの Edge AppSheet フォルダ（
$HOME/.edgemicro）にある YAML ファイル。こちらのdefault.yamlというデフォルト構成ファイルを作成し、環境ごとに 1 つずつ作成します。ORG-ENV-config.yaml。このファイルをアップロードしてください 影響を受けた組織と環境についてすべて
- パケット 4 で、Edge API が