3. Prometheus 监控体系概述
在深入连接池水位巡检之前，必须先理解 Prometheus 监控体系的核心设计。Prometheus 是一个基于指标（Metric）的监控系统，其架构、数据模型和采集模式决定了我们如何定义、采集和告警连接池水位。
3.1 Prometheus 整体架构
Prometheus 采用拉取（Pull）为主的架构，核心组件包括 Prometheus Server、Exporter、Alertmanager 以及数据可视化层。下图展示了各组件之间的协作关系：
架构要点：连接池水位巡检依赖 Exporter 暴露连接池指标 → Prometheus Server 定期拉取 → 规则评估触发告警 → Alertmanager 通知。理解这个链路是设计告警规则的前提。
3.2 数据模型：Metric、Label、Sample
Prometheus 的数据模型是多维时间序列模型，每个时间序列由 Metric（指标名）、Label（标签） 和 Sample（样本） 唯一标识。
| 概念 | 定义 | 连接池示例 |
|---|---|---|
| Metric | 指标名称，描述被监控的量化特征 | hikaricp_connections_active |
| Label | 键值对标签，用于维度区分和过滤 | pool="order-db-pool", instance="10.0.1.5:8080" |
| Sample | 时间戳 + 浮点数值，构成数据点 | t=1710000000, v=12.0 |
一个完整的时间序列标识如下：
hikaricp_connections_active{pool="order-db-pool", instance="10.0.1.5:8080"} 12.0
│ │ │ │
└─ Metric └─ Label 1 └─ Label 2 └─ Sample Value
巡检关键：连接池告警规则必须利用 Label 区分不同连接池实例。例如
pool="order-db-pool" 和 pool="user-db-pool" 需要分别设置不同的水位阈值。
3.3 Pull vs Push 模式
Prometheus 默认采用 Pull（拉取） 模式，与传统的 Push（推送）模式有本质区别。下表对比了两种模式在连接池监控场景下的差异：
| 对比维度 | Pull 模式（Prometheus 默认） | Push 模式（如 Graphite） |
|---|---|---|
| 数据流向 | Server 主动拉取 Exporter 端点 | 客户端主动推送数据到中央网关 |
| 连接池适用性 | 适合长运行服务，Exporter 持续暴露 /metrics | 适合短任务或批量作业 |
| 故障检测 | 拉取超时或失败 → 立即发现目标不可达 | 推送中断 → 难以区分是数据延迟还是故障 |
| 配置复杂度 | 需要服务发现或静态配置目标地址 | 客户端只需配置网关地址，更简单 |
| 安全性 | Server 端控制采集频率，不易被客户端淹没 | 需额外认证和限流机制 |
对于连接池水位巡检，Pull 模式具有明显优势：
- 自动发现故障：如果应用宕机，Exporter 端点不可达，Prometheus 立即标记该实例为
up=0，触发告警。 - 采集频率可控：Server 端统一配置
scrape_interval，避免客户端推送频率不一致导致数据混乱。 - 连接池指标实时性：默认 15s 拉取间隔足以捕捉连接池水位变化趋势。
注意：在 Kubernetes 环境中，Pod 可能频繁重建，Pull 模式依赖服务发现动态更新目标列表。如果服务发现配置不当，可能导致连接池指标采集中断。
3.4 Exporter 概念
Exporter 是 Prometheus 生态中的指标适配器，负责将第三方系统的内部状态转换为 Prometheus 可识别的指标格式。Exporter 暴露一个 HTTP 端点（通常是 /metrics），Prometheus Server 定期拉取该端点获取数据。
常见的 Exporter 类型及在连接池监控中的应用：
| Exporter 名称 | 监控对象 | 连接池相关指标示例 |
|---|---|---|
| Node Exporter | 操作系统（CPU/内存/网络） | 系统文件描述符限制（影响连接池最大连接数） |
| MySQL Exporter | MySQL 数据库 | mysql_global_status_threads_connected |
| JMX Exporter | Java 应用（Tomcat/HikariCP） | hikaricp_connections_active, hikaricp_connections_idle |
| 自定义 Exporter | 自研中间件或连接池实现 | 通过 Prometheus 客户端库暴露自定义指标 |
Exporter 的工作流程如下图所示：
实践建议：对于 Java 应用中的 HikariCP 连接池，推荐使用 JMX Exporter 或 Micrometer + Prometheus 注册表 暴露连接池指标。对于自研连接池，可使用 Prometheus 客户端库（如
prometheus_client for Python）快速构建自定义 Exporter。
3.5 连接池监控的指标暴露方式
在连接池水位巡检场景中，Exporter 需要暴露以下核心指标：
- 活跃连接数：
hikaricp_connections_active— 当前正在使用的连接数。 - 空闲连接数：
hikaricp_connections_idle— 池中空闲等待的连接数。 - 等待线程数：
hikaricp_connections_pending— 等待获取连接的线程数。 - 最大连接数：
hikaricp_connections_max— 连接池配置的最大连接数。 - 创建/销毁速率：
hikaricp_connections_creation_seconds— 连接创建耗时，反映数据库压力。
这些指标通过 Label 区分不同的连接池实例（如 pool="order-db"），为后续告警规则设计提供维度基础。