Google 会使用 AI 技术将内容翻译成您偏好的语言。AI 翻译可能包含错误。

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

您正在查看 Apigee Edge 文档。
前往 Apigee X 文档。信息

问题

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

错误消息

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

可能的原因

下表显示了 Edge 界面轨迹中无法捕获 API 请求的可能原因：

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

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

诊断

如需在跟踪会话中捕获 API 请求，该 API 请求必须由 Edge 的组件消息处理器进行处理。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 路由器处失败

原因

在这种情况下，错误可能是由 TLS/SSL 握手失败引起的。如果出现这种情况，您可能会看到以下某条错误消息：
```
Received fatal alert: handshake_failure
```
```
HTTP/1.1 400 Bad Request
```
您可能还会看到 SSL 证书错误。
分辨率

请参阅以下剧本，排查并解决这些问题：

TLS/SSL 握手失败

400 Bad Request - SSL Certificate Error

情形 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"
    }
  }
}

分辨率

请参阅此 playbook 以排查和解决此问题：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