查看 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 診斷錯誤:
- 以下列使用者身分登入 Apigee Edge UI: 擔任適當角色
切換到您要調查問題的機構。
- 前往「Analyze」(分析) >「API 監控 >調查頁面。
- 請選取您發現錯誤的確切時間範圍。
- 您可以選取「Proxy」篩選器來縮小錯誤程式碼的範圍。
- 根據「時間」繪製「Fault Code」指標。
選取含有錯誤程式碼
protocol.http.TooBigBody
的儲存格 如下所示:畫面上會顯示錯誤程式碼的相關資訊
protocol.http.TooBigBody
,如下所示:按一下「查看記錄」,然後展開失敗要求的資料列。
- 在「Logs」(記錄檔) 視窗中,記下下列詳細資料:
- 狀態碼:
502
- 錯誤來源:
target
- 錯誤代碼:
protocol.http.TooBigBody
。
- 狀態碼:
- 如果「錯誤來源」的值為
target
和「錯誤程式碼」, 值為protocol.http.TooBigBody
,就表示 目標/ 後端伺服器的回應酬載大小大於 允許 Apigee Edge 中的限制。
Trace
如何使用追蹤工具診斷錯誤:
- 啟用追蹤工作階段,然後執行下列其中一項操作:
- 等待
502 Bad Gateway
錯誤發生,或 - 如果可以重現問題,請發出 API 呼叫並重現問題
502 Bad Gateway
個錯誤。
- 等待
- 請選取其中一個失敗的要求,然後檢查追蹤記錄。
- 瀏覽追蹤記錄的各個階段,找出失敗的部分。
前往系統收到目標的回應後就要前往「Error」階段, 伺服器階段,如下所示:
請注意追蹤記錄中的錯誤值:
- 錯誤:
Body buffer overflow
- error.class:
com.apigee.errors.http.server.BadGateway
這表示 Apigee Edge (Message Processor 元件) 會在 由於酬載大小超過允許的上限,因此才會收到來自後端伺服器的回應 我們會自動向帳單帳戶扣款 並每月或在您達到用量上限時發送帳單
- 錯誤:
您會在「Response Sent to Client」(回應已傳送至用戶端) 階段中看到失敗情況,如下所示:
- 記下追蹤記錄中的錯誤值。上述追蹤記錄範例顯示:
- 錯誤:
502 Bad Gateway
- 錯誤內容:
{"fault":{"faultstring":"Body buffer overflow","detail":{"errorcode":"protocol.http.TooBigBody"}}}
- 錯誤:
前往「已從目標伺服器收到的回應」階段,即可在不同情境下前往對應的頁面:
未壓縮
情境 #1:以未壓縮格式傳送的回應酬載
請注意追蹤記錄中的錯誤值:
- 從目標伺服器收到的回應:
200 OK
- Content-Length (來自「Response Headers」部分):約 11 MB
經過壓縮
情境 #2:要求以壓縮格式傳送酬載
請注意追蹤記錄中的錯誤值:
- 從目標伺服器收到的回應:
200 OK
- Content-Encoding:如果在「回應標頭」中看到這個標頭
記下這個值。例如,在本例中
gzip
。
- 從目標伺服器收到的回應:
請注意「回應內容」部分下方的「內文」:
{"fault":{"faultstring":"Body buffer overflow","detail":{"errorcode":"protocol.http.TooBigBody"}}}
前往追蹤記錄中的「AX」AX(已記錄 Analytics 資料) 階段,然後按一下該階段 即可查看相關詳細資料
- 在「階段詳細資料」中,向下捲動到「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 下表說明 Apigee 根據下列條件傳回
502
錯誤的原因: 有兩種情境,以 target.received.content.length 的值為準:情境 target.received.content.length 的值 失敗原因 採用未壓縮格式的回應酬載 約 11 MB 尺寸 >允許的大小上限為 10 MB 壓縮格式的回應酬載 約 10 MB 解壓縮後大小超過上限
NGINX
如何使用 NGINX 存取記錄診斷錯誤:
- 如果您是 Private Cloud 使用者,可以透過 NGINX 存取記錄檔判斷
提供 HTTP
502
錯誤的相關重要資訊。 查看 NGINX 存取記錄:
/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log
其中: ORG、ENV 和 PORT# 會替換為實際值。
- 搜尋查看在特定時間範圍內是否有任何
502
錯誤 ( 或是發生任何請求失敗502
。 - 如果在 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
原因:回應酬載大小超過允許的上限
診斷
- 判定下列項目的「錯誤程式碼」、「錯誤來源」和「回應酬載大小」。 您在使用 API 監控、追蹤工具或 NGINX 存取記錄檔時觀察到的錯誤,詳情請參閱 與情境 1 相關的常見診斷步驟。
- 如果 Fault Source 的值為
target
,表示回應 目標/後端伺服器傳送至 Apigee 的酬載大小大於 在 Apigee Edge 中允許限制。 - 驗證「回應酬載大小」;如步驟 1 所示。
- 如果酬載大小 >上限為 10 MB,就是造成錯誤的原因。
- 如果酬載大小約為 10 MB 允許上限,就可能收到回應 酬載是以壓縮格式傳遞。前往 原因:解壓縮後的回應酬載大小超過允許的上限。
- 驗證回應酬載大小是否確實 >方法是查看
來實際回應:
- 如果您無法存取對目標/後端伺服器發出的實際要求, 前往「解析度」。
- 如果您可以存取對目標/後端伺服器提出的實際要求,則
請執行下列步驟:
- 如果您是公用 Cloud/Private Cloud 使用者,請直接向 或存取其他機器 傳送至後端伺服器。
- 如果您是 Private Cloud 使用者,也可以向 來自其中一個訊息處理器
- 查看 Content-Length 標頭。
- 如果您發現酬載大小超過 在 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
。
診斷
- 判定以下項目的「錯誤程式碼」、「錯誤來源」和「回應酬載大小」。 您在使用 API 監控、追蹤工具或 NGINX 存取記錄時觀察到的錯誤,詳情請參閱 與情境 2 相關的常見診斷步驟。
- 如果 Fault Source 的值為
target
,則表示 目標/後端應用程式傳送至 Apigee 的回應酬載大小大於 在 Apigee Edge 中允許的數量上限。 - 驗證「回應酬載大小」;如步驟 1 所示。
- 如果酬載大小 >上限為 10 MB,那麼就是錯誤的原因。
- 如果酬載大小約為 10 MB 允許的上限,則回應酬載 會以壓縮格式傳遞在這種情況下,請檢查壓縮後的未壓縮大小 回應酬載
- 您可以驗證目標/後端的回應是否以壓縮格式傳送,以及
未壓縮時的大小超過允許的上限,請使用下列其中一項參數
方法:
Trace
使用追蹤工具:
- 如果您擷取失敗要求的追蹤記錄,請參閱
Trace 和
- 判斷 target.received.content.length 的值
- 驗證來自用戶端的要求是否包含
內容編碼:
gzip
標頭
- 如果 target.received.content.length 的值約為 10 MB
而回應標頭為 Content-Encoding:
gzip
,則代表 發生這項錯誤的原因
實際要求
使用實際要求:
- 如果您無法存取對目標/後端伺服器發出的實際要求, 前往「解析度」。
- 如果您可以存取對目標/後端伺服器提出的實際要求,則
請執行下列步驟:
- 驗證回應中所傳遞的酬載大小以及
回應中送出
Content-Encoding
標頭。 - 如果找到回應標頭
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。
- 驗證回應中所傳遞的酬載大小以及
回應中送出
訊息處理器記錄
使用訊息處理器記錄:
- 如果您是 Private Cloud 使用者,可將訊息處理者的記錄檔用於
來判斷 HTTP
502
錯誤的相關重要資訊。 查看訊息處理器記錄
/opt/apigee/var/log/edge-message-processor/logs/system.log
搜尋,查看在特定期間是否有任何
502
錯誤 (如果問題是過去發生) 或者502
。你可以使用以下搜尋字串:grep -ri "chunkCount"
grep -ri "BadGateway: Body buffer overflow"
- 您會看到
system.log
提供的行,如下所示 (TotalRead
和chunkCount
可能依情況而異):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)
在解壓縮程序中,只要訊息處理器決定 讀取位元組總計 >10 MB 時,事件會停止並顯示下列一行:
Message is too large. TotalRead 10489856 chunkCount 2571
它表示回應酬載大小超過 10 MB,且 Apigee 如果大小開始超過上限 (10 MB),並提供錯誤程式碼,就會擲回錯誤。
protocol.http.TooBigBody
- 如果您擷取失敗要求的追蹤記錄,請參閱
Trace 和
解析度
修正大小
選項 #1 [建議]:修正目標伺服器應用程式,不要傳送超過 Apigee 限制的酬載大小
- 分析特定目標伺服器以傳送回應 / 酬載大小的原因 超過 中定義的允許上限 限制。
- 如果您不想要,請修改目標伺服器應用程式,使其在應用程式的清單中 回應 / 酬載大小小於允許的上限。
- 如果可行,而您想傳送回應/酬載超過允許的上限 請繼續下一個選項
已簽署的網址模式
選項 #2 [建議]:在 Apigee Java 呼叫中使用已簽署的網址模式
如果酬載大於 10 MB,Apigee 會建議在 Apigee Java 摘要,以 邊緣呼叫:GitHub 上的已簽署網址產生器範例。
串流
方法 #3:使用串流功能
如果您的 API Proxy 需要處理非常大量的要求和/或回應, 在 Apigee 中啟用串流功能。
CwC
方法 #4:使用 CwC 屬性提高緩衝區限制
只有在無法使用以下任何建議選項時,才能使用這個選項: 如果提高預設大小,可能就會發生效能問題。
Apigee 提供 CwC 屬性,以便增加要求和回應酬載的大小 我們會自動向帳單帳戶扣款 並每月或在您達到用量上限時發送帳單詳情請參閱 設定路由器或訊息處理器的訊息大小限制。
限制
Apigee 預期用戶端應用程式和後端伺服器傳送酬載大小不得超過
允許的數量上限 (如
Request/response size
所述)
Apigee Edge 限制。
- 如果您是公有雲使用者,則要求與回應數量上限
酬載大小與
Request/response size
Apigee Edge 限制。 - 如果您是 Private Cloud 使用者 ,可能已修改預設上限 限制的要求和回應酬載大小限制 (即使這不是建議做法)。 如要判斷要求酬載大小上限,請遵循 如何查看目前的限制。
如何查看目前的限制?
本節將說明如何驗證資源
HTTPResponse.body.buffer.limit
的「訊息」應用程式已更新為新值
處理器:
在訊息處理器電腦上搜尋屬性
/opt/apigee/edge-message- processor/conf
目錄中的HTTPResponse.body.buffer.limit
,並查看以下設定的值:grep -ri "HTTPResponse.body.buffer.limit" /opt/apigee/edge-message-processor/conf
上述指令的結果範例如下:
/opt/apigee/edge-message-processor/conf/http.properties:HTTPResponse.body.buffer.limit=10m
在上方輸出範例中,請注意 「
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
其中: ORG、ENV 和 PORT# 會替換為 實際價值
- 訊息處理器系統記錄:
/opt/apigee/var/log/edge-message-processor/logs/system.log