Message Processor のトラブルシューティングガイド

このトピックでは、Message Processor のトラブルシューティングと問題の修正の手順について説明します。Message Processor は、apigee-runtime コンポーネントの一部です。ランタイムサービス構成の概要もご覧ください。

Readiness Probe が 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 への接続の問題新しい MP が自動スケーリングまたは Pod の再起動の一部として表示される場合、このエラーが表示されることがあります。多くの場合、この問題は、Synchronizer がダウンしていて、MP が契約を読み込めなかったときに発生します。

原因	説明
Synchronizer から管理プレーンへの接続の問題	Synchronizer が管理プレーンに接続できません。通常、この問題は、`contractProvider` URL をオーバーライドして、誤ったサービスアカウントをそれに関連付けた場合に発生します。たとえば、本番環境のサーバーを指す `contractProvider` URL を使用して、ステージングデプロイ用のサービスアカウントを構成する場合などです。
Message Processor から Synchronizer への接続の問題	新しい MP が自動スケーリングまたは Pod の再起動の一部として表示される場合、このエラーが表示されることがあります。多くの場合、この問題は、Synchronizer がダウンしていて、MP が契約を読み込めなかったときに発生します。

診断: Synchronizer から管理プレーンへの接続の問題

Synchronizer から管理プレーンへの接続の問題を診断するには、次のようにします。

クラスタ内の Pod を一覧表示します。
```
kubectl get pods -n namespace
```

apigee-synchronizer Pod でシェルを開きます。

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-synchronizer
ls

  dr-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 -c synchronizer

診断: 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 -c synchronizer

Readiness Probe が無効な暗号鍵で失敗する

症状

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 プロキシの呼び出しを直接実行して、上りゲートウェイをバイパスできるかどうかを確認することもできます。

次のコマンドを実行して、ポート 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 を使用して、Management API が正しく動作しているかどうかを確認できます。

クラスタ内の Pod の名前を取得します。
```
kubectl get pods -n namespace
```

ポート転送を使用して、apigee-runtime Pod にアクセスします。ポート転送の構文は次のとおりです。

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/tree API にリクエストを送信します。

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 ログにさらに詳細な情報を含めることができます。

名前空間内の Pod を一覧表示します。
```
kubectl get pods -n namespace
```
リストされた apigee-runtime Pod のいずれかを選択してデバッグします。
その 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 モードに戻っていることを確認します。

Message Processor のトラブルシューティング ガイド

Readiness Probe が HTTP ステータス コード 500 で失敗する

症状

エラー メッセージ