本主题介绍执行排查和解决消息处理器问题时可执行的步骤。消息处理器是 apigee-runtime 组件的一部分。另请参阅运行时服务配置概览。
就绪性探测失败并返回 HTTP 状态代码 500
症状
一个或多个 apigee-runtime Pod 未处于“就绪”状态。
错误消息
使用 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 ...
可能的原因
该错误表示消息处理器没有可用于处理流量的活跃合同。在此状态下，消息处理器无法自称“就绪”。
| 原因 | 说明 |
|---|---|
| 同步器到管理平面连接问题 | 同步器无法连接到管理平面。如果您替换 contractProvider 网址并将错误的服务账号与之关联，通常会导致此问题。例如，如果您使用指向生产服务器的 contractProvider 网址为暂存部署配置服务账号。 |
| 消息处理器到同步器连接问题 | 如果新的 MP 在自动扩缩或 Pod 重启中启动，您可能会看到此错误。通常，当同步器出现错误且 MP 无法加载合同时，便会出现此问题。 |
诊断：同步器到管理平面连接问题
如需诊断同步器到管理平面连接问题，请执行以下操作：
- 列出集群中的 Pod：
kubectl get pods -n namespace
- 在
apigee-synchronizerPod 中打开一个 shell：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 shell。
解决方法
如果缺少 version.properties，或者如上所述存在版本不匹配，请检查同步器日志，以尝试确定未下载最新合同的原因。例如：
kubectl logs -f -n namespace synchronizer-pod-name
如需了解如何解释同步器日志，请参阅同步器日志。如果同步器出现故障，请尝试使用 apigeectl 将其重启。例如：
$APIGEECTL_HOME/apigeectl apply -f overrides/overrides.yaml -c 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 无法加载合同，因此会出现此错误。通常，当同步器出现故障时，就会出现此问题，从而阻止 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 -c synchronizer
加密密钥无效的就绪性探测失败
症状
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 代理
在某些情况下，为帮助隔离问题，您可能需要检查能否直接从 apigee-runtime Pod 进行 API 代理调用，从而绕过入站流量网关。
- 执行以下命令，转发到端口 8843。这样您就可以在 Pod 中调用 API：
kubectl port-forward -n namespace apigee-runtime-pod-name 8843:8843
- 调用已部署的 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 是否正常运行。
- 获取集群中 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”环境中已部署代理的信息：
[ { "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-runtimePod 进行调试。 - 为该 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 模式。