本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。 # 針對 Lambda 中的問題進行故障診斷 下列主題提供您在使用 Lambda API、主控台或工具時可能遭遇錯誤和問題的故障診斷建議。如果您發現未列在此處的問題，您可以使用此頁面上的 **Feedback (意見回饋)** 按鈕來報告。 如需更多故障診段建議和常見支援問題的解答，請瀏覽 [AWS 知識中心](https://aws.amazon.com/premiumsupport/knowledge-center/#AWS_Lambda)。 如需有關偵錯和疑難排解 Lambda 應用程式的詳細資訊，請參閱無伺服器園地中的[偵錯](https://serverlessland.com/content/service/lambda/guides/aws-lambda-operator-guide/debugging-ops)。 **Topics** + [對 Lambda 中的組態問題進行疑難排解](troubleshooting-configuration.md) + [針對 Lambda 中的部署問題進行疑難排解](troubleshooting-deployment.md) + [針對 Lambda 中的調用問題進行疑難排解](troubleshooting-invocation.md) + [針對 Lambda 中的執行問題進行疑難排解](troubleshooting-execution.md) + [對 Lambda 中的事件來源映射問題進行疑難排解](troubleshooting-event-source-mapping.md) + [針對 Lambda 中的聯網問題進行疑難排解](troubleshooting-networking.md) # 對 Lambda 中的組態問題進行疑難排解 函式組態設定可能會影響 Lambda 函式的整體效能和行為。這些設定可能不會造成實際的函式錯誤，但可能會導致意外的逾時和結果。 下列主題針對您可能遇到的與 Lambda 函式組態設定相關的常見問題，提供疑難排解建議。 **Topics** + [記憶體組態](#memory-config) + [CPU 受限的組態](#cpu-bound-config) + [逾時](#timeouts) + [調用之間的記憶體外洩](#memory-leakage) + [非同步結果傳回至稍後的調用](#asynchronous-results) ## 記憶體組態 您可以將 Lambda 函式設定為使用 128 MB 至 10,240 MB 記憶體。依預設，在主控台中建立的任何函數都會被指派最小數量的記憶體。許多 Lambda 函式在此設定下限下仍具有效能。但是，若要匯入大型程式庫或完成記憶體密集型任務，128 MB 並不足夠。 如果函式的執行速度比預期慢得多，則首先應增大記憶體設定。對於記憶體受限的函數，這將解決瓶頸問題，並可能改善函數的效能。 ## CPU 受限的組態 對於運算密集型操作，如果函式效能慢於預期，這可能是由於函式屬於 CPU 密集型。在這種情況下，函數的運算容量跟不上工作的速度。 雖然 Lambda 不允許您直接修改 CPU 組態，但 CPU 可以透過記憶體設定間接控制。當您配置更多記憶體時，Lambda 服務會按比例配置更多虛擬 CPU。當記憶體設定為 1.8 GB 時，Lambda 函式會配置一個完整的 vCPU；超過此數值後，函式將可使用多個 vCPU 核心。檔記憶設定為 10,240 MB 時，將有 6 個 vCPU 可供使用。換言之，您可以透過增加記憶體配置來改善效能，即使函式並未用完所有記憶體。 ## 逾時 Lambda 函式的[逾時](https://docs.aws.amazon.com/lambda/latest/dg/configuration-console.html)可設定為 1 至 900 秒 (15 分鐘)。依預設，Lambda 主控台會將此設定為 3 秒。逾時值是一種安全閥，可確保函式不會無限期執行。達到逾時值後，Lambda 會停止函式調用。 將逾時值設定為接近函數的平均持續時間會提高函數意外逾時的風險。函數的持續時間會有所不同，這取決於資料傳輸和處理量，以及函數與之互動的任何服務的延遲。逾時的常見原因包括： + 從 S3 儲存貯體或其他資料存放區下載資料時，下載量較大或下載時間較平均時間長。 + 函數會向另一個服務提出請求，這需要更長的時間才能回應。 + 提供給函數的參數要求函數具有更高的運算複雜性，這會導致調用時間更長。 測試應用程式時，請確保測試可準確反映資料的大小和數量以及真實的參數值。重要的是，使用工作負載合理預期上限的資料集。 此外，只要可行，就在工作負載中實作上限限制。在本範例中，應用程式可以使用每種檔案類型的大小上限。然後，您可以測試應用程式在一系列預期檔案大小 (最高可達並包括上限) 下的效能。 ## 調用之間的記憶體外洩 Lambda 調用 INIT 階段儲存的全域變數和物件會在暖調用之間保留其狀態。它們只會在執行環境第一次執行 (也稱為「冷啟動」) 時完全重設。處理常式結束時，儲存在處理常式中的變數都會銷毀。最佳實務是使用 INIT 階段設定資料庫連線、載入程式庫、建立快取，以及載入不可變的資產。 在同一執行環境中跨多個調用使用第三方程式庫時，需要查閱其在無伺服器運算環境中的使用說明文件。有些資料庫連線和日誌記錄程式庫可能會儲存中繼調用結果和其他資料。這會導致這些程式庫的記憶體使用量隨著後續暖調用而增加。在此情況下，您可能會發現 Lambda 函式耗盡記憶體，即使自訂程式碼正確處理變數也是如此。 此問題會影響暖執行環境中發生的調用。例如，下列程式碼會在調用之間造成記憶體外洩。Lambda 函數透過增加全域陣列的大小，在每次調用時使用額外的記憶體： ``` let a = [] exports.handler = async (event) => { a.push(Array(100000).fill(1)) } ``` 使用 128 MB 的記憶體設定，在調用此函式 1000 次之後，Lambda 函式的**監控**索引標籤會顯示發生記憶體外洩時典型的調用、持續時間和錯誤計數變更： ![\[除錯操作圖 4\]](http://docs.aws.amazon.com/zh_tw/lambda/latest/dg/images/debugging-ops-figure-4.png) 1. **調用**：由於調用需要更長的時間才能完成，因此穩定的交易速率會定期中斷。狀態穩定時，記憶體外洩不會耗用函數配置的所有記憶體。隨著效能降低，作業系統正在對本機儲存體進行分頁，以容納函數所需的不斷增長的記憶體，這會導致完成的交易數減少。 1. **持續時間**：在函式耗盡記憶體之前，會穩定地以兩位數毫秒速率完成調用。分頁發生時，持續時間會增加一個數量級。 1. **錯誤計數**：因為記憶體外洩超過配置的記憶體，最終函式因運算超過逾時而出錯，或是執行環境終止函式。 出錯後，Lambda 會重新啟動執行環境，這解釋了為什麼在全部三個圖形中會回到原始狀態。展開 CloudWatch 的持續時間指標可提供最短、最長和平均持續時間統計資料的更多詳細資訊： ![\[除錯操作圖 5\]](http://docs.aws.amazon.com/zh_tw/lambda/latest/dg/images/debugging-ops-figure-5.png) 若要尋找 1000 個調用中產生的錯誤，可以使用 CloudWatch Insights 查詢語言。下列查詢會排除資訊日誌，僅報告錯誤： ``` fields @timestamp, @message | sort @timestamp desc | filter @message not like 'EXTENSION' | filter @message not like 'Lambda Insights' | filter @message not like 'INFO'  | filter @message not like 'REPORT' | filter @message not like 'END' | filter @message not like 'START' ``` 在針對此函數的日誌群組執行時，這表示週期性錯誤是逾時造成的： ![\[除錯操作圖 6\]](http://docs.aws.amazon.com/zh_tw/lambda/latest/dg/images/debugging-ops-figure-6.png) ## 非同步結果傳回至稍後的調用 對於使用非同步模式的函數程式碼，一次調用的回呼結果可能在未來的調用中傳回。此範例使用了 Node.js，但相同的邏輯可套用至使用非同步模式的其他執行時期。函數使用 JavaScript 中的傳統回呼語法。它會呼叫一個非同步函數，該函數具有增量計數器，可追蹤調用次數： ``` let seqId = 0 exports.handler = async (event, context) => { console.log(`Starting: sequence Id=${++seqId}`) doWork(seqId, function(id) { console.log(`Work done: sequence Id=${id}`) }) } function doWork(id, callback) { setTimeout(() => callback(id), 3000) } ``` 連續調用多次時，回呼的結果會出現在後續調用中： ![\[除錯操作圖 7\]](http://docs.aws.amazon.com/zh_tw/lambda/latest/dg/images/debugging-ops-figure-7.png) 1. 程式碼呼叫 `doWork` 函式，將回呼函式最為最後一個參數傳入。 1. `doWork` 函式需要一段時間才能完成，然後才會調用回呼。 1. 函式的日誌記錄指出調用在 `doWork` 函式完成執行之前結束。此外，在開始反覆運算後，正在處理先前反覆運算的回呼，如日誌中所示。 在 JavaScript 中，非同步回呼會使用[事件迴圈](https://developer.mozilla.org/en-US/docs/Web/JavaScript/EventLoop)處理。其他執行時期使用不同機制處理並行。當函式的執行環境結束時，Lambda 會凍結環境，直至下一次調用。恢復後，JavaScript 會繼續處理事件迴圈，此時迴圈包含先前調用的非同步回呼。如果沒有此內容，函數可能會無故執行程式碼並傳回任意資料。事實上，它確實是執行時期並行與執行環境交互的成品。 這會造成前一次調用的隱私資料可能出現在後續的調用中。有兩種方法可以防止或偵測到此行為。首先，JavaScript 提供[非同步和等待關鍵字](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/async_function)來簡化非同步開發，並強制程式碼執行等待非同步呼叫完成。可以使用此方法重寫上述函數，如下所示： ``` let seqId = 0 exports.handler = async (event) => { console.log(`Starting: sequence Id=${++seqId}`) const result = await doWork(seqId) console.log(`Work done: sequence Id=${result}`) } function doWork(id) { return new Promise(resolve => { setTimeout(() => resolve(id), 4000) }) } ``` 使用此語法可防止處理常式在非同步函數完成之前結束。在這種情況下，如果回呼花費的時間超過 Lambda 函數的逾時時間，函數會擲回錯誤，而不是在稍後的調用中傳回回呼結果： ![\[除錯操作圖 8\]](http://docs.aws.amazon.com/zh_tw/lambda/latest/dg/images/debugging-ops-figure-8.png) 1. 程式碼會使用處理常式中的等待關鍵字呼叫非同步 `doWork` 函式。 1. `doWork` 函式需要一段時間才能完成，然後才會解析承諾。 1. 函式會逾時，因為 `doWork` 耗費的時間超過逾時限制允許的時間，而且回呼結果不會在稍後的調用中傳回。 一般而言，您應該確定程式碼中的任何背景程序或回呼在程式碼結束前完成。如果這在您的使用案例中無法做到，可以使用識別符來確定回呼屬於目前的調用。為此，可以使用內容物件提供的 *awsRequestId*。透過將此值傳遞至非同步回呼，您可以將傳遞的值與目前的值進行比較，以偵測回呼是否來自另一個調用： ``` let currentContext exports.handler = async (event, context) => { console.log(`Starting: request id=$\{context.awsRequestId}`) currentContext = context doWork(context.awsRequestId, function(id) { if (id != currentContext.awsRequestId) { console.info(`This callback is from another invocation.`) } }) } function doWork(id, callback) { setTimeout(() => callback(id), 3000) } ``` ![\[除錯操作圖 9\]](http://docs.aws.amazon.com/zh_tw/lambda/latest/dg/images/debugging-ops-figure-9.png) 1. Lambda 函數處理常式採用內容參數，提供對唯一調用請求 ID 的存取權。 1. `awsRequestId` 會傳遞至 doWork 函式。在回呼中，ID 會與目前調用的 `awsRequestId` 進行比較。如果這些值不同，程式碼可以採取相應的動作。 # 針對 Lambda 中的部署問題進行疑難排解 當您更新函數時，Lambda 會透過啟動包含更新程式碼或設定的函數新執行個體，來部署變更。部署錯誤會導致您無法使用新版本，而造成這類錯誤的可能原因包含您部署套件、程式碼、許可或工具的問題。 當您使用 Lambda API 或 等用戶端直接部署更新至函數時 AWS CLI，您可以直接在輸出中看到來自 Lambda 的錯誤。如果您使用 AWS CloudFormation AWS CodeDeploy、 或 等服務 AWS CodePipeline，請在該服務的日誌或事件串流中尋找來自 Lambda 的回應。 下列主題提供您在使用 Lambda API、主控台或工具時可能遭遇錯誤和問題的故障診斷建議。如果您發現未列在此處的問題，您可以使用此頁面上的 **Feedback (意見回饋)** 按鈕來報告。 如需更多故障診段建議和常見支援問題的解答，請瀏覽 [AWS 知識中心](https://aws.amazon.com/premiumsupport/knowledge-center/#AWS_Lambda)。 如需有關偵錯和疑難排解 Lambda 應用程式的詳細資訊，請參閱無伺服器園地中的[偵錯](https://serverlessland.com/content/service/lambda/guides/aws-lambda-operator-guide/debugging-ops)。 **Topics** + [一般：許可遭拒/無法載入此類檔案](#troubleshooting-deployment-denied) + [一般：呼叫 UpdateFunctionCode 時發生錯誤](#troubleshooting-deployment-updatefunctioncode) + [Amazon S3：錯誤代碼 PermanentRedirect。](#troubleshooting-deployment-PermanentRedirect) + [一般：找不到、無法載入、無法匯入、找不到類別、沒有此類檔案或目錄](#troubleshooting-deployment-functionHandler1) + [一般：未定義的方法處理常式](#troubleshooting-deployment-functionHandler2) + [一般：超過 Lambda 程式碼儲存限制](#troubleshooting-deployment-CodeStorageExceeded) + [Lambda：分層轉換失敗](#troubleshooting-deployment-LayerConversionFailed) + [Lambda：InvalidParameterValueException 或 RequestEntityTooLargeException](#troubleshooting-deployment-InvalidParameterValueException1) + [Lambda：InvalidParameterValueException](#troubleshooting-deployment-InvalidParameterValueException2) + [Lambda：並行和記憶體配額](#troubleshooting-deployment-quotas) + [Lambda：佈建並行的別名組態無效](#troubleshooting-deployment-provisioned-concurrency) ## 一般：許可遭拒/無法載入此類檔案 **錯誤：***EACCES：拒絕許可，開啟 '/var/task/index.js'* **錯誤：***無法載入這類檔案 – 函數* **錯誤：***[Errno 13] 拒絕許可：'/var/task/function.py'* Lambda 執行時間需有許可才能讀取部署套裝服務中的檔案。在 Linux 許可八進位標記法中，Lambda 需要 644 個許可 (rw-r--r--) 用於非可執行檔，以及 755 個許可 (rwxr-x) 用於目錄和可執行檔。 在 Linux 和 MacOS 中，使用 `chmod` 命令變更部署套件中檔案和目錄的檔案許可。例如，若要為非可執行檔提供正確的許可，請執行下列命令。 ``` chmod 644 ``` 若要在 Windows 中變更檔案許可，請參閱 Microsoft Windows 文件的 [Set, View, Change, or Remove Permissions on an Object](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc731667(v=ws.10))。 **注意** 如果您未授予 Lambda 存取部署套件中的目錄所需的許可，Lambda 會將這些目錄的許可設定為 755 (rwxr-xr-x)。 ## 一般：呼叫 UpdateFunctionCode 時發生錯誤 **錯誤：***呼叫 UpdateFunctionCode 操作時發生錯誤 (RequestEntityTooLargeException)* 當您將部署套裝服務或 Layer 存檔直接上傳至 Lambda 時，ZIP 檔案的大小限制為 50 MB。若要上傳更大的檔案，請將它存放在 Amazon S3 中並使用 S3Bucket 和 S3Key 參數。 **注意** 當您直接使用 AWS CLI、 AWS SDK 或其他方式上傳檔案時，二進位 ZIP 檔案會轉換為 base64，這會將其大小增加約 30%。若要允許此操作，以及請求中其他參數的大小，Lambda 套用的實際請求大小限制會更大。因此，50 MB 的限制是概略值。 ## Amazon S3：錯誤代碼 PermanentRedirect。 **錯誤：***GetObject 時發生錯誤。S3 錯誤代碼：PermanentRedirect. S3 錯誤訊息：儲存貯體位於此區域：us-east-2。請使用此區域重試請求* 當您從 Amazon S3 儲存貯體上傳函數的部署套件時，儲存貯體必須位於與函數相同的區域。當您在呼叫 [UpdateFunctionCode](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionCode.html) 時指定 Amazon S3 物件，或在 AWS CLI 或 AWS SAM CLI 中使用 套件和部署命令時，可能會發生此問題。為開發應用程式的每個區域建立部署成品儲存貯體。 ## 一般：找不到、無法載入、無法匯入、找不到類別、沒有此類檔案或目錄 **錯誤：** *Cannot find module 'function'* (找不到 'function' 模組) **錯誤：***無法載入這類檔案 – 函數* **錯誤：** *Unable to import module 'function'* (無法匯入 'function' 模組) **錯誤：** *Class not found: function.Handler* (找不到類別：function.Handler) **錯誤：** *fork/exec /var/task/function: no such file or directory* (fork/exec /var/task/function：找不到檔案或目錄) **錯誤：** *Unable to load type 'Function.Handler' from assembly 'Function'.* (無法從 'Function' 組件載入 'Function.Handler' 類型。) 您函數處理器組態中的檔案或類別名稱與您的程式碼不相符。如需詳細資訊，請參閱下一節。 ## 一般：未定義的方法處理常式 **錯誤：** *index.handler is undefined or not exported* (index.handler 未定義或尚未匯出) **錯誤：** *Handler 'handler' missing on module 'function'* ('function' 模組上找不到 'handler' 處理器) **錯誤：** *未定義 \$1 的 `handler' 方法* **錯誤：** *No public method named handleRequest with appropriate method signature found on class function.Handler* (在 function.Handler 類別上找不到具備適當方法簽章，名為 handleRequest 的公有方法) **錯誤：** *Unable to find method 'handleRequest' in type 'Function.Handler' from assembly 'Function'* (在來自 'Function' 組件的 'Function.Handler' 類型中找不到 'handleRequest' 方法) 您函數處理器組態中的處理器方法名稱與您的程式碼不相符。每個執行時間都會定義處理器的命名慣例，例如 *filename*.*methodname*。處理器是您函數程式碼中的方法，執行時間會在調用您的函數時執行該方法。 針對某些語言，Lambda 提供了程式庫，其中包含預期處理器方法具備特定名稱的界面。如需每種語言的處理器命名詳細資訊，請參閱下列主題。 + [使用 Node.js 建置 Lambda 函數](lambda-nodejs.md) + [使用 Python 建置 Lambda 函數](lambda-python.md) + [使用 Ruby 建置 Lambda 函數](lambda-ruby.md) + [使用 Java 建置 Lambda 函數](lambda-java.md) + [使用 Go 建置 Lambda 函數](lambda-golang.md) + [使用 C\$1 建置 Lambda 函數](lambda-csharp.md) + [使用 PowerShell 建置 Lambda 函數](lambda-powershell.md) ## 一般：超過 Lambda 程式碼儲存限制 **錯誤：***超過程式碼儲存限制。* Lambda 會將函式程式碼儲存在帳戶私有的內部 S3 儲存貯體中。每個 AWS 帳戶在每個區域中配置 75 GB 的儲存空間。程式碼儲存包含 Lambda 函數和層使用的總儲存空間。如果您達到配額，在嘗試部署新函數時，會收到 *CodeStorageExceededException*。 透過清理舊版本的函式、移除未使用的程式碼或使用 Lambda 層，即可管理可用的儲存空間。此外，最佳實務是[針對個別工作負載使用個別 AWS 帳戶](concepts-application-design.md#multiple-accounts)，以協助管理儲存配額。 您可以在 Lambda 主控台的**儀表板**子選單下檢視儲存體總用量： ![\[監控可觀測性圖 26\]](http://docs.aws.amazon.com/zh_tw/lambda/latest/dg/images/monitoring-observability-figure-26.png) ## Lambda：分層轉換失敗 **錯誤：***Lambda 分層轉換失敗。如需有關解決此問題的建議，請參閱《Lambda 使用者指南》中的「Lambda 部署問題疑難排解」頁面。* 當您使用分層設定 Lambda 函數，Lambda 會將該分層與函數程式碼合併。如果此程序無法完成，Lambda 便會傳回此錯誤。如果出現此錯誤，請執行下列步驟： + 從分層中刪除所有未使用的檔案 + 刪除分層中的所有符號連結 + 重新命名任何與函數分層中目錄名稱相同的所有檔案 ## Lambda：InvalidParameterValueException 或 RequestEntityTooLargeException **錯誤：***InvalidParameterValueException：Lambda 因為您提供的環境變數超過 4KB 限制，Lambda 無法設定您的環境變數。測量的字串：\$1"A1":"uSFeY5cyPiPn7AtnX5BsM...* **錯誤：** *RequestEntityTooLargeException：請求必須小於 5120 位元組的 UpdateFunctionConfiguration 操作* 儲存在函數組態中的變數物件大小上限不得超過 4,096 個位元組。這包括金鑰名稱、值、引號、逗號和括號。HTTP 請求主體的大小總計也受到限制。 ``` { "FunctionName": "my-function", "FunctionArn": "arn:aws:lambda:us-east-2:123456789012:function:my-function", "Runtime": "nodejs24.x", "Role": "arn:aws:iam::123456789012:role/lambda-role", "Environment": { "Variables": { "BUCKET": "amzn-s3-demo-bucket", "KEY": "file.txt" } }, ... } ``` 在此範例中，物件是 39 個字元，並在其存放為字串 `{"BUCKET":"amzn-s3-demo-bucket","KEY":"file.txt"}` (不含空格) 時，最多佔用 39 個位元組。環境變數值中每個標準 ASCII 字元使用一個位元組。每個延伸的 ASCII 字元和 Unicode 字元可以使用 2 個位元組到 4 個位元組。 ## Lambda：InvalidParameterValueException **錯誤：** *InvalidParameterValueException：因為您提供的環境變數已包含目前不支援修改的預留金鑰，Lambda 無法設定您的環境變數。* Lambda 保留一些環境變數金鑰以供內部使用。例如，執行時間使用的 `AWS_REGION` 可決定目前區域，而且不可置換。但是，執行時間使用的其他變數，例如 `PATH`，可在函數組態中擴充。如需完整清單，請參閱[定義執行時間環境變數](configuration-envvars.md#configuration-envvars-runtime)。 ## Lambda：並行和記憶體配額 **錯誤：***指定的函數 ConcurrentExecutions 使帳戶的 UnreservedConcurrentExecution 降低到其最小值以下* **錯誤：***「MemorySize」值無法滿足限制條件：成員的值必須小於或等於 3008* 當您超過帳戶的並行或記憶體[配額](gettingstarted-limits.md)時，就會發生這些錯誤。新 AWS 帳戶已減少並行和記憶體配額。若要解決與並行相關的錯誤，您可以[請求提高配額](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html)。您無法請求增加記憶體配額。 + **並行：**如果您嘗試使用保留或佈建的並行建立函數，或者您的每個函數並行請求 ([PutFunctionConcurrency](https://docs.aws.amazon.com/lambda/latest/api/API_PutFunctionConcurrency.html)) 超過帳戶的並行配額，便可能發生錯誤。 + **記憶體：**如果分配給函數的記憶體數量超過帳戶的記憶體配額，就會發生錯誤。 ## Lambda：佈建並行的別名組態無效 **錯誤：***佈建並行的別名組態無效* 當您嘗試更新 Lambda 函式的程式碼或組態，而某個具有佈建並行的別名指向有問題的版本時，就會發生此錯誤。Lambda 會為佈建並行預先初始化執行環境，若這些環境因程式碼錯誤、資源限制或受影響的堆疊和別名而無法正確初始化，部署就會失敗。如果遇到此問題，請執行下列步驟： 1. **復原別名：**暫時更新別名，使其指向先前可正常運作的版本。 ``` aws lambda update-alias \ --function-name \ --name \ --function-version ``` 1. **修正 Lambda 初始化程式碼：**確保在處理常式外部執行的初始化程式碼不包含任何未捕捉的例外狀況，並完成用戶端與連線的初始化。 1. **安全地重新部署：**部署已修正的程式碼並發布新版本。接著，更新別名，使其指向已修正的版本。如有必要，也可以重新啟用[佈建並行](provisioned-concurrency.md)。 如果使用 AWS CloudFormation，請更新堆疊定義，`FunctionVersion:!GetAtt version.Version`讓別名指向工作版本： ``` alias: Type: AWS::Lambda::Alias Properties: FunctionName: !Ref function FunctionVersion: !GetAtt version.Version Name: BLUE ProvisionedConcurrencyConfig: ProvisionedConcurrentExecutions: 1 ``` # 針對 Lambda 中的調用問題進行疑難排解 當您調用 Lambda 函數時，Lambda 會先驗證請求並檢查擴展容量，再將事件傳送到您的函數，或是事件佇列 (針對非同步調用)。導致調用錯誤的可能原因包含請求參數、事件結構、函數設定、使用者許可、資源許可或限制等問題。 如果您直接調用函數，您會在 Lambda 的回應中看到調用錯誤。如果您透過事件來源映射或是其他服務以非同步方式調用您的函數，您可能會在日誌、無效字母佇列或是失敗事件目的地上找到錯誤。錯誤處理選項和重試行為會因您調用函數的方式，以及錯誤的類型而有所不同。 如需 `Invoke` 操作可以傳回的錯誤類型清單，請參閱[調用](https://docs.aws.amazon.com/lambda/latest/api/API_Invoke.html)。 **Topics** + [Lambda：函數在初始化階段逾時 (Sandbox.Timedout)](#troubleshooting-timeouts) + [IAM：lambda:InvokeFunction 未獲授權](#troubleshooting-invocation-noauth) + [Lambda：找不到有效的引導程序 (Runtime.InvalidEntrypoint)](#troubleshooting-invocation-bootstrap) + [Lambda：無法執行操作 ResourceConflictException](#troubleshooting-invocation-ResourceConflictException) + [Lambda：函數卡在待定狀態](#troubleshooting-invocation-pending) + [Lambda：一個函數正在使用所有並行](#troubleshooting-invocation-allconcurrency) + [一般：無法使用其他帳戶或服務調用函數](#troubleshooting-invocation-cannotinvoke) + [一般：函數調用正在循環](#troubleshooting-invocation-loop) + [Lambda：具有佈建並行的別名路由](#troubleshooting-invocation-alias) + [Lambda：使用佈建並行的冷啟動](#troubleshooting-invocation-coldstart) + [Lambda：新版本的冷啟動](#troubleshooting-invocation-newversion) + [Lambda：未預期的 Node.js 在執行時間結束 (Runtime.NodejsExit)](#troubleshooting-invocation-nodejs-exit) + [EFS：函數無法掛載 EFS 檔案系統](#troubleshooting-invocation-efsmount) + [EFS：函數無法連線到 EFS 檔案系統](#troubleshooting-invocation-efsconnect) + [EFS：因為逾時，函數無法掛載 EFS 檔案系統](#troubleshooting-invocation-efstimeout) + [Lambda：Lambda 偵測到耗時太久的 IO 程序](#troubleshooting-invocation-ioprocess) + [容器：CodeArtifactUserException 錯誤](#troubleshooting-deployment-container-artifact) + [容器：InvalidEntrypoint 錯誤](#troubleshooting-deployment-container-entrypoint) ## Lambda：函數在初始化階段逾時 (Sandbox.Timedout) **錯誤：***任務在 3.00 秒後逾時* 當[初始化](lambda-runtime-environment.md#runtimes-lifecycle-ib)階段出現逾時，Lambda 會在下一個調用請求到達時重新執行`Init`階段，以再次初始化執行環境。(我們將其稱為[隱藏的初始化](lambda-runtime-environment.md#suppressed-init)。) 不過，如果函數設定了較短的[逾時持續時間](configuration-timeout.md) (通常大約 3 秒)，則隱藏的初始化可能無法在配置的逾時前完成，導致`Init`階段再次逾時。或者，隱藏的初始化雖然完成，但留給[調用](lambda-runtime-environment.md#runtimes-lifecycle-invoke)階段的時間不夠，導致後者無法完成，從而造成`Invoke`階段逾時。 若要減少逾時錯誤，請使用以下其中一種或幾種策略： + **延長函數逾時期間**：延長[逾時](configuration-timeout.md)，讓`Init`和`Invoke`階段有時間成功完成。 + **增加分配給函數的記憶體**：更多的[記憶體](configuration-memory.md)意味著更多的 CPU 運算能力，這可以加快`Init`和`Invoke`階段的速度。 + **最佳化函數初始化程式碼**：縮短初始化所需的時間，以確保`Init`和`Invoke`階段可以在設定的逾時內完成。 ## IAM：lambda:InvokeFunction 未獲授權 **錯誤：***使用者 arn:aws:iam::123456789012:user/developer 無權對資源 my-function 執行 lambda:InvokeFunction* 您的使用者或您擔任的角色必須有調用函數的許可。此要求也適用於 Lambda 函數及其他調用函數的運算資源。將 AWS 受管政策 **AWSLambdaRole** 新增至您的使用者，或新增允許對目標函數`lambda:InvokeFunction`執行動作的自訂政策。 **注意** IAM 動作的名稱 (`lambda:InvokeFunction`) 指的是 `Invoke` Lambda API 操作。 如需詳細資訊，請參閱 [在 中管理許可 AWS Lambda](lambda-permissions.md)。 ## Lambda：找不到有效的引導程序 (Runtime.InvalidEntrypoint) **錯誤：***找不到有效的引導程序：[/var/task/bootstrap /opt/bootstrap]* 當部署套件的根層級不包含名為 `bootstrap` 的可執行檔時，通常會發生此錯誤。例如，如果您使用 .zip 檔案部署 `provided.al2023` 函數，則 `bootstrap` 檔案必須位於 .zip 檔案的根層級，而不在目錄中。 ## Lambda：無法執行操作 ResourceConflictException **錯誤：***ResourceConflictException：此時無法執行操作。函數量前處於下列狀態：擱置中* 當您在建立時將函數連接到 Virtual Private Cloud (VPC) 時，函數會在 Lambda 建立彈性網路界面的同時，進入 `Pending` 狀態。在此期間，您無法調用或修改函數。如果您在建立後將函數連接到 VPC，則可以在更新擱置時調用該函數，但無法修改其程式碼或組態。 如需詳細資訊，請參閱 [Lambda 函數狀態](functions-states.md)。 ## Lambda：函數卡在待定狀態 **錯誤：** *函數停留在 `Pending` 狀態幾分鐘的時間。* 如果函數卡在 `Pending` 狀態的時間超過六分鐘，請呼叫下列其中一個 API 操作來解除封鎖： + [UpdateFunctionCode](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionCode.html) + [UpdateFunctionConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionConfiguration.html) + [PublishVersion](https://docs.aws.amazon.com/lambda/latest/api/API_PublishVersion.html) Lambda 會取消待處理的操作並將該函數放入 `Failed` 狀態。您接著可以嘗試另一個更新。 ## Lambda：一個函數正在使用所有並行 **問題：***單一函數正在使用所有可用的並行，造成其他函數遭到調節。* 若要將 區域中 AWS 您帳戶的可用並行分割為集 AWS 區，請使用[預留並行](configuration-concurrency.md)。預留並行可確保函數一律會擴展至其受到指派的並行，且函數擴展的並行也不會超過其受到指派的並行。 ## 一般：無法使用其他帳戶或服務調用函數 **問題：***您可以直接調用函數，但當其他服務或帳戶調用該函數時，它不會執行。* 您在函數[以資源為基礎的政策](access-control-resource-based.md)中，授予[其他服務和](lambda-services.md)帳戶調用函數的許可。如果調用者屬於另一個帳戶，則該使用者也必須具備[函數的調用許可](access-control-identity-based.md)。 ## 一般：函數調用正在循環 **問題：** *在迴圈中連續調用函數。* 這通常發生在函數在觸發它的相同 AWS 服務中管理資源時。例如，可以建立函數，將物件存放在所設定的 Amazon Simple Storage Service (Amazon S3) 儲存貯體中，該儲存貯體具有[再次調用函數的通知](with-s3.md)。若要阻止函數執行，可將函數的可用[並行處理](lambda-concurrency.md)降為零，這會限制所有將來的調用。然後，識別造成遞迴調用的程式碼路徑或組態錯誤。Lambda 會自動偵測並停止某些 AWS 服務和 SDKs遞迴迴圈。如需詳細資訊，請參閱[使用 Lambda 遞迴迴圈偵測功能防止無限迴圈](invocation-recursion.md)。 ## Lambda：具有佈建並行的別名路由 **問題：** *在別名路由期間佈建並行溢出調用。* Lambda 使用簡單的概率模型來在兩個函數版本之間分配流量。在流量較低時，您可能會看到每個版本已設定流量百分比與實際流量百分比之間，存在很大差異。如果您的函數使用佈建並行，透過在別名路由作用期間設定較高數目的已佈建並行執行個體，則可以避免[溢出調用](monitoring-metrics-types.md#invocation-metrics)。 ## Lambda：使用佈建並行的冷啟動 **問題：***啟用佈建的並行後，您會看到冷啟動。* 當函數上的並行執行次數少於或等於[已設定的佈建並行層級](provisioned-concurrency.md)，則不應該發生任何冷啟動。若要協助您確認佈建的並行是否能正常運作，請執行下列動作： + 請在函數版本或別名上[檢查佈建的並行是否啟用](provisioned-concurrency.md)。 **注意** [函數的未發佈版本](configuration-versions.md) (\$1LATEST) 無法設定佈建並行。 + 確保您的觸發條件調用的是正確的函數版本或別名。例如，如果您使用的是 Amazon API Gateway，請檢查 API Gateway 調用的函數版本或別名具有佈建的並行，而不是 \$1LATEST。若要確認正在使用佈建的並行，您可以檢查 [ProvisionedConcurrencyInvocations Amazon CloudWatch 指標](monitoring-concurrency.md#provisioned-concurrency-metrics)。非零值表示函數正在初始化執行環境上處理調用。 + 判斷您的函數並行是否超過已佈建並行的設定層級，方法是檢查 [ProvisionedConcurrencySpilloverInvocations CloudWatch 指標](monitoring-concurrency.md#provisioned-concurrency-metrics)。非零值表示所有已佈建的並行處於使用中的狀態，而某些調用會在冷啟動時發生。 + 檢查[調用頻率](gettingstarted-limits.md#api-requests) (每秒請求數)。具有佈建並行的函數，每個佈建並行的請求速率上限為每秒 10 個。例如，設定為具備 100 個佈建並行的函數每秒可以處理 1,000 個請求。如果調用速率超過每秒 1,000 個請求，就可能會發生冷啟動。 ## Lambda：新版本的冷啟動 **問題：***在部署新版的函數時，您會看到冷啟動。* 當您更新函數別名時，Lambda 會根據別名上設定的權重，自動將佈建的並行移至新版本。 **錯誤：***KMSDisabledException：因為使用的 KMS 金鑰已停用，Lambda 無法解密環境變數。請檢查函數的 KMS 金鑰設定。* 如果您的 AWS Key Management Service (AWS KMS) 金鑰已停用，或如果允許 Lambda 使用該金鑰的授予遭到撤銷，則可能會發生此錯誤。如果授權遺失，請將函數設定為使用不同的金鑰。然後重新分配自訂金鑰以重新建立授權。 ## Lambda：未預期的 Node.js 在執行時間結束 (Runtime.NodejsExit) **問題：***Lambda 執行期用戶端偵測到非預期的 Node.js 結束碼。* 當您的函數在解決所有 Promises 之前結束時，就會發生此錯誤，例如由於程式碼錯誤。當 Node.js 偵測到防止 Promises 解決的死結時，也可能發生這種情況。此錯誤只會影響非同步樣式處理常式，不會影響回呼樣式處理常式。 **受影響的執行時間：**Node.js 18 及更新版本。 **若要解決此問題：** 1. 檢查您的函數程式碼是否有非同步處理常式中未解決的承諾。 1. 在函數完成之前，確保所有承諾都已正確解決 （已解決或拒絕）。 1. 檢閱您的程式碼是否有非同步操作中的潛在競爭條件。 如需 Node.js 結束代碼和程序終止的詳細資訊，請參閱 [Node.js 文件](https://nodejs.org/docs/latest/api/process.html#exit-codes)。 ## EFS：函數無法掛載 EFS 檔案系統 **錯誤：***EFSMountFailureException：函數無法使用存取點 arn:aws:elasticfilesystem:us-east-2:123456789012:access-point/fsap-015cxmplb72b405fd 掛載 EFS 檔案系統。* 對[檔案系統](configuration-filesystem.md)的掛載要求已遭拒。檢查函數的許可，並確認其檔案系統和存取點是否存在，且可供使用。 ## EFS：函數無法連線到 EFS 檔案系統 **錯誤：***EFSMountConnectivityException：函數無法使用存取點 arn:aws:elasticfilesystem:us-east-2:123456789012:access-point/fsap-015cxmplb72b405fd 連線至 Amazon EFS 檔案系統。請檢查您的網路組態，並再試一次。* 函數無法使用 NFS 通訊協定 (TCP 連接埠 2049) 建立函數[檔案系統](configuration-filesystem.md)的連線。為 VPC 的子網路檢查[安全群組與路由組態](https://docs.aws.amazon.com/efs/latest/ug/network-access.html)。 如果您在更新函數的 VPC 組態設定後遇到這些錯誤，請嘗試卸載並重新掛載檔案系統。 ## EFS：因為逾時，函數無法掛載 EFS 檔案系統 **錯誤：***EFSMountTimeoutException：由於掛載逾時，函數無法使用存取點 \$1arn:aws:elasticfilesystem:us-east-2:123456789012:access-point/fsap-015cxmplb72b405fd\$1 掛載 EFS 檔案系統*。 函數可以連線至函數的[檔案系統](configuration-filesystem.md)，但掛載操作逾時。稍後再試一次，並考慮限制函數的[並行數量](configuration-concurrency.md)，以減少檔案系統的負載。 ## Lambda：Lambda 偵測到耗時太久的 IO 程序 *EFSIOException：函數執行個體已停止，因為 Lambda 偵測到耗時太久的 IO 處理序。* 先前的調用逾時，而且 Lambda 無法終止函數處理常式。當附加的檔案系統用完高載額度，且基準輸送量不足時，可能會發生此問題。若要增加輸送量，您可以增加檔案系統的大小，或使用佈建的輸送量。 ## 容器：CodeArtifactUserException 錯誤 **錯誤：***CodeArtifactUserPendingException 錯誤訊息* CodeArtifact 正在等待最佳化。當 Lambda 完成最佳化時，函式會轉換為[作用中狀態](functions-states.md)。HTTP 回應代碼 409。 **錯誤：***CodeArtifactUserDeletedException 錯誤訊息* CodeArtifact 已排程待刪除。HTTP 回應代碼 409。 **錯誤：***CodeArtifactUserFailedException 錯誤訊息* Lambda 無法最佳化程式碼。您需要更正程式碼並重新上傳。HTTP 回應代碼 409。 ## 容器：InvalidEntrypoint 錯誤 **錯誤：***Runtime.ExitError 或 "errorType": "Runtime.InvalidEntrypoint"* 確認容器映像的 ENTRYPOINT 包含作為位置的絕對路徑。同時請確認映像不含作為 ENTRYPOINT 的符號連結。 **錯誤：***您正在使用 CloudFormation 範本，且您的容器 ENTRYPOINT 正在以 null 或空值覆寫。* 檢閱 CloudFormation 範本中的 [ImageConfig](https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/aws-properties-lambda-function-imageconfig.html) 資源。如果您在範本中宣告 `ImageConfig` 資源，則必須為所有三個屬性提供非空值。 # 針對 Lambda 中的執行問題進行疑難排解 當 Lambda 執行時間執行您的函數程式碼時，可能會在已經處理事件一段時間的函數執行個體上處理事件，或是需要初始化新的執行個體。函數初始化期間、您的處理器程式碼處理事件時，或是您的函數傳回回應時 (或是無法傳回時)，都可能會發生錯誤。 造成函數執行錯誤的可能原因包含了您程式碼、函數組態、下游資源或是許可的問題。如果您直接叫用您的函數，您會在 Lambda 的回應中看到函數錯誤。如果您透過事件來源映射或是其他服務以非同步方式叫用您的函數，您可能會在日誌、無效字母佇列或是失敗的目的地上找到錯誤。錯誤處理選項和重試行為會因您叫用函數的方式，以及錯誤的類型而有所不同。 當您的函數程式碼或 Lambda 執行時間傳回錯誤時，Lambda 回應中的狀態碼將會是 200 OK。名為 `X-Amz-Function-Error` 的標頭指示回應中存在錯誤。400 和 500 系列的狀態碼為[叫用錯誤](troubleshooting-invocation.md)預留。 **Topics** + [Lambda：使用 Visual Studio Code 進行遠端偵錯](#troubleshooting-execution-remote-debugging) + [Lambda：執行時間太長](#troubleshooting-execution-toolong) + [Lambda：非預期的事件承載](#troubleshooting-execution-unexpected-payload) + [Lambda：出乎意料的大型承載大小](#troubleshooting-execution-large-payload) + [Lambda：JSON 編碼與解碼錯誤](#troubleshooting-execution-json-encoding) + [Lambda：日誌或追蹤沒有出現](#troubleshooting-execution-logstraces) + [Lambda：並非所有函數的日誌都會顯示](#troubleshooting-execution-missinglogs) + [Lambda：該函數在執行完成之前傳回](#troubleshooting-execution-unfinished) + [Lambda：執行非預期的函式版本或別名](#unintended-function) + [Lambda：偵測無限迴圈](#infinite-loops) + [一般：下游服務無法使用](#downstream-unavailability) + [AWS SDK：版本和更新](#troubleshooting-execution-versions) + [Python：程式庫的載入不正確](#troubleshooting-execution-libraries) + [Java：從 Java 11 更新至 Java 17 後，函數需要更長的時間來處理事件](#troubleshooting-execution-java-perf) + [Kafka：處理和重試組態問題時發生錯誤](#troubleshooting-kafka-error-handling) ## Lambda：使用 Visual Studio Code 進行遠端偵錯 **問題：***在實際 AWS 環境中難以疑難排解複雜的 Lambda 函數行為* Lambda 透過 AWS Toolkit for Visual Studio Code提供遠端偵錯功能。如需設定與一般說明，請參閱[使用 Visual Studio Code 遠端偵錯 Lambda 函式](debugging.md)。 如需疑難排解、進階使用案例和區域可用性的詳細說明，請參閱 AWS Toolkit for Visual Studio Code 《 使用者指南》中的[遠端偵錯 Lambda 函數](https://docs.aws.amazon.com/toolkit-for-vscode/latest/userguide/lambda-remote-debug.html)。 ## Lambda：執行時間太長 **問題：***函數執行時間過長。* 如果您的程式碼在 Lambda 中執行的時間比在本機機器上長，可能是因為函數可用的記憶體或處理能力受到限制。[設定函數使用額外記憶體](configuration-memory.md)以同時增加記憶體和 CPU。 ## Lambda：非預期的事件承載 **問題：***函式因格式錯誤的 JSON 或資料驗證不完整而出現錯誤。* 所有的 Lambda 函數都會在處理常式的第一個參數中接收事件承載。事件承載是 JSON 結構，可能包含陣列和巢狀元素。 當上游服務未使用可靠的流程來檢查其 JSON 結構時，可能會出現 JSON 格式錯誤的問題。當服務串接文字字串或嵌入尚未經過消毒的使用者輸入時，就會發生這種情況。JSON 也經常被序列化，以便在服務之間傳遞。一律做為 JSON 的生產者和消費者剖析 JSON 結構，以確定結構有效。 同樣地，不檢查事件承載中的值範圍可能導致錯誤。此範例顯示計算預扣稅的函數： ``` exports.handler = async (event) => { let pct = event.taxPct let salary = event.salary // Calculate % of paycheck for taxes return (salary * pct) } ``` 此函數使用事件承載中的薪資和稅率執行計算。但是，程式碼無法檢查屬性是否存在。它也無法檢查資料類型，或確定界限，例如確定稅率在 0 和 1 之間。因此，這些邊界以外的值將產生無意義的結果。類型不正確或缺少屬性會導致執行時期錯誤。 建立測試以確定您的函數能夠處理較大的承載。Lambda 事件承載的大小上限為 1 MB。視內容而定，較大的承載可能表示傳遞到函數的項目較多，或內嵌在 JSON 屬性中的二進位資料較多。在這兩種情況下，都可能導致 Lambda 函數的處理量增加。 較大的承載也可能導致逾時。例如，Lambda 函數每 100 毫秒處理一筆記錄，逾時 3 秒。承載中 0-29 個項目的處理成功。但是，一旦承載中的項目數超過 30，函數就會逾時並擲回錯誤。為避免這種情況，請確定設定超時，以處理預期最大項目數的額外處理時間。 ## Lambda：出乎意料的大型承載大小 **問題：***函式因大型承載而逾時或導致錯誤。* 較大的承載可能導致逾時和錯誤。建議建立測試，確保函式能夠處理預期的最大承載量，並確保函式逾時設定正確。 此外，某些事件承載可能包含指向其他資源的指標。例如，具有 128 MB 記憶體的 Lambda 函式，可以對以物件形式儲存於 S3 的 JPG 檔案進行映像處理。對於較小的映像檔案，函數可如預期執行。不過，當提供較大的 JPG 檔案做為輸入時，Lambda 函數會因為記憶體耗盡而擲出錯誤。為避免這種情況，測試案例應包含預期資料大小上限的範例。程式碼也應驗證承載大小。 ## Lambda：JSON 編碼與解碼錯誤 **問題：***剖析 JSON 輸入時發生 NoSuchKey 例外狀況。* 進行檢查，確保正確處理 JSON 屬性。例如，對於 S3 產生的事件，`s3.object.key` 屬性包含經過 URL 編碼的物件索引鍵名稱。許多函數會將此屬性當成文字來處理，以載入引用的 S3 物件： **Example** ``` const originalText = await s3.getObject({ Bucket: event.Records[0].s3.bucket.name, Key: event.Records[0].s3.object.key }).promise() ``` 此程式碼可與金鑰名稱 `james.jpg` 搭配使用，但在名稱為 `james beswick.jpg` 時擲出 `NoSuchKey` 錯誤。由於 URL 編碼會在金鑰名稱中轉換空格和其他字元，因此必須先確定函數解碼金鑰，再使用此資料： **Example** ``` const originalText = await s3.getObject({ Bucket: event.Records[0].s3.bucket.name, Key: decodeURIComponent(event.Records[0].s3.object.key.replace(/\+/g, " ")) }).promise() ``` ## Lambda：日誌或追蹤沒有出現 **問題：** *日誌未出現在 CloudWatch Logs 中。* **問題：***追蹤不會出現在 中 AWS X-Ray。* 您的函數需要許可才能呼叫 CloudWatch Logs 和 X-Ray。更新其[執行角色](lambda-intro-execution-role.md)以授予許可。新增下列受管政策來啟用日誌和追蹤。 + **AWSLambdaBasicExecutionRole** + **AWSXRayDaemonWriteAccess** 將許可新增至您的函數時，亦請對其程式碼或組態進行細微更新。若您函數的執行中執行個體具有已過期的憑證，上述動作會強制停止並取代這些執行個體。 **注意** 在函數調用後，日誌可能需要 5 到 10 分鐘才會顯示。 ## Lambda：並非所有函數的日誌都會顯示 **問題：***即使我有正確的許可，但 CloudWatch Logs 缺少函數日誌* 如果您的 AWS 帳戶 達到其 [CloudWatch Logs 配額限制](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/cloudwatch_limits_cwl.html)，CloudWatch 會調節函數記錄。發生這種情況時，您的函數的一些日誌輸出可能不會在 CloudWatch Logs 中顯示。 如果您的函數輸出日誌的速度過快，Lambda 無法處理它們，這也有可能導致日誌輸出不在 CloudWatch Logs 中顯示。當 Lambda 無法以函數產生日誌的速度將它們傳送到 CloudWatch 時，它會捨棄日誌以防止函數的執行速度變慢。當日誌輸送量單一日誌串流超過 2 MB/s 時，預期會持續觀察到日誌遭捨棄。 如果函數設定為使用 [JSON 格式日誌](monitoring-cloudwatchlogs-logformat.md)，Lambda 會嘗試在捨棄日誌時將[`logsDropped`](telemetry-schema-reference.md#platform-logsDropped) 事件傳送至 CloudWatch Logs。不過，當 CloudWatch 對函數的日誌記錄進行限流時，此事件可能無法到達 CloudWatch Logs，因此當 Lambda 捨棄記錄時，您不一定會看到記錄。 若要檢查您的 AWS 帳戶 是否已達到其 CloudWatch Logs 配額限制，請執行下列動作： 1. 開啟 [Service Quotas 主控台](https://console.aws.amazon.com/servicequotas)。 1. 在導覽窗格中，選擇 **AWS services (AWS 服務)**。 1. 對於 **AWS services** 清單，搜尋並選取 Amazon CloudWatch Logs。 1. 在 **Service Quotas** 清單中，選擇 `CreateLogGroup throttle limit in transactions per second`、`CreateLogStream throttle limit in transactions per second` 和 `PutLogEvents throttle limit in transactions per second` 配額，以檢視您的使用率。 您也可以設定 CloudWatch 警示，以便在帳戶利用率超過您為這些配額指定的限制時提醒您。請參閱[建立以靜態閾值為基礎的 CloudWatch 警示](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ConsoleAlarms.html)，以了解詳細資訊。 如果 CloudWatch Logs 的預設配額限制不足以滿足您的使用案例，您可以[請求提高配額](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html)。 ## Lambda：該函數在執行完成之前傳回 **問題：(Node.js)*** 函數在程式碼完成執行前傳回* 包括 AWS SDK 在內的許多程式庫會以非同步方式運作。當您進行網路呼叫或是執行需要等待回應的其他操作時，程式庫會傳回稱為 promise 的物件，在背景追蹤操作的進度。 若要等待 promise 解析為回應，請使用 `await` 關鍵字。這會阻止您的處理器在包含回應的 promise 解析為物件前執行。如果您不需要在程式碼中使用回應中的資料，您可以直接將 promise 傳回執行時間。 有些程式庫不會傳回 promise，但是可以包裝在傳回 promise 的程式碼中。如需詳細資訊，請參閱[在 Node.js 中定義 Lambda 函數處理常式](nodejs-handler.md)。 ## Lambda：執行非預期的函式版本或別名 **問題：***未調用的函式版本或別名* 當您在主控台或使用 發佈新的 Lambda 函數時 AWS SAM，最新的程式碼版本會以 表示`$LATEST`。依預設，未指定版本或別名的調用會自動指向函式程式碼的 `$LATEST` 版本。 如果使用特定的函式版本或別名，這些是除了 `$LATEST` 之外不可變的已發布函式版本。對這些函式進行疑難排解時，請先確定呼叫者已調用預期的版本或別名。您可以透過檢查函式日誌來完成此操作。所調用的函式版本會始終顯示在 START 日誌行中： ![\[除錯操作圖 1\]](http://docs.aws.amazon.com/zh_tw/lambda/latest/dg/images/debugging-ops-figure-1.png) ## Lambda：偵測無限迴圈 **問題：***因 Lambda 函式而導致無限迴圈模式* Lambda 函數中有兩種無限迴圈類型。第一種在函式本身內部，由一個永不結束的迴圈造成。調用只會在函式逾時之時結束。您可以透過監控逾時來識別這些情況，然後修正迴圈行為。 第二種迴圈類型介於 Lambda 函數和其他 AWS 資源之間。當來自 S3 儲存貯體等資源的事件調用 Lambda 函數，然後該函數與相同來源的資源交互以觸發另一個事件時，就會發生這些情況。這會再次調用函式，進而與同一個 S3 儲存貯體建立另一次互動，依此類推。這些類型的迴圈可能由許多不同的 AWS 事件來源造成，包括 Amazon SQS 佇列和 DynamoDB 資料表。您可以使用[遞迴迴圈偵測](invocation-recursion.md)功能來識別這些模式。 ![\[除錯操作圖 2\]](http://docs.aws.amazon.com/zh_tw/lambda/latest/dg/images/debugging-ops-figure-2.png) 透過確保 Lambda 函式寫入與取用端資源不同的資源，即可避免這些迴圈。如果必須將資料發布回取用端資源，請確保新資料不會觸發相同的事件。或者，使用[事件篩選](invocation-eventfiltering.md)功能。例如，以下是針對 S3 和 DynamoDB 資源無限迴圈的兩種建議解決方案： + 如果寫回同一個 S3 儲存貯體，請使用與事件觸發程序不同的字首或尾碼。 + 如果將項目寫入同一個 DynamoDB 資料表，請包含取用端 Lambda 函式可以篩選的屬性。如果 Lambda 找到該屬性，則不會導致另一次調用。 ## 一般：下游服務無法使用 **問題：***Lambda 函式所依賴的下游服務無法使用* 對於呼叫第三方端點或其他下游資源的 Lambda 函式，確保其具備處理服務錯誤與逾時的能力。這些下游資源可能具有可變回應時間，或可能因服務中斷而無法使用。根據實作，如果未在函式程式碼內處理服務的錯誤回應，這些下游錯誤可能顯示為 Lambda 逾時或例外狀況。 每當函式依賴下游服務時 (例如 API 呼叫)，請實作適當的錯誤處理和重試邏輯。對於關鍵服務，Lambda 函式應將指標或日誌發布到 CloudWatch。例如，若第三方付款 API 無法使用，Lambda 函式可以記錄此資訊。然後，您可以設定 CloudWatch 警示來傳送與這些錯誤相關的通知。 由於 Lambda 可以快速擴展，非無伺服器下游服務可能難以應對流量激增的狀況。有三種常見的應對方法： + **快取**：如果第三方服務傳回的值不會經常變更，建議快取這些結果。您可以將這些值儲存於函式的全域變數中或其他服務中。例如，來自 Amazon RDS 執行個體的產品清單查詢結果可以在函數內儲存一段時間，以防備援查詢。 + **佇列**：儲存或更新資料時，在 Lambda 函式與資源之間新增 Amazon SQS 佇列。在下游服務處理訊息時，佇列會持久保留資料。 + **代理**：通常使用長效連線 (例如 Amazon RDS 執行個體)，使用代理層來匯集和重複使用這些連線。對於關聯式資料庫，[Amazon RDS Proxy](https://github.com/aws-samples/s3-to-lambda-patterns/tree/master/docrepository) 是一種服務，旨在協助改善以 Lambda 為基礎的應用程式的可擴展性和彈性。 ## AWS SDK：版本和更新 **問題：***執行時間中包含的 AWS SDK 不是最新版本* **問題：***執行時間更新中包含的 AWS SDK 會自動更新* 解譯語言的執行時間包括 AWS SDK 的版本。Lambda 會定期更新這些執行時期，使用最新的 SDK 版本。若要查詢執行時期內含的 SDK 版本，請參閱下列章節： + [執行時期內含 SDK 版本 (Node.js)](lambda-nodejs.md#nodejs-sdk-included) + [執行時期內含 SDK 版本 (Python)](lambda-python.md#python-sdk-included) + [執行時期內含 SDK 版本 (Ruby)](lambda-ruby.md#ruby-sdk-included) 若要使用較新版本的 AWS SDK，或將函數鎖定到特定版本，您可以將程式庫與函數程式碼綁定，或[建立 Lambda 層](chapter-layers.md)。如需建立包含相依性部署套件的詳細資訊，請參閱下列主題： ------ #### [ Node.js ] [使用 .zip 封存檔部署 Node.js Lambda 函數](nodejs-package.md) ------ #### [ Python ] [使用 .zip 封存檔部署 Python Lambda 函數](python-package.md) ------ #### [ Ruby ] [使用 .zip 封存檔部署 Ruby Lambda 函數](ruby-package.md) ------ #### [ Java ] [使用 .zip 或 JAR 封存檔部署 Java Lambda 函數](java-package.md) ------ #### [ Go ] [使用 .zip 封存檔部署 Go Lambda 函數](golang-package.md) ------ #### [ C\$1 ] [使用 .zip 封存檔建置和部署 C＃ Lambda 函數](csharp-package.md) ------ #### [ PowerShell ] [使用 .zip 封存檔部署 PowerShell Lambda 函數](powershell-package.md) ------ ## Python：程式庫的載入不正確 **問題：**(Python) *有些程式庫無法從部署套件正確載入* 使用以 C 或 C\$1\$1 撰寫延伸模組的程式庫必須在處理器架構與 Lambda 相同的環境中編譯 (Amazon Linux)。如需詳細資訊，請參閱[使用 .zip 封存檔部署 Python Lambda 函數](python-package.md)。 ## Java：從 Java 11 更新至 Java 17 後，函數需要更長的時間來處理事件 **問題：**(Java) *從 Java 11 更新至 Java 17 後，函數需要更長的時間來處理事件* 使用 `JAVA_TOOL_OPTIONS` 參數調校編譯器。Java 17 和更新版本的 Lambda 執行時期變更了預設的編譯器選項。此變更可改善短期函數的冷啟動時間，但先前的行為更適合長時間執行的運算密集函數。將 `JAVA_TOOL_OPTIONS` 設定為 `-XX:-TieredCompilation` 以還原至 Java 11 的行為。如需 `JAVA_TOOL_OPTIONS` 參數的詳細資訊，請參閱 [了解 `JAVA_TOOL_OPTIONS` 環境變數](java-customization.md#java-tool-options)。 ## Kafka：處理和重試組態問題時發生錯誤 **問題：***Kafka 事件來源映射無法設定重試設定或失敗時的目的地* Kafka 重試組態和故障時目的地僅適用於啟用佈建模式的事件來源映射。在嘗試設定重試組態`ProvisionedPollerConfig`之前，請確定您已在 `MinimumPollers`中設定 。 常見的組態錯誤： + **使用 bisect 批次無限次重試** – 當 `MaximumRetryAttempts` 設定為 -1 （無限） `BisectBatchOnFunctionError`時，您無法啟用 。設定有限重試限制或停用平分批次。 + **相同主題遞迴** – Kafka 失敗時目的地主題不能與您的任何來源主題相同。為您的無效字母主題選擇不同的主題名稱。 + **無效的 Kafka 目的地格式** – 將 Kafka 主題指定為失敗時的目的地時，請使用 `kafka://` 格式。 + **kafka：WriteData 許可問題** – 確保您的執行角色具有目的地主題的`kafka-cluster:WriteData`許可。主題不存在逾時例外狀況，或寫入 API 限流問題可能需要提高帳戶限制。 # 對 Lambda 中的事件來源映射問題進行疑難排解 Lambda 中與[事件來源映射](invocation-eventsourcemapping.md)相關的問題可能較為複雜，因為涉及在多個服務中進行除錯。此外，事件來源行為可能會因所使用的具體事件來源而有所不同。本節列出了涉及事件來源映射的常見問題，也提供了如何識別並進行疑難排解的指導。 **注意** 本節使用 Amazon SQS 事件來源作為說明，但其原則同樣適用於其他為 Lambda 函式佇列訊息的事件來源映射。 ## 識別和管理限流 在 Lambda 中，當達到函式或帳戶的並行限制時，就會發生限流。建議參考下列範例，其中有從 Amazon SQS 佇列讀取訊息的 Lambda 函式。該 Lambda 函式模擬 30 秒的調用時間，且批次大小為 1。這表示函式每 30 秒僅能處理 1 則訊息： ``` const doWork = (ms) => new Promise(resolve => setTimeout(resolve, ms)) exports.handler = async (event) => { await doWork(30000) } ``` 由於調用時間過長，訊息進入佇列的速度會超過處理速度。如果帳戶的未預留並行為 100，Lambda 會向上擴展至 100 個並行執行，隨後便會發生限流。您可以在函數的 CloudWatch 指標中看到此模式： ![\[除錯操作圖 10\]](http://docs.aws.amazon.com/zh_tw/lambda/latest/dg/images/debugging-ops-figure-10.png) 函式的 CloudWatch 指標顯示沒有錯誤，但**並行執行**圖表顯示已達到 100 的並行上限。因此，**限流**圖表顯示限流已生效。 您可以透過 CloudWatch 警示來偵測限流狀況，在函式的限流指標大於 0 時即觸發警示。在您確認限流問題後，有以下幾種解決方案可供選擇： + 請求此區域的 AWS Support 團隊增加並行。 + 識別函數中的效能問題，以提高處理速度，從而改善輸送量。 + 增加函式的批次大小，以便每次調用能處理更多訊息。 ## 處理函數中的錯誤 如果處理函式擲出錯誤，Lambda 會將訊息傳回 SQS 佇列。Lambda 可防止函式擴展，避免出現大規模錯誤。CloudWatch 中的下列 SQS 指標表示佇列處理出現問題： ![\[除錯操作圖 11\]](http://docs.aws.amazon.com/zh_tw/lambda/latest/dg/images/debugging-ops-figure-11.png) 特別是，最舊訊息的存留期和可見訊息的數量都在增加，但沒有訊息被刪除。佇列會繼續成長，但訊息未處理。處理 Lambda 函數的 CloudWatch 指標也表示存在問題： ![\[除錯操作圖 12\]](http://docs.aws.amazon.com/zh_tw/lambda/latest/dg/images/debugging-ops-figure-12.png) **錯誤計數**指標不為零且不斷增加，同時**並行執行**已減少且限流已停止。這表示 Lambda 已因錯誤而停止向上擴展函式。函式的 CloudWatch 日誌提供錯誤類型的詳細資訊。 您可以透過先識別導致錯誤的函數，然後尋找並消除錯誤來解決此問題。修正錯誤並部署新版函式程式碼後，CloudWatch 指標會顯示處理復原： ![\[除錯操作圖 13\]](http://docs.aws.amazon.com/zh_tw/lambda/latest/dg/images/debugging-ops-figure-13.png) 在這裡，**錯誤計數**指標會降至零，**成功率**指標會恢復至 100%。Lambda 會再次開始向上擴展函式，如**並行執行**圖表中所示。 ## 識別和處理背壓 如果事件生產者為 SQS 佇列產生訊息的速度持續快於 Lambda 函式的處理速度，就會產生背壓。在這種情況下，SQS 監控會顯示最舊訊息的存留期以線性方式增長，同時顯示可見訊息的大致數量。可以使用 CloudWatch 警示來偵測佇列中的背壓。 消除背壓的步驟取決於您的工作負載。如果主要目標是提高 Lambda 函式的處理能力與輸送量，有以下選項可用選擇： + 請求特定區域的 AWS Support 團隊增加並行。 + 增加函式的批次大小，以便每次調用能處理更多訊息。 # 針對 Lambda 中的聯網問題進行疑難排解 根據預設，Lambda 會在擁有 AWS 服務及網際網路連線能力的內部 virtual private cloud (VPC) 中執行您的函數。若要存取本機網路資源，您可以[設定您的函數，使其連接到您帳戶中的 VPC](configuration-vpc.md)。當您使用此功能時，您可以使用 Amazon Virtual Private Cloud (Amazon VPC) 資源管理函數的網際網路存取能力及網路連線能力。 網路連線錯誤可能是由於 VPC 路由組態、安全群組規則、 AWS Identity and Access Management (IAM) 角色許可或網路位址轉譯 (NAT) 的問題，或是 IP 地址或網路介面等資源的可用性所造成。視問題而定，如果請求無法到達其目標，您可能會看到特定錯誤或逾時。 **Topics** + [VPC：函數會失去網際網路存取或逾時](#troubleshooting-networking-cfn) + [VPC：TCP 或 UDP 連線間歇性失敗](#troubleshooting-networking-tcp-udp) + [VPC：函數需要存取 而不 AWS 服務 使用網際網路](#troubleshooting-networking-access) + [VPC：已達到彈性網絡介面限制](#troubleshooting-networking-limit) + [EC2：具有「lambda」類型的彈性網路介面](#troubleshooting-networking-eni) + [DNS：遇到 UNKNOWNHOSTEXCEPTION，無法連線至主機](#troubleshooting-networking-dns-tcp) ## VPC：函數會失去網際網路存取或逾時 **問題：***Lambda 函數在連線到 VPC 之後失去網際網路存取能力。* **錯誤：***Error: connect ETIMEDOUT 176.32.98.189:443* (錯誤：連線 ETIMEDOUT 176.32.98.189:443) **錯誤：***Error: Task timed out after 10.00 seconds* (錯誤：任務在 10.00 秒後逾時) **錯誤：** *ReadTimeoutError：讀取逾時。(讀取逾時 = 15)* 當您將函數連線到 VPC 時，所有傳出請求都會通過 VPC。若要連線到網際網路，請設定您的 VPC 從函數的子網路將傳出流量傳送到公有子網路中的 NAT 閘道。如需詳細資訊和範例 VPC 組態，請參閱 [啟用 VPC 連線的 Lambda 函數的網際網路存取](configuration-vpc-internet.md)。 若部分 TCP 連線逾時，且子網路使用網路存取控制清單 (NACL)，請參閱 [VPC：TCP 或 UDP 連線間歇性失敗](#troubleshooting-networking-tcp-udp)。否則，此問題很可能是封包分散所致。Lambda 函數無法處理傳入的分段 TCP 請求，因為 Lambda 不支援 TCP 或 ICMP 的 IP 分段。 ## VPC：TCP 或 UDP 連線間歇性失敗 **注意** 此問題僅在子網路使用[網路存取控制清單 (ACL)](https://docs.aws.amazon.com//vpc/latest/userguide/vpc-network-acls.html#nacl-basics) 時才會發生。Lambda 連線至子網路並不需要網路 ACL。 **問題：***Lambda 間歇性斷開與您已設定網路存取控制清單 (ACL) 的 VPC 子網路連線。* 對於啟用 VPC 的 Lambda 函數， 會在客戶帳戶中 AWS 建立[超平面 ENIs](configuration-vpc.md#configuration-vpc-enis)，並使用暫時性連接埠`1024``65535`將 Lambda 連線至客戶的 VPC。若在目標子網路中使用網路 ACL，則必須允許 TCP 與 UDP 使用 `1024` 至 `65535` 的連接埠範圍。若不允許此完整連接埠範圍，可能會導致連線間歇性失敗。 ## VPC：函數需要存取 而不 AWS 服務 使用網際網路 **問題：***您的 Lambda 函數需要在不使用網際網路 AWS 服務 的情況下存取 。* 若要 AWS 服務 從沒有網際網路存取的私有子網路將函數連接至 ，請使用 VPC 端點。 ## VPC：已達到彈性網絡介面限制 **錯誤：***ENILimitReachedException: The elastic network interface limit was reached for the function's VPC.* (ENILimitReachedException：已到達函數 VPC 彈性網路界面的限制。) 當您將 Lambda 函數連線到 VPC 時，Lambda 會為每個連接到函數的子網路和安全群組組合建立彈性網絡介面。預設服務配額為每個 VPC 250 個網路介面。若要請求提升配額，您可以使用 [Service Quotas 主控台](https://console.aws.amazon.com/servicequotas/home/services/lambda/quotas/L-9FEE3D26)。 ## EC2：具有「lambda」類型的彈性網路介面 **錯誤代碼：***Client.OperationNotPermitted* **錯誤訊息：***無法針對此類型的介面修改安全群組* 如果您嘗試修改由 Lambda 所管理的彈性網絡介面 (ENI)，將會收到此錯誤訊息。`ModifyNetworkInterfaceAttribute` 不包含在 Lambda 為更新彈性網路介面上的操作所建立的 Lambda API 中。 ## DNS：遇到 UNKNOWNHOSTEXCEPTION，無法連線至主機 **錯誤訊息：***UNKNOWNHOSTEXCEPTION* Lambda 函數最多支援 20 個並行 TCP 連線的 DNS 解析。您的函數可能是達到了該限制。最常見的 DNS 請求乃透過 UDP 完成。如果您的函數只進行 UDP DNS 連線，則問題不太可能是這個。此錯誤通常是由於配置錯誤或基礎設施降級而出現的，因此在深入檢查 DNS 流量之前，請確認 DNS 基礎設施已正確設定且運作狀態良好，而且 Lambda 函數參考的是 DNS 中指定的主機。 如果您判斷問題與 TCP 連線上限相關，請注意，您並無法請求提高此限制。如果 Lambda 函數因為 DNS 承載高而退回到 TCP DNS，請確認您的解決方案使用的程式庫支援 EDNS。如需有關 EDNS 的詳細資訊，請參閱 [RFC 6891](https://datatracker.ietf.org/doc/html/rfc6891) 標準。如果 DNS 承載持續超過 EDNS 大小上限，您的解決方案可能仍會達到 TCP DNS 限制。