Google ACE: 監控、日誌記錄與維運疑難排解 — 學習指南

By Laurynas Brazys · 31 August 2026 · #google #ACE #certification #exam-prep #study-guide

屬於 Google Associate Cloud Engineer — 學習指南. 使用經過驗證的解答練習： Google 考試中心, 或參加限時模擬考試： ExamRoll.io.

總覽

在 Google Cloud 上實現卓越營運的關鍵，在於將遙測資料（telemetry）轉化為具體行動。監控（Monitoring）、記錄（Logging）與疑難排解（Troubleshooting）三者共同提供了維持服務可靠性所需的信號、護欄和工作流程。本節將涵蓋核心的可觀測性服務、診斷工具、可靠性實踐以及事件應變操作，並探討其設計理念、權衡取捨與常見的故障模式。

監控與警示基礎

Cloud Monitoring 會從 Google Cloud 服務、代理程式（agents）和自訂指標（custom metrics）中擷取時間序列資料，以提供儀表板、運作時間檢查、SLO 和警示功能。

• 指標與基數（cardinality）

  • 受監控的資源類型（例如 gce_instance、aws_ec2_instance、global）會界定專案、地區和執行個體 ID 等維度（dimensions）的範圍。
  • 應盡量減少無邊界（unbounded）的標籤值（例如 user_id），以防止高基數問題爆發，這會拖慢查詢速度並增加成本。
  • 針對延遲（latency），應優先選用分佈指標（distribution metrics）（p50/p90/p99），並使用對齊視窗（alignment windows）來進行一致的匯總（rollups）。

• 儀表板

  • 使用內建的服務儀表板來快速上手。建立自訂儀表板以整合跨專案的指標。面板的組織應先依據症狀（延遲、錯誤、飽和度），再依據原因（CPU、記憶體）。
  • 對於叢集（fleets），應避免使用個別執行個體的圖表；改為按服務、可用區（zone）或 MIG 進行匯總，以減少雜訊、增強信號。

• 警示政策

  • 設計基於症狀且與使用者體驗相關的警示：例如可用性 SLO 消耗（burn）、延遲百分位數、錯誤率。使用多視窗、多消耗率的警示來捕捉快速和慢速的消耗（例如，1 小時內消耗 2% 和 5 分鐘內消耗 5%）。
  • 設定合理的通知頻率限制和自動關閉行為。使用事件自動緩解註解（incident auto-mitigation annotations）來記錄應變手冊（runbooks）。
  • 對於有嚴格排程的關鍵批次作業和資料管道，應使用指標缺席（metric absence）警示。
  • 以日誌為基礎的指標（Log-based metrics）支援對應用程式或安全事件（例如，重複出現的 permissionDenied）發出警示。

• 通知管道

  • 根據嚴重性設定管道：SEV1 使用呼叫通知（paging）（on-call、簡訊、電話），SEV2/3 使用即時通訊（chat），低優先級使用電子郵件或 webhooks。使用 Pub/Sub 與票務（ticketing）或自動化系統整合。
  • 定期測試通知管道；過時的管道是一種無聲的故障模式。

• 運作時間檢查與綜合監控（synthetic monitoring）

  • 從全球各個監測點（vantage points）發出的 HTTP(S) 和 TCP 檢查可驗證外部可達性。將檢查與內容比對（content match）結合，以偵測部分故障。
  • 對於內部服務，可透過混合式連線（hybrid connectivity）或 Private Service Connect 使用私有運作時間檢查。
  • 故障模式：檢查可能因 DNS TTL 延遲、TLS 憑證輪替問題或區域性中斷而失敗；在發出呼叫通知前，應與指標數據相互佐證。

• 多專案監控

  • 使用單一的 Monitoring 工作區並連結所有專案，以整合儀表板和警示。這能簡化整個叢集的 SLO 管理並減少重複設定。

記錄、稽核與應用程式診斷

Cloud Logging 是平台和應用程式日誌的路由、儲存和查詢層。輔助的 APM 工具（Error Reporting、Trace、Profiler）可加速根本原因的隔離。

• 日誌路由、值區（buckets）、匯出（sinks）與保留

  • 使用匯出（sinks）將日誌路由到日誌值區（預設或自訂）、BigQuery（用於分析）、Pub/Sub（用於串流處理）或 Cloud Storage（用於封存）。
  • 為了資料落地（data residency）和效能，應使用區域範圍的日誌值區。若法規遵循有要求，則套用 CMEK。
  • 依值區設定保留期限（例如，營運日誌保留 30-90 天，稽核日誌保留數年）。較長的保留期會增加成本；應積極使用篩選器來控制開銷。
  • 排除項目（Exclusions）可減少擷取冗長的日誌（例如，健康檢查）。應驗證篩選器，以避免無意中丟棄關鍵日誌。

  範例：為稽核日誌建立一個 BigQuery 匯出

undefined

範例：建立一個排除項目

undefined

• 查詢與記錄瀏覽器（Log Explorer）

  • 在 resource.type、severity、labels 和 JSON payloads 上使用進階篩選器。儲存常用分類路徑（triage paths）的查詢（例如，啟動失敗、permissionDenied、quotaExceeded）。
  • 建立以日誌為基礎的分佈（distribution）和計數器（counter）指標，用於警示和儀表板。

• Cloud Audit Logs

  • 管理員活動日誌（Admin Activity logs）：永遠開啟，擷取不收費；記錄管理員的寫入操作（例如，createInstance）。
  • 資料存取日誌（Data Access logs）：記錄資料層（data-plane）的讀取和寫入操作（例如，storage.objects.get）。對許多服務而言預設為停用；應選擇性地啟用，因為其數量和成本可能很高。
  • 系統事件日誌（System Event logs）：Google 系統的動作（例如，autoscaler、維護期間的即時遷移）。
  • 政策拒絕日誌（Policy Denied logs）：明確記錄 IAM 和機構政策的拒絕事件。對於存取問題的疑難排解和安全審查至關重要。
  • 將稽核日誌路由到 BigQuery 以便保留和調查；對 authenticationInfo.principalEmail 等標籤建立索引，以便進行歸因分析。

• Error Reporting、Trace 與 Profiler

  • Error Reporting 會按服務和版本自動將堆疊追蹤（stack traces）分組；與通知管道整合，以便在新錯誤群組出現和錯誤突然飆升時收到通知。
  • Cloud Trace 收集請求延遲的分佈和跨距（spans）；設定取樣（sampling）率以平衡額外負擔和精確度（例如，對於高 QPS 的服務，設定為千分之一，若使用 OpenTelemetry collectors，可搭配尾部取樣 tail-based sampling）。
  • Profiler 在生產環境中提供低負擔的持續性 CPU/堆疊（heap）剖析。將其限制在熱路徑（hot paths）或具代表性的工作負載上，以控制資料量和額外負擔。使用來源對應（source mapping）以獲得可讀的呼叫圖（call graphs）。
  • 權衡取捨：較高的取樣率能改善診斷，但會增加成本和潛在的 PII（個人識別資訊）曝險；應清除敏感欄位並使用權杖化（tokenization）。

服務、資源與網路的故障排除

有效率的故障排除是從症狀開始，接著到系統邊界，然後再到資源與其相依性。

• 受管服務的健康狀況、服務狀態、配額、區域性事件

  • 驗證事件是否源於上游：檢查服務健康狀況和最近的區域性公告。尋找錯誤暴增、延遲升高或配額錯誤。
  • 配額是以專案為單位，且通常也以區域為單位；日誌中的 quotaExceeded 和 rateLimitExceeded 表示正在進行流量調節。在尖峰事件前預先申請提高配額。
  • 故障模式：部分區域性中斷可能表現為間歇性錯誤；在可能的情況下，設定多區域故障轉移。

• 資源健康狀況與 VM 診斷

  • 使用執行個體操作、維護事件和健康狀態檢查。對於 MIGs，檢查自動修復的重啟和健康狀態檢查的失敗，以隔離有問題的映像檔或設定。

  • VM 序列控制台，用於查看開機和核心訊息：

undefined

- 常見原因：核心崩潰 (kernel panics)、不良的 fstab 項目導致開機受阻、不正確的網路設定、OS Login 設定錯誤導致 SSH 失敗。

• 確保使用 OS Login 搭配個別使用者的 SSH 金鑰和 IAM 角色 (compute.osLogin 或 compute.osAdminLogin)，以實現可追溯的存取。

• 使用 Logs Explorer 進行故障分析

  • 從症狀日誌 (5xx, deadlineExceeded) 開始，依資源標籤進行篩選，然後與部署變更和配額日誌進行關聯分析。使用直方圖檢視來找出變更點。

• 網路可觀測性

  • VPC Flow Logs：對每個 VNIC 的 5-tuple 流量進行取樣；在子網路上啟用。調整取樣率 (例如 0.5) 和中繼資料選項，以在效能與詳細程度之間取得平衡。

undefined

• 防火牆日誌記錄：擷取關鍵規則的允許/拒絕決策，以診斷非預期的封鎖或規則遮蔽 (shadowing)。

undefined

• Connectivity Tests：模型化並驗證跨 VPC、對等互連 (peering)、Cloud VPN、Cloud Interconnect 和防火牆規則的可達性。對於變更前的驗證和事件分類 (triage) 很有用。

undefined

• 輔助訊號：Cloud NAT 和負載平衡器日誌，用於分析出口 (egress) 和邊緣問題。故障模式包括非對稱路由、遺失路由、防火牆規則順序錯誤以及政策限制。

可靠性、SLO 與事件營運

營運紀律將遙測資料與使用者影響目標及一致的事件執行聯繫起來。

• SLO、錯誤預算與基準線

  • 根據以使用者為中心的 SLI（可用性、延遲、正確性）來定義 SLO。例如：在 30 天內，99.9% 的讀取請求在 200 毫秒內完成。
  • 依服務和發布版本追蹤錯誤預算並設計彙總儀表板。根據預算消耗情況來管控部署。
  • 在流量增加前建立效能基準線；效能衰退是透過與基準的偏差來偵測，而非絕對值。

• 減少警報雜訊

  • 優先使用服務層級的警報，而非執行個體層級的警報。使用變化率和百分位數條件。在維護期間應用通知節流、事件自動關閉和警報靜音。
  • 透過共通的標籤和政策來對警報進行去重複；使用感知相依性的路由，以避免因同一事件而同時呼叫資料庫和應用程式的負責人。

• 事件應變工作流程

  • 進行分類並宣告嚴重性；指派角色（事件指揮官、營運、溝通、記錄員）。
  • 升級路徑：輪值待命、主題專家和供應商支援（在支援工單中包含專案 ID、請求 ID、時間戳和區域）。
  • 溝通：維持單一事實來源（聊天頻道和事件文件）。定期向利害關係人提供更新，內容包含影響、緩解措施和預計完成時間 (ETA)。
  • 緩解劇本：回滾、容錯移轉、停用功能旗標或增加容量。優先選擇影響範圍小且可逆的變更。

• 事件後檢討與 RCA

  • 證據導向：關聯指標、日誌、追蹤和變更事件。記錄哪些偵測信號觸發了、為什麼觸發或未觸發，以及偵測/緩解所需的時間。
  • 識別促成因素，而不僅是直接原因。記錄具體的行動項目、負責人和截止日期；並據此更新操作手冊和警報。
  • 無咎文化鼓勵充分揭露資訊並進行系統性修復。

• 營運操作手冊

  • 結構：觸發與偵測、快速診斷樹、安全的緩解措施、回滾/還原步驟、驗證和退出標準。
  • 讓指令和過濾器可隨時複製貼上；為應變人員驗證最小權限 IAM（例如，用於唯寫備份的 storage.objectCreator；用於工作負載身分識別的專用服務帳戶）。
  • 透過變更管理對操作手冊進行版本控制；在演習日進行測試。

實務問題情境

Northwind Outfitters 在 Google Cloud 上執行一個區域性的電子商務平台。在最近一次流量高峰後，使用者間歇性地回報結帳逾時和產品搜尋緩慢的問題。營運團隊需要快速恢復可靠性、減少警報雜訊，並強化跨多個專案的診斷能力。

方法：

1. 整合跨專案的監控

• 行動：建立一個單一的 Monitoring 工作區，並連結 prod、payments 和 search 專案。建立一個「使用者旅程」儀表板，顯示結帳和搜尋的可用性、延遲和錯誤率。
• 理由：集中化的可視性支援服務層級的分類，並能關聯跨服務的問題（例如，搜尋延遲連帶導致結帳逾時）。

2. 實作 SLO 和消耗率警報

• 行動：定義 SLO：99.9% 的結帳請求在 400 毫秒內完成，99.95% 的搜尋請求在 250 毫秒內完成。針對延遲和錯誤率 SLI 建立多重時間視窗的消耗率警報（1 小時內消耗 2% 和 5 分鐘內消耗 5%）。透過呼叫系統通知輪值人員，透過聊天軟體通知利害關係人。
• 理由：消耗率警報可以捕捉到快速的效能衰退和持續的緩慢消耗，而不會因為正常的波動而發出呼叫。

3. 新增包含內容匹配的合成正常運行時間檢查

• 行動：為公開進入點設定 TCP 和 HTTPS 正常運行時間檢查，並為內部支付 API 設定一個私有正常運行時間檢查，驗證回應內文包含「ok」。
• 理由：偵測可達性和部分故障，例如後端路由錯誤或上游服務效能下降。

4. 強化日誌路由和保留政策

• 行動：建立專用的日誌儲存桶：ops（90 天）、security-audit（2 年，CMEK）。透過匯出槽將 Admin Activity、Data Access、System Event 和 Policy Denied 日誌路由到 BigQuery 進行分析。為頻繁的健康檢查新增排除規則。
• 理由：適當的保留期可控制成本；BigQuery 可實現快速的數位鑑識。排除規則在不損失關鍵證據的情況下減少雜訊。

5. 啟用應用程式診斷

• 行動：使用 OpenTelemetry 為服務進行檢測以啟用 Trace；為後端和前端啟用 Error Reporting；將 Profiler 推展至結帳服務，以保守的取樣率進行 CPU 和堆積分析。
• 理由：Trace 可識別延遲熱點路徑；Error Reporting 能突顯新的錯誤群組；Profiler 能以低額外負擔揭露 CPU 競爭和記憶體洩漏問題。

6. 強化網路可觀測性

• 行動：在 prod 子網路上啟用 VPC Flow Logs（0.5 取樣率，包含所有中繼資料），並在通往 search 和 payments 的傳入流量的 allow/deny 規則上啟用防火牆日誌。建立從 web 層到 search 以及從 payments 到 Cloud SQL 的 Connectivity Tests。
• 理由：流量日誌和防火牆日誌能揭露封包丟失、重傳和被遮蔽的規則；Connectivity Tests 可驗證可達性並識別錯誤設定。

7. 資源層級的診斷與

← 部署、組態與自動化 · 所有領域 · 安全性、合規性與資料保護 →

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

瀏覽 Google →