Cloud Monitoring 與 Cloud Trace

Cloud Monitoring 與 Cloud Trace 簡介

Cloud Monitoring 與 Cloud Trace 是 Professional Cloud Developer 考試期待你在每個工作負載標記為 production-ready 之前都要接好的兩個可觀測性支柱。Cloud Monitoring 負責收集時序指標、執行 Alerting Policy、託管儀表板，並追蹤 SLO 與錯誤預算。Cloud Trace 攝取分散式 span、計算每個 RPC 的延遲百分位數，並把那個正在拖累你尾端延遲的慢請求挖出來。再搭配 Cloud Profiler 與 OpenTelemetry SDK，就構成 Google Cloud 維運套件（前身為 Stackdriver）的開發者介面層。

這份筆記會走過指標類型、MQL 查詢語言、儀表板結構、所有 Alerting Policy 變體、Uptime Check、SLO 與錯誤預算的計算、Cloud Trace 的取樣模型與 30 天保留期、Cloud Profiler 的三種 profile、OpenTelemetry 接線、自訂指標、取代 Workspace 的 Metrics Scope，以及 Notification Channel 的路由。每個章節都對應到 PCD 考試會出現的具體 GCP API、gcloud 指令或數字預設值。

白話文解釋

在深入 Cloud Monitoring 與 Cloud Trace 的內部運作前，用三個具體畫面把這些零件講通。

把 Cloud Monitoring 想成商用客機的駕駛艙

波音 787 駕駛艙有幾百個儀表，但飛行員巡航時只盯六個：高度、空速、姿態、航向、垂直速度、燃油。其他都接到自動警報，只有超過門檻才打擾飛行員。Cloud Monitoring 也是這個邏輯。你會從 Compute Engine、Cloud Run、GKE 與應用程式收上千條指標，但健康的儀表板只放六到十個黃金訊號（請求速率、p95 延遲、錯誤率、飽和度、佇列深度、業務 KPI）。其他都躲在 Alerting Policy 後面，只在真的超門檻時才把你叫醒。把所有指標都塞到單一儀表板上，等於有駕駛艙卻沒有飛行員，因為人類視覺系統超過十幾個元素就停止吸收細節。

把 Cloud Trace 想成多階段報稅流程的回執

當一份稅務文件經過初審、覆核、經理、合夥人、再回到客戶 portal，每次交接都會在封面蓋上時間戳。六週後客戶問「為什麼拖這麼久」，合夥人讀章就知道是覆核那位卡了九天。Cloud Trace 對每個 HTTP 請求蓋的就是這種回執。沿路每個微服務都會加上一個 span，紀錄起訖時間與 metadata。當尾端延遲悄悄上升，你打開 Trace 瀑布圖，看到 Spanner 呼叫從 80 ms 變成 1.8 秒，立刻就知道該往哪挖。沒有 Trace，你讀的是一份沒簽名的稅表，只能猜誰造成延誤。

把 SLO 與錯誤預算想成每月的行動上網方案

電信業者承諾你一個月 50 GB。如果第 28 天你已經串流到 49 GB，第 29 天網速就會被限速。如果第 15 天才用了 30 GB，那你坐飛機追劇還很從容。SLO 運作邏輯完全一樣。你向使用者承諾「30 天內 99.9% 請求成功」，就等於預算了 43.2 分鐘的允許故障時間。每一個 5xx 回應都在燒預算。當燒速命中 Alerting Policy 的門檻（典型上是快燒 14.4x、慢燒 6x），事件就會 fire，團隊在預算恢復前停止推送高風險變更。沒有 SLO，所有可靠性的討論都會淪為各說各話；有了 SLO，就變成算術題。

Cloud Monitoring 與 Cloud Trace 核心概念

PCD 考試期待你對下列物件與其精確語意熟稔。

Metric Descriptor

Metric Descriptor 透過 type 名稱（例如 compute.googleapis.com/instance/cpu/utilization）、value type（BOOL、INT64、DOUBLE、STRING、DISTRIBUTION）、kind（GAUGE、DELTA、CUMULATIVE）以及監控資源，來識別一條時序。Cloud Monitoring 內建上千個 descriptor，也允許你用 custom.googleapis.com/ 或 workload.googleapis.com/ 前綴註冊自訂 descriptor。

Monitored Resource

Monitored Resource 是指標所紀錄到的、帶有標籤的物件，例如 gce_instance、k8s_container、cloud_run_revision、generic_task。每種資源型別都帶自己的 label 集合（project_id、instance_id、zone 等），這就是 Monitoring 在數百萬條時序中如何鎖定單一序列的方式。

Alerting Policy

Alerting Policy 把一個或多個 condition 綁到一組 notification channel 與 documentation 區塊。Condition 有六種家族：metric threshold、metric absence、forecast、MQL、PromQL、log-based。當 condition 評估為 true 時開出事件，恢復時自動關閉。

Uptime Check

Uptime Check 是從六個固定全球地點發出的合成 HTTP、HTTPS、TCP 或 ICMP 探測（USA-OR、USA-VA、USA-IA、Europe、South America、Asia-Pacific）。預設頻率每分鐘一次，逾時 5 秒。每個 check 都會輸出一條可被警示的指標。

Span 與 Trace

Span 是一個帶有起訖時間戳、名稱、attributes 與 parent span ID 的計時操作。Trace 是共享同一個 16-byte trace ID 的 span 樹。Cloud Trace 預設保留 span 達 30 天，單一 trace 最多支援 1000 個 span。

SLI、SLO、Error Budget

SLI 是使用者快樂度的可量測代理，通常是請求成功率或請求延遲。SLO 是 SLI 在滾動或日曆視窗上的目標值（常見 28 天）。錯誤預算就是 SLO 的倒影：99.9% 的 SLO 在 28 天內等於 40 分 19 秒的允許故障。

Metrics Scope（前身 Workspace）

Metrics Scope 是 Cloud Monitoring 的可視性邊界。每個 Google Cloud 專案一開始的 scope 只包含自己。你最多可以把 375 個受監控專案 加進一個 scoping project，讓一個維運團隊同時觀察多個應用程式專案而不必切換 context。

指標類型與 MQL 查詢語言

懂指標 kind 與 value type 就解決了一半「警示為什麼一直跳」的問題。

Metric Kind：GAUGE、DELTA、CUMULATIVE

GAUGE 回報當下值（CPU 百分比、佇列深度）。DELTA 回報在固定對齊視窗內的變動量（每分鐘 HTTP 請求數）。CUMULATIVE 回報程序啟動以來單調遞增的累計值（bytes_sent_count）。畫圖或設警示時，Monitoring 會自動把 CUMULATIVE 對齊為 rate；忘記對齊 CUMULATIVE counter 是「我儀表板畫成 0」這類工單最常見的原因。

Value Type 與 DISTRIBUTION

多數指標是 INT64 或 DOUBLE，但延遲指標通常是 DISTRIBUTION。DISTRIBUTION 內部存的是分桶 histogram，這就是為什麼 Monitoring 能在不留每筆原始樣本的情況下算 p50、p95、p99。MQL 的 percentile() 函式只吃 DISTRIBUTION；丟 DOUBLE 進去會回傳錯誤。

MQL 基本語法

Monitoring Query Language 是「指標版 SQL」。最小查詢長這樣：

fetch cloud_run_revision::run.googleapis.com/request_count
| filter resource.service_name == 'checkout-api'
| align rate(1m)
| every 1m
| group_by [resource.location], sum(value.request_count)

這個 pipeline 讀起來是：fetch 資源與指標、filter 列、align 到時間視窗、every 為取樣頻率、group_by 加聚合。MQL 支援跨指標 join，所以你能用一個查詢算出「錯誤率 = 5xx 數 ÷ 總數」這種比率。

何時改用 PromQL

Cloud Monitoring 也接受 PromQL，對應 managed Prometheus 與一般警示。從自建 Prometheus 遷移過來的團隊通常會繼續用 PromQL 保留肌肉記憶；GCP 原生的綠地團隊則選 MQL，因為和內建指標、label 階層整合更緊。

儀表板與視覺化

儀表板把指標海變成 30 秒可掃完的故事。

內建 vs. 自訂儀表板

Cloud Monitoring 對每個主要 Google 服務（Cloud Run、GKE、Cloud SQL、Pub/Sub）都附贈預建儀表板，自動出現、零設定。自訂儀表板存在 dashboards API 中，可透過 UI、JSON、Terraform（google_monitoring_dashboard）或 gcloud monitoring dashboards create --config-from-file=dashboard.json 建立。

元件種類

Dashboard widget 包含 XY chart（折線、堆疊、長條）、scorecard（大數字加 sparkline）、gauge、heatmap（給 DISTRIBUTION 用）、alert chart（疊上事件歷史）、Markdown 文字、嵌入式 log 面板。混搭很關鍵：用 scorecard 顯示當下錯誤率，再配一張過去七天的 XY chart，遠勝兩張折線圖。

Mosaic Layout 與分區標題

儀表板現在支援 mosaic layout，能夠不被舊版 12 欄格框死，並可加入可摺疊的分區標題。團隊通常用分區對映到四大黃金訊號（流量、延遲、錯誤、飽和度），讓每張服務儀表板長相一致。

共享與版本控管

儀表板存活於專案中，凡有 roles/monitoring.viewer 都看得到。JSON 應放進 Git 讓儀表板 drift 變成可 review，並用 Terraform 把 dev 推到 prod。儀表板 ID 不會變，所以你能把固定網址寫進 runbook。

Alerting Policy 深入解析

PCD 考試很愛問「哪種 condition 對應哪種情境」。

Metric Threshold Condition

標準款：當 metric.value > X 持續 duration 分鐘以上就 fire。你要設 aligner（mean、max、sum、percentile）、reducer（跨 instance 平均、跨 instance 百分位數）、門檻與 duration 視窗。5 分鐘的 duration 能防止單一樣本尖峰把團隊吵醒。

Metric Absence Condition

當預期應該存在的指標在設定 duration 內停止回報時 fire。用來偵測掛掉的 agent、意外縮到 0 的 Cloud Run revision，或心跳指標沒打出來的排程作業。沒有 absence condition，agent 掛了會永遠看起來像「指標低於門檻」。

Forecast Condition

Cloud Monitoring 內建一個線性回歸模型，預測指標是否會在未來視窗（典型 1 到 24 小時）內突破門檻。經典場景就是磁碟塞爆：forecast 說「磁碟將在 6 小時內裝滿」，趁還有時間擴容前就把團隊叫醒。

MQL 與 PromQL Condition

單一指標門檻不夠用時，MQL 或 PromQL condition 讓你跨多條時序寫任意數學。考試最愛的例子是錯誤率比值：5xx_count / total_count > 0.01 for 5 minutes。單一 MQL condition 就能取代原本需要 multi-condition policy 加複雜 AND/OR 邏輯的設計。

Log-Based Alert

Log-based alert 在符合 Cloud Logging 查詢的 log 條目數量上 fire，而不是指標值。用在一次性訊號，例如「我們收到了某個特定 stack frame 的 NullPointerException」，這種不值得開永久的 log-based metric。

Uptime Check 與合成監控

世界六大洲的真實使用者不在乎你的服務從隔壁機房看起來是不是健康的。

HTTP、HTTPS、TCP、ICMP Check

Cloud Monitoring 的 uptime check 有 HTTP（GET 或 POST）、HTTPS（可選憑證有效性檢查）、TCP（測連接埠連線）與 ICMP（ping）四種。HTTPS check 可驗證憑證鏈，並在到期不到 15 天時 fire 警示，剛好捕捉到續約 cron 默默失敗的情況。

六個全球探測地點

每個 uptime check 都從六個固定區域 fire：USA-OR（Oregon）、USA-VA（Virginia）、USA-IA（Iowa）、Europe（Belgium）、South America（São Paulo）、Asia-Pacific（Singapore）。成功門檻預設是「六地至少 2 個回報成功」，這個閾值容忍區域性 ISP 怪事而不亂叫。

Synthetic Monitor 處理多步驟流程

單純 GET /health 不夠時，Cloud Monitoring Synthetic Monitor 跑一段 Node.js 或 Python 腳本（典型用 Puppeteer 或 Playwright），走完登入、加入購物車、結帳。Synthetic monitor 每 1 到 60 分鐘執行一次，並輸出一條可警示的自訂指標。

Uptime Check 計費與配額

Uptime check 每專案 100 個內免費，超過後每個每月 $0.30。Synthetic monitor 底層其實在跑 Cloud Functions，按該服務計費。PCD 考試很少考價格，但會考「Uptime check 只能做 HTTP/TCP 探測，無法登入流程，那是 Synthetic monitor 的工作」。

SLO 與錯誤預算

Service monitoring 是 Cloud Monitoring 把 SLI/SLO 抽象具現化的子產品。

定義 SLI

你把 SLI 定義在 Service 物件上（Cloud Run service、GKE workload、Istio service，或自註冊的 BasicService）。SLI 是下列之一：request-based availability、request-based latency、windows-based availability、自訂 MQL。Latency SLI 說的是「好請求是 300 ms 以內完成的」；availability SLI 說的是「好請求是沒有 5xx 的」。

Compliance Period 與燒速

SLO 指定目標（99.9%）、compliance period（滾動 28 天為標準）、calendar 或 rolling 模式。燒速（burn rate）是你目前消耗預算的倍數。燒速 1.0x 表示預算正好在 period 結束時用完；14.4x 表示 2 小時就會被燒光。

Multi-Window Multi-Burn-Rate 警示

SRE 推薦的模式：14.4x 燒速持續 1 小時（1 小時內燒掉 5% 預算）開 P1 警示；6x 燒速持續 6 小時開 P2 警示。這個組合同時抓得到快速事件（資料庫掛掉）與慢退化（某次部署悄悄加了 5 ms 延遲），又能過濾單分鐘的尖峰。

Error Budget Policy

錯誤預算策略是團隊層級的約定：預算燒完之後會發生什麼——功能凍結、強制 postmortem、升級 paging。Cloud Monitoring 只追蹤預算，不強制執行策略；策略是團隊工程文化的責任。

Cloud Trace 內部運作

Trace 是 Monitoring 的延遲除錯搭檔。

Trace Context 傳遞

Trace 由進入點產生的 16-byte trace ID 識別，透過 W3C traceparent HTTP header 傳遞到每個下游呼叫（舊程式可能還在用 X-Cloud-Trace-Context）。Cloud Run、App Engine、GKE Ingress 會自動注入 header；你的應用程式必須在對外呼叫時把它轉發出去，否則 trace 會碎成幾段斷裂的片段。

Sampling 取樣

Cloud Trace 在 App Engine standard 上預設每實例每秒 0.1 個請求取樣，把 overhead 壓到幾乎為零。OpenTelemetry SDK 讓你用 ParentBased(TraceIdRatioBased(0.01)) 設 1% 取樣並尊重上游決策。AlwaysOn 對低流量服務沒差，對高流量服務則會讓 trace 攝取費用爆炸。

30 天保留期

Trace span 保留期是 30 天。產品本身沒有延長保留的選項；如果需要 30 天以上的歷史延遲分析，要透過 Trace export API 匯出到 BigQuery，或用排程 Cloud Function 呼叫 ListTraces API。考試常見的 distractor 是 90 天或 365 天；正確答案永遠是 30。

Trace Analysis 報告

Cloud Trace 內建延遲報告，可比較兩個時間視窗（今天 vs 昨天、部署前 vs 部署後）。Latency regression 報告會挑出 p95 上升超過設定門檻的 endpoint，這是確認某次部署造成變慢最快的辦法。

Trace 計費

Trace 每月前 250 萬個 span 免費，超過後每百萬個 $0.20。一個天真把 OpenTelemetry sampler 設為 1.0 的部署，在繁忙服務上一個下午就能把免費額度燒光。

Cloud Profiler：程式碼層級效能

Trace 告訴你哪個 RPC 慢，Profiler 告訴你那個 RPC 裡面是哪個函式燒 CPU。

CPU、Heap、Contention Profile

Cloud Profiler 連續收集三種 profile：CPU time（時鐘時間花在哪裡）、heap（哪些 allocation 主導記憶體）、contention（哪些 mutex 鎖在阻塞 goroutine 或 thread）。Contention profiling 只支援 Go 與 Java；Python 只有 CPU 和 heap。

Agent 設定

掛 Profiler 是接語言對應的 agent：Go 用 cloud.google.com/go/profiler、Python 用 google-cloud-profiler pip 套件、JVM 用 Java agent JAR、Node.js 用 @google-cloud/profiler。Agent 每分鐘抽樣大約 10 秒，並非同步上傳 profile，overhead 控制在 5% 以下。

Flame Graph 判讀

Profiler UI 渲染 flame graph：x 軸是累計時間消耗、y 軸是 call stack。寬條代表昂貴的函式；高堆疊代表深遞迴。「diff」視圖可比較兩個時間視窗或兩個服務版本，部署後出現的回歸會直接從畫面跳出來。

Profiler 配額

Profiler 對所有 Google Cloud 專案都免費。實務上唯一的限制是每專案 50 個 deployment（deployment 是服務名稱、版本、zone 的三元組）。超過就申請配額提升或合併命名。

OpenTelemetry 與自訂指標

CNCF 標準 SDK 是讓應用程式接上 Cloud Monitoring 與 Cloud Trace 最現代、與廠商解耦的方式。

OpenTelemetry SDK 接線

OpenTelemetry 取代了老的 OpenCensus（2024 起棄用）。你裝語言對應的 SDK 加 GCP exporter：Python 用 opentelemetry-exporter-gcp-monitoring 與 opentelemetry-exporter-gcp-trace；Node.js 用 @google-cloud/opentelemetry-cloud-monitoring-exporter。Exporter 用你服務既有的驗證憑證把 span 推到 Cloud Trace，把 metric 推到 Cloud Monitoring。

Auto-Instrumentation 自動插樁

每個語言都附 auto-instrumentation agent，自動 hook 常見函式庫（Flask、Django、requests、gRPC、JDBC、Express），不必改 code。Python 只要 opentelemetry-instrument python app.py 就能讓服務完整被 trace。考題如果說「最少開發者工作量」，答案通常就是 auto-instrumentation。

用 OpenTelemetry 寫自訂指標

除了自動收的指標，你也可以發 application 自訂指標：每秒訂單數、cache 命中率、佇列深度。在 Meter 上定義 Counter、UpDownCounter、Histogram 或 ObservableGauge，從程式碼遞增，exporter 會把它 flush 成 Cloud Monitoring 裡的 workload.googleapis.com/your_metric_name。

Direct API vs. OpenTelemetry

也可以直接打 monitoring.googleapis.com/v3/projects/PROJECT/timeSeries:create REST API 寫自訂指標，但這條路寫起來囉嗦又耦合。OpenTelemetry 是推薦路徑，因為同樣的 instrumentation 可在 GCP、AWS、地端與未來其他 backend 共用。

Metrics Scope 與跨專案可視性

Workspace 改名是本課最常被考的題型。

從 Workspace 到 Metrics Scope

Google 在 2022 把 Workspace 改名為 Metrics Scope。底層模型沒變：一個 scoping project 匯整多個受監控專案的指標，給維運團隊一個 single pane of glass。舊 API 與 SDK 裡的「Workspace」字眼仍可運作，但已是棄用術語。

Scoping Project 與 Monitored Project

Scoping project 是 Monitoring console 根基所在的專案。Monitored project 是其指標、trace、uptime check 出現在該 scope 內的專案。一個 monitored project 同時只能屬於一個 scope；若需要被兩個 scope 看到，就只能輪替或複製。

上限與階層

一個 scoping project 最多支援 375 個 monitored project。加入專案需要 scoping project 的 roles/monitoring.editor 與 monitored project 的 roles/monitoring.viewer。Folder 和 organization 階層不會自動把專案塞進 scope；要透過 API 或 gcloud monitoring metrics-scopes 一個一個加。

跨專案警示與儀表板

專案進入同一個 scope 後，你就能用單一 label filter 蓋過所有專案來建儀表板和警示。這就是平台團隊如何在不開全組織 IAM 的情況下，從一個 Monitoring UI 看 200 個應用程式專案。

Notification Channel 與事件路由

警示寫得再好，沒人收到就是死掉的警示。

支援的 Channel 種類

Cloud Monitoring 支援 Email、SMS（限美國號碼）、Slack、PagerDuty、Webhook（HTTP POST 到任意 URL）、Pub/Sub、Google Chat、用 webhook 接的 Microsoft Teams，以及幾個第三方整合（Splunk On-Call、BigPanda）。每個 channel 是專案 scope 的資源，透過確認 email 或 OAuth 授權完成驗證。

Webhook 與 Pub/Sub Channel

Webhook channel 把 JSON event payload POST 到任意 URL，這是讓 Cloud Monitoring 接到自訂事件管理或自動修復系統的方式。Pub/Sub channel 把同樣 payload 發到 topic，讓 Cloud Function 或 Cloud Run 服務消費後做程式化動作（rollback、scale-up、開 ticket）。

依嚴重度分流路由

最常見的模式是按 policy 嚴重度掛不同 channel 組合：P1 進 PagerDuty、P2 進 PagerDuty 加 Slack、P3 只進 Slack、P4 進 email digest。一個 policy 可以列多個 channel；順序不重要，因為所有 channel 都是並行接通知。

Snooze 與維護視窗

Snooze 是限時抑制：阻止指定 policy（用名稱 pattern 或 label filter）在視窗內開出新事件。在規劃部署、資料庫遷移或任何已知會引起警示的變更前先 snooze。Snooze 不刪歷史，只是把 channel 層在那段時間靜音。

常見陷阱與取捨

Cloud Trace 取樣設太高

把 OpenTelemetry sampler 設成 AlwaysOn、服務 1000 RPS 的話，一個月會匯出 26 億個 span。免費額度 250 萬個之後每百萬 $0.20，光 trace 儲存就超過 $500 一個月。預設用 TraceIdRatioBased(0.01)（1%），只在事件除錯時臨時調高。

對單一樣本尖峰開警示

「CPU 現在超過 90%」這種 condition 會在每次 GC 或一陣合理流量都 fire。一定要把 threshold 配 5 分鐘以上的 duration window，逼尖峰持續一段時間才會開事件。

Trace Context 沒傳遞

如果你的程式用自訂 HTTP client，沒轉發 traceparent header，trace 會碎成多段斷裂片段，瀑布圖就沒用了。在 Trace 裡看對外請求驗證——如果第二個服務出現為獨立 root trace，就是 propagation 壞了。

把 Cloud Profiler 跟 Cloud Trace 搞混

PCD 考試很愛把這兩個並列。Trace 告訴你「哪個 RPC 慢」（呼叫 Spanner 的 gRPC 花了 1.8 秒）。Profiler 告訴你「RPC 裡哪段程式碼慢」（JSON serializer 在 500 KB payload 上燒了 1.6 秒 CPU）。完整全棧效能除錯兩個都需要。

最佳實踐

從 Google Cloud Architecture Center 與 PCD 實考題萃取的精簡清單。

從第一天就用 OpenTelemetry 插樁

事後再加 instrumentation 等於要動每個服務。把 OpenTelemetry auto-instrumentation 寫進 base container image、設好 GCP exporter，新服務都會自動有 metric 與 trace。

一個服務、一張儀表板、四個黃金訊號

每個服務擁有一張儀表板，渲染流量（每秒請求數）、錯誤（錯誤率%）、延遲（p50、p95、p99）與飽和度（CPU、記憶體、佇列深度）。其他儀表板可以做深掘上下文，但黃金訊號那張是值班登入頁。

先定 SLO 再設警示

先定義 SLO，再從燒速衍生警示。反過來（先設警示後補 SLO）會做出不一致的門檻與警示疲勞。

每個警示都要寫文件

成熟維運中 documentation Markdown 欄位不是可選的。包含症狀、影響、診斷用的 MQL 查詢、rollback 指令與升級路徑。

每季測試 pager 一次

每季一次，從 production channel chain 發送測試警示，確認 PagerDuty 升級流程通、runbook 連結能解析、值班工程師 5 分鐘內找得到 rollback 指令。未經測試的事件回應只是「對 vendor 的信心」假裝成「真實能力」。

考試技巧

PCD 考題對 Cloud Monitoring 與 Trace 反覆套用一組固定 pattern。

Pattern：微服務分散式追蹤

題目提到「微服務架構的延遲」或「跨服務瓶頸」，答案是 Cloud Trace 加 OpenTelemetry instrumentation，不是 Cloud Logging、也不是 Cloud Profiler。

Pattern：程式碼級 CPU 熱點

題目提到「哪個函式吃掉最多 CPU」或「低效程式碼路徑」，答案是 Cloud Profiler，不是 Trace。

Pattern：預測慢燒故障

題目說「磁碟還剩幾小時會滿」或「在系統壞之前發警示」，答案是 forecast alerting condition，不是靜態 threshold。

Pattern：跨專案可視性

題目問「如何在一個儀表板看 50 個專案的指標」，答案是 Metrics Scope 加 50 個 monitored project，不是 federated dashboard、也不是匯出 BigQuery。

Pattern：自訂 application 指標

題目問如何把業務 KPI（訂單、營收、佇列深度）送進 Cloud Monitoring，答案是 OpenTelemetry custom metric，不是 Cloud Logging structured log、也不是 BigQuery streaming insert。

真實情境：電商結帳延遲

設想一個 Cloud Run 結帳服務，/checkout endpoint 會呼叫商品庫存（Cloud Run）、第三方付款授權與 Spanner 訂單寫入。週二某次部署後 p95 延遲從 280 ms 上升到 720 ms，但沒有錯誤率警示 fire。

值班工程師打開 Cloud Trace 延遲報告，選「自部署起」對「前 24 小時」，看到庫存 RPC 的 p95 從 40 ms 跳到 460 ms。鑽進一筆慢 trace，發現庫存內部某個 Spanner 查詢現在掃 12 個 partition 而不是 1 個。Cloud Profiler 比對兩次部署的 diff 視圖，確認是新加的 LIKE '%term%' 查詢繞過了複合索引。修一行查詢、30 分鐘內部署完成。

沒有 Trace，團隊得花好幾小時猜哪個微服務退化。沒有 Profiler，他們會知道庫存服務變慢但不知道為什麼。沒有 MQL latency SLO，要等到客戶投訴才會被注意到。

常見問題（FAQ）

Cloud Trace span 的保留期是多久？

Cloud Trace span 保留 30 天。產品本身沒有延長保留的選項。若需要 30 天之後的歷史延遲分析，要用 Trace API 加排程 Cloud Function 匯出到 BigQuery，或依賴 latency 報告的預先聚合指標——這些 Cloud Monitoring 會保留 24 個月。

Cloud Monitoring 和 Cloud Logging 差在哪？

Cloud Monitoring 儲存數值時序指標並執行警示。Cloud Logging 儲存應用程式與基礎設施的文字或 JSON log 條目。Logging 支援 log-based metric 把 log 欄位轉成數字，再流入 Monitoring。「請求數、有多慢」找 Monitoring；「這個請求裡到底發生什麼」找 Logging。

如何把自訂應用程式指標送進 Cloud Monitoring？

推薦路徑是 OpenTelemetry SDK 搭配 GCP exporter。在 Meter 上定義 Counter 或 Histogram 工具，從程式碼遞增，exporter 會把它 flush 成 workload.googleapis.com/your_metric_name。另一條路是直接打 monitoring.googleapis.com/v3/projects/PROJECT/timeSeries:create REST API，但這條囉嗦、無法移植到其他 backend。

單一 Alerting Policy 能通知多個 channel 嗎？

可以。一個 Alerting Policy 可掛任意數量的 notification channel。事件開出時所有 channel 並行接通知。常見模式是依嚴重度分流：P1 通知 PagerDuty 加 Slack incident channel；P2 只通知 Slack。

Uptime Check 和 Synthetic Monitor 差在哪？

Uptime check 是無狀態 HTTP、HTTPS、TCP 或 ICMP 探測，每 1 到 15 分鐘從六個固定全球地點 fire，無法做多步驟流程。Synthetic monitor 跑 Node.js 或 Python 腳本（典型 Puppeteer 或 Playwright），可走完登入、填表單、驗證步驟，適合端到端測試關鍵使用者流程。

Cloud Profiler 和 Cloud Trace 怎麼分？

Cloud Trace 量測服務之間的延遲，告訴你哪個 RPC 慢。Cloud Profiler 量測單一程序內部的 CPU、heap、contention，告訴你哪個函式慢。Trace 回答「哪個微服務退化了」；Profiler 回答「那個服務裡哪行程式碼退化了」。

Cloud Monitoring 的 Workspace 被什麼取代？

Metrics Scope。概念完全一樣：一個 scoping project 匯整最多 375 個 monitored project 的指標，給維運團隊單一可觀測介面。改名發生在 2022，舊 API 裡的「Workspace」字眼仍可運作但已棄用。

如何避免 Cloud Trace 因為 span 太多燒爆預算？

把 OpenTelemetry sampler 設為 ParentBased(TraceIdRatioBased(0.01))，1% 取樣。事件除錯時可用 feature flag 或 Cloud Run 環境變數臨時調高，事後再降回 1%。1000 RPS 的服務開 AlwaysOn 取樣，光 span 攝取就會超過每月 $500。

相關章節

• Cloud Logging 與 Error Reporting — 指標可觀測性的搭檔，log 與例外聚合。
• 雲端原生設計模式 — 為什麼黃金訊號和 SLO 在微服務架構中重要的上下文。
• 雲端環境測試 — Synthetic monitor 作為持續測試的延伸。

延伸閱讀

• Cloud Monitoring documentation
• Cloud Trace documentation
• Cloud Profiler documentation
• Monitoring Query Language (MQL) reference
• Service monitoring 與 SLO
• OpenTelemetry GCP exporters