Windows 下载、安装 Alertmanager，Prometheus 告警通知中枢，去重、分组、路由、静默抑制（附安装包alertmanager-0.33.1.windows-amd64.zip）

1. Alertmanager 简介

Alertmanager 是 Prometheus 生态中的告警通知组件，由 Prometheus 团队开发并维护。它诞生于云原生监控（cloud-native monitoring）体系，与 Prometheus 服务器、各类 Exporter 一起构成"采集 → 查询 → 告警"的完整监控链路。Alertmanager 采用 Go 语言编写，以 Apache License 2.0 开源，单个静态二进制即可部署，GitHub 星标约 8,500，是继 Prometheus 之后云原生告警事实上的标准组件。

用大白话说，Prometheus 负责"发现哪里出了问题"，而 Alertmanager 负责"把问题通知到对的人手上"。当多台服务器同时触发大量告警时，直接逐条通知会把人的手机和邮箱刷爆；Alertmanager 的工作就是把这些原始告警做一次"整理"——把重复的合并成一条、把相关的打成一个包、把不同级别的告警按规则送到不同渠道（邮件、Slack、PagerDuty、钉钉/企业微信等），还支持在维护窗口临时"静默"掉不想看的告警。

核心特点：

• 告警去重（deduplication）：内容相同的多条告警合并为一条，避免重复通知轰炸
• 告警分组（grouping）：按标签把相关告警聚合到一个分组，一次通知一条摘要
• 告警路由（routing）：基于标签匹配器（matcher）把不同告警路由到不同接收器，形成树状分发规则
• 静默（silencing）：在指定时间窗口内临时屏蔽某类告警，适合计划内维护
• 抑制（inhibition）：某条告警已触发时，自动抑制低优先级的关联告警（如整机宕机时不再逐条发磁盘告警）
• 多渠道接收器：内置 email、Slack、PagerDuty、OpsGenie 等，并通过 webhook 接收器对接钉钉、企业微信、自定义系统
• 高可用（high availability）：多实例组成集群，基于 gossip 协议同步状态，默认启用
• amtool 命令行工具：随发行版打包，可查询告警、管理静默、测试路由

2. v0.33.1 版本亮点

该版本汇集了 2 位贡献者 的 3 条 贡献。

v0.33.1（2026-07-04）是一个补丁版本，主要包含 3 项 Bug 修复：

文档修复：

• 修复 webhook 文档中缺失的 notification_reason 字段（#5329）

静默（silences）修复：

• 修复静默快照缺失旧版 matchers 字段的问题，此前旧版 Alertmanager 无法读取新版快照（#5330）
• 无 matchers 的静默在 API 响应中填充空数组（#5331）

v0.33 系列背景：

v0.33.0（2026-06-12）是 0.33 系列的功能版本，引入的主要能力包括：按聚合分组告警标记（AlertMarkers），移除全局告警标记；Web UI 支持静默注释（silence annotations）；API 在 /api/v2/receivers、/api/v2/alerts、/api/v2/alerts/groups 端点新增 receiver labels 与 receiver_matchers 过滤；新增事件记录器（event-recorder），在 --enable-feature=event-recorder 特性标志后支持 file、webhook、kafka 输出；移除已无作用的 --enable-feature=auto-gomaxprocs 选项；SNS 通知器新增 use_aws_http_client 配置项；模板新增 now 函数用于获取当前时间。

3. 获取安装包

如果访问 GitHub 不便，安装包及中文文档：https://hanshuixin.org/go/225S（内含 alertmanager-0.33.1.windows-amd64.zip、README 中英对照、发布说明中英对照和 LICENSE）。

Alertmanager 其他版本：https://hanshuixin.org/resource/software_integrated_package/Windows/Alertmanager

Windows安装alertmanager-v0.33.1（alertmanager-0.33.1.windows-amd64）.zip
├── alertmanager-0.33.1.windows-amd64.zip
├── Windows安装alertmanager-v0.33.1（alertmanager-0.33.1.windows-amd64）.pdf
├── README/
│   ├── README.md
│   └── README-中文版.md
├── 发布说明/
│   ├── RELEASE-NOTES.md
│   └── RELEASE-NOTES-中文版.md
└── LICENSE

4. 安装

将整合包根目录中的 alertmanager-0.33.1.windows-amd64.zip 解压到任意目录（如 C:\alertmanager），解压后得到 alertmanager.exe（服务端程序）、amtool.exe（命令行工具）以及 alertmanager.yml（默认配置文件）等文件。命令行中进入该目录，运行 alertmanager.exe 即可启动服务，默认监听 http://localhost:9093。

生产环境建议遵循"先校验、再启动"的顺序：

# 1. 校验配置文件
amtool.exe check-config alertmanager.yml

# 2. 前台启动（先确认无报错）
alertmanager.exe --config.file=alertmanager.yml

确认运行正常后，再注册为系统服务长期运行。Windows 可选择用 NSSM 等工具托管。

启动参数要点：

• --config.file=alertmanager.yml：指定配置文件，默认从当前目录加载
• --web.listen-address=0.0.0.0:9093：监听所有网卡（默认只监听本机回环地址）
• --cluster.listen-address=0.0.0.0:9094：集群同步端口；设为空字符串可关闭高可用模式
• --data.retention=120h：静默与告警状态等数据的保留时长

4.1 关键配置（必须）

Alertmanager 必须加载配置文件才能正常工作，默认从当前目录的 alertmanager.yml 加载，也可用 --config.file 参数指定。一个最小可用的 alertmanager.yml 骨架：

global:
  smtp_smarthost: 'smtp.example.com:465'   # 邮件 SMTP 服务器（格式：主机:端口）
  smtp_from: 'alert@example.com'           # 发件人邮箱（收件人看到的发件人）
  smtp_auth_username: 'alert@example.com'  # SMTP 认证用户名，一般就是邮箱账号
  smtp_auth_password: '你的客户端授权码'     # 不是登录密码！是邮箱后台开启 SMTP 时生成的授权码
  smtp_require_tls: false                  # 465 端口为 SSL/TLS 直连，无需 STARTTLS

route:
  receiver: 'default'
  group_by: ['alertname', 'cluster']       # 告警分组标签
  group_wait: 30s                          # 新分组首次通知前等待
  group_interval: 5m                       # 后续通知批处理间隔
  repeat_interval: 3h                      # 告警持续时的重复提醒间隔

receivers:
  - name: 'default'
    email_configs:
      - to: 'ops@example.com'
        send_resolved: true                # 告警恢复时也发送通知

常用配置项：

5. 使用

5.1 启动服务

在解压目录下直接运行 alertmanager.exe，即可用内置的默认配置启动。若自定义了配置文件，用 --config.file 指定：

alertmanager.exe --config.file=alertmanager.yml

启动后浏览器访问 http://localhost:9093，可查看当前告警列表、静默规则与运行状态。默认配置下页面即可交互，无需额外账号。

5.2 配置邮件通知（实战案例）

把告警送进邮箱是 Alertmanager 最常用的用法，也是"采集 → 查询 → 告警 → 通知"闭环的最后一步。下面是一份完整的邮件通知配置，逐字段注释：

global:
  smtp_smarthost: 'smtp.example.com:465'        # SMTP 服务器地址，格式「主机:端口」
  smtp_from: 'alert@example.com'                # 发件人邮箱，收件人看到的发件人
  smtp_auth_username: 'alert@example.com'       # SMTP 认证用户名，一般就是邮箱账号
  smtp_auth_password: '你的客户端授权码'      # 不是登录密码！是邮箱后台生成的授权码
  smtp_require_tls: false                   # 465 端口是 SSL/TLS 直连，无需 STARTTLS

route:
  receiver: 'email'                         # 默认接收器，指向下方 receivers 里的 name
  group_by: ['alertname', 'instance']       # 相同 alertname + instance 合并为一个告警组
  group_wait: 5m                            # 新告警组出现后先等 5 分钟，聚合同批告警再发第一封
  group_interval: 15m                       # 同一告警组又有新告警时，每隔 15 分钟补发一批
  repeat_interval: 1h                       # 告警一直没恢复时，每 1 小时重复提醒一次

receivers:
  - name: 'email'                           # 接收器名，route.receiver=email 就是引用这里
    email_configs:
      - to: 'ops@example.com'               # 收件人邮箱
        send_resolved: true                 # true：告警恢复时也发一封「已恢复」通知

逐字段解释：

• global 段是全局 SMTP 设置，只管"邮件从哪发出去"。smtp_smarthost 填你所用邮箱服务商的 SMTP 服务器地址（格式「主机:端口」），上面示例里的 smtp.example.com 只是占位，请按实际邮箱替换。smtp_auth_password 填的是「客户端授权码」而不是登录密码——126、QQ、网易、新浪等多数邮箱出于安全考虑，要求第三方程序用授权码登录，需先在邮箱后台开启 SMTP 服务并生成授权码。465 端口走 SSL/TLS 直连，所以 smtp_require_tls 设为 false；若改用 587 端口则要设为 true（STARTTLS）。
• route 段决定"怎么发、多久发一次"。receiver 是兜底接收器，指向下方某个接收器的 name；group_by 决定哪些告警合并成一封邮件，按 alertname + instance 分组最常用，避免同一告警在多台机器触发时刷屏；group_wait 是首次发现告警后的等待时间，用来把同一瞬间爆发的一批告警合并进第一封邮件；group_interval 是同一告警组后续新增告警的发送间隔；repeat_interval 是告警一直存在时的重复提醒间隔，避免"只报一次就不再管"。
• receivers 段定义具体通知渠道。name 与 route.receiver 对应；email_configs 里的 to 是收件人；send_resolved: true 让告警恢复时也发一封通知，做到"坏了通知、好了也通知"。

常见邮箱服务商的 SMTP 服务器地址（SSL 465 端口）：

配置写好后、启动之前，先用 amtool 校验一遍，确认无误：

amtool.exe check-config alertmanager.yml

当团队不止一个接收人时，用树状路由把告警按标签分发，例如数据库告警发 DBA、生产 critical 告警走电话/短信渠道：

route:
  receiver: 'default'                       # 兜底接收器
  group_by: ['alertname', 'cluster']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 3h

  routes:
    # 数据库相关告警单独处理
    - matchers:
        - service="database"
      receiver: 'db-team'
      group_by: ['alertname', 'database']

    # 生产环境 critical 告警走电话/短信渠道
    - matchers:
        - severity="critical"
        - env="prod"
      receiver: 'oncall-pager'

receivers:
  - name: 'default'
    email_configs:
      - to: 'ops@example.com'
        send_resolved: true
  - name: 'db-team'
    email_configs:
      - to: 'dba@example.com'
        send_resolved: true
  - name: 'oncall-pager'
    pagerduty_configs:
      - routing_key: '<your-pagerduty-key>'

规则要点：

• 路由自上而下匹配，命中后进入对应接收器；未命中的告警落入根路由的 receiver
• group_by 决定哪些告警合并为一个通知；按 alertname 分组是最常用做法
• send_resolved: true 让告警恢复时也发一条通知，避免"只报坏不报好"

5.3 接入 Prometheus

Prometheus 只负责"发现异常"，真正把告警送到人手里的是 Alertmanager。在 Prometheus 的 prometheus.yml 中配置 alerting 段即可接入：

alerting:
  alertmanagers:
    - static_configs:
        - targets: ["localhost:9093"]

若部署了多个 Alertmanager 组成高可用集群，把列表全部写上即可，无需负载均衡：

alerting:
  alertmanagers:
    - static_configs:
        - targets:
            - alertmanager1:9093
            - alertmanager2:9093
            - alertmanager3:9093

配置完成后，Prometheus 命中的告警会自动推送过来，由 Alertmanager 负责去重、分组并通知。至此，"采集 → 查询 → 告警 → 通知"的完整链路就打通了。

要真正收到一封"服务器离线"的邮件，还需要在 Prometheus 侧写一条告警规则（PromQL 表达式命中即触发），并让规则里携带的 severity、instance 等标签与 Alertmanager 的 group_by、routes 对应起来。一个最小示例：

# Prometheus 的 rules.yml
groups:
  - name: demo
    rules:
      - alert: "服务器离线"
        expr: up == 0
        for: 2m
        labels:
          severity: critical
        annotations:
          summary: "服务器离线"
          description: "{{ $labels.instance }} 无法访问，已持续 2 分钟"

这条规则命中后，Prometheus 会把告警推给 Alertmanager；Alertmanager 按 group_by（如 alertname + instance）合并去重，再依据 severity 等标签路由到对应接收器，最终发出邮件。邮件正文里的 {{ $labels.instance }} 会被替换成具体机器名，方便一眼定位故障对象。

5.4 amtool 命令行

amtool 是随发行版打包的命令行工具，用于与 Alertmanager API 交互。常用命令：

# 查看当前正在触发的告警
amtool.exe alert

# 以扩展格式查看告警（含标签与注释）
amtool.exe -o extended alert

# 按查询条件过滤告警
amtool.exe alert query alertname="HighLatency"

# 查看当前静默规则
amtool.exe silence query

也可以把 API 地址写进配置，避免每次重复指定。默认配置文件路径为 $HOME/.config/amtool/config.yml：

alertmanager.url: "http://localhost:9093"
output: extended

5.5 静默与抑制

**静默（silencing）**用于计划内维护：在维护窗口内屏蔽某类告警，避免误报刷屏。

# 新增一条静默（静默 alertname=HighLatency 的告警）
amtool.exe silence add alertname=HighLatency

# 查看静默列表
amtool.exe silence query

# 手动让某条静默提前过期
amtool.exe silence expire <silence-id>

静默会记录创建者与注释，方便事后追溯；静默到期后相关告警自动恢复通知。

**抑制（inhibition）**用于告警之间的级联收敛：当根因告警已触发时，抑制掉由其派生的大量次生告警。典型场景是"整机宕机"时抑制该机上所有"服务不可用"的告警。在 alertmanager.yml 中配置：

inhibit_rules:
  - source_matchers:
      - severity="critical"      # 源告警（已触发）
    target_matchers:
      - severity="warning"       # 目标告警（被抑制）
    equal: ['alertname']         # 标签名相同时才应用抑制

5.6 高可用集群

Alertmanager 的高可用默认启用，基于 gossip 协议在实例间同步状态。集群通过 --cluster.* 标志配置，核心参数：

# 实例 1
alertmanager.exe --cluster.listen-address=0.0.0.0:9094 --cluster.peer=peer2:9094

# 实例 2（指定实例 1 为对等节点）
alertmanager.exe --cluster.listen-address=0.0.0.0:9094 --cluster.peer=peer1:9094

要点：

• --cluster.listen-address 是集群监听端口（默认 0.0.0.0:9094），其他对等节点的 --cluster.peer 要指向该端口
• 集群需同时放行 UDP 与 TCP 两种协议（防火墙或容器均需注意）
• 若实例没有带默认路由的 IP，须用 --cluster.advertise-address 指定广播地址
• 单机不需要高可用时，设置 --cluster.listen-address= 即可关闭