亞馬遜雲國際 AWS CloudWatch監控延遲問題

第一章：你以為在看延遲，其實在看觀測延遲

延遲問題最常見的陷阱，是把「系統本身的延遲」誤當成「你在 CloudWatch 看到的延遲」。CloudWatch 指標通常有統計週期、聚合方式、延遲上報時間，甚至資料本身就不是單次請求的真實值。當團隊在例會上說「延遲已恢復」時，有可能只是指標回到正常區間；但真正的用戶體驗、或是某個關鍵依賴仍然慢著。

要讓排查真正有效，先把問題說清楚：你要處理的是哪一種延遲？回應延遲、處理延遲、排隊延遲、還是資料傳輸延遲？它們看似同一個詞，觀測方式與根因卻完全不同。

以一個典型場景為例：API 接到請求後回覆。用戶感受到的延遲，可能包含至少五段：DNS/連線、負載均衡與排程、應用程式處理、對資料庫或下游服務呼叫、再加上序列化與回傳。每一段都有自己的影響因素，也就需要不同的指標與日志去對齊。

延遲要分層看：從用戶到依賴

我建議把延遲拆成三層來理解：端到端（E2E）、服務內部、依賴與資源層。

• 端到端延遲：從用戶發起到服務回覆。最直接，但資訊最少，需要搭配追蹤或分段計時。
• 服務內部延遲：應用程式內部的處理時間、排隊等待時間、併發控制、序列化與外部呼叫前的準備。
• 依賴與資源層：網路、負載均衡、VPC 路由與 NAT、資料庫、快取、佇列、SQS/SNS、以及下游服務的處理或吞吐。

當你用 CloudWatch 去看「延遲」時，首先確認你看到的到底是哪一層。例如 ALB/ELB 的 TargetResponseTime 更像是服務回應時間；Lambda 的 Duration 是函數執行時間；RDS 的 CPU/IO 指標是資源壓力的間接訊號；而自訂的 application latency 才更接近真正的服務內部延遲。

第二章：CloudWatch 常見資料源與延遲觀測方式

CloudWatch 的核心能力很像一個「觀測平台」。你能看到的不是單一事件，而是指標、日誌和告警之間的關係。理解這些資料源的差異，你才不會被數字帶著走。

Metrics：指標的聚合與統計是第一個要問的問題

CloudWatch Metrics 通常以固定粒度（例如 1 分鐘或 5 分鐘）聚合。若你遇到瞬間的尖峰延遲，並且尖峰剛好落在某個統計週期邊界之外，你可能看不到真相。更糟的是，某些指標會採用平均值、p95 或 p99 這些統計彙總。如果業務延遲分佈呈長尾，平均值可能掩蓋問題。

因此在設定排查與告警時，至少問三個問題：

• 指標粒度是多少？ 是否需要更細的粒度或改成事件驅動告警？
• 採用的統計是什麼？ p95/p99 比平均值更能反映用戶體驗。
• 延遲是否與流量量相關？ 有些延遲是擁塞造成，流量高峰往往帶來明顯的尾延遲。

此外，一些服務指標本身就可能有上報延遲。例如日誌處理與指標提取有管線延遲，導致告警比實際事故晚，甚至晚到你錯過定位的關鍵窗口。

亞馬遜雲國際 Logs：用事件補上 Metrics 的盲區

如果 Metrics 僅能告訴你「慢了」，Logs 才能回答「為什麼慢」。尤其當你懷疑某個特定錯誤、超時重試、或外部呼叫變慢時，日志往往能提供更直接的證據。

實務上，Logs 的價值在於：你可以用關鍵字、錯誤碼、traceId、requestId，把一次請求的上下游行為串起來。當你發現某個錯誤碼在延遲尖峰時同時出現，就有了明確方向。

但也要注意：CloudWatch Logs Insights 的查詢也有成本與時間限制。良好的做法是，提前在應用程式中把可用欄位寫入日誌，例如 traceId、userId、route、dependencyName、durationMs、retryCount。你不是臨時才想起可觀測性，而是事故來時能立刻查。

Alarms 與 Dashboard：告警是提醒，不是答案

告警的目的，是告訴你「現在值得看」。它不是根因分析工具。很多團隊把告警設成單一指標閾值，結果每次都只能回到「再看一次」。更有效的做法是把告警與面向根因的上下文綁在一起：例如同時監控延遲與錯誤率、同時監控延遲與 CPU/連線數、同時監控排隊指標與請求量。

Dashboard 則適合做「事故前後對齊」。你可以把端到端延遲、服務內部延遲、下游依賴延遲、錯誤碼、流量、資源指標，全部放在一張圖上。當事故發生時，人的注意力是有限的，一張圖往往比多次翻查更快。

X-Ray 或分散式追蹤：把延遲拆回原點

當延遲是分散式造成（多個服務彼此呼叫），僅靠指標與日志往往不夠。X-Ray 的價值在於：它能讓你在一次鏈路中看見每一段耗時。特別是當你遇到「平均正常、但少量請求特別慢」的長尾延遲，追蹤會非常快地指向哪個環節拖了後腿。

如果你沒有啟用 X-Ray，也可以在應用程式層加入分段計時與 traceId。CloudWatch 本身不會憑空產生這些資訊，只有你把它們寫入，觀測才有細節。

第三章：定位延遲的實戰流程（從快到慢）

當事故來臨，你需要一個能在十到二十分鐘內給出方向的流程。否則每次排查都會陷入「查什麼都可能」的無限循環。

步驟一：先判斷是全局還是局部

第一件事不是看延遲指標，而是判斷延遲是否集中在特定路由、特定資源、或特定依賴。

• 若全局端到端延遲增加，同時錯誤率也上升：更可能是資源飽和、連線或佇列問題。
• 若僅某些 API 慢：更可能是該 API 的依賴變慢（例如某張查詢慢的資料表）或是該路徑的程式碼路徑改變。
• 若僅某些地區或特定時間窗慢：可能與網路路由、NAT、或部署/配置變更相關。

這一步的關鍵，是讓你把排查範圍從「整套系統」縮到「一條鏈路」。

步驟二：用端到端指標對齊時間線

在 CloudWatch Dashboard 或告警中，先找到延遲尖峰的起止時間。接著把同一時間線上的關聯指標打開：請求量、錯誤率、重試次數、CPU/記憶體、佇列深度、資料庫連線數、以及依賴的延遲。

很多根因是同步出現的：例如延遲上升同時錯誤率上升，或延遲上升同時佇列深度上升。只要你把時間線對齊，答案就會比你預期更接近。

步驟三：分段比對——從服務外到服務內

接下來是把延遲「往內縮」。以常見架構來說，你可以按照下列順序比對：

• 負載均衡層（ALB/ELB）：看 TargetResponseTime、HTTP 5xx、RequestCount。
• 計算層（EC2/Auto Scaling、ECS、Lambda）：看 CPU、Memory、Throttling、Duration、Queue time。
• 應用層：看自訂的 handler latency、GC 次數、Thread 池耗盡、外部呼叫耗時分段。
• 依賴層：RDS/ElastiCache 的慢查詢、IO 延遲、cache miss ratio；SQS 的處理延遲；下游 API 的 latency/p95。

你不必一次看所有指標。通常只要找到「哪一段先開始變慢」，根因就已經有 70% 的方向。

步驟四：用 Logs 確認“慢”的型態

指標告訴你慢了，但日志會告訴你慢的型態。常見型態包含：

• 超時：外部呼叫超時、連線逾時，或資料庫等待超時。
• 重試：重試次數上升造成雪崩式延遲。
• 鎖與等待：資料庫慢可能是行鎖或索引問題。
• 排隊：工作佇列深度上升、或 thread pool 耗盡。

當你在 Logs 中看到某個錯誤碼集中出現，或看到 retryCount 的 distribution 明顯左移/右移，基本就能鎖定根因類型。

步驟五：驗證根因，而不是只停在“可能”

在定位時，人很容易停在推測。要避免這點，你需要一個驗證方式：例如回放一段 trace、對照某個 release 的開始時間、或比較特定租戶/路由的差異。

舉例來說，如果你懷疑某個資料庫查詢變慢，不能只看資料庫 CPU。你需要看該查詢的執行時間、執行頻率、以及執行計畫是否因為統計更新或索引變更而改變。CloudWatch Logs 或應用層的 slow query log 可以直接驗證。

如果你懷疑是快取問題，除了看 cache miss，也要看 miss 發生後的下游延遲是否同步上升。否則你可能只是看到 miss 增加，但延遲真正原因可能還在別處。

第四章：常見延遲根因與對應的 CloudWatch 觀測點

延遲問題的根因通常不是神秘事件，而是一些很規律的失衡：容量、連線、排程、或依賴不可預期。以下把常見根因與你應該看的指標/日志放在一起。

亞馬遜雲國際 根因 1：資源飽和造成排隊（CPU/Memory/執行緒/Worker）

當計算層或應用層資源飽和，延遲不會是均勻增加，而是呈現尾端惡化。你會看到 p95/p99 明顯比平均值更糟。

• 亞馬遜雲國際 指標：CPU 利用率高、Memory 壓力、Thread pool 活躍執行緒飽和、Lambda throttles、ECS 待處理任務。
• 日志：請求處理時間分段中，某一段（例如等待鎖或等待 thread）突然拉長。

處理方式通常是容量調整（擴容）或調整並發策略（限流、背壓）。但要先確認是「能不能擴」還是「擴了也無效」。如果依賴層也在飽和，單純擴容計算層反而會放大問題。

根因 2：資料庫或下游服務的慢查詢/慢處理

資料庫慢查詢會造成等待，表現為應用端的請求耗時增加。你會看到延遲與某些 query pattern 同步。

• 指標：RDS CPU/FreeableMemory 不一定立刻飆升；更關鍵的是 ReadIOPS/WriteIOPS、DBLoad、以及連線等待相關指標（依引擎不同可用性不同）。
• 日志：slow query log、或應用層記錄的 DB call duration。

常見導火索是索引缺失、查詢條件未走索引、統計更新後執行計畫改變，或部署帶來的查詢模式變化。這類根因最好用 slow query/trace 直接驗證，而不是只看 CPU。

亞馬遜雲國際 根因 3：快取失效或雪崩（Cache miss 放大下游）

快取看起來只是命中率問題，但實際上它會把系統的負載分配方式改掉。一旦 miss 變多，下游服務壓力瞬間上升，延遲會在短時間內快速惡化。

• 指標：命中率下降、cache size 變小、或 cache eviction 次數上升。
• 日志：cache key 生成方式是否變了、重建/回填行為是否異常、以及 miss 後的下游呼叫耗時。

亞馬遜雲國際 你需要關注的不只是 miss，而是 miss 的突發程度與回填策略。例如回填同步做會拖慢請求；回填非同步則可能減少尾延遲。CloudWatch 的觀測應該能把「miss 的瞬間」與「延遲的瞬間」對齊。

根因 4：網路與連線問題（DNS、NAT、連線耗盡）

網路問題很難從單一指標判斷，但它們通常呈現為：連線建立耗時上升、TLS 握手耗時上升、或某些環節突然出現 timeout。

• 指標：若是 ALB，可看 TargetResponseTime 以及錯誤碼型態；若是服務內部，則看 connect latency/dns latency。
• 日志：連線超時、socket hang up、DNS lookup failed、重試次數上升。

常見誘因是 NAT gateway 出口耗盡、連線池配置不合理、或某次部署引入了新的目的端域名/解析行為。

根因 5：自動擴縮容或調度策略導致“延遲晃動”

擴縮容不是免費的。當擴縮容以步長或 cooldown 設定不恰當，會出現：流量上升時擴不動，導致延遲尖峰；流量下降時仍保留過多容量，平均延遲看似正常但成本上升。更糟的是，某些調度或批次處理可能引入“節奏性延遲”。

在 CloudWatch 中，你應該把延遲與擴縮容事件對齊：Auto Scaling 活動、ECS 事件、Lambda 併發限制。只要看到延遲尖峰與擴縮容的延遲落後對齊，你就可以把根因從“應用變慢”改成“容量反應慢”。

第五章：告警怎麼設，才不會把你拖進噪音

告警設計是工程能力的一部分。設太少，你錯過訊號；設太多，你在噪音裡迷路。更重要的是：告警要能告訴你“接下來該看哪裡”。

告警組合：延遲 + 錯誤率 + 流量/資源

單一告警最容易誤判。例如 p95 延遲突然上升，可能是流量剛好飆升但系統仍可用；也可能是資源飽和。若你同時監控錯誤率與請求量，就能快速區分。

• 延遲告警：以 p95/p99 或分位數（若可用）為主，避免只用平均。
• 錯誤率告警：5xx 比 4xx 更能反映後端故障。
• 資源告警：CPU/Memory/Throttling/佇列深度，讓你知道是排隊還是依賴問題。
• 流量參考：請求數突增時延遲上升並不一定代表故障，但需要確認是否超出容量。

亞馬遜雲國際 告警門檻不是“拍腦袋”，要跟分佈與季節性對齊

很多團隊用固定數字當門檻。這在有季節性流量或不同時段效能差異的系統上會失準。更好的方式是：用歷史數據估計正常區間，再設定合理的緩衝與持續時間（evaluation period）。

同時，當延遲分佈長尾時，比起設定平均值閾值，更應關注 p99。因為事故常在尾端發生，用戶感受也主要來自尾延遲。

避免告警風暴：加入抑制與分級處理

你可以把告警分層：

• 資訊級：延遲小幅上升，但不影響可用性，提供趨勢。
• 警告級：延遲上升且錯誤率開始增加或資源開始逼近瓶頸。
• 嚴重級：p99 長時間超標且錯誤率上升，或出現大量 timeout。

分級的好處是：值班人員不會因為大量告警而疲勞，嚴重事件反而會被更快注意到。

第六章：把排查結果沉澱成“可重複的流程”

延遲事故最可怕的不是那一次，而是它會反覆發生。當你每次都從頭查，時間成本會越來越高。真正成熟的做法是把排查流程變成團隊資產。

建立“延遲劇本”：按現象走查一組固定問題

你可以把常見現象做成劇本。例如：

• 現象 A：端到端延遲 p99 上升，但錯誤率低——可能是排隊或依賴慢但未超時。
• 現象 B：延遲上升且 5xx 上升——可能是資源耗盡、連線問題或程式異常。
• 現象 C：延遲上升但某些路由才有——可能是查詢變慢或第三方 API 特定操作。
• 現象 D：延遲呈週期性——可能是批次任務、排程尖峰或調度策略造成的波動。

每個劇本都列出：應查看哪些 dashboard 區塊、哪些日志關鍵字、以及預期會看到什麼結果。下次事故來時，排查速度會明顯提升。

把“證據”寫進事後報告：不是只寫結論

事後報告常見問題是只寫「我們發現是某某原因」。但如果你沒有寫證據鏈，下一次你仍需要重複確認。建議每次事故至少包含四段內容：

• 觀測到的現象：哪些指標在什麼時間變化，分位數如何變。
• 亞馬遜雲國際 排除的可能性：例如排除資料庫 CPU、排除網路異常。
• 確認的證據：某段 trace 顯示哪個 dependency 變慢、某條 slow query 的耗時證明等。
• 修正與驗證：改了什麼、發布點是什麼、驗證了哪些指標恢復。

這樣你才真的能把經驗轉成未來的能力。

第七章：如何避免“看錯方向”的常見工程失誤

很多延遲事故不是因為技術不夠，而是因為觀測方法與工程習慣不夠嚴謹。以下是我見過最常導致誤判的幾個點。

亞馬遜雲國際 失誤 1：只看平均值，不看分位數

平均值會被大量正常請求稀釋，長尾延遲會消失。用戶最痛的通常是 p95/p99。除非你的業務延遲分佈非常均勻，否則都應優先關注分位數。

失誤 2：沒有對齊時間線，導致證據不成立

指標與日志的延遲上報、查詢粒度差異、以及事件發生與你看到數字之間的延後，都可能讓人誤判因果關係。排查時要刻意對齊：確認你看到的變化時間是否晚於實際事件。

失誤 3：把“延遲”與“吞吐”混為一談

當吞吐上升，延遲可能自然上升。正確做法是看延遲是否在容量可接受範圍內，以及是否出現尾端惡化或錯誤率同步上升。只盯延遲而不看吞吐，你可能對正常變化過度反應。

失誤 4：沒有把關鍵欄位寫入日志

如果日志沒有 traceId、requestId、dependencyName、durationMs、retryCount，你在事故時只能查到“錯了什麼”，卻無法證明“哪段慢”。可觀測性不是一次性開關，而是每次迭代都應補齊的工程需求。

結語：延遲不是數字，是可被拆解的故事

AWS CloudWatch 讓我們看見系統的影子，但延遲真正的樣貌藏在分層的故事裡：用戶體驗、服務處理、依賴與資源的節奏。當你把觀測延遲、指標聚合、以及分段計時的差異考慮進來，你就會從“看見變化”走向“找到因果”。

下一次遇到 CloudWatch 上的延遲尖峰，不要急著下結論。先縮小範圍、對齊時間線、分段比對、用日志或追蹤確認證據，最後把驗證與修正寫成劇本。延遲問題才會真正從反覆發生的噩夢，變成可管理的工程流程。