Amazon SOA-C02: 監控、日誌記錄與修復 — 學習指南
屬於 AWS SysOps Administrator Associate SOA-C02 — 學習指南. 使用經過驗證的解答練習： Amazon 考試中心, 或參加限時模擬考試： ExamRoll.io.
監控、日誌記錄與修復為 AWS 環境提供了營運的神經系統：它們偵測問題、提供上下文，並驅動修正措施。本領域涵蓋了建立有意義的指標和儀表板、以符合成本效益的方式收集和保留日誌、建立可追蹤的應用程式可觀測性，以及自動化告警和修復。良好的實作能在信噪比之間取得平衡、控制成本，並確保操作手冊與自動化都經過測試且可供稽核。
CloudWatch 指標、儀表板與告警
圍繞業務和營運的 SLI (服務等級指標) 來設計指標 (例如延遲、錯誤率、佇列深度、基礎設施的 CPU/記憶體)。使用內建指標 (EC2、RDS、ELB) 並透過 PutMetricData 建立自訂指標，用於應用程式層級的計數器 (
undefined
)。優先選用能進行篩選的維度 (InstanceId、ServiceName)，並避免使用會導致指標成本暴增的高基數維度。
使用 CloudWatch 儀表板將指標、日誌和告警結合成營運視圖。在主控台或透過 CloudFormation (AWS::CloudWatch::Dashboard) 建立小工具，並使用指標數學運算 (metric math) 來產生衍生指標：利用指標數學運算計算錯誤率 (ERRORS/SUM(REQUESTS)) 並顯示百分位數 (p50、p90、p99)。對於告警，根據意圖選擇設定模式：
- 單一指標告警，用於簡單的閾值：
undefined
- 複合告警，透過結合多個告警的條件 (AND/OR) 來減少雜訊。
- 異常偵測，用來自動調整閾值：在具有預期季節性行為的指標上使用 CloudWatch 異常偵測。
決策標準：使用評估期間和資料點觸發告警的設定來避免告警抖動；觸發 SNS、Auto Scaling 或 Systems Manager Automation 作為告警動作。對於具有變動基準線的環境，優先選擇複合告警和異常偵測。
CloudWatch Logs、Logs Insights 與保留策略
使用 CloudWatch Logs 群組來彙總日誌，並按應用程式和環境進行結構化。透過 CLI 建立日誌群組：
undefined
，並使用
undefined
來強制執行保留策略。使用訂閱篩選器將日誌串流至 Kinesis Data Firehose (用於 S3/Redshift)、Lambda (即時處理) 或合作夥伴工具；在 S3 中壓縮和分區以降低儲存成本。
使用 CloudWatch Logs Insights 進行臨時查詢和建立儀表板；建立可提取追蹤 ID 和錯誤上下文的已儲存查詢 (例如：
undefined
)。保留與擷取成本的控制實務：
- 根據合規性和故障排除需求，為每個日誌群組設定適當的保留天數 (7/30/90/365 天)。
- 透過保留生命週期或 Firehose 將較舊的日誌匯出到 S3，並搭配壓縮和生命週期規則移至 Glacier/Archive。
- 使用取樣或結構化日誌 (JSON) 以及嵌入式指標格式 (Embedded Metric Format, EMF) 來減少昂貴的高基數日誌，同時仍能從中衍生指標。
決策標準：對詳細的偵錯日誌設定較短的保留期，對稽核/安全日誌設定較長的保留期；將大量日誌路由到 S3，而不是在 CloudWatch 中無限期保留。
CloudTrail、稽核軌跡與事件歷史
在所有區域和帳戶中啟用 CloudTrail；建立一個組織追蹤 (organization trail)，將稽核日誌集中記錄到一個安全的 S3 儲存貯體，並啟用日誌檔案驗證和 SSE-KMS 加密。設定管理事件 (讀取/寫入)，並在需要詳細稽核的地方選擇性地啟用資料事件 (S3 物件層級、Lambda 函數調用)，因為資料事件的量較大且成本較高。
使用主控台中的 CloudTrail 事件歷史進行 90 天內的快速搜尋，並使用 CloudTrail Lake 或在匯出的 S3 日誌上執行 Athena 進行長期分析和調查。透過以下方式保護追蹤：
- 強制執行多區域追蹤以捕獲全球服務事件。
- 將 CloudTrail 與 CloudWatch Logs 整合以進行近乎即時的偵測，或與 EventBridge 整合以將特定事件路由到 Lambda/Systems Manager 進行自動化修復。
- 套用 S3 儲存貯體政策和 S3 物件鎖定 (S3 Object Lock) (若有需要) 以防止竄改。
決策標準：僅在需要鑑識可見性的儲存貯體/函數上啟用資料事件；使用集中式追蹤和跨帳戶存取模式來簡化合規性。
應用程式追蹤與可觀測性 (X-Ray)
使用 AWS X-Ray SDK 來檢測應用程式，以發送區段 (segment) 和子區段 (subsegment)。對於未經檢測的執行環境，以 sidecar 或服務 (ECS 任務、EC2 daemon 或 Lambda 內建追蹤) 的形式執行 X-Ray daemon/agent。設定取樣規則以控制追蹤量，並在 ServiceLens 中設定服務地圖 (service map) 以視覺化服務之間的依賴關係。用業務關鍵字 (例如 userId、orderId) 來註釋追蹤，並記錄例外/元數據以協助分類問題。
透過在應用程式日誌中包含 X-Ray 追蹤 ID 來關聯追蹤與日誌 (使用追蹤標頭或 SDK 取得當前的追蹤 ID)，以便 CloudWatch Logs Insights 查詢可以連接日誌和追蹤。對於 Lambda，啟用主動追蹤 (在主控台或使用
undefined
) 以自動將追蹤發送到 X-Ray。使用追蹤分析來偵測長尾延遲、熱點和資料庫呼叫的細部分析。
決策標準：為關鍵服務啟用追蹤，並使用自適應取樣來限制成本；優先使用結構化追蹤 (註釋/元數據)，以讓日誌與追蹤的關聯變得確定性。
自動化修復與警示 (EventBridge/Lambda)
使用 EventBridge 規則來匹配 CloudWatch Alarm 狀態變更、CloudTrail 事件或自訂事件，並將它們路由到 Lambda、Systems Manager Automation 文件、Step Functions 或 SNS 等目標。建立帶有輸入轉換器 (input transformers) 的規則，以將最精簡的上下文傳遞給修復動作 (
undefined
)。實作 Lambda 函式以進行輕量級修復 (例如重啟服務、撤銷憑證)，但對於具備檢查點、可稽核的長時間執行劇本 (playbook)，則應使用 SSM Automation 或 Step Functions。
設計修復措施時應考量安全性：包含試運轉模式 (dry-run mode)、冪等性、驗證步驟、IAM 最小權限、日誌記錄以及緊急停止開關 (kill-switch)。在 EventBridge/Lambda 整合中使用無法處理佇列 (dead-letter queue) 和重試策略，並將修復嘗試發佈到稽核日誌或安全軌跡中。在預備 (staging) 帳戶中測試自動化，並在部署後執行金絲雀測試 (canary test)。
決策標準：對於多步驟恢復和需要人工批准的場景，優先選擇 SSM Automation 或 Step Functions；對於簡單、快速的修復，則使用 Lambda。對於有風險的操作，務必包含手動回滾或人工介入的中斷點。
常見陷阱與決策標準
- 依賴單一指標做健康狀態決策：結合多個指標 (例如，錯誤率 + 延遲 + 節流) 或使用複合警示/指標數學來避免誤報。
- 未考慮日誌保留與擷取成本：設定每個日誌群組的保留期限，透過 Firehose 將大量日誌以壓縮格式路由到 S3，並使用生命週期政策將舊資料移至更便宜的儲存層。
- 使用高基數維度或禁用追蹤取樣導致過度檢測：限制維度並啟用自適應取樣，以在保留訊號的同時控制成本。
- 未經測試即部署自動化修復：在投入生產環境前，應在預備環境中驗證、使用試運轉旗標，並確保冪等性與安全的回滾機制。
- 因過多雜訊警示導致警示疲勞：使用異常偵測、複合警示、抑制視窗，並且只將有意義的事件上報給輪班人員。
- 缺乏日誌、指標與追蹤之間的關聯性：將追蹤 ID 傳播到日誌和 EMF 指標中，並建立已儲存的 Logs Insights 查詢和 ServiceLens 視圖，以將資料串連起來。
實務問題：使用案例情境
Acme Payments 在流量高峰期間遇到間歇性的支付處理失敗；工程師觀察到延遲增加和零星的 5xx 錯誤，但自動重啟有時反而掩蓋了根本原因。
- 使用 X-Ray SDK 和 EMF 指標來檢測支付服務；將追蹤 ID 加入應用程式日誌，並透過 PutMetricData/EMF 發送 OrdersFailed 和 OrdersProcessed 的結構化指標。
- 建立 CloudWatch 指標數學來計算錯誤率 (OrdersFailed / OrdersProcessed)，並建立一個複合警示，結合「錯誤率 > 閾值」和「p99 延遲 > 閾值」兩個條件。
- 將警示動作路由到一個 EventBridge 規則，該規則會觸發一個 Step Functions 工作流程以執行診斷步驟 (收集近期的追蹤/日誌、執行健康檢查)，並在安全的情況下，透過 SSM Automation 進行自動重啟。
- 設定 CloudTrail 和 CloudWatch Logs 訂閱，將完整日誌以壓縮格式封存到 S3，並透過生命週期政策移至 Glacier，同時在 CloudWatch 中為詳細的偵錯日誌設定較短的保留期。
- 在生產環境中啟用自動修復之前，執行端對端測試和金絲雀綜合交易 (透過 CloudWatch Synthetics) 來驗證可觀測性與修復流程。
基本原理：關聯指標、日誌與追蹤以找出根本原因，而非反覆處理表象症狀；結合多個警示以減少雜訊，並使用可稽核、經過測試的自動化 (Step Functions/SSM) 進行安全修復，同時控制日誌儲存成本。
所有領域 · 高可用性、容錯與災難復原 →
練習這些題目 → · 在 ExamRoll.io 上限時練習 →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
通過考試 →