2. Prometheus基础回顾

在进入告警自愈剧本复测之前,必须牢固掌握 Prometheus 的核心基础。本章从架构、数据模型、PromQL 基础到告警规则配置,逐层梳理,确保后续复测操作有据可依。

2.1 Prometheus 整体架构

Prometheus 采用拉取(Pull)模式采集指标,通过服务发现或静态配置确定目标。核心组件包括:

  • Prometheus Server:负责指标抓取、存储、查询和告警评估。
  • Exporters:将非原生格式(如 Node、MySQL、Nginx)转换为 Prometheus 指标。
  • Pushgateway:用于短期或批处理任务的指标推送。
  • Alertmanager:处理告警去重、分组、静默和通知路由。
  • Service Discovery:自动发现 Kubernetes、Consul、EC2 等环境中的目标。
Prometheus 核心架构 Exporters Pushgateway Service Discovery Prometheus Server 抓取 · 存储 · 查询 告警评估 Alertmanager 去重 · 分组 · 通知 Grafana / API 可视化 · 查询 本地 TSDB 架构要点 • Pull 模式:Server 主动拉取,避免推送风暴,易于水平扩展。 • 告警自愈依赖 Alertmanager 与 Webhook 联动,触发自动化剧本。 • 本地 TSDB 默认保留 15 天,长期存储需对接 Thanos 或 Cortex。
复测关注点:在自愈剧本中,Prometheus Server 负责评估告警规则,Alertmanager 负责将告警转发至 Webhook 接收器(如 Jenkins、Kubernetes Job、自愈引擎)。架构中任何一环的延迟或故障都会影响自愈时效。

2.2 数据模型

Prometheus 所有采集数据均为时间序列,由 Metric Name 和 Labels 唯一标识。

概念 说明 示例
Metric Name 指标名称,反映监控对象含义 http_requests_total
Labels 键值对标签,用于维度区分 {method="GET", endpoint="/api"}
Sample 时间戳 + 浮点数值 @1620000000 1024
Metric Type Counter / Gauge / Histogram / Summary Counter 只增不减

2.3 PromQL 基础

PromQL 是 Prometheus 的查询语言,在告警规则和自愈触发条件中频繁使用。以下为复测中最常用的模式:

  • 即时查询:node_cpu_seconds_total{mode="idle"} — 返回当前最新值。
  • 范围查询:node_cpu_seconds_total[5m] — 返回过去 5 分钟所有样本。
  • 速率计算:rate(http_requests_total[1m]) — 每秒平均增长率,适用于 Counter。
  • 聚合操作:sum by (instance) (rate(http_requests_total[5m])) — 按实例聚合。
  • 阈值判断:node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes < 0.1 — 内存可用率低于 10%。
# 常用 PromQL 示例:CPU 使用率 > 80%
(1 - avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m]))) * 100 > 80
复测提示:自愈剧本中,PromQL 的 rate() 和 increase() 窗口长度直接影响告警灵敏度。窗口过短易抖动,过长则延迟。建议在复测时对比 1m、5m、10m 窗口的告警触发时间。

2.4 告警规则配置

告警规则定义在 YAML 文件中,由 Prometheus Server 定期评估。规则文件通过 rule_files 字段加载。

# 示例告警规则文件:alerts.yml
groups:
  - name: node_alerts
    rules:
      - alert: HighCpuUsage
        expr: (1 - avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m]))) * 100 > 80
        for: 2m
        labels:
          severity: critical
        annotations:
          summary: "Instance {{ $labels.instance }} CPU 使用率过高"
          description: "当前值: {{ $value }}%"
字段 含义 复测注意事项
alert 告警名称,在 Alertmanager 中用于路由匹配 名称需与自愈剧本中的 alertname 一致
expr PromQL 表达式,返回非空结果即触发 复测时需验证表达式在 Grafana 中返回预期值
for 持续时间,条件满足该时长后才触发告警 自愈场景建议设置 for: 1m 避免误触发
labels 附加标签,可覆盖或新增 用于区分告警严重级别、环境、团队
annotations 描述信息,支持模板变量 自愈剧本常从 annotations 提取故障详情
告警规则评估与自愈触发流程 Prometheus 评估 告警触发 Alertmanager Webhook 自愈 复测关键检查点 1. 规则文件语法校验:promtool check rules alerts.yml 2. 告警状态机:Pending → Firing → Resolved,自愈剧本通常在 Firing 时触发。 3. 自愈完成后需确认告警自动 Resolved,避免重复执行。
常见陷阱:告警规则中的 for 字段在自愈场景中容易被忽略。如果 for 设置过长(如 5 分钟),自愈剧本可能延迟触发,导致故障时间窗口扩大。建议复测时从 for: 0s 开始逐步调优。

2.5 本章小结