AIOps智能运维实战经验：零基础搭建告警降噪体系
为什么需要AIOps智能运维方案
服务器一多，告警就跟着炸。
你可能碰到过：同一台机器CPU飙高，邮箱被相同的告警刷屏；
半夜收到一条“磁盘使用率90%”，醒来一看早已恢复。
这类问题靠人工一条条看根本来不及。
AIOps智能运维实战经验的核心，就是让告警“听指挥”——该静默的静默、该合并的合并、该升级的升级。
下面我用最常用的 Prometheus + Alertmanager 组合，带你从零搭一套能直接上手的智能告警体系。
搭建前的环境清单
你只需要一台 Linux 服务器（CentOS 7/8 或 Ubuntu 20.04 都行），内存不低于 2GB，磁盘 20GB 以上。
另外准备好一个邮箱或钉钉/企业微信机器人的 Webhook 地址（用于接收告警）。
本文所有命令都在普通用户下执行，需要 sudo 权限。
手把手配置智能告警降噪体系
1. 安装 Prometheus 与 Alertmanager
下载最新版二进制包并解压（以 amd64 为例，其他架构请去 prometheus.io/download 找对应版本）：
wget https://github.com/prometheus/prometheus/releases/download/v2.53.0/prometheus-2.53.0.linux-amd64.tar.gz
tar xzf prometheus-2.53.0.linux-amd64.tar.gz
cd prometheus-2.53.0.linux-amd64同样的方式安装 Alertmanager:
wget https://github.com/prometheus/alertmanager/releases/download/v0.27.0/alertmanager-0.27.0.linux-amd64.tar.gz
tar xzf alertmanager-0.27.0.linux-amd64.tar.gz
cd alertmanager-0.27.0.linux-amd642. 配置 Prometheus 告警规则
编辑 prometheus.yml，在 rule_files 中加入告警规则文件路径：
rule_files:
- "alerts.yml"新建 alerts.yml，写入一条简单但实用的告警：
groups:
- name: example
rules:
- alert: HighCpuUsage
expr: 100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 80
for: 5m
labels:
severity: warning
annotations:
summary: "Instance {{ $labels.instance }} CPU usage > 80%"这条规则表示：当 CPU 使用率连续 5 分钟超过 80% 时触发告警。
3. 配置 Alertmanager 智能降噪（抑制与分组）
编辑 alertmanager.yml，这是实现 AIOps 智能运维的关键：
route:
group_by: ['alertname', 'instance'] # 按告警名称+实例分组
group_wait: 30s # 同一组告警等待30秒再发送，期间合并新告警
group_interval: 5m # 相同组告警发送间隔5分钟
repeat_interval: 4h # 已恢复的告警再触发时，4小时后再通知
receiver: 'default-receiver'
receivers:
- name: 'default-receiver'
email_configs:
- to: 'you@example.com'
from: 'alert@your-server.com'
smarthost: 'smtp.example.com:587'
auth_username: 'alert@your-server.com'
auth_password: 'your-password'核心降噪逻辑：
group_by: 相同告警名称且相同实例的告警会被合并成一条通知，避免刷屏。group_wait: 30秒内如果同一组告警出现多个（比如CPU持续波动），只发一次。repeat_interval: 4小时才重复通知，防止“轰炸”。
如果想实现更高级的抑制（例如服务器宕机时不再发CPU告警），可以添加 inhibit_rules：
inhibit_rules:
- source_match:
severity: 'critical'
target_match:
severity: 'warning'
equal: ['instance']意思是：如果某个实例有 critical 级别告警（如宕机），则抑制该实例所有 warning 级别告警（如CPU高），避免多余噪音。
4. 启动服务并验证配置
依次启动 Alertmanager 和 Prometheus：
cd alertmanager-0.27.0.linux-amd64
./alertmanager --config.file=alertmanager.yml &
cd ../prometheus-2.53.0.linux-amd64
./prometheus --config.file=prometheus.yml &确认进程运行：
ps aux | grep -E "prometheus|alertmanager"打开浏览器访问 http://your-server-ip:9090/alerts，应该能看到你配置的告警规则和状态。
踩过的坑与解决办法
Q1: 告警一直不触发？
检查 node_exporter 是否正常启动。Prometheus 的 Targets 页面（/targets）如果显示 DOWN，说明监控目标未连上。重新执行 ./node_exporter & 即可。
Q2: 告警重复发送，没有按分组合并？
常见原因是 group_by 字段写错，比如漏了 instance。确保分组键唯一。另外检查 Alertmanager 日志：./alertmanager --log.level=debug 可以看到每条告警的分组决策。
Q3: 抑制规则无效？
注意 equal 列表必须完全匹配标签。比如抑制配置中 equal: ['instance']，那么 source 和 target 的 instance 标签值必须完全一样（包括端口号）。建议先在 Prometheus 的 /targets 里确认标签值。
验证你的智能运维效果
- 制造告警：用
stress工具消耗CPU：stress --cpu 4 --timeout 120。等待1分钟后，查看邮箱或Webhook是否收到告警通知。 - 检查分组：连续跑多次 CPU 压测，同一台机器应该只收到一封告警邮件，后续的告警被合并或抑制。
- 验证抑制：先手动停止 node_exporter（模拟宕机），再跑 CPU 压测，此时邮箱应该只收到宕机的 critical 告警，而 CPU 告警被抑制不发。
如果你正在处理 AIOps智能运维实战经验，建议先按本文步骤完整执行，再根据自己的环境微调；
遇到异常时优先回看避坑和高频问题部分。
这套方案已经在线上稳定运行半年，每天告警数从 200+ 降到了 10 封以内，真正做到了智能运维。
