PagerDuty 接收器是什么
PagerDuty 接收器把告警通过 Events API v2 推给 PagerDuty，由它在服务侧按事件规则决定是打电话、发短信还是仅记录。配置里最关键的是 routing_key（集成密钥）与 severity 的映射：PagerDuty 用 severity 判断响应策略，如果所有告警都写成同一个级别，分级与升级链就形同虚设。它适合需要电话唤起与升级链的场景，代价是要维护服务目录与事件规则的对应关系。
基本信息
| 配置位置 | receivers[].pagerduty_configs |
|---|---|
| 关键字段 | routing_key、severity、send_resolved、url、details |
| 去重机制 | 按事件标识合并，同一告警不会重复开单 |
| 适用版本 | Alertmanager 0.2x 及以上 |
| 权限要求 | PagerDuty 侧服务与集成密钥 |
典型使用场景
- 电话唤醒：严重故障需要在夜间把人叫起来，用升级链兜底
- 分级响应：按 severity 决定是打电话还是仅记录，避免全员响铃
- 值班排班：与排班表联动，自动指向当班人而非固定某个人
- 恢复闭环：开启恢复通知后事件自动解除，无需人工处理
- 质量统计：用事件数据统计确认时长与响应质量
使用要点
- severity 要真实分级，写死成一个级别会让分级与升级链失效
- routing_key 属于凭据，不要放在公开仓库里
- 详情字段要带上下文（服务、实例、当前值），否则值班人还要自己找数据
- 代理网络下投递失败只在 Alertmanager 日志可见，需要定期检查
- 服务目录里的告警规则要与 Alertmanager 的 severity 对齐
配置示例
配置示例
receivers:
- name: pager
pagerduty_configs:
- routing_key: <PD 集成密钥>
severity: '{{ .CommonLabels.severity }}'
send_resolved: true
details:
firing: '{{ .Alerts.Firing | len }}'
num_alerts: '{{ .Alerts | len }}'字段读法
| 字段 | 作用 | 注意 |
|---|---|---|
| routing_key | 集成密钥 | 属于凭据，需妥善保管 |
| severity | 严重级别 | 决定响应策略，必须真实分级 |
| send_resolved | 恢复事件 | 关闭后事件不会自动解除 |
| details | 详情字段 | 便于值班人直接判断 |
| url | API 端点 | 默认使用 Events API v2 |
在服务目录里为告警配置事件规则，并与 Alertmanager 的 severity 对齐之后，响应策略才能真正按级别生效。
接入步骤
- 在 PagerDuty 侧创建服务并选择 Events API v2 集成，拿到集成密钥
- 在 Alertmanager 的接收器里配置 routing_key 与 severity 映射
- 用一条测试告警走通链路，确认事件能在服务侧正确开单
- 核对事件规则：哪个级别打电话、哪个级别只记录，避免全员响铃
- 开启恢复通知后再次测试，确认事件能自动解除