AWS帳號購買 AWS Lambda日誌監控設定方法

第一章：你要監控的到底是什麼

談「AWS Lambda 日誌監控設定方法」，很多人第一反應是「把 CloudWatch 裡的日誌搜尋出來就好」。但真正做起來，問題常常不是搜尋，而是你要監控的事件是否明確、告警是否可靠、通知是否能被即時接住。

日誌監控通常包含三個層次：

第一層是「日誌有沒有產生」。例如函式是否真的被呼叫、是否卡在冷啟動或啟動失敗。

第二層是「日誌內容是否異常」。例如錯誤堆疊、特定錯誤碼、慢速處理、超出重試次數等。

第三層是「異常是否需要人介入」。有些錯誤是可恢復的，有些只要追蹤就好；告警要能區分「噪音」與「事故」。

AWS帳號購買 因此在開始設定前，先把監控目標寫成可驗證的語句，會讓後續配置更順。比如：

「當 Lambda 執行失敗（ERROR）在 5 分鐘內超過 3 次，就通知值班人員。」

「當 log 裡出現『Timeout』字樣超過 1 次，就升級到高優先級。」

「若完全沒有日誌產生，判定事件來源或授權可能失效，於 30 分鐘內提醒。」

你會發現，這些句子其實已經對應到 CloudWatch 的查詢、告警與通知方式了。

第二章：準備工作—確保日誌真的進來了

日誌監控的前提，是 CloudWatch Logs 能收到 Lambda 的輸出。你可以從三個地方確認。

2.1 檢查 Lambda 的日誌啟用

在 AWS 管理主控台打開你的 Lambda 函式，查看「監控（Monitoring）」或「監控與日誌」相關設定。確保已啟用「CloudWatch Logs」。

若你使用的是 IaC（例如 Terraform 或 CloudFormation），就檢查執行角色（execution role）的權限。

2.2 確認執行角色的權限

Lambda 要能寫入 CloudWatch Logs，執行角色至少需要以下能力（概念上）：

1）建立/寫入 log group（logs:CreateLogGroup）

2）建立/寫入 log stream（logs:CreateLogStream）

3）上傳事件（logs:PutLogEvents）

權限不足時，最常見情況是：函式其實可能跑起來了，但完全沒有日誌；或只有少量日誌後就中止。這會讓你後續的監控誤判。

2.3 確認日誌格式與內容

不一定要一開始就上 JSON 格式，但越結構化越好。例如每條 log 都包含 requestId、jobId、錯誤類型、處理階段。你不必把世界變成完美的 observability，但至少要避免「一行文字看不出是哪個步驟失敗」。

建議在程式中統一使用明確關鍵字，例如：

「ERROR」「WARN」「LATENCY_MS」「FUNCTION_STAGE」「ERROR_CODE」等。

AWS帳號購買 第三章：用 CloudWatch Logs 建立可監控的查詢

日誌告警多半是基於「Logs Insights 查詢」或以篩選模式做事件觸發。核心是：你要能在固定時間窗內，取得可量化的指標。

3.1 選擇監控時間窗與粒度

監控時間窗不是越短越好。太短會被日誌延遲和抖動影響，太長又會錯過快速處理的窗口。

常用做法：

針對錯誤：5 分鐘或 15 分鐘。

針對超時：5 分鐘。

AWS帳號購買 針對「沒有日誌」：20 分鐘或 30 分鐘（視呼叫頻率而定）。

粒度方面，你應該決定是「整體函式層級」還是「依來源或參數分群」。例如同一個 Lambda 處理多種任務，可能只在特定任務失敗頻繁。若你不分群，告警容易過度觸發。

3.2 以關鍵字或結構化欄位做篩選

如果你目前的 log 是純文字，先用關鍵字最直接。例如找 ERROR：

「只要包含『ERROR』就計入」或「只要包含『Task timed out』就計入」。

如果你能輸出 JSON，會更精準。例如用某個欄位 errorCode 或 stage。

關鍵字方案的風險是：可能把「非致命錯誤」也算進去，造成噪音。結構化欄位可以降低誤報。

3.3 建立查詢並驗證結果

在 CloudWatch Logs 的 Logs Insights 中寫下你的查詢條件，並用「最近 1 小時/24 小時」測試，確認：

1）成功的執行是否幾乎不被計入。

2）真正故障時，查詢結果是否會顯著上升。

3）你期望的錯誤類型是否有穩定的關鍵字或欄位。

這一步很重要，因為「告警」本質上是對查詢結果的再封裝。一旦查詢不準，告警就會失去可信度。

第四章：告警建立方式—把查詢變成能通知的規則

當你已經有明確的查詢條件，下一步是把它轉成告警規則。AWS 提供多種路徑，實務上你會遇到兩種常見模式：一種是基於 Metric（將日誌轉成指標後告警），另一種是直接基於 Logs/查詢結果觸發告警。

無論你使用哪一種，思路一致：用查詢或指標得到數量，再設定閾值與通知。

4.1 設定「條件」：計數型 vs 狀態型

計數型：例如 5 分鐘內 ERROR 次數 >= 3。這是最直覺也最常見的告警。

狀態型：例如「未出現任何成功或任何呼叫」；或「延遲超過門檻持續 N 分鐘」。狀態型通常需要更謹慎設計，避免把正常低流量誤判成事故。

你可以用「至少有一次觸發」作為前置條件；若事件來源本身是固定排程，就能更好判斷異常。

4.2 設定「閾值」：從觀察開始

如果你直接用拍腦袋的閾值，告警一定會失靈。建議做法：

先觀察一段時間（例如 3~7 天），記錄正常期間錯誤出現的頻率。很多系統在正常時就會有少量 WARN 或偶發錯誤。

再用這些數據決定閾值。例如正常時 ERROR 平均 0.2 次/5 分鐘，當你看到 3 次/5 分鐘以上，就很可能是事件。

如果你同時要監控「超時」或「連線失敗」，也應分別設定閾值，不能混用同一套規則。

AWS帳號購買 4.3 設定「評估頻率」與「持續時間」

告警通常由兩部分組成：評估頻率（how often to check）和持續條件（for how long it must stay above threshold）。

例如：

每 1 分鐘評估一次，連續 3 次都超過閾值才觸發，能避免單次抖動。

AWS帳號購買 如果你希望更快觸發，就降低持續條件；但你就要接受更多噪音。這是設計上的交易，不是誰對誰錯。

第五章：通知管道—讓告警被人真的看見

再好的告警，如果送不到正確的人手上，就等於沒有。通知管道需要同時考慮「時效性」與「可操作性」。

5.1 SNS + Email/簡訊/HTTPS

最常見的是 AWS SNS 作為通知分發中心，告警觸發後送到：

1）Email（適合低到中優先級）

2）簡訊（適合緊急）

3）HTTP endpoint（你自建接收器或整合服務）

如果你只有 Email，記得確認收件人是否有延遲查看，並在告警內容中提供足夠上下文。

5.2 Slack / 工單系統 / PagerDuty

如果你的團隊已經有值班流程，最好讓告警直接進入該流程的入口。例如：

高優先級丟 PagerDuty 或工單，低優先級丟 Slack 團隊頻道。

通知內容要避免「只有告警名稱」。一封信或一則訊息至少要包含：

1）函式名稱與版本/別名

2）觸發時間與評估區間

3）錯誤的關鍵摘要（例如 ERROR 次數、最常見錯誤碼）

4）建議操作（例如查看最近 15 分鐘日誌、檢查特定下游服務）

如果你能在 log 裡提供 errorCode，就可以在告警摘要中直接帶出，讓值班人更快定位。

5.3 權限與訂閱確認

通知設定常見失敗原因不是告警本身，而是 SNS 訂閱未確認、IAM 權限不足或 endpoint 沒有正確接收。建議在上線前用「手動測試」觸發一次告警，確保訊息真的到達。

第六章：避免常見落差—為什麼告警沒有響或一直響

實務上你會遇到兩大類問題：告警不響（漏報）或一直響（誤報）。兩者的根因往往雷同。

AWS帳號購買 6.1 日誌延遲造成的時間窗錯配

CloudWatch Logs 的可用性可能會有延遲。你設太短的評估時間窗，可能在日誌尚未寫入時就先判斷，導致漏報或錯誤狀態。

解法是把評估頻率與等待時間留出緩衝，或在測試階段觀察「實際錯誤發生時間」到「查詢結果出現」之間的差。

AWS帳號購買 6.2 Lambda 沒有觸發或配置錯誤

AWS帳號購買 如果你的監控目標包含「沒有日誌就告警」，你需要先確認事件來源會穩定觸發。排程失效、事件規則沒啟用、權限（例如 event source mapping 的角色）缺失，都會導致函式完全不跑。

此時「沒有日誌」確實該告警，但建議在文案中提醒可能原因是事件來源中斷，而不是函式本身故障。

6.3 日誌量不足或查詢篩選過嚴

例如你只用一個關鍵字篩選，但實際錯誤堆疊中那個字串偶爾不出現。或你的程式版本改了 log 格式，告警查詢還停留在舊格式。

這類問題在部署頻繁的系統特別常見。建議在每次重大改版後，用 Logs Insights 回放檢查告警查詢是否仍能捕捉到已知錯誤樣本。

6.4 權限不足：Logs/Metric/告警不是同一套角色

很多人只確認了 Lambda 寫入 Logs 的權限，卻忽略了告警或查詢使用的服務角色或權限。

例如：

告警規則可能需要讀取日誌或呼叫相關資源。

AWS帳號購買 通知可能需要允許向 SNS topic 發佈或訂閱。

漏掉任何一環，都會讓整體流程中斷。

6.5 重試與錯誤歸因：告警數字會被放大

當上游或 Lambda 本身有重試機制，單次事件可能產生多次失敗日誌。你如果以「ERROR 次數」作為唯一指標，會把重試造成的抖動當事故。

解法是把告警指標從次數轉成「唯一 requestId 的失敗數」，或加入更具體的錯誤類型/錯誤碼。

即使你不能做唯一計數，至少也要把重試行為納入告警閾值設計。

第七章：提升告警品質的做法—從日誌策略開始

告警不是只靠設定頁面就能做好。它是日誌策略的延伸。你越能讓日誌清楚、可分類，告警越能精準地發揮。

7.1 使用一致的 log level 與關鍵欄位

建議至少做到：

1）所有錯誤以 ERROR 註記

2）把業務階段（stage）寫進 log：例如 AUTH、VALIDATION、CALL_EXTERNAL、PERSIST

3）輸出 correlation id：requestId、jobId 或 trace id

4）輸出可分析的 errorCode 或錯誤類別

當你這樣做後，告警可以針對「外部呼叫失敗」或「資料驗證失敗」分別設閾值與通知對應的團隊。

7.2 將慢操作納入監控

很多事故不是直接 crash，而是延遲上升導致鏈路堆積。Lambda 本身也有指標（例如 Duration、Errors、Throttles），但你要結合日誌才能知道慢在什麼階段。

實作方式之一：在 log 裡輸出 stage 的耗時，並在告警查詢中抓出 LATENCY_MS 超標的情況。

即使你最終仍以 CloudWatch 指標告警，日誌能讓你快速回答「為什麼變慢」。

7.3 用結構化日誌降低查詢複雜度

純文字搜尋容易，但維護成本高。結構化日誌（例如 JSON）讓查詢變得直觀：直接篩 errorCode、stage、status。

同樣的監控需求，用結構化日誌通常需要更少的查詢條件，告警更不容易因為文案改動而失效。

第八章：把流程做成標準—可持續運行的監控

當你只設一次告警，問題不在於能不能做，而在於「能不能維持」。監控需要隨著服務演進而調整。

8.1 建立告警分級與處理責任

告警至少分成三層：

Level 1：影響功能（必須有人接）

Level 2：功能未完全中斷，但品質下降或風險上升

Level 3：可觀測性/除錯類（可延後）

每個等級對應不同通知方式與回應時間。不要讓所有告警都一樣緊急；否則很快就會出現「看到就忽略」的疲勞。

8.2 定期回顧：調整閾值與去噪

每週或每兩週做一次回顧很有用：

哪些告警頻繁觸發但實際上沒造成事故？把誤報原因抓出來，調整查詢或閾值。

哪些事故沒有告警？回頭補上對應的查詢條件。

此外，當部署頻率高時，把查詢與日志格式的變更納入流程，避免版本差導致監控失靈。

8.3 演練與測試：確保告警不是「理論上可用」

你可以在測試環境或用非正式方式做演練，例如：

部署一個會故意拋出錯誤的版本（只在測試期間）

觸發事件，確認告警條件在預期時間內觸發

確認通知內容包含足夠資訊讓人能直接進到日誌定位

這比任何文件都更能提升信心。

第九章：一個實用範例—從需求到告警規則

以下用一個常見案例串起整個流程：假設你的 Lambda 負責處理排程任務，每次任務可能呼叫外部 API。

9.1 需求定義

你希望做到：

（1）當外部 API 呼叫失敗（錯誤碼 EXTERNAL_API_FAILED）在 10 分鐘內累積達 5 次，通知值班。

（2）當出現 Timeout（字樣或 errorCode = TIMEOUT）在 10 分鐘內累積達 2 次，升級到高優先級。

（3）若 30 分鐘內沒有任何任務日誌（例如 stage=JOB_START 的記錄），通知「事件來源可能中斷」。

9.2 日誌落地

在程式中，確保至少在兩個地方打 log：

job開始時：包含 jobId、stage=JOB_START、requestId

外部呼叫失敗時：包含 stage=CALL_EXTERNAL、errorCode=EXTERNAL_API_FAILED、statusCode、requestId

timeout時：包含 stage=CALL_EXTERNAL、errorCode=TIMEOUT、durationMs

若你做到了這點，告警的查詢就可以簡潔且準確。

9.3 告警條件設計

告警（1）：查詢 stage=CALL_EXTERNAL 且 errorCode=EXTERNAL_API_FAILED，計數 10 分鐘窗，閾值 5。

告警（2）：查詢 errorCode=TIMEOUT，計數 10 分鐘窗，閾值 2，通知升級。

告警（3）：查詢 stage=JOB_START 的存在性。用「沒有資料」作條件時，記得先確認任務排程頻率，不然低頻時會誤報。

在評估頻率方面，你可以每 1 分鐘查一次，但要求連續 3 次成立再觸發，降低因為日誌延遲造成的抖動。

9.4 通知內容

通知訊息中放入：

函式名稱、告警類型、觸發時間、統計次數、查詢區間、最常見 errorCode（若你能在查詢摘要帶出）。

讓值班能快速判斷是外部 API 問題、還是 timeout 擴散。

第十章：最後的檢查清單—上線前確保不踩雷

把這份清單跑一遍，你的監控會更穩。

1）Lambda 已啟用 CloudWatch Logs，且執行角色有 logs:PutLogEvents 權限。

AWS帳號購買 2）在 Logs Insights 中能查到你要監控的錯誤樣本，查詢結果符合預期。

3）告警時間窗與評估頻率考慮日誌延遲，不會因為太短而漏報。

4）閾值是基於觀測資料而非猜測；誤報已被納入調整。

5）通知管道完成訂閱/權限，且告警觸發後能在你的工作流程中被看見。

6）日誌格式在部署後仍能被告警查詢捕捉，並有對應的回歸測試。

7）告警分級與回應責任清楚，避免疲勞與忽略。

結語：監控的價值在於可被行動

AWS Lambda 的日誌監控設定，本質上是在把「觀察」轉成「行動」。你要做的不只是讓告警存在，而是讓告警在正確的時間、針對正確的問題、通知正確的人，並提供足夠上下文讓他們能迅速定位與處理。

當你把查詢條件設準、把通知做對、把日誌結構化，告警就會從背景噪音變成真正的風險雷達。下一次事故來臨時，你會更快知道發生了什麼，少走很多彎路。