AlertmanagerConfig 是什么
AlertmanagerConfig 是 Prometheus Operator 定义的 CRD，把路由与接收器下沉到命名空间：各团队在自己命名空间里维护告警路由与接收器，由 Operator 合并进全局 Alertmanager 配置。它解决了多团队共享一套告警组件时的配置争抢——不必再让所有人改同一份 alertmanager.yml。前提是全局 Alertmanager 侧配置了选择器与命名空间范围，子配置才会被合并进去。
基本信息
| 资源类型 | Kubernetes CRD（monitoring.coreos.com/v1alpha1） |
|---|---|
| 归属组件 | Prometheus Operator |
| 关键字段 | spec.route、spec.receivers、spec.inhibitRules |
| 合并前提 | Alertmanager 资源里配置 alertmanagerConfigSelector 与命名空间选择器 |
| 适用环境 | Kubernetes 集群 |
典型使用场景
- 多团队自治：各命名空间维护自己的路由与接收器，互不阻塞
- 权限收敛：团队只在本命名空间建 CR，不必改动全局配置
- 路由隔离：按标签把告警投递到对应团队的通道
- 平台统一：平台侧只维护全局默认路由与通知汇总
- GitOps 管理：CR 与业务清单一起版本化，变更可追溯
使用要点
- 全局 Alertmanager 必须配选择器，否则子配置写了也不生效
- CR 内的路由与全局路由合并后的实际行为要用测试告警验证
- 命名空间选择范围要明确，避免误合并测试命名空间的配置
- 接收器里的地址要能在集群内解析，跨命名空间引用使用完整域名
- 上线前先小范围验证合并结果，再逐步放开范围
AlertmanagerConfig 示例
AlertmanagerConfig 示例
apiVersion: monitoring.coreos.com/v1alpha1
kind: AlertmanagerConfig
metadata:
name: team-search
namespace: search
spec:
route:
receiver: search-im
groupBy: ['alertname']
matchers:
- name: team
value: search
receivers:
- name: search-im
webhookConfigs:
- url: http://relay.search.svc:8060/im字段读法
| 字段 | 含义 | 注意 |
|---|---|---|
| spec.route | 团队级路由规则 | 与全局路由合并后生效 |
| spec.receivers | 接收器定义 | 地址需在集群内可解析 |
| spec.inhibitRules | 抑制规则 | 合并顺序影响实际行为 |
| matchers | 标签匹配条件 | 写错会导致路由不命中 |
| 全局选择器 | 筛选哪些 CR 参与合并 | 缺失则子配置全部失效 |
子配置与全局配置合并后的结果才是实际生效值，冲突时以合并结果为准；上线前用一条测试告警走完整个路径最稳妥。