Grafana 不负责告警升级流转，仅触发规则并分发通知；升级逻辑由 Alertmanager 或自研中转服务实现，通过标签分级、路由配置与状态跟踪完成多级响应。
Grafana 本身不直接处理“告警升级流转”这类复杂路由逻辑，它负责规则触发和初步通知分发；真正的升级（比如：10分钟未响应→转给主管，30分钟未处理→触发电话告警）需要由下游告警管理组件完成。实际生产中，升级流转不是 Grafana 做的，而是 Alertmanager 或自研中转服务实现的。下面分三块讲清楚怎么做：
Grafana 告警规则里埋好升级线索
关键是在告警规则中打上可识别的标签，为后续分级路由提供依据。例如：
- 设置
severity: warning/critical/emergency - 加入
team: backend、service: payment、oncall: shift-a等上下文标签 - 使用 Go 模板动态计算标签值：
labels: severity: "{{ if gt $value 95 }}emergency{{ else if gt $value 90 }}critical{{ else }}warning{{ end }}"
Alertmanager 实现多级静默与升级
Alertmanager 是 Prometheus 生态的标准告警中枢，它通过 route 和 inhibit_rules 支持完整的升级逻辑：
-
按 severity 分层路由：把
warning发邮件，critical发飞书+短信，emergency触发电话机器人 -
设置
group_wait和group_interval：控制同类告警合并节奏，避免刷屏 -
用
repeat_interval实现“未处理再提醒”：比如repeat_interval: 30m表示每半小时重发一次未解决告警 -
配置
inhibit_rules抑制低优先级告警：当severity=emergency触发时，自动抑制同 service 下所有warning告警
典型 route 配置片段：
route:
receiver: 'default-receiver'
group_by: ['alertname', 'cluster']
group_wait: 30s
group_interval: 5m
repeat_interval: 30m
routes:
- match:
severity: emergency
receiver: 'phone-call'
continue: false
- match:
severity: critical
receiver: 'feishu-and-sms'
continue: false
- match:
severity: warning
receiver: 'email-digest'自研中转服务补充增强逻辑（适合飞书/企微等平台）
如果不用 Alertmanager，或需对接飞书、企业微信等无原生分级能力的渠道，就得自己写中转服务：
- 接收 Grafana Webhook 的原始 JSON
- 解析
labels.severity、annotations.description、startsAt等字段 - 维护一个内存或 Redis 中的“告警状态表”，记录：是否已响应、首次触发时间、当前升级阶段
- 根据预设策略自动推进：
-
startsAt + 10m且无 ack → @值班主管 -
startsAt + 30m且仍无 ack → 调用飞书语音机器人拨号
-
- 返回 HTTP 200 告知 Grafana 已接收，避免重试
这类服务用 Spring Boot、Python Flask 或 Node.js 都能快速落地，重点是把“时间戳 + 状态 + 上下文标签”串起来做判断。
Grafana 只管“什么时候该叫人”，真正决定“叫谁、怎么叫、叫几次”的，得靠 Alertmanager 或你写的那几百行中转代码。
