使用Prometheus与Alertmanager实现主机宕机告警的问题咨询

核心思路是避免完全依赖节点侧的Prometheus上报告警，新增中心侧独立的探活或采集机制。

方案1：调整为中心化Prometheus采集架构（推荐） #

这是生产环境最常用的部署方案，从架构根源解决问题：

• 废弃各节点上部署的Prometheus实例，仅在中心侧部署统一的Prometheus服务
• 在中心Prometheus的scrape_config中配置所有节点的node exporter作为采集目标，拉取各节点的监控指标
• 新增节点宕机告警规则，示例如下：

groups:
- name: node_status_alerts
  rules:
  - alert: NodeDown
    expr: up{job="node_exporter"} == 0
    for: 2m
    labels:
      severity: critical
    annotations:
      summary: "节点 {{ $labels.instance }} 不可用"
      description: "节点 {{ $labels.instance }} 指标采集连续失败超过2分钟，疑似宕机"

• 中心Prometheus直接对接已有的中心Alertmanager，触发告警后自动推送至Slack
• 优势：架构更简洁，监控规则统一管理，无需维护节点侧的Prometheus实例，避免节点故障导致的告警上报失败问题。

方案2：保留现有架构，新增中心侧探活机制 #

如果因业务限制不能调整现有分布式Prometheus架构，可以新增独立探活逻辑：

• 中心侧部署blackbox_exporter，配置ICMP ping、端口探测等探活规则，覆盖所有需要监控的节点IP
• 部署一套轻量的中心独立Prometheus（和现有业务链路隔离），采集blackbox_exporter的探活指标
• 新增探活失败告警规则，示例如下：

groups:
- name: probe_alerts
  rules:
  - alert: NodeProbeFailed
    expr: probe_success{job="node_icmp_check"} == 0
    for: 2m
    labels:
      severity: critical
    annotations:
      summary: "节点 {{ $labels.instance }} 探活失败"
      description: "节点 {{ $labels.instance }} 连续2分钟探活失败，请排查服务器硬件、网络或系统状态"

• 该中心独立Prometheus对接现有Alertmanager，触发告警后推送至Slack
• 优势：无需调整现有业务监控链路，改造成本低。

注意事项 #

• 告警规则的for参数建议设置为1~5分钟，避免网络瞬时波动导致的误告警
• 如果服务器禁用ICMP协议，可以替换为探测node exporter的9100端口、SSH 22端口等可用端口
• 需保证中心侧的Prometheus、Alertmanager、探活服务本身的高可用，避免中心服务故障导致告警失效。

内容的提问来源于stack exchange，提问作者Viral