このトピックでは、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 の再起動の一環として新しい MP が出現する場合は、このエラーが表示されることがあります。多くの場合、この問題は、Synchronizer がダウンしていて、MP がコントラクトを読み込めなかったときに発生します。 |
診断: 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 /application/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 が停止していて、MP がコントラクトを読み込めないときに発生します。次に例を示します。
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" } } } ]
ロギングを使用してランタイム Pod の問題をデバッグする
トラブルシューティングで使用できるように、ログセッションを作成して apigee-runtime Pod の詳細なログ出力を生成できます。
ログセッションを作成する
ランタイム Pod のログセッションを作成するには:
- ランタイム Pod を一覧表示します。デフォルトでは、それらは
apigee名前空間にあります。別の名前空間を選択した場合は、代わりにその名前空間を使用します。kubectl get pods -n apigee
- リストされた
apigee-runtimePod のいずれかを選択してデバッグします。 /logsessionsAPI を使用して、トラブルシューティングするランタイム Pod にログセッションを作成します。API の詳細については、ログセッション API についてをご覧ください。kubectl exec -it RUNTIME_POD_NAME -n apigee \ -- curl "https://0:8843/v1/logsessions?loggerNames=ALL&level=FINE&timeout=60000" -k -X POST -v
次に例を示します。
kubectl exec -it apigee-runtime-hybrid-18-01232-dev-d27ca57-190rc6-3klyg-lc7h5 -n apigee \ -- curl "https://0:8843/v1/logsessions?loggerNames=ALL&level=FINE&timeout=60000" -k -X POST -v
レスポンスはログセッション ID です。例:
9f831a7d-e533-4ead-8e58-12ec1059a622- ログを出力します。
kubectl logs -f -n apigee RUNTIME_POD_NAME
ログセッションを一覧表示する
ランタイム Pod でアクティブなログセッションのリストを取得するには:
kubectl exec -it RUNTIME_POD_NAME -n apigee \ -- curl "https://0:8843/v1/logsessions" -k -v
ログセッションを取得する
ログセッションの詳細を取得するには:
kubectl exec -it RUNTIME_POD_NAME -n apigee \ -- curl "https://0:8843/v1/logsessions/LOG_SESSION_ID" -k -v
ログセッションを終了する
ログセッションを終了するには:
kubectl exec -it RUNTIME_POD_NAME -n apigee \
-- curl "https://0:8843/v1/logsessions/LOG_SESSION_ID" -k -X DELETE -v
logsessions API について
このセクションでは、logsessions API クエリ パラメータについて説明します。
loggerNames: 表示するログ出力の種類を指定します。有効な値はCONTRACT_REPLICATION、DEBUG.SESSION、またはALLです。level: ログ出力レベルを指定します。有効な値は、FINEST、FINER、FINE、INFO、SEVERE、ALLです。timeout: 指定したログレベルでログセッションが動作する時間を指定します。タイムアウト後、ログレベルはINFOに戻ります。
成功すると、API からログセッションのセッション ID が返されます。