1. 架构总览
整套体系只有四个核心组件，理解它们的关系就够了：
+----------------+ scrape +--------------+ query +----------------+
| node_exporter | ─────────► | Prometheus | ◄───────── | Grafana |
| (业务 exporter)| /metrics | (存储+告警) | | (可视化面板) |
+----------------+ +------+-------+ +----------------+
│ alert
▼
+----------------+
| Alertmanager | ──► 企业微信 / 钉钉 / Slack
+----------------+- Exporter —— 把各种指标暴露成 HTTP
/metrics端点。 - Prometheus —— 定时拉取（scrape）指标，存储并执行告警规则。
- Alertmanager —— 负责告警的去重、分组与路由通知。
- Grafana —— 可视化面板，把时序数据画成图。
2. 数据采集：node_exporter
先采集最基础的节点指标。用 docker-compose 一分钟拉起整个监控栈：
# docker-compose.yml
services:
prometheus:
image: prom/prometheus:v2.53.0
volumes:
- ./prometheus.yml:/etc/prometheus/prometheus.yml
ports:
- "9090:9090"
node-exporter:
image: prom/node-exporter:v1.8.2
network_mode: host
restart: unless-stopped
grafana:
image: grafana/grafana:11.1.0
ports:
- "3000:3000"
environment:
GF_SECURITY_ADMIN_PASSWORD: admin配置抓取目标（prometheus.yml）：
global:
scrape_interval: 15s
evaluation_interval: 15s
scrape_configs:
- job_name: 'node'
static_configs:
- targets: ['192.168.1.10:9100', '192.168.1.11:9100']
- job_name: 'nginx'
static_configs:
- targets: ['192.168.1.10:9113']
生产环境建议
使用 Service Discovery（Consul、K8s 或文件发现）自动注册目标，不要手动维护
static_configs，节点一多就会变成维护噩梦。
3. 告警规则：Prometheus 的表达式语言
PromQL 是这套体系的核心语言。看几条最常用的规则：
groups:
- name: node-alerts
rules:
- alert: NodeDown
expr: up == 0
for: 2m
annotations:
summary: "节点 {{ $labels.instance }} 已失联"
- alert: DiskSpaceLow
expr: (1 - (node_filesystem_avail_bytes /
node_filesystem_size_bytes)) * 100 > 85
for: 10m
annotations:
summary: "{{ $labels.instance }} 磁盘使用率超过 85%"
- alert: HighCPULoad
expr: node_load1 > 4
for: 5mup—— Prometheus 自带指标，抓取成功为 1，失败为 0。for: 2m—— 持续满足条件 2 分钟才触发告警，用来过滤瞬时抖动。- 阈值设定原则：先跑起来，再基于历史数据收敛，避免一上来就告警轰炸。
告警疲劳
告警规则宁少勿滥。每个告警都应该是「能执行的动作」——收到告警即行动，
而不是「知道了」。无法响应的告警直接删除。
4. 可视化与告警通知
Grafana 里导入官方 dashboard（ID: 1860 是经典的 node_exporter 面板），或从零创建。
常用 PromQL 示例：
# CPU 使用率
100 - (avg by (instance) (rate(node_cpu_seconds_total{
mode="idle"}[5m])) * 100)
# 内存使用率
(node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes)
/ node_memory_MemTotal_bytes * 100
# 磁盘读写速率（字节/秒）
rate(node_disk_read_bytes_total[5m])告警通知路由示例（alertmanager.yml）：
route:
group_by: ['alertname', 'cluster']
group_wait: 30s
group_interval: 5m
repeat_interval: 4h
receiver: wechat
receivers:
- name: wechat
wechat_configs:
- corp_id: xxx
agent_id: 1000002
api_secret: xxx
to_user: '@all'5. 高可用与容量规划
- 单机规模（节点 < 50）—— 单实例 Prometheus 完全够用，数据保留 15 天。
- 横向扩展 —— 用 Thanos 或 VictoriaMetrics 做联邦与长期存储，避免单点。
- 多副本告警 —— 关键环境跑两个 Prometheus 副本，由 Alertmanager 的
group_wait/ 高可用特性去重，防止重复告警轰炸。 - 容量估算 —— 每个 target 约占用 10~20 MB 内存，50 个 target 约 1 GB。按此粗略规划。
至此，一套「采集 → 存储 → 告警 → 可视化」的完整监控体系已经跑通。 下一步就是基于真实告警不断收敛阈值，让监控体系从「能响」进化到「好用」。
