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

ここに表示されているのは、Apigee ハイブリッドに関するドキュメントのバージョン 1.7 です。 This version is end of life. You should upgrade to a newer version. 詳細については、サポート対象バージョンをご覧ください。

Version 1.7 (unsupported)

サポート対象のバージョン:

• v1.13（最新）
• v1.12
• v1.11
• サポート対象バージョンのリスト

サポートされていないバージョン:

• v1.10
• v1.9
• v1.8
• v1.7
• v1.6
• v1.5
• v1.4
• v1.3
• v1.2
• v1.1

このトピックでは、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 から管理プレーンへの接続の問題を診断するには、次のようにします。

1. クラスタ内の Pod を一覧表示します。

   kubectl get pods -n namespace

2. 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

3. 次のディレクトリに移動します。

   cd /application/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

4. version.properties で有効なバージョンを確認します。次に例を示します。

   cat versions.properties
   
     #active repository version
     #Sat Dec 14 19:45:00 GMT 2019
     active.version=749

5. active.version の値がコントラクト フォルダ番号の名前と一致することを確認します。上記の例では（下記も参照）、フォルダ名は 750 であるため、一致していません。

   dr-xr-sr-x 4 apigee apigee  4096 Sep 12 16:52 750

6. 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 への接続の問題を診断するには、次のようにします。

1. クラスタ内の Pod を一覧表示します。

   kubectl get pods -n namespace

2. ランタイムログを確認して、コントラクトがダウンロードされていない理由を判断します。

   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 ゲートウェイをバイパスできるかどうかを確認することもできます。

1. 次のコマンドを実行して、ポート 8443 に転送します。これにより、Pod 内で API を呼び出すことができます。

   kubectl port-forward -n namespace apigee-runtime-pod-name 8443:8443

2. デプロイされた 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 が正しく動作しているかどうかを確認できます。

1. クラスタ内の Pod の名前を取得します。

   kubectl get pods -n namespace

2. ポート転送を使用して、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

3. 次の例のように、別のターミナル ウィンドウを開き、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"
       }
     }
   } ]

ロギングを使用してランタイム Pod の問題をデバッグする

トラブルシューティングで使用できるように、ログセッションを作成して apigee-runtime Pod の詳細なログ出力を生成できます。

ログセッションを作成する

ランタイム Pod のログセッションを作成するには:

1. ランタイム Pod を一覧表示します。デフォルトでは、それらは apigee 名前空間にあります。別の名前空間を選択した場合は、代わりにその名前空間を使用します。

   kubectl get pods -n apigee

2. リストされた apigee-runtime Pod のいずれかを選択してデバッグします。
3. /logsessions API を使用して、トラブルシューティングするランタイム 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

4. ログを出力します。

   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 が返されます。