AWS實名認證 亞馬遜雲流量監控報警與設置CloudWatch自定義

第一章：為什麼要監控「雲流量」，而不是只看錯誤

在上雲之後，很多團隊最先關注的通常是「錯誤率」。例如 5xx 是否飆升、應用是否拋例外、容器是否崩潰。這些當然重要，但它們屬於“結果”。而真正能幫你提前發現問題、縮短定位時間的，往往是“過程”：流量何時變大或變小、來源是否異常、延遲如何爬升、連線是否被拒絕、在網路層是否已經出現壅塞或安全攔截。

雲端的流量監控通常不是單一指標就能解決的，它需要把多層觀測拼成一張“地圖”。例如：負載均衡層看吞吐和延遲，應用層看處理時間與隊列壓力，網路層看連線與流向，平台層看資源是否被打滿。當你把這些訊號連起來，再加上告警，才會得到一個能讓你在問題發生前或剛發生時就反應的監控系統。

本文的目標，是讓你能把“監控報警”和“CloudWatch 自定義指標”落到可操作的層面：你該從哪些來源取數據、告警怎麼設、維度如何設計、以及如何把你真正關心的業務事件（而不是只有平台事件）變成可追蹤的指標。

第二章：監控架構的基本思路——先決定你要保護什麼

在開始建指標之前，先想清楚你要保護的目標是什麼。不同目標會導致你監控的指標與告警門檻完全不同。

常見目標可以分成三類：

1）可用性：服務是否還能對外回應。告警通常看錯誤率、成功率、延遲、連線失敗等。

2）性能：即使沒有大量錯誤，也可能已經開始降級。告警通常看延遲上升、吞吐下降、CPU/記憶體壓力、佇列堆積。

3）安全與合規：異常流量或攻擊嘗試。告警可能看來源 IP 的突增、封包被拒絕的增多、WAF 觸發率、Flow Logs 中的拒絕行為等。

當你定義清楚目標，接下來就能決定：你要哪些來源（Load Balancer、API Gateway、VPC Flow Logs、應用埋點、資料庫），以及要把哪些事件映射成 CloudWatch 指標。

第三章：CloudWatch 的核心概念——指標、維度、週期與告警

CloudWatch 監控的單位是「指標（Metric）」；每個指標會有「維度（Dimension）」來區分不同資源或來源。這裡最容易踩的坑是：你把所有東西都放在同一個指標裡，最後告警無法判斷到底是哪個環境、哪個服務或哪個節點出問題。

實務上，你可以把維度設計成能讓你快速定位問題的組合。例如：

— 環境：prod / staging

— 服務：api / worker / web

— 區域：ap-southeast-1 / us-east-1

— 端點或路徑：/login、/search（若你需要）

AWS實名認證 — 負載均衡器或目標群組：target group 名稱

— 消費群組：SQS queue 名稱（若是事件驅動）

告警的週期（Period）也很關鍵。Period 太短會導致噪音太大，Period 太長又會延誤反應。常見做法是先從 1 分鐘或 5 分鐘開始，根據吞吐與流量波動再調整。

最後是告警策略：你需要清楚你的告警是要“提醒你正在惡化”，還是“確定已經失效”。前者可以使用較敏感的條件配合較短的延遲（例如連續幾個週期觸發），後者就用更嚴格的門檻或更長的確認窗口。

第四章：先用現成指標搭起基本告警網——從 ELB/ALB、API Gateway 開始

如果你的架構使用 ALB（或 NLB）與 API Gateway，那 CloudWatch 通常已經提供不少內建指標，你不必一開始就從零自建。

4.1 針對 ALB/ELB：延遲、錯誤、吞吐、連線

在 ALB 常用的監控方向有：

— TargetResponseTime 或類似延遲指標：觀察後端處理變慢。

— HTTPCode_Target_5XX_Count / 4XX：判斷是否有錯誤風暴。

— RequestCount：流量是否突然下降或突然暴增。

— TargetConnectionErrorCount：後端連線是否失敗。

建議你用“趨勢+門檻”的方式，而不是只用單一固定值。例如延遲告警可以採用：

— 基於 95 分位延遲的門檻（若可用）

— 或者延遲比平常上升一定百分比（但要先確認你沒有季節性波動）

另外，錯誤率告警要避免誤判：某些服務在低流量時候 1 次錯誤就會讓 5xx 比例看起來很高。這時可以加上最低請求量條件，或使用絕對錯誤數（例如 5 分鐘內 50 次以上）。

4.2 針對 API Gateway：吞吐與延遲的“服務化視角”

API Gateway 常見監控也包含延遲、錯誤碼分佈、節流（throttling）等。對團隊而言，它更像是“對外合約”的觀測點：你可以按 Stage、API、Method/Resource 來細分告警。

設告警時，通常要特別注意：

— 配置變更後是否會立即觸發（例如調整限流或後端整合）

— Stage 的流量差異很大，prod 不要用 staging 的門檻

— 某些 4xx 是正常業務（例如驗證失敗），你應該針對“非預期”的類型設告警

第五章：把網路層也納入——VPC Flow Logs 與流量異常告警

很多延遲或錯誤並不直接反映在應用的 5xx 上。比如攻擊造成大量連線嘗試，或安全規則導致連線被拒；又或者路由/安全群組導致某些目標群組連不到。這些狀況，用 ALB 指標可能看不到全貌。

因此你需要在網路層補一刀：VPC Flow Logs。它提供了“誰在和誰通訊、是否被拒絕、流量大小、協議與端口”等訊息。

5.1 開啟 Flow Logs，並定義你要落在哪裡

流程上通常是：在 VPC 開啟 Flow Logs，選擇輸出目的（S3 或其他可分析的位置），再由你建立分析管道（可用 Athena/Glue、或用訂閱把數據送到監控/告警服務）。

注意：Flow Logs 本身不是“告警服務”，它的價值在於你能從中萃取出可用指標。也就是把“原始事件”轉成“可計數、可告警的數值”。這就引出了下一章的核心：CloudWatch 自定義指標。

5.2 常見的網路層告警指標方向

你可以從 Flow Logs 萃取這類告警：

— 拒絕率上升：例如 action='REJECT' 的連線數在短時間內快速增加。

— 特定來源 IP 或 ASN 突增：外部掃描或攻擊通常會帶來突增。

— 異常目的端口：例如原本只有 443，突然出現 3389/23 等嘗試。

— 流量包大小或連線時長異常：某些攻擊會造成大量短連線。

這些告警的關鍵不是“精準”，而是“能及時讓人知道需要查”。當你真正遇到事件時，你希望告警能縮小排查範圍，而不是提供一堆難以解讀的數據。

第六章：建立 CloudWatch 自定義指標——把你關心的事量化

內建指標的好處是省時間；但它們的侷限也很明顯：你只能看到平台層的“標準視角”。而你真正要監控的，往往是你自己的業務邏輯：例如“下游依賴是否慢”“任務處理是否堆積”“某類錯誤是否集中在特定客戶群”或“某端點在某時間段是否異常耗時”。

這時就需要 CloudWatch 自定義指標，把事件或計算結果上報到 CloudWatch，配合告警通知形成閉環。

6.1 自定義指標上報的常見方式

實務中常見的上報方式包括：

— 應用程式直接呼叫 CloudWatch PutMetricData（適合指標數量不多、頻率可控）

— 使用 CloudWatch Agent 或自動化收集器（適合系統層，如自訂 CPU/記憶體/磁碟行為）

— 由事件驅動服務計算後上報（例如 Lambda 定時/事件觸發，從查詢結果得出指標）

— 從日誌分析產生指標（例如先把 log 指標萃取成數值，再上報）

AWS實名認證 對於“流量監控”這個主題，我建議：把你想要告警的結果先在分析層得到，再由計算層上報自定義指標。原因很簡單：原始資料往往太多、太雜，如果直接把原始事件一筆筆丟進 CloudWatch，不僅昂貴，還會讓維度與告警設計變得失控。

AWS實名認證 6.2 指標命名與維度設計：讓告警能定位

命名規則沒有單一“宇宙規格”，但你應該遵守可讀性與一致性。常用做法是：

AWS實名認證 — Namespace：例如 'CustomTrafficMonitoring'、'MyServiceMetrics'

— MetricName：例如 'RejectedConnections'、'EndpointLatencyP95'、'AuthFailureRate'

— 維度：環境、服務、端點或目標群組等

當你設告警時，CloudWatch 會按維度分組。假如維度太多，就會導致你很難管理告警（而且成本也會升高）。因此你要在“能定位”與“可管理”之間取平衡。

6.3 量化方法：把事件變成可告警的數值

以網路拒絕連線為例，你可以在分析層做如下計算：

— 在固定時間窗（例如 5 分鐘）內，統計 VPC Flow Logs 中 REJECT 的連線數

— 再計算每秒率或每 5 分鐘的絕對數

— 最後上報一個指標：RejectedConnections（單位 count 或 per 5min）

這個指標接著就能被告警：當短時間內拒絕數超過門檻，通知值班人員。

如果你想更“業務化”，也可以把特定來源（例如某國家或某端點）視為維度，形成更有意義的告警。

第七章：告警設置策略——門檻不是越敏感越好

很多團隊告警失效，不是因為 CloudWatch 不夠好，而是因為策略設錯。你要避免兩種狀況：告警太多（噪音）導致值班麻木；以及告警太少（漏報）導致事故後才知道。

7.1 建議的三段式告警：預警、異常、失效

你可以把同一條服務建立三種告警等級：

— 預警：例如延遲或拒絕率比過去上升到某個程度，但還沒有造成錯誤爆炸。

— 異常：延遲持續上升、錯誤碼出現明顯增長，或吞吐出現斷崖。

— 失效：錯誤率或失敗數已經足以影響使用者，需立即介入。

這樣做的好處是：你可以在不同等級安排不同響應流程。預警可能只通知觀測人員，異常開始需要快速排查，失效則啟動應急流程。

7.2 以時間窗降低誤報

告警通常要搭配 “在 N 個週期內滿足條件” 的設定。與其用單一瞬間門檻，不如用連續條件。例如延遲在 1 分鐘內尖峰可能只是偶發；但連續 5 分鐘上升意味著系統真的在惡化。

7.3 門檻的建立：從基線開始

門檻不是拍腦袋。你應該先觀察一段時間的基線，找出正常範圍與波動。對流量監控尤其如此：流量天生會有工作日/非工作日差異。

實務上你可以這樣做：

AWS實名認證 — 取至少 7 天資料，計算平均與分位（若可用）。

— 把告警門檻設在“正常上緣之外”，並留出緩衝。

— 再根據事故回顧調整：你是否在事故前收到了預警？是否事故期間告警過早或過晚？

第八章：把監控與報警做成可執行的流程——從通知到定位

監控系統最後要落在行動上。告警觸發後，你需要值班人員有一個清晰的路徑，知道接下來要看什麼。

8.1 通知通道：不要只看郵件

常見做法是把 CloudWatch 告警接到 SNS，進而推送到團隊的通訊工具或事件系統。你需要確保：

— 不同告警等級可以走不同通知頻道（或不同抑制策略）

— 通知包含足夠上下文：服務名、環境、觸發條件、指標值、時間範圍

— 有沉默/抑制機制：例如維護窗口、已知變更期間的降噪

8.2 典型定位順序：先查流量，再查依賴，再查資源

遇到告警時，建議你用一個固定順序：

1）流量是否異常：RequestCount 是否突增/突減？來源是否集中？

2）延遲或錯誤是否同步上升：是否是延遲先上升？

3）依賴是否在惡化：下游呼叫是否慢？資料庫是否繁忙？

4）資源是否被打滿：CPU/記憶體/連線池/Worker backlog

若你在網路層設了 Flow Logs 自定義指標，那你就可以更早判斷“不是應用問題，而是連線在路上就被拒絕了”。這會顯著縮短定位時間。

AWS實名認證 第九章：一個完整示例——監控拒絕連線與端點耗時，並建立自定義告警

下面用一個貼近實務的例子串起整個流程：假設你有一個面向外部的服務，通過 ALB 暴露 HTTPS，後端是容器服務。你希望在以下情況提前告警：

— 外部來源嘗試連線但被安全規則拒絕（REJECT 上升）

— 某些端點耗時上升（延遲/超時增加）

— 這兩者若持續，則進入更高告警等級

AWS實名認證 9.1 內建指標：先做基本可用性與延遲

你可以先在 ALB 上設置：

— 預警：TargetResponseTime 平均或 P95 在 5 分鐘內超過基線上緣。

— 異常：5xx 比例或 5xx 次數在短時間內上升。

— 失效：5xx 次數或成功率持續下滑。

AWS實名認證 同時，也設 RequestCount 的異常下滑告警（因為流量突然下降有時不是自然波動，而可能是依賴故障或網路阻斷）。

9.2 網路層：用 Flow Logs 萃取 REJECT 連線數

你在 VPC 啟用 Flow Logs。然後你建一段分析/計算邏輯（例如定時任務每 5 分鐘跑一次），從 Flow Logs 內統計：

— 時窗內 REJECT 的連線數

— 可能的維度：端口（例如 443）、目的目標（例如目標群組後的子網）、來源區域或安全群組等（視你資料可得性）

最後你把結果上報到 CloudWatch，自定義指標命名為：

— Namespace：CustomTrafficMonitoring

— MetricName：RejectedConnections

— 維度：Environment、Service、Port（或其他可定位維度）

指標單位選擇固定時間窗內的 count，並在告警中明確使用相同的週期/粒度。

9.3 自定義告警：預警—異常—失效

對 RejectedConnections，你可設：

— 預警：5 分鐘內 REJECT 次數超過基線上緣的 2 倍（或超過某個絕對值，但要先看你平時的流量水平）。

— 異常：持續 10 分鐘（連續兩次週期）超過更高門檻。

AWS實名認證 — 失效：同時觸發 ALB 的延遲上升或 5xx 增加（用“關聯邏輯”的方式，或在告警管理上把兩種告警做聯動）。

這裡的重點是：你不是只看 REJECT，而是讓 REJECT 與性能/可用性指標結合，避免單純安全掃描帶來的噪音造成誤報。

9.4 應用層：端點耗時與超時的自定義指標

如果你已經在應用內埋點（例如統計每個端點處理時間、超時次數、下游呼叫失敗），就可以把它們變成 CloudWatch 指標。例如：

— MetricName：EndpointLatencyP95

— MetricName：EndpointTimeoutCount

維度可以用：Environment、Service、Endpoint（例如 /login、/search）。

注意 Endpoint 維度可能非常多，會影響告警管理。你可以採用策略：先只監控高流量或高風險端點；或把 Endpoint 類型做聚合（例如 Auth、Search、Checkout）。

第十章：成本與可維護性——讓自定義指標長久活下來

自定義指標很有力量，但也容易變成“指標墓地”。如果你沒有治理，就會出現：

— 指標太多，告警到處都是，沒人敢改

AWS實名認證 — 維度爆炸，導致成本與查詢複雜度上升

— 指標定義不一致，團隊理解分裂

因此你需要兩個治理機制：

1）指標白名單：只有被確認能回答問題的指標才允許建立告警。

2）生命周期：告警不是永遠有效。每次事故後都要回顧：告警是否有幫助？是否需要調整門檻或停用某個不再重要的指標。

另外，CloudWatch 自定義指標的上報頻率也要控管。對於計數型指標，盡量做聚合後上報（例如每 1 分鐘或 5 分鐘），避免逐事件上報。

第十一章：常見踩坑清單——把時間花在正確地方

下面整理幾個常見問題，幫你在實作時少走彎路。

11.1 門檻沒有基線，導致告警“看起來很合理但其實沒用”

很多團隊一開始就用固定數值，例如“延遲超過 1 秒就告警”。但如果你的服務延遲本來就接近 900ms，這個告警就沒有區分力。相反，如果服務正常是 50ms，門檻太高又會延誤反應。你需要基線。

11.2 維度設計過度，導致告警管理失敗

例如你把每個 endpoint、每個客戶 ID、每個 Pod 都塞進維度。這會造成維度組合數巨大，告警也會變成“全都在響”。合理做法是聚合到可定位但不失控的粒度。

11.3 只看平台指標，忽略“事件真正的意義”

平台指標可能告訴你“拒絕了”，但你需要判斷這是安全掃描正常行為，還是攻擊造成的壓力；也需要知道它是否影響使用者。用關聯策略或加上第二條條件，就能讓告警更接近真實事件。

11.4 自定義指標沒有一致的命名與定義口徑

例如 EndpointTimeoutCount 到底是“超時的請求數”還是“超時的次數”？在不同團隊改動後就會混亂。你要固定計算口徑，並寫在指標定義文件或工程註記中。

第十二章：落地建議——從小做起，讓系統越來越聰明

如果你正在建立或重構監控體系，不必一次做到完美。建議路線是：

第一步：先用內建指標建立基本告警（可用性與延遲）。確保值班能收到有用的通知，且能快速定位。

第二步：補上網路層的訊號（VPC Flow Logs 萃取拒絕率或異常連線）。把“路上的問題”提前暴露。

第三步：建立自定義指標，只選擇最能反映事件的計算結果上報。先把告警效果跑起來，再逐步擴大覆蓋面。

第四步：做告警治理與回顧。每次事件後調整門檻、關聯條件與維度粒度，讓系統更貼近你的業務。

監控不是一次性的工程，而是會隨業務變化而演進的能力。你越能把“流量”與“風險”之間的關係具體化，就越不會在事故發生後才手忙腳亂。

結語：把流量監控變成預警系統，而不是報表

亞馬遜雲的流量監控要做得好，關鍵不在於你收集了多少資料，而在於你把資料轉成可行動的訊號：讓告警能在正確的時間提醒你，讓自定義指標能反映你真正關心的變化，讓維度與門檻能在事故發生時快速縮小範圍。當你把 ELB/API Gateway 的內建觀測與 VPC Flow Logs 的網路層訊號，以及 CloudWatch 自定義指標的業務化計算串成一體，監控就會從“看板”升級為真正的預警與回溯系統。

如果你願意從一個最痛的問題開始（例如拒絕連線引發的延遲上升、或某端點超時擴散），你就能在最短時間看到價值。剩下的工作，是把它做穩、做準、做可維護。這才是監控工程真正值得投入的地方。