监控告警体系架构设计
监控系统是SRE稳定性工程的基石。一套完整的监控告警体系需要覆盖基础设施层（CPU、内存、磁盘、网络）、中间件层（数据库连接池、消息队列堆积、缓存命中率）和应用层（接口响应时间、错误率、业务指标）。Prometheus作为时序数据库负责指标采集与存储，Grafana负责可视化展示，AlertManager负责告警路由与通知。
监控指标遵循USE原则（Utilization、Saturation、Errors）和RED原则（Rate、Errors、Duration）。USE适用于资源监控，RED适用于服务监控。两个原则结合使用，可以覆盖从硬件到应用的完整监控链路。
Prometheus安装与配置
Prometheus采用Pull模式采集指标，通过Service Discovery自动发现监控目标。以下是生产环境的Prometheus配置：
# /etc/prometheus/prometheus.yml
global:
scrape_interval: 15s
scrape_timeout: 10s
evaluation_interval: 15s
external_labels:
cluster: 'production'
environment: 'prod'
# 告警规则文件
rule_files:
- "/etc/prometheus/rules/*.yml"
# 告警推送配置
alerting:
alertmanagers:
- static_configs:
- targets: ['localhost:9093']
# 采集目标配置
scrape_configs:
# Prometheus自身监控
- job_name: 'prometheus'
static_configs:
- targets: ['localhost:9090']
# Node Exporter - 主机指标
- job_name: 'node'
static_configs:
- targets:
- '192.168.1.101:9100'
- '192.168.1.102:9100'
- '192.168.1.103:9100'
# 应用服务指标
- job_name: 'app'
metrics_path: '/actuator/prometheus'
static_configs:
- targets: ['192.168.1.101:8080']
# 采集超时设置
scrape_timeout: 5s数据保留策略通过启动参数控制。生产环境建议保留15天数据，SSD存储：
# /etc/systemd/system/prometheus.service
[Service]
ExecStart=/usr/local/bin/prometheus \
--config.file=/etc/prometheus/prometheus.yml \
--storage.tsdb.path=/data/prometheus \
--storage.tsdb.retention.time=15d \
--storage.tsdb.retention.size=100GB \
--web.enable-lifecycle \
--web.enable-admin-apiretention.size设置100GB上限，防止磁盘写满导致服务中断。当数据量达到上限时，Prometheus自动删除最旧的数据。
Node Exporter部署与关键指标
Node Exporter采集主机级别的资源指标。安装后默认监听9100端口，暴露约500个指标。关键监控指标如下：
# CPU使用率（排除idle和iowait）
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
# 磁盘空间使用率
(node_filesystem_size_bytes - node_filesystem_avail_bytes) / node_filesystem_size_bytes * 100
# 磁盘I/O等待时间
rate(node_disk_io_time_seconds_total[5m])
# 网络入站带宽（Mbps）
rate(node_network_receive_bytes_total[5m]) * 8 / 1024 / 1024
# TCP连接数
node_netstat_Tcp_CurrEstab磁盘I/O等待时间是一个容易被忽略的指标。当iowait持续超过20%时，说明磁盘已成为性能瓶颈，需要考虑更换SSD或优化I/O密集型应用。TCP连接数突增可能是遭受攻击或应用连接泄漏，需要结合应用日志进行排查。
Grafana仪表盘配置
Grafana通过Prometheus数据源对接，创建仪表盘展示监控指标。以下是一个服务器概览仪表盘的JSON配置片段：
{
"panels": [
{
"title": "CPU使用率",
"type": "graph",
"datasource": "Prometheus",
"targets": [
{
"expr": "100 - (avg by(instance) (rate(node_cpu_seconds_total{mode=\"idle\"}[5m])) * 100)",
"legendFormat": "{{instance}}"
}
],
"thresholds": [
{"value": 80, "color": "orange"},
{"value": 90, "color": "red"}
]
},
{
"title": "内存使用率",
"type": "gauge",
"targets": [
{
"expr": "(node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes) / node_memory_MemTotal_bytes * 100",
"legendFormat": "{{instance}}"
}
],
"fieldConfig": {
"defaults": {
"thresholds": {
"steps": [
{"value": 0, "color": "green"},
{"value": 75, "color": "yellow"},
{"value": 90, "color": "red"}
]
}
}
}
}
]
}仪表盘应遵循从上到下、从全局到细节的布局原则。顶部放置CPU、内存、磁盘、网络等概览面板，中间放置应用服务的关键指标，底部放置日志和事件面板。每个面板设置合理的阈值线，超出阈值时自动变色，便于快速识别异常。
AlertManager告警规则与通知
告警规则定义在Prometheus的rules文件中，AlertManager负责告警的去重、分组、路由和通知。以下是生产环境的告警规则配置：
# /etc/prometheus/rules/alerts.yml
groups:
- name: host_alerts
rules:
# CPU使用率超过80%持续5分钟
- alert: HighCPUUsage
expr: 100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 80
for: 5m
labels:
severity: warning
team: ops
annotations:
summary: "CPU使用率过高 {{ $labels.instance }}"
description: "实例 {{ $labels.instance }} CPU使用率已达 {{ $value }}%"
# 内存使用率超过90%
- alert: HighMemoryUsage
expr: (node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes) / node_memory_MemTotal_bytes * 100 > 90
for: 3m
labels:
severity: critical
team: ops
annotations:
summary: "内存使用率过高 {{ $labels.instance }}"
description: "实例 {{ $labels.instance }} 内存使用率已达 {{ $value }}%"
# 磁盘空间不足
- alert: DiskSpaceLow
expr: (node_filesystem_size_bytes - node_filesystem_avail_bytes) / node_filesystem_size_bytes * 100 > 85
for: 5m
labels:
severity: warning
annotations:
summary: "磁盘空间不足 {{ $labels.instance }} {{ $labels.mountpoint }}"
description: "挂载点 {{ $labels.mountpoint }} 使用率已达 {{ $value }}%"
- name: service_alerts
rules:
# 服务宕机
- alert: ServiceDown
expr: up == 0
for: 1m
labels:
severity: critical
annotations:
summary: "服务不可用 {{ $labels.job }} {{ $labels.instance }}"
description: "目标 {{ $labels.instance }} 已离线超过1分钟"
# 接口错误率过高
- alert: HighErrorRate
expr: sum(rate(http_requests_total{status=~"5.."}[5m])) / sum(rate(http_requests_total[5m])) * 100 > 5
for: 2m
labels:
severity: critical
team: dev
annotations:
summary: "接口错误率过高"
description: "5xx错误率已达 {{ $value }}%"AlertManager的路由配置实现告警分级处理：
# /etc/alertmanager/alertmanager.yml
route:
group_by: ['alertname', 'severity']
group_wait: 30s
group_interval: 5m
repeat_interval: 4h
receiver: 'default'
routes:
# critical级别立即发送
- match:
severity: critical
receiver: 'pagerduty'
group_wait: 0s
repeat_interval: 1h
# warning级别发送到钉钉
- match:
severity: warning
receiver: 'dingtalk'
repeat_interval: 4h
receivers:
- name: 'default'
webhook_configs:
- url: 'http://localhost:8060/dingtalk/webhook/send'
- name: 'pagerduty'
webhook_configs:
- url: 'https://events.pagerduty.com/integration/xxx/enqueue'
- name: 'dingtalk'
webhook_configs:
- url: 'http://localhost:8060/dingtalk/webhook/send?severity=warning'
inhibition_rules:
# 当服务宕机时，抑制该服务的其他告警
- source_match:
alertname: 'ServiceDown'
target_match_re:
alertname: 'HighErrorRate|HighLatency'
equal: ['instance']告警抑制规则（inhibition_rules）是减少告警风暴的关键配置。当ServiceDown告警触发时，同一实例的HighErrorRate和HighLatency告警会被自动抑制，避免一个故障产生数十条告警通知。group_wait和group_interval控制告警的合并窗口，30秒内的相同告警会被合并为一条通知。
告警规则的for参数设置需要权衡灵敏度和误报率。CPU告警设置5分钟的for窗口可以过滤掉瞬时尖峰，但可能延迟真实故障的发现。对于关键服务，建议将for窗口设为1-2分钟，同时调低阈值，配合告警抑制规则控制通知频率。
原创文章，作者：小编，如若转载，请注明出处：https://www.yunthe.com/prometheusgrafana-jian-kong-gao-jing-ti-xi-da-jian-cong-zhi/
