Amazon CloudWatch：指標、日誌與警報

Amazon CloudWatch 是 AWS Certified Developer Associate（DVA-C02）考試中測驗頻率最高的可觀測性服務。任務說明 4.2「為可觀測性埋點」給出了一份簡短卻密度極高的考點清單：Amazon CloudWatch Metrics、Amazon CloudWatch Logs、Amazon CloudWatch Alarms、Amazon CloudWatch Dashboards、Amazon CloudWatch Synthetics canaries、Amazon CloudWatch RUM，再加上 Embedded Metric Format（EMF）、訂閱篩選器、指標篩選器、CloudWatch Agent，以及 Amazon CloudWatch 與 AWS CloudTrail、AWS Config 等相鄰服務的差異。本章訓練你辨認 DVA-C02 考試可能出現的每一個 Amazon CloudWatch 概念，並在限時壓力下對應到正確答案。Amazon CloudWatch 值得你分配 8 至 10 %的總備考時間；精通 Amazon CloudWatch 可觀測性，是把「我的 Lambda 壞掉了」類型題目轉化為穩拿分數的關鍵。

Amazon CloudWatch 是什麼？

Amazon CloudWatch 是 AWS 託管的可觀測性服務，負責收集、儲存、查詢、視覺化，並針對來自 AWS 服務、應用程式及地端系統的指標與日誌發出警報。Amazon CloudWatch 接收三種訊號類型——指標（數值時間序列）、日誌（文字或 JSON 事件），以及事件（現已更名為 Amazon EventBridge）——並透過儀表板、警報、Logs Insights 查詢、Synthetics canaries 以及 CloudWatch API 對外提供服務。每一個 AWS 服務都會自動將一批內建 Amazon CloudWatch 指標推送過來；你的應用程式碼則可透過 AWS SDK 或 CloudWatch Agent 主動推送自訂 Amazon CloudWatch 指標與 Amazon CloudWatch Logs 事件。

Amazon CloudWatch 在 DVA-C02 考綱中的位置

在 DVA-C02 中，Amazon CloudWatch 橫跨所有領域：

• 領域 1（開發）：AWS Lambda 自動寫入 Amazon CloudWatch Logs；API Gateway 存取日誌落地於 Amazon CloudWatch Logs；DynamoDB 將節流指標發布到 Amazon CloudWatch。
• 領域 2（安全性）：Amazon CloudWatch Logs 以 AWS KMS 加密、日誌目的地帳號的資源政策、針對登入失敗指標設定 Amazon CloudWatch Alarms。
• 領域 3（部署）：AWS CodeDeploy 依 Amazon CloudWatch Alarms 觸發回滾、Amazon CloudWatch 儀表板監控部署健康狀態。
• 領域 4（疑難排解）：Amazon CloudWatch Logs Insights 進行根因分析、Amazon CloudWatch Synthetics canaries 監控可用性、Embedded Metric Format 處理高基數指標。

熟記 Amazon CloudWatch 基礎知識後，領域 4 的得分就如探囊取物；而 Amazon CloudWatch 擔任配角的跨領域題目，也會變成容易拿下的分數。

Amazon CloudWatch 資料模型一覽

Amazon CloudWatch 裡的每一筆遙測資料，都存放在以下兩個命名空間之一：指標存放區（索引鍵＝命名空間＋指標名稱＋維度，值＝數值時間序列，保留期 15 個月並逐步彙總），或日誌存放區（索引鍵＝日誌群組＋日誌串流，值＝附時間戳的事件文字，保留期可設定為 1 天至 10 年或永不過期）。警報監看指標串流；指標篩選器將符合條件的日誌事件轉換為指標；訂閱篩選器以近即時方式將原始日誌事件串流至 Amazon Kinesis、AWS Lambda 或 Amazon Kinesis Data Firehose；儀表板呈現指標與 Logs Insights 查詢；Synthetics canaries 依排定的腳本產生合成指標與日誌。DVA-C02 的所有題目，都從這些基本元件延伸而來。

白話文解釋 Amazon CloudWatch

Amazon CloudWatch 講白了就是 AWS 的「監視室」— 所有服務的心跳、儀表、黑盒子錄音，全部集中在這一個房間牆上。用下面三種類比，Amazon CloudWatch 的幾個抽象概念一次就記牢。

類比一 — 電網調度中心

把 Amazon CloudWatch 想成一座電網調度中心。全城每一個變電站（AWS 服務）都自動把電壓、電流、頻率（內建指標）拉線到這個控制室的儀表板（Amazon CloudWatch Dashboards）；任何一個數值跨過紅線，警報燈（Amazon CloudWatch Alarms）立刻閃爍，自動派遣修復車（Amazon SNS 通知、Auto Scaling、Systems Manager Automation）。黑盒子錄音機（Amazon CloudWatch Logs）同時記下每一次操作日誌，想回查時拿出放大鏡（Amazon CloudWatch Logs Insights）按時段、按關鍵字搜尋。複合警報（composite alarms）是主任級的「當 A 變電站跳閘且 B 變電站電壓異常才算緊急」的組合條件，避免半夜被單一偶發警報吵醒。

Amazon CloudWatch＝雲端服務的電網調度室，儀表、警報、黑盒子一站齊全。

類比二 — 醫院生命監測系統

Amazon CloudWatch 也像醫院的生命監測系統。每一個病人（AWS 資源、應用程式實例）都接上感測器（指標收集器），每分鐘回報心跳、血壓、血氧（標準 1 分鐘指標），重症 ICU 的病人則接上秒級監測（高解析度 1 秒指標）。護理站的大螢幕（Amazon CloudWatch Dashboards）讓值班醫師一眼看完整個病房。數值跨過紅線時警報器響（Amazon CloudWatch Alarms）；連續兩次超標且其他指標一起異常才叫急診（anomaly detection＋composite alarm），避免假警報。巡房護士按排定時間用固定腳本做病例檢查（Amazon CloudWatch Synthetics canaries）——就算沒有真病人，也能先發現設備壞了。

Amazon CloudWatch＝AWS 環境的院內監護系統，全自動、全時段、全科別。

類比三 — 黑盒子飛行記錄器加塔台雷達

Amazon CloudWatch 還像飛機的黑盒子加塔台雷達。每一次飛行（request）的每一步操作、每一筆錯誤、每一句駕駛艙對話，都寫進黑盒子（Amazon CloudWatch Logs）——就算飛機失事，事後也能拆解分析。雷達上（Amazon CloudWatch Metrics）看到的則是即時高度、速度、航向（Invocations、Duration、Errors）。黑盒子可以即時串流到調度中心（訂閱篩選器 → Kinesis / Lambda / Firehose），讓地面先發現異常；也能事後用 Amazon CloudWatch Logs Insights 做 filter + stats 的類 SQL 分析。當管制員要交接給其他塔台（跨帳號或跨區域儀表板），Amazon CloudWatch 支援共享與跨帳號可觀測性。

三個類比串起來，Amazon CloudWatch 的「集中 × 即時 × 可查 × 可警報 × 可合成」五大性格就全清晰了。

Amazon CloudWatch Logs：日誌群組、日誌串流與保留期限

Amazon CloudWatch Logs 是受管的日誌存放服務，幾乎每一位 AWS 開發者在上手的第一個小時就會接觸到它。

日誌群組 vs 日誌串流

Amazon CloudWatch 日誌群組是最上層的容器，儲存共用設定——保留政策、KMS 加密金鑰、指標篩選器、訂閱篩選器、存取控制。日誌串流是來自日誌群組內單一來源的日誌事件序列。對於 AWS Lambda 而言，每個執行環境（sandbox）都有自己的串流，名稱格式類似 2026/04/20/[$LATEST]abc123。對於 Amazon EC2 實例，CloudWatch Agent 通常為每個實例的每個日誌檔建立一條串流。

命名慣例請務必記住：AWS Lambda 日誌群組固定為 /aws/lambda/FUNCTION_NAME；Amazon API Gateway 存取日誌通常指向 /aws/apigateway/ACCESS_LOGS/STAGE_NAME。Amazon CloudWatch 不會自動建立日誌群組，必須等到第一次寫入才會建立；請在 IaC 中預先建立，以便從第一天起就設定保留期限。

保留政策

Amazon CloudWatch Logs 預設永久保留日誌——這是一顆沉默的費用地雷。你必須明確設定保留期限。支援的保留天數為：1、3、5、7、14、30、60、90、120、150、180、365、400、545、731、1827（5 年）、2192（6 年）、2557（7 年）、2922（8 年）、3288（9 年）、3653（10 年）或永不過期。以 aws logs put-retention-policy --log-group-name NAME --retention-in-days 30 對每個日誌群組設定保留期限。

靜態加密

Amazon CloudWatch Logs 始終在靜態狀態下加密。預設由 AWS 管理金鑰。若有合規需求，可為每個日誌群組關聯客戶自管的 AWS KMS 金鑰；Amazon CloudWatch Logs 會代為呼叫 kms:GenerateDataKey 與 kms:Decrypt，因此金鑰政策必須透過 kms:EncryptionContext:aws:logs:arn 條件允許 logs.REGION.amazonaws.com。

Amazon CloudWatch Logs Insights：查詢語法

Amazon CloudWatch Logs Insights 是 Amazon CloudWatch Logs 的互動式查詢引擎，自動解析 JSON 欄位，並支援類 SQL 的管線語言。

核心指令

每一條 Amazon CloudWatch Logs Insights 查詢都是以 | 分隔的指令管線：

• fields — 選擇要顯示的欄位（例如 fields @timestamp, @message, level）。
• filter — 篩選列（例如 filter level = "ERROR" and duration > 1000）。
• stats — 彙總（例如 stats count() by bin(5m)、stats avg(duration) by functionName）。
• sort — 排序（sort @timestamp desc）。
• limit — 限制列數（limit 20）。
• parse — 以 glob 或正規表達式從非結構化訊息中提取欄位（parse @message "user=* action=*" as user, action）。
• display — 選擇結果表格中顯示的欄位。
• dedup — 依指定欄位去重複。

保留欄位

Amazon CloudWatch Logs Insights 自動提供 @timestamp、@message、@logStream、@log 與 @ingestionTime。對於 AWS Lambda 日誌群組，Amazon CloudWatch 額外加入 @requestId、@duration、@billedDuration、@memorySize、@maxMemoryUsed、@initDuration——這些欄位在分析冷啟動時極為實用。

實際範例

找出過去一小時內最慢的 AWS Lambda 呼叫：

fields @timestamp, @requestId, @duration
| filter @type = "REPORT"
| sort @duration desc
| limit 20

以每分鐘桶計算 ERROR 等級事件數：

fields @timestamp, @message
| filter @message like /ERROR/
| stats count() by bin(1m)

解析自訂日誌行並依使用者彙總：

parse @message "user=* action=* latency=*" as user, action, latency
| filter ispresent(user)
| stats avg(latency), count() by user
| sort count desc
| limit 10

計費模型

Amazon CloudWatch Logs Insights 依**掃描的資料量（位元組）**計費。降低掃描費用的方式：（a）縮小日誌群組範圍、（b）縮短時間窗口、（c）盡可能改用指標篩選器預先彙總，（d）只選取所需欄位——Amazon CloudWatch 不按回傳欄位數計費，但縮小時間範圍與日誌群組才是真正的費用槓桿。

Amazon CloudWatch Logs 訂閱篩選器

Amazon CloudWatch Logs 訂閱篩選器將 Amazon CloudWatch Logs 轉化為即時事件串流。

支援的目的地

訂閱篩選器比對日誌模式，並將符合的事件串流至以下其中一個目的地：

• AWS Lambda — 每批次日誌直接觸發呼叫。是日誌觸發警報與 ETL 的經典模式。
• Amazon Kinesis Data Streams — 高吞吐量串流，可接任意消費者（KCL、另一個 AWS Lambda、自訂應用程式）。
• Amazon Kinesis Data Firehose — 受管交付，目的地為 Amazon S3、Amazon Redshift、Amazon OpenSearch Service 或 Splunk。

每個日誌群組最多可同時設定 2 個訂閱篩選器。篩選器模式使用 Amazon CloudWatch Logs 篩選器模式語法——以空白分隔的 token、JSON 欄位比對語法如 { $.level = "ERROR" }，或正規表達式（新版篩選器語法）。

跨帳號訂閱

訂閱篩選器支援跨帳號目的地：來源帳號的日誌群組將事件串流至集中彙總帳號的 Amazon Kinesis 串流。這是企業級日誌管線的骨幹架構。

訂閱篩選器 vs 指標篩選器

這兩者常被混淆：

• 訂閱篩選器 = 即時串流至 AWS Lambda、Amazon Kinesis 或 Amazon Kinesis Data Firehose。事件內容流向下游。
• 指標篩選器 = 模式比對後將數值指標發布至 Amazon CloudWatch Metrics。事件內容不流出，只有計數或提取的數值。

Amazon CloudWatch Logs 指標篩選器

Amazon CloudWatch Logs 指標篩選器將日誌模式轉換為數值 Amazon CloudWatch 指標。

指標篩選器的運作方式

指標篩選器由三個部分組成：（1）比對日誌事件的篩選器模式、（2）指定命名空間、指標名稱、預設值及可選提取數值的指標轉換，以及（3）從解析日誌欄位填入的選用維度。

範例——每當 AWS Lambda 日誌出現 ERROR 時，向命名空間 MyApp 發布名為 ErrorCount 的指標：

Filter pattern: ERROR
Metric name:    ErrorCount
Namespace:      MyApp
Metric value:   1

提取數值欄位進行彙總——JSON 日誌 { "latency_ms": 234 }：

Filter pattern: { $.latency_ms = * }
Metric name:    ApiLatency
Namespace:      MyApp
Metric value:   $.latency_ms

指標篩選器免費（無額外擷取費用），並在擷取時即時評估，是「依錯誤數設定警報」模式的基礎。

指標篩選器限制

• 每個日誌群組最多 100 個指標篩選器。
• 提取值對 JSON 日誌使用 JSON path 語法（$.fieldName），對空白分隔日誌使用位置解析（[ip, user, timestamp]）。
• 指標篩選器不具回溯效力——只對建立後的新日誌事件生效。

CloudWatch Agent：EC2 與地端環境

AWS Lambda、Amazon API Gateway、Amazon DynamoDB 及大多數受管服務會自動將指標與日誌發布至 Amazon CloudWatch。Amazon EC2 與地端伺服器則不會——它們需要 CloudWatch Agent（前身為 Unified CloudWatch Agent）。

CloudWatch Agent 收集的訊號

CloudWatch Agent 傳送兩類訊號：

• 超管理程式層之外的系統指標：記憶體使用量、swap 使用量、磁碟檔案系統使用量、行程數、TCP 連線狀態。這些資訊無法從實例外部取得——EC2 超管理程式只能看到 CPU、網路與磁碟 I/O。
• 日誌：磁碟上的任何檔案（/var/log/nginx/access.log、Windows 事件日誌、IIS 日誌）都可串流至 Amazon CloudWatch Logs。

Agent 讀取一份 JSON 設定檔（通常由 AWS Systems Manager Parameter Store 或 SSM State Manager 管理），宣告要收集哪些指標與日誌。

地端環境支援

CloudWatch Agent 使用 IAM 使用者的存取金鑰或 IAM Roles Anywhere 設定檔，在地端伺服器上執行。同一個 Agent 二進位檔支援 Linux 與 Windows。這是混合架構在 Amazon CloudWatch 中統一可觀測性的做法。

記憶體與磁碟指標並非內建

DVA-C02 常被忽略的細節：Amazon EC2 的記憶體使用量與磁碟檔案系統使用量並非 Amazon CloudWatch 的內建指標。你必須安裝 CloudWatch Agent（或發布自訂指標）才能取得這些數據。EC2 的內建指標涵蓋 CPU、網路、磁碟 I/O（來自超管理程式）及狀態檢查——不包含記憶體，也不包含檔案系統使用量。

Embedded Metric Format（EMF）

Embedded Metric Format（EMF）是從 AWS Lambda 發布高基數自訂指標的現代慣用方式，不需要同步呼叫 PutMetricData，因此沒有額外延遲。

EMF 的運作原理

你發出一條符合 EMF schema 的結構化 JSON 日誌行——最上層的 _aws 區塊列出指標名稱、單位與維度，旁邊的屬性則承載數值與維度值。Amazon CloudWatch Logs 在擷取時自動解析符合 EMF 格式的事件，並將指標提取至 Amazon CloudWatch Metrics，完全不需要呼叫 PutMetricData API。

最簡 EMF 範例（Node.js AWS Lambda）：

{
  "_aws": {
    "Timestamp": 1713571200000,
    "CloudWatchMetrics": [{
      "Namespace": "MyApp",
      "Dimensions": [["Service", "Operation"]],
      "Metrics": [{ "Name": "Latency", "Unit": "Milliseconds" }]
    }]
  },
  "Service": "CheckoutService",
  "Operation": "CreateOrder",
  "Latency": 123,
  "RequestId": "abc-123",
  "UserId": "u-42"
}

擷取時會將 Latency = 123 解析為維度為 Service=CheckoutService, Operation=CreateOrder 的 Amazon CloudWatch 指標，而 RequestId 與 UserId 則留在日誌事件中作為可搜尋欄位——日誌側保持高基數，指標側維持安全基數。

EMF 對 AWS Lambda 的優勢

• 無同步 API 呼叫 — 寫入一條日誌行幾乎沒有成本，而 PutMetricData 會增加 10 至 50 毫秒的延遲，且按呼叫次數計費。
• 原子性 — 指標與日誌事件在同一行同時發出，不可能失去同步。
• 高基數安全 — UserId、RequestId、OrderId 保留在日誌中供除錯，只有低基數維度發布至 Amazon CloudWatch Metrics。
• 開箱即用 — AWS 提供 Node.js、Python、Java 與 .NET 的 aws-embedded-metrics 函式庫。

Amazon CloudWatch Logs Live Tail

Amazon CloudWatch Logs Live Tail 是針對即時系統除錯的互動式追蹤體驗。

Live Tail 的功能

Live Tail 即時串流新擷取的日誌事件，可跨越一個或多個日誌群組，並支援選用的篩選模式。它取代了舊有的「手動重新整理主控台」工作流程，讓即時除錯更順暢。Live Tail 非常適合用來確認部署是否寫入健康日誌、在監看 AWS Lambda 輸出的同時重現錯誤，或追蹤 Amazon EKS 叢集的控制面日誌。

Live Tail 限制與費用

• 每次 Live Tail 工作階段最長 3 小時，之後必須重新啟動。
• 依每分鐘、每個包含的日誌群組計費。
• 每個工作階段最多支援 10 個日誌群組（請確認目前限制）。
• 篩選模式必須符合 Amazon CloudWatch Logs 篩選器模式語法。

在 DVA-C02 中，將 Live Tail 定位為雲端版的「tail -f」，與歷史查詢的 Amazon CloudWatch Logs Insights 互補。

Amazon CloudWatch Metrics：命名空間與維度

Amazon CloudWatch Metrics 是以命名空間、指標名稱和一組維度作為索引的時間序列資料庫。

命名空間

命名空間是最上層的指標容器——AWS 服務發布至內建命名空間，例如 AWS/Lambda、AWS/EC2、AWS/DynamoDB、AWS/ApiGateway。你的自訂指標則放在自選的命名空間下（通常為 MyApp/Service）。命名空間不能以 AWS/ 開頭——該前綴為 AWS 服務保留。

維度

維度是用來限定指標範圍的名稱-值配對。AWS Lambda 的 Invocations 指標有 FunctionName 維度；DynamoDB 的 ConsumedReadCapacityUnits 有 TableName、GlobalSecondaryIndexName、Operation 等維度。無維度的指標與有維度的指標是不同的時間序列——Amazon CloudWatch 不會自動跨組合彙總無維度資料。

每個指標最多可附加 30 個維度。每個唯一的（命名空間＋指標名稱＋完整維度集合）都是一個獨立計費的自訂指標——維度的高基數是最容易讓 Amazon CloudWatch 帳單爆炸的方式。

標準解析度 vs 高解析度指標

Amazon CloudWatch 支援兩種解析度：

• 標準解析度 — 資料點粒度為 1 分鐘。這是 AWS 服務與以預設 StorageResolution=60 發布的自訂指標的預設值。
• 高解析度 — 資料點粒度為 1 秒。以 PutMetricData 中的 StorageResolution=1 發布。高解析度指標費用較高，且 1 秒粒度只保留 3 小時（之後彙總至 1 分鐘保留 15 天、5 分鐘保留 63 天、1 小時保留 15 個月）。

指標保留階梯

Amazon CloudWatch 以自動彙總方式共保留指標 15 個月：

• 1 秒資料（僅高解析度）：3 小時。
• 1 分鐘資料：15 天。
• 5 分鐘資料：63 天。
• 1 小時資料：15 個月。

超過 15 個月後，指標將自動捨棄。若需更長的保留期，請透過 AWS SDK 將指標匯出至 Amazon S3 或資料倉儲。

以 PutMetricData 發布自訂指標

發布自訂 Amazon CloudWatch 指標的傳統方式是使用 PutMetricData API。

API 結構

cloudwatch.put_metric_data(
    Namespace="MyApp",
    MetricData=[{
        "MetricName": "OrdersProcessed",
        "Dimensions": [{"Name": "Env", "Value": "prod"}],
        "Value": 1.0,
        "Unit": "Count",
        "StorageResolution": 60
    }]
)

PutMetricData 最佳實踐

• 每次呼叫最多批次 1,000 個資料點，以降低 API 開銷與費用。
• 設定正確的 Unit（Count、Seconds、Milliseconds、Bytes、Percent 等）——Amazon CloudWatch 的警報顯示會更準確，圖表也會對齊。
• 從 AWS Lambda 優先使用 EMF — PutMetricData 增加同步延遲且按呼叫次數計費；EMF 兩者皆避免。
• 切勿發布高基數維度 — 以 UserId 作為維度＝每位使用者各一個自訂指標＝帳單災難。請用 EMF 將這些屬性保留在日誌中，只發布彙總指標。

Amazon CloudWatch Alarms

Amazon CloudWatch Alarms 監看指標（或指標數學運算式），並在三種狀態之間轉換。

警報狀態

• OK — 最近的資料點在閾值之內。
• ALARM — 最近的資料點突破閾值。
• INSUFFICIENT_DATA — 資料點不足以判斷（新警報，或指標來源停止回報）。

你需要設定：指標＋統計值（Average、Sum、Maximum、Minimum、p99 等）＋週期（60 秒、300 秒……）＋評估週期數（考慮幾個週期）＋觸發警報所需的資料點數（這幾個週期中必須有幾個突破閾值）。範例：「CPU p95 在 5 個 1 分鐘評估週期中的 3 個超過 80%」可建立強健的警報，忽略單分鐘的偶發峰值。

缺失資料處理

TreatMissingData 參數決定間隔如何解讀——missing（忽略）、notBreaching（視為 OK）、breaching（視為 ALARM）或 ignore（狀態不變）。對於只在發生錯誤時才發布資料的稀疏指標（如錯誤計數），選擇方式至關重要。

警報動作

Amazon CloudWatch Alarms 可在狀態變化時觸發動作：

• Amazon SNS 主題 — 萬用扇出（電子郵件、簡訊、透過 AWS Chatbot 的 Slack、AWS Lambda、HTTPS webhook）。
• Auto Scaling 動作 — 擴展或縮減 Auto Scaling 群組。
• Amazon EC2 動作 — 停止、終止、重新啟動或復原承載指標的實例。
• AWS Systems Manager 動作 — 建立 Incident Manager 事件，或執行自動化文件。
• AWS Lambda 函數（透過較新的警報動作）— 觸發任意補救措施。

複合警報

複合警報以布林運算式結合多個子警報的狀態：

ALARM("HighCPU") AND (ALARM("HighErrorRate") OR ALARM("LowDisk"))

複合警報能抑制警報風暴——當上游故障時，下游警報連鎖觸發；複合條件捕捉真正的根因，對雜訊保持靜默。複合警報也支援 SuppressorAlarm（在維護視窗警報啟用期間遮蔽子警報）。

指標數學

Amazon CloudWatch 警報可評估指標數學運算式而非單一指標。用來計算錯誤數除以總呼叫數的錯誤率、跨維度加總指標，或套用異常偵測。

錯誤率警報範例——當 Errors / Invocations > 0.05 持續 5 分鐘時觸發：

m1 = Errors      (AWS/Lambda, FunctionName=CheckoutFn, Sum, 300s)
m2 = Invocations (AWS/Lambda, FunctionName=CheckoutFn, Sum, 300s)
e1 = m1 / m2
Alarm: e1 > 0.05 for 3 of 5 datapoints

異常偵測區間

Amazon CloudWatch 異常偵測在指標歷史上套用機器學習模型（季節性＋趨勢），發出預期值的區間。當指標離開區間時才觸發警報，而非依靜態閾值。異常偵測會自動處理每日與每週的季節性——非常適合靜態閾值難以設定的流量驅動指標。

Amazon CloudWatch Dashboards

Amazon CloudWatch Dashboards 是視覺化層——一張由指標、指標數學與 Logs Insights 查詢驅動的小工具畫布。

小工具類型

• 折線圖、堆疊面積圖、長條圖、數字 — 時間序列指標小工具。
• 文字（Markdown） — 操作手冊片段、聯絡資訊。
• 日誌表格 — 呈現 Amazon CloudWatch Logs Insights 查詢結果。
• 警報狀態 — 顯示目前的警報狀態。
• Explorer — 依標籤或資源群組自動分組的檢視。

每個小工具包含一個指標或指標數學運算式、一個時間範圍與一個統計值。儀表板可設定 10 秒、1 分鐘、2 分鐘、5 分鐘或 15 分鐘的自動重新整理間隔。

共享與跨帳號儀表板

• 可共享儀表板 — 產生公開 URL（以電子郵件連結、SSO 或 IP 允許清單保護），供外部讀者唯讀存取。
• 跨帳號儀表板 — 透過 AWS Organizations＋Amazon CloudWatch 跨帳號可觀測性功能，一個集中的監控帳號可在同一個儀表板上呈現多個來源帳號的指標與日誌。這是集中式平台工程可觀測性的基礎。

計費方式為固定費率：每個儀表板每月 $3.00（超過 3 個小工具時），前 3 個最多含 50 個指標的儀表板免費。

Amazon CloudWatch Synthetics Canaries

Amazon CloudWatch Synthetics canaries 是依排程執行的腳本，模擬使用者對你的端點的行為——這是可觀測性的合成監控面向。

Canary 藍圖

你可以選擇標準藍圖或撰寫自訂腳本：

• Heartbeat Monitor — 打一個 HTTPS URL 並確認 200 回應。
• API Canary — 依序呼叫 REST 並斷言回應主體與標頭。
• Broken Link Checker — 爬取頁面並確認每個連結可解析。
• Visual Monitor — 螢幕截圖與基準線比對。
• GUI Workflow — Puppeteer / Selenium 風格的腳本化使用者旅程（登入、加入購物車、結帳），使用 Amazon CloudWatch Synthetics Recorder 錄製。

Canaries 依排程執行（頻率運算式 rate(5 minutes)、cron 或 rate(1 minute) 的 1 分鐘頻率），並將指標（SuccessPercent、Duration、4xx、5xx）發布至命名空間 CloudWatchSynthetics，同時將螢幕截圖與 HAR 檔案存至 Amazon S3。

Canary 腳本底層是 AWS Lambda

Canary 以你不直接管理的 AWS Lambda 函數執行——Amazon CloudWatch Synthetics 為你打包 Node.js / Python＋Puppeteer / Selenium 執行環境。你提供腳本，Amazon CloudWatch 負責執行。

針對 Canary 指標設定警報

Canaries 最有價值的用法是搭配 Amazon CloudWatch Alarms，在 SuccessPercent < 100 時觸發——這能在中斷發生的瞬間就偵測到，早於任何真實使用者的投訴。Canaries 全天 24 小時運行，因此即使在凌晨 3 點沒有流量的時段，也能提供基準可用性訊號。

CloudWatch RUM：真實使用者的對應方案

Amazon CloudWatch RUM（Real User Monitoring）是瀏覽器端的真實使用者遙測，與 canaries 互補。你在 web 應用程式中嵌入 RUM JavaScript 片段；它將核心網頁指標（LCP、FID、CLS）、頁面載入時間、JavaScript 錯誤與使用者工作階段流程回報至 Amazon CloudWatch。RUM 與 Synthetics canaries 涵蓋「真實使用者 vs 合成使用者」的完整矩陣。

ServiceLens 與 Contributor Insights

兩個進階 Amazon CloudWatch 功能在 DVA-C02 中以配角身分出現。

ServiceLens

Amazon CloudWatch ServiceLens 將 AWS X-Ray 追蹤、Amazon CloudWatch Metrics、Amazon CloudWatch Logs 與 Synthetics canaries 整合在一個統一的服務地圖中。你可以看到每個節點的健康狀態（警報狀態）、指標（延遲、錯誤率）、追蹤（最慢的操作）與日誌（最近的錯誤），無需切換主控台。ServiceLens 是微服務架構根因分析的建議起點。

Contributor Insights

Amazon CloudWatch Contributor Insights 識別在一段時間內對指標貢獻最多的前 N 個來源——例如「哪 5 個 IP 位址向 ALB 發送了最多請求」、「哪 10 個 DynamoDB 分區鍵造成了最多節流」。你定義解析日誌欄位並依貢獻者索引鍵分組的規則。在 DynamoDB 節流場景中，Contributor Insights 是找出熱點鍵生產者的最快方式。

Amazon CloudWatch vs AWS CloudTrail vs AWS Config

DVA-C02 考試非常喜歡混淆這三者。請清楚區分其範疇：

• Amazon CloudWatch — 運營可觀測性。指標（數值時間序列）、日誌（應用程式或系統日誌事件）、警報、儀表板。回答「我的應用程式現在健康嗎？」
• AWS CloudTrail — AWS API 呼叫的稽核日誌。每一次對 AWS API 的呼叫——誰呼叫、何時、來自哪個 IP、哪個資源、什麼參數。回答「誰刪除了我的 S3 儲存貯體？」CloudTrail 事件可以交付至 Amazon CloudWatch Logs 以設定警報（例如針對 DeleteBucket 或根使用者登入發出警報）。
• AWS Config — 設定合規。隨時間快照每個資源的設定並評估規則。回答「我的資源是否符合政策，以及何時發生漂移？」

AWS CloudTrail＋Amazon CloudWatch Logs 是針對可疑 API 活動設定警報的慣用方式。AWS Config＋AWS Lambda 補救是自動修復合規漂移的慣用方式。Amazon CloudWatch 單獨負責應用程式層面的健康狀態。

Amazon CloudWatch 費用考量

Amazon CloudWatch 的計費方式常讓團隊在無聲中花費大量費用。DVA-C02 偶爾會問「降低 Amazon CloudWatch 帳單的最便宜方式」。

Amazon CloudWatch Logs 費用驅動因素

• 擷取 — 依擷取的 GB 計費（對於日誌量大的應用程式，這是主要費用）。
• 儲存 — 依每 GB 每月計費，加上預設的 Never Expire 保留期限複利計算。
• Logs Insights 查詢 — 依掃描 GB 計費。
• Live Tail — 依每分鐘每日誌群組計費。

最大節省空間：設定保留政策、在熱路徑降低日誌詳細程度、使用日誌等級、優先使用 EMF（一條結構化事件同時承載指標與可搜尋上下文），以及用指標篩選器計數取代下載日誌計數的工作流程。

Amazon CloudWatch Metrics 費用驅動因素

• 自訂指標 — 依每個唯一（命名空間＋指標名稱＋維度集合）每月計費。高基數維度倍增速度極快。
• PutMetricData API 呼叫 — 依每 1,000 次呼叫計費。每次最多批次 1,000 個資料點。
• 高解析度指標 — 費用高於標準解析度。只在真正需要 1 秒粒度時使用。
• GetMetricData / GetMetricStatistics API — 依查詢的指標數計費。

最大節省空間：避免以使用者、訂單或請求 ID 作為維度（改用 EMF 將其保留在日誌中）、批次 PutMetricData，以及預設使用標準解析度，除非需要次分鐘粒度。

Amazon CloudWatch Alarms 與 Dashboards 費用

• 標準警報 — 每個警報每月 $0.10。
• 高解析度警報 — 每個警報每月 $0.30。
• 複合警報 — 每個警報每月 $0.50。
• 異常偵測警報 — 每個警報每月 $0.30。
• 儀表板 — 每個儀表板每月 $3.00（前 3 個最多含 50 個指標的儀表板免費）。

讓警報保持聚焦並使用複合警報——一個向待命人員發送通知的複合父警報，比 20 個子警報各自通知更便宜、也更安靜。

Amazon CloudWatch 常見考試陷阱

了解陷阱所帶來的分數，與熟讀文件同等重要。

陷阱 1 — 訂閱篩選器 vs 指標篩選器

訂閱篩選器＝將事件串流至 AWS Lambda / Amazon Kinesis / Amazon Kinesis Data Firehose。指標篩選器＝向 Amazon CloudWatch Metrics 發布數值。依下游需要的是事件內容還是只需計數來選擇。

陷阱 2 — 預設日誌保留為永久

Amazon CloudWatch Logs 預設保留期為 Never Expire。請在 IaC 中明確設定 RetentionInDays 以控制儲存費用。

陷阱 3 — EC2 記憶體與磁碟非內建

Amazon EC2 的內建指標不包含記憶體與檔案系統使用量。請安裝 CloudWatch Agent；否則光靠內建指標無法解決考題的場景需求。

陷阱 4 — EMF vs 從 AWS Lambda 使用 PutMetricData

在 AWS Lambda 中，優先使用 EMF（結構化日誌→指標）而非 PutMetricData（同步 API 呼叫）。v2.1 強調項目。

陷阱 5 — CloudWatch vs CloudTrail vs Config

運營健康＝Amazon CloudWatch。API 稽核＝AWS CloudTrail。設定合規＝AWS Config。三個不同的問題，三個不同的服務。

陷阱 6 — 標準解析度 vs 高解析度指標

標準解析度＝1 分鐘（預設，較便宜）。高解析度＝1 秒（StorageResolution=1，費用較高，只在真正需要時使用）。

陷阱 7 — 警報評估週期 vs 資料點數

EvaluationPeriods = 5 且 DatapointsToAlarm = 3 表示「5 個週期中有 3 個突破閾值」，而非「連續 5 次突破」。這種 M of N 模型可避免警報來回切換。

陷阱 8 — Canary 警報目標

Synthetics canaries 發布至命名空間 CloudWatchSynthetics，指標為 SuccessPercent、Duration、4xx、5xx。針對 SuccessPercent < 100 設定警報，以獲得最快的中斷偵測。

陷阱 9 — 複合警報靜默

複合警報的 SuppressorAlarm 會在維護視窗期間靜默子警報的通知——不要手動停用警報來應對這個需求。

陷阱 10 — Logs Insights 查詢管線順序

fields → filter → parse → stats → sort → limit。parse 從文字中提取欄位；filter ispresent(name) 接著過濾掉不符合的列。

常見問題 — Amazon CloudWatch 可觀測性

Q1. 用一句話描述 Amazon CloudWatch 對 DVA-C02 的意義？

Amazon CloudWatch 是 AWS 託管的可觀測性服務，從 AWS 服務、應用程式與地端系統擷取指標、日誌與合成訊號；以可設定的保留期限儲存它們；並透過 Amazon CloudWatch Dashboards、Amazon CloudWatch Alarms、Amazon CloudWatch Logs Insights、Amazon CloudWatch Synthetics canaries 以及 Amazon CloudWatch API 對外提供服務。在 DVA-C02 中，Amazon CloudWatch 是所有「監控 / 警報 / 疑難排解」場景題的預設答案，也在幾乎所有其他領域擔任配角。

Q2. Amazon CloudWatch Logs 訂閱篩選器與指標篩選器有何不同？

訂閱篩選器以近即時方式將原始日誌事件串流至 AWS Lambda、Amazon Kinesis Data Streams 或 Amazon Kinesis Data Firehose——下游接收事件內容，可進行處理（ETL、警報、轉送至 OpenSearch）。指標篩選器比對日誌模式並發布數值 Amazon CloudWatch 指標（計數或提取的數值）；事件內容不流出。若題目問「將日誌轉送至下游」選訂閱篩選器；若問「關鍵字出現 N 次時觸發警報」選指標篩選器。

Q3. Embedded Metric Format 是什麼，為何 AWS Lambda 應該使用它？

Embedded Metric Format（EMF）是一種 JSON 日誌結構，最上層的 _aws 區塊宣告指標名稱與維度，旁邊的屬性承載數值。Amazon CloudWatch Logs 在擷取時解析 EMF，並自動在 Amazon CloudWatch Metrics 中建立指標——無需呼叫 PutMetricData API。AWS Lambda 應使用 EMF，因為：（a）避免同步 API 呼叫的 10 至 50 毫秒延遲、（b）將 UserId 和 RequestId 等高基數欄位保留在日誌中供除錯，同時只將低基數維度發布為指標，（c）AWS 提供的 aws-embedded-metrics 函式庫讓發出一行日誌就能完成所有工作。

Q4. 如何用 Amazon CloudWatch 監控 Amazon EC2 的記憶體與磁碟使用量？

Amazon EC2 的 Amazon CloudWatch 內建指標涵蓋 CPU、網路、磁碟 I/O（來自超管理程式）及狀態檢查——但不包含記憶體使用量，也不包含檔案系統使用量。若要監控這些，請在實例（或地端伺服器）上安裝 CloudWatch Agent，並使用 JSON 設定宣告要收集的指標（mem_used_percent、disk_used_percent）。Agent 將指標發布至命名空間（通常為 CWAgent），你可以像處理其他 Amazon CloudWatch 指標一樣設定警報。

Q5. Amazon CloudWatch、AWS CloudTrail 與 AWS Config 的差異是什麼？

Amazon CloudWatch 用於運營遙測——指標、日誌、警報、儀表板，回答「我的應用程式現在健康嗎？」AWS CloudTrail 是每一次 AWS API 呼叫的稽核日誌——誰呼叫、從哪裡呼叫、使用什麼參數——回答「誰刪除了我的儲存貯體？」AWS Config 記錄每個資源隨時間的設定，並評估合規規則——回答「我的資源是否仍然合規，以及何時發生漂移？」Amazon CloudWatch Logs 常作為 AWS CloudTrail 事件的下游目標，讓你能針對可疑 API 活動設定警報，但 API 稽核的真正資料來源是 AWS CloudTrail。

Q6. 複合警報與異常偵測如何減少假警報？

複合警報以布林運算式結合子警報狀態（例如 ALARM(HighCPU) AND ALARM(HighErrorRate)）——只有在你關心的共同發生條件成立時，複合警報才會觸發，從而抑制連鎖雜訊。異常偵測在指標歷史上套用季節性＋趨勢機器學習模型，並發出預期區間；你在指標離開區間時才觸發警報，而非依靜態閾值，因此正常的每日與每週模式不會引發假通知。將複合警報與異常偵測結合，並加入維護視窗的 SuppressorAlarm，即可實現靜默且聰明的告警機制。

Q7. Amazon CloudWatch Logs Insights 是什麼，其查詢管線是什麼樣子？

Amazon CloudWatch Logs Insights 是 Amazon CloudWatch Logs 的互動式類 SQL 查詢引擎。標準管線為 fields → filter → parse → stats → sort → limit。fields 選擇欄位、filter 縮小列的範圍、parse 以 glob 或正規表達式從非結構化文字提取欄位、stats 彙總（例如 stats avg(duration) by functionName）、sort 排序，limit 限制列數。Amazon CloudWatch Logs Insights 自動預先解析 JSON 日誌欄位，並提供 AWS Lambda 專屬欄位，如 @requestId、@duration、@billedDuration、@memorySize、@maxMemoryUsed 與 @initDuration。查詢依掃描的資料量（GB）計費。

Q8. Amazon CloudWatch Synthetics canaries 是什麼，與 Amazon CloudWatch RUM 有何不同？

Amazon CloudWatch Synthetics canaries 是依排程執行的腳本（Node.js / Python 搭配 Puppeteer 或 Selenium），模擬使用者對你的端點的行為——心跳檢查、API 序列、GUI 工作流程、視覺回歸。它們發布指標（SuccessPercent、Duration、4xx、5xx）與螢幕截圖，並在 SuccessPercent < 100 時觸發警報，即使沒有真實使用者也能偵測中斷。Amazon CloudWatch RUM 是瀏覽器端的 JavaScript 片段，捕捉真實使用者行為——核心網頁指標、頁面載入時間、JavaScript 錯誤——提供生產環境中的使用者體驗資料。使用 canaries 達成可用性 SLO，使用 RUM 達成真實使用者效能 SLO。

Q9. 什麼決定 Amazon CloudWatch Logs 的費用，如何降低它？

Amazon CloudWatch Logs 費用有三個主要驅動因素：擷取（每 GB）、儲存（每 GB 每月，預設永不過期保留期限）以及 Logs Insights 查詢（每掃描 GB）。最大節省空間：設定保留政策（預設為永久）、在熱路徑降低日誌詳細程度、使用日誌等級、優先使用 Embedded Metric Format（一條結構化事件承載指標＋可搜尋上下文）、以指標篩選器取代下載日誌計數的工作流程，以及在每次查詢前縮小 Logs Insights 的時間範圍與日誌群組範圍以減少掃描位元組數。

Q10. DVA-C02 必背的 Amazon CloudWatch 限制數字有哪些？

必記：指標保留期 15 個月，自動彙總（1 秒→3 小時、1 分鐘→15 天、5 分鐘→63 天、1 小時→15 個月）；每個指標最多 30 個維度；每個日誌群組最多 2 個訂閱篩選器；每個日誌群組最多 100 個指標篩選器；PutMetricData 每次最多批次 1,000 個資料點；標準警報每月 $0.10、複合警報 $0.50、異常偵測警報 $0.30；Amazon CloudWatch Dashboards 超過免費方案後固定 $3.00 /儀表板/月；Logs Insights 依掃描 GB 計費；日誌保留值從 1 天至 10 年或永不過期。這些數字能回答 DVA-C02 上大多數需要直接記憶的 Amazon CloudWatch 考題。

摘要 — Amazon CloudWatch 可觀測性一覽

• Amazon CloudWatch 是 DVA-C02 的核心可觀測性服務，直接對應任務 4.2，並在所有其他領域擔任配角。
• 三大基本元件：指標（時間序列，保留 15 個月並彙總）、日誌（日誌群組與串流，保留期可設定，預設永不過期），以及警報（OK / ALARM / INSUFFICIENT_DATA 狀態機）。
• Amazon CloudWatch Logs Insights 查詢管線：fields → filter → parse → stats → sort → limit；AWS Lambda 的保留欄位：@timestamp、@message、@requestId、@duration、@initDuration。
• 訂閱篩選器將日誌事件串流至 AWS Lambda、Amazon Kinesis Data Streams 或 Amazon Kinesis Data Firehose（每個日誌群組 2 個）。指標篩選器從日誌模式發布數值指標（每個日誌群組 100 個）。
• CloudWatch Agent 是從 Amazon EC2 與地端伺服器收集記憶體、磁碟檔案系統及自訂日誌的必要工具——這些非內建指標。
• Embedded Metric Format 發出結構化 JSON 日誌，自動轉換為 Amazon CloudWatch 指標——v2.1 強調項目，是 AWS Lambda 中優於 PutMetricData 的首選模式。
• Amazon CloudWatch Logs Live Tail 是即時追蹤體驗；Amazon CloudWatch Logs Insights 是歷史查詢的類 SQL 引擎。
• 指標分為標準解析度（1 分鐘，預設）與高解析度（1 秒，費用較高，1 秒保留 3 小時）。
• PutMetricData 支援每次最多批次 1,000 個資料點；避免高基數維度——它們會讓帳單爆炸。
• 警報支援指標數學（衍生指標如錯誤率＝錯誤數 / 呼叫數）、複合警報（帶靜默器的布林組合），以及用於季節性指標的異常偵測區間。
• 警報動作：Amazon SNS、Auto Scaling、Amazon EC2 停止 / 終止 / 重啟 / 復原、AWS Systems Manager 自動化、AWS Lambda。
• 儀表板透過 AWS Organizations＋Amazon CloudWatch 跨帳號可觀測性支援跨帳號呈現，並可以公開或 IP 限制的 URL 共享。
• Synthetics canaries 是依排程執行的 AWS Lambda 腳本（Puppeteer / Selenium），模擬使用者行為；針對 SuccessPercent < 100 設定警報。Amazon CloudWatch RUM 捕捉包含核心網頁指標在內的真實使用者瀏覽器遙測。
• ServiceLens 在一個服務地圖上統一 X-Ray 追蹤、Amazon CloudWatch Metrics、Amazon CloudWatch Logs 與 Synthetics；Contributor Insights 找出對指標貢獻最多的前 N 個來源（熱點分區鍵、高流量 IP）。
• Amazon CloudWatch（運營健康）vs AWS CloudTrail（API 稽核）vs AWS Config（設定合規）——三個截然不同的範疇，考試最愛出題。
• 費用控制：設定日誌保留期、優先使用 EMF 而非 PutMetricData、避免高基數維度、批次寫入指標、預設使用標準解析度，並以複合警報整合通知。