AWS帳號註冊 AWS CloudWatch告警設定方法

第一章：為什麼要把告警做對

很多團隊在雲端運維上，起步時告警會很「熱鬧」：CPU 拉警報、記憶體上升報警、錯誤率飆高也報、延遲超過也報。看起來很安全，實際上卻容易變成噪音。值班的人忙著關閉告警、或乾脆把所有通知都靜音，最後真正重要的告警反而被淹沒。

告警的核心不是「越多越好」，而是「在正確的時間告訴正確的人採取正確的行動」。一個成熟的告警體系通常做到三件事：第一，能用相對少的告警覆蓋主要風險；第二，降低誤報與漏報；第三，能把告警導向可執行的處置流程（例如開工單、觸發自動化、或上報到值班）。

CloudWatch 是 AWS 提供的監控與告警平台，能夠把指標（Metrics）、日誌（Logs）、告警動作（Actions）串起來。掌握它的設計方法，才能讓告警真正變成運維的加速器。

第二章：建立告警前先想清楚三個問題

在你點進 CloudWatch Create Alarm 之前，建議先把需求拆成三個問題。這一步看似繁瑣，但實際上會大幅降低後續返工。

問題一：你要監控的「目標」是什麼？

告警不是監控資料而是監控結果。常見目標包含：

• 可用性：服務是否出現不可用、超時、連線失敗。
• 效能：延遲（Latency）、吞吐（Throughput）、資源是否緊繃。
• 可靠性：錯誤率、重試行為、失敗率、降級是否正常。
• AWS帳號註冊 成本/容量：資源用量逼近上限、或突然的用量異常。

問題二：誰需要在什麼時間收到通知？

不同情境的處置權責不同。例子：

• 短暫抖動（例如 1 分鐘內的 CPU 峰值）可能不需要通知。
• 影響客戶體驗（例如延遲超過 SLA 或 5xx 增加）要通知值班。
• 持續性異常（例如錯誤率在 15 分鐘以上）需要通知值班並升級。

你可以在告警上設計多層級通知：先輕量通知（觀察用），再升級通知（需要處置）。

問題三：你希望告警告訴你的是「正在發生」還是「已經發生」？

這決定你設定的評估方式。例如你可以採用「連續多個週期觸發」的策略，使告警反映更穩定的狀態；也可以使用更敏感的指標（例如錯誤率飆升）讓告警更快到達。

第三章：CloudWatch 指標告警的基本構件

CloudWatch 告警主要由幾個關鍵部分組成：指標（Metric）或運算式（Math Expression）、統計方式、週期（Period）、評估週期（Evaluation Periods）、閾值（Threshold）、資料缺失處理（Treat missing data）以及告警動作（Actions）。理解這些元件，你就能針對不同告警情境做精準調整。

1）指標與命名空間：先找到正確的 Metrics

CloudWatch 指標通常有命名空間（Namespace），例如：

• AWS/EC2：CPUUtilization、NetworkIn/Out 等。
• AWS/ApplicationELB：TargetResponseTime、HTTPCode_Target_5XX_Count 等。
• AWS/ELB、AWS/RDS、AWS/Lambda 等也都有對應指標。

AWS帳號註冊 如果指標選錯，你看到的告警再漂亮也不會對應到真正問題。所以第一步是確認指標與你要保護的資源一致（例如特定環境、特定負載平衡器、特定服務）。

2）週期（Period）：資料聚合的節奏

週期表示 CloudWatch 以多長的時間窗聚合一次資料，常見選項例如 1 分鐘、5 分鐘。週期太短可能造成噪音，太長又可能延遲告警。

選週期時可用這個原則：如果你希望告警能在「幾分鐘內」反映狀況，就讓週期接近這個時間尺度的分割；若你追求穩定性，週期略拉長並搭配評估週期過濾短暫波動。

3）評估週期（Evaluation Periods）與「連續觸發」

AWS帳號註冊 評估週期表示條件需要連續成立多少個週期才觸發。這對降低誤報非常有效。

例如你要監控 CPUUtilization > 80%。若你設定週期 1 分鐘、評估週期 3，表示至少連續 3 分鐘 CPU 超過 80% 才告警。這通常比「只要某次達到閾值就告警」更符合實際運維。

4）統計方式（Statistic）：Average、Sum、Maximum 的差異

同一個指標在週期內可能同時有多筆資料。CloudWatch 會用統計方式把它聚合成一個值。常見選項：

• Average：平均值，適合觀測長時間的壓力（例如 CPU 平均）。
• Sum：週期內總和，適合計數類指標（例如錯誤次數）。
• Maximum：最大值，適合找尖峰（例如延遲最大值）。

如果你用錯統計方式，告警會偏離實際含意。比如延遲用 Average 可能掩蓋尖峰；錯誤用 Average 可能把瞬間大量錯誤變成較低平均而不觸發。

5）資料缺失（Treat missing data）：誤報與漏報的關鍵開關

很多告警的問題不是閾值本身，而是「資料突然不見了」卻仍然觸發或不觸發。CloudWatch 提供 Treat missing data 的策略，常見包括：

• missing 視為 good：適用於資源暫停時不希望觸發。
• missing 視為 bad：適用於「必須持續上報」的監控。
• missing 視為 ignore：忽略該週期，但要注意評估週期邏輯。

例如自動擴展縮容導致實例數變少，若你監控的是單一實例，缺失資料可能是正常現象。相反地，如果你監控的是重要服務的自訂指標，缺失資料可能代表上報中斷或服務故障，這時就要慎重處理 missing data。

第四章：從零開始設定一個告警（以常見 CPU 告警示範）

下面用一個具代表性的流程示範建立「EC2 CPU 持續高於閾值」告警。目的不是死記步驟，而是把思考框架帶入你自己的情境。

步驟一：確認你監控的範圍

你要監控單一 EC2 實例？還是整個 Auto Scaling 群組？若你有多個實例，通常使用合適維度（Dimensions）或聚合指標策略，例如以每台/或整體平均作為告警依據。

建議先以「影響客戶」角度選擇範圍：若任何一台承載關鍵服務的實例 CPU 飆高會造成延遲，那就可能需要按實例；若整體壓力反映在平均 CPU，則聚合告警更符合管理效率。

步驟二：選擇指標與統計

選擇命名空間 AWS/EC2，指標 CPUUtilization。統計可以從 Average 開始，因為 CPU 壓力通常以「持續高壓」比「瞬間一秒」更值得關注。

如果你要捕捉尖峰影響，則用 Maximum；但尖峰可能引入更多誤報，因此評估週期要相對更寬。

步驟三：設計週期與閾值

一個常用起點是：

• Period：1 分鐘或 5 分鐘
• Evaluation Periods：3 或 5
• Threshold：80%（起點，後續視基線調整）

這裡的重點是「起點」而不是「固定值」。最好先看過去一到兩週的 CPU 分布與變化情況，找出正常波動範圍，再設定能夠區分異常的閾值。

步驟四：處理缺失資料

AWS帳號註冊 如果實例會被停機或縮容，資料缺失可能是正常。你可以把 missing 視為 good 或 ignore。但若 CPU 指標應該永遠存在（例如固定運行的服務），missing 視為 bad 更能反映監控斷線。

步驟五：告警動作（Actions）與通知渠道

通常告警會觸發到 SNS（簡訊/Email/HTTP endpoint/Lambda）。建議至少建立：

• ALARM：發出通知。
• AWS帳號註冊 OK：告知恢復（如果團隊需要）。
• INSUFFICIENT_DATA：選擇是否通知（多數情況可少通知）。

如果你有值班制度，通知內容要包含關鍵資訊：資源名稱、指標值、觸發時間、告警描述以及建議排查方向。

第五章：用運算式做出更貼近業務的告警

很多告警看起來合理，但其實對業務幫助有限。原因是它們直接使用單一指標，忽略了「相對指標」或「組合邏輯」。CloudWatch 支援運算式（Math Expression），你可以把多個指標組合成更有意義的指標。

AWS帳號註冊 示例：錯誤率告警（5xx 比例）

假設你使用 Application Load Balancer。你可能有：

• HTTPCode_Target_5XX_Count：5xx 次數
• RequestCount 或其他總請求數指標

比起監控「5xx 次數超過多少」，更常見也更可控的做法是監控「錯誤率」：

• 錯誤率 = 5xx 次數 / 總請求數

運算式可以把這兩個計數組合，再以百分比或比例設定閾值。這樣在低流量時不會因為少量錯誤而誤報，在高流量時能更敏感地反映品質劣化。

如何避免運算式的陷阱

• 留意總請求數接近 0 的情況：錯誤率可能被放大。你可以用最低請求量作為前置條件（例如總請求數 > 某值再判定錯誤率）。
• AWS帳號註冊 確認分母與分子使用相同週期與維度。
• 評估週期要配合業務容忍度：錯誤率偶發可能可接受，但連續惡化就不能。

第六章：常見告警類型與建議設定方法

下面整理幾種在實務中最常出現的告警類型，並提供設定思路。你可以把它當成告警設計清單。

1）資源耗盡：CPU、記憶體、磁碟或連線數

資源告警要特別注意「預警」而不是「爆炸」。例如 CPU 從 50% 緩慢爬升到 95%，你最好在 75~85% 左右就給出早期通知，讓團隊有時間擴容或調優。

對於連線數（如資料庫連線、ALB 連線數），常常會有短時間尖峰。建議：

• 以 Maximum 搭配較多評估週期過濾短暫尖峰。
• 同時設定「絕對值」與「增長趨勢」的告警（如果你能取得趨勢指標或用運算式做差分）。

2）延遲告警：平均或分位數（如果有）

延遲是影響用戶體驗的直接指標。若你只用平均延遲，可能會錯過少量但高影響的問題。可行的方向：

• 使用 Maximum 或特定百分位指標（若你的來源提供，例如 p95/p99）。
• 搭配錯誤率一起看：延遲升高但錯誤率不變，可能是網路或排隊；延遲升高且錯誤率升高，可能是後端容量不足。

3）錯誤率告警：5xx、4xx、Lambda 失敗或 Kinesis 處理失敗

錯誤率告警常用「比率」而不是「次數」。比率能跨流量規模保持一致性。但要記得處理低流量造成的分母接近 0 問題。

此外，錯誤類型要分層：

• 5xx：通常與後端故障更直接相關，優先級高。
• 4xx：可能是客戶請求問題，但也可能是認證、路由或參數錯誤。你可以依業務容忍度調整閾值。
• Lambda Error：可能是程式碼問題，建議與版本或別名（alias）維度串起來。

4）流量異常與成本風險：請求量、吞吐與擴縮容行為

很多團隊只盯故障不盯成本，最後會被帳單嚇到。你可以設計「流量異常」告警：

• 如果請求量短時間超出基線，可能是爬蟲、誤配置或促銷活動導致。
• 如果擴縮容頻繁觸發（擴了又縮、縮了又擴），可能表示利用率設定不當。

這類告警不一定要立刻叫值班，但應該提供給運營或財務對齊風險。

第七章：把通知做成「可處置」而不是「可查看」

告警最大的失敗常見不是沒觸發，而是觸發了卻沒有人知道下一步做什麼。你需要讓通知具備行動性。

通知內容建議包含哪些欄位

• 告警名稱（可快速定位是哪個系統/環境/指標）。
• 觸發狀態（ALARM/OK）。
• 指標值與閾值（最好含單位）。
• 觸發持續時間（由 Evaluation 設計推算）。
• 資源標識（例如 Load Balancer 名稱、Target Group、實例 ID）。
• 排查方向（例如：先看該服務的 5xx、延遲、再看下游依賴與佇列）。

通知通道設計：SNS、Email、聊天工具與值班系統

CloudWatch 本身不負責「值班制度」，它只是把事件送到你設定的管道。實務上常見做法是：

• 先用 SNS 集中通知，讓不同訂閱者接收。
• 用 Lambda 或自訂 webhook 將通知格式化為團隊可讀內容，並路由到不同群組（例如不同服務、不同環境）。
• 如果你有值班系統，讓告警升級到值班電話或 on-call 工具。

AWS帳號註冊 重點是「可控」：避免每次都把人炸醒，也避免該升級時沒升級。

AWS帳號註冊 第八章：避免誤報與漏報的實用策略

告警設計的藝術，大多集中在「避免誤報」與「避免漏報」。下面是常見的幾個策略。

策略一：用評估週期過濾抖動

只要你看到大量「短暫觸發」告警，第一個調整方向通常是 Evaluation Periods，而不是立即提高閾值。提高閾值可能讓真正的異常也被掩蓋。

策略二：設計「兩段式」告警：預警與告警

你可以針對同一指標建立兩個告警：

• 預警（Warning）：較低閾值，通知到觀察者或 Slack 維運群。
• 告警（Critical）：較高閾值或更長持續時間，通知到值班。

這會讓團隊有機會在真正嚴重前介入。

策略三：設計 missing data 的語意

誤報往往不是閾值，而是資料缺失。例如監控到 AWS 指標因為權限或延遲導致短暫空窗，若你把 missing 視為 bad，就可能造成告警風暴。

反之，如果服務停了但告警沒有處理 missing data，你可能失去「停機」這種最重要的訊號。所以要把 missing data 的語意定義清楚：缺失是「正常暫停」還是「異常中斷」。

策略四：把告警與部署/擴縮容事件關聯

部署、重啟、擴縮容會造成短期指標變化。如果你不考慮這些事件，告警會在每次變更時觸發。實務上可以：

• 在發版窗口調整告警靈敏度（例如暫時降低告警或延長評估週期）。
• 或至少讓告警訊息明確包含當前部署版本/環境，方便排除「只是發版」。

第九章：整合日誌（Logs）與告警（可選但很有力量）

純指標告警適合做「狀態判斷」，但如果你需要更快定位原因，日誌告警能補足。CloudWatch Logs 可搭配特定條件（例如錯誤關鍵字）觸發告警。

這類告警在以下場景特別有用：

• 程式拋出特定例外（Exception）或錯誤碼。
• 依賴服務超時（timeout）或連線失敗。
• 某段業務流程出現特定錯誤訊息（例如「payment declined」）。

但也要小心過度敏感導致誤報。建議把日誌告警和指標告警做互補：指標告警負責觸發事件範圍，日誌告警負責提供原因線索。

第十章：一套可持續運作的告警流程

告警建立不是最後一步。真正的運維成熟度，來自「迭代」。建議你把告警流程納入團隊的運作節奏。

告警落地後要做的三件事

• 盤點告警噪音：每週或每兩週檢查觸發次數、誤報率。對誤報高的告警做調整：提高評估週期、改用更合適統計方式、或用運算式引入條件。
• 補齊處置流程：每個告警都應該對應一段「你應該先看什麼」。至少讓值班能在 5 分鐘內完成初步判斷。
• 覆蓋新風險：當架構改了、服務新增了、或 SLA 變更，告警也要跟著更新。舊告警可能變得不再有用，甚至帶來錯誤信心。

AWS帳號註冊 用指標驗證告警是否有效

你可以用簡單但有效的評估方法：當告警觸發時，值班人員是否能在短時間內定位原因、是否能在 SLA 受影響前介入。若告警經常「觸發但無法幫助決策」，就說明告警的設計還沒貼近業務。

第十一章：實作建議與常見錯誤

最後列幾個最常見的實作坑，避免你在第一次部署時就踩雷。

錯誤一：閾值直接照抄

很多文章給出的 CPU 80%、錯誤率 1% 是「起點」。如果你照抄而不看基線，你可能在正常時就被告警洗版，或在異常前完全沒有訊號。

錯誤二：只設單一指標

單一指標很容易讓你做出錯誤判斷。例如 CPU 高可能是正常批處理，也可能是下游卡住導致排隊。更好的做法是用多指標或運算式組合判斷。

錯誤三：沒有處理部署與擴縮容

每次發版都觸發告警，久了就沒人信。相反地，如果你完全屏蔽部署期間告警，也可能漏掉真故障。建議把策略「調整靈敏度」而非「一刀切停掉」。

錯誤四：忽略 missing data 的語意

這是最容易造成「告警失真」的問題。請先想清楚：缺失資料代表什麼？代表服務停了？代表監控中斷？代表實例縮容正常？不同答案需要不同設定。

結語：把告警變成團隊的決策系統

AWS CloudWatch 告警設定的真正價值，不在於你把某個閾值填進去，而在於你把「異常」定義得更接近業務，並讓通知導向正確行動。從選對指標、設計週期與評估週期、處理缺失資料，到運算式打造更有意義的比例告警，再到 SNS/通知通道的可處置內容，最後用迭代把噪音降到可接受，告警才會成為運維的長期資產。

當你能做到：告警不再只是訊息，而是決策的起點；當值班的人看到通知就知道下一步看什麼，那麼 CloudWatch 的告警體系就真正落地了。