502 閘道錯誤 - TooBigBody

查看 Apigee Edge 說明文件。
前往 Apigee X說明文件
資訊

問題

用戶端應用程式收到 HTTP 狀態碼 502 Bad Gateway 和錯誤代碼 protocol.http.TooBigBody 做為 API 呼叫的回應。

錯誤訊息

用戶端應用程式會取得下列回應代碼:

HTTP/1.1 502 Bad Gateway

此外,您也可能會看到下列錯誤訊息:

{
   "fault":{
      "faultstring":"Body buffer overflow",
      "detail":{
         "errorcode":"protocol.http.TooBigBody"
      }
   }
}

可能原因

如果目標/後端伺服器將酬載大小傳送到 Apigee Edge 的一部分,就會發生這個錯誤 的 HTTP 回應大於 Apigee Edge 中的限制

以下是可能引發錯誤的可能原因:

原因 說明 適用的疑難排解操作說明
回應酬載大小超過允許的上限 在對 Apigee 發出 HTTP 回應時,目標/後端伺服器傳送的酬載大小為 超過 Apigee 允許的上限。 邊緣公有雲和私有雲使用者
回應酬載大小超過允許的上限 解壓縮 做為 HTTP 的一部分,目標/後端伺服器會以壓縮格式傳送的酬載大小 透過 Apigee 解壓縮時,傳回 Apigee 的回應數超出允許的上限。 邊緣公有雲和私有雲使用者

常見的診斷步驟

請使用下列其中一項工具/技巧診斷這個錯誤:

API Monitoring

如何使用 API Monitoring 診斷錯誤:

  1. 以下列使用者身分登入 Apigee Edge UI 擔任適當角色
  2. 切換到您要調查問題的機構。

  3. 前往「Analyze」(分析) >「API 監控 >調查頁面。
  4. 請選取您發現錯誤的確切時間範圍。
  5. 您可以選取「Proxy」篩選器來縮小錯誤程式碼的範圍。
  6. 根據「時間」繪製「Fault Code」指標。
  7. 選取含有錯誤程式碼 protocol.http.TooBigBody 的儲存格 如下所示:

  8. 畫面上會顯示錯誤程式碼的相關資訊 protocol.http.TooBigBody,如下所示:

  9. 按一下「查看記錄」,然後展開失敗要求的資料列。

  10. 在「Logs」(記錄檔) 視窗中,記下下列詳細資料:
    • 狀態碼: 502
    • 錯誤來源: target
    • 錯誤代碼: protocol.http.TooBigBody
  11. 如果「錯誤來源」的值為 target 和「錯誤程式碼」, 值為 protocol.http.TooBigBody,就表示 目標/ 後端伺服器的回應酬載大小大於 允許 Apigee Edge 中的限制

Trace

如何使用追蹤工具診斷錯誤:

  1. 啟用追蹤工作階段,然後執行下列其中一項操作:
    • 等待 502 Bad Gateway 錯誤發生,或
    • 如果可以重現問題,請發出 API 呼叫並重現問題 502 Bad Gateway 個錯誤。
  2. 請選取其中一個失敗的要求,然後檢查追蹤記錄。
  3. 瀏覽追蹤記錄的各個階段,找出失敗的部分。
  4. 前往系統收到目標的回應後就要前往「Error」階段, 伺服器階段,如下所示:

    請注意追蹤記錄中的錯誤值:

    • 錯誤: Body buffer overflow
    • error.classcom.apigee.errors.http.server.BadGateway

    這表示 Apigee Edge (Message Processor 元件) 會在 由於酬載大小超過允許的上限,因此才會收到來自後端伺服器的回應 我們會自動向帳單帳戶扣款 並每月或在您達到用量上限時發送帳單

  5. 您會在「Response Sent to Client」(回應已傳送至用戶端) 階段中看到失敗情況,如下所示:

  6. 記下追蹤記錄中的錯誤值。上述追蹤記錄範例顯示:
    • 錯誤: 502 Bad Gateway
    • 錯誤內容: {"fault":{"faultstring":"Body buffer overflow","detail":{"errorcode":"protocol.http.TooBigBody"}}}
  7. 前往「已從目標伺服器收到的回應」階段,即可在不同情境下前往對應的頁面:

    未壓縮

    情境 #1:以未壓縮格式傳送的回應酬載

    請注意追蹤記錄中的錯誤值:

    • 從目標伺服器收到的回應200 OK
    • Content-Length (來自「Response Headers」部分):約 11 MB

    經過壓縮

    情境 #2:要求以壓縮格式傳送酬載

    請注意追蹤記錄中的錯誤值:

    • 從目標伺服器收到的回應200 OK
    • Content-Encoding:如果在「回應標頭」中看到這個標頭 記下這個值。例如,在本例中 gzip
  8. 請注意「回應內容」部分下方的「內文」

    {"fault":{"faultstring":"Body buffer overflow","detail":{"errorcode":"protocol.http.TooBigBody"}}}
    
  9. 前往追蹤記錄中的「AX」AX(已記錄 Analytics 資料) 階段,然後按一下該階段 即可查看相關詳細資料

  10. 在「階段詳細資料」中,向下捲動到「Variables Read」部分,然後決定 target.received.content.length 的值,代表:
    • 以未壓縮格式傳送的回應酬載時,實際大小
    • Apigee 解壓縮時的回應酬載大小 (當酬載由 並以壓縮格式傳送一律與允許的值 限制 (10 MB)。
    ,瞭解如何調查及移除這項存取權。

    未壓縮

    情境 #1:以未壓縮格式傳送的回應酬載

    請注意 target.received.content.length 的值:

    要求標頭
    target.received.content.length 約 11 MB

    經過壓縮

    情境 #2:要求以壓縮格式傳送酬載

    請注意 target.received.content.length 的值:

    要求標頭
    target.received.content.length 約 10 MB
  11. 下表說明 Apigee 根據下列條件傳回 502 錯誤的原因: 有兩種情境,以 target.received.content.length 的值為準:

    情境 target.received.content.length 的值 失敗原因
    採用未壓縮格式的回應酬載 約 11 MB 尺寸 >允許的大小上限為 10 MB
    壓縮格式的回應酬載 約 10 MB

    解壓縮後大小超過上限

NGINX

如何使用 NGINX 存取記錄診斷錯誤:

  1. 如果您是 Private Cloud 使用者,可以透過 NGINX 存取記錄檔判斷 提供 HTTP 502 錯誤的相關重要資訊。
  2. 查看 NGINX 存取記錄:

    /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log

    其中: ORGENVPORT# 會替換為實際值。

  3. 搜尋查看在特定時間範圍內是否有任何 502 錯誤 ( 或是發生任何請求失敗 502
  4. 如果在 X-Apigee-fault-code 比對中發現任何 502 錯誤 protocol.http.TooBigBody 的值,然後判斷 X-Apigee-fault-source.

    NGINX 存取記錄中的 502 錯誤示例:

    上述 NGINX 存取記錄範例的項目 X-Apigee- fault-code X-Apigee-fault-source:

    回應標頭
    X-Apigee-fault-code protocol.http.TooBigBody
    X-Apigee-fault-source target

原因:回應酬載大小超過允許的上限

診斷

  1. 判定下列項目的「錯誤程式碼」、「錯誤來源」和「回應酬載大小」。 您在使用 API 監控、追蹤工具或 NGINX 存取記錄檔時觀察到的錯誤,詳情請參閱 與情境 1 相關的常見診斷步驟
  2. 如果 Fault Source 的值為 target,表示回應 目標/後端伺服器傳送至 Apigee 的酬載大小大於 在 Apigee Edge 中允許限制
  3. 驗證「回應酬載大小」;如步驟 1 所示。
  4. 驗證回應酬載大小是否確實 >方法是查看 來實際回應:
    1. 如果您無法存取對目標/後端伺服器發出的實際要求, 前往「解析度」
    2. 如果您可以存取對目標/後端伺服器提出的實際要求,則 請執行下列步驟:
      1. 如果您是公用 Cloud/Private Cloud 使用者,請直接向 或存取其他機器 傳送至後端伺服器。
      2. 如果您是 Private Cloud 使用者,也可以向 來自其中一個訊息處理器
      3. 查看 Content-Length 標頭。
      4. 如果您發現酬載大小超過 在 Apigee Edge 中允許受限,這是導致 問題。

    來自後端伺服器的回應範例:

    curl -v https://BACKENDSERVER-HOSTNAME/testfile
    
    * About to connect() to 10.14.0.10 port 9000 (#0)
    *   Trying 10.14.0.10...
    * Connected to 10.14.0.10 (10.148.0.10) port 9000 (#0)
    > GET /testfile HTTP/1.1
    > User-Agent: curl/7.29.0
    > Host: 10.14.0.10:9000
    > Accept: */*
    >
    < HTTP/1.1 200 OK
    < Accept-Ranges: bytes
    < Content-Length: 11534336
    < Content-Type: application/octet-stream
    < Last-Modified: Wed, 30 Jun 2021 08:18:02 GMT
    < Date: Wed, 30 Jun 2021 09:22:41 GMT
    <
    ----snipped----
    <Response Body>
    

    在上述範例中,您可以看到 Content-Length: 11534336 (which is ~11 MB) 是造成錯誤的原因,因為該值超過 Apigee Edge 的允許限制

解析度

請參閱「解析度」一節。

原因:回應酬載大小超過允許的上限 解壓縮

如果回應酬載是以壓縮格式和回應標頭傳送 將Content-Encoding設為 gzip, Apigee 解壓縮回應 酬載。在解壓縮程序中,如果 Apigee 發現酬載大小較大 超過 Apigee Edge 允許的數量上限。之後,該限制會停止進一步 解壓縮並立即回應 呼叫 502 Bad Gateway 和錯誤代碼 protocol.http.TooBigBody

診斷

  1. 判定以下項目的「錯誤程式碼」、「錯誤來源」和「回應酬載大小」。 您在使用 API 監控、追蹤工具或 NGINX 存取記錄時觀察到的錯誤,詳情請參閱 與情境 2 相關的常見診斷步驟
  2. 如果 Fault Source 的值為 target,則表示 目標/後端應用程式傳送至 Apigee 的回應酬載大小大於 在 Apigee Edge 中允許的數量上限。
  3. 驗證「回應酬載大小」;如步驟 1 所示。
    • 如果酬載大小 >上限為 10 MB,那麼就是錯誤的原因。
    • 如果酬載大小約為 10 MB 允許的上限,則回應酬載 會以壓縮格式傳遞在這種情況下,請檢查壓縮後的未壓縮大小 回應酬載
  4. 您可以驗證目標/後端的回應是否以壓縮格式傳送,以及 未壓縮時的大小超過允許的上限,請使用下列其中一項參數 方法:

    Trace

    使用追蹤工具:

    1. 如果您擷取失敗要求的追蹤記錄,請參閱 Trace
      1. 判斷 target.received.content.length 的值
      2. 驗證來自用戶端的要求是否包含 內容編碼:gzip 標頭
    2. 如果 target.received.content.length 的值約為 10 MB 而回應標頭為 Content-Encoding: gzip ,則代表 發生這項錯誤的原因

    實際要求

    使用實際要求:

    1. 如果您無法存取對目標/後端伺服器發出的實際要求, 前往「解析度」
    2. 如果您可以存取對目標/後端伺服器提出的實際要求,則 請執行下列步驟:
      1. 驗證回應中所傳遞的酬載大小以及 回應中送出 Content-Encoding 標頭。
      2. 如果找到回應標頭 Content-Encoding 已設為 gzip 和酬載的未壓縮大小大於 在 Apigee Edge 中允許限制,這是導致 。

        從後端伺服器接收的回應範例:

        curl -v https://BACKENDSERVER-HOSTNAME/testzippedfile.gz
        
        * About to connect() to 10.1.0.10 port 9000 (#0)
        *   Trying 10.1.0.10...
        * Connected to 10.1.0.10 (10.1.0.10) port 9000 (#0)
        > GET /testzippedfile.gz HTTP/1.1
        > User-Agent: curl/7.29.0
        > Host: 10.1.0.10:9000
        > Accept: */*
        >
        < HTTP/1.1 200 OK
        < Accept-Ranges: bytes
        < Content-Encoding: gzip
        < Content-Type: application/x-gzip
        < Last-Modified: Wed, 30 Jun 2021 08:18:02 GMT
        < Testheader: test
        < Date: Wed, 07 Jul 2021 10:14:16 GMT
        < Transfer-Encoding: chunked
        <
        ----snipped----
        <Response Body>
        

        在上述範例中,系統傳送了 Content-Encoding: gzip 標頭,並 回應中的檔案 testzippedfile.gz 大小小於 但未壓縮檔案 testzippedfile 的大小為 約 15 MB。

    ,瞭解如何調查及移除這項存取權。

    訊息處理器記錄

    使用訊息處理器記錄:

    1. 如果您是 Private Cloud 使用者,可將訊息處理者的記錄檔用於 來判斷 HTTP 502 錯誤的相關重要資訊。
    2. 查看訊息處理器記錄

      /opt/apigee/var/log/edge-message-processor/logs/system.log

    3. 搜尋,查看在特定期間是否有任何 502 錯誤 (如果問題是過去發生) 或者 502。你可以使用以下搜尋字串:

      grep -ri "chunkCount"
      
      grep -ri "BadGateway: Body buffer overflow"
      
    4. 您會看到 system.log 提供的行,如下所示 (TotalReadchunkCount 可能依情況而異):
      2021-07-07 09:40:47,012  NIOThread@7 ERROR HTTP.SERVICE -
      TrackingInputChannel.checkMessageBodyTooLarge() : Message is too large.
      TotalRead 10489856 chunkCount 2571
      
      2021-07-07 09:40:47,012  NIOThread@7 ERROR HTTP.CLIENT -
      HTTPClient$Context.onInputException() :
      ClientInputChannel(ClientChannel[Connected:
      Remote:10.148.0.10:9000 Local:10.148.0.9:42240]@9155
      useCount=1 bytesRead=0 bytesWritten=182 age=23ms  lastIO=0ms
      isOpen=true).onExceptionRead exception: {}
      com.apigee.errors.http.server.BadGateway: Body buffer overflow
      
      2021-07-07 09:40:47,012  NIOThread@7 ERROR
      ADAPTORS.HTTP.FLOW - AbstractResponseListener.onException() :
      AbstractResponseListener.onError(HTTPResponse@77cbd7c4,
      Body buffer overflow)
      
    5. 在解壓縮程序中,只要訊息處理器決定 讀取位元組總計 >10 MB 時,事件會停止並顯示下列一行:

      Message is too large. TotalRead 10489856 chunkCount 2571

      它表示回應酬載大小超過 10 MB,且 Apigee 如果大小開始超過上限 (10 MB),並提供錯誤程式碼,就會擲回錯誤。 protocol.http.TooBigBody

解析度

修正大小

選項 #1 [建議]:修正目標伺服器應用程式,不要傳送超過 Apigee 限制的酬載大小

  1. 分析特定目標伺服器以傳送回應 / 酬載大小的原因 超過 中定義的允許上限 限制
  2. 如果您不想要,請修改目標伺服器應用程式,使其在應用程式的清單中 回應 / 酬載大小小於允許的上限。
  3. 如果可行,而您想傳送回應/酬載超過允許的上限 請繼續下一個選項

已簽署的網址模式

選項 #2 [建議]:在 Apigee Java 呼叫中使用已簽署的網址模式

如果酬載大於 10 MB,Apigee 會建議在 Apigee Java 摘要,以 邊緣呼叫:GitHub 上的已簽署網址產生器範例。

串流

方法 #3:使用串流功能

如果您的 API Proxy 需要處理非常大量的要求和/或回應, 在 Apigee 中啟用串流功能。

CwC

方法 #4:使用 CwC 屬性提高緩衝區限制

只有在無法使用以下任何建議選項時,才能使用這個選項: 如果提高預設大小,可能就會發生效能問題。

Apigee 提供 CwC 屬性,以便增加要求和回應酬載的大小 我們會自動向帳單帳戶扣款 並每月或在您達到用量上限時發送帳單詳情請參閱 設定路由器或訊息處理器的訊息大小限制

限制

Apigee 預期用戶端應用程式和後端伺服器傳送酬載大小不得超過 允許的數量上限 (如 Request/response size 所述) Apigee Edge 限制

  1. 如果您是公有雲使用者,則要求與回應數量上限 酬載大小與Request/response size Apigee Edge 限制
  2. 如果您是 Private Cloud 使用者 ,可能已修改預設上限 限制的要求和回應酬載大小限制 (即使這不是建議做法)。 如要判斷要求酬載大小上限,請遵循 如何查看目前的限制

如何查看目前的限制?

本節將說明如何驗證資源 HTTPResponse.body.buffer.limit 的「訊息」應用程式已更新為新值 處理器:

  1. 在訊息處理器電腦上搜尋屬性 /opt/apigee/edge-message- processor/conf 目錄中的 HTTPResponse.body.buffer.limit,並查看以下設定的值:

    grep -ri "HTTPResponse.body.buffer.limit" /opt/apigee/edge-message-processor/conf
    
  2. 上述指令的結果範例如下:

    /opt/apigee/edge-message-processor/conf/http.properties:HTTPResponse.body.buffer.limit=10m
    
  3. 在上方輸出範例中,請注意 「HTTPResponse.body.buffer.limit」已設為 10m 這個值。 http.properties

    這表示在 Apigee 中設定的要求酬載大小限制 私有雲的檔案大小為 10 MB

如果仍需 Apigee 支援團隊的協助,請前往 必須收集診斷資訊。

必須收集診斷資訊

收集下列診斷資訊,然後與 Apigee Edge 支援團隊聯絡:

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

  • 機構名稱
  • 環境名稱
  • API Proxy 名稱
  • 完成用於重現 502 錯誤的 curl 指令
  • API 要求的追蹤檔
  • 目標/後端伺服器回應的完整輸出內容,以及酬載大小

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

  • 偵測到失敗要求的完整錯誤訊息
  • 機構名稱
  • 環境名稱
  • API Proxy 套裝組合
  • 失敗 API 要求的追蹤檔
  • 完成用於重現 502 錯誤的 curl 指令
  • 目標/後端伺服器回應的完整輸出內容,以及酬載大小
  • NGINX 存取記錄 /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log

    其中: ORGENVPORT# 會替換為 實際價值

  • 訊息處理器系統記錄:/opt/apigee/var/log/edge-message-processor/logs/system.log