本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。 # 故障診斷 Lambda 受管執行個體 ## 調節和擴展問題 ### 偶爾限流 **問題：**您在正常操作期間遇到限流錯誤 (HTTP 429)。 **原因：**Lambda 受管執行個體可能會拒絕新的調用，以保護已在執行中的調用。如果您的執行環境持續具有高使用率，則新的調用可能會受到調節。 **解決方案**： + **監控擴展指標：**檢查調節原因圖表，以了解調節和容量擴展問題的原因。在下列範例中，高 CPU 會導致調節。 + **檢閱函數組態：**確保您的函數記憶體和 vCPU 設定支援多並行執行。視需要增加函數記憶體或 vCPU 配置。如果 `ExecutionEnvironmentVCPUUtilization` 很高，請嘗試為每個函數新增更多 vCPU。 ``` aws lambda update-function \ --function-name my-function \ ... --memory-size 8192 ``` 如果 `ExecutionEnvironmentMemoryUtilization` 很高，請嘗試為每個 vCPU 新增更多記憶體： ``` aws lambda update-function \ --function-name my-function \ --capacity-provider-config '{ "LambdaManagedInstancesCapacityProviderConfig": { "ExecutionEnvironmentMemoryGiBPerVCpu": 4.0 } }' ``` ### 擴展期間的調節 **問題：**當流量快速增加時，您遇到限流錯誤 (HTTP 429)。 **原因：**Lambda 受管執行個體會根據 CPU 資源使用率和多並行飽和度以非同步方式擴展。如果您的流量在 5 分鐘內增加一倍以上，您可能會在 Lambda 擴展執行個體和執行環境以滿足需求時看到調節。 **解決方案：** + **調整目標資源使用率：**如果您的工作負載具有可預測的流量模式，請設定較低的目標資源使用率，以維持額外的流量暴增空間。 ``` aws lambda create-capacity-provider \ --name my-capacity-provider \ ... --capacity-provider-scaling-config '{ "ScalingMode": "Manual", "ScalingPolicies": [ { "PredefinedMetricType": "LambdaCapacityProviderAverageCPUUtilization", "TargetValue": 30.0 } ] }' ``` + **預熱容量：**對於計劃的流量增加，請使用 `PutFunctionScalingConfig` API 預熱額外的容量。 ``` aws lambda put-function-scaling-config \ --function-name my-function \ --qualifier 1 \ --function-scaling-config '{ "MinExecutionEnvironments": 100 }' ``` ### 緩慢縮減規模 **問題：**執行個體在流量減少後需要很長的時間才能縮減規模。 **原因：**Lambda 受管執行個體會逐漸縮減規模，以維持可用性，並避免可能影響效能的快速容量變更。 **解決方案**： 這是預期的行為。Lambda 會保守地縮減執行個體，以確保穩定性。監控您的 CloudWatch 指標，以追蹤執行中的執行個體數量。 ## 並行問題 ### 具有低並行體驗調節的執行環境 **問題：**儘管有可用的容量，您的函數仍會遇到限流。 **原因：**並行上限極低的執行環境可能無法有效地擴展。Lambda 受管執行個體專為多並行應用程式而設計。 **解決方案：** + **增加並行上限：**如果您的函數調用使用極少 CPU，請將並行上限設定為每個 vCPU 64。 ``` aws lambda update-function \ --function-name ordering-api-backend \ --capacity-provider-config '{ "LambdaManagedInstancesCapacityProviderConfig": { "PerExecutionEnvironmentMaxConcurrency": 32 } }' ``` + **最佳化函數程式碼：**檢閱函數程式碼以減少每次調用的 CPU 耗用，從而允許更高的並行。 + **調整函數記憶體和 vCPU：**確保您的函數有足夠的資源來處理多個並行調用。 ### 執行緒安全問題 (Java 執行時間） **問題：**您的 Java 函數會產生不正確的結果，或在載入時遇到競爭條件。 **原因：**多個執行緒同時執行處理常式方法，共用狀態不安全。 **解決方案**： + 將 `AtomicInteger`或 `AtomicLong`用於計數器，而非基本類型 + 將 取代`HashMap`為 `ConcurrentHashMap` + 使用 `Collections.synchronizedList()` 包裝 `ArrayList` + 將 `ThreadLocal`用於請求特定的狀態 + 從 Lambda 內容物件存取追蹤 IDs，而不是環境變數 如需詳細指引，請參閱 [Lambda 受管執行個體的 Java 執行期](lambda-managed-instances-java-runtime.md)文件。 ### 狀態隔離問題 (Node.js 執行時間） **問題：**您的 Node.js 函數會從不同的請求傳回資料或遇到資料損毀。 **原因：**全域變數會在相同工作者執行緒上的並行調用之間共用。當非同步操作產生控制時，其他調用可以修改共用狀態。 **解決方案**： + 針對`@aws/lambda-invoke-store`所有請求特定的狀態安裝和使用 + 使用 `InvokeStore.set()`和 取代全域變數 `InvokeStore.get()` + 在 中使用唯一的檔案名稱`/tmp`與請求 IDs + 使用 `InvokeStore.getXRayTraceId()`而非環境變數存取追蹤 IDs 如需詳細指引，請參閱 [Lambda 受管執行個體的 Node.js 執行期](lambda-managed-instances-nodejs-runtime.md)文件。 ### 檔案衝突 (Python 執行時間） **問題：**您的 Python 函數會從 中的檔案讀取不正確的資料`/tmp`。 **原因：**多個程序共用`/tmp`目錄。同時寫入至相同檔案可能會導致資料損毀。 **解決方案**： + 使用具有請求 IDs的唯一檔案名稱： `/tmp/request_{context.request_id}.txt` + 將檔案鎖定搭配 `fcntl.flock()` 用於共用檔案 + 使用`os.remove()`後使用 清除暫存檔案 如需詳細指引，請參閱 [Lambda 受管執行個體的 Python 執行期](lambda-managed-instances-python-runtime.md)文件。 ## 效能問題 ### 高記憶體使用率 **問題：**您的函數遇到高記憶體使用率或out-of-memory錯誤。 **原因：**Python 中的每個並行請求會以自己的記憶體空間在個別程序中執行。總記憶體用量等於每個程序記憶體乘以並行程序。 **解決方案**： + 在 CloudWatch `MemoryUtilization` 中監控指標 + 如果記憶體用量接近函數的記憶體限制，請減少`MaxConcurrency`設定 + 增加函數記憶體配置以支援更高的並行 + 透過隨需載入資料來最佳化記憶體用量，而不是在初始化期間 ### 效能不一致 **問題：**函數效能在叫用之間有很大差異。 **原因：**Lambda 可能會根據可用性選擇不同的執行個體類型，或者函數可能會在資源可用性不同的執行個體上執行。 **解決方案**： + **指定允許的執行個體類型：**如果您有特定的效能需求，請在容量提供者中設定允許的執行個體類型，以限制 Lambda 可以選擇的執行個體類型。 + **監控執行個體層級指標：**`MemoryUtilization`在容量提供者層級追蹤 `CPUUtilization`和 ，以識別資源限制。 + **檢閱容量指標：**檢查 `vCPUAvailable`和 `MemoryAvailable` ，以確保執行個體上有足夠的資源可用。 ## 容量提供者問題 ### 函數版本無法成為 ACTIVE **問題：**發佈後，您的函數版本會保持待定狀態。 **原因：**Lambda 正在啟動受管執行個體並啟動執行環境。此程序需要時間，尤其是新容量提供者的第一個函數版本。 **解決方案**： 等待 Lambda 完成初始化程序。Lambda 預設會針對 AZ 彈性啟動三個執行個體，並在標記函數版本 ACTIVE 之前啟動三個執行環境。這通常需要幾分鐘的時間。 ### 無法刪除容量提供者 **問題：**嘗試刪除容量提供者時發生錯誤。 **原因：**您無法刪除已連接函數版本的容量提供者。 **解決方案**： 1. 使用容量提供者搭配 `ListFunctionVersionsByCapacityProvider` API 識別所有函數版本。 1. 刪除或更新這些函數版本，以移除容量提供者關聯。 1. 重試刪除容量提供者。 ### 函數發佈期間的一般錯誤訊息 **問題：**發佈函數時，您遇到一般錯誤訊息，例如「發佈期間發生內部錯誤」。 **解決方案**： + **檢查 IAM 許可：**確保您具有嘗試使用的容量提供者的`lambda:PassCapacityProvider`許可。 + **驗證容量提供者組態：**使用 `GetCapacityProvider` API 確認您的容量提供者處於 ACTIVE 狀態。 + **檢閱 VPC 組態：**確保容量提供者中指定的子網路和安全群組已正確設定並可存取。 + **Check AWS CloudTrail 日誌：**檢閱 CloudTrail 日誌，以取得有關失敗操作的詳細錯誤資訊。 ## 監控和可觀測性問題 ### 缺少 CloudWatch 指標 **問題：**您在 CloudWatch 中看不到容量提供者或函數的預期指標。 **原因：**指標每隔 5 分鐘發佈一次。新的容量提供者或函數可能沒有立即可用的指標。 **解決方案**： 在發佈函數版本後等待至少 5-10 分鐘，然後預期指標會出現在 CloudWatch 中。確認您查看的是正確的命名空間 (`AWS/Lambda`) 和維度 (`FunctionName`、 `CapacityProviderName`或 `InstanceType`)。 ### 找不到 CloudWatch 日誌 **問題：**您的函數已成功執行，但無法在 CloudWatch Logs 中找到日誌。 **原因：**Lambda 受管執行個體會在您的 VPC 中執行，並需要網路連線才能將日誌傳送至 CloudWatch Logs。如果沒有適當的 VPC 連線組態，您的函數就無法連線到 CloudWatch Logs 服務端點。 **解決方案**： 設定 VPC 連線，讓您的函數將日誌傳送至 CloudWatch Logs。您有三種選項： **選項 1：CloudWatch Logs 的 VPC 端點 （建議用於生產）** 1. 開啟位於 https：//[console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/) 的 Amazon VPC 主控台。 1. 在導覽窗格中選擇**端點**。 1. 選擇**建立端點**。 1. 在 **Service category** (服務類別) 中，選擇​ **AWS services**。 1. 針對**服務名稱**，選取 `com.amazonaws.region.logs`(`region`取代為您的 AWS 區域）。 1. 針對 **VPC**，選取容量提供者使用的 VPC。 1. 針對**子網路**，選取您要建立端點網路介面的子網路。如需高可用性，請在多個可用區域中選擇子網路。 1. 針對**安全群組**，選取允許來自函數安全群組的傳入 HTTPS 流量 （連接埠 443) 的安全群組。 1. 為端點啟用**私有 DNS**。 1. 選擇**建立端點**。 **選項 2：具有網際網路閘道的公有子網路** 如果您的容量提供者使用公有子網路，請確保： 1. 網際網路閘道已連接至您的 VPC 1. 路由表會將`0.0.0.0/0`流量路由至網際網路閘道 1. 安全群組允許連接埠 443 上的傳出 HTTPS 流量 **選項 3：具有 NAT 閘道的私有子網路** 如果您的容量提供者使用私有子網路，請確保： 1. NAT 閘道存在於公有子網路中 1. 私有子網路路由表會將`0.0.0.0/0`流量路由至 NAT 閘道 1. 公有子網路路由表會將`0.0.0.0/0`流量路由至網際網路閘道 1. 安全群組允許連接埠 443 上的傳出 HTTPS 流量 如需 VPC 連線選項的詳細指引，請參閱 [Lambda 受管執行個體的 VPC 連線](lambda-managed-instances-networking.md)。 ### 從並行請求關聯日誌有困難 **問題：**來自不同請求的日誌會交錯，因此難以追蹤個別請求。 **原因：**在多並行系統中，預期日誌交錯和標準行為。 **解決方案**： + **使用 JSON 格式的結構化記錄：**在所有日誌陳述式中包含請求 ID + **Java：**搭配 使用 Log4j `ThreadContext` 來自動包含請求 ID + **Node.js：**`console.log()`搭配 JSON 格式使用，並包含 `InvokeStore.getRequestId()` + **Python：**使用標準記錄模組搭配 JSON 格式並包含 `context.request_id` 如需詳細指引，請參閱執行時間特定的文件頁面。 ## 取得其他協助 如果您在嘗試這些解決方案後持續遇到問題： 1. **檢閱 CloudWatch 指標：**檢查容量提供者和執行環境指標，以識別資源限制或擴展問題。 1. **Check AWS CloudTrail 日誌：**檢閱 CloudTrail 日誌，以取得 API 呼叫和錯誤的詳細資訊。 1. **聯絡 AWS 支援：**如果您無法解決問題，請聯絡 AWS 支援，提供有關容量提供者組態、函數組態以及您遇到的特定錯誤訊息的詳細資訊。 ## 後續步驟 + 了解 [Lambda 受管執行個體的容量提供者](lambda-managed-instances-capacity-providers.md) + 了解 [Lambda 受管執行個體的擴展](lambda-managed-instances-scaling.md) + 檢閱 [Java](lambda-managed-instances-java-runtime.md)、[Node.js](lambda-managed-instances-nodejs-runtime.md) 和 [Python](lambda-managed-instances-python-runtime.md) 的執行時間特定指南 + 使用 [CloudWatch 指標](lambda-managed-instances-monitoring.md)監控 Lambda 受管執行個體 + 檢閱 [Lambda 受管執行個體的最佳實務](lambda-managed-instances-best-practices.md)