本頁面由 Cloud Translation API 翻譯而成。

訊息處理器疑難排解指南

本主題將說明如何排解及修正訊息處理器問題。訊息處理器是 apigee-runtime 元件的一部分。另請參閱「執行階段服務設定總覽」。

就緒探查失敗，並傳回 HTTP 狀態碼 500

問題

一或多個 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
...

可能原因

這項錯誤表示訊息處理器沒有有效的合約，因此無法處理流量。在此狀態下，訊息處理器無法自行呼叫「ready」。

原因	說明
同步器與管理層的連線問題	同步器無法連線至管理平面。如果您覆寫 `contractProvider` 網址，並將錯誤的服務帳戶與其建立關聯，通常就會發生這個問題。舉例來說，如果您為暫存部署作業設定服務帳戶，但 `contractProvider` 網址指向的是正式環境伺服器。
訊息處理器與同步器之間的連線問題	如果新的 MP 是自動調整規模或 Pod 重新啟動的一部分，您可能會看到這項錯誤。一般來說，如果同步器故障，且 MP 無法載入合約，就會發生這個問題。

診斷結果：同步器與管理平面之間的連線問題

如要診斷同步器與管理平面之間的連線問題，請按照下列步驟操作：

列出叢集中的 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 /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

在 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，或如上所述版本不符，請檢查同步器記錄，嘗試找出無法下載最新合約的原因。例如：

kubectl logs -f -n namespace synchronizer-pod-name

如要瞭解如何解讀同步處理工具記錄，請參閱「同步處理工具記錄」。如果同步器停止運作，請嘗試使用 apigeectl 重新啟動。例如：

$APIGEECTL_HOME/apigeectl apply -f overrides/overrides.yaml --org --env env-name

診斷：訊息處理器與同步器之間的連線問題

如要診斷訊息處理器與同步器之間的連線問題，請按照下列步驟操作：

列出叢集中的 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 可能無法載入合約。一般來說，問題發生時，同步器會停止運作，導致 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)

解析度

嘗試重新啟動同步器。例如：

$APIGEECTL_HOME/apigeectl apply -f overrides/overrides.yaml --org --env env-name

無效的加密金鑰導致完備性探測失敗

問題

apigee-runtime Pod 未處於就緒狀態。

診斷

使用 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 編碼。如要進一步瞭解如何建立格式正確的金鑰，請參閱「資料加密」。

查看訊息處理工具記錄

如要進一步瞭解如何查看及解讀訊息處理器記錄，請參閱「執行階段記錄」。

從執行階段 Pod 呼叫 API Proxy

在某些情況下，為了協助找出問題，您可能需要檢查是否可以直接從 apigee-runtime Pod 內部發出 API Proxy 呼叫，藉此略過 Ingress Gateway。

執行下列指令，轉送至通訊埠 8443。這樣一來，您就能在 Pod 中呼叫 API：
```
kubectl port-forward -n namespace apigee-runtime-pod-name 8443:8443
```

呼叫已部署的 API Proxy。舉例來說，如果 Proxy 基礎路徑為 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-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」環境中已部署的 Proxy 相關資訊：

[ {
  "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-runtime Pod 中選擇要偵錯的 Pod。

使用 /logsessions API 在要排解問題的執行階段 Pod 中建立記錄工作階段。如要瞭解 API 的詳細資訊，請參閱「關於 logsessions 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。