Prometheus 告警规则设计规范

Prometheus 告警规则设计规范

1. 目标

建立一套规范的 Prometheus 告警规则设计标准，为运维监控提供高效的告警分组、收敛、静默抑制和快速响应能力，确保体系的可维护性与扩展性。

---

2. 告警规则设计原则

1. 准确性：减少误报和漏报，提升告警的可信度。
2. 分层次：按照告警严重性和优先级进行分层。
3. 分组化：以功能或业务维度对告警进行分组管理。
4. 易维护：告警规则结构清晰、命名统一、标签规范。
5. 自动化：通过版本控制和 CI/CD 实现告警规则的自动化部署和更新。

---

3. 告警分组与分层设计

3.1 告警分组

根据业务逻辑和监控指标，将告警分为以下类别：

• 业务维度：

  • 数据库告警：MySQL、PostgreSQL、MongoDB 等。
  • 中间件告警：Kafka、Redis、RabbitMQ 等。
  • 应用服务告警：服务存活、响应时间、依赖异常等。

• 功能维度：

  • 可用性（Availability）：监控服务和组件的运行状态。
  • 性能（Performance）：资源使用情况（CPU、内存、磁盘等）。
  • 安全性（Security）：异常访问、认证失败等。

3.2 告警分层

按照严重性划分告警级别，帮助团队快速响应和处理：

• 一级告警（Critical）：

  • 严重影响业务的故障（服务宕机、关键资源耗尽）。
  • 需立即通知并触发值班响应。

• 二级告警（Warning）：

  • 潜在风险（性能临近瓶颈、非核心服务异常）。
  • 需尽快关注并采取预防措施。

• 三级告警（Info）：

  • 非紧急问题（低优先级的日志或配置异常）。
  • 可在日常巡检中处理。

---

4. 告警命名规范

统一的命名规则可以提升规则的可读性和易维护性。

4.1 命名格式

Component_Metric_Condition_Level

• Component：告警关联的系统组件名称。
• Metric：监控指标名称。
• Condition：触发条件的描述。
• Level：告警的严重级别。

4.2 示例

• Database_DiskUsage_High_Critical
• Service_ResponseTime_Slow_Warning
• Network_ConnectionLost_Info

---

5. 标签与注释规范

5.1 标签设计（Labels）

标签用于分类和路由告警信息，是告警收敛和静默的重要依据。

• 必要标签：

  • severity：告警级别（critical、warning、info）。
  • team：处理告警的责任团队（如 infra、app、db）。
  • environment：运行环境（如 prod、staging、test）。
  • service：关联服务名称。

• 示例：

labels:severity: criticalteam: databaseenvironment: prodservice: mysql

5.2 注释设计（Annotations）

通过注释提供详细信息，帮助值班人员快速定位和解决问题。

• summary：告警的简要描述。

• description：告警详情，包括上下文信息。

• runbook_url：指向处理步骤的文档或链接。

• 示例：

annotations:summary: "High memory usage on {{ $labels.instance }}"description: "Memory usage on {{ $labels.instance }} exceeded 90% for 5 minutes."runbook_url: "https://docs.example.com/runbooks/high-memory-usage"

---

6. 告警规则设计示例

6.1 基础告警规则

groups:- name: availability_alertsrules:- alert: InstanceDownexpr: up == 0for: 1mlabels:severity: criticalteam: infraenvironment: prodannotations:summary: "Instance {{ $labels.instance }} down"description: "The instance {{ $labels.instance }} is unreachable for 1 minute."

6.2 性能告警规则

  - name: performance_alertsrules:- alert: HighCPUUsageexpr: avg(rate(process_cpu_seconds_total[5m])) > 0.8for: 5mlabels:severity: warningteam: appenvironment: stagingannotations:summary: "High CPU usage on {{ $labels.instance }}"description: "The CPU usage on {{ $labels.instance }} is above 80% for 5 minutes."

---

7. 告警规则收敛策略

7.1 重复告警的收敛

• 避免短暂波动触发告警：
  • 使用 for 参数延迟告警触发，减少误报。

for: 5m

7.2 Alertmanager 聚合

通过标签聚合相同类型的告警，减少通知频率。

group_by: ['alertname', 'service', 'team']
group_wait: 30s
group_interval: 5m
repeat_interval: 3h

---

8. 静默与抑制设计

8.1 静默（Silence）

• 在系统维护期间，通过静默屏蔽非必要告警。
• 可基于标签匹配进行静默。

8.2 抑制（Inhibition）

• 避免次生告警的重复发送。
• 示例：

inhibit_rules:- source_match:severity: criticaltarget_match:severity: warningequal: ['service', 'instance']

---

9. 动态告警设计

9.1 动态阈值设计

动态阈值的设计可根据历史数据预测系统指标的正常范围，从而减少告警噪声并识别异常趋势。

9.1.1 预测分析（Predictive Analysis）

使用 Prometheus 提供的预测函数（如 predict_linear 和 holt_winters）对未来趋势进行建模。

• 示例：预测磁盘空间在一小时内是否耗尽

alert: DiskSpaceRunningOut
expr: predict_linear(node_filesystem_avail_bytes[1h], 3600) < 0
for: 5m
labels:severity: criticalteam: infraenvironment: prod
annotations:summary: "Disk space running out on {{ $labels.instance }}"description: "The available disk space on {{ $labels.instance }} will run out within 1 hour. Current available space: {{ $value }} bytes."runbook_url: "https://docs.example.com/runbooks/disk-space"

9.1.2 异常检测（Anomaly Detection）

基于历史模式检测偏离正常范围的指标。

• 示例：使用 avg_over_time 和 stddev_over_time 检测内存使用的异常波动

alert: HighMemoryUsageAnomaly
expr: (node_memory_MemAvailable_bytes < avg_over_time(node_memory_MemAvailable_bytes[1h]) - 2 * stddev_over_time(node_memory_MemAvailable_bytes[1h]))
for: 5m
labels:severity: warningteam: appenvironment: staging
annotations:summary: "Memory usage anomaly on {{ $labels.instance }}"description: "The available memory on {{ $labels.instance }} has dropped significantly below the historical average."runbook_url: "https://docs.example.com/runbooks/memory-usage"

9.1.3 自适应阈值

根据当前负载动态调整阈值。例如，高负载期间允许更高的 CPU 使用率。

• 示例：动态调整 CPU 使用率告警阈值

alert: AdaptiveHighCPUUsage
expr: (avg(rate(node_cpu_seconds_total[5m])) by (instance)) > (1.5 * avg_over_time(avg(rate(node_cpu_seconds_total[5m]))[1h]))
for: 5m
labels:severity: warningteam: appenvironment: prod
annotations:summary: "High CPU usage on {{ $labels.instance }}"description: "The CPU usage on {{ $labels.instance }} is significantly higher than the historical baseline."runbook_url: "https://docs.example.com/runbooks/high-cpu-usage"

---

9.2 分布式依赖告警

对于依赖于分布式系统的场景，设计规则时需结合整体健康状态和单节点异常，避免单一指标误触发告警。

• 示例：Kafka 集群整体健康状态告警

alert: KafkaClusterUnderReplicatedPartitions
expr: sum(kafka_cluster_partition_under_replicated) > 0
for: 3m
labels:severity: criticalteam: infraenvironment: prod
annotations:summary: "Under-replicated partitions in Kafka cluster"description: "The Kafka cluster has under-replicated partitions. Affected partitions: {{ $value }}"runbook_url: "https://docs.example.com/runbooks/kafka-under-replication"

---

10. 动态告警与静默策略

10.1 动态告警启停

结合维护窗口自动启停告警，避免维护期间无意义的告警。

• 示例：通过标签 maintenance 动态控制告警

alert: ServiceUnavailable
expr: up == 0 and on(instance) (labels{maintenance!="true"})
for: 1m
labels:severity: criticalteam: appenvironment: prod
annotations:summary: "Service {{ $labels.instance }} unavailable"description: "The service {{ $labels.instance }} is down for 1 minute."

10.2 告警收敛和抑制

在多级告警场景中，避免次生告警产生。

• 示例：当关键服务宕机时，屏蔽非关键告警

inhibit_rules:- source_match:severity: criticalalertname: ServiceDowntarget_match:severity: warningequal: ['service']

---

11. 动态告警规则部署示例

11.1 动态磁盘告警

groups:- name: dynamic_disk_alertsrules:- alert: DiskUsageHighexpr: node_filesystem_usage_bytes / node_filesystem_size_bytes > 0.85for: 10mlabels:severity: warningteam: infraenvironment: prodannotations:summary: "High disk usage on {{ $labels.instance }}"description: "The disk usage on {{ $labels.instance }} has exceeded 85% for 10 minutes."runbook_url: "https://docs.example.com/runbooks/high-disk-usage"

---

12. 示例目录结构

将规则按分组存储，方便管理和扩展：

rules/
├── availability.rules.yml
├── performance.rules.yml
├── security.rules.yml
└── maintenance.silences.yml