GCP 90天试用 GCP谷歌云监控报警自定义
你有没有在凌晨三点被手机震醒，眯眼一看——「GCE实例CPU使用率持续15分钟超95%」？点开一看，服务器稳如泰山，CPU峰值其实就冲了37秒，剩下14分23秒全靠监控系统自己脑补。你叹了口气，默默把报警阈值调高，顺手给GCP控制台发了条差评：「这报警，比我家楼下的流浪猫还爱虚张声势。」
别急，这不是GCP不行，是你还没把它当人使——不是当工具，是当一个能听懂你话、记得住你脾气、还能帮你甩锅的智能搭档。今天这篇，不讲概念，不列API文档，就拿一杯咖啡的时间，带你亲手把GCP监控报警从「聋哑AI」调教成「靠谱哨兵」。
第一步：先别急着设报警，先把指标「养熟」
很多人一上来就直奔 Alerting → Create Policy，结果发现下拉菜单里全是「CPU利用率」「网络字节数」这种祖传指标，想监控「/api/v2/orders 失败率连续5分钟＞3%」？抱歉，菜单里没有，系统说：「您已超出基础套餐，请充值高级洞察力。」
真相是：自定义指标不是藏在某个付费开关后面，而是藏在你自己的代码和日志里。
举个接地气的例子：你在Cloud Run上跑了个订单服务，每次HTTP 5xx，你本就在log里打了{"service":"orders", "status":500, "path":"/v2/pay"}。这时候，别急着写告警，先打开Logs Explorer → 查找日志 → 点右上角「Create Metric」。选「Counter」类型，填过滤器：resource.type="cloud_run_revision" jsonPayload.status=500，起名orders_5xx_count——搞定。30秒后，这个指标就出现在Metrics Explorer里，像刚领了工牌的新员工，随时待命。
关键提示：别用「Gauge」！除非你想监控内存剩余MB数这类瞬时值；统计类（失败次数、请求量、错误率）一律用Counter，它会自动按时间窗口做rate()计算，省得你半夜推导微积分。
第二步：画图不是为了好看，是为了验证「它真懂你在看啥」
指标建好，别跳过这一步：去Metrics Explorer，拖拽你的orders_5xx_count，选「Rate per minute」，加个除法运算：div(rate(orders_5xx_count)[5m], rate(http_server_request_count)[5m])，得到真实失败率。
为什么强调「画图」？因为这是唯一能让你看清数据灵魂的时刻。你可能发现：失败率曲线毛刺飞起，但每次尖峰只持续20秒——说明是偶发网络抖动，不是服务崩了；也可能发现失败率缓慢爬升到1.8%，然后断崖式掉回0——大概率是某段逻辑里有个没catch的异常，重试三次后直接放弃。这些节奏感，报警策略写不出来，但眼睛看得出来。
顺便治一个经典幻觉：「我设置了5分钟窗口，它就应该每5分钟算一次」。错。GCP默认用滑动窗口（sliding window），实际是每分钟滚动计算最近5分钟的rate——所以你看到的「当前失败率」，其实是过去5分钟的加权平均，不是静态切片。这点不理解，后续所有阈值都可能偏航。
第三步：报警策略——少即是多，慢即是准
进Alerting → Create Policy，选你的自定义指标，这时重点来了：别直接填「> 3%」，先点开「Advanced options」。
- Aggregation：选「Mean」而不是「Max」——避免单次毛刺触发；
- Alignment period：设为60秒（匹配你metrics的采集粒度）；
- Rolling window：填300秒（就是5分钟）；
- GCP 90天试用 Condition：写成
metric.labels.service = "orders"，精准锁定，别让支付服务的报警误伤用户中心； - Trigger when：选「Most recent value」——别选「Any value in window」，否则1秒超标就告警，纯属自虐。
再加一道保险：设置「Notification channels」前，先建个「Uptime Check」盯住你的告警接收端口。比如Slack webhook地址，别等真出事才发现404了。我们吃过亏：某次升级Slack App权限，webhook静默失效三天，而GCP告警日志里只有一行「Delivery failed」，小得像蚊子哼哼。
第四步：别让告警变成骚扰，学会「分级说话」
生产环境只有一种告警级别：P0（立刻爬起来）、P1（早上第一件事）、P2（写进周报）。GCP本身不支持分级，但你可以用Pub/Sub + Cloud Functions弯道超车。
流程是：告警触发 → 推送事件到Pub/Sub主题 → Function消费消息 → 根据incident.severity和condition.name判断等级 → P0发Slack+电话；P1仅发Slack+邮件；P2写入BigQuery留痕。Function里几行Python：if '5xx_rate' in msg and float(msg['value']) > 5.0: send_sms()——简单粗暴，胜过一百页SLO文档。
最后，三个血泪避坑指南
- 单位陷阱：GCP里「内存使用率」返回的是0~1的浮点数，不是0~100的百分比。你填「> 80」？它永远不响。必须填「> 0.8」。同理，磁盘IOPS是整数，延迟是毫秒——别信直觉，查Docs左上角那个小问号图标。
- 权限迷宫：
roles/monitoring.editor不能创建指标，得加roles/logging.logWriter；想让函数推送告警，Service Account还得有pubsub.publisher。建议新建项目时直接套用roles/monitoring.admin起步，稳定后再拆。 - 延迟不是bug，是特性：从日志打点→指标生成→图表渲染→告警触发，GCP全链路延迟约90~120秒。别指望「实时」，把「5分钟检测窗口」理解成「5分钟+2分钟缓冲」更现实。想更快？上OpenTelemetry+Prometheus+Thanos组合拳，但那已是另一场战役。
写完这篇，我顺手检查了自己线上项目的告警策略——删掉了3条「CPU＞90%」，加了2条「5xx率＞1.5%且持续8分钟」，又把Slack通知模板改成了「【P0】订单服务失败率已达2.3%（5min avg），请确认是否DB连接池耗尽」。消息里带了直接跳转Cloud SQL连接数监控的链接。
真正的监控不是让机器叫得更响，而是让人听得更准。GCP不是不够聪明，是你还没教会它什么叫「重点」。现在，关掉这篇文章，打开你的GCP控制台——别复制粘贴，先去Logs Explorer里，把你最常骂的那条错误日志，变成第一个自定义指标。
记住：最好的告警，是你看了之后，不用查文档、不用翻代码、不用打电话问同事，就知道该去哪一行加个try-catch。
