Cloud Monitoring 與可觀測性

GCP 可觀測性簡介 (Introduction to Observability on GCP)

可觀測性 (Observability) 不僅僅是「監控」。它是根據系統的外部輸出來理解其內部狀態的能力。在 Google Cloud 中，Cloud Monitoring 透過收集來自 Google Cloud 資源與應用程式的指標 (Metrics)、事件和元數據，為可觀測性奠定了基礎。一位 Professional Cloud Architect 會使用這些工具來確保系統的可靠性、效能與成本效率。

白話文解釋 Cloud Monitoring

類比 1 — 汽車儀表板 (The Car Dashboard)

監控就像是汽車的儀表板。速度計（指標 Metric）告訴你現在開多快。油量表告訴你還剩多少資源。「檢查引擎」燈號（警報 Alert）則是在出問題的當下告訴你狀況不對，即使你還不知道具體原因是什麼。

類比 2 — 健康監測器（智慧手錶）

可觀測性就像戴著一只智慧手錶，追蹤你的心率、睡眠模式和血氧濃度。如果你的心率突然飆升，手錶不僅會說「危險」，它還能幫助醫生（架構師）觀察一段時間內的模式，看看心率飆升是發生在運動時還是休息時，從而幫助診斷根本原因。

類比 3 — 航空管制塔台 (The Air Traffic Control Tower)

Cloud Monitoring 就是航空管制 (ATC) 塔台。管制員在雷達上看到每一架飛機（服務）。他們可以看到每架飛機的高度（延遲 Latency）、速度（吞吐量 Throughput）和燃料水平（資源使用情況）。如果沒有 ATC，整個機場（雲端基礎設施）將陷入混亂。

Cloud Monitoring 的核心組件

1. 指標 (Metrics)： 自動為 Google Cloud 服務（如 GCE、GKE、Cloud SQL）收集。你也可以從程式碼發送自訂指標 (Custom Metrics)。
2. 資訊主頁 (Dashboards)： 指標的可視化呈現。使用自訂資訊主頁將相關指標群組化（例如「支付服務」的所有相關指標）。
3. 運作時間檢查 (Uptime Checks)： 定期檢查你的應用程式是否可以從全球各個位置存取。
4. MQL (Monitoring Query Language)： 一種強大、具表現力的語言，用於查詢和轉換指標數據。它類似於 SQL，但針對時間序列數據進行了優化。

Google Cloud Managed Service for Prometheus (GMP)

對於已經在使用 Prometheus 進行 Kubernetes 監控的團隊，GMP 提供了一個全託管、全球可擴展且與 Prometheus 相容的監控解決方案。

• 零運維 (No Ops)： 你不需要管理 Prometheus 伺服器或儲存空間。
• 混合雲： 使用相同的 Prometheus 工具監控 GKE、地端和其他雲端。

可觀測性的最佳實踐

• 監控「黃金訊號」(Golden Signals)： 延遲 (Latency)、流量 (Traffic)、錯誤 (Errors) 和飽和度 (Saturation)。
• 基於日誌的指標 (Log-based Metrics)： 將你的日誌轉換為指標（例如「計算日誌中 404 錯誤的數量」），以彌合日誌記錄與監控之間的差距。
• 分散式追蹤 (Distributed Tracing)： 使用 Cloud Trace 查看單個請求如何穿過多個微服務，進而找到延遲的確切來源。

架構師洞察： 對於 PCA 考試，如果場景涉及監控「多雲」或「混合雲」環境，則在外部 VM 上安裝 Ops Agent 並配合 Cloud Monitoring 是首選解決方案。 ::

Metrics Explorer 與 Monitoring Query Language (MQL)

Metrics Explorer 是 Cloud Monitoring 進行臨時指標調查的入口。它提供建構器 UI，讓你選擇資源類型（例如 gce_instance、k8s_container、https_lb_rule）、指標類型（例如 compute.googleapis.com/instance/cpu/utilization）、過濾標籤、對齊器（如 ALIGN_RATE、ALIGN_MEAN）以及化約器（如按 zone 進行 REDUCE_SUM）。對於 80% 的維運除錯而言，建構器就夠用；剩下的 20% 則必須用 MQL。

PCA 場景常用 MQL 指令

fetch gce_instance::compute.googleapis.com/instance/cpu/utilization
| filter resource.zone =~ 'us-central1-.*'
| align mean_aligner(1m)
| every 1m
| group_by [resource.instance_id], mean(val())

考試常考的 MQL 操作：

• fetch — 選擇資源與指標類型。永遠是第一個動詞。
• align — 將原始樣本標準化到固定週期（rate、delta、mean_aligner）。聚合前必做。
• group_by — 等同 SQL GROUP BY 加聚合函式（sum、mean、percentile）。
• join — 結合兩條時間序列計算比率（例如 HTTP 錯誤率 = 5xx / 總數）。這是建構器 UI 做不到的殺手級功能。
• outer_join 0 — 用 0 填補缺漏資料點，對 SLO 分母在低流量時段降為零時相當關鍵。

何時該用 MQL

需要以下情境時請用 MQL：跨指標比率、百分位數對百分位數的數學運算、動態門檻（例如今天 vs. 上週）或嵌在警報條件裡的異常偵測邏輯。建構器 UI 內部其實就是編譯成 MQL — 你可以在任何面板上點「Show as MQL」學等價的表達式。

資訊主頁：Cloud Monitoring 原生 vs. Grafana

Cloud Monitoring 提供兩種原生資訊主頁類型，外加一流的 Grafana 整合。如何選擇是 PCA 反覆出現的場景。

Cloud Monitoring 原生資訊主頁

• 自動建立資訊主頁 — 隨服務（Cloud SQL、GKE、Load Balancing）自動佈建，零設定的基準視圖。
• 自訂資訊主頁 — 可透過 console 或 JSON / Terraform (google_monitoring_dashboard) 定義。支援 XY 圖表、計分卡 (scorecard)、熱力圖、日誌面板與 Markdown 小工具。
• 資訊主頁變數 — 像 ${project} 或 ${environment} 這類變數可讓一張資訊主頁同時服務 dev/stage/prod。

Managed Service for Prometheus + Grafana

當團隊已經在用 Grafana 時，把它指向 GMP 提供的 Prometheus 相容查詢端點（https://monitoring.googleapis.com/v1/projects/PROJECT/location/global/prometheus/）。透過 Prometheus data source sync sidecar 或 workload identity 進行驗證。好處：

• 重用既有 Grafana 資訊主頁（Kubernetes mixins、Node Exporter 等），不必改寫成 MQL。
• PromQL 語法（counter、histogram with histogram_quantile）原生支援。
• Cloud Monitoring Grafana plugin 也能直接用 MQL 或建構器查詢 Cloud Monitoring。

抉擇法則

• 純 GCP、指標 + 日誌統合在同一介面 → Cloud Monitoring 自訂資訊主頁。
• Kubernetes 重度使用者、多雲、既有 Prometheus exporter → GMP + Grafana。
• 想在同一張資訊主頁同時使用 PromQL 與 Cloud Monitoring 指標 → Grafana 加掛兩個 data source。

運作時間檢查 (Uptime Checks) 深入解析

運作時間檢查會從預設六個全球位置對公開端點（HTTP、HTTPS、TCP）做合成探測：USA-Oregon、USA-Iowa、USA-Virginia、Europe、South America、Asia-Pacific。當回應非 2xx、內容比對不過或請求逾時，該位置即視為失敗。

設定選項

• 頻率 — 1、5、10 或 15 分鐘。1 分鐘成本較高但能更快抓到瞬間性的中斷。
• 逾時 (Timeout) — 最多 60 秒。
• 內容比對 (Content matcher) — 字串、regex、JSON path、「包含 / 不包含」。能抓到「回 200 但 body 寫 ERROR」這類 bug。
• 驗證 — Basic auth、OIDC token（給 IAP 後方的私有服務）、自訂 header。
• TLS 驗證 — 自簽的 dev 環境可關閉；正式環境保持開啟。

私有 VPC 的內部運作時間檢查

公開探測器無法觸及私有 VPC 服務。私有運作時間檢查從 service-producer VPC 內部執行，探測內部負載平衡器或 VM。需要啟用 Service Directory 與託管 checker 資源。用於那些不該對網際網路暴露的內部微服務。

警報政策接線

運作時間檢查本身就是一個指標 (monitoring.googleapis.com/uptime_check/check_passed)。建議用「6 個位置中至少有 2 個失敗持續 5 分鐘」的規則接警報，可過濾單一區域網路抖動造成的假警報。對關鍵服務則收緊到「任一位置失敗即告警」。

SLO 與 Error Budget 工程

Cloud Monitoring 在 Services 區塊原生支援 Service Level Objective (SLO)。流程為：定義一個 Service、挑一個 Service Level Indicator (SLI)、設定目標值，Monitoring 會自動生成 Error Budget 的 burn-rate 指標。

支援的 SLI 類型

• Request-based SLI — good_request_count / total_request_count。來源：Cloud Load Balancing、Istio/ASM、App Engine、Cloud Run，或自訂的成對指標。
• Windows-based SLI — 每 1 分鐘 window 依門檻判定 good/bad（例如 p99 延遲 < 200ms）。延遲類 SLO 比較適合。
• Basic SLI — 全託管產品（GAE、Cloud Run）預設提供，Google 自動發布可用性與延遲指標。

Burn Rate 警報

對 99.9% SLO 的 30 天 window 而言，error budget 是 43.2 分鐘。當預算消耗速度超過可持續水準時即觸發 burn-rate 警報。Google 建議多 window、多 burn-rate 政策：

• Fast burn — 1 小時回看 14.4× burn rate（立刻 page on-call，吃掉 2% 預算）。
• Slow burn — 6 小時回看 1× burn rate（開單，不 page）。

這種模式能同時抓到急性事故與慢性劣化，又不會被每 1 分鐘的抖動干擾。

把 SLO 接到 Release 流程

在 CI/CD 中呼叫 SLO API：在 promote 新版前查詢目前剩餘的 error budget。若預算低於門檻則凍結部署 — 這是 Google 自家 SRE playbook 的標準做法。

自訂指標與 OpenTelemetry

當內建指標不夠（例如「我的自訂 worker 的 queue depth」）時，可透過 Cloud Monitoring API (projects.timeSeries.create) 發送自訂指標；新專案則建議用 OpenTelemetry SDK 搭配 GCP exporter。

自訂指標結構

• Metric type — custom.googleapis.com/myapp/queue_depth（自訂指標必須加 custom 前綴）。
• Metric kind — GAUGE（當前值）、DELTA（區間變化量）或 CUMULATIVE（單調遞增 counter）。
• Value type — INT64、DOUBLE、DISTRIBUTION（用於 histogram / 延遲百分位數）。
• Labels — 最多 10 個自訂 label（例如 queue_name、region）。

OpenTelemetry → Cloud Monitoring

from opentelemetry import metrics
from opentelemetry.exporter.cloud_monitoring import CloudMonitoringMetricsExporter
from opentelemetry.sdk.metrics import MeterProvider
from opentelemetry.sdk.metrics.export import PeriodicExportingMetricReader

reader = PeriodicExportingMetricReader(CloudMonitoringMetricsExporter())
metrics.set_meter_provider(MeterProvider(metric_readers=[reader]))
meter = metrics.get_meter("checkout-service")
queue_depth = meter.create_gauge("queue_depth")
queue_depth.set(42, {"queue_name": "orders"})

Exporter 預設每 60 秒批次送出。免費額度外的成本是每百萬 sample $0.2580 — 因此 label 基數 (cardinality) 設計要小心，因為每組獨特 label 組合會建立一條獨立的時間序列。

基數預算

Cloud Monitoring 對每個 metric descriptor 在 Metrics Scope 內的活躍時間序列有 20 萬條的軟性上限。避免高基數 label（如 user_id、request_id）— 這類資料應該放 Cloud Logging 或 Cloud Trace，不該放指標。

基於日誌的指標 (Log-Based Metrics)

Log-based metrics 把日誌條目轉成 Cloud Monitoring 時間序列。兩種類型：

Counter 指標

計算符合 filter 條件的日誌條目數量。範例：計算 Cloud SQL 出現 error: deadlock 的次數，用來監控鎖競爭。

resource.type="cloudsql_database"
severity="ERROR"
textPayload:"deadlock"

Distribution 指標

透過 regex 或 JSON path 從每筆日誌條目擷取一個數值，再 bucket 化為 histogram。範例：當你無法在 app 加 Cloud Monitoring SDK 時，可從非結構化的 access log 擷取回應延遲。

成本與注意事項

• 系統 log-based metrics（Google 提供的）免費。
• 使用者自訂 log-based metrics 依掃描的日誌條目數與寫入的指標資料計費。
• Log-based metrics 繼承的是日誌保留期，不是指標保留期 — 如果某筆日誌被 sink exclusion 排除，該指標就會停止收到資料。
• Labels 從日誌欄位擷取，同樣受基數規則限制。

警報政策條件深度解析

警報政策是可觀測性的行動層。一個 policy = 一個或多個條件 + 通知通道 + 文件說明 + 選用的 auto-close 時間。

條件類型

• Metric threshold — 最常見。「CPU > 80% 持續 5 分鐘，任一 GCE instance」。
• Metric absence — 指標停止回報時觸發。是「我的 exporter 還活著嗎」這類檢查的關鍵。
• Forecast — 用過去 1h–24h 的線性回歸預測未來是否會突破門檻。適合磁碟即將寫滿的警報（「專案磁碟 4 小時後會滿」）。
• Log-match — 看到特定日誌條目即觸發（例如 setIamPolicy 這類安全稽核事件）。比走 log-based metric 快。
• MQL condition — 任意 MQL 表達式回傳布林時間序列。適用跨指標比率。
• Uptime check failed — 綁定 uptime check 資源的專用條件。

通知通道

Cloud Monitoring 支援 Email、SMS、Slack、PagerDuty、Pub/Sub、Webhook、行動 App。要做事件管理整合時就用 Pub/Sub → Cloud Function → 自訂繞送邏輯（例如依上班時段做升級）。

防抖動 (Anti-flapping) 旋鈕

• duration — 條件必須為真多久才觸發。預設 5 分鐘是甜蜜點。
• auto_close — 復原後等多久才關閉事件（預設 7 天；瞬時問題可調到 30 分鐘）。
• combiner — 多條件 policy 用 AND、OR、AND_WITH_MATCHING_RESOURCE。

Cloud Trace 與 Cloud Profiler 整合

指標與日誌回答的是「what」和「when」。Cloud Trace 與 Cloud Profiler 回答的是「where」和「why」。

Cloud Trace

• 分散式追蹤服務，透過 OpenTelemetry 協定（舊稱 Stackdriver Trace SDK / Zipkin）接收 span。
• App Engine、Cloud Run、Cloud Functions、GKE（搭配 OpenTelemetry Collector sidecar），以及 Cloud Load Balancer（取樣）都有自動 instrumentation。
• Trace List UI 會繪製延遲隨時間變化，並可下鑽到單一 trace 看跨服務 span 的瀑布圖。
• Trace ID 是與日誌相連的鍵 — Cloud Logging 會自動關聯帶 trace 欄位的條目，所以點一個 trace 就能 inline 看到對應日誌。

Cloud Profiler

• 持續性 profiling：CPU、heap、競爭 (Go)、wall-clock 時間，採樣負擔約 5%。
• 支援 Go、Java、Node.js、Python、PHP、.NET（preview）。啟用方式：掛上 agent library + 服務帳號權限 roles/cloudprofiler.agent。
• Flame graph 可比較兩個時間區間或兩個服務版本 — 找出 deploy 後造成 regression 的殺手級功能。

四支柱模式

一套 PCA 等級的可觀測性堆疊把所有東西串起來：

1. Cloud Monitoring → 指標 + 資訊主頁 + 警報。
2. Cloud Logging → 帶 trace 關聯的結構化日誌。
3. Cloud Trace → 請求等級的延遲拆解。
4. Cloud Profiler → 程式碼等級的 CPU/記憶體熱點。

四者共用相同的資源 labels 與 trace ID，所以從警報一鍵就能讓 SRE 從「p99 延遲突破 SLO」追到「這個版本的這個 Go function 在吃 CPU」。

Metrics Scopes 與多專案整合

舊有的「Workspace」概念已改名為 Metrics Scope。Metrics Scope 由一個範圍界定專案 (scoping project) 擁有，最多可列入 375 個被監控專案，這些專案的指標、資訊主頁與警報都會出現在 scoping project 的視圖中。

架構模式

• 依環境分 scope — 每個環境（dev/stage/prod）一個 scoping project，scope 內列入該環境的 workload 專案。
• 依團隊分 scope — 平台/SRE 團隊擁有一個 scope，列入跨事業群的所有正式環境專案。
• 組織級彙整 — 一個中央可觀測性專案 scope 所有正式環境專案；團隊 scope 仍然存在以保留自主性。

權限

• 在 scoping project 上有 roles/monitoring.viewer 的使用者，就能看到所有列入專案的指標 — 即使他們在 workload 專案上沒有 IAM。
• 想把一個專案加入 scope 需要：scoping project 上的 monitoring.metricsScopes.link 加上目標專案上的 monitoring.metricsScopes.linkSource。

限制

• 一個被監控專案可以同時屬於多個 scope（共用服務的好搭檔）。
• 警報政策仍是依專案 scope — Metrics Scope 只整合檢視，不整合警報。組織級警報得透過 Terraform 或 Config Sync 重複佈署 policy。
• 日誌不在 Metrics Scope 內。多專案日誌整合請用資料夾或組織層級的 aggregated log sink，匯入到中央 log bucket 或 BigQuery dataset。

常見問題 — Cloud Monitoring (FAQ — Cloud Monitoring)

Q1. 什麼是「Ops Agent」？

Ops Agent 是 Google Cloud 操作套件 (Operations Suite) 的單一代理程式。它從你的 Compute Engine 執行個體收集指標和日誌。它取代了舊版的 Monitoring 和 Logging 代理程式。

Q2. 監控數據保留多久？

標準指標通常保留 6 週。某些高解析度指標的保留期可能較短。如需進行長期分析，請將指標匯出至 BigQuery。

Q3. 我可以監控其他專案的資源嗎？

可以。你可以使用指標範圍 (Metrics Scopes) 從單個「範圍界定專案 (Scoping Project)」監控多個專案。這對於在多專案組織中集中管理可觀測性至關重要。

Q4. 「運作時間檢查 (Uptime Check)」與「健康檢查 (Health Check)」有什麼區別？

運作時間檢查是外部的（從網際網路進行 Ping 測試）；健康檢查是內部的（由負載平衡器或託管執行個體群組使用，用於決定是否應重啟 VM）。

Q5. 什麼時候應該使用 MQL 而不是基本查詢建構器？

當你需要執行複雜操作時使用 MQL，例如計算兩個不同指標的比率（例如：錯誤率 = 錯誤數 / 總請求數）或執行跨服務聯結 (Join)。