AIOps破解运维困局

AIOps 全链路智能运维 168 篇连载 · 开篇总览

阶段一：AIOps 架构导论

第 1 篇：传统监控致命缺陷｜全新一代指标日志一体化 AIOps 智能运维架构总览

1. 业务痛点

企业运维团队在日常工作中普遍面临以下核心痛点：

传统监控体系只能看基础 CPU、内存、磁盘指标，当故障发生时，运维人员需要在多个系统间切换，无法快速定位根因，更无法实现自动化修复。

2. 组件架构定位与在整体 AIOps 链路中的作用

本方案构建的 AIOps 全链路架构包含 12 个核心层级，形成完整的监控 – 告警 – 分析 – 自愈闭环：

┌─────────────────────────────────────────────────────────────────┐
│ 可视化观测层 (Grafana) │
├─────────────────────────────────────────────────────────────────┤
│ 运维沉淀层 (故障归档/知识库迭代) │
├─────────────────────────────────────────────────────────────────┤
│ 自愈执行层 (N8N→AWX→Agent) │
├─────────────────────────────────────────────────────────────────┤
│ 知识库检索层 (向量数据库) │
├─────────────────────────────────────────────────────────────────┤
│ AI 智能分析层 (LLM 大模型) │
├─────────────────────────────────────────────────────────────────┤
│ 事件编排层 (N8N 告警清洗/分级/去重) │
├─────────────────────────────────────────────────────────────────┤
│ 告警治理层 (Alertmanager 分组/抑制/静默) │
├─────────────────────────────────────────────────────────────────┤
│ 规则计算层 (本地规则+Thanos Ruler) │
├─────────────────────────────────────────────────────────────────┤
│ 时序存储层 (Thanos/VictoriaMetrics) │
├─────────────────────────────────────────────────────────────────┤
│ 分布式采集层 (Prometheus Agent) │
├─────────────────────────────────────────────────────────────────┤
│ 服务注册层 (Consul 动态服务发现) │
├─────────────────────────────────────────────────────────────────┤
│ 全覆盖采集层 (指标 + 日志 + 拨测 + 网络) │
└─────────────────────────────────────────────────────────────────┘

各层级核心职责：

• 采集层：统一纳管 Linux/Windows 服务器、网络设备、中间件、数据库、K8s 集群、业务日志
• 存储层：Thanos 分布式架构解决单点瓶颈，支持超长期数据存储
• 告警层：Alertmanager 实现告警分组、抑制、静默、多渠道通知
• 编排层：N8N 低代码平台实现告警标准化、分级、去重、结构化
• AI 层：LLM 大模型自动摘要、根因推理、故障建议生成
• 自愈层：AWX+Agent 批量执行远程故障修复脚本

3. 环境准备、版本选择、端口规划、资源需求

3.1 版本选型建议

3.2 端口规划表

3.3 资源需求估算

4. 三套部署方案：裸机部署、Docker Compose 部署、Kubernetes 部署

4.1 裸机二进制部署（生产推荐）

优势：性能最优、资源开销最小、便于深度调优

适用场景：物理机集群、对性能要求严苛的生产环境

# 创建目录结构
mkdir -p /opt/aiops/{prometheus,alertmanager,grafana,thanos,consul}
cd /opt/aiops/prometheus

# 下载二进制包
wget https://github.com/prometheus/prometheus/releases/download/v2.45.0/prometheus-2.45.0.linux-amd64.tar.gz
tar -xzf prometheus-2.45.0.linux-amd64.tar.gz
mv prometheus-2.45.0.linux-amd64/* .

# 创建 systemd 服务
cat > /etc/systemd/system/prometheus.service <<EOF
[Unit]
Description=Prometheus Server
After=network.target

[Service]
User=prometheus
Group=prometheus
ExecStart=/opt/aiops/prometheus/prometheus \\
–config.file=/opt/aiops/prometheus/prometheus.yml \\
–storage.tsdb.path=/opt/aiops/prometheus/data \\
–storage.tsdb.retention.time=15d \\
–web.listen-address=:9090
Restart=always

[Install]
WantedBy=multi-user.target
EOF

systemctl daemon-reload
systemctl enable prometheus
systemctl start prometheus

4.2 Docker Compose 部署（测试/开发推荐）

优势：部署简单、便于迁移、环境隔离

适用场景：测试环境、开发环境、快速验证

# docker-compose.yml
version: '3.8'
services:
prometheus:
image: prom/prometheus:v2.45.0
container_name: prometheus
ports:
– "9090:9090"
volumes:
– ./prometheus.yml:/etc/prometheus/prometheus.yml
– prometheus_data:/prometheus
command:
– '–config.file=/etc/prometheus/prometheus.yml'
– '–storage.tsdb.path=/prometheus'
– '–storage.tsdb.retention.time=15d'
restart: always

alertmanager:
image: prom/alertmanager:v0.26.0
container_name: alertmanager
ports:
– "9093:9093"
volumes:
– ./alertmanager.yml:/etc/alertmanager/alertmanager.yml
restart: always

grafana:
image: grafana/grafana:10.0.0
container_name: grafana
ports:
– "3000:3000"
volumes:
– grafana_data:/var/lib/grafana
environment:
– GF_SECURITY_ADMIN_PASSWORD=admin123
restart: always

volumes:
prometheus_data:
grafana_data:

# 启动服务
docker-compose up -d

# 查看状态
docker-compose ps

# 查看日志
docker-compose logs -f prometheus

4.3 Kubernetes 集群部署（云原生推荐）

优势：高可用、弹性伸缩、自动故障恢复

适用场景：K8s 生产环境、云原生架构

# prometheus-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: prometheus
namespace: monitoring
spec:
replicas: 2
selector:
matchLabels:
app: prometheus
template:
metadata:
labels:
app: prometheus
spec:
containers:
– name: prometheus
image: prom/prometheus:v2.45.0
ports:
– containerPort: 9090
volumeMounts:
– name: config
mountPath: /etc/prometheus
– name: data
mountPath: /prometheus
args:
– –config.file=/etc/prometheus/prometheus.yml
– –storage.tsdb.path=/prometheus
– –storage.tsdb.retention.time=15d
volumes:
– name: config
configMap:
name: prometheus-config
– name: data
persistentVolumeClaim:
claimName: prometheus-pvc
—
apiVersion: v1
kind: Service
metadata:
name: prometheus
namespace: monitoring
spec:
selector:
app: prometheus
ports:
– port: 9090
targetPort: 9090
type: ClusterIP

# 部署到 K8s 集群
kubectl apply -f prometheus-deployment.yaml

# 验证部署
kubectl get pods -n monitoring
kubectl get svc -n monitoring

# 端口转发访问
kubectl port-forward svc/prometheus 9090:9090 -n monitoring

5. 核心配置文件详解（全中文注释）

5.1 Prometheus 主配置文件

# prometheus.yml – Prometheus 核心配置文件

# 全局配置
global:
scrape_interval: 15s # 默认抓取间隔 15 秒
evaluation_interval: 15s # 规则评估间隔 15 秒
external_labels:
monitor: 'aiops-monitor' # 外部标签，用于 Thanos 区分集群
region: 'cn-beijing' # 区域标签

# 告警管理器配置
alerting:
alertmanagers:
– static_configs:
– targets:
– alertmanager:9093 # Alertmanager 地址

# 规则文件路径
rule_files:
– /opt/aiops/prometheus/rules/*.yml

# 抓取配置
scrape_configs:
# Prometheus 自监控
– job_name: 'prometheus'
static_configs:
– targets: ['localhost:9090']
labels:
instance_type: 'monitoring'

# Node Exporter 服务器监控
– job_name: 'node_exporter'
static_configs:
– targets: ['node1:9100', 'node2:9100', 'node3:9100']
labels:
instance_type: 'server'

# Blackbox 拨测监控
– job_name: 'blackbox_http'
metrics_path: /probe
params:
module: [http_2xx]
static_configs:
– targets:
– https://www.example.com
relabel_configs:
– source_labels: [__address__]
target_label: __param_target
– source_labels: [__param_target]
target_label: instance
– target_label: __address__
replacement: blackbox:9115

# Consul 服务发现
– job_name: 'consul_services'
consul_sd_configs:
– server: consul:8500
services: []
relabel_configs:
– source_labels: [__meta_consul_service]
target_label: job

5.2 Alertmanager 配置文件

# alertmanager.yml – 告警管理器配置

global:
smtp_smarthost: 'smtp.example.com:587'
smtp_from: 'alertmanager@example.com'
smtp_auth_username: 'alertmanager@example.com'
smtp_auth_password: 'password123'

# 路由树配置
route:
receiver: 'default-receiver' # 默认接收器
group_by: ['alertname', 'cluster'] # 告警分组维度
group_wait: 30s # 组等待时间
group_interval: 5m # 组间隔时间
repeat_interval: 4h # 重复通知间隔

# 子路由 – 按严重程度分流
routes:
– match:
severity: critical
receiver: 'critical-receiver'
group_wait: 10s
repeat_interval: 1h
– match:
severity: warning
receiver: 'warning-receiver'
repeat_interval: 4h

# 接收器配置
receivers:
– name: 'default-receiver'
email_configs:
– to: 'ops-team@example.com'
send_resolved: true

– name: 'critical-receiver'
webhook_configs:
– url: 'http://n8n:5678/webhook/alertmanager'
send_resolved: true
email_configs:
– to: 'oncall@example.com'
send_resolved: true

– name: 'warning-receiver'
email_configs:
– to: 'ops-team@example.com'
send_resolved: true

# 抑制规则 – 防止告警风暴
inhibit_rules:
– source_match:
severity: 'critical'
target_match:
severity: 'warning'
equal: ['alertname', 'cluster', 'service']

# 静默规则
silencers:
– matchers:
– name: alertname
value: 'TestAlert'
startsAt: '2024-01-01T00:00:00Z'
endsAt: '2024-01-01T23:59:59Z'

6. 功能验证、指标抓取验证、服务可用性验证

6.1 Prometheus 服务验证

# 检查服务状态
systemctl status prometheus

# 检查端口监听
netstat -tlnp | grep 9090

# 检查 API 健康状态
curl -s http://localhost:9090/api/v1/status/config | jq .

# 检查目标抓取状态
curl -s http://localhost:9090/api/v1/targets | jq '.data.activeTargets[].health'

6.2 指标抓取验证

# 查询 Prometheus 自身指标
curl -s 'http://localhost:9090/api/v1/query?query=prometheus_tsdb_head_samples_appended_total' | jq .

# 查询 Node Exporter 指标
curl -s 'http://localhost:9090/api/v1/query?query=node_cpu_seconds_total' | jq .

# 验证指标时间范围
curl -s 'http://localhost:9090/api/v1/query_range?query=up&start=2024-01-01T00:00:00Z&end=2024-01-01T23:59:59Z&step=1m' | jq .

6.3 Grafana 数据源验证

6.4 告警链路验证

# 手动触发测试告警
cat > /tmp/test_alert.yml <<EOF
groups:
– name: test_alert
rules:
– alert: TestAlert
expr: vector(1)
for: 10s
labels:
severity: critical
annotations:
summary: "测试告警"
description: "验证告警链路"
EOF

# 重载 Prometheus 配置
curl -X POST http://localhost:9090/-/reload

# 查看告警状态
curl -s http://localhost:9090/api/v1/rules | jq .

7. 组件自监控配置、对应 Exporter 指标采集、告警规则配置

7.1 Prometheus 自监控指标

# prometheus_self_monitor.yml
groups:
– name: prometheus_self
rules:
– alert: PrometheusDown
expr: absent(up{job="prometheus"})
for: 1m
labels:
severity: critical
annotations:
summary: "Prometheus 服务宕机"
description: "Prometheus 实例 {{ $labels.instance }} 已宕机超过 1 分钟"

– alert: PrometheusTargetMissing
expr: up == 0
for: 5m
labels:
severity: warning
annotations:
summary: "监控目标丢失"
description: "目标 {{ $labels.instance }} 已失联超过 5 分钟"

– alert: PrometheusStoragePressure
expr: prometheus_tsdb_storage_blocks_bytes_total / prometheus_tsdb_storage_blocks_bytes_max > 0.9
for: 10m
labels:
severity: warning
annotations:
summary: "Prometheus 存储压力过大"
description: "存储使用率超过 90%"

7.2 Node Exporter 核心告警规则

# node_exporter_alerts.yml
groups:
– name: node_alerts
rules:
– alert: HighCPUUsage
expr: 100 – (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 80
for: 10m
labels:
severity: warning
annotations:
summary: "CPU 使用率过高"
description: "实例 {{ $labels.instance }} CPU 使用率超过 80%"

– alert: HighMemoryUsage
expr: (1 – (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes)) * 100 > 85
for: 10m
labels:
severity: warning
annotations:
summary: "内存使用率过高"
description: "实例 {{ $labels.instance }} 内存使用率超过 85%"

– alert: DiskSpaceLow
expr: (node_filesystem_avail_bytes / node_filesystem_size_bytes) * 100 < 15
for: 30m
labels:
severity: critical
annotations:
summary: "磁盘空间不足"
description: "实例 {{ $labels.instance }} 磁盘可用空间低于 15%"

– alert: NodeDown
expr: up{job="node_exporter"} == 0
for: 5m
labels:
severity: critical
annotations:
summary: "服务器宕机"
description: "服务器 {{ $labels.instance }} 已宕机超过 5 分钟"

8. 工具高级用法、生产最佳实践

8.1 PromQL 高级查询技巧

# 计算 5 分钟平均 CPU 使用率
100 – (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)

# 计算内存使用率
(1 – (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes)) * 100

# 计算磁盘 IO 等待时间
rate(node_disk_io_time_seconds_total[5m]) * 100

# 计算网络带宽使用
rate(node_network_receive_bytes_total{device="eth0"}[5m]) * 8

# 预测磁盘何时写满
predict_linear(node_filesystem_avail_bytes{mountpoint="/"}[6h], 24*3600)

# 同比/环比分析
# 本周 vs 上周同一时间
rate(http_requests_total[5m]) / rate(http_requests_total[5m] offset 7d)

8.2 生产环境最佳实践

8.3 性能调优参数

# Prometheus 启动参数优化
–storage.tsdb.retention.time=15d # 数据保留时间
–storage.tsdb.min-block-duration=2h # 最小块时长
–storage.tsdb.max-block-duration=2h # 最大块时长
–storage.tsdb.wal-compression=true # WAL 压缩
–web.max-connections=512 # 最大连接数
–query.max-concurrency=20 # 查询并发数
–query.timeout=2m # 查询超时时间

9. 生产踩坑清单、故障排查、架构优化方案

9.1 常见踩坑清单

9.2 故障排查流程

1. 检查服务状态
systemctl status prometheus
docker-compose ps

2. 查看服务日志
journalctl -u prometheus -f
docker-compose logs prometheus

3. 检查配置文件语法
promtool check config prometheus.yml
promtool check rules rules/*.yml

4. 验证 API 健康
curl http://localhost:9090/api/v1/status/config

5. 检查目标抓取
curl http://localhost:9090/api/v1/targets

6. 测试 PromQL 查询
curl 'http://localhost:9090/api/v1/query?query=up'

9.3 架构优化方案

小型环境（<500 目标）

• 单 Prometheus + 单 Alertmanager + 单 Grafana
• 本地存储 15 天
• 无需 Thanos

中型环境（500-2000 目标）

• 2 Prometheus 高可用 + Thanos Sidecar
• MinIO 对象存储
• Thanos Query 统一查询

大型环境（>2000 目标）

• 多 Prometheus 分片 + Prometheus Agent 分布式采集
• Thanos 完整架构（Sidecar/Query/Store/Compactor/Ruler）
• 多副本、跨集群查询、下采样

10. 本篇小结 + 下篇预告

本篇小结

本文作为 AIOps 全链路智能运维 168 篇连载的开篇，系统阐述了：

下篇预告

第 2 篇：全组件全景拆解：Prometheus 全生态 + 日志 + 拨测 + 网络 +AI 自愈完整技术栈讲解

下篇将深入拆解本 AIOps 平台的完整技术栈，包括：

• Prometheus 官方原生组件全家桶
• CNCF 生态组件全景图
• 全品类 Exporter 覆盖清单
• 日志体系 Loki+Promtail 架构
• 分布式时序存储四大方案对比
• 服务发现体系 Consul 深度解析
• AI 智能运维 LLM+ 向量数据库架构
• 自动化自愈 AWX+Agent 平台设计

敬请期待！