2. Prometheus 概述：架构、核心组件、数据模型与指标类型
Prometheus 是云原生计算基金会（CNCF）的毕业项目，也是现代可观测性体系的事实标准。理解其架构设计、组件职责、数据模型与指标类型，是构建 SLO 作业模板与故障自愈机制的基础。本章从这四个维度展开，帮助你在后续章节中快速定位 Prometheus 在 SLO 体系中的角色。
2.1 Prometheus 整体架构
Prometheus 采用 拉取（Pull）模型 作为核心采集方式，配合 时间序列数据库（TSDB） 存储与 PromQL 查询语言，形成一套完整的监控与告警闭环。其架构可概括为“采集 → 存储 → 查询 → 告警”四个阶段。
2.2 核心组件详解
Prometheus 生态由四个核心组件构成，每个组件在 SLO 作业模板与故障自愈链路中承担不同职责。
| 组件 | 核心职责 | SLO / 自愈中的角色 |
|---|---|---|
| Prometheus Server | 指标采集、TSDB 存储、PromQL 查询、告警规则评估 | 计算 SLO 达成率、触发自愈规则、暴露自愈指标 |
| Alertmanager | 告警去重、分组、静默、抑制、路由通知 | 将 SLO 违规告警路由到自愈 Webhook、避免告警风暴 |
| Exporters | 将非 Prometheus 格式的指标转换为 /metrics 端点 | 暴露基础设施与中间件指标，作为 SLO 的原始数据源 |
| Pushgateway | 接收短期任务或批处理作业的推送指标 | 用于无法拉取的场景（如 CronJob），补充 SLO 数据采集 |
2.2.1 Prometheus Server
Server 是 Prometheus 的“心脏”。它通过服务发现或静态配置找到采集目标，按设定的 scrape_interval 拉取指标数据，经过解析、标签处理后存入本地 TSDB。同时，Server 定期评估告警规则，当规则表达式持续满足触发条件时，将告警发送至 Alertmanager。
2.2.2 Alertmanager
Alertmanager 负责告警的“后半程”处理。它接收来自 Prometheus Server 的告警，执行去重（防止重复通知）、分组（将同类告警合并）、静默（临时屏蔽已知问题）和抑制（高等级告警屏蔽低等级告警）。最终通过配置的接收器（Receiver）将告警发送到邮件、Slack、PagerDuty 或自定义 Webhook。在故障自愈场景中，Alertmanager 通常将告警路由到自愈引擎的 Webhook 端点。
2.2.3 Exporters
Exporters 是 Prometheus 生态的“适配器”。对于不支持直接暴露 Prometheus 格式指标的应用（如 Linux 系统、MySQL、Nginx），Exporter 负责采集这些系统的内部状态，转换为 Prometheus 可识别的 /metrics 端点。常见的 Exporter 包括：
- node_exporter：采集 CPU、内存、磁盘、网络等主机指标。
- blackbox_exporter：通过 HTTP、HTTPS、TCP、ICMP 探测外部服务可用性。
- mysql_exporter：采集 MySQL 数据库的连接数、查询性能、复制状态等。
node_exporter 提供基础设施可用性指标，blackbox_exporter 提供用户侧探测的可用性指标，mysql_exporter 提供数据库延迟与错误率指标。这些是定义 SLO 的原始数据。
2.3 数据模型
Prometheus 的数据模型是理解指标查询与 SLO 计算的核心。所有采集到的数据均以 时间序列（Time Series） 形式存储，每个时间序列由 指标名称（Metric Name） 和一组 标签（Labels） 唯一标识。
数据模型的基本结构如下：
<metric_name>{<label_name1>="<label_value1>", <label_name2>="<label_value2>", ...} <value> <timestamp>例如，记录 HTTP 请求总数的指标：
http_requests_total{method="GET", endpoint="/api/v1/users", status="200"} 1024 1700000000数据模型的关键特性：
- 指标名称：描述被测量内容的语义，如
http_requests_total、node_cpu_seconds_total。 - 标签：键值对形式，用于维度扩展。标签是 Prometheus 多维度数据模型的基石，允许对同一指标按不同维度进行聚合、过滤。
- 样本：一个时间点的具体数值与时间戳。
- 时间序列：同一指标名称 + 同一标签组合的所有样本集合。
status 标签区分成功与失败请求，用 endpoint 标签区分不同 API 的延迟。标签基数过高（如将用户 ID 作为标签）会导致 TSDB 性能急剧下降，必须避免。
2.4 指标类型
Prometheus 客户端库提供四种核心指标类型，每种类型在 SLO 计算与故障自愈中有不同的适用场景。
| 指标类型 | 语义 | 典型 SLO 应用 |
|---|---|---|
| Counter | 只增不减的累计计数器（重启后重置为 0） | 请求总数、错误总数、CPU 时间总量 |
| Gauge | 可增可减的瞬时值 | 当前内存使用量、并发连接数、队列深度 |
| Histogram | 对观测值进行分桶统计，记录每个桶的计数 | 请求延迟分布（如 ≤100ms、≤500ms、≤1s 的请求数） |
| Summary | 类似 Histogram，但直接计算分位数（如 p50、p99） | 请求延迟的分位数监控（无需在查询端计算） |
2.4.1 Counter
Counter 是最常用的指标类型，适合记录事件发生的次数。在 SLO 中，通常使用 rate() 或 increase() 函数将 Counter 转换为每秒速率或增量，用于计算错误率、请求率等 SLI。
# 计算过去 5 分钟的平均每秒请求错误率
rate(http_requests_total{status=~"5.."}[5m]) / rate(http_requests_total[5m])2.4.2 Gauge
Gauge 用于测量可以上下波动的值，如内存使用量、温度、队列长度。在故障自愈中，Gauge 常用于触发基于阈值的告警，例如当 node_memory_MemAvailable_bytes 低于某个值时触发扩容。
2.4.3 Histogram
Histogram 通过预定义的分桶（Bucket）来记录观测值的分布。它自动生成三个时间序列：<basename>_bucket{le="..."}（累积桶计数）、<basename>_sum（总和）、<basename>_count（总计数）。在 SLO 中，Histogram 是计算延迟类 SLI 的标准方式。
# 计算过去 5 分钟请求延迟 ≤ 500ms 的比例（SLO 指标）
sum(rate(http_request_duration_seconds_bucket{le="0.5"}[5m])) / sum(rate(http_request_duration_seconds_count[5m]))2.4.4 Summary
Summary 在客户端直接计算分位数，适合对分位数精度要求高且无法在查询端重复计算的场景。但 Summary 的分位数是预定义的，无法像 Histogram 那样在查询时灵活调整分桶边界。