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

您正在查看 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 個內部伺服器錯誤。

原因 說明 誰可以執行疑難排解步驟
在已啟用串流功能的情況下存取酬載 發生錯誤，因為系統會在啟用串流功能時存取要求/回應酬載。 邊緣私人和公有雲使用者

原因：在啟用串流的情況下存取酬載

診斷

程序 1：使用追蹤記錄

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

    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-Threat-Protection 政策失敗。這表示酬載必須是 JSON 格式。

  8. 確認酬載的格式是否正確。如果酬載無效，您會收到這個錯誤。

  9. 如果酬載有效，但您仍看到「錯誤訊息」一節所列的錯誤，表示發生這些錯誤的原因是正在啟用串流功能。

    視政策剖析的酬載 (如步驟 #6 所示) 而定，在適當階段檢查 Trace 工具中的酬載內容。

    在這個範例中，系統會剖析要求酬載，因此請檢查追蹤記錄中的「Request Received from Client」階段，然後查看「Request Content」(要求內容)。

    alt_text

    如上方螢幕截圖所示，如果「要求內容」沒有任何內容，即使您傳送了有效的酬載，則表示這個問題可能是由要求串流啟用。

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

    同樣地，如果系統在錯誤發生時剖析回應酬載，請在「Responsereceive 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. 您可以按照下列步驟，查看追蹤記錄中「AX」(Analytics (分析) 已記錄) 階段中的 "X-Apigee-fault-source" 值，確認 500 錯誤是因為政策所致：
    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" 屬性，如下方 ProxyEndpoint 所示：
    <ProxyEndpoint name="default">
...
  <HTTPProxyConnection>
    <BasePath>/v1/weather</BasePath>
    <VirtualHost>secure</VirtualHost>
  </HTTPProxyConnection>
</ProxyEndpoint>
    ，然後停用 Proxy/目標端點中的串流功能。

    或

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

注意 ：

  • 在本應對手冊中，我們在範例情境中使用了 JSONThreatProtection 政策，處理已啟用串流的要求酬載。導致 500 個內部伺服器錯誤，但錯誤有所不同。
  • 這些錯誤也會顯示在 JSONToXML 和 XMLToJSON 等政策中，這類政策會在啟用串流功能時處理要求或回應酬載。
  • 在已啟用串流功能的情況下，我們強烈建議您不要在需要存取酬載存取權的 Proxy 中使用任何這類政策。
  • 這樣做屬於反模式，如「反模式：在啟用串流的情況下存取要求/回應酬載」一節所述。

使用 API 監控功能診斷問題

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

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

逐步操作範例，示範如何使用 API Monitoring 排解 API 的 5xx 問題。舉例來說，您可以設定快訊，讓系統在 500 個錯誤數量超過特定門檻時通知您。

如果您想在政策擲回 500 錯誤回應時收到通知，就必須將「500 狀態碼」設為快訊，並將錯誤來源設為 Proxy。

收集診斷資訊的必要性

如果按照上述指示操作後仍無法解決問題，請收集以下診斷資訊。請與 Apigee 支援團隊聯絡並與他們分享。

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

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

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

  • 觀察失敗要求的完整錯誤訊息
  • 您觀察到 500 個錯誤的機構、環境名稱和 API Proxy 名稱
  • API Proxy 套裝組合
  • 要求中使用的酬載 (如果有的話)
  • 內含 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 錯誤時，包含時區資訊的時間範圍。