500 內部伺服器錯誤 - 已啟用串流功能

您目前查看的是 Apigee Edge 說明文件。
前往 Apigee X 說明文件。 info

問題

用戶端應用程式會收到 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 私有雲和公有雲使用者

原因：存取已啟用串流的酬載

診斷

程序 1：使用 Trace

  1. 啟用追蹤工作階段，然後發出 API 呼叫來重現問題 - 500 內部伺服器錯誤。
  2. 選取其中一個失敗的要求，然後檢查追蹤記錄。
  3. 瀏覽追蹤記錄的各個階段，找出發生失敗的位置。
  4. 政策剖析要求/回應酬載時，可能發生這項錯誤。
  5. 以下是追蹤記錄的螢幕截圖範例，顯示 JSONThreatProtection 政策 失敗，並出現「Expecting } at line 1」(第 1 行應為「}」) 錯誤：

    alt_text

    如上方的螢幕截圖所示，請記下追蹤輸出內容中的下列資訊：

    不符合規定的政策： JSONThreatProtection

    流程：Proxy 要求

  6. 檢查失敗的政策定義，並查看正在剖析的酬載。

    在範例情境中，請檢查名為「JSON-Threat-Protection」的 JSONThreatProtection 政策，並檢查 <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. 您可以在 API 要求中檢查要求酬載和 Content-Type 標頭的內容。在下列 curl 指令範例中，我們使用 JSON 酬載。 

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

    您也可以檢查失敗的政策，並判斷要剖析的酬載類型。在上述範例情境中，JSON 威脅防護政策失敗。 這表示酬載必須採用 JSON 格式。

  8. 驗證酬載格式是否正確，如果酬載無效，您可能會收到這項錯誤。

  9. 如果酬載有效，但您仍收到「錯誤訊息」一節列出的錯誤，則這些錯誤的原因是酬載在啟用串流時遭到存取。

    根據政策剖析的酬載 (如步驟 6 所判斷)，在適當階段使用追蹤工具檢查酬載內容。

    在範例情境中，系統正在剖析要求酬載，因此請檢查追蹤記錄中的「Request Received from Client」(收到用戶端要求) 階段，並檢查「Request Content」(要求內容)。

    alt_text

    如上圖所示，如果「Request Content」為空白，即使您已傳送有效酬載，也表示問題可能出在已啟用要求串流。

    這是因為啟用串流時，要求酬載不會顯示在追蹤記錄中。

    同樣地，如果發生錯誤時正在剖析回應酬載，請在「Response received from target server」(從目標伺服器收到的回應)階段檢查回應內容。

  10. 接著，請根據 API Proxy 流程中失敗政策的使用位置，檢查 Proxy 和目標端點定義。確認是否已啟用串流功能。

    在範例情境中，失敗的政策是在 Proxy 要求流程中執行 (如上述步驟 5 所判斷)，因此請檢查 Proxy 端點： 

    <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 Proxy 在啟用串流時存取要求酬載，並使用 JSONThreatProtection 政策。這會導致錯誤，因為它會在 API Proxy 中觸發緩衝處理，並破壞在 Apigee Edge 中使用串流的用途。

    如果酬載較小，可能不會看到這項錯誤，但如果酬載較大，就會看到這些錯誤。

  11. 如要確認 500 錯誤是否是由政策所致，請按照下列步驟，在追蹤記錄的「AX」 (記錄的 Analytics 資料) 階段中，檢查"X-Apigee-fault-source"的值：
    1. 點選「AX」(已記錄 Analytics 資料) 階段，如下方螢幕截圖所示：

      alt_text

    2. 向下捲動至「階段詳細資料」的「錯誤標頭」部分 ，然後判斷「X-Apigee-fault-code」、 「X-Apigee-fault-source」和「X-Apigee-fault-policy」的值，如下所示：

      alt_text

    3. 如上圖所示，如果「X-Apigee-fault-source」的值為「policy」，表示啟用串流時，政策存取酬載導致發生錯誤。

解析度

如「反模式：啟用串流時存取要求/回應酬載」一文所述，啟用串流時存取酬載是反模式。

  1. 如要處理酬載，請移除 "request.streaming.enabled" and "response.streaming.enabled" 屬性，在 Proxy/目標端點中停用串流，如下方的 ProxyEndpoint 範例所示： 
    <ProxyEndpoint name="default">
...
  <HTTPProxyConnection>
    <BasePath>/v1/weather</BasePath>
    <VirtualHost>secure</VirtualHost>
  </HTTPProxyConnection>
</ProxyEndpoint>

    或

  2. 如要為 API Proxy 使用串流，請勿在 API Proxy 中使用任何存取要求/回應酬載的政策。

附註：

  • 在本劇本中，JSONThreatProtection 政策用於處理要求酬載，並在範例情境中啟用串流。這導致 500 Internal Server Error，並出現不同錯誤。
  • 如果啟用串流，系統在處理要求或回應酬載時，也可能因 JSONToXML 和 XMLToJSON 等政策而顯示這些錯誤。
  • 如果 Proxy 需要存取啟用串流時的酬載，我們強烈建議不要在 Proxy 中使用任何這類政策。
  • 如「反模式：啟用串流時存取要求/回應酬載」所述，這麼做是反模式。

使用 API 監控功能診斷問題

如果您是私有雲使用者，請略過這個程序。

API 監控功能可協助您快速找出問題領域，診斷錯誤、效能和延遲問題，以及問題來源 (例如開發人員應用程式、API Proxy、後端目標或 API 平台)。

逐步瞭解範例情境，瞭解如何使用 API 監控功能排解 API 的 5xx 問題。舉例來說，您可能會想設定快訊，在 500 錯誤數量超過特定門檻時收到通知。

如要在政策擲回 500 錯誤回應時收到通知，請將錯誤來源設為「Proxy」，並為 500 狀態碼設定快訊。

必須收集診斷資訊

如果按照上述指示操作後問題仍未解決，請收集下列診斷資訊。請聯絡 Apigee 支援團隊並提供這些資訊。

如果您是公有雲使用者，請提供下列資訊：

  • 機構名稱
  • 環境名稱
  • API Proxy 名稱
  • 完成 curl 指令和要求酬載 (如有)，重現 500 錯誤
  • 包含 500 內部伺服器錯誤的要求的追蹤記錄檔
  • 如果目前未發生 500 錯誤，請提供過去發生 500 錯誤的時間範圍和時區資訊。

如果您是 Private Cloud 使用者，請提供下列資訊：

  • 失敗要求顯示的完整錯誤訊息
  • 您觀察到 500 錯誤的機構、環境名稱和 API Proxy 名稱
  • API Proxy 套裝組合
  • 要求中使用的酬載 (如有)
  • 包含 500 內部伺服器錯誤的要求的追蹤記錄檔
  • NGINX 存取記錄 (/opt/apigee/var/log/edge-router/nginx/ <org>~ <env>.<port#>_access_log)
  • 訊息處理器記錄 (/opt/apigee/var/log/edge-message-processor/logs/system.log)
  • 發生 500 錯誤時的時間範圍與時區資訊。