現在、Apigee と Apigee ハイブリッドのドキュメントを表示しています。
このトピックに対応する Apigee Edge のドキュメントはありません。
このトピックでは、Message Processor のトラブルシューティングと問題の修正の手順について説明します。Message Processor は、apigee-runtime コンポーネントの一部です。ランタイム サービス構成の概要もご覧ください。
readinessProbe が HTTP ステータス コード 500 で失敗する
症状
1 つ以上の apigee-runtime Pod が Ready 状態ではありません。
エラー メッセージ
kubectl を使用して失敗した apigee-runtime Pod を記述すると、次のエラーが表示されます。
Readiness probe failed: HTTP probe failed with statuscode: 500
次に例を示します。
kubectl describe pod -n hybrid \ apigee-runtime-apigee-gcp-prod1-test-blue-67db4f457b-9c7c7 ... apigee-runtime-apigee-gcp-prod1-test-blue-67db4f457b-9c7c7 Readiness probe failed: HTTP probe failed with statuscode: 500 ...
考えられる原因
このエラーは、Message Processor でトラフィックの処理に使用できるアクティブなコントラクトがないことを意味します。この状態では、Message Processor は自身を READY 状態にすることはできません。
| 原因 | 説明 |
|---|---|
| Synchronizer と管理プレーン間の接続の問題 | Synchronizer が管理プレーンに接続できません。通常、この問題は、contractProvider URL をオーバーライドして、誤ったサービス アカウントをそれに関連付けた場合に発生します。たとえば、本番環境のサーバーを指す contractProvider URL を使用して、デプロイ ステージング用のサービス アカウントを構成する場合などです。 |
| Message Processor から Synchronizer への接続の問題 | 自動スケーリングや Pod の再起動の一環として新しい Message Processor が出現する場合は、このエラーが表示されることがあります。この問題は多くの場合、Synchronizer がダウンしていて、Message Processor がコントラクトを読み込めなかったときに発生します。 |
診断: Synchronizer から管理プレーンへの接続の問題
Synchronizer から管理プレーンへの接続の問題を診断するには、次のようにします。
- クラスタ内の Pod を一覧表示します。
kubectl get pods -n namespace
apigee-synchronizerPod でシェルを開きます。kubectl exec -it -n namespace synchronizer-pod-name -- bash
次に例を示します。
kubectl exec -it -n apigee apigee-synchronizer-apigee-gcp-prod1-test-blue-cnj5x -- bash
- 次のディレクトリに移動します。
cd /opt/apigee/var/log/apigee-synchronizerlsdr-xr-sr-x 4 apigee apigee 4096 Sep 12 16:52 750 drwxr-sr-x 2 apigee apigee 4096 Sep 12 16:52 cachedFiles -rw-r--r-- 1 apigee apigee 22295 Sep 12 16:52 config.log -rw-r--r-- 1 apigee apigee 76 Sep 12 16:52 versions.properties version.propertiesで有効なバージョンを確認します。次に例を示します。cat versions.properties #active repository version #Sat Dec 14 19:45:00 GMT 2019 active.version=749
active.versionの値がコントラクト フォルダ番号の名前と一致することを確認します。前述の例では（以下も参照）、フォルダ名は750であるため、一致していません。dr-xr-sr-x 4 apigee apigee 4096 Sep 12 16:52 750
- Pod のシェルを終了します。
解決策
version.properties が欠落している場合、または上記のようなバージョンの不一致がある場合は、Synchronizer ログを確認して、最新のコントラクトがダウンロードされていない理由を判断します。次に例を示します。
kubectl logs -f -n namespace synchronizer-pod-name
Synchronizer ログの解釈の詳細については、Synchronizer のログをご覧ください。Synchronizer が停止している場合は、apigeectl を使用して再起動してみてください。次に例を示します。
$APIGEECTL_HOME/apigeectl apply -f overrides/overrides.yaml --org --env env-name
診断: Message Processor から Synchronizer への接続の問題
Message Processor から Synchronizer への接続の問題を診断するには、次のようにします。
- クラスタ内の Pod を一覧表示します。
kubectl get pods -n namespace
- ランタイムログを確認して、コントラクトがダウンロードされていない理由を判断します。
kubectl logs -f -n namespace pod-name
次に例を示します。
kubectl logs -f -n apigee apigee-runtime-apigee-gcp-prod1-test-blue-67db4f457b-9c7c7
新しい MP が自動スケールまたは Pod の再起動の一部として表示される場合、MP によってコントラクトが読み込まれない可能性があります。この問題は多くの場合、Synchronizer が停止していて、Message Processor がコントラクトを読み込めないときに発生します。次に例を示します。
2019-09-13 16:59:24,331 podName:N/A ipAddress:N/A dpColor:N/A HttpClient@331886186-301 DEBUG o.e.j.c.AbstractConnectionPool - AbstractConnectionPool$1.failed() : Connection 1/64 creation failed java.net.UnknownHostException: apigee-synchronizer-apigee-gcp-prod1-test.hybrid.svc.cluster.local at java.net.InetAddress.getAllByName0(InetAddress.java:1281) at java.net.InetAddress.getAllByName(InetAddress.java:1193) at java.net.InetAddress.getAllByName(InetAddress.java:1127) at org.eclipse.jetty.util.SocketAddressResolver$Async.lambda$resolve$1(SocketAddressResolver.java:167) at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:672) at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:590) at java.lang.Thread.run(Thread.java:748) at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:590) at java.lang.Thread.run(Thread.java:748)
解決策
Synchronizer を再起動してみます。次に例を示します。
$APIGEECTL_HOME/apigeectl apply -f overrides/overrides.yaml --org --env env-name
readinessProbe が無効な暗号鍵で失敗する
症状
apigee-runtime Pod が READY 状態ではありません。
診断
kubectl を使用して失敗した apigee-runtime Pod を記述すると、Readiness probe failed: Probe hybrid-encryption-key-validation-probe failed というエラーが表示されます。次に例を示します。
$ kubectl describe pod -n namespace apigee-runtime-pod-name
...
Readiness probe failed: Probe hybrid-encryption-key-validation-probe failed due to
com.apigee.probe.model.ProbeFailedException{ code = hybrid.encryption.key.InvalidEncryptionKey,
message = Invalid encryption key. Please check the length of the encryption key, associated
contexts = []}
...
解決策
サポートされている暗号鍵の長さは 16、24、32 バイトで、鍵の値は base64 でエンコードする必要があります。適切に形式設定された鍵の作成について詳しくは、データ暗号化をご覧ください。
Message Processor のログの表示
Message Processor ログの表示と解釈の詳細については、ランタイムログをご覧ください。
ランタイム Pod から API プロキシを呼び出す
場合によっては、問題を特定するために、apigee-runtime Pod 内から API プロキシの呼び出しを直接実行して、Ingress ゲートウェイをバイパスできるかどうかを確認することもできます。
- 次のコマンドを実行して、ポート 8443 に転送します。これにより、Pod 内で API を呼び出せます。
kubectl port-forward -n namespace apigee-runtime-pod-name 8443:8443
- デプロイされた API プロキシを呼び出します。たとえば、プロキシのベースパスが
ilove-apisの場合は:curl -k -v https://0:8443//ilove-apis < HTTP/1.1 200 OK < X-Powered-By: Apigee < Access-Control-Allow-Origin: * < X-Frame-Options: ALLOW-FROM RESOURCE-URL < X-XSS-Protection: 1 < X-Content-Type-Options: nosniff < Content-Type: text/html; charset=utf-8 < Content-Length: 18 < ETag: W/"12-Jb9QP1bUxNSmZkxQGt5KLQ" < Date: Fri, 13 Sep 2019 18:33:46 GMT < Via: 1.1 google < X-Apigee.Message-ID: 016f5f7f-c59e-404c-86e8-7b0737833f982 < X-Apigee.dp.color: blue < X-Apigee.proxy: /organizations/my-org/environments/test/apiproxies/i-loveapis/revisions/1 < X-Apigee.proxy.basepath: /ilove-apis < X-Apigee.target-latency: 9 < * Connection #0 to host 0 left intact <H2>I <3 APIs
管理 API を確認する
以下に示されている API を使用して、管理 API が正しく動作しているかどうかを確認できます。
- クラスタ内の Pod の名前を取得します。
kubectl get pods -n namespace
- ポート転送を使用して、
apigee-runtimePod にアクセスできるようにします。ポート転送の構文は次のとおりです。kubectl port-forward -n namespace podname 8843:8843
次に例を示します。
kubectl port-forward -n apigee \ apigee-runtime-my-organization-test-blue-57965b7789-6j4bp 8843:8843 - 次の例に示すように、別のターミナル ウィンドウを開き、
curlなどのユーティリティを使用してclassification/treeAPI にリクエストを送信します。curl -k https://0:8843/v1/classification/tree
次のレスポンス例には、test 環境にデプロイされたプロキシの情報が含まれています。
[ { "condition" : "(always matches)", "virtualHost" : { "env" : "test", "name" : "default", "org" : "my-organization", "tree" : { "elements" : [ { "application" : "myproxy", "basePath" : "/myproxy", "name" : "default", "revision" : "1" } ], "name" : "IdentificationTree" } } } ]
DEBUG モードを使用する
トラブルシューティングで使用できるように、DEBUG モードを有効にして、apigee-runtime Pod ログにさらに詳細な情報を含めることができます。
- Namespace 内の Pod を一覧表示します。
kubectl get pods -n namespace
- リストされた
apigee-runtimePod のいずれかを選択してデバッグします。 - その Pod に対して、ポート転送コマンドを実行します。次に例を示します。
kubectl port-forward -n hybrid apigee-runtime-hybrid-prod-blue-fcpdd 8843
- 別のターミナルを開き、次の API を呼び出してデバッグを有効にします。
curl "https://0:8843/v1/logsessions?sessions=debug" -X POST -v -k
kubectl logsコマンドを実行して、DEBUG モードのログを確認します。次に例を示します。kubectl logs -f -n hybrid apigee-runtime-hybrid-prod-blue-fcpdd
- DEBUG ログの調査が完了したら、ログレベルを INFO（デフォルト）にリセットします。次に例を示します。
curl "https://0:8843/v1/logsessions?sessions=info" -X POST -v -k
kubectl logsコマンドを実行して、ログが INFO モードに戻っていることを確認します。