Cloud Monitoring：告警与恢复确认

验证：静态检查 · 核验于 2026-09-28

适用版本: 云环境版本未实测；适用条件见正文
验证范围: 已检查文档构建、链接与脚本语法；未执行云端实验。

Console：Monitoring → Alerting / Dashboards。

常用操作#

替换为实际资源；本段不依赖 lab.env。

PROJECT_ID='REPLACE_PROJECT_ID'

gcloud monitoring policies list --project="$PROJECT_ID"

容易踩的坑#

Incident 自动 CLOSED 不证明业务恢复。 检查关闭原因及最新业务水位；持续上报 0 也不属于 metric absence。

各副本 p95 不能直接平均；按分布数据聚合后计算。

配置说明与完整示例（按需展开）

前置：Logging已创建 lab_errors。指标告诉你发生多少，日志解释具体发生什么。

创建通知与告警#

source lab.env
gcloud services enable monitoring.googleapis.com

Console → Monitoring → Alerting → Edit notification channels：添加并验证你的 Email，记录 projects/PROJECT/notificationChannels/ID。

export CHANNEL='替换为完整notificationChannels资源名'
cat > alert.json <<EOF
{
  "displayName": "lab-errors",
  "combiner": "OR",
  "enabled": true,
  "notificationChannels": ["$CHANNEL"],
  "documentation": {"mimeType": "text/markdown", "content": "[排障入口](https://xiezhao.me/GCP/Operations/)。关闭事件后仍须验证业务；无数据自动关闭不代表恢复。"},
  "alertStrategy": {
    "notificationPrompts": ["OPENED", "CLOSED"],
    "autoClose": "1800s",
    "notificationChannelStrategy": [{"notificationChannelNames": ["$CHANNEL"], "renotifyInterval": "1800s"}]
  },
  "conditions": [{
    "displayName": "Errors in five minutes",
    "conditionThreshold": {
      "filter": "metric.type=\"logging.googleapis.com/user/lab_errors\" AND resource.type=\"global\"",
      "comparison": "COMPARISON_GT",
      "thresholdValue": 0,
      "duration": "0s",
      "aggregations": [{"alignmentPeriod": "300s", "perSeriesAligner": "ALIGN_SUM"}],
      "trigger": {"count": 1}
    }
  }]
}
EOF
gcloud monitoring policies create --policy-from-file=alert.json --format='value(name)' > monitoring-policy-name.txt
gcloud logging write lab-events '{"event":"alert_test"}' --payload-type=json --severity=ERROR

等待数分钟，确认 incident 和通知同时出现。如果没有，检查指标是否已有数据、monitored resource 是否为 global、通知是否验证，以及过滤器是否匹配。告警 API

项目监控面板#

配套 static/examples/enterprise-orders/gcp/dashboard.py 输出可审查的面板 JSON，包括请求速率、5xx 速率、跨 revision 合并后的延迟 p95（第 95 百分位）。在企业项目工作目录执行；基础项目将 SERVICE_NAME 改成 orders-api：

export SERVICE_NAME=orders-enterprise
mkdir -p evidence
python3 gcp/dashboard.py > evidence/dashboard.json
gcloud monitoring dashboards create --config-from-file=evidence/dashboard.json --format='value(name)' > evidence/dashboard-name.txt

先跑订单业务验收，再在 Monitoring → Dashboards 打开新面板，选择最近 30 分钟。零请求时没有曲线并不等于服务健康；p95 不能通过平均各副本的 p95 得到，本面板对分布数据聚合。Cloud Run 指标

企业项目的 monitoring.tf 创建 Job 失败/采样缺失、SQL CPU/磁盘压力和 SQL 采样缺失告警。Job 缺失规则合并 result 序列，避免历史失败序列停止上报而单独误报。它检测的是没有采样；如果平台持续上报 0，不能据此检测调度停摆。基础 Pub/Sub 项目另关注未确认消息数与最老消息年龄；订单积压与账本对账不能只靠 HTTP 曲线推断。

验收：制造一次失败，能从指标找到时间窗口，再用 order_id 查询日志。目标不是只有“CPU 超过 80%”，而是发现订单是否无法处理。

正式 SLO 应定义成功请求比例、延迟门槛、统计窗口和错误预算；单次错误告警只是本篇的通知链路实验。

通知、无数据与恢复的验收#

策略	明确行为
通知	显式配置 OPENED/CLOSED，未关闭事件每 30 分钟重复；记录发送与实际收件时间
单次日志错误 / Job 失败	稀疏事件告警；无数据达到 autoClose 后可关闭，不能据此断言下一次任务成功
SQL 容量	缺失时保留既有判断，同时由单独的采样缺失策略发现监控中断
Job/SQL 采样缺失	先要有有效历史样本；持续上报 0 不属于缺失，资源被删除/关闭也存在检测边界

duration=0s 的阈值不能靠设置 evaluationMissingData 改变缺失行为。Cloud Monitoring 的自动关闭与恢复通知分别配置；收到 CLOSED 后仍检查关闭原因、最近数据及业务结果。策略 API、缺失告警限制。

在独立预生产项目跑通实际订单与两个 Job，确认图表有采样、业务水位推进。
保存本次 policy 资源名；基础日志实验写入上述 ERROR，核对事件及邮件。停止实验错误后，记录关闭原因：真实条件恢复或无数据自动关闭，不混用验收结论。
企业任务演练先核对 Scheduler 原为启用且仅服务测试数据，再暂停 projector；观察采样是否停止或继续为 0。只有前者应由当前 absence 规则触发，后者需基于完成次数/业务水位的停摆告警，不把未报警认作演练成功。
恢复 Scheduler 并实际执行 Job，验证任务成功、积压消退、订单对账、事件关闭及 CLOSED 邮件。若失败或未送达，保留现场并修配置，不删除策略掩盖问题。

export SCHEDULER_JOB='REPLACE_PREPROD_PROJECTOR_SCHEDULER'
gcloud scheduler jobs describe "$SCHEDULER_JOB" --location="$REGION" --project="$PROJECT_ID"
# 仅在上述前置条件满足后逐段执行。
gcloud scheduler jobs pause "$SCHEDULER_JOB" --location="$REGION" --project="$PROJECT_ID"
# 故障窗口结束必须恢复；执行与业务验收另按项目手册。
gcloud scheduler jobs resume "$SCHEDULER_JOB" --location="$REGION" --project="$PROJECT_ID"
gcloud scheduler jobs run "$SCHEDULER_JOB" --location="$REGION" --project="$PROJECT_ID"

暂停和恢复两段之间保留完整观察窗口；不要整块复制后立即恢复。策略配置使用 gcloud monitoring policies describe "$(cat monitoring-policy-name.txt)" 检查；Terraform 管理的策略从部署结果取资源名，不用日志实验的 ID。

任务从未成功运行或平台指标不适合作心跳时，生产需补独立的“预期任务清单 + 最近成功业务水位”检查。外部观察者应持续验证水位年龄、任务存在和队列积压；不能只在任务成功后发送一次指标，然后假设 absence 覆盖全部故障。监控自身失联及维护到期流程见通知可靠性演练。

清理#

gcloud monitoring policies list --format='table(name,displayName)'
# 仅填入本篇创建的 policy ID
gcloud monitoring policies delete '替换为policy ID'

在 Console 删除实验面板和专用通知渠道，再按 Logging 篇删除指标。不要删除团队共用通知渠道。

若使用上述 JSON 面板，只删除记录的本次 ID：

gcloud monitoring dashboards delete "$(cat evidence/dashboard-name.txt)"