此页面由 Cloud Translation API 翻译。

未在边缘界面中捕获 API 请求

您正在查看的是 Apigee Edge 文档。
转到 Apigee X 文档。信息

问题

下图显示了启动跟踪会话时，Edge 界面中未捕获 API 请求：

错误消息

此问题发生时，Edge 界面中不会显示任何错误消息。

可能的原因

下表显示了在 Edge UI Trace 中捕获 API 请求失败的可能原因：

原因	说明	问题排查说明适用于
消息处理器未处理的请求	API 请求必须由 Edge 的组件消息处理器处理才能捕获跟踪记录。如果 API 请求未能到达 Apigee Edge，则其在 Edge 的入口点（即路由器）失败，那么就无法捕获跟踪记录。	边缘公有云和私有云用户
在分类树中找不到 API 代理	Apigee 消息处理器使用名为“分类树”的路由规则定义，根据传入请求的主机名、基本路径、修订版本和环境来调度请求。如果相关 API 代理因某种原因从分类树中移除，系统可能不会填充跟踪交易。	Edge Private Cloud 用户

原因：消息处理器未处理请求

诊断

如需在跟踪会话中捕获 API 请求，API 请求必须由 Edge 的组件消息处理器进行处理。在 Trace 事务中可能无法捕获 API 请求有多种原因。

例如，如果 API 请求无法到达 Apigee Edge，则会在 Edge 的入口点失败（即路由器）失败，那么就无法捕获跟踪记录。下文将更详细地介绍每种情况。

场景 1：请求未能到达 Apigee Edge

原因

在这种情况下，错误可能是由 DNS 解析或网络连接问题导致的。如果是这样，您在运行此命令时可能会看到以下错误：
```
curl https://hostName:port/apiProxyBasePath/requestPath
```
```
curl: (6) Could not resolve host: hostName
```
分辨率

您可以使用以下命令验证 DNS 配置：
```
dig hostName
```
您可以使用以下命令验证网络连接：
```
telnet hostName port
```

场景 2：请求在 Apigee Edge Router 上失败

原因

在这种情况下，错误可能是由于 TLS/SSL 握手失败所致。如果是这样，您可能会看到以下错误之一：
```
Received fatal alert: handshake_failure
```
```
HTTP/1.1 400 Bad Request
```
您可能还会看到 SSL 证书错误。
分辨率

请参阅以下策略方案，排查并解决这些问题：

TLS/SSL 握手失败

400 请求错误 - SSL 证书错误

场景 3：消息处理器无法处理请求

原因

在这种情况下，Apigee 消息处理器无法找到指定虚拟主机和路径的 API 代理。因此，您可能会看到以下错误之一：

HTTP/1.1 404 Not Found

{
  "fault":{
    "faultstring":"Unable to identify proxy for host: default and url: \/apiProxyBasePath/requestPath",
    "detail":{
      "errorcode":"messaging.adaptors.http.flow.ApplicationNotFound"
    }
  }
}

分辨率

请参阅此手册来排查和解决此问题：404（“无法找到适用于主机的代理”）。

原因：在分类树中找不到 API 代理

诊断

如果消息处理器在其分类树中找不到某个 API 代理，那么向该特定代理发出的任何 API 请求都不会显示在 Edge 界面的跟踪会话中。

请按以下步骤确定是否属于这种情况：

登录每个消息处理器，并使用以下命令检查请求 API 的特定修订版本是否已在消息处理器的相关环境中部署：
```
curl -v http://localhost:8082/v1/runtime/organizations/orgName/environments/envName/apis/apiName/revisions
```
输出示例：

上面的命令将输出已部署的修订版本的列表。例如，如果部署了修订版本 12，您将看到以下输出：
```
[ "12" ]
```
除非您遇到间歇性 HTTP 404 错误，否则您可能会看到已部署特定修订版本。
使用以下命令读取分类树并检查 API 代理名称是否存在：
```
curl -i http://localhost:8082/v1/classification/tree | grep apiName
```
对每个消息处理器重复步骤 1 和 2。如果任何消息处理器的分类树中缺少指定的 API 代理名称，请遵循以下解决方法。

分辨率

请按照以下步骤解决此问题。请务必采取一切必要预防措施，避免在请求负载较高的情况下重启消息处理器，导致生产中断。

登录到分类树中缺少特定 API 代理的每个消息处理器主机，并使用以下命令重启消息处理器：
```
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
```

重启后，使用以下命令等待其变为活动状态：

/opt/apigee/apigee-service/bin/apigee-service edge-message-processor wait_for_ready

消息处理器准备就绪后，使用以下命令验证 API 代理的可用性：
```
curl -v http://localhost:8082/v1/runtime/organizations/orgName/environments/envName/apis/apiName/revisions
```
输出示例：

上面的命令将输出已部署的修订版本的列表。例如，如果部署了修订版本 12，您将看到以下输出：
```
[ "12" ]
```
除非您遇到间歇性 HTTP 404 错误，否则您可能会看到已部署特定修订版本。
使用以下命令读取分类树并验证 API 代理名称是否存在：
```
curl -i http://localhost:8082/v1/classification/tree | grep apiName
```
如果问题仍然存在，请参阅必须收集诊断信息。

必须收集诊断信息

如果在按照上述说明操作后问题仍然存在，请收集以下诊断信息并将其分享给 Apigee Edge 支持团队：

诊断信息类型	命令
跟踪会话命令的输出	curl -v `management-server-host`:8080/v1/runtime/organizations/`orgName`/environments/`envName`/apis/`apiProxyName`/revisions/`revisionNumber`/debugsessions -u `user`
管理服务器日志	/opt/apigee/var/log/edge-management-server/logs/system.log
消息处理器日志	/opt/apigee/var/log/edge-message-processor/logs/system.log
从管理服务器到邮件处理器的 `telnet`/`netcat` 命令输出	telnet `MessageProcessor_IP` 8082 nc -vz `MessageProcessor_IP` 8082
消息处理器上的 netstat 命令的输出	netstat -an > netstat.txt
输出列出为所有消息处理器上特定 API 代理部署的修订版本	curl -v http://localhost:8082/v1/runtime/organizations/`orgName`/environments/`envName`/apis/`apiName`/revisions
所有消息处理器上的分类树输出	curl -i http://localhost:8082/v1/classification/tree