500 内部服务器错误 - 已启用流式传输

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

问题

客户端应用收到 HTTP 响应状态代码 500， 用于 API 调用的 Internal Server Error 消息。

错误消息

客户端应用可能会收到如下所示的错误响应： 

HTTP/1.1 500 Internal Server Error

然后，系统可能会显示类似如下的错误消息： 

{
   "fault":{
      "faultstring":"Expecting } at line 1"
      "detail":{
         "errorcode":"Internal Server Error"
      }
   }
}

OR

{
   "fault":{
      "faultstring":"Expecting ] at line 1"
      "detail":{
         "errorcode":"Internal Server Error"
      }
   }
}

可能的原因

许多不同的原因都可能导致 500 内部服务器错误。本指南 重点介绍因访问请求/响应而导致的 500 内部服务器错误。 流式传输时产生的负载 已启用。

原因 说明 谁可以执行问题排查步骤
使用 已启用流式传输 由于在启用流式传输时访问了请求/响应载荷，因此发生错误。 Edge Private 和 Public Cloud 用户

原因：在启用流式处理的情况下访问载荷

诊断

步骤 1：使用 Trace

  1. 启用跟踪 会话，然后进行 API 调用以重现此问题 -“500 Internal Server Error”。
  2. 选择其中一个失败请求并检查跟踪记录。
  3. 浏览跟踪记录的各个阶段，并找到失败的位置。
  4. 政策解析请求/响应载荷时可能会发生此错误。
  5. 下面是一个跟踪屏幕截图示例，其中显示了 JSONThreatProtection 政策 失败，并显示错误 "Expecting } at line 1"：

    alt_text

    记下轨迹输出中的以下信息，如上图所示 屏幕截图：

    失败政策 ：JSONThreatProtection

    流：代理请求

  6. 检查失败的政策定义并检查正在解析的载荷。

    在示例场景中，检查名为 JSON-Threat-Protection 失败，并检查 <Source> 元素。 

    <JSONThreatProtection async="false" continueOnError="false" enabled="true" name="JSON-Threat-Protection">
   <DisplayName>JSON Threat Protection</DisplayName>
   <ArrayElementCount>20</ArrayElementCount>
   <ContainerDepth>10</ContainerDepth>
   <ObjectEntryCount>15</ObjectEntryCount>
   <ObjectEntryNameLength>50</ObjectEntryNameLength>
   <Source>request</Source>
   <StringValueLength>1000</StringValueLength>
</JSONThreatProtection>

    请注意，<Source> 元素指向 request.。这意味着， 解析请求载荷时出错。

  7. 通过检查 API 请求确定要解析的载荷类型。

    8. 您可以在以下位置查看请求载荷的内容和 Content-Type 标头： API 请求。以下示例 curl 命令中使用了 JSON 载荷。 

    curl -i https://VIRTUAL_HOST_ALIAS/BASEPATH -H "Content-Type: application/json" \
-X POST -d @request-payload.json

    您还可以检查失败的政策并确定有效负载的类型 已解析。在上面的示例场景中，JSON-Threat-Protection 政策失败了。 这表示载荷必须采用 JSON 格式。

  8. 验证载荷的格式是否正确。如果载荷无效，则会出现此错误。

  9. 如果载荷有效，但您仍遇到 错误消息部分，然后指明这些错误的原因 那就是启用流式传输时，系统正在访问载荷。

    根据政策解析的载荷（在第 6 步中确定）， 在 Trace 工具的适当阶段检查载荷内容。

    在示例场景中，系统会解析请求载荷，因此请检查 跟踪记录中的“Request Received from Client”阶段并检查 请求内容

    alt_text

    如果系统发现请求内容为空（如上方屏幕截图所示），即使 如果您发送了有效负载，则表示此问题的可能原因是 请求流式传输。

    这是因为启用流式传输后，请求载荷将不会显示在跟踪记录中。

    同样，如果在错误发生时解析响应有效负载，则检查 响应从目标服务器收到阶段返回响应内容。

  10. 接下来，根据出现故障的位置，检查代理和目标端点的定义 政策。验证是否已启用直播。

    在示例场景中，失败政策是在代理请求流中执行的 （如上述第 5 步中所确定）；因此，请检查代理端点： 

    <ProxyEndpoint name="default">
...
  <HTTPProxyConnection>
    <BasePath>/v1/weather</BasePath>
    <VirtualHost>secure</VirtualHost>
    <Properties>
      <Property name="response.streaming.enabled">true</Property>
      <Property name="request.streaming.enabled">true</Property>
    </Properties>
  </HTTPProxyConnection>
</ProxyEndpoint>

    如上例所示，请求流式传输已启用，如 属性 "request.streaming.enabled" 设置为 true。

    因此，错误原因是使用了 API 代理中的 JSONThreatProtection 政策 在启用流式传输时访问请求有效负载的方法。这会导致错误，因为它 在 API 代理中触发缓冲，违反在 Apigee Edge 中使用流式传输的目的。

    如果载荷较小，系统可能不会显示此错误，但使用较大的载荷时， 您可以看到这些错误。

  11. 您可以通过检查相应值，验证 500 错误是否由政策导致 &quot;X-Apigee-fault-source&quot; 的部分 （记录的 Google Analytics 数据）按照下面给出的步骤在跟踪记录中所处的阶段： <ph type="x-smartling-placeholder">
      </ph>
    1. 点击 "AX" (Analytics Data Recorded) 阶段 如以下屏幕截图所示：

      alt_text

    2. 在“阶段详情”部分中，向下滚动至错误标头版块和 确定 “X-Apigee-fault-code”的值， &quot;X-Apigee-fault-source&quot;和 “X-Apigee-fault-policy”如下所示：

      alt_text

    3. 如果 &quot;X-Apigee-fault-source&quot; 的值为 “policy”，如下所示 如上图所示，则表示该错误是由于对 负载。

分辨率

在启用流式传输的情况下访问载荷属于反模式，如 反模式：在启用流式传输后访问请求/响应载荷。

  1. 如果您要处理此载荷，则需要在代理/目标中停用流式传输 通过移除 "request.streaming.enabled" and "response.streaming.enabled" 属性来移除端点，如以下 ProxyEndpoint 示例所示： 
    <ProxyEndpoint name="default">
...
  <HTTPProxyConnection>
    <BasePath>/v1/weather</BasePath>
    <VirtualHost>secure</VirtualHost>
  </HTTPProxyConnection>
</ProxyEndpoint>

    或者

  2. 如果您想为 API 代理使用流式传输，请勿在 访问请求/响应载荷的 API 代理。

注意：

  • 在本 playbook 中，JSONThreatProtection 政策用于通过如下方法处理请求载荷： 启用流式传输这会导致 500 内部服务器错误及不同错误。
  • JSONToXML 和 XMLToJSON 等政策也能够处理 请求或响应载荷。
  • 我们强烈建议不要在需要访问 启用流式传输时有效负载。
  • 这样做是一种反模式，如 反模式：在启用流式传输后访问请求/响应载荷。

使用 API 监控来诊断问题

如果您是 Private Cloud 用户，请跳过此步骤。

借助 API 监控，您可以快速隔离问题区域，以诊断错误、性能和延迟问题及其来源，例如开发者应用、API 代理、后端目标或 API 平台。

逐步执行示例场景，了解如何使用 API 监控来排查 API 的 5xx 问题。例如，您可能想要设置提醒，以便在 500 个错误的数量超出特定阈值时收到通知。

如果您希望在政策抛出 500 错误响应时收到通知，则需要设置 500 状态代码提醒，并将故障来源设为代理。

必须收集的诊断信息

如果按照上述说明操作后问题仍然存在，请收集以下诊断信息。请与 Apigee 支持团队联系并分享他们。

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

  • 组织名称
  • 环境名称
  • API 代理名称
  • 完成 curl 命令和请求负载（如果有），以重现 500 错误
  • 包含发生 500 Internal Server Error 的请求的跟踪文件
  • 如果目前未发生 500 错误，则提供过去出现 500 错误时的时区信息。

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

  • 观察到失败请求的完整错误消息
  • 您观察到 500 错误的组织、环境名称和 API 代理名称
  • API 代理软件包
  • 请求中使用的载荷（如果有）
  • 包含发生 500 Internal Server Error 的请求的跟踪文件
  • NGINX 访问日志 (/opt/apigee/var/log/edge-router/nginx/ <org>~ <env>.<port#>_access_log)
  • 消息处理器日志 (/opt/apigee/var/log/edge-message-processor/logs/system.log)
  • 发生 500 错误时包含时区信息的时间段。