开源监控告警如何配置？

wen 开源项目 2026-06-08 51

本文目录导读：

开源监控告警如何配置？

核心组件与作用
配置步骤（Prometheus + Alertmanager）
常见告警通知渠道配置
高级功能：分组与抑制（Alertmanager 核心价值）
Grafana 告警（可选，适合不想写 PromQL 的用户）
常见问题排查
生产环境建议

配置开源监控告警系统,通常包含指标采集、告警规则定义、告警通知和可视化四个核心环节，由于“开源监控”选项很多（如 Prometheus + Alertmanager、Zabbix、Grafana + Loki + Mimir 等），下面以最流行的 Prometheus + Alertmanager 组合为例，提供一套标准配置流程。

核心组件与作用

Prometheus：负责采集、存储指标数据，并根据预设规则触发告警。
Alertmanager：接收 Prometheus 的告警，进行分组、抑制、静默，并发送通知（邮件、企业微信、钉钉等）。
Grafana（可选，但推荐）：可视化仪表盘，也可在其内部直接配置告警。

配置步骤（Prometheus + Alertmanager）

安装并配置 Prometheus

文件：prometheus.yml

global:
  scrape_interval: 15s      # 数据采集间隔
  evaluation_interval: 15s  # 告警规则评估间隔（建议与scrape一致）
# 告警规则文件路径（支持通配符）
rule_files:
  - "rules/*.yml"
# 采集目标配置（示例：监控本机、Node Exporter、业务服务）
scrape_configs:
  - job_name: 'prometheus'
    static_configs:
      - targets: ['localhost:9090']
  - job_name: 'node_exporter'
    static_configs:
      - targets: ['192.168.1.10:9100', '192.168.1.11:9100']
  - job_name: 'business_app'
    metrics_path: '/metrics'
    static_configs:
      - targets: ['192.168.1.20:8080']
# 告警推送目标：Alertmanager 服务地址
alerting:
  alertmanagers:
    - static_configs:
        - targets:
          - localhost:9093

编写告警规则

在 rules/ 目录下创建规则文件，node_alerts.yml：

groups:
  - name: node_alerts
    interval: 30s            # 该组规则评估周期
    rules:
      - alert: HighCpuUsage
        expr: 100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 80
        for: 5m              # 持续5分钟超过阈值才触发（防止波动误报）
        labels:
          severity: warning
        annotations:
          summary: "CPU 使用率超过 80% (instance: {{ $labels.instance }})"
          description: "CPU 使用率当前为 {{ $value }}%"
      - alert: DiskSpaceLow
        expr: (node_filesystem_avail_bytes{mountpoint="/"} / node_filesystem_size_bytes{mountpoint="/"}) * 100 < 10
        for: 2m
        labels:
          severity: critical
        annotations:
          summary: "磁盘空间不足 (instance: {{ $labels.instance }})"
          description: "根分区可用空间仅剩 {{ $value | humanizePercentage }}"

关键字段说明：

expr：PromQL 查询语句，决定触发条件。
for：持续多久才触发，避免瞬时抖动。
labels：可自定义 severity（warning/critical 等），用于 Alertmanager 分组。
annotations：告警时的描述信息，支持模板变量 {{ $labels.xxx }} 和 {{ $value }}。

配置 Alertmanager

文件：alertmanager.yml

global:
  resolve_timeout: 5m        # 告警自动恢复后，多久标记为已解决
route:
  group_by: ['alertname', 'severity']   # 按告警名称和严重级别分组
  group_wait: 30s            # 同一组告警的等待时间，收集更多同类告警
  group_interval: 5m         # 同一组告警的重复通知间隔
  repeat_interval: 4h        # 已发送的告警，多久再次发送（防止持续骚扰）
  receiver: 'default'        # 默认接收人
receivers:
  - name: 'default'
    # 这里以邮件为例，其他通知方式见下文
    email_configs:
      - to: 'ops@example.com'
        from: 'alert@example.com'
        smarthost: 'smtp.example.com:587'
        auth_username: 'alert@example.com'
        auth_password: 'your_password'
        require_tls: true

提醒：上方的 group_wait、group_interval、repeat_interval 是控制告警风暴的关键参数，建议根据业务容忍度调整。

热加载配置

修改 prometheus.yml 或规则文件后，向 Prometheus 发送 SIGHUP 信号或访问其 API：

# 方式1：curl 热加载
curl -X POST http://localhost:9090/-/reload
# 方式2：系统命令（需 root）
kill -HUP $(pgrep prometheus)

对于 Alertmanager，同样支持 SIGHUP 或 UI 页面 reload。

常见告警通知渠道配置

企业微信机器人（最常用）

receivers:
  - name: 'wechat'
    wechat_configs:
      - send_resolved: true
        api_url: 'https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=你的WebhookKey'
        message_type: 'markdown'

钉钉机器人

- name: 'dingtalk'
  webhook_configs:
    - url: 'https://oapi.dingtalk.com/robot/send?access_token=你的Token'
      send_resolved: false
      message_type: 'text'

Slack

- name: 'slack'
  slack_configs:
    - api_url: 'https://hooks.slack.com/services/T000000/B000000/xxx'
      channel: '#monitor'
      send_resolved: true

邮件（SMTP）

参考上文 receivers.email_configs，注意需配置 auth_username 和 auth_password（部分企业邮箱需使用授权码）。

高级功能：分组与抑制（Alertmanager 核心价值）

分组：当多个相似告警（如“服务器A磁盘满”、“服务器B磁盘满”）同时触发，Alertmanager 会将它们合并为一条通知，避免消息轰炸。
抑制：如果某主机整体挂掉（node_exporter 超时），那么该主机的所有子告警（如 CPU、磁盘、内存）都会被自动抑制，只发一条“主机不可达”。
静默：在维护窗口期，可以手动在 Alertmanager UI 添加静默规则，忽略指定标签的告警。

Grafana 告警（可选，适合不想写 PromQL 的用户）

在 Grafana 中配置数据源（如 Prometheus）。
进入某个 Dashboard，点击图表 → Alert → Create Alert。
图形化定义阈值（如“CPU > 80%”）、评估间隔、通知渠道（邮件、钉钉等）。
优点：无需学习 PromQL，适合快速搭建。
缺点：复杂逻辑不如原生 Prometheus 规则强大。

常见问题排查

问题现象	排查命令/方法
告警未触发	`curl http://localhost:9090/api/v1/alerts` 查看当前告警状态
告警未收到通知	检查 Alertmanager 日志 `/var/log/alertmanager/alertmanager.log`
规则语法错误	使用 `promtool check rules rules/*.yml` 校验规则文件
采集目标异常	访问 `http://localhost:9090/targets` 查看各目标状态
通知超时	检查网络连通性、SMTP 端口、Webhook URL 是否正确

生产环境建议

使用高可用部署：至少双节点 Prometheus（可通过 Thanos、VictoriaMetrics 做远程存储）和双节点 Alertmanager（自带高可用，互相去重）。
分级告警：warning（邮件/群聊）、critical（电话/短信）、disaster（PagerDuty、Opsgenie）。

动态通知：根据 severity 标签走不同路由，

route:
  routes:
    - match:
        severity: critical
      receiver: 'phone'
    - match:
        severity: warning
      receiver: 'wechat'

周期性健康检查：监控 Prometheus 自身采集延迟、Alertmanager 队列积压。

如果你有特定的监控对象（如数据库、Kubernetes、自定义业务指标）或偏好的技术栈（如 Zabbix、夜莺、Open-Falcon），可以进一步说明，我可以提供更针对性的配置示例。