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 的追蹤記錄範例螢幕截圖 政策 失敗，並傳回「Expecting } at line 1」 錯誤訊息：

    alt_text

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

    違規政策： JSONThreatProtection

    流程：Proxy 要求

  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. 接下來，根據失敗的位置檢查 Proxy 和目標端點的定義 政策會用於 API 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 錯誤值，確認 500 錯誤是因政策問題所導致 &quot;X-Apigee-fault-source&quot;中的 &quot;X-Apigee-fault-source&quot; (已記錄的 Analytics 資料) 追蹤記錄的階段步驟如下：
    1. 按一下 [AX] (已記錄的 Analytics 資料) 階段 如以下螢幕截圖所示：

      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. 如要處理酬載，您必須停用 Proxy/Target 中的串流功能 透過移除屬性 "request.streaming.enabled" and "response.streaming.enabled" ，即可進行端點設定，如下方 ProxyEndpoint 範例所示： 
    <ProxyEndpoint name="default">
...
  <HTTPProxyConnection>
    <BasePath>/v1/weather</BasePath>
    <VirtualHost>secure</VirtualHost>
  </HTTPProxyConnection>
</ProxyEndpoint>

    或

  2. 如要將串流用於 API Proxy，請不要在 存取要求/回應酬載的 API Proxy。

注意：

  • 在本教戰手冊中，JSONThreatProtection 政策是透過 在範例情境中啟用串流功能這導致發生 500 個內部伺服器錯誤，但不同的錯誤。
  • 您也可以透過 JSONToXML 和 XMLToJSON 等政策查看這些錯誤， 要求或回應酬載
  • 強烈建議您不要在需要存取權的 Proxy 中使用這類政策 則會產生多個酬載
  • 這麼做屬於反模式，如 反模式：在啟用串流時存取要求/回應酬載。

使用 API Monitoring 診斷問題

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

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

逐步完成範例情境，示範如何使用 API Monitoring 排解 5xx 問題。舉例來說，您可以設定快訊，在 500 個錯誤數量超過特定門檻時收到通知。

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

必須收集診斷資訊

按照上述說明操作後，如果問題仍未解決，請收集下列診斷資訊。請聯絡 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 個錯誤的時間範圍。