需打通应用层指标、数据库原生状态与k8s服务发现三层数据监控hyperf连接池水位；启用hyperf/metric自定义上报、集成mysqld_exporter采集mysql真实连接状态，并通过k8s标签与pod_ip实现pod-db实例关联下钻分析。
Hyperf 在 Kubernetes 环境中监控连接池连接数，不能只依赖框架自身上报的查询耗时指标（如 hyperf_db_query_duration_ms），而需打通「应用层指标 + 数据库原生状态 + K8s 服务发现」三层数据，才能真实反映连接池使用水位和瓶颈。
暴露 Hyperf 连接池运行时指标
Hyperf 的 hyperf/metric 组件支持通过 Prometheus 格式导出连接池关键状态，但默认不开启连接数统计。需手动启用并注册自定义指标：
- 在
config/autoload/metric.php中启用 Prometheus 适配器，并确保adapter指向PrometheusAdapterFactory - 在
config/autoload/dependencies.php注入Pool\PoolFactoryInterface相关监听器，或编写自定义PoolMonitor类，定时采集$pool->getStats()返回的active、idle、waiting数值 - 调用
Counter::instance()->inc()或Gauge::instance()->set()将这些值以hyperf_pool_connections_total{type="mysql",pool="default"}等格式上报
集成 mysqld_exporter 获取 MySQL 实际连接状态
Hyperf 上报的只是“已借出”的连接数，无法体现 MySQL 侧的真实压力。必须部署 mysqld_exporter 并抓取以下核心指标：
-
mysql_global_status_threads_connected：当前 MySQL 总连接数，对比max_connections判断是否接近上限 -
mysql_global_status_threads_running：活跃线程数，高值常意味着锁等待或慢查询堆积 -
mysql_global_status_aborted_connects：失败连接数突增，可能因连接池配置过大触发 MySQL 拒绝新连 -
mysql_global_status_innodb_row_lock_time_avg：行锁平均等待时间，超 50ms 需排查事务或索引问题
注意：mysqld_exporter 必须使用最小权限账号（仅 PROCESS、REPLICATION CLIENT、SELECT），否则采集失败且存在安全风险。
在 K8s 中自动发现与关联 Pod 和数据库实例
Kubernetes 动态调度特性要求监控配置能自动匹配服务关系。推荐做法：
- 为每个 Hyperf Pod 添加标签：
app: user-service、hyperf-pool-type: mysql，并在 Prometheus 的relabel_configs中提取这些标签，注入到采集到的指标中 - 用
kube-state-metrics关联 Pod 生命周期：当某 Pod 的hyperf_pool_connections_total持续为 0 但mysql_global_status_threads_connected居高不下，说明该 Pod 可能未正常释放连接或已僵死 - 通过
pod_ip与mysql_instance建立映射，在 Grafana 中实现「点击某个 Pod → 查看它所连 MySQL 实例的连接分布」下钻分析
Swow 引擎下的特殊处理
若使用 Swow 协程引擎（Hyperf 3.1+），连接池行为与 Swoole 不同，需额外注意：
- Swow 连接池的
min_connections和max_connections是硬限制，不会像 Swoole 那样动态伸缩；务必在config/autoload/databases.php中删除旧版pool配置，改用 Swow 专用结构，否则指标会失真 - Swow 的
check_interval（心跳检测间隔）不得低于 3000ms，否则可能导致 idle 连接未被及时回收，idle数值虚高 - 建议在启动脚本中加入健康检查：定期执行
SELECT CONNECTION_ID()并比对threads_connected，验证连接是否真正复用而非新建
