您正在查看 Apigee Edge 文档。
前往 Apigee X 文档。 信息
问题
客户端应用收到 HTTP 状态代码 504，并收到消息 Gateway Timeout 作为 API 调用的响应。
HTTP 状态代码 - 504 Gateway Timeout 错误表示客户端在执行 API 期间未及时收到来自 Edge 网关或后端服务器的响应
错误消息
客户端应用会收到以下响应代码：
HTTP/1.1 504 Gateway Timeout
在某些情况下，您可能还会看到以下错误消息：
{
"fault": {
"faultstring": "Gateway Timeout",
"detail": {
"errorcode": "messaging.adaptors.http.flow.GatewayTimeout"
}
}
}什么原因会导致网关超时？
通过 Edge 平台发送 API 请求的典型路径为客户端 -> 路由器 -> 消息处理器 -> 后端服务器，如下图所示：
Edge 平台中的客户端应用、路由器和消息处理器都设置了合适的超时值。Edge 平台会根据超时值，预期在一定时间内针对每个 API 请求发送响应。如果您未在指定的时间段内收到响应，则会返回 504 Gateway Timeout Error。
下表详细介绍了 Edge 中可能会发生超时的情况：
| 超时发生 | 详细信息 |
|---|---|
| 消息处理器上发生超时 |
|
| 路由器上发生超时 |
|
| 客户端应用发生超时 |
|
可能的原因
在 Edge 中，504 Gateway Timeout 错误的典型原因如下：
| 原因 | 详细信息 | 针对以下情况提供的步骤 |
|---|---|---|
| 后端服务器速度缓慢 | 处理 API 请求的后端服务器因负载过高或性能不佳而运行缓慢。 | 公共云和私有云用户 |
| Edge 处理 API 请求的速度较慢 | 由于高负载或性能不佳，Edge 需要很长时间才能处理 API 请求。 |
后端服务器速度缓慢
如果后端服务器速度非常慢或需要很长时间才能处理 API 请求，您将收到 504 Gateway Timeout 错误。如上文所述，超时可能发生在以下任一情况下：
- 消息处理器在后端服务器响应之前超时。
- 路由器在消息处理器/后端服务器响应之前超时。
- 客户端应用在路由器/消息处理器/后端服务器响应之前超时。
以下部分介绍了如何在每种情况下诊断和解决问题。
场景 1 消息处理器在后端服务器响应之前超时
诊断
您可以使用以下程序来诊断 504 Gateway Timeout 错误是否因后端服务器速度缓慢而发生。
程序 1：使用 Trace
如果问题仍然存在（仍出现 504 错误），请按以下步骤操作：
- 在 Edge 界面中跟踪受影响的 API。您可以等待错误发生，也可以在有 API 调用的情况下，进行一些 API 调用，重现
504 Gateway Timeout错误。 - 发生错误后，检查显示响应代码为
504的具体请求。 - 检查每个阶段的耗时，并记下花费时间最多的阶段。
- 如果您在以下某个阶段之后立即发现耗时最长的错误，则表示后端服务器速度较慢或处理请求的时间较长：
- 已向目标服务器发送请求
- ServiceCallout 政策
以下示例 Trace 显示，即使在 55 秒后，后端服务器仍未响应，从而导致 504 Gateway Timeout 错误：
在上述跟踪记录中，由于后端服务器未响应，消息处理器在 55002 毫秒后超时。
方法 2：使用消息处理器日志
- 检查消息处理器的日志 (
/opt/apigee/var/log/edge-message-processor/logs/system.log) -
如果您在特定时间发现特定 API 代理请求存在
Gateway Timeout和onTimeoutRead错误，则表示消息处理器已超时。显示网关超时错误的消息处理器日志示例
2015-09-29 20:16:54,340 org:myorg env:staging api:profiles rev:13 NIOThread@1 ERROR ADAPTORS.HTTP.FLOW - AbstractResponseListener.onException() : AbstractResponseListener.onError(HTTPResponse@4d898cf1, Gateway Timeout) 2015-09-29 20:16:57,361 org:myorg env:staging api:profileNewsletters rev:8 NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context$3.onTimeout() : SSLClientChannel[C:XX.XX.XX.XX:443 Remote host:192.168.38.54:38302]@120171 useCount=2 bytesRead=0 bytesWritten=824 age=55458ms lastIO=55000ms .onTimeoutRead
在上述消息处理器日志中，您会注意到，IP 地址为 XX.XX.XX.XX 的后端服务器在 55 秒后（lastIO=55000ms）仍未响应。因此，消息处理器超时并发送了
504 Gateway Timeout错误。请查看以下内容：如何在消息处理器上控制超时？
- 如何控制消息处理器的超时时间。消息处理器通常通过属性
HTTPTransport.io.timeout.millis设置为 55 秒的默认超时值。此超时值适用于由相应消息处理器处理的组织中的所有 API 代理。- 如果后端服务器未在 55 秒内响应，消息处理器会超时并向客户端发送
504 Gateway Timeout错误。
- 如果后端服务器未在 55 秒内响应，消息处理器会超时并向客户端发送
- 消息处理器中指定的超时值可被 API 代理中指定的属性
io.timeout.millis替换。此超时值适用于指定了上述属性的特定 API 代理。例如，如果 API 代理中的io.timeout.millis设置为 10 秒，则此特定 API 代理将使用 10 秒的超时值。- 如果后端服务器在特定 API 代理的 10 秒内未做出响应，消息处理器会超时并向客户端发送
504 Gateway Timeout错误。
- 如果后端服务器在特定 API 代理的 10 秒内未做出响应，消息处理器会超时并向客户端发送
- 如何控制消息处理器的超时时间。消息处理器通常通过属性
分辨率
- 检查后端服务器为何需要超过 55 秒，看看是否可以修复/优化它以更快地响应。
- 如果无法修复/优化后端服务器，或者已知后端服务器所用时间长于配置的超时时间，则 增加路由器和消息处理器的超时值，使其达到合适的值。
场景 2 - 路由器在消息处理器/后端服务器响应之前超时
如果路由器在消息处理器/后端服务器响应之前超时，您可能会收到 504 Gateway Timeout 错误。在以下情况下可能会发生这种情况：
- 在路由器上设置的超时值短于在消息处理器上设置的超时值。例如，假设路由器的超时时间为 50 秒，而消息处理器的超时时间为 55 秒。
路由器超时 消息处理器超时 50 秒 55 秒 - 使用 API 代理的目标端点配置中设置的
io.timeout.millis属性，以更高的超时值替换消息处理器的超时值：例如，如果设置了以下超时值：
路由器超时 消息处理器超时 API 代理中的超时 57 秒 55 秒 120 秒 但 API 代理中的
io.timeout.millis设置为 120 秒：<HTTPTargetConnection> <Properties> <Property name="io.timeout.millis">120000</Property> </Properties> <URL>http://www.apigee.com</URL> </HTTPTargetConnection>这样一来，即使消息处理器的超时值（55 秒）小于路由器的超时值（57 秒），消息处理器也不会在 55 秒后超时。这是因为消息处理器上的 55 秒超时值被 API 代理中设置的 120 秒值所替换。因此，此特定 API 代理的消息处理器的超时值将为 120 秒。
由于路由器的超时值 (57 秒) 低于 API 代理中设置的 120 秒，因此如果后端服务器在 57 秒后未做出响应，路由器将超时。
诊断
- 检查 NGINX 访问日志 (
/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log) -
如果路由器在消息处理器之前超时，您将在特定 API 请求的 NGINX 访问日志中看到
504状态，并且消息处理器的message id将设置为-。这是因为路由器未在路由器上设置的超时时限内收到消息处理器的任何响应。显示因路由器超时而导致 504 错误的 NGINX 日志条目示例
- 在上面的示例中，请注意 NGINX 上
504的状态，来自消息处理器的消息 ID 为-，总耗时为 57.001 秒。这是因为路由器在 57.001 秒后超时，并且我们没有收到来自消息处理器的任何响应。 - 在这种情况下，您会
Broken Pipe在消息 处理器日志 (/opt/apigee/var/log/edge-message-processor/logs/system.log).2017-06-09 00:00:25,886 org:myorg env:test api:myapi-v1 rev:23 messageid:rrt-mp01-18869-23151-1 NIOThread@1 INFO HTTP.SERVICE - ExceptionHandler.handleException() : Exception java.io.IOException: Broken pipe occurred while writing to channel ClientOutputChannel(ClientChannel[A:XX.XX.XX.XX:8998 Remote host:YY.YY.YY.YY:51400]@23751 useCount=1 bytesRead=0 bytesWritten=486 age=330465ms lastIO=0ms ) 2017-06-09 00:00:25,887 org:myorg env:test api:myapi-v1 rev:23 messageid:rrt-mp01-18869-23151-1 NIOThread@1 INFO HTTP.SERVICE - ExceptionHandler.handleException() : Exception trace: java.io.IOException: Broken pipe at com.apigee.nio.channels.ClientOutputChannel.writePending(ClientOutputChannel.java:51) ~[nio-1.0.0.jar:na] at com.apigee.nio.channels.OutputChannel.onWrite(OutputChannel.java:116) ~[nio-1.0.0.jar:na] at com.apigee.nio.channels.OutputChannel.write(OutputChannel.java:81) ~[nio-1.0.0.jar:na] … <snipped>
之所以显示此错误，是因为路由器一旦超时，就会关闭与消息处理器的连接。当消息处理器完成处理后，它会尝试将响应写入路由器。由于与路由器的连接已关闭，因此您会在消息处理器上收到 Broken Pipe exception。
在上述情况下，预计会看到此异常。因此，504 Gateway Timeout 错误的实际原因是后端服务器的响应时间过长，您需要解决该问题。
分辨率
- 如果是自定义后端服务器，则
- 检查后端服务器响应时间较长的原因，看看是否可以修复/优化以加快响应速度。
- 如果无法修复/优化后端服务器，或者已知后端服务器需要很长时间才能完成操作，请增加路由器和消息处理器的超时值。
建议：按以下顺序在不同组件上设置超时值：
客户端超时 > 路由器超时 > 消息处理器超时 > API 代理中的超时
- 如果是 NodeJS 后端服务器，则：
- 检查 NodeJS 代码是否会调用任何其他后端服务器，以及是否需要很长时间才能返回响应。检查后端服务器运行时间较长的原因，并根据需要解决问题。
- 检查消息处理器是否出现 CPU 或内存用量偏高的情况：
- 如果任何消息处理器的 CPU 使用率过高，请使用以下命令每 30 秒生成三个线程转储：
JAVA_HOME/bin/jstack -l PID > FILENAME
- 如果任何消息处理器出现内存用量过高的情况，请使用以下命令生成 heap dump：
sudo -u apigee JAVA_HOME/bin/jmap -dump:live,format=b,file=FILENAME PID
- 使用以下命令重启消息处理器。这应该会降低 CPU 和内存用量：
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
- 监控 API 调用，以确认问题是否仍然存在。
- 请与 Apigee Edge 支持团队联系，并提供线程转储、堆转储和消息处理器日志 (
/opt/apigee/var/log/edge-message-processor/logs/system.log))，以便我们调查 CPU/内存用量过高的原因。
- 如果任何消息处理器的 CPU 使用率过高，请使用以下命令每 30 秒生成三个线程转储：
检查此项：消息处理器上 NodeJS 后端服务器的超时时间是如何控制的
|
场景 3 - 客户端应用在路由器/消息处理器/后端服务器响应之前超时
如果客户端应用在后端服务器响应之前超时，您可能会收到 504 Gateway Timeout 错误。如果出现以下情况，则可能会发生上述情况：
- 客户端应用上设置的超时值低于路由器和消息处理器上设置的超时值：
例如，如果设置了以下超时值：
客户端超时 路由器超时 消息处理器超时 50 秒 57 秒 55 秒 在这种情况下，通过 Edge 获取 API 请求响应的总时间不得超过 50 秒。这包括发出 API 请求所用的时间、Edge（路由器、消息处理器）处理请求所用的时间、将请求发送到后端服务器（如果适用）所用的时间、后端处理请求并发送响应所用的时间、Edge 处理响应所用的时间，以及最终将响应发送回客户端所用的时间。
如果路由器在 50 秒内未响应客户端，则客户端将超时并关闭与路由器的连接。客户端将收到
504的响应代码。这会导致 NGINX 设置状态代码
499，表明客户端关闭了连接。
诊断
- 如果客户端应用在收到路由器响应之前超时，则会关闭与路由器的连接。在这种情况下，您会在特定 API 请求的 NGINX 访问日志中看到状态代码 499。
显示状态代码 499 的 NGINX 日志条目示例
- 在上面的示例中，请注意 NGINX 上
499的状态和总耗时为 50.001 秒。这表示客户端在 50.001 秒后超时。 - 在这种情况下，您会在
Broken Pipe消息处理器日志 (/opt/apigee/var/log/edge-message-processor/logs/system.log).
2017-06-09 00:00:25,886 org:myorg env:test api:myapi-v1 rev:23 messageid:rrt-1-11193-11467656-1 NIOThread@1 INFO HTTP.SERVICE - ExceptionHandler.handleException() : Exception java.io.IOException: Broken pipe occurred while writing to channel ClientOutputChannel(ClientChannel[A:XX.XX.XX.XX:8998 Remote host:YY.YY.YY.YY:51400]@23751 useCount=1 bytesRead=0 bytesWritten=486 age=330465ms lastIO=0ms ) 2017-06-09 00:00:25,887 org:myorg env:test api:myapi-v1 rev:23 messageid:rrt-1-11193-11467656-1 NIOThread@1 INFO HTTP.SERVICE - ExceptionHandler.handleException() : Exception trace: java.io.IOException: Broken pipe at com.apigee.nio.channels.ClientOutputChannel.writePending(ClientOutputChannel.java:51) ~[nio-1.0.0.jar:na] at com.apigee.nio.channels.OutputChannel.onWrite(OutputChannel.java:116) ~[nio-1.0.0.jar:na] at com.apigee.nio.channels.OutputChannel.write(OutputChannel.java:81) ~[nio-1.0.0.jar:na] … <snipped>
- 路由器超时后，会关闭与消息处理器的连接。当消息处理器完成处理后，会尝试将响应写入路由器。由于与路由器的连接已关闭，因此您会在消息处理器上收到
Broken Pipe exception。 - 在上述情况下，出现此异常是预期行为。因此，
504 Gateway Timeout错误的实际原因仍然是后端服务器的响应时间过长，您需要解决该问题。
分辨率
- 如果是您的自定义后端服务器，请执行以下操作：
- 检查后端服务器，确定其耗时超过 57 秒的原因，并查看是否可以修复/优化该服务器以加快响应速度。
- 如果无法修复/优化后端服务器，或者您知道后端服务器需要很长时间才能完成操作，请增加路由器和消息处理器的超时值。
建议：按以下顺序在不同组件上设置超时值：
客户端超时 > 路由器超时 > 消息处理器超时 > API 代理中的超时
- 如果是 NodeJS 后端，则：
- 检查 NodeJS 代码是否会调用任何其他后端服务器，以及这些调用是否需要很长时间才能返回。检查这些后端服务器耗时较长的原因。
- 检查消息处理器的 CPU 或内存用量是否偏高：
- 如果消息处理器的 CPU 使用率过高，请使用以下命令每 30 秒生成三个线程转储：
JAVA_HOME/bin/jstack -l PID > FILENAME
- 如果消息处理器的内存用量过高，请使用以下命令生成 堆转储：
sudo -u apigee JAVA_HOME/bin/jmap -dump:live,format=b,file=FILENAME PID
- 使用以下命令重启消息处理器。这应该会降低 CPU 和内存使用量：
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
- 监控 API 调用，以确认问题是否仍然存在。
- 请与 Apigee Edge 支持团队联系，并提供线程转储、堆转储和消息处理器日志 (
/opt/apigee/var/log/edge-message-processor/logs/system.log))，以便他们调查 CPU/内存用量过高的原因。
- 如果消息处理器的 CPU 使用率过高，请使用以下命令每 30 秒生成三个线程转储：
增加路由器和消息处理器的超时值
请根据您的需求仔细选择要在路由器和消息处理器上设置的超时值。请勿设置任意大的超时值。如果您需要帮助，请与 Apigee Edge 支持团队联系。
路由器
chown apigee:apigee /opt/apigee/customer/application/router.properties
- 在路由器机器上创建
/opt/apigee/customer/application/router.properties文件（如果尚不存在）。 - 将以下代码行添加到此文件中：
conf_load_balancing_load.balancing.driver.proxy.read.timeout=TIME_IN_SECONDS
例如，如果您想将超时值设置为 120 秒，请按如下方式进行设置：
conf_load_balancing_load.balancing.driver.proxy.read.timeout=120
- 确保此文件归 apigee 所有：
- 重启路由器：
/opt/apigee/apigee-service/bin/apigee-service edge-router restart
- 如果您有多个路由器，请在所有路由器上重复执行上述步骤。
消息处理器
- 在消息处理器机器上创建
/opt/apigee/customer/application/message-processor.properties文件（如果尚不存在）。 - 将以下代码行添加到此文件中：
conf_http_HTTPTransport.io.timeout.millis=TIME_IN_MILLISECONDS
例如，如果您想将超时值设置为 120 秒，请按如下方式进行设置：
conf_http_HTTPTransport.io.timeout.millis=120000
- 确保此文件归 apigee 所有：
chown apigee:apigee /opt/apigee/customer/application/message-processor.properties
- 重启消息处理器：
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
- 如果您有多个消息处理器，请在所有消息处理器上重复执行上述步骤。
建议：按以下顺序在不同组件上设置超时值：客户端超时 > 路由器超时 > 消息处理器超时 > API 代理中的超时 |
Edge 处理 API 请求的速度较慢
如果 Edge 非常慢，并且/或者处理 API 请求的时间很长，您会收到 504 Gateway Timeout 错误。
诊断
- 在 Edge 界面中跟踪受影响的 API。
- 您可以等待错误发生，也可以在有 API 调用的情况下进行一些 API 调用，重现
504 Gateway Timeout错误。 - 请注意，在这种情况下，您可能会在轨迹中看到成功响应。
- 由于消息处理器未在路由器/客户端上指定的超时期限内（以超时期限最短的路由器/客户端为准）响应，因此路由器/客户端超时。 不过，消息处理器会继续处理请求，并且可能会成功完成。
- 此外，只有当消息处理器与 HTTP/HTTPS 后端服务器通信时，才会触发在消息处理器上设置的
HTTPTransport.io.timeout.millis值。换句话说，当 API 代理中的任何政策（ServiceCallout 政策除外）耗时过长时，此超时不会触发。
- 发生错误后，检查耗时最长的特定请求。
- 检查每个阶段的耗时，并记下耗时最多的阶段。
- 如果您发现任何政策（服务调用政策除外）中的最长经过时间，则表明 Edge 需要很长时间才能处理请求。
- 以下是一个示例界面轨迹，显示了 JavaScript 政策的极高耗时：
- 在上述示例中，您会发现 JavaScript 政策花费的时间异常长，约为 245 秒。
分辨率
- 检查响应时间过长的政策，以及是否存在可能需要长时间处理的任何自定义代码。如果存在此类代码，请查看是否可以修复/优化已识别的代码。
- 如果没有可能导致处理时间过长的自定义代码，请检查消息处理器是否出现 CPU 或内存用量过高的情况：
- 如果任何消息处理器的 CPU 使用率过高，请使用以下命令每 30 秒生成三个线程转储：
JAVA_HOME/bin/jstack -l PID > FILENAME
- 如果任何消息处理器的内存用量过高，请使用以下命令生成 堆转储：
sudo -u apigee JAVA_HOME/bin/jmap -dump:live,format=b,file=FILENAME PID
- 使用以下命令重启消息处理器。这应该会降低 CPU 和内存使用率。
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
- 监控 API 调用，并确认问题是否仍然存在。
- 请与 Apigee Edge 支持团队联系，并提供线程转储、堆转储和消息处理器日志 (
/opt/apigee/var/log/edge-message-processor/logs/system.log))，以便他们调查 CPU/内存用量过高的原因。
- 如果任何消息处理器的 CPU 使用率过高，请使用以下命令每 30 秒生成三个线程转储：
使用 API Monitoring 诊断问题
借助 API Monitoring，您可以快速找出问题区域，以诊断错误、性能和延迟时间问题及其来源，例如开发者应用、API 代理、后端目标或 API 平台。
逐步了解示例场景，该场景演示了如何使用 API 监控功能排查 API 的 5xx 问题。 例如，您可能希望设置一个提醒，以便在 504 状态代码的数量超过特定阈值时收到通知。