此页面由 Cloud Translation API 翻译。

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

<ph type="x-smartling-placeholder"></ph> 您正在查看 Apigee Edge 文档。
转到 Apigee X 文档。信息

问题

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

错误消息

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

可能的原因

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

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

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

诊断

如需在 Trace 会话中捕获 API 请求，必须由 Edge 的组件消息处理器处理该 API 请求。在 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 Bad Request - SSL 证书错误

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

原因

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

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 界面的 Trace 会话中。

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

登录到每个消息处理器，并使用以下命令检查请求 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