macOS 下载、安装 Alertmanager，Prometheus 生态的告警管理组件，负责去重、分组与路由（附安装包alertmanager-0.33.1.darwin-arm64.tar.gz）

发布于 2026/8/13 · 1 阅读

AlertmanagerPrometheus告警管理告警路由静默云原生CNCF监控开源软件macOS

Alertmanager 是 Prometheus 生态的告警管理组件，负责对告警进行去重、分组与路由，支持静默与抑制，通过邮件、PagerDuty、webhook 等接收器送达通知，是云原生告警管理的事实标准。

文章目录

1. Alertmanager 简介
2. v0.33.1 版本亮点

2.1 文档修复
2.2 静默（silences）相关修复

3. 获取安装包
4. 安装

4.1 开机自启（launchd 服务化）

5. 使用

5.1 配置邮件告警（SMTP）
5.2 与 Prometheus 对接
5.3 常用命令行（amtool）
5.4 REST API
5.5 运行状态监控

封面.png

1. Alertmanager 简介

Alertmanager 是 Prometheus 生态中的告警管理组件，与 Prometheus 监控系统同源。它诞生于 SoundCloud 公司内部的 Prometheus 监控项目（版权记录为 2013–2015 年 The Prometheus Authors，产品由 SoundCloud Ltd. 开发），用 Go 语言编写，随 Prometheus 一同发展。2016 年 Prometheus 加入云原生计算基金会（CNCF），2018 年更成为继 Kubernetes 之后第二个从 CNCF 毕业的项目，Alertmanager 也作为其告警处理的核心组件被各大公司广泛采用。如今 alertmanager 仓库在 GitHub 上拥有约 8400 颗星标、2400 余个 fork、370 余位贡献者，是云原生告警管理领域事实上的标准组件。

Alertmanager 要解决的，是"异常发现之后如何可靠、不轰炸地把告警送达正确的人"的问题。Prometheus 负责按规则评估指标、发现异常并触发告警，但这些原始告警可能大量重复、彼此关联：同一故障可能反复触发几十条告警，不同级别的告警之间也可能存在层级关系。若直接推送给值班人员，很容易造成通知轰炸与告警疲劳。Alertmanager 在中间承接这一环节，对告警进行去重、分组、路由，并在需要时静默、抑制，最后通过邮件、PagerDuty、OpsGenie、webhook 等多种接收器（receiver）送达，从而让值班人员只收到有效、聚合后的告警。

Alertmanager 的核心能力：

去重（deduplicating）：对同一告警的多份副本去重，避免重复通知
分组（grouping）：将同组的多个告警按标签归并，合并为一条通知批量发送
路由（routing）：按标签匹配规则将告警路由到不同的接收器（receiver）
静默（silencing）：在指定时间段内静默匹配特定条件的告警，例如维护窗口期间
抑制（inhibition）：当更严重的告警触发时，自动抑制相关的低级别告警，减少噪音
丰富的接收器集成：内置邮件、PagerDuty、OpsGenie、Slack、webhook 等通知渠道
高可用（High Availability）：支持多实例集群，通过 gossip 协议同步告警与静默状态
API 与命令行：提供 v2 REST API，并附带 amtool 命令行工具用于交互与查询

2. v0.33.1 版本亮点

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

v0.33.1 发布于 2026 年 7 月 4 日，是继 v0.33.0 之后的补丁版本，共修复了 3 处缺陷，全部围绕文档与静默（silences）相关功能的修正：

2.1 文档修复

补充 webhook 文档中缺失的 notification_reason 字段说明（#5329）

2.2 静默（silences）相关修复

修复静默快照（snapshot）缺失旧版 matchers 字段的问题。该缺陷会导致较旧版本的 Alertmanager 无法读取较新版本生成的快照，可能引发不必要的兼容性问题（#5330）
修复无匹配器（matchers）的静默在 API 响应中应填充为空数组、而非返回 null 的问题（#5331）

3. 获取安装包

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

适用于 macOS arm64（Apple Silicon，M 系列芯片）。Intel（x86_64）Mac 请选择对应的 alertmanager-0.33.1.darwin-amd64.tar.gz。

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

macOS安装alertmanager-v0.33.1（alertmanager-0.33.1.darwin-arm64）.zip
├── alertmanager-0.33.1.darwin-arm64.tar.gz   ← 解压后运行
├── macOS安装alertmanager-v0.33.1（alertmanager-0.33.1.darwin-arm64）.pdf
├── README/
│   ├── README.md
│   └── README-中文版.md
├── 发布说明/
│   ├── RELEASE-NOTES.md
│   └── RELEASE-NOTES-中文版.md
└── LICENSE

4. 安装

alertmanager-0.33.1.darwin-arm64.tar.gz 是 Alertmanager 官方发布的 macOS arm64 预编译二进制包，解压即可运行。解压后的目录内含 alertmanager、amtool 两个可执行文件，以及默认配置文件 alertmanager.yml：

# 解压二进制包
tar -xzf alertmanager-0.33.1.darwin-arm64.tar.gz

# 进入解压目录
cd alertmanager-0.33.1.darwin-arm64

# 启动 Alertmanager（使用自带的默认配置）
./alertmanager --config.file=alertmanager.yml

启动后访问 http://localhost:9093 即可打开 Alertmanager 的 Web 界面。默认配置使用一个 webhook 接收器（指向 http://127.0.0.1:5001/），实际使用前请按需修改。

4.1 开机自启（launchd 服务化）

macOS 系统中，可将 Alertmanager 托管为 launchd 启动项，实现开机自启与崩溃自动拉起。先将二进制部署到统一目录：

# 部署到统一目录并设置可执行权限
sudo mkdir -p /usr/local/alertmanager
sudo cp alertmanager amtool /usr/local/alertmanager/
sudo cp alertmanager.yml /usr/local/alertmanager/
sudo chmod +x /usr/local/alertmanager/alertmanager /usr/local/alertmanager/amtool

创建 plist 文件 ~/Library/LaunchAgents/com.alertmanager.plist（用户级，登录后自启；若需开机即启动、不依赖登录，则放到 /Library/LaunchDaemons/）：

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Label</key>
    <string>com.alertmanager</string>
    <key>ProgramArguments</key>
    <array>
        <string>/usr/local/alertmanager/alertmanager</string>
        <string>--config.file=/usr/local/alertmanager/alertmanager.yml</string>
    </array>
    <key>RunAtLoad</key>
    <true/>
    <key>KeepAlive</key>
    <true/>
    <key>StandardOutPath</key>
    <string>/usr/local/alertmanager/alertmanager.log</string>
    <key>StandardErrorPath</key>
    <string>/usr/local/alertmanager/alertmanager.err.log</string>
</dict>
</plist>

配置要点说明：

KeepAlive：进程异常退出时自动拉起
RunAtLoad：加载该 launchd 任务时立即启动服务
StandardOutPath / StandardErrorPath：日志输出到指定文件，便于排查
日志路径需确保 alertmanager 运行用户有写入权限

加载并启动服务：

# 加载 launchd 服务并启动
launchctl load ~/Library/LaunchAgents/com.alertmanager.plist

# 启动 / 停止 / 查看状态
launchctl start com.alertmanager
launchctl stop com.alertmanager
launchctl list | grep alertmanager

5. 使用

5.1 配置邮件告警（SMTP）

Alertmanager 默认配置只接了一个 webhook 接收器，实际使用中最常见的第一步是把它接到邮件。下面是一份完整的邮件告警配置，逐字段说明：

global:
  # SMTP 服务器地址（主机:端口）。常见端口：25（明文）、465（SSL 直连）、587（STARTTLS）
  smtp_smarthost: 'smtp.example.com:465'
  # 发件人邮箱，即收件人看到的"发件人"地址
  smtp_from: 'alert@example.com'
  # SMTP 认证用户名，通常与发件人邮箱一致
  smtp_auth_username: 'alert@example.com'
  # SMTP 认证密码
  # 重要：这里通常不是邮箱登录密码，而是邮箱服务商后台生成的「客户端授权码」
  # （QQ 邮箱、163 邮箱等需先在设置里开启 SMTP 服务，再获取授权码）
  smtp_auth_password: '<你的授权码>'
  # 是否强制要求 TLS。465 端口为 SSL/TLS 直连、无需 STARTTLS，这里设为 false
  smtp_require_tls: false

route:
  # 默认接收器，未匹配到任何子路由的告警都发到这里
  receiver: 'email'
  # 分组维度：相同 alertname + instance 的告警会被合并为一个通知组
  group_by: ['alertname', 'instance']
  # 首次收到告警后等待多久再发送，用于聚合同一波同时触发的告警
  group_wait: 30s
  # 同一告警组出现新告警后，多久再发送一次
  group_interval: 5m
  # 告警一直未恢复时，重复提醒的间隔
  repeat_interval: 1h

receivers:
  - name: 'email'
    email_configs:
      # 收件人邮箱，可写多个
      - to: 'oncall@example.com'
        # 告警恢复时是否也发送"已恢复"通知
        # true：触发发一封、恢复再发一封；false：只发触发告警，不发恢复通知
        send_resolved: true

几个容易踩坑的关键点：

授权码 ≠ 登录密码：smtp_auth_password 填的是邮箱服务商生成的「客户端授权码」（QQ 邮箱、163 邮箱等需在「设置 → 账号」中开启 SMTP 服务后获取），不是邮箱登录密码。
端口与 TLS 对应关系：465 端口是 SSL/TLS 直连，此时 smtp_require_tls 设为 false；若改用 587 端口（STARTTLS），则应设为 true。25 端口通常为明文，不建议用于公网告警。
send_resolved：设为 true 时，告警恢复也会收到一封"已恢复"邮件，便于确认故障闭环；设为 false 则只发故障告警。

配置写好后，用 amtool 校验，通过后重启生效：

amtool check-config alertmanager.yml

当告警需要按团队或严重级别分发到不同渠道时，再用 route 的子路由（routes）加 matchers（匹配器）做分流，并用 inhibit_rules（抑制规则）减少低级别噪音：

route:
  receiver: 'team-mail'
  routes:
    # severity 为 critical 的告警走电话值班渠道
    - matchers:
        - severity="critical"
      receiver: 'team-pager'
    # service 为 database 的告警交给数据库值班组
    - matchers:
        - service="database"
      receiver: 'team-DB-pager'

inhibit_rules:
  # 同一告警已触发 critical 时，抑制其 warning 级别的通知
  - source_matchers:
      - severity="critical"
    target_matchers:
      - severity="warning"
    equal: ['alertname']

receivers:
  - name: 'team-mail'
    email_configs:
      - to: 'team@example.com'
  - name: 'team-pager'
    pagerduty_configs:
      - routing_key: '<pager-key>'
  - name: 'team-DB-pager'
    pagerduty_configs:
      - routing_key: '<DB-team-key>'

要点说明：

group_by：按标签将告警归组，同一组的多条告警合并为一条通知，避免轰炸
group_wait / group_interval / repeat_interval：控制首次通知、批次间隔与重复提醒的节奏
inhibit_rules（抑制规则）：当源告警（source）触发时，静默匹配的目标告警（target），用于"更严重告警已触发，低级告警就不必再发"

5.2 与 Prometheus 对接

要让 Prometheus 把告警推送给 Alertmanager，需在 Prometheus 的 prometheus.yml 中配置 alerting 段，并引入告警规则文件：

# prometheus.yml 中的告警相关配置
alerting:
  alertmanagers:
    - static_configs:
        - targets: ['localhost:9093']

rule_files:
  - "rules.yml"

在 rules.yml 中定义告警规则，表达式满足条件并持续 for 指定时长后进入告警状态：

groups:
  - name: example
    rules:
      - alert: 服务离线
        expr: up == 0
        for: 2m
        labels:
          severity: critical
        annotations:
          summary: 实例离线
          description: "{{ $labels.instance }} 已离线超过 2 分钟"

注意：不要在 Prometheus 与多个 Alertmanager 之间做负载均衡，而应让 Prometheus 指向所有 Alertmanager 的列表——Alertmanager 期望所有告警都发送给所有实例，以保证高可用。

5.3 常用命令行（amtool）

amtool 是随 Alertmanager 一起发布的命令行工具，用于查询与管理告警、静默：

# 查看当前触发中的告警
amtool alert

# 查看扩展输出
amtool -o extended alert

# 按标签查询告警
amtool alert query alertname="Test_Alert"

# 静默某条告警
amtool silence add alertname=Test_Alert

# 查看静默列表
amtool silence query

# 让静默过期
amtool silence expire <silence-id>

# 查看远程 Alertmanager 的路由树
amtool config routes --alertmanager.url=http://localhost:9093

amtool 也可通过配置文件 ~/.config/amtool/config.yml 指定默认的 Alertmanager 地址、默认接收器等选项，避免每条命令重复传入。

5.4 REST API

Alertmanager 提供 v2 版本的 REST API，通过 /api/v2 前缀访问。常用端点：

GET /api/v2/status：查看 Alertmanager 状态
GET /api/v2/alerts：查询当前告警
GET /api/v2/silences：查询静默
POST /api/v2/silences：创建静默

例如用 curl 查看状态：

curl http://localhost:9093/api/v2/status

5.5 运行状态监控

Alertmanager 的 Web 界面（默认 http://localhost:9093）提供了告警、静默、状态等页面，可直观查看当前触发的告警、已建立的静默，以及集群节点信息。对运行状态，也可通过 /api/v2/status 或 amtool 命令即时查看。