2. Prometheus 监控体系基础：架构、数据模型与指标类型

在深入连接池水位巡检之前，必须建立对 Prometheus 监控体系的底层认知。本章将拆解 Prometheus 的核心架构、数据模型以及四种指标类型（Counter、Gauge、Histogram、Summary），为后续配置连接池巡检规则打下坚实基础。

2.1 Prometheus 整体架构

Prometheus 采用“拉取（Pull）”模式采集指标，区别于传统“推送（Push）”模型。其核心组件包括：

• Prometheus Server：负责指标抓取、存储与查询。
• Exporters：将第三方系统（如数据库、中间件）的指标转换为 Prometheus 格式。
• Pushgateway：用于短期任务或无法直接拉取的场景。
• Alertmanager：处理告警去重、分组与通知。
• Service Discovery：动态发现目标实例（Kubernetes、Consul 等）。

2.2 数据模型：时间序列与标签

Prometheus 所有数据均以时间序列（Time Series）形式存储。一个时间序列由指标名称（Metric Name）和一组标签（Labels）唯一标识。

2.3 四种核心指标类型

Prometheus 客户端库提供四种指标类型，理解其语义是配置巡检规则的前提。

2.3.1 Counter（计数器）

• 特点： 只增不减（除非系统重启）。
• 适用场景： 请求总数、错误总数、连接创建总数。
• PromQL 常用函数： rate()、increase()。
• 连接池示例： hikaricp_connections_creation_total（连接创建总数）。

2.3.2 Gauge（仪表盘）

• 特点： 可增可减，反映当前瞬时值。
• 适用场景： 内存使用率、连接池活跃连接数、队列深度。
• PromQL 常用函数： avg()、max()、min()。
• 连接池示例： hikaricp_connections_active（当前活跃连接数）。

2.3.3 Histogram（直方图）

• 特点： 对观测值（如请求延迟）进行分桶计数，可计算分位数。
• 适用场景： 请求延迟分布、连接获取等待时间。
• PromQL 常用函数： histogram_quantile()。
• 连接池示例： hikaricp_connections_acquire_seconds_bucket（连接获取耗时分布）。

2.3.4 Summary（摘要）

• 特点： 类似 Histogram，但直接在客户端计算分位数，无法聚合。
• 适用场景： 已知分位数需求且无需跨实例聚合的场景。
• 连接池示例： hikaricp_connections_acquire_seconds_summary（连接获取耗时摘要）。

2.4 指标类型选择原则

选择指标类型时遵循以下原则：

1. 只增不减的累计值 → 使用 Counter（如连接创建总数、连接关闭总数）。
2. 可上下波动的瞬时值 → 使用 Gauge（如活跃连接数、空闲连接数、等待获取连接数）。
3. 需要分析分布或计算分位数 → 使用 Histogram（如连接获取耗时、SQL 执行耗时）。
4. 已知分位数且无需跨实例聚合 → 使用 Summary（如每个实例的 P95 延迟）。

2.5 连接池巡检中的典型指标映射