📚 课程目录第2章 Prometheus核心概念回顾

2. Prometheus 监控基础回顾：架构、数据模型与 Metric 类型

在构建基于 Prometheus 的滚动升级自动化回滚工程之前，必须牢固掌握 Prometheus 的核心监控基础。本章将系统回顾 Prometheus 的架构设计、数据模型、四种核心 Metric 类型以及数据采集模式，为后续的监控驱动决策奠定理论基础。

2.1 Prometheus 整体架构

Prometheus 采用 Pull 模型 作为主要的数据采集方式，其架构由多个组件协同工作，形成一个完整的监控与告警闭环。核心组件包括：

Prometheus Server：负责数据采集、存储与查询，是系统的中枢。
Exporters：部署在被监控目标上，将业务或系统指标转换为 Prometheus 可识别的格式。
Pushgateway：用于接收短生命周期任务（如批处理作业）推送的指标。
Alertmanager：处理告警，进行去重、分组、静默并发送通知。
Service Discovery：动态发现 Kubernetes、Consul 等环境中的监控目标。

  架构要点： Pull 模型是 Prometheus 的核心设计哲学，它使监控系统对被监控目标具有完全的控制权，能够主动决定采集频率和采集目标，从而避免被监控端故障导致的数据丢失。

2.2 数据模型

Prometheus 的数据模型以 时间序列 为核心，每个时间序列由 Metric Name 和一组 Labels 唯一标识。理解数据模型是编写高效 PromQL 查询和设计监控指标的基础。

概念	说明	示例
Metric Name	指标名称，描述监控对象的含义	`http_requests_total`
Labels	键值对标签，用于维度区分	`{method="GET", endpoint="/api"}`
Sample	时间戳 + 浮点数值	`@1620000000 1024`
Time Series	Metric Name + Labels 唯一标识的样本流	`http_requests_total{method="GET"}`

标签设计原则： 标签是 Prometheus 数据模型的灵魂。在滚动升级场景中，建议将 version、deployment、pod 等作为标签，以便在升级过程中按版本维度聚合和对比指标。

2.3 Metric 类型详解

Prometheus 客户端库提供四种核心 Metric 类型，每种类型适用于不同的监控场景。在滚动升级回滚工程中，正确选择 Metric 类型直接决定了监控数据的有效性。

2.3.1 Counter（计数器）

Counter 只增不减，适用于累计型指标，如请求总数、错误总数。在滚动升级中，错误率 通常通过两个 Counter 的差值计算得出。

# 定义：只增不减的计数器
# 适用：请求数、错误数、任务完成数
# 示例：升级过程中监控 5xx 错误总数
http_requests_total{status="500", version="v2.0.1"}

2.3.2 Gauge（仪表盘）

Gauge 可增可减，适用于瞬时值指标，如当前内存使用量、并发连接数。在滚动升级中，资源水位 和 Pod 状态 通常使用 Gauge 表示。

# 定义：可增可减的瞬时值
# 适用：CPU 使用率、内存使用量、当前 Pod 数量
# 示例：升级过程中监控 Pod 就绪状态
kube_deployment_status_replicas_ready{deployment="my-app", version="v2.0.1"}

2.3.3 Histogram（直方图）

Histogram 对观测值进行分桶统计，适用于分析数据分布，如请求延迟、响应大小。在滚动升级中，延迟分布变化 是判断升级是否引入性能退化的关键指标。

# 定义：对观测值进行分桶计数
# 适用：请求延迟、响应大小
# 示例：升级过程中监控延迟分布
# 指标名后缀 _bucket、_sum、_count
http_request_duration_seconds_bucket{le="0.1", version="v2.0.1"}
http_request_duration_seconds_sum{version="v2.0.1"}
http_request_duration_seconds_count{version="v2.0.1"}

2.3.4 Summary（摘要）

Summary 直接计算分位数，适用于需要预定义分位数的场景，如 SLA 报告。与 Histogram 不同，Summary 在客户端计算分位数，无法跨实例聚合。

# 定义：客户端计算的分位数
# 适用：SLA 监控、预定义分位数需求
# 示例：升级过程中监控 P99 延迟
# 指标名后缀 _quantile、_sum、_count
http_request_duration_seconds{quantile="0.99", version="v2.0.1"}

Metric 类型	核心特征	滚动升级场景	聚合能力
Counter	只增不减	错误计数、请求计数	支持 Sum
Gauge	可增可减	Pod 就绪数、资源使用率	支持 Avg / Max / Min
Histogram	分桶统计	延迟分布、响应大小分布	支持分位数估算
Summary	客户端分位数	SLA 报告、预定义分位数	不支持跨实例聚合

2.4 Pull 模型与 Pushgateway

Prometheus 默认采用 Pull 模型，即 Prometheus Server 主动向 Exporter 的 HTTP 端点拉取指标。这种模式具有以下优势：

健康检查自然集成：如果目标无法拉取，说明目标可能已宕机。
控制采集节奏：Server 端统一控制采集频率，避免被监控端过载。
配置驱动：通过 scrape_config 灵活定义采集目标。

然而，对于 短生命周期任务（如批处理作业、CronJob），任务执行时间短，Prometheus 可能来不及拉取指标。此时需要 Pushgateway 作为中间代理：

# Pushgateway 工作流程
# 1. 短任务在结束时将指标推送到 Pushgateway
# 2. Prometheus 从 Pushgateway 拉取指标
# 3. 注意：Pushgateway 不会自动清理过期指标，需要手动管理

# 推送示例（使用 curl）
echo "job_duration_seconds{job=\"batch\"} 42.5" | curl --data-binary @- http://pushgateway:9091/metrics/job/batch

Pushgateway 使用注意事项： Pushgateway 不是绕过 Pull 模型的万能方案。它可能成为单点故障，且不会自动过期指标。在滚动升级场景中，建议优先使用 Pull 模型采集长期运行的 Pod 指标，仅对批处理任务使用 Pushgateway。

2.5 本章小结

本章回顾了 Prometheus 的核心监控基础，包括：

架构：Pull 模型驱动的组件协作体系
数据模型：时间序列 + 标签的维度化设计
Metric 类型：Counter、Gauge、Histogram、Summary 的适用场景
采集模式：Pull 模型为主，Pushgateway 为补充