Google Cloud 維運套件

什麼是 Google Cloud Operations Suite？

Google Cloud Operations Suite — 目前正式品牌名稱為 Google Cloud Observability — 是每個 Google Cloud 專案內建的統一遙測、監控與故障排除平台。它的前身是 Stackdriver，一家 Google 於 2014 年收購的獨立監控公司。收購後先更名為 Stackdriver，再改名為 Cloud Operations Suite，最終定名為 Google Cloud Observability。在 Cloud Digital Leader（CDL）考試中，這三個名稱均指同一套產品家族：Cloud Logging、Cloud Monitoring、Cloud Trace、Cloud Profiler 與 Error Reporting。

Google Cloud Operations Suite 的目的，是回答每位企業領導人、SRE 工程師與開發人員每天都在問的核心問題：「我的服務健康嗎？如果不健康，原因是什麼？」 沒有可觀測性，雲端工作負載就是一個黑盒子。您只能看到帳單是否上升，卻無從得知昨天的延遲飆升是否影響了顧客、正式環境是否正在醞釀記憶體洩漏，或錯誤率是否正朝著 SLO 違規的邊緣爬去。

Google Cloud Operations Suite 的設計同時照顧到企業領導人視角與工程師視角。CDL 考試情境會問到：「哪個 Google Cloud 產品提供集中式 log 儲存，並可選擇性長期保留至 BigQuery？」或「值班團隊需要在錯誤率超過 1% 時收到通知，哪個產品用於設定警示政策？」本章節將每個常見的 CDL 情境對應到正確的 Google Cloud Observability 產品，說明可觀測性三大支柱（log、指標、追蹤），並以台灣人熟悉的具體類比加以詮釋。

讀完本章節，您將了解 Google Cloud Operations Suite 如何跨 Compute Engine、GKE 與 Cloud Run 等運算服務收集遙測資料、警示政策如何將事件路由至值班頻道、log sink 如何供應合規封存，以及 SRE 團隊如何利用這套工具推動服務等級目標。您也將理解 Google Cloud Operations Suite 的成本控制槓桿 — 因為大規模使用 Cloud Logging 往往是實務上最常被低估的 Google Cloud 費用項目之一。

可觀測性的三大支柱

現代可觀測性建立在遙測的三大支柱上：log、指標與追蹤。每根支柱回答不同的問題，每根支柱對應 Google Cloud Operations Suite 中的不同產品。

支柱一 — Log（發生了什麼？）

Log 是帶有時間戳記的結構化（或非結構化）離散事件紀錄。一筆 log 說的是：「14:32:11 UTC，使用者 [email protected] 以 HTTP 401 從 IP 203.0.113.42 第三次登入失敗。」Log 是鑑識紀錄 — 當事情出錯時，您從 log 中重建究竟發生了什麼。在 Google Cloud Operations Suite 中，log 存放於 Cloud Logging。

支柱二 — 指標（頻率與規模？）

指標是隨時間聚合的數值量測。一個指標說的是：「過去一分鐘內，這項服務收到 1,247 個請求，第 95 百分位延遲為 320 ms，出現 12 個 HTTP 500 回應。」指標是儀表板與警報層 — 它們以整體視角告訴您系統是否健康，並在閾值突破時觸發警示。在 Google Cloud Operations Suite 中，指標存放於 Cloud Monitoring。

支柱三 — 追蹤（請求去了哪裡？）

追蹤跟隨單一請求在分散式系統中的完整旅程。一條追蹤說的是：「請求 abc123 進入 API 閘道，呼叫驗證服務（15 ms），再呼叫目錄服務（40 ms），然後執行三次資料庫查詢（共 210 ms），最終在 295 ms 後回應給使用者。」追蹤是分散式時間軸 — 它告訴您哪個下游呼叫是瓶頸。在 Google Cloud Operations Suite 中，追蹤存放於 Cloud Trace。

白話文解釋

可觀測性聽起來抽象，直到您把它對應到具體可感知的場景。Google Cloud Operations Suite 其實不只是一項「工具」 — 它是您服務的指揮中控室，擁有儀表板、警報、紀錄機和應急手冊。以下三個類比從不同角度捕捉同一個核心概念，每個類比各自突顯可觀測性的不同面向。

類比一 — 加護病房的監護儀器

想像一位病患躺在加護病房的病床上。床邊有多台器材從未停止記錄：心率監視器每秒發出嗶嗶聲，血壓計每十五分鐘自動充氣一次，血氧夾在病患指尖發出紅光，床尾的病歷表記錄每一次用藥、每一次醫師查房與每一次檢驗結果。這些器材沒有一項是可有可無的 — 少了它們，醫護人員等同於眼盲，病情惡化的病患可能在任何人察覺之前便已危及生命。

Google Cloud Observability 對您的服務扮演完全相同的角色。Cloud Monitoring 是心率監視器與血壓計 — 它全天候監視 CPU、延遲、請求數量與錯誤率，並在任何生命徵象超過警戒線時立即發出警示（傳送警報）。Cloud Logging 是床尾的病歷表 — 它紀錄每一個事件、每一筆錯誤、每一次登入嘗試，讓醫師到場時有完整的歷史紀錄可供查閱。Cloud Trace 是追蹤顯影劑在病患血管中流動的影像掃描 — 它精準顯示分散式請求流中的阻塞位置。

就如醫院不能在缺乏監護儀的情況下安全運作，Google Cloud 工作負載也不能在沒有 Google Cloud Operations Suite 的情況下安全運作。就如醫院不能為了省電而停用監護儀，您也不能為了省下 Google Cloud Operations Suite 的 log 收錄費用而關閉 log — 您只能精準篩選，保留重要的、丟棄無關緊要的。

類比二 — 工廠中控室

台中一間現代製造廠可能同時運行數百台機器：射出成型機、包裝線、輸送帶、烤漆站與品質檢驗站。中央控制室的牆上掛滿螢幕。一面螢幕顯示每條產線的即時產能數字，另一面螢幕以熱圖呈現哪些機器在運行、閒置或發生故障。門口上方的紅色旋轉燈，在任何重大警報觸發時就會開始旋轉。作業員坐在控制台前緊盯著螢幕。

Google Cloud Operations Suite 就是您的雲端中控室。Cloud Monitoring 儀表板是那面螢幕牆，即時顯示每個微服務的服務等級指標。警示政策是旋轉紅燈 — 當錯誤率超過 1%、延遲第 95 百分位跨越 500 ms、記憶體用量攀升至 90% 以上時，警報觸發並透過通知頻道路由至電子郵件、Slack、PagerDuty、SMS 或任何已設定的頻道。Cloud Logging 是作業員翻閱以調查特定警報的紙本操作 log。

中控室的比喻也很好地捕捉了可用性檢查的概念 — Google Cloud Operations Suite 可定期從全球多個地點 ping 您的公開端點，就像工廠品管人員每小時巡視廠線，親眼確認每台機器都在正常出貨。若五個 ping 地點中有三個回報失敗，工廠就真的出了問題，而不只是局部網路短暫波動。

類比三 — 飛機的黑盒子與雷達塔台

每架商用客機都攜帶兩個黑盒子：駕駛艙語音記錄器與飛行資料記錄器。它們捕捉一切 — 每個儀表讀數、每次無線電通訊、每個操作輸入。失事後，調查人員從黑盒子資料重建飛機最後幾分鐘的狀況。與此同時，雷達塔台即時追蹤空域中每架飛機的位置，引導飛機繞開惡劣天氣並警示碰撞風險。

您的 Google Cloud 工作負載需要兩者兼備。Cloud Logging 是黑盒子 — 它持久紀錄每一個事件，讓事件發生後您能執行事後分析，精準重建發生了什麼。Cloud Monitoring 是雷達塔台 — 它即時掌握機隊（服務群）中每架飛機的位置與健康狀態，並在墜機發生之前、而非之後發出警告。Cloud Trace 增添了第三個維度：單一旅客穿越多段旅程的飛行軌跡 — 從登機門到轉機航班再到行李轉盤。當一位旅客遲到，追蹤資料告訴您延誤究竟發生在安檢、跑道還是海關。

Google Cloud Operations Suite 讓一批不透明的服務，變成一家儀器完善、可觀測的航空公司。就像航空公司一樣，遙測的成本是真實存在的 — 將駕駛艙的對話錄音保存十年需要花費儲存費用 — 但「不記錄」的代價在事件發生、需要鑑識答案時，往往是災難性的。

Cloud Logging — 集中式 Log 聚合

Cloud Logging 是 Google Cloud Operations Suite 中的 log 管理服務。它自動從每個 Google Cloud 服務收錄 log 資料 — Compute Engine、GKE、Cloud Run、App Engine、Cloud Functions、Cloud SQL、負載平衡器、Cloud Storage 存取 log、稽核 log — 並統一存放於可查詢、可管理保留期限的集中式儲存庫。

Log 如何進入 Cloud Logging

• Cloud Run、Cloud Functions、App Engine： 自動擷取 log。應用程式寫入 stdout 或 stderr 的任何輸出，都會成為 Cloud Logging 的條目，無需安裝任何代理程式。
• GKE： 叢集預設執行 GKE Logging 代理程式。Pod log、系統 log 與 Kubernetes 事件，全部以叢集、命名空間與 Pod 名稱標籤串流至 Cloud Logging。
• Compute Engine： 在每台 VM 上安裝 Ops Agent（舊版 Logging Agent 與 Monitoring Agent 的統一後繼者）。Ops Agent 透過同一個頻道同時收集 log 與指標。
• 外部與混合來源： 使用 BindPlane 或 OpenTelemetry Collector，將來自地端伺服器、AWS 工作負載或第三方 SaaS 的 log 轉發至 Cloud Logging。
• 自訂應用程式 log： 使用 Cloud Logging 客戶端函式庫（Java、Python、Node.js、Go 等），撰寫帶有嚴重程度、標籤與 JSON 酬載的結構化 log 條目。

以 Log 為基礎的指標

Cloud Logging 可以從 log 內容衍生指標。例如，若您的存取 log 包含 "status":500，您可以建立一個以 log 為基礎的指標，每分鐘計算一次 500 狀態碼出現次數，然後在 Cloud Monitoring 上針對該指標建立警示。這就是團隊將非結構化作業資料轉化為結構化警報的方式。

Log Sink — 將 Log 路由至儲存目的地

Log sink 是 Cloud Logging 的路由規則，將符合條件的 log 條目複製到 Cloud Logging 以外的目的地：

• BigQuery： 用於 SQL 分析、合規報告與長期可搜尋的保留。
• Cloud Storage： 用於低成本封存（Coldline 或 Archive 級別）以及七到十年的法規保留。
• Pub/Sub： 用於即時串流至下游 SIEM（Chronicle、Splunk、Datadog）或自訂資料管線。

Log sink 讓企業得以平衡作業可搜尋性（在 Cloud Logging 中保留近期 log 以快速查詢）與符合成本效益的合規性（將所有 log 路由至 Cloud Storage 以低成本保留多年）。

Cloud Monitoring — 指標、儀表板、警示與 SLO

Cloud Monitoring 是 Google Cloud Operations Suite 中的指標與警示服務。它從每個 Google Cloud 產品收集時間序列數值資料，讓您建立自訂儀表板，並在條件違反時將警示路由至值班頻道。

內建指標

每個 Google Cloud 產品都開箱即用地提供一組系統指標：Compute Engine VM 的 CPU 與磁碟、GKE Pod 的 CPU 與記憶體、Cloud Run 的請求數量與延遲、Cloud SQL 的連線數、Pub/Sub 的積壓大小等。這些指標無需安裝或設定任何東西 — 它們自動出現在 Cloud Monitoring 中。

自訂指標

針對特定應用程式的訊號（例如：「每分鐘放棄結帳的購物車數量」），您可以使用 Cloud Monitoring API 發布自訂指標，或透過 log（以 log 為基礎的指標）衍生。

儀表板

Cloud Monitoring 儀表板是使用者可自行設定的顯示介面。您組合各種小工具 — 折線圖、熱圖、計分卡、量表 — 並排列成服務團隊或領導團隊所需的一覽視圖。儀表板可跨專案共享、嵌入事件應對手冊，或用於定期的作業審查會議。

警示政策與通知頻道

Google Cloud Operations Suite 的警示模型由三個構建單元組成：

1. 警示政策： 定義條件（例如：「Cloud Run 錯誤率連續 5 分鐘超過 1%」）以及受影響的資源與嚴重程度。
2. 通知頻道： 指定警示的傳送目的地。支援的頻道包括電子郵件、SMS、Slack、PagerDuty、Webhook、Pub/Sub、Google Chat 與 Cloud Mobile App。
3. 事件： 當政策條件觸發時，Cloud Monitoring 建立一筆事件紀錄，通知所有已設定的頻道，並追蹤該事件直到條件解除。

可用性檢查

可用性檢查是針對您公開端點的排程 HTTPS、HTTP 或 TCP 探測，從全球多個 Google Cloud 區域執行。它們告訴您亞洲、歐洲與美洲的真實使用者是否能實際連達您的服務。可用性檢查與警示政策整合，讓您在過多全球地點回報失敗時收到通知。

SLO 監控

Cloud Monitoring 為 SRE 團隊提供服務等級目標（SLO）監控。您定義一項服務，選擇服務等級指標（SLI） — 例如「延遲低於 300 ms 的請求比例」— 並設定 SLO 目標（例如：滾動 28 天視窗內達 99.9%）。Cloud Monitoring 即時追蹤錯誤預算燃燒率，並可在燃燒率威脅到 SLO 時發出警示。有關更廣泛的 SLO 與 SRE 實踐，請參閱 /en/certs/gcp/cdl/topics/devops-and-sre-principles。

Cloud Trace — 延遲分析的分散式追蹤

Cloud Trace 是 Google Cloud Operations Suite 中的分散式追蹤服務。在微服務架構中，單一使用者請求可能穿越十幾個後端服務。當請求速度緩慢時，「時間花在哪裡？」這個問題光憑 log 就很難回答。Cloud Trace 透過為每個請求標記追蹤 ID、跨服務邊界傳播該 ID（透過 HTTP 標頭），並在 Google Cloud Operations Suite UI 中重建完整的 span 樹狀結構，來解決這個問題。

追蹤的運作方式

請求路徑中的每個服務發出一個 span — 記錄該服務處理其那份請求所花費的時間，以及任何標籤（資料庫查詢、下游服務名稱、狀態碼）。各個 span 透過共享的追蹤 ID 串聯起來。最終結果是一個火焰圖，精準顯示哪個 span 是瓶頸所在。

自動插桩

• App Engine Standard： 每個請求自動追蹤。
• Cloud Run、Cloud Functions： 自動傳播追蹤 ID；安裝 OpenTelemetry SDK 以發出應用程式 span。
• GKE 與 Compute Engine： 使用 OpenTelemetry 插桩函式庫，將 span 發送至 Cloud Trace。

何時使用 Cloud Trace

• 部署後診斷延遲退化。
• 找出哪個下游呼叫是瓶頸。
• 透過消除多餘或緩慢的服務跳轉，最佳化端對端使用者體驗。

Cloud Profiler — 持續性 CPU 與記憶體效能剖析

Cloud Profiler 是 Google Cloud Operations Suite 中的永遠在線正式環境效能剖析器。傳統的效能剖析器（gperftools、pprof、async-profiler）需要開發人員連接到正在執行的程序並擷取快照，在正式環境中操作並不安全。Cloud Profiler 截然不同：它持續運行、負擔幾乎可忽略（約 1% CPU 使用率），並隨時間聚合火焰圖。

Cloud Profiler 的量測項目

• CPU 時間： 哪些函式燃燒最多 CPU？
• 堆積配置： 哪些函式配置最多記憶體？
• 競爭： 哪些鎖導致 goroutine 或執行緒等待？
• 掛鐘時間： 請求實際上端對端花費時間在哪裡？

Cloud Profiler 支援 Go、Java、Node.js 與 Python。整合只需一行代理程式安裝指令。對於管理大型機隊的 SRE 團隊，Cloud Profiler 是適當規格調整的秘密武器 — 發現 60% 的 CPU 消耗在單一低效 JSON 解析器上，修正它，基礎設施成本立即減半。

Error Reporting — 自動例外聚合

Error Reporting 是 Google Cloud Operations Suite 中的例外聚合服務。當應用程式拋出例外（Java 堆疊追蹤、Python traceback、Go panic、Node.js Error），Error Reporting 自動：

1. 從 Cloud Logging 解析堆疊追蹤。
2. 將相同的錯誤分組（相同的堆疊特徵），讓您看到每種錯誤一筆條目，而非每次發生一筆。
3. 隨時間統計發生次數，並追蹤首次出現與最後出現的時間戳記。
4. 在新的錯誤類型出現於正式環境時通知團隊。

這意味著工程師看到的是「本週 20 種不同錯誤類型，依頻率排序」，而非「200,000 筆個別堆疊追蹤」 — 將一片資訊洪流轉化為有優先順序的待辦行動清單。

Cloud Debugger 發生了什麼事？

Cloud Debugger 是 Google Cloud Operations Suite 中的一項產品，讓開發人員能在不停止程序的情況下，在正式環境程式碼中設置中斷點並擷取變數狀態。Google 已於 2023 年 5 月停止 Cloud Debugger 服務。替代策略如下：

• 使用 Error Reporting 追蹤正式環境例外。
• 使用 Cloud Logging 搭配豐富的結構化酬載，擷取除錯器原本會顯示的執行期情境。
• 使用 Cloud Trace 與 Cloud Profiler 進行效能調查。
• 使用本機除錯進行實際的中斷點工作流程。

CDL 考試題目仍可能將 Cloud Debugger 作為已停用的參考提及；認出這個名稱，記下其職責已遷移至 Cloud Logging 加上 Error Reporting，然後繼續作答即可。

各運算選項的遙測資料

不同的 Google Cloud 運算服務預設將遙測資料送入 Google Cloud Operations Suite 的方式略有差異。了解這些預設值是 CDL 考試最愛考的題型。

Cloud Run

每一行 stdout 或 stderr 輸出自動成為 Cloud Logging 條目。請求數量、請求延遲、容器執行個體數量與容器 CPU，無需任何設定即出現在 Cloud Monitoring 中。

GKE

Pod log 由 GKE Logging 代理程式擷取。Pod CPU 與記憶體由 GKE Monitoring 代理程式擷取。兩者在新叢集中預設啟用。

Compute Engine

VM 不會自動傳送應用程式 log 或詳細的系統指標。您必須在每台 VM 上安裝 Ops Agent。若未安裝 Ops Agent，您只能看到 Hypervisor 層級的 CPU、磁碟與網路指標。

App Engine、Cloud Functions

完全受管 — log、指標與追蹤均自動發出，無需代理程式。

多雲與混合環境

對於 Google Cloud 以外的工作負載（地端、AWS、Azure），部署 OpenTelemetry Collector 或 BindPlane，將遙測資料轉發至 Google Cloud Operations Suite。這就是企業在混合架構中以單一可觀測性平面管理異質環境的方式。有關底層運算選項，請參閱 /en/certs/gcp/cdl/topics/google-cloud-compute-options。

可觀測性的定價與成本最佳化

Google Cloud Operations Suite 採用各服務獨立計費的模型，並提供慷慨的免費額度 — 但免費額度在大規模使用下很快就會用盡，CDL 考試中關於成本最佳化的情境題往往聚焦於該拉哪個槓桿。

Cloud Logging 定價

• 免費額度： 每個專案每月前 50 GiB 收錄免費。
• 超出免費額度： 每額外收錄 GiB 約 0.50 美元。
• 保留： 前 30 天免費；更長的保留需額外付費，除非您 sink 至 Cloud Storage。

Cloud Monitoring 定價

• 免費額度： 所有 Google Cloud 系統指標免費。
• 自訂指標與以 log 為基礎的指標： 每月 150 MiB 免費，超出後依每 MiB 收取少量費用。
• API 讀取： 每月 100 萬次呼叫免費。

Cloud Trace、Cloud Profiler、Error Reporting

• Cloud Trace：每月前 250 萬個 span 收錄免費。
• Cloud Profiler：免費。
• Error Reporting：免費（以 Cloud Logging 作為底層儲存）。

成本控制槓桿

1. Log 排除篩選器： 在收錄時丟棄 debug 層級的 log。
2. 儲存桶保留期限分層： 對話量龐大的 log 使用較短的保留期限。
3. Sink 至 Cloud Storage： 以低成本封存 log 供合規使用，而非支付 Cloud Logging 的保留費用。
4. Cloud Trace 取樣： 對高流量服務以 1/1000 的比率取樣。

有關更廣泛的 Google Cloud 成本管理工具組，請參閱 /en/certs/gcp/cdl/topics/cost-management-tools。

Google Cloud Operations Suite 如何支援 SRE 實踐

Google Cloud Operations Suite 是 Google 推廣的**網站可靠性工程（SRE）**實踐的實作基礎。對應關係非常直接：

• SLI、SLO、錯誤預算： 在 Cloud Monitoring SLO 中定義與追蹤。
• 針對症狀而非原因的警示： 以繫結於使用者端 SLI 的 Cloud Monitoring 警示政策建置。
• 事後分析與無責任回顧： 從 Cloud Logging 的鑑識資料與 Cloud Trace 的請求時間軸驅動。
• 持續改進： 從 Cloud Profiler 火焰圖驅動，找出正式環境程式碼的熱點路徑。
• 減少例行性工作（Toil）： 透過自動化應對 Cloud Monitoring 警示政策產生之事件的手冊回應來實現。

有關 CDL 情境中 DevOps 與 SRE 原則的深入說明，請參閱 /en/certs/gcp/cdl/topics/devops-and-sre-principles。

安全性與稽核 Log

Google Cloud 在每個專案中自動產生 Cloud Audit Logs — 這是「誰在何時何地做了什麼」的不可竄改紀錄。共有四種類型：

• Admin Activity log： 永遠開啟、免費，擷取設定變更（例如：建立 VM、變更 IAM 政策）。
• Data Access log： 選擇性開啟，擷取資料讀寫（例如：誰查詢了哪個 BigQuery 資料表）。
• System Event log： 永遠開啟、免費，擷取 Google 發起的事件（例如：VM 的即時遷移）。
• Policy Denied log： 擷取被 IAM 或 VPC Service Controls 封鎖的存取嘗試。

Cloud Audit Logs 存放於 Cloud Logging，並透過 log sink 路由至 BigQuery 或 Cloud Storage 供合規保留。CDL 情境題中「監管機構要求保留五年的顧客資料存取紀錄」，對應的是 Data Access log sink 至 Cloud Storage Archive 級別。

與更廣泛 Google Cloud 生態系統的整合

Google Cloud Operations Suite 並非孤立存在 — 它與幾乎所有其他 Google Cloud 產品整合：

• IAM： 控制誰能讀取 log、設定警示與確認事件。
• BigQuery： 接收 log sink 以對作業資料進行 SQL 分析。
• Pub/Sub： 即時將 log 串流至下游系統。
• Cloud Storage： 以低廉的 Coldline 或 Archive 級別儲存長期 log 封存。
• Chronicle 與 Security Command Center： 消費 Cloud Logging 稽核資料供安全作業使用。
• Looker： 將以 log 為基礎的分析視覺化，供高層主管儀表板使用。
• VPC Service Controls： 透過在 Cloud Logging 周圍執行邊界控制，防止 log 外洩。

這種緊密整合，正是企業鮮少將 Google Cloud Operations Suite 替換為第三方 SIEM 來處理 Google 原生工作負載的原因 — 複製資料的摩擦成本，高於採用獨立工具的邊際效益。

常見問題

Stackdriver 與 Google Cloud Operations Suite 有什麼差別？

答： 它們是同一套產品家族，只是名稱不同。「Stackdriver」是最初的品牌（源自 2014 年的收購）。後更名為「Cloud Operations Suite」，現在正式品牌為「Google Cloud Observability」。三個名稱均指 Cloud Logging、Cloud Monitoring、Cloud Trace、Cloud Profiler 與 Error Reporting 的總稱。CDL 考試題目可能混用這三個名稱。

我需要安裝代理程式才能在 Cloud Run 或 App Engine 上取得可觀測性嗎？

答： 不需要。Cloud Run、Cloud Functions、App Engine Standard 與 App Engine Flexible 會自動將 log 與系統指標傳送至 Google Cloud Operations Suite。只有 Compute Engine VM 需要代理程式 — 安裝 Ops Agent 才能擷取應用程式 log 與詳細的系統指標。GKE 則會在新叢集中自動安裝 log 與監控代理程式。

警示如何路由至我的值班團隊？

答： 在 Cloud Monitoring 中建立警示政策，定義條件（例如：「錯誤率連續 5 分鐘超過 1%」）。為政策附加一個或多個通知頻道 — 支援的頻道包括電子郵件、SMS、Slack、PagerDuty、Webhook、Pub/Sub、Google Chat 與 Google Cloud 行動應用程式。條件觸發時，Cloud Monitoring 建立一筆事件並通知所有已設定的頻道。條件解除後，事件自動結案，並發送「已解決」通知。

如何將 log 保留成本控制在合理範圍內？

答： 使用三個槓桿。第一，Cloud Logging 的 log 排除篩選器在收錄時丟棄低價值條目（例如：正式環境中的 debug 層級 log、健康檢查探測）。第二，log sink 將僅用於合規的 log 路由至 Cloud Storage（Coldline 或 Archive 級別），以低成本實現多年保留，而非支付 Cloud Logging 的每 GiB 保留費率。第三，為話量龐大的工作負載設定較短的儲存桶保留期限，讓嘈雜的 log 在 7 或 14 天後過期，而稽核 log 則 sink 至長期儲存。

什麼取代了 Cloud Debugger？

答： Cloud Debugger 已於 2023 年 5 月停止服務。替代策略結合了 Cloud Logging（搭配擷取執行期情境的豐富結構化酬載）、Error Reporting（用於分組的例外追蹤）、Cloud Trace（用於分散式延遲分析）與 Cloud Profiler（用於 CPU 與記憶體效能剖析）。若需要逐步中斷點除錯，請針對測試環境使用本機 IDE 除錯器。

Google Cloud Operations Suite 能收錄來自 AWS 或地端工作負載的遙測資料嗎？

答： 可以。在來源環境部署 OpenTelemetry Collector 或 BindPlane，並設定其將 log、指標與追蹤轉發至 Google Cloud。這就是多雲與混合架構企業在異質環境中運營單一可觀測性平面的方式。Google Cloud Operations Suite 的指標與 log 模型相容於 OpenTelemetry。

總結

Google Cloud Operations Suite — 品牌名稱為 Google Cloud Observability，歷史上也稱為 Stackdriver — 是 Google Cloud 內建的統一遙測、監控與故障排除平台：

• Cloud Logging — 集中式 log 聚合、以 log 為基礎的指標，以及透過 log sink 路由至 BigQuery、Pub/Sub 或 Cloud Storage 供分析與合規保留。
• Cloud Monitoring — 系統與自訂指標、儀表板、警示政策、通知頻道、可用性檢查與 SLO 追蹤。
• Cloud Trace — 跨微服務的分散式追蹤延遲分析，以 OpenTelemetry 為基礎的自動插桩。
• Cloud Profiler — 正式環境中持續、低負擔的 CPU 與記憶體效能剖析，支援 Go、Java、Python 與 Node.js。
• Error Reporting — 從 Cloud Logging 酬載自動聚合與分組例外。

可觀測性三大支柱 — log、指標、追蹤 — 分別直接對應 Cloud Logging、Cloud Monitoring 與 Cloud Trace。Cloud Run、App Engine 與 Cloud Functions 無需安裝任何代理程式即可將遙測資料傳送至這套服務；Compute Engine 需要 Ops Agent；GKE 則自動安裝代理程式。警示模型是政策 → 通知頻道 → 事件，PagerDuty、Slack、電子郵件與 SMS 是典型的值班通知目的地。

身為 Cloud Digital Leader，您的職責是識別哪個產品解決哪種可觀測性問題、說明讓 Cloud Logging 不致預算爆炸的成本控制槓桿，並闡述這套服務如何支援現代 SRE 實踐，包括 SLO、錯誤預算與無責任事後分析。掌握這套框架，您就能有信心回答 CDL 考試中所有與可觀測性相關的題目。