马哥Linux运维 | Prometheus 告警规则生产级配置：50+ 核心指标与最佳实践(二)

本文来源公众号“马哥Linux运维”，仅用于学术分享，侵权删，干货满满。

原文链接：https://mp.weixin.qq.com/s/X4ADdHOXtQw5Hy5iQSal8A

文章略长，分为(一)、(二)、(三)和(四)两部分，一起学习吧！

马哥Linux运维 | Prometheus 告警规则生产级配置：50+ 核心指标与最佳实践(一)-优快云博客

7️⃣ 最小必要原理

PromQL 查询引擎核心机制

时间序列数据模型：Prometheus 将所有指标存储为时间序列，每个时间序列由指标名称 + 标签集唯一标识：

node_cpu_seconds_total{cpu="0", mode="idle", instance="192.168.1.10:9100", job="node_exporter"}

查询执行流程：

1. 1. 选择器解析：up{job="node_exporter"} → 找到所有匹配标签的时间序列

2. 2. 范围向量计算：[5m] → 提取过去 5 分钟的所有数据点

3. 3. 函数执行：rate() → 计算每秒平均变化率

4. 4. 聚合操作：sum by(instance) → 按 instance 标签分组求和

5. 5. 比较判断：> 80 → 返回满足条件的时间序列

告警规则评估机制：

PromQL 查询 → 返回向量 → for 持续时间判断 → 状态转换 → 发送到 Alertmanager

状态转换模型：

Inactive（未触发）
   ↓ PromQL 条件满足
Pending（等待中，for 持续时间未达到）
   ↓ for 持续时间达到
Firing（告警中）
   ↓ PromQL 条件不满足
Resolved（已恢复）

为什么需要 for 持续时间？

• • 防止瞬时抖动触发告警（如 CPU 瞬间峰值）

• • 平衡告警响应速度与误报率

• • 典型值：critical=1-5 分钟，warning=5-10 分钟，info=10-30 分钟

Alertmanager 告警处理流程：

接收告警 → 分组（group_by） → 抑制（inhibit_rules） → 静默（silences） → 路由（route） → 去重 → 发送通知

分组机制：同一组的多个告警会合并成一条通知，避免告警风暴。例如：

• • 10 台服务器同时 CPU 高负载 → 合并为 1 条通知

• • 分组键: ['alertname', 'cluster']

抑制机制：当 source 告警触发时，target 告警会被抑制。例如：

• • NodeDown 触发 → 抑制该节点的所有其他告警（HighCPUUsage/HighMemoryUsage/DiskSpaceLow）

• • 原理：节点宕机已经是最严重问题，其他告警无需重复通知

---

8️⃣ 可观测性（监控 + 告警 + 性能）

监控指标

Linux 原生监控：

# 实时查看 Prometheus 运行状态
systemctl status prometheus

# 查看 Prometheus 日志
sudo journalctl -u prometheus -f --since "10 minutes ago"

# 检查 TSDB 存储大小
du -sh /var/lib/prometheus/

# 查看活跃时间序列数量
curl -s http://localhost:9090/api/v1/status/tsdb | jq '.data.numSeries'
# 预期输出：10000-50000（取决于监控规模）

# 查看告警规则状态
curl -s http://localhost:9090/api/v1/rules | jq '.data.groups[].rules[] | select(.type=="alerting") | {name: .name, state: .state}'

Prometheus 自监控指标：

# TSDB 大小（字节）
prometheus_tsdb_storage_blocks_bytes

# 活跃时间序列数
prometheus_tsdb_head_series

# 每秒抓取样本数
rate(prometheus_tsdb_head_samples_appended_total[5m])

# 规则评估耗时（P99）
histogram_quantile(0.99, rate(prometheus_rule_evaluation_duration_seconds_bucket[5m]))

# Alertmanager 通知发送成功率
rate(alertmanager_notifications_total{integration="slack"}[5m])
/
rate(alertmanager_notifications_failed_total{integration="slack"}[5m])

Prometheus 告警规则（监控系统自身）

# /etc/prometheus/rules/prometheus_performance.yml
groups:
-name:prometheus_performance
interval:30s
rules:
# 时间序列增长过快
-alert:PrometheusTimeSeriesGrowth
expr:|
          rate(prometheus_tsdb_head_series[1h]) > 1000
for:30m
labels:
severity:warning
annotations:
summary:"Prometheus 时间序列增长过快"
description:"每小时新增 {{ $value }} 个时间序列，可能存在高基数标签"

# 规则评估耗时过长
-alert:PrometheusSlowRuleEvaluation
expr:|
          histogram_quantile(0.99, rate(prometheus_rule_evaluation_duration_seconds_bucket[5m])) > 10
for:15m
labels:
severity:warning
annotations:
summary:"Prometheus 规则评估耗时过长"
description:"P99 评估耗时超过 10 秒，当前值: {{ $value }}s"

# WAL 损坏
-alert:PrometheusWALCorruption
expr:|
          rate(prometheus_tsdb_wal_corruptions_total[5m]) > 0
for:0m
labels:
severity:critical
annotations:
summary:"Prometheus WAL 文件损坏"
description:"检测到 WAL 损坏，数据可能丢失"

性能基准测试

测试场景 1: 抓取性能

# 模拟 100 个目标，每个目标 1000 个指标
# 预期：Prometheus 每 15 秒抓取一次，CPU < 50%，内存 < 4GB

# 查询当前抓取目标数
curl -s http://localhost:9090/api/v1/targets | jq '.data.activeTargets | length'

# 查询每秒采集样本数
curl -s http://localhost:9090/api/v1/query --data-urlencode 'query=rate(prometheus_tsdb_head_samples_appended_total[5m])' | jq '.data.result[0].value[1]'
# 预期输出：6666.67（100 目标 x 1000 指标 / 15 秒）

测试场景 2: 查询性能

# 测试复杂查询耗时
time curl -s 'http://localhost:9090/api/v1/query' --data-urlencode 'query=histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket[5m])) by (job, le))'
# 预期输出：real 0m0.123s（< 200ms）

# 测试范围查询耗时（过去 24 小时）
time curl -s 'http://localhost:9090/api/v1/query_range' \
  --data-urlencode 'query=up{job="node_exporter"}' \
  --data-urlencode 'start=2025-01-16T00:00:00Z' \
  --data-urlencode 'end=2025-01-17T00:00:00Z' \
  --data-urlencode 'step=60s'
# 预期输出：real 0m2.456s（< 5s）

调优参数（prometheus.yml）：

global:
# 调优：降低抓取间隔可减少数据量
scrape_interval:30s# 默认 15s，推荐 15-60s

storage:
tsdb:
# 调优：数据保留时间（默认 15 天）
retention.time:15d

# 调优：数据保留大小（优先于 retention.time）
retention.size:50GB

# 调优：WAL 压缩（启用可减少磁盘 I/O）
wal_compression:true

[已实测] 性能数据（RHEL 8.7, 8C16G）：

• • 监控 100 台服务器（每台 1000 指标）

• • 时间序列总数：100K

• • CPU 使用率：30-40%

• • 内存使用：6-8GB

• • 磁盘 I/O：< 10MB/s 写入

• • 查询 P95 延迟：< 200ms

后续内容请看（三）。

THE END !

文章结束，感谢阅读。您的点赞，收藏，评论是我继续更新的动力。大家有推荐的公众号可以评论区留言，共同学习，一起进步。