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

このトピックでは、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 /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 -c synchronizer

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

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. 次のコマンドを実行して、ポート 8843 に転送します。これにより、Pod 内で API を呼び出すことができます。
    kubectl port-forward -n namespace apigee-runtime-pod-name 8843:8843
  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"
        }
      }
    } ]

DEBUG モードを使用する

トラブルシューティングで使用できるように、DEBUG モードを有効にして、apigee-runtime Pod ログにさらに詳細な情報を含めることができます。

  1. Namespace 内の Pod を一覧表示します。
    kubectl get pods -n namespace
  2. リストされた apigee-runtime Pod のいずれかを選択してデバッグします。
  3. その Pod に対して、ポート転送コマンドを実行します。次に例を示します。
    kubectl port-forward -n hybrid apigee-runtime-hybrid-prod-blue-fcpdd 8843
  4. 別のターミナルを開き、次の API を呼び出してデバッグを有効にします。
    curl "https://0:8843/v1/logsessions?sessions=debug" -X POST -v -k
  5. kubectl logs コマンドを実行して、DEBUG モードのログを確認します。次に例を示します。
    kubectl logs -f -n hybrid apigee-runtime-hybrid-prod-blue-fcpdd
    
  6. DEBUG ログの調査が完了したら、ログレベルを INFO(デフォルト)にリセットします。次に例を示します。
    curl "https://0:8843/v1/logsessions?sessions=info" -X POST -v -k
  7. kubectl logs コマンドを実行して、ログが INFO モードに戻っていることを確認します。