本主題將說明如何排解及修正訊息處理器相關問題。訊息處理器是
apigee-runtime 元件的一部分。另請參閱「執行階段服務設定總覽」。
就緒探針失敗，HTTP 狀態碼為 500
問題
有一或多個 apigee-runtime 容器未處於「就緒」狀態。
錯誤訊息
當您使用 kubectl 描述失敗的 apigee-runtime 容器時，您會看到以下錯誤：
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」。
| 原因 | 說明 |
|---|---|
| Synchronizer 與管理層連線問題 | 同步器無法連線至管理層面。這類問題通常是因為您覆寫 contractProvider 網址，並將錯誤的服務帳戶與該網址建立關聯。舉例來說，如果您為測試環境部署設定服務帳戶，並使用指向正式版伺服器的 contractProvider 網址， |
| 訊息處理器與同步器連線問題 | 如果新 MP 是自動調整或 Pod 重新啟動的一環，您可能會看到這項錯誤。 一般來說，這個問題會在同步器關閉且 MP 無法載入合約時發生。 |
診斷：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 /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，或如上文所述版本不相符，請檢查同步器記錄，嘗試找出未下載最新合約的原因。例如：
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 容器並未處於就緒狀態。
診斷
當您使用 kubectl 描述失敗的 apigee-runtime 容器時，您會看到以下錯誤：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 代理呼叫，藉此略過入口網關。
- 執行下列指令，將連線轉送至 8443 通訊埠。這樣一來，您就能在 Pod 中呼叫 API：
kubectl port-forward -n namespace apigee-runtime-pod-name 8443:8443
- 呼叫已部署的 API Proxy。舉例來說，如果 Proxy 的 basepath 是
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」環境中已部署的 Proxy 相關資訊：
[ { "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 模式。