AWS帳號充值代辦 AWS Lambda 監控與故障排除：建構可靠的函式執行環境
AWS帳號充值代辦 # AWS Lambda 監控與故障排除：建構可靠的函式執行環境
在實際使用 AWS Lambda 時，最常見的問題不是「函式怎麼建立」，而是「函式為什麼偶發失敗」、「執行時間為什麼突然變長」、「明明有流量卻沒有正確處理」、「日誌裡只有一串錯誤卻很難定位根因」。
如果你搜尋這個主題，通常代表你已經在使用 Lambda，並且正在面對以下其中一種情況：
- 函式偶發超時，無法穩定回應 API 請求
- Lambda 成本突然增加，但不知道是哪個版本或哪個事件源造成
- 監控面板看得到錯誤率，卻無法快速定位是哪一步出錯
- 函式掛在 VPC 後連不到資料庫、Redis 或外部服務
- CloudWatch Logs 有錯，但缺少系統化的故障排查流程
- 想建立告警與儀表板，但不知道應該盯哪些指標
這篇文章不做概念介紹，直接從實際操作出發，帶你完成一套可用的 Lambda 監控、告警與故障排除流程，並整理常見問題的檢查順序，讓你在出現異常時能更快定位問題。
---
## 一、先釐清監控目標：你到底要觀察什麼
Lambda 的故障排查，建議不要一開始就衝進日誌，而是先把監控拆成 4 個層次：
AWS帳號充值代辦 1. **函式是否成功執行**
2. **函式執行是否變慢**
3. **函式是否因資源限制被拒絕或中斷**
4. **函式依賴的下游服務是否異常**
對應到 AWS 實際操作，至少要先建立以下觀察面：
- CloudWatch Metrics：看錯誤、延遲、併發、節流
- CloudWatch Logs：看每次執行細節與錯誤堆疊
- CloudWatch Alarms：出現異常時主動通知
- AWS X-Ray：看函式內部與外部依賴的耗時分佈
- Dead Letter Queue 或 On-failure Destination：保留失敗事件方便重試與分析
如果你現在的環境只有 Lambda 本身，卻沒有告警、沒有日誌篩選、沒有追蹤，那麼出問題時一定只能靠人工翻日誌，效率很低。
---
## 二、先建立基礎監控：CloudWatch Metrics 必看指標
AWS帳號充值代辦 進入 AWS Console 後，操作路徑如下：
**Lambda Console → Functions → 選擇你的函式 → Monitor → View CloudWatch metrics**
你需要重點關注以下指標。
### 1. Invocations
表示函式被觸發的次數。
用途：
- 驗證事件源是否真的有把流量送進 Lambda
- 對照 Error、Duration、Throttles 觀察異常是否隨流量升高而增加
如果你的上游明明有請求，但 Invocations 幾乎沒有變化，優先檢查：
- API Gateway 是否正確整合 Lambda
- EventBridge 規則是否命中
- SQS/SNS/Kinesis 是否已綁定事件來源映射
- 觸發器是否被停用
### 2. Errors
表示函式執行失敗次數。
常見造成 Errors 升高的原因：
- 程式異常未捕捉
- 權限不足，無法讀取 S3、Secrets Manager、DynamoDB 等資源
- 資料格式錯誤
- 初始化失敗
- 依賴外部服務連線失敗
排查建議：
- 先看 Errors 是否持續上升還是偶發尖峰
- 再對照 CloudWatch Logs 查同時間的錯誤堆疊
- 如果是新版本上線後才出現，檢查 Alias/Version 切換紀錄
### 3. Duration
表示函式執行時間。
你要重點看：
- 平均值是否逐步升高
- P95/P99 是否有明顯長尾
- 是否接近 Timeout 設定值
若 Duration 接近 Timeout，通常下一步就會出現 Timeout 錯誤。
實務上常見原因：
- 函式記憶體太小，導致 CPU 不足
- 查資料庫變慢
- 連外 API 延遲升高
- 函式在 VPC 中，ENI 初始化或 NAT 出網延遲較大
- 套件初始化時間過長，冷啟動偏慢
### 4. Throttles
表示請求因併發限制被拒絕。
這是 Lambda 穩定性排查時非常關鍵的指標。
如果 Throttles 出現，優先檢查：
- 帳號區域併發額度是否不足
- 函式是否設定 Reserved Concurrency，且值太小
- 突發流量是否超過可用併發
- 是否有其他函式搶占同一區域併發配額
### 5. ConcurrentExecutions
表示同時執行中的函式數量。
用途：
- 判斷是否因流量尖峰導致併發爆增
- 對照 Throttles 看是否需要調整保留併發或申請額度提升
### 6. IteratorAge（若使用 SQS/Kinesis/DynamoDB Streams）
這個指標很容易被忽略，但非常有用。
若 IteratorAge 持續升高，通常代表：
- Lambda 消費速度追不上事件堆積速度
- 下游處理太慢
- 有批次失敗重試造成積壓
AWS帳號充值代辦 此時不要只看 Errors，還要一起看批次大小、併發與處理邏輯。
---
## 三、建立告警：不要等用戶報錯才發現
只看監控面板不夠，必須設定 CloudWatch Alarm。
建議至少建立以下告警：
### 1. Error 告警
建議條件：
- 5 分鐘內 Errors > 0
- 或 Error Rate > 1%
適合場景：
- API 型函式
- 核心任務處理函式
- 金流、訂單、通知等關鍵流程
### 2. Duration 告警
AWS帳號充值代辦 建議條件：
- P95 Duration 超過 Timeout 的 70%～80%
例如：
- Timeout 設 30 秒
- 可將告警設為 P95 > 21 秒
這樣可以在真正 timeout 前先預警。
### 3. Throttles 告警
建議條件：
- 1 分鐘內 Throttles > 0
因為只要出現節流，就已經代表部分請求未被正常處理或將延後處理。
### 4. IteratorAge 告警
建議條件：
- 根據業務可接受延遲設定，例如超過 60 秒或 300 秒
AWS帳號充值代辦 ### 5. Dead Letter Queue 訊息數告警
如果你已為非同步 Lambda 配置 SQS DLQ，應針對 DLQ 訊息數增加建立告警。這通常比單純看 Lambda Errors 更快發現實際失敗事件。
### 告警建立步驟
操作路徑：
**CloudWatch Console → Alarms → Create alarm**
基本流程：
1. 選擇指標來源為 Lambda
2. 選取對應函式與指標
3. 設定統計方式，例如 Sum、Average、p95
4. 設定時間區間，例如 1 分鐘、5 分鐘
5. 設定閾值
6. 綁定 SNS 通知主題
7. 測試通知是否可正常收到
實務建議：
- 告警不要只發 Email，最好同步發到 Slack、Teams 或工單系統
- 告警名稱要包含環境與函式名稱，例如 `prod-order-create-lambda-errors`
- 不同嚴重程度分開 SNS Topic，避免通知噪音太高
---
## 四、日誌排查：CloudWatch Logs 要怎麼看才快
很多人會打開日誌後直接搜尋 `ERROR`，但 Lambda 真正常見的失敗不一定都會印出標準錯誤級別。正確做法是先找到對應請求，再看初始化、執行與結束資訊。
操作路徑：
**CloudWatch Console → Logs → Log groups → /aws/lambda/函式名稱**
每次 Lambda 執行通常會看到這幾類訊息：
- `START RequestId`
- 程式輸出日誌
- 錯誤堆疊
- `END RequestId`
- `REPORT RequestId`
### REPORT 行要重點看什麼
例如：
```text
REPORT RequestId: xxx Duration: 3200 ms Billed Duration: 3201 ms Memory Size: 256 MB Max Memory Used: 248 MB Init Duration: 850 ms
```
重點欄位：
- `Duration`：本次實際執行時間
- `Billed Duration`：計費時間
- `Memory Size`：分配記憶體
- `Max Memory Used`：本次最大記憶體使用量
- `Init Duration`：初始化耗時，冷啟動時特別重要
### 如何從 REPORT 快速判斷問題
#### 情況 1：Max Memory Used 非常接近 Memory Size
例如：
- Memory Size = 512 MB
- Max Memory Used = 505 MB
這表示函式非常接近記憶體上限，可能出現：
- 執行變慢
- OOM
- 某些語言執行時被系統回收
處理方式：
- 先把記憶體提高一級測試，例如 512 MB → 1024 MB
- 重新觀察 Duration 與 Errors 是否下降
#### 情況 2：Init Duration 很高
例如 Init Duration 經常超過 1000 ms，通常代表：
- 套件過大
- 初始化時做了過多網路連線或設定讀取
- 函式掛在 VPC 中增加冷啟動成本
- 容器映像過大
處理方式：
- 把初始化邏輯移出熱路徑
- 減少依賴套件
- 避免在 handler 啟動前做太多同步操作
- 需要低延遲時考慮 Provisioned Concurrency
#### 情況 3：沒有 END，只有 Task timed out
典型訊息：
```text
Task timed out after 30.00 seconds
```
表示函式超時被中止。這種情況通常不是單純把 Timeout 改大就能解決，而是要先排查：
- 是否卡在資料庫查詢
- 是否等待外部 API 回應
- 是否重試邏輯沒有退出
- 是否 DNS/網路有問題
- 是否程式進入死循環
---
## 五、用 Logs Insights 快速篩出異常請求
當日誌量很大時，不要手動一條一條翻，直接使用 CloudWatch Logs Insights。
操作路徑：
AWS帳號充值代辦 **CloudWatch Console → Logs Insights**
選取 Lambda 的 Log Group 後，可以用以下查詢語句。
### 1. 查最近錯誤
```sql
fields @timestamp, @message
| filter @message like /ERROR|Task timed out|Exception/
| sort @timestamp desc
| limit 100
```
### 2. 查超時訊息
```sql
fields @timestamp, @message
| filter @message like /Task timed out/
| sort @timestamp desc
```
### 3. 查高記憶體使用
```sql
fields @timestamp, @message
| filter @message like /REPORT/
| parse @message "Memory Size: * MB Max Memory Used: * MB" as memorySize, maxMemoryUsed
| display @timestamp, memorySize, maxMemoryUsed
| sort @timestamp desc
```
### 4. 查冷啟動耗時
```sql
fields @timestamp, @message
| filter @message like /Init Duration/
| parse @message "Init Duration: * ms" as initDuration
| display @timestamp, initDuration
| sort @timestamp desc
```
實務建議：
- 在程式中輸出結構化 JSON 日誌，後續查詢會更準確
- 每條日誌帶上 requestId、userId、orderId、traceId 等欄位，方便跨服務定位
- 不要把敏感資訊如 token、密碼、信用卡資料直接寫入日誌
---
## 六、啟用 X-Ray：看清楚時間到底耗在哪裡
當你只知道 Duration 很高，卻不知道是 Lambda 本身慢、資料庫慢、還是外部 API 慢，X-Ray 會比單純看 Logs 更有效。
### 啟用步驟
操作路徑：
**Lambda Console → Functions → 選擇函式 → Configuration → Monitoring and operations tools → Edit → 勾選 Active tracing**
如果函式角色缺少權限，請確認 IAM Role 含有 X-Ray 所需權限，例如：
- `AWSXRayDaemonWriteAccess`
### 啟用後可以看什麼
- 函式總耗時
- 初始化時間
- 下游 AWS 服務呼叫耗時
- 外部 HTTP 呼叫耗時
- 錯誤發生在哪一段
### 常見排查場景
#### 場景 1：資料庫連線慢
如果 X-Ray 顯示 Lambda 本體執行很短，但某個 RDS 查詢段落耗時很長，優先檢查：
- Lambda 與 RDS 是否在同一 VPC/子網規劃內
- Security Group 是否正確放行
- 查詢是否缺少索引
- 是否每次都重新建立資料庫連線
#### 場景 2：第三方 API 慢
AWS帳號充值代辦 如果外部 HTTP 呼叫佔用大部分時間：
- 增加請求 timeout
- 設定合理重試次數，不要無限等待
- 對慢 API 做快取或非同步化
- 把第三方依賴從同步請求鏈路拆出去
#### 場景 3：初始化慢
如果大量耗時都在初始化階段：
- 精簡依賴套件
- 減少大型 SDK 載入
- 拆分函式職責
- 對高頻低延遲函式使用 Provisioned Concurrency
---
## 七、常見故障排查：按問題類型逐一處理
下面這一部分是最常用的。當 Lambda 出現異常時，建議按這個順序檢查。
---
## 八、問題一：Lambda 執行超時
### 典型現象
AWS帳號充值代辦 - CloudWatch Logs 出現 `Task timed out`
- Duration 接近或等於 Timeout
- 上游 API Gateway 回 502、504
- 非同步任務反覆重試
### 排查順序
#### 第一步：確認 Timeout 設定值
操作路徑：
**Lambda Console → Function → Configuration → General configuration**
檢查目前 Timeout 是多少秒。
如果你業務本來就需要 20 秒以上，但 Timeout 只設 3 秒，先修正為合理值。但如果原本只需 2 秒，卻常跑到 30 秒，就不是單純調大 Timeout 可以解決。
#### 第二步：看 Duration 與 Init Duration
- Duration 高：代表實際處理慢
- Init Duration 高：代表冷啟動或初始化慢
#### 第三步：看是否卡在下游依賴
檢查：
- RDS 查詢
- Redis 操作
- 第三方 API
- S3 下載大檔
- Secrets Manager 讀取
#### 第四步：檢查是否在 VPC 內
若 Lambda 掛在 VPC：
- 確認私有子網是否能透過 NAT Gateway 出網
- 確認 Security Group 和 NACL 無阻擋
- 確認 DNS 解析正常
#### 第五步：檢查程式邏輯
AWS帳號充值代辦 常見問題：
- 無限重試
- 迴圈未正常結束
- 批次資料量過大
- 沒有對外部請求設定 timeout
### 處理建議
- 把外部 HTTP timeout 設短，例如 2～5 秒，而不是跟著 Lambda Timeout 一樣長
- 批次處理拆小
- 增加記憶體，測試 CPU 提升是否縮短 Duration
- 長任務改用 Step Functions、SQS 解耦或 ECS/Fargate 執行
---
## 九、問題二：Lambda 無法連接資料庫或 Redis
### 典型現象
- 連線逾時
- `ECONNREFUSED`
- `ETIMEDOUT`
- 偶發可連、偶發失敗
### 重點檢查
#### 1. Security Group
確認：
- Lambda 綁定的 Security Group
- RDS/Redis 綁定的 Security Group
- 目標埠是否放行，例如 MySQL 3306、PostgreSQL 5432、Redis 6379
最佳做法：
- 使用 Security Group 對 Security Group 放行
- 不要直接用 `0.0.0.0/0` 開資料庫埠
#### 2. 子網與路由
如果 Lambda 在私有子網中，資料庫也在 VPC 內，通常不需要 NAT 才能內網互通；但如果 Lambda 還需要順便存取外部 API，則需要 NAT Gateway。
檢查：
- 子網路由表是否正確
- Lambda 是否選到了沒有通往目標的子網
- 多 AZ 下是否所有子網都能連到目標服務
#### 3. DNS 與 VPC 設定
若使用 RDS endpoint 或 ElastiCache endpoint，確認：
- VPC 已啟用 DNS resolution / DNS hostnames
- Lambda 所在子網可正常解析內部網域
#### 4. 連線池問題
很多 Lambda 連資料庫失敗，不是網路真的斷，而是連線數被打滿。
典型情況：
- 併發一上來，每個 Lambda execution 都建立新連線
- 資料庫 max connections 被耗盡
處理方式：
- 在函式執行環境重用連線，不要每次 invocation 都重新建連
- 使用 RDS Proxy 管理連線池
- 控制 Lambda Reserved Concurrency，避免瞬間打爆資料庫
---
AWS帳號充值代辦 ## 十、問題三：Lambda 被節流（Throttling）
### 典型現象
- CloudWatch 指標出現 Throttles
- 部分請求延遲或失敗
- 非同步事件處理積壓
### 排查順序
#### 1. 看函式是否設了 Reserved Concurrency
AWS帳號充值代辦 操作路徑：
AWS帳號充值代辦 **Lambda Console → Function → Configuration → Concurrency and recursion detection**
如果 Reserved Concurrency 設得太小，例如 5，而流量同時進來 50 個請求，就一定節流。
#### 2. 看帳號區域總併發額度
如果多個函式共用區域併發池，某個高流量函式可能把額度吃光，導致其他函式被影響。
#### 3. 看事件來源類型
- API Gateway 同步請求：節流會直接影響前端回應
- SQS/Kinesis：可能表現為延遲升高與積壓
### 處理建議
- 為關鍵函式保留 Reserved Concurrency
- 對非關鍵函式限制併發，避免搶占資源
- 使用 SQS 緩衝突發流量
- 申請提高 Lambda 併發配額
- 如果下游是資料庫，先算資料庫可承受連線數，再反推 Lambda 可用併發
---
## 十一、問題四：Lambda 記憶體不足或效能不穩
### 典型現象
- Duration 高且波動大
- REPORT 顯示 Max Memory Used 接近上限
- 函式偶發崩潰
### 處理步驟
#### 1. 先調高記憶體做 A/B 測試
Lambda 的 CPU 與網路能力會隨記憶體一起提升，因此調高記憶體不一定只會增加成本，有時反而因執行時間變短，總成本接近甚至更低。
例如測試：
- 256 MB
- 512 MB
- 1024 MB
觀察：
- Duration 是否下降
- Errors 是否減少
- 每次成本是否可接受
#### 2. 精簡套件與資料載入
避免：
- 啟動時載入大型模型或大型字典
- 一次讀取過大檔案到記憶體
- 不必要的全量資料查詢
#### 3. 批次資料拆分
如果一次處理 1000 筆資料經常吃滿記憶體，改為每批 100 或 200 筆。
---
## 十二、問題五：Lambda 沒有日誌或日誌不完整
### 典型現象
- 函式有被觸發，但 CloudWatch Logs 幾乎沒有內容
- 只有部分 invocation 有日誌
- 新函式執行失敗卻看不到 log group
### 檢查項目
#### 1. IAM 權限
Lambda 執行角色需要具備 CloudWatch Logs 寫入權限，通常至少包含：
- `logs:CreateLogGroup`
- `logs:CreateLogStream`
- `logs:PutLogEvents`
最簡方式是先確認是否綁定 AWS 受管政策：
- `AWSLambdaBasicExecutionRole`
#### 2. 程式是否真的輸出日誌
確認你的程式在關鍵節點有輸出：
- 收到事件時
- 呼叫外部依賴前後
- 捕捉例外時
- 回傳前
#### 3. 是否在超時前來不及刷新日誌
AWS帳號充值代辦 若函式超時太快，最後部分日誌可能來不及完整輸出。這時要優先解決 Timeout，而不是只盯著日誌本身。
---
## 十三、問題六：部署後新版本異常，但舊版本正常
AWS帳號充值代辦 ### 典型現象
- 更新程式後 Errors 突然升高
- 只有某個 Alias 對應流量出錯
- 回滾後恢復正常
### 推薦做法
#### 1. 使用 Version + Alias 發版
不要每次都直接覆蓋 `$LATEST` 給生產環境。應建立：
- Version
- Alias，例如 `dev`、`staging`、`prod`
#### 2. 逐步放量
透過 Alias 加權流量，把 5% 或 10% 請求先導向新版本，觀察：
- Errors
- Duration
- 業務成功率
#### 3. 建立版本級監控
不要只看整個函式總體指標，否則新版本異常可能被舊版本流量稀釋。
---
## 十四、建立一套實用的 Lambda 可靠性配置清單
如果你要把 Lambda 跑得更穩，下面這份清單可以直接對照現有環境逐項補齊。
### 監控層
- 啟用 CloudWatch Metrics
- 建立 Error、Duration、Throttles、IteratorAge 告警
- 建立核心函式儀表板
- 啟用 X-Ray Active Tracing
- 日誌使用結構化 JSON
### 執行層
- Timeout 不要用預設值，按實際任務調整
- 記憶體做壓測後選定，不要憑感覺
- 關鍵函式配置 Reserved Concurrency
- 必要時使用 Provisioned Concurrency
### 網路層
- Lambda 接入 VPC 前先確認是否真的需要
- 需要外網時確認 NAT 路由
- Security Group 僅放行必要埠
- 驗證 DNS 解析與跨子網連通
### 程式層
- 外部請求必設 timeout
- 重試要有上限
- 初始化邏輯最小化
- 連線可重用，不要每次新建
- 錯誤日誌保留關鍵上下文
### 容錯層
- 非同步函式配置 DLQ 或 Destination
- 批次任務設定失敗重試策略
- 關鍵事件源設計冪等處理
- 上線使用 Version/Alias，支援快速回滾
---
## 十五、實戰排查範本：Lambda 出問題時先照這個順序看
當你的 Lambda 突然異常，建議按照下面順序檢查，速度會比直接翻程式碼快很多。
### 5 分鐘內初步定位
1. 看 CloudWatch Metrics
- Invocations
- Errors
- Duration
- Throttles
- ConcurrentExecutions
2. 看同時間 CloudWatch Logs
- 是否有 Exception
- 是否有 Task timed out
- REPORT 的 Max Memory Used、Init Duration
3. 看最近是否有部署
- 是否剛切換新版本
- 是否改過環境變數、IAM、VPC
### 15 分鐘內縮小範圍
4. 判斷是程式錯誤、資源瓶頸還是網路問題
5. 如有 X-Ray，檢查慢點出現在初始化、資料庫還是外部 API
6. 如接 SQS/Kinesis，檢查是否有積壓與 IteratorAge 增加
### 30 分鐘內採取處置
7. 必要時回滾版本
8. 臨時提高記憶體或 timeout 做驗證
9. 如為併發問題，調整 Reserved Concurrency 或限流上游
10. 如為下游資料庫問題，先降載或切換到緩衝佇列
---
## 十六、結語
AWS Lambda 的穩定性，不是靠「出錯後看日誌」這一招就能解決，而是要在上線前就把監控、告警、追蹤、容錯與版本回滾機制一起補齊。
真正實用的 Lambda 監控與故障排除思路應該是：
- 先用 Metrics 判斷異常類型
- 再用 Logs 找具體錯誤與資源訊號
- 必要時用 X-Ray 定位耗時鏈路
- 對高風險問題提前配置告警、DLQ、併發限制與版本回滾
如果你的 Lambda 目前已經在線上服務，建議先從下面三件事做起：
1. 為 Errors、Duration、Throttles 建立 CloudWatch 告警
2. 啟用結構化日誌與 X-Ray
3. 檢查每個函式的 Timeout、記憶體、VPC、併發設定是否合理
把這三步補上後，多數 Lambda 線上故障都能更快被發現，也更容易定位根因。
