告警设计的一条铁律
每条告警都必须能回答一个问题：收到它以后要做什么？如果答案是「看一下」或者「不用管」，那它就不该是告警，应该降级成看板指标或日报内容。
我们做告警治理的标准流程是：先统计过去 30 天所有告警的触发次数和实际处置动作，把从未导致任何动作的告警全部关掉或降级。通常这一步就能砍掉 60%-80% 的噪声。
告警分层设计
| 层级 | 监控对象 | 示例指标 | 告警策略 |
|---|---|---|---|
| 业务层 | 用户能感知的指标 | 下单成功率、支付成功率、页面可用性 | 直接告警到值班，这是最重要的一层 |
| 应用层 | 服务健康度 | 错误率、P99 延迟、队列积压 | 超阈值告警，配合同比判断 |
| 中间件层 | 数据库、缓存、消息队列 | 连接数、慢查询、复制延迟、缓存命中率 | 分级告警，中危先记录 |
| 资源层 | CPU、内存、磁盘、网络 | 使用率、IOPS、带宽 | 只在趋势性异常时告警，不做瞬时告警 |
| 平台层 | 云服务状态 | AWS Health 事件、配额使用率 | 配额接近上限提前告警 |
很多团队只做了资源层监控，结果 CPU 一切正常但用户已经下不了单。业务层指标才是最终判据。
可观测性技术栈
展示与告警
Grafana 看板
CloudWatch Dashboard
企微/钉钉机器人
PagerDuty 值班轮转
指标
CloudWatch Metrics
Prometheus
自定义业务指标
SLO 计算
日志
Fluent Bit 采集
CloudWatch Logs
OpenSearch
S3 归档 + Athena
链路
OpenTelemetry SDK
X-Ray
服务依赖图
慢调用分析
合成监控
CloudWatch Synthetics
多地域拨测
关键流程巡检
日志成本很容易失控。建议：结构化日志、按级别采样、热数据留 7-14 天在 OpenSearch，冷数据归档到 S3 用 Athena 查。
SLO 与错误预算告警
# 基于错误预算燃烧率的告警，比固定阈值更能反映真实风险
# 目标：99.9% 可用性（30 天错误预算 = 43.2 分钟）
groups:
- name: slo-order-service
rules:
# 定义 SLI：成功请求占比
- record: sli:order_success_ratio:rate5m
expr: |
sum(rate(http_requests_total{service="order",code!~"5.."}[5m]))
/
sum(rate(http_requests_total{service="order"}[5m]))
- record: sli:order_success_ratio:rate1h
expr: |
sum(rate(http_requests_total{service="order",code!~"5.."}[1h]))
/
sum(rate(http_requests_total{service="order"}[1h]))
- record: sli:order_success_ratio:rate6h
expr: |
sum(rate(http_requests_total{service="order",code!~"5.."}[6h]))
/
sum(rate(http_requests_total{service="order"}[6h]))
# 快速燃烧：1 小时内烧掉 2% 的月度预算 → 立即告警
# 按这个速度，预算会在 2 天内耗尽
- alert: OrderServiceFastBurn
expr: |
(1 - sli:order_success_ratio:rate5m) > 14.4 * 0.001
and
(1 - sli:order_success_ratio:rate1h) > 14.4 * 0.001
for: 2m
labels:
severity: P1
team: order
annotations:
summary: "订单服务错误预算快速消耗"
description: |
当前错误率 {{ $value | humanizePercentage }}，
按此速度月度错误预算将在 2 天内耗尽。
runbook: "https://wiki.internal/runbook/order-service-errors"
# 慢速燃烧：6 小时内烧掉 5% → 工作时间处理
- alert: OrderServiceSlowBurn
expr: |
(1 - sli:order_success_ratio:rate6h) > 6 * 0.001
for: 15m
labels:
severity: P3
team: order
annotations:
summary: "订单服务错误预算缓慢消耗"
description: "需在本周内定位并修复，避免月末预算耗尽。"
# 延迟 SLO：P99 超过 500ms
- alert: OrderServiceLatencyDegraded
expr: |
histogram_quantile(0.99,
sum(rate(http_request_duration_seconds_bucket{service="order"}[5m])) by (le)
) > 0.5
for: 5m
labels:
severity: P2
team: order燃烧率告警的好处是：短时的小波动不会打扰你，但持续性的劣化会及时暴露。比「错误率 > 1% 就告警」精准得多。