Amazon DOP-C02: 監控、日誌記錄與可觀測性 — 學習指南

By Laurynas Brazys · 4 August 2026 · #amazon #dop-c02 #certification #exam-prep #study-guide

屬於 AWS DevOps Engineer Professional DOP-C02 — 學習指南. 使用經過驗證的解答練習： Amazon 考試中心, 或參加限時模擬考試： ExamRoll.io.

總覽

在 AWS 上的監控、日誌記錄與可觀測性，需要將指標、日誌、追蹤、事件和健康遙測資料結合成可據以行動的信號。有效的架構會使用 Amazon CloudWatch 處理指標、警報和儀表板；使用 CloudWatch Logs 和 Logs Insights 進行日誌擷取和分析；使用 AWS X-Ray 進行分散式追蹤；使用 AWS CloudTrail 進行稽核和完整性檢查；使用 Amazon EventBridge 進行事件驅動的偵測和自動化；使用 AWS Health 處理特定於帳戶的服務事件；並使用集中式管道 (Kinesis Data Firehose 和 OpenSearch) 進行大規模的搜尋和關聯分析。以下模式強調減少雜訊、精確的信號路由、自動化以及多帳戶/多區域的操作。

CloudWatch 指標、警報、儀表板與複合警報

CloudWatch 指標是 SLO、擴展和警示的基礎。發佈具有細粒度維度的自訂指標以隔離信號（例如：apiOperation、appVersion、statusCode）。使用 CloudWatch 嵌入式指標格式 (EMF) 搭配結構化日誌，從 Lambda、容器和 EC2 高效率地發出高基數維度，以避免 PutMetricData API 的額外開銷。

設定具有穩健評估機制的警報：

• 選擇與資料粒度和 SLO 視窗一致的期間。
• 設定 datapointsToAlarm (n 個資料點中有 m 個) 以抵禦暫時性的雜訊。
• 使用 TreatMissingData 以避免在部署或暫停期間產生誤報。
• 當基線因季節性而變化時，利用異常偵測帶；並使用指標數學計算衍生指標（p95 延遲、錯誤百分比、飽和度比率）。
• 將動作附加到警報：透過 SNS 通知、建立 OpsCenter OpsItems、執行 SSM Automation 或復原 EC2 執行個體。擴展政策可以參考警報狀態來採取行動，但複合警報無法直接觸發擴展。

複合警報透過 AND/OR 邏輯結合多個底層警報，以減少警報疲勞。例如，僅在 p95 延遲過高、5xx 錯誤率超過閾值且 CPU 飽和度持續存在時才發出警報，從而與使用者受到的影響保持一致。複合警報可透過跨帳戶可觀測性或將指標串流至中央帳戶的方式，接受來自跨區域/跨帳戶的子警報的狀態更新。

儀表板將跨服務的關鍵指標視覺化。使用小工具來顯示指標、Logs Insights 查詢結果和警報狀態。標準化儀表板的慣例（命名、時間範圍、SLO 覆蓋層），並利用 CloudWatch Observability Access Manager (OAM) 實現跨區域/跨帳戶的檢視。為了進行臨時性的關聯分析，可將 Logs Insights 和 X-Ray ServiceLens 小工具與服務地圖小工具及 Kinesis Firehose 錯誤率並排釘選。

CloudWatch Logs：日誌群組、指標篩選器、訂閱篩選器與 Logs Insights

根據應用程式/元件和生命週期階段來組織日誌群組。設定明確的保留政策（不要依賴「永不過期」），並在需要時啟用 KMS 加密。使用資源政策和細粒度的 IAM 來控制生產者和訂閱者。對於高吞吐量的擷取，請確保足夠的日誌串流並行性和批次處理。

指標篩選器將日誌模式轉換為指標。定義一個帶有提取權杖（JSON 或以空格分隔）的篩選模式，並將權杖對應到指標維度。這支援了像是直接從日誌發佈每個 API、每個版本、每個回應碼的指標，而無需修改生產者的使用案例。確保單位和預設值正確；偏好每個事件為 1，並透過指標數學推導出速率。使用這些指標進行 SLO 警示和儀表板製作。

訂閱篩選器將日誌近乎即時地串流至：

• Kinesis Data Firehose，用於轉換並交付至 S3/OpenSearch。
• Kinesis Data Streams，用於自訂消費者。
• Lambda，用於自訂路由、PII 編輯或事件驅動的通知。 使用帶有 IAM 角色的 CloudWatch Logs destination 來進行跨帳戶訂閱。規劃重試和背壓機制；Lambda 和 Firehose 分別提供內建的重試和 DLQ/錯誤 S3 儲存貯體。

CloudWatch Logs Insights 提供對日誌的互動式、無伺服器查詢。核心運算子包括 fields、filter、parse、stats、sort、limit、dedup 和用於時間分桶的 bin。剖析 JSON 欄位或對文字日誌使用類 grok 的剖析方式。範例：

• filter status >= 500 | stats count() by apiOperation, appVersion
• parse @message /duration=(?\d+)/ | stats pct(@ms,95) by service 使用 QueryDefinition 儲存常用查詢以供團隊重複使用，並將它們作為查詢小工具嵌入儀表板中。為了自動化，可透過 EventBridge 排程一個 Lambda 來執行 StartQuery/GetQueryResults，並將摘要發佈到 SNS 或 OpsCenter。將查詢範圍限制在特定的日誌群組和時間視窗內以控制成本。

AWS X-Ray：追蹤、取樣規則、服務地圖與註釋

X-Ray 擷取跨服務的分散式追蹤，以找出延遲的來源與故障邊界。使用 AWS Distro for OpenTelemetry (ADOT) 或 X-Ray SDK 來檢測 (instrument) 服務，傳遞追蹤標頭 (例如 X-Amzn-Trace-Id)，並在需要的地方 (ECS/EKS/EC2) 執行 X-Ray daemon/agent。許多託管服務皆原生整合 (例如 API Gateway、ALB 透過存取日誌代理追蹤、啟用主動追蹤的 Lambda、Step Functions 透過 subsegments)。

取樣規則控制資料量與訊號的保真度。使用一組中央取樣規則，並包含：

• 每秒固定儲備量 (reservoir)，用於每個服務的基準追蹤。
• 基於比率的取樣百分比，以便隨吞吐量擴展。
• 規則優先級與服務/URL 匹配，用於熱門路徑和錯誤情境。 在事件期間和針對金絲雀流量增加取樣，以在管理成本的同時確保可觀測性。

服務地圖將呼叫圖視覺化，顯示包含延遲、錯誤率和調節指標的邊緣 (edge)。深入鑽研追蹤以檢查 segment 和 subsegment，從而了解下游相依性。使用註釋 (annotations) (已索引的鍵值對) 進行高基數 (high-cardinality) 過濾，例如 customerTier、apiOperation、appVersion 或 AWS 請求 ID。使用元資料 (metadata) 來儲存詳細、未索引的上下文，以避免索引過度膨脹。將 X-Ray 追蹤群組與 CloudWatch ServiceLens 結合，以便在單一視圖中關聯日誌、指標和追蹤。建立過濾表達式 (例如，annotation.appVersion = “2.3.1” and fault = true) 來隔離迴歸問題，並匯出追蹤 ID 以進行針對性的日誌搜尋。

治理與事件：CloudTrail、EventBridge 與 AWS Health

CloudTrail 記錄 API 活動以進行治理和鑑識分析。啟用一個橫跨所有帳戶和所有區域的組織追蹤 (organization trail)，將日誌交付到一個使用 SSE-KMS 的集中式 S3 儲存貯體，啟用日誌檔案驗證，並與 CloudWatch Logs 整合以進行近乎即時的偵測。區分事件類別：

• 管理事件：控制平面 (control plane) (例如 CreateUser、RunInstances)。根據需要設定以包含唯讀和唯寫事件。
• 資料事件：高流量的資料平面 (data plane) 操作，例如 S3 物件層級存取、Lambda Invoke、DynamoDB 項目 API、EKS API 伺服器呼叫。選擇性地限定資料事件的範圍 (依儲存貯體/函數/資料表) 以控制成本。 使用 CloudTrail Insights 偵測異常的 API 突增，並將 CloudTrail 事件饋送至 EventBridge 以進行自動修復。在稽核期間，使用摘要檔案 (digest files) 和 AWS CLI 的 cloudtrail validate-logs 命令來驗證日誌的完整性。

EventBridge 提供一個事件結構 (event fabric) 用於偵測和自動化。使用預設事件匯流排 (event bus) 處理 AWS 服務事件，並為應用程式領域的事件建立自訂匯流排。定義事件模式 (event pattern) 以匹配來源 (source)、詳細類型 (detail-type)、詳細資訊欄位 (detail fields)、前綴、數值範圍和「anything-but」條件。應用輸入轉換器 (input transformers) 來重塑事件，附加基於資源的政策以進行跨帳戶發布，並在目標上設定重試/DLQ。常見的目標包括 Lambda (修復)、Step Functions (協調)、SQS (解耦)、Systems Manager Automation (維運操作)、CodePipeline (CI 觸發器) 和 SNS (通知)。封存和重播事件以從消費者中斷中恢復，並使用結構描述登錄 (schema registry) 來產生強型別的事件模型。

AWS Health 呈現帳戶特定的服務事件、排程變更和營運問題。透過 EventBridge 與來源為 aws.health 和詳細類型為 AWS Health Event 的事件整合，以路由到事件應變頻道、開啟 OpsCenter OpsItems，或在維護時段觸發安全的關機/擴展操作。使用組織檢視 (Organizational View) 搭配委派管理員帳戶，以匯總所有帳戶的 Health 事件，並考慮使用 AWS Health API 或 AWS Health Aware 解決方案，將整理過的通知推送到待命 (on-call) 系統。

使用 Kinesis Data Firehose 與 OpenSearch 進行集中式日誌記錄

一個多帳戶、多區域的日誌記錄策略，能將日誌的擷取與搜尋標準化。在每個生產者帳戶中，設定 CloudWatch Logs 訂閱篩選器，將日誌傳送到由中央 Kinesis Data Firehose 支援的跨帳戶日誌目的地。啟用 Firehose 的功能：

• 透過 Lambda 進行資料轉換，以進行正規化 (JSON)、PII (個人可識別資訊) 遮蔽，並用 AWS 帳戶、區域、VPC 和服務中繼資料來豐富內容。
• 傳送到 S3 時進行壓縮 (GZIP) 和動態分割，以優化在 Athena 中的查詢效能。
• 使用 KMS 進行加密，並透過 VPC 傳送至私有端點。 將資料傳送到 Amazon OpenSearch Service 以進行低延遲搜尋和 Kibana/OpenSearch Dashboards 視覺化。使用索引範本、用於輪替和保留的 ILM/ISM 政策，以及將使用者對應到索引模式 (例如：帳戶/團隊/服務) 的精細存取政策。為失敗的文件設定錯誤輸出到 S3，並監控 Firehose 的傳送和 OpenSearch 的擷取指標 (DeliveryToElasticsearch.Success, ElasticsearchFailedRequests)。對於非常高的流量，可考慮透過 Firehose 將所有日誌存放在 S3，並將一個子集串流到 OpenSearch，同時對 S3 上的資料進行隨選的 Athena 查詢，以進行長尾調查來控制成本。

將此管道與 CloudWatch 指標篩選器結合，以實現快速、低成本的計數器，並與 Logs Insights 結合，以進行臨機的深度查詢。使用由 Firehose/OpenSearch 異常或 CloudWatch 警報觸發的 EventBridge 規則，來啟動修復措施或引發事件。

實務問題情境

Airbnb 在部署於 EKS 和 Lambda 上的微服務中，經歷了間歇性的 API 錯誤和延遲高峰，且有多個行動應用程式版本在線上運行。維運團隊需要近乎即時地按 API 操作、回應碼和應用程式版本進行偵測；跨追蹤和日誌進行快速的根本原因分析；對已知的故障模式進行自動化修復；以及符合治理等級的稽核軌跡。

1. 標準化結構化日誌記錄

• 在服務 (EKS, Lambda) 中實作 EMF 結構的 JSON 日誌，包含

undefined

、

undefined

、

undefined

、

undefined

和

undefined

等欄位。

• 原因：EMF 能夠以低開銷在 CloudWatch 中直接提取指標，並提供高基數維度以實現精確的警報。

2. 建立 CloudWatch Logs 指標篩選器

• 為每個服務日誌群組定義指標篩選器，按

undefined

、

undefined

和

undefined

來遞增計數器。

• 原因：無需額外的程式碼路徑即可產生每個維度的指標，從而能夠為每個 API 和客戶端版本建立儀表板和可操作的警報。

3. 建立分層的 CloudWatch 警報和一個複合警報

• 針對 p95 延遲、5xx 錯誤率和飽和度 (CPU、記憶體、並行/節流) 設定警報。建立一個複合警報：連續 3 個週期中有 2 個週期出現 LatencyHigh AND ErrorsHigh。
• 原因：減少雜訊，專注於影響使用者的事件。

4. 部署具有目標取樣的 X-Ray 追蹤

• 在 EKS 上使用 ADOT 收集器，並為 Lambda 啟用主動追蹤。定義取樣規則以捕獲所有錯誤追蹤和具代表性的成功呼叫樣本，並對新的應用程式版本進行更高的取樣率。
• 原因：保證對故障的可見性，並為效能熱點提供足夠的覆蓋範圍，同時控制成本。

5. 與 ServiceLens 和 Logs Insights 進行關聯

• 建立結合了指標小工具、X-Ray 服務地圖和 Logs Insights 查詢 (例如，

undefined

) 的儀表板。

• 原因：單一窗格的關聯性可加速診斷哪個操作和客戶端版本出現了退化。

6. 透過 Firehose 將日誌集中到 OpenSearch 和 S3

• 設定訂閱篩選器到一個中央 Firehose，並使用 Lambda 轉換來進行正規化、遮蔽 PII，並用帳戶/區域資訊豐富內容。傳送到 OpenSearch 進行 7 天的熱查詢，並傳送到 S3 進行持久保留和 Athena 查詢。
• 原因：對當前問題進行快速的跨團隊搜尋，並以低成本進行歷史分析。

7. 使用 EventBridge 自動化偵測和修復

• 為 CloudWatch 警報狀態變更和選定的 CloudTrail 寫入 API 事件 (例如：安全群組修改) 建立 EventBridge 規則。目標：使用 Lambda 進行安全回滾 (例如：還原功能旗標)，並使用 Step Functions 進行多步驟修復。
• 原因：事件驅動的控制迴圈縮短了 MTTR (平均修復時間) 並強制執行了防護措施。

8. 整合 AWS Health 和維護處理

• 為影響 EC2、EKS 或網路的

undefined

事件新增 EventBridge 規則。目標設定為 SSM Automation，以封鎖/排空節點或轉移流量。

• 原因：主動緩解排程或營運問題可減少停機時間。

9. 透過 CloudTrail org trail 和完整性來強化治理

• 啟用一個組織性的、多區域的 trail，包含 S3 和 Lambda 的資料事件、SSE-KMS 加密和日誌檔案驗證。串流到 CloudWatch Logs 和 OpenSearch 以進行異常偵測和調查。
• 原因：完整、防篡改的稽核符合合規性要求並加速 RCA (根本原因分析)。

10. 通知和維運整合

• 將關鍵事件路由到 SNS 和 on-call 系統，開啟附有 runbook 的 OpsCenter OpsItems，並附加警報標籤以標示所有權和嚴重性。
• 原因：明確的所有權和自動化的 runbook 提高了回應的品質和速度。

選擇此設計是為了結合低延遲、維度豐富的指標 (CloudWatch + EMF)、深度的追蹤關聯 (X-Ray + ServiceLens)、大規模搜尋 (OpenSearch + S3/Athena)、事件驅動的修復 (EventBridge + Lambda/SSM/Step Functions) 以及可稽核的治理 (具有完整性驗證的 CloudTrail)。它透過取樣、保留分層以及反映真實使用者影響的目標式警報，在成本和保真度之間取得了平衡。

← 基礎設施即程式碼與組態管理 · 所有領域 · 安全、合規性與治理 →

練習這些題目 → · 在 ExamRoll.io 上限時練習 →

瀏覽 Amazon →