某個 Lambda 函數會處理來自 IoT 裝置的訊息。該公司需要近乎即時的吞吐量指標，以計算該函數在每個時間間隔內接收和處理的訊息數量。初始化和後續處理不應包含在吞吐量測量中。開發人員應該實作什麼？

正確答案是修改程式碼，使其在每次函數接收和處理訊息時發布自訂 CloudWatch 指標，並使用這些指標來計算吞吐量。因為這能提供最精確且即時的吞吐量數據，且能排除初始化和後續處理的影響。自訂指標允許開發人員精確定義要測量的事件。 使用 Lambda ConcurrentExecutions CloudWatch 指標來推斷吞吐量不夠精確，它衡量的是同時執行的函數數量，而非處理的訊息數量。讓應用程式將計算出的吞吐量記錄到 CloudWatch Logs，並使用 EventBridge 定期觸發另一個 Lambda 來處理這些日誌，會引入延遲且處理複雜，不符合近乎即時的要求。使用 Lambda Invocations 和 Duration 指標在 CloudWatch 中計算吞吐量，雖然能提供函數的整體執行情況，但無法單獨測量訊息處理的吞吐量，且會包含初始化和後續處理的時間。