在Linux环境下构建不会因单台机器故障而失灵的监控报警体系，核心思路是让数据采集与通知能力分散到多个节点，同时对外呈现统一入口。Prometheus负责指标拉取与规则评估，Alertmanager负责去重、分组与渠道发送，两者均支持水平复制，因此天然适合做高可用。
一、整体架构设计
我们准备两台Linux服务器，分别命名为 node-a 与 node-b，系统均使用 Ubuntu 22.04。两台机器上都运行 Prometheus 与 Alertmanager 实例，Prometheus 通过相同 scrape 配置抓取被监控目标，Alertmanager 之间通过 Gossip 协议同步通知状态，避免重复报警。前端使用 Keepalived 生成虚拟IP（VIP），Nginx 将流量转发到本地实例，当一台机宕机，VIP 漂移到另一台，监控界面与报警出口都不中断。
这种架构不需要共享存储，每个 Prometheus 本地保留自己的时序数据，短期故障恢复后历史仍在。若需要长期集中存储，可后续接入远程写组件，但高可用报警本身不依赖它。下表列出关键组件分工：
| 组件 | 部署位置 | 主要作用 |
|---|---|---|
| Prometheus | node-a, node-b | 拉取指标、执行告警规则 |
| Alertmanager | node-a, node-b | 接收告警、去重、发邮件或webhook |
| Keepalived | node-a, node-b | 管理VIP，故障转移 |
| Nginx | node-a, node-b | 反向代理本地服务 |
二、Prometheus与Alertmanager基础配置
在两台机器上创建相同的 prometheus.yml，确保告警规则一致。下面示例中 Prometheus 抓取自身与另一台节点的 node_exporter，并将告警推给本地 Alertmanager。
global:
scrape_interval: 15s
evaluation_interval: 15s
rule_files:
- /etc/prometheus/rules/*.yml
alerting:
alertmanagers:
- static_configs:
- targets: ['127.0.0.1:9093']
scrape_configs:
- job_name: 'prometheus'
static_configs:
- targets: ['127.0.0.1:9090']
- job_name: 'node'
static_configs:
- targets: ['node-a:9100', 'node-b:9100']
告警规则文件可定义如实例宕机这类条件。例如当 node_up 指标为 0 持续一分钟即触发。两个节点的规则内容必须完全相同，否则会出现一边报警另一边静默的混乱。
Alertmanager 配置需开启集群模式，通过 --cluster.listen-address 与 --cluster.peer 参数互联。以下为 alertmanager.yml 示例，使用邮件发送，并配置分组等待时间：
global:
smtp_smarthost: 'smtp.ipipp.com:587'
smtp_from: 'alert@ipipp.com'
smtp_auth_username: 'alert@ipipp.com'
smtp_auth_password: 'password'
route:
receiver: 'email'
group_wait: 30s
group_interval: 5m
repeat_interval: 4h
receivers:
- name: 'email'
email_configs:
- to: 'admin@ipipp.com'
三、实现高可用与故障转移
启动 Alertmanager 时，node-a 执行如下命令，node-b 将 peer 指向 node-a 的 9094 端口：
# node-a alertmanager --config.file=/etc/alertmanager/alertmanager.yml --cluster.listen-address=0.0.0.0:9094 # node-b alertmanager --config.file=/etc/alertmanager/alertmanager.yml --cluster.listen-address=0.0.0.0:9094 --cluster.peer=node-a:9094
这样两个 Alertmanager 通过 Gossip 交换静默与通知状态，任意一方发出邮件后，另一方不会重复发送。Keepalived 的配置则保证 VIP 始终在健康节点。以下为 keepalived.conf 精简版，使用 VRRP 脚本检测 Nginx 存活：
vrrp_script chk_nginx {
script "pidof nginx"
interval 2
}
vrrp_instance VI_1 {
state MASTER
interface eth0
virtual_router_id 51
priority 150
advert_int 1
authentication {
auth_type PASS
auth_pass 1111
}
virtual_ipaddress {
192.168.0.100
}
track_script {
chk_nginx
}
}
node-b 的 priority 设为 100 且 state 为 BACKUP。当 node-a 的 Nginx 停止，VIP 漂到 node-b，用户访问 192.168.0.100 依然能看到 Prometheus 页面并触发报警。需要注意，防火墙必须放行 9090、9093、9094 及 VRRP 协议，否则集群与漂移都会失败。
四、验证与常见误区
验证时可手动停掉 node-a 的 Prometheus 进程，观察 node-b 是否在评估周期内发出告警，并检查邮件是否只收到一次。也可用 curl 向任意 Alertmanager 提交静默，看另一台是否同步。很多人误以为两个 Prometheus 必须连同一个 Alertmanager 才算高可用，其实让每个 Prometheus 连本地 Alertmanager 再互联，才是官方推荐做法。
另一个常见错误是 scrape 配置写死单台 IP，导致 VIP 切换后抓取目标不变。应当将被监控主机名或域名写入配置，配合 DNS 或 hosts 文件解析，保证任意节点都能拿到全部目标。完成上述步骤后，一套在 Linux 上抗单点故障的监控报警系统便搭建完毕。
PrometheusAlertmanager高可用修改时间：2026-08-06 21:42:17