針對 API Gateway 中的回應串流問題進行故障診斷 - Amazon API Gateway
一般性問題的故障診斷故障診斷 cURL 錯誤使用存取記錄進行故障診斷

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

針對 API Gateway 中的回應串流問題進行故障診斷

下列疑難排解指引可能有助於解決使用回應串流APIs 的問題。

一般性問題的故障診斷

您可以使用 TestInvokeMethod 或主控台的測試索引標籤來測試串流回應。下列考量事項可能會影響您使用測試叫用進行回應串流：

  • 當您測試方法時，API Gateway 會緩衝串流的回應承載。一旦符合下列任一條件，API Gateway 便會傳回包含緩衝承載的一次性回應：

    • 請求已完成

    • 已經過 35 秒

    • 已緩衝超過 1 MB 的回應承載

  • 如果超過 35 秒才傳回 HTTP 回應狀態和所有標頭，則 TestInvokeMethod 中傳回的回應狀態為 0。

  • API Gateway 不會產生任何執行日誌。

部署 API 之後，您可以使用 curl 命令來測試串流回應。建議您使用 -i選項，在輸出中包含通訊協定回應標頭。若要查看到達時的回應資料，請使用 curl 選項 --no-buffer

故障診斷 cURL 錯誤

如果您正在測試整合並收到錯誤 curl: (18) transfer closed with outstanding read data remaining，請確定整合的逾時時間夠長。如果您使用的是 Lambda 函數，則需要更新 Lambda 函數的回應逾時。如需詳細資訊，請參閱設定 Lambda 函數逾時。

使用存取記錄進行故障診斷

您可以使用 REST API 階段的存取日誌來記錄回應串流並進行疑難排解。除了現有的變數之外，您還可以使用下列存取日誌變數：

$context.integration.responseTransferMode

整合的回應傳輸模式。可以是 BUFFERED 或 STREAMED。

$context.integration.timeToAllHeaders

從用戶端接收所有整合回應標頭時，API Gateway 建立與 的整合連線之間的時間。

$context.integration.timeToFirstContent

API Gateway 在收到第一個內容位元組時建立與 的整合連線之間的時間。

$context.integration.latency 或 $context.integrationLatency

當整合回應串流完成時，API Gateway 與 建立整合連線的時間。

下圖顯示這些存取日誌變數如何代表回應串流的不同元件。

在 API Gateway 中存取回應串流的日誌變數

如需存取日誌的詳細資訊，請參閱在 API Gateway 中設定 REST API 的 CloudWatch 記錄功能。您也可以使用 X-Ray 來監控回應串流。如需詳細資訊，請參閱在 API Gateway 中使用 X-Ray 追蹤使用者對 REST API 的請求。