499 客户端关闭连接

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

问题

客户端应用收到 API 请求的超时错误，或者当 API 请求仍在 Apigee 上执行时，请求突然终止。

您将在 API Monitoring 和 NGINX Access 日志中观察此类 API 请求的状态代码 499。有时，您会在 API Analytics 中看到不同的状态代码，因为它显示了消息处理器返回的状态代码。

错误消息

客户端应用可能会遇到如下错误： 

curl: (28) Operation timed out after 6001 milliseconds with 0 out of -1 bytes received

导致客户端超时的原因是什么？

在边缘平台上，API 请求的典型路径是客户端 > 路由器 > 消息处理器 > 后端服务器，如下图所示：

Apigee Edge 平台中的路由器和消息处理器都设置了合适的默认超时值，以确保 API 请求不会花费太长时间才能完成。

客户端超时

您可以根据需要为客户端应用配置合适的超时值。

网络浏览器和移动应用等客户端具有由操作系统定义的超时时间。

路由器超时

路由器上配置的默认超时时间为 57 秒。这是从在 Edge 上收到 API 请求到响应发回时，API 代理可以执行的最长时间，包括后端响应和被执行的所有政策。您可以替换路由器和虚拟主机上的默认超时值，如 在路由器上配置 I/O 超时中所述。

消息处理器超时

消息处理器上配置的默认超时时间为 55 秒。这是后端服务器处理请求并响应消息处理器所用的最长时间。您可以在消息处理器或 API 代理中替换默认超时设置，如 在消息处理器上配置 I/O 超时中所述。

如果客户端在 API 代理超时之前关闭了与路由器的连接，您会观察到特定 API 请求的超时错误。对于此类请求，路由器会记录状态代码 499 Client Closed Connection，您可以在 API Monitoring 和 NGINX 访问日志中观察到此状态代码。

可能的原因

在 Edge 中，导致 499 Client Closed Connection 错误的典型原因如下：

原因 说明 适用的问题排查说明
客户端突然关闭了连接 如果客户端由于最终用户在请求完成前取消了请求而关闭连接，就会发生这种情况。 公有云和私有云用户
客户端应用超时 如果客户端应用在 API 代理没有时间处理和发送响应之前超时，就会发生这种情况。当客户端超时时间小于路由器超时时间时，通常就会发生这种情况。 公有云和私有云用户

常见诊断步骤

使用以下工具/技巧之一来诊断此错误：

  • API 监控
  • NGINX 访问日志

API 监控

要使用 API Monitoring 诊断错误，请执行以下操作：

  1. 前往 Analyze > API Monitoring > Investigate 页面。
  2. 过滤出 4xx 个错误，然后选择时间范围。
  3. 根据时间绘制状态代码。
  4. 选择一个存在 499 个错误的单元格，如下所示：

  5. 您会在右侧窗格中看到有关 499 错误的信息，如下所示：

  6. 在右侧窗格中，点击查看日志。

    在流量日志窗口中，请注意某些 499 错误的以下详细信息：

    • 请求：此属性提供用于进行调用的请求方法和 URI
    • 响应时间：此字段提供请求所用的总时间。

    您还可以使用 API Monitoring GET Logs API 来获取所有日志。例如，通过查询 org、env、timeRange 和 status 的日志，您可以下载客户端超时的事务的所有日志。

    由于 API Monitoring 会针对 HTTP 499 错误将代理设置为 -，因此您可以使用 API (Logs API) 获取虚拟主机和路径的关联代理。

    例如： 

    curl "https://apimonitoring.enterprise.apigee.com/logs/apiproxies?org=ORG&env=ENV&select=https://VIRTUAL_HOST/BASEBATH" -H "Authorization: Bearer $TOKEN"
  7. 查看其他 499 错误的响应时间，并检查所有 499 错误的响应时间是否一致（假设为 30 秒）。

NGINX 访问日志

如需使用 NGINX 访问日志诊断错误，请执行以下操作：

  1. 如果您是 Private Cloud 用户，则可以使用 NGINX 访问日志来确定有关 HTTP 499 错误的关键信息。
  2. 查看 NGINX 访问日志：
    /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log
  3. 搜索以查看在特定时间段内是否存在任何 499 错误（如果问题是在过去发生的），或者是否有任何请求仍然失败并显示 499。
  4. 请注意部分 499 错误的以下信息：
    • 总响应时间
    • Request URI
    • 用户代理

    NGINX 访问日志中的 499 错误示例：

    2019-08-23T06:50:07+00:00       rrt-03f69eb1091c4a886-c-sy      50.112.119.65:47756
10.10.53.154:8443       10.001  -       -       499     -       422     0
   GET /v1/products HTTP/1.1        -       okhttp/3.9.1    api.acme.org
rrt-03f69eb1091c4a886-c-sy-13001-6496714-1
    50.112.119.65   -       -       -       -       -       -       -       -1      -       -       dc-1  router-pod-1
rt-214-190301-0020137-latest-7d
36       TLSv1.2 gateway-1     dc-1  acme    prod  https   -

    对于此示例，我们会看到以下信息：

    • 总响应时间：10.001 秒。这表示客户端在 10.001 秒后超时
    • 请求： GET /v1/products
    • 主机：api.acme.org
    • 用户代理：okhttp/3.9.1
  5. 检查所有 499 错误中的总响应时间和用户代理是否一致。

原因：客户端突然关闭了连接

诊断

  1. 从浏览器或移动应用中运行的单页应用调用 API 时，如果最终用户突然关闭浏览器、前往同一标签页中的另一个网页，或者通过点击或点按 停止加载来停止加载页面，浏览器将中止请求。
  2. 如果发生这种情况，具有 HTTP 499 状态的事务通常在每个请求的请求处理时间（响应时间）上有所不同。
  3. 您可以比较响应时间，并使用 API Monitoring 或 NGINX Access 日志验证每个 499 错误的时间是否不同，以确定是否是这个原因，如常见诊断步骤中所述。

分辨率

  1. 这是正常现象，如果发生少量 HTTP 499 错误，通常无需担心。

  2. 如果同一网址路径经常发生这种情况，可能是因为与该路径关联的特定代理速度非常慢，用户不愿意等待。

    知道哪个代理可能会受到影响后，请使用延迟时间分析信息中心进一步调查导致代理延迟的原因。

    1. 在这种情况下，请按照常见诊断步骤中的步骤确定受影响的代理。
    2. 使用 延迟时间分析信息中心进一步调查导致代理延迟的原因并解决问题。
    3. 如果您发现特定代理出现延迟，则可能需要告知用户此代理将需要一些时间才能做出响应。

原因：客户端应用超时

这种情况在很多情况下都可能发生。

  1. 在正常的操作条件下，请求预计需要一定时间（如 10 秒）才能完成。不过，客户端应用设置的超时值不正确（假设为 5 秒），这会导致客户端应用在 API 请求完成之前超时，从而导致 499。在这种情况下，我们需要将客户端超时设置为适当的值。
  2. 目标服务器或调用程序的用时超出了预期。在这种情况下，您需要修复相应的组件并适当调整超时值。
  3. 客户端不再需要响应，因此已中止。对于自动填充功能或短轮询等高频率 API，可能会发生这种情况。

诊断

API Monitoring 或 NGINX 访问日志

使用 API Monitoring 或 NGINX 访问日志诊断错误：

  1. 按照常见诊断步骤中的说明，查看 HTTP 499 事务的 API Monitoring 日志或 NGINX 访问日志。
  2. 确定所有 499 错误的响应时间是否一致。
  3. 如果是，则可能是因为特定客户端应用在其端配置了固定的超时。如果 API 代理或目标服务器响应缓慢，客户端会在代理超时之前超时，从而导致相同 URI 路径出现大量 HTTP 499s。在这种情况下，请从 NGINX 访问日志中确定用户代理，这可以帮助您确定具体的客户端应用。
  4. Apigee 前面也可能有一个负载平衡器，例如 Akamai、F5、AWS ELB 等。如果 Apigee 在自定义负载平衡器后面运行，则必须将负载平衡器的请求超时配置为大于 Apigee API 超时。默认情况下，Apigee Router 会在 57 秒后超时，因此适合在负载平衡器上配置 60 秒的请求超时。

跟踪记录

使用 Trace 诊断错误

如果问题仍然存在（499 错误仍然存在），请执行以下步骤：

  1. 在 Edge 界面中为受影响的 API 启用跟踪会话。
  2. 您可以等待错误发生，或者进行 API 调用，然后进行一些 API 调用并重现错误。
  3. 检查每个阶段所用的时间，并记下大部分时间花在哪个阶段。
  4. 如果您在以下某个阶段之后立即观察到用时最长的错误，则表示后端服务器速度缓慢或处理请求需要很长时间：
    • 请求已发送到目标服务器
    • ServiceCallout 政策

    下面是一个示例界面跟踪记录，显示了请求发送到目标服务器后出现的网关超时：

分辨率

  1. 请参阅 配置 I/O 超时的最佳做法，了解在 Apigee Edge 的 API 请求流程中涉及的不同组件上应该设置哪些超时值。
  2. 请确保根据最佳实践在客户端应用上设置适当的超时值。

如果问题仍然存在，请参阅必须收集诊断信息。

必须收集的诊断信息

如果问题仍然存在，请收集以下诊断信息，然后与 Apigee Edge 支持团队联系。

如果您是公有云用户，请提供以下信息：

  • 组织名称
  • 环境名称
  • API 代理名称
  • 完成用于重现超时错误的 curl 命令
  • 您看到客户端超时错误的 API 请求的跟踪文件

如果您是 Private Cloud 用户，请提供以下信息：

  • 观察到失败请求的完整错误消息
  • 环境名称
  • API 代理软件包
  • 您看到客户端超时错误的 API 请求的跟踪文件
  • NGINX 访问日志 (/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log)
  • 消息处理器系统日志 (/opt/apigee/var/log/edge-message-processor/logs/system.log)