标签：#SRE #Prometheus #Grafana #DevOps #监控告警 #运维
🛡️ 前言：为什么选择“黄金三角”？
- Prometheus：基于Pull (拉取)模型的时序数据库。哪怕你的应用挂了，Prometheus 依然活着，能准确记录“死亡时刻”。
- Grafana：颜值即正义。它能把枯燥的 metrics 数据变成老板爱看的高大上大屏。
- AlertManager：告警收敛神器。防止一出故障手机被 1000 条短信轰炸，它能通过分组、抑制、静默，只发最关键的那一条。
🏗️ 一、 架构设计：数据流是如何跑通的？
监控的核心逻辑：采集 -> 存储 -> 计算 -> 展示/告警。
监控体系架构图 (Mermaid):
🛠️ 二、 极速部署：Docker Compose 一键拉起
为了方便管理，我们将所有组件编排在一个docker-compose.yml中。
目录结构：
monitor/ ├── docker-compose.yml ├── prometheus/ │ └── prometheus.yml ├── alertmanager/ │ └── config.yml └── grafana/ └── provisioning/ (可选)docker-compose.yml:
version:'3.8'services:# 1. Prometheus: 大脑prometheus:image:prom/prometheus:latestcontainer_name:prometheusvolumes:-./prometheus/:/etc/prometheus/-prometheus_data:/prometheuscommand:-'--config.file=/etc/prometheus/prometheus.yml'-'--storage.tsdb.retention.time=15d'# 数据保留15天ports:-"9090:9090"# 2. Grafana: 脸面grafana:image:grafana/grafana:latestcontainer_name:grafanaports:-"3000:3000"volumes:-grafana_data:/var/lib/grafana# 3. AlertManager: 喉舌alertmanager:image:prom/alertmanager:latestcontainer_name:alertmanagerports:-"9093:9093"volumes:-./alertmanager/:/etc/alertmanager/command:-'--config.file=/etc/alertmanager/config.yml'# 4. Node Exporter: 采集器 (监控本机)node-exporter:image:prom/node-exporter:latestcontainer_name:node-exporterports:-"9100:9100"volumes:prometheus_data:grafana_data:🧠 三、 配置 Prometheus：连接采集器与告警器
编写prometheus/prometheus.yml。
global:scrape_interval:15s# 每15秒抓一次数据# 关联 AlertManageralerting:alertmanagers:-static_configs:-targets:['alertmanager:9093']# 告警规则文件 (后面会写)rule_files:-"rules/*.yml"# 抓取目标scrape_configs:-job_name:'prometheus'static_configs:-targets:['localhost:9090']-job_name:'node'static_configs:-targets:['node-exporter:9100']# 抓取本机指标📊 四、 配置 Grafana：点亮监控大屏
- 启动服务：
docker-compose up -d。 - 访问
http://localhost:3000(默认账号 admin/admin)。 - 添加数据源：Configuration -> Data Sources -> Add -> 选择 Prometheus -> URL 填
http://prometheus:9090-> Save & Test。 - 导入仪表盘 (Dashboard)：
- 不要自己画图！去 Grafana 官网找现成的模板。
- 推荐 ID:1860(Node Exporter Full)。
- 点击 Import -> 输入 1860 -> Load -> 选择刚才的数据源 -> Import。
效果：瞬间拥有了一个包含 CPU、内存、磁盘 IO、网络流量的专业级服务器监控面板。
🚨 五、 告警实战：从“CPU 飙高”到“钉钉通知”
监控不告警，等于没监控。
1. 定义告警规则 (prometheus/rules/host.yml)
我们在 Prometheus 端定义“什么是故障”。
groups:-name:HostAlertsrules:-alert:HighCpuUsage# 表达式: CPU 使用率 > 80% 持续 1分钟expr:(100-(avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[1m])) * 100))>80for:1mlabels:severity:warningannotations:summary:"实例 {{ $labels.instance }} CPU 过高"description:"当前 CPU 使用率: {{ $value }}%"2. 配置告警发送 (alertmanager/config.yml)
在 AlertManager 端定义“故障发给谁”。推荐使用 Webhook 对接钉钉或企业微信群机器人。
global:resolve_timeout:5mroute:group_by:['alertname']group_wait:10sgroup_interval:10srepeat_interval:1h# 1小时内不重复轰炸receiver:'dingtalk'receivers:-name:'dingtalk'webhook_configs:# 这里推荐使用专门的 prometheus-webhook-dingtalk 转换器# 或者直接写一个简单的 Python/Go 服务接收 JSON 并转发给钉钉-url:'http://webhook-adapter:8060/dingtalk/send'☕ 六、 企业级 SRE 进阶建议
搭建好只是第一步，要达到企业级标准，还需注意以下痛点：
- 服务发现 (Service Discovery)：
不要在prometheus.yml里写死 IP。线上机器经常扩缩容，建议使用Consul或Kubernetes (ServiceMonitor)进行自动发现。 - 存储瓶颈：
Prometheus 本地存储不适合存长期数据。如果需要查看 1 年前的趋势，建议通过 Remote Write 对接VictoriaMetrics或Thanos。 - 告警收敛：
当核心交换机挂了，下面 100 台服务器都会报“网络不可达”。
需要在 AlertManager 配置inhibit_rules(抑制规则)：如果交换机挂了，就屏蔽掉所有服务器的告警，只发一条交换机故障的通知。
🎯 总结
通过 Prometheus + Grafana + AlertManager，我们构建了一套闭环的监控运维体系。
- 采集：看到系统的每一个毛孔。
- 可视化：让数据会说话。
- 告警：在用户投诉前发现问题。
对于 SRE 来说，监控不是为了证明系统有多好，而是为了在系统变坏时，我们能第一个知道。
Next Step:
尝试编写一个简单的Python Exporter。只用不到 20 行代码，通过prometheus_client库，把你关注的业务指标（如“今日订单数”、“接口报错率”）暴露出来，并在 Grafana 上画出折线图。
