GCP 監控與日誌入門：用 Monitoring 和 Logging 找出問題

服務上線後，光知道它「正在執行」還不夠。CPU 是否持續偏高？最近的錯誤從哪個版本開始？凌晨的存取失敗是使用者操作錯誤，還是權限設定有問題？

這些問題都屬於可觀測性（Observability）的範圍。在 Google Cloud 裡，Cloud Monitoring 主要處理指標、圖表與告警，Cloud Logging 則保存並查詢事件紀錄。遇到故障時，通常會在兩邊來回比對，而不是只看其中一個畫面。

兩者都屬於 GCP 的可觀測性工具套件（Google Cloud Observability），這套件下還有幾個核心服務：

表格超出欄寬時，可左右捲動；鍵盤可聚焦表格後用左右方向鍵查看。

舊教材裡的「Stackdriver」是這套工具以前的名稱。現在的文件使用 Cloud Monitoring、Cloud Logging 或 Google Cloud Observability。

這篇會先用 Monitoring 查看指標、建立 Dashboard、告警與 Uptime Check，再到 Logging 查詢和路由日誌。最後把 Ops Agent、Log-based Metric 和其他可觀測性工具放回同一套排錯流程裡。

一、先用 Cloud Monitoring 看系統狀態

1.1 什麼是 Cloud Monitoring？

Cloud Monitoring 會接收 Google Cloud 服務與應用程式送出的時間序列資料，常見用途包括：

• 在 Dashboard 上即時視覺化系統狀態
• 設定告警規則，在指標超出閾值時通知你
• 執行 Uptime Check 確認服務持續可用

許多 Google Cloud 服務會自動寫入原生指標。例如建立 VM 後，不必先安裝 Agent 就能看到 Hypervisor 觀測到的 CPU、網路與磁碟資料。不過 Guest OS 內部的記憶體和程序狀態需要另外收集。

1.2 指標的三種類型

在 Cloud Monitoring 中，所有指標都屬於以下三種類型之一：

表格超出欄寬時，可左右捲動；鍵盤可聚焦表格後用左右方向鍵查看。

設定圖表或告警前先確認 Metric Kind。Gauge 可以直接看當下數值；Delta 和 Cumulative 通常還需要搭配對齊區間與速率轉換，才不會把累積值誤當成瞬間流量。

1.3 Compute Engine 的可用指標

以下是 Compute Engine VM 預設提供的指標：

表格超出欄寬時，可左右捲動；鍵盤可聚焦表格後用左右方向鍵查看。

容易混淆的是記憶體：Compute Engine 看得到 VM 配置了多少記憶體，但不知道作業系統目前用了多少。後者要由 VM 裡的 Ops Agent 回報。

1.4 安裝 Ops Agent

# 方法 1：登入 VM 後安裝
curl -sSO https://dl.google.com/cloudagents/add-google-cloud-ops-agent-repo.sh
sudo bash add-google-cloud-ops-agent-repo.sh --also-install

# 方法 2：透過 Agent Policy 管理一批 VM
# Console 做法：建立 VM 時勾選「Install Ops Agent for Monitoring and Logging」
#   → VM Manager 會建立 Ops Agent OS policy（設定 enable-osconfig metadata label）自動安裝並維護 Ops Agent

# gcloud 做法：用 Agent Policy 批次治理某個 Zone 內符合標籤的 VM
# （GA 版以 YAML 描述政策且以 Zone 為單位；官方建議能用 GA 就不要再用舊的 beta 版 --agent-rules 寫法）
cat > ops-agent-policy.yaml <<'EOF'
agentsRule:
  packageState: installed
  version: latest
instanceFilter:
  inclusionLabels:
  - labels:
      env: prod
EOF
gcloud compute instances ops-agents policies create ops-agents-policy-prod \
    --zone=asia-east1-a \
    --file=ops-agent-policy.yaml

舊教材常見的 google-monitoring-enable 與 google-logging-enable metadata 對應 Legacy Agent，不是 Ops Agent。新環境應以 Ops Agent 的安裝流程或 Agent Policy 管理。

安裝完成後，先確認 Agent 服務正常，再到 Metrics Explorer 檢查 agent.googleapis.com 開頭的資料是否持續進來。

flowchart TB
  NEED["先定義想回答的<br/>營運問題"] --> SIGNAL{"需要觀測哪一類訊號？"}
  SIGNAL -->|"GCP 資源的 CPU、網路、磁碟等"| NATIVE["使用服務原生指標<br/>通常自動送入 Monitoring"]
  SIGNAL -->|"VM 內的記憶體、程序與應用日誌"| AGENT["安裝並設定 Ops Agent"]
  SIGNAL -->|"訂單量、佇列深度等應用業務數值"| CUSTOM["由應用程式送出<br/>自訂指標"]
  SIGNAL -->|"只有日誌裡才看得到的事件"| LOG["建立 Log-based Metric<br/>把符合條件的日誌轉成指標"]
  NATIVE --> MONITOR["在 Cloud Monitoring<br/>建立 Dashboard 或 Alert"]
  AGENT --> MONITOR
  CUSTOM --> MONITOR
  LOG --> MONITOR
  MONITOR --> VERIFY["確認資料持續到達、標籤可分組<br/>且頻率與成本符合需求"]

1.5 建立自訂 Dashboard

GCP Console 為每個服務都附了預設 Dashboard，不過你也可以自己做一個：

在 Console 裡可以這樣建立：

1. 前往 Cloud Monitoring → Dashboards → Create Dashboard
2. 為 Dashboard 命名（例如：「生產環境總覽」）
3. 點選 Add Widget 新增圖表：
   • Line Chart：適合顯示趨勢（CPU 隨時間變化）
   • Gauge：適合顯示當前狀態（目前 CPU 是幾 %）
   • Scorecard：大數字顯示單一關鍵指標
   • Heatmap：適合顯示延遲分布
4. 選擇指標來源（例如：compute.googleapis.com/instance/cpu/utilization）
5. 設定圖表維度（按 VM 名稱、Zone 分組等）

如果要直接查 Monitoring API：

# 列出所有可用指標 descriptor（透過 Monitoring API，搜尋 cpu 相關）
# gcloud 沒有對應的子指令，需直接呼叫 Monitoring API
PROJECT_ID=$(gcloud config get-value project)
curl -s -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  "https://monitoring.googleapis.com/v3/projects/${PROJECT_ID}/metricDescriptors?filter=metric.type%3D%22compute.googleapis.com/instance/cpu/utilization%22" \
  | jq -r '.metricDescriptors[].type'

1.6 設定 Alerting Policy（告警規則）

告警規則由三個部分組成：

Alerting Policy
    ├── Condition（什麼條件觸發告警？）
    ├── Notification Channel（通知誰？用什麼方式？）
    └── Documentation（告警說明，可附上 Runbook 連結）

以下用「CPU 使用率持續高於 80%」示範設定方式。

在 Console 裡：

1. Cloud Monitoring → Alerting → Create Policy
2. Select a metric：compute.googleapis.com/instance/cpu/utilization
3. Configure trigger：
   • Condition type: Threshold
   • Alert trigger: Any time series violates
   • Threshold value: 0.8（即 80%）
   • Retest window（在 Advanced options 裡，API 欄位為 duration）: 1 min（持續 1 分鐘才觸發）
4. Configure notifications：新增 Email 通知頻道
5. 設定告警名稱並儲存

也可以用 gcloud 管理通知頻道與 Policy：

# 列出現有的告警政策
gcloud monitoring policies list

# 建立通知頻道（Email）
gcloud beta monitoring channels create \
    --display-name="Team Email" \
    --type=email \
    --channel-labels=email_address=team@yourcompany.com

# 建立告警政策（使用 JSON 設定）
gcloud monitoring policies create \
    --policy-from-file=alerting-policy.json

常見通知頻道：

表格超出欄寬時，可左右捲動；鍵盤可聚焦表格後用左右方向鍵查看。

flowchart TB
  subgraph DETECT["偵測異常"]
    direction LR
    SIGNAL["持續收到<br/>指標時間序列"] --> EVAL["依聚合、閾值與<br/>比較運算評估"]
    EVAL --> WINDOW{"Condition 是否持續違反<br/>達到設定的 Duration？"}
  end
  WINDOW -->|"否"| OBSERVE["正常或短暫尖峰<br/>維持監控"]
  WINDOW -->|"是"| INCIDENT["開啟 Incident<br/>附上 Runbook 文件"]
  subgraph RESPOND["通知、處理與恢復確認"]
    direction LR
    INCIDENT --> NOTIFY["通知 Email、Slack、PagerDuty<br/>或 Webhook"]
    NOTIFY --> ACK["依 Runbook<br/>調查與修復"]
    ACK --> RECOVER{"指標是否恢復<br/>且不再違反條件？"}
  end
  RECOVER -->|"否"| CONTINUE["事件維持開啟<br/>繼續處理"]
  RECOVER -->|"是"| CLOSE["關閉 Incident<br/>記錄原因與後續行動"]

1.7 Uptime Check：自動監控服務可用性

Uptime Check 會從指定區域定期送出 HTTP、HTTPS 或 TCP 請求，確認服務是否能從外部抵達。它適合回答「入口還通不通」，但不能取代應用程式內部的健康指標。

建立 Uptime Check：

# 透過 Console：Cloud Monitoring → Uptime checks → Create Uptime Check
# 設定：
# - Protocol: HTTPS
# - Resource type: URL
# - Hostname: yourdomain.com
# - Path: /health
# - Check frequency: 1 minute
# - Locations: 依使用者所在地與成本需求選擇

Uptime Check 會按「目標數量 × 執行頻率 × 執行區域」累計次數。一個 Check 若從三個區域執行，每輪就會算三次。官方目前提供每個 Project 每月 100 萬次免費額度，超出部分則計入該 Project 所屬的 Billing Account；價格可能調整，建立大量高頻 Check 前要再看一次定價頁。

建立 Check 後還要搭配 Alerting Policy 和通知頻道，否則失敗只會留在監控介面，不會主動找到值班人員。

二、再用 Cloud Logging 還原發生過的事

2.1 什麼是 Cloud Logging？

Cloud Logging 接收 Google Cloud 服務、應用程式和基礎設施產生的日誌。你可以依時間、資源與 Severity 查詢，也能把指定日誌路由到其他目的地或轉成指標。

Cloud Audit Logs 常見的四種類型如下：

表格超出欄寬時，可左右捲動；鍵盤可聚焦表格後用左右方向鍵查看。

2.2 哪些稽核日誌會自動產生？

表格超出欄寬時，可左右捲動；鍵盤可聚焦表格後用左右方向鍵查看。

# 查詢 Admin Activity 稽核日誌（誰做了什麼操作）
gcloud logging read 'logName="projects/my-project/logs/cloudaudit.googleapis.com%2Factivity"' \
  --limit=20 --format=json

# 查詢 Data Access 日誌（誰讀取了什麼資料）
gcloud logging read 'logName="projects/my-project/logs/cloudaudit.googleapis.com%2Fdata_access"' \
  --limit=10

多數服務的 Data Access 日誌需要另外啟用：

# 在 IAM 政策中啟用 Data Access 日誌
# Console → IAM & Admin → Audit Logs → 選擇服務 → 勾選 Data Read / Data Write

如果要追查「誰刪除了 VM」，應查 Admin Activity；若要查「誰讀取了某個物件」，才是 Data Access。後者通常要事先啟用，無法在事件發生後補回過去未產生的紀錄。

flowchart TB
  QUESTION["先問：想追查的事件<br/>到底發生了什麼？"] --> TYPE{"事件性質是？"}
  TYPE -->|"有人建立、刪除或修改資源設定"| ADMIN["Admin Activity<br/>固定產生並存入 _Required"]
  TYPE -->|"有人讀取或寫入資源資料"| DATA["Data Access<br/>多數服務需另外啟用"]
  TYPE -->|"Google Cloud 系統自行執行變更"| SYSTEM["System Event<br/>固定產生並存入 _Required"]
  TYPE -->|"請求被安全政策拒絕"| DENIED["Policy Denied<br/>預設產生並存入 _Default"]
  ADMIN --> QUERY["在 Log Explorer 或 gcloud<br/>依 logName、資源與時間查詢"]
  DATA --> ENABLE{"目標服務的 Data Access<br/>是否已事先啟用？"}
  ENABLE -->|"是"| QUERY
  ENABLE -->|"否"| GAP["無法回補過去紀錄<br/>先評估資料量與成本後啟用"]
  SYSTEM --> QUERY
  DENIED --> QUERY

2.3 日誌保留期限

日誌保留期限是按照日誌 Bucket而不是日誌類型來計算的：

表格超出欄寬時，可左右捲動；鍵盤可聚焦表格後用左右方向鍵查看。

2.4 Logs Explorer：搜尋與分析日誌

Logs Explorer 是 Cloud Logging 的查詢介面。剛開始可以先用資源類型、Severity 和時間範圍縮小資料，再加入 Payload 欄位找特定錯誤。

幾個常用查詢：

# 查看特定資源類型的日誌
resource.type="gce_instance"

# 查看特定嚴重等級以上的日誌
severity >= "ERROR"

# 同時過濾資源類型和嚴重等級
resource.type="gce_instance" AND severity >= "WARNING"

# 查看特定 VM 的日誌
resource.type="gce_instance" AND
resource.labels.instance_id="1234567890"

# 查看 Cloud Run 服務的日誌
resource.type="cloud_run_revision"

# 搜尋包含特定文字的日誌
textPayload:"error connecting to database"

# 查看特定時間範圍（前一小時）
timestamp >= "2026-03-11T10:00:00Z" AND
timestamp <= "2026-03-11T11:00:00Z"

嚴重等級（Severity）由低到高：

DEBUG → INFO → NOTICE → WARNING → ERROR → CRITICAL → ALERT → EMERGENCY

2.5 gcloud 查詢日誌

# 查詢 Compute Engine 最新 10 筆日誌
gcloud logging read "resource.type=gce_instance" --limit=10

# 查詢 ERROR 以上等級的日誌
gcloud logging read "severity>=ERROR" \
    --limit=20 \
    --format=json

# 列出專案中所有的 Log 名稱
gcloud logging logs list

# 查詢特定 Log 的內容
gcloud logging read 'logName="projects/my-project/logs/cloudaudit.googleapis.com%2Factivity"' \
    --limit=5

2.6 Log Sink：日誌路由與匯出

Log Router 會依 Sink 的 Filter 把日誌送往指定目的地。常見用途包括長期保存、SQL 分析、串接 SIEM，或集中多個 Project 的日誌。

表格超出欄寬時，可左右捲動；鍵盤可聚焦表格後用左右方向鍵查看。

建立 Log Sink（匯出到 BigQuery）：

# 1. 建立 BigQuery Dataset
bq mk --location=asia-east1 my_logs_dataset

# 2. 建立 Log Sink
gcloud logging sinks create my-bigquery-sink \
    bigquery.googleapis.com/projects/my-project/datasets/my_logs_dataset \
    --log-filter='resource.type="gce_instance" AND severity>=WARNING'

# 3. 查看 Sink 的 Service Account（需要授予 BigQuery 寫入權限）
gcloud logging sinks describe my-bigquery-sink

# 4. 授予 Sink 的 SA 寫入 BigQuery 的權限
gcloud projects add-iam-policy-binding my-project \
    --member="serviceAccount:SINK_WRITER_IDENTITY" \
    --role="roles/bigquery.dataEditor"

建立 Log Sink（封存到 Cloud Storage）：

# 建立 GCS Bucket（舊寫法 gsutil mb -l asia-east1 gs://... 官方已不建議）
gcloud storage buckets create gs://my-logs-archive-bucket --location=asia-east1

# 建立 Log Sink
gcloud logging sinks create my-gcs-sink \
    storage.googleapis.com/my-logs-archive-bucket \
    --log-filter='resource.type="gce_instance"'

如果要集中分析稽核日誌，Filter 可以鎖定 cloudaudit.googleapis.com：

# 把所有稽核日誌匯出到 BigQuery 做分析
gcloud logging sinks create audit-to-bq \
  bigquery.googleapis.com/projects/my-project/datasets/audit_logs \
  --log-filter='logName:"cloudaudit.googleapis.com"'

flowchart TB
  START["先用 Log Filter 定義<br/>哪些日誌需要路由"] --> GOAL{"匯出後最主要的用途是？"}
  GOAL -->|"長期保存並用 SQL 分析"| BQ["BigQuery Dataset"]
  GOAL -->|"低成本封存與生命週期管理"| GCS["Cloud Storage Bucket"]
  GOAL -->|"即時送往 SIEM、Splunk 或自動化流程"| PUBSUB["Pub/Sub Topic"]
  GOAL -->|"跨專案集中查詢與治理"| BUCKET["其他專案或集中式<br/>Cloud Logging Bucket"]
  BQ --> WRITER["取得 Sink Writer Identity<br/>授予目的地所需的最小寫入權限"]
  GCS --> WRITER
  PUBSUB --> WRITER
  BUCKET --> WRITER
  WRITER --> TEST["產生測試日誌並確認<br/>目的地收到符合 Filter 的資料"]
  TEST --> REVIEW["監控用量、失敗與成本<br/>定期調整 Filter 和保留策略"]

2.7 Log-based Metrics：從日誌建立指標

如果想追蹤某類日誌出現的頻率，或從 Payload 提取延遲等數值，可以建立 Log-based Metric，再交給 Monitoring 畫圖或告警。

使用者自訂的 Log-based Metric 主要有兩類：

• Counter：計算符合條件的日誌條目數量（每分鐘幾筆錯誤？）
• Distribution：從日誌中提取數值分布（API 回應時間分布）

建立 Log-based Counter（計算 HTTP 500 錯誤次數）：

gcloud logging metrics create http-500-errors \
    --description="Count of HTTP 500 errors" \
    --log-filter='resource.type="gce_instance" AND
    jsonPayload.statusCode=500'

建立後，Cloud Logging 只會從之後收到且符合 Filter 的日誌產生資料點，不會回頭處理舊日誌。接著就能在 Monitoring 裡把它放進圖表或 Alerting Policy。

2.8 Log-based Alerting

如果需求只是「某種日誌一出現就通知」，也可以建立 Log-based Alert，不必先做 Metric：

Cloud Logging → Logs Explorer → 查詢結果工具列的 Actions → Create log alert

設定觸發條件：「當 severity=CRITICAL AND resource.type=gce_instance 的日誌出現時，每 5 分鐘最多通知一次」

三、其他可觀測性工具各自看什麼？

Monitoring 和 Logging 通常是起點。問題進到請求路徑、程式效能或例外彙整時，再搭配以下工具。

3.1 Cloud Trace：分散式追蹤

一個請求若經過多個服務，只有總延遲很難判斷慢在哪裡。Cloud Trace 會以 Trace 和 Span 呈現請求路徑與各階段耗時。

適用場景：

• 找出哪個服務造成整體延遲高
• 追蹤一個用戶請求在各服務間的流轉路徑

應用程式可以透過 OpenTelemetry SDK 或相容的收集流程送出 Trace。導入時也要把 Trace ID 放進結構化日誌，之後才能在 Trace 和 Logging 之間交叉查找。

3.2 Cloud Profiler：程式碼效能分析

Cloud Profiler 會持續取樣應用程式的 CPU 與記憶體使用狀況，並把熱點對應到程式碼。是否適用仍要看語言、執行環境與 Agent 支援狀況。

支援語言：Go、Java、Node.js、Python

它適合處理「服務長期偏慢，但指標和單次 Trace 還看不出是哪段程式碼消耗資源」的問題。

3.3 Error Reporting：應用程式錯誤彙整

Error Reporting 會把內容相近的應用程式例外分組，方便查看發生次數、時間與受影響版本，不必逐筆翻找相同 Stack Trace。

支援平台：App Engine、Cloud Run functions（原 Cloud Functions）、Cloud Run、Compute Engine、GKE

注意：行動應用程式的 Crash 監控建議使用 Firebase Crashlytics。

flowchart TB
  START["服務出現異常<br/>先描述想回答的問題"] --> QUESTION{"目前最需要知道什麼？"}
  QUESTION -->|"何時開始、影響多大、是否仍在發生"| MONITOR["Cloud Monitoring<br/>看 Metrics、Dashboard 與 Incident"]
  QUESTION -->|"異常當下發生了哪些事件"| LOGGING["Cloud Logging<br/>查時間、資源、severity 與錯誤內容"]
  QUESTION -->|"單一請求跨多個服務慢在哪一站"| TRACE["Cloud Trace<br/>沿 Trace 找延遲 Span"]
  QUESTION -->|"哪段程式碼長期消耗 CPU 或記憶體"| PROFILER["Cloud Profiler<br/>找程式碼層級熱點"]
  QUESTION -->|"哪些 Exception 重複最多、影響誰"| ERROR["Error Reporting<br/>彙整與分組應用程式錯誤"]
  MONITOR --> CORRELATE["用共同的時間、資源與請求 ID<br/>交叉比對其他訊號"]
  LOGGING --> CORRELATE
  TRACE --> CORRELATE
  PROFILER --> CORRELATE
  ERROR --> CORRELATE
  CORRELATE --> FIX["形成根因假設、修復<br/>並用 Metrics 驗證是否恢復"]

四、費用主要從哪裡來？

以下是目前常見的計費項目，實際價格仍以官方頁面和帳務報表為準。

Cloud Logging

表格超出欄寬時，可左右捲動；鍵盤可聚焦表格後用左右方向鍵查看。

Cloud Monitoring

表格超出欄寬時，可左右捲動；鍵盤可聚焦表格後用左右方向鍵查看。

最容易低估的是標籤基數、日誌量與 Uptime Check 的執行區域。正式上線前可以先用小流量觀察一週，再依實際用量調整 Filter、保留期與採樣方式。最新數字請查看 Google Cloud Observability 定價頁。

五、用幾個情境檢查觀念

準備 ACE 時，可以用下面幾個情境確認自己是否分得清資料來源、告警與日誌類型。

類型 1：指標選擇

題目：你想監控 VM 的記憶體使用率，但在 Cloud Monitoring 中找不到記憶體相關指標。最可能的原因是？

• Cloud Monitoring 支援記憶體指標，但 Compute Engine 不會從 Hypervisor 取得 Guest OS 記憶體使用率
• 應先確認 VM 是否已安裝並正常執行 Ops Agent

類型 2：日誌匯出

題目：你需要將 GCP 日誌長期保存並用 SQL 分析。可以怎麼做？

• 建立 Log Sink，把符合條件的日誌路由到 BigQuery
• 若只需要在 Logging 裡分析，也要評估 Log Bucket、Log Analytics 與保留期是否更合適

類型 3：告警設定

題目：你的 Web 服務需要在回應時間超過 2 秒時通知工程師。應使用哪個工具？

• 使用 Cloud Monitoring Alerting Policy，對相應延遲指標設定閾值與持續時間

類型 4：日誌類型

題目：你想查看過去 7 天內誰修改了你的防火牆規則。應查看哪種日誌？

• System Event 記錄平台或服務代理執行的變更
• Data Access 記錄資料或設定的讀取與資料操作
• 人員修改防火牆規則應查 Admin Activity

類型 5：保留期限

題目：Admin Activity 日誌的預設保留期是多少天？

• 來源資源 _Required 中的 Admin Activity 原件固定保留 400 天，不能調整該 bucket 的保留期。
• 若需要 7 年等較長保留，可另外路由副本到自訂 Logging bucket 或其他支援目的地，設定保留、讀取權限與費用；不是把 _Required 本身改成 7 年。細節見 Logging bucket 文件。

六、把監控與日誌串成一個練習

以下用一台 Compute Engine VM 示範基本流程。正式環境還要補上權限、變更審查、Runbook 與告警測試。

# 步驟 1：安裝 Ops Agent，收集 Guest OS 指標
# 在 VM 內執行：
curl -sSO https://dl.google.com/cloudagents/add-google-cloud-ops-agent-repo.sh
sudo bash add-google-cloud-ops-agent-repo.sh --also-install

# 確認 Ops Agent 正在執行
sudo systemctl status google-cloud-ops-agent

# 步驟 2：設定 Uptime Check（Console 操作）
# Cloud Monitoring → Uptime checks → Create
# 填入: HTTPS, yourdomain.com, /health, Check every 1 minute

# 步驟 3：建立告警政策（CPU > 80%）
# Cloud Monitoring → Alerting → Create Policy
# Metric: compute.googleapis.com/instance/cpu/utilization
# Threshold: 0.8, Retest window: 1 min
# Notification: Email to your team

# 步驟 4：建立 Log Sink（匯出 ERROR 日誌到 BigQuery）
gcloud logging sinks create production-errors-sink \
    bigquery.googleapis.com/projects/my-project/datasets/production_logs \
    --log-filter='resource.type="gce_instance" AND severity>=ERROR'

# 步驟 5：查詢日誌，確認 Filter 能找到預期資料
gcloud logging read \
    'resource.type="gce_instance" AND severity>=ERROR' \
    --limit=5 \
    --format=table

七、排錯時怎麼使用這些工具？

Cloud Monitoring 適合先確認異常從何時開始、影響哪些資源，以及是否仍在發生：

表格超出欄寬時，可左右捲動；鍵盤可聚焦表格後用左右方向鍵查看。

接著用 Cloud Logging 對齊同一段時間與資源，查看部署、權限變更和應用錯誤：

表格超出欄寬時，可左右捲動；鍵盤可聚焦表格後用左右方向鍵查看。

系列文章連結

• 上一篇：GCP-105：看懂身分、角色與權限繼承
• 下一篇：GCP-107：Cloud Storage 物件儲存
• 延伸閱讀：ACE-205：GCP 安全架構與合規

延伸閱讀

• Cloud Monitoring 官方文件
• Cloud Logging 官方文件
• Logging Query Language 語法參考
• Log Sinks 設定指南
• Ops Agent 安裝指南
• Cloud Monitoring 定價

監控的價值不在於圖表數量，而在於能不能縮短「發現異常、找到證據、完成修復、確認恢復」這段時間。先替一個真正需要維護的服務建立少量指標與告警，再根據實際事件補強，通常比一開始做滿整個 Dashboard 更容易維持。