10.1 为什么数据库中间件需要集成监控？
随着微服务化与分布式系统的普及，数据库中间件的运行状态、SQL 执行效率、连接状态等信息越来越重要。中间件一旦出现瓶颈，可能直接拖垮整个系统的性能和稳定性。
所以，监控系统不再是“可选项”，而是“核心组件”。
10.2 监控目标与全链路观测范围
| 类型 | 观测指标 | 说明 |
|---|---|---|
| 中间件性能 | QPS / TPS、请求延迟 | 每秒处理的查询数，事务数 |
| SQL 执行 | SQL 响应时间、慢查询分析 | 排查卡顿 SQL |
| 连接状态 | 活跃连接数、等待队列长度 | 判断是否连接数耗尽 |
| 数据库后端 | 后端 MySQL 响应、健康状态 | 判断 DB 故障或卡顿 |
| 系统资源 | CPU、内存、网络、IO | 判断宿主机是否瓶颈 |
| 异常报警 | 错误率、不可达节点 | 自动预警与告警通知 |
10.3 全链路监控体系架构设计
┌───────────────┐
│ 用户请求 │
└──────┬────────┘
↓
┌────────────────────────────┐
│ 数据库中间件集群 │
└──────┬──────┬──────┬────────┘
↓ ↓ ↓
SQL 执行 日志采集 指标采集
↓ ↓ ↓
┌────────┐┌────────┐┌────────┐
│ OpenTelemetry │ Prometheus│ Filebeat │
└────────┘└────────┘└────────┘
↓ ↓ ↓
┌────────────┐┌───────────────┐┌────────────┐
│ Jaeger/Zipkin│ Grafana │ ELK Stack │
└────────────┘└───────────────┘└────────────┘
10.4 核心监控指标汇总
✅ 请求处理指标
- middleware_qps - middleware_request_latency_ms - middleware_connection_wait_time
✅ SQL 执行与路由
- sql_exec_time - sql_slow_query_count - sql_parse_error_total - sql_route_node_count
✅ 后端数据库状态
- mysql_up{instance=“192.168.1.3”} - mysql_conn_active - mysql_qps_backend
✅ 系统与资源层指标
- node_cpu_usage - node_memory_usage - node_network_io - node_disk_read/write
10.5 实战方案：Prometheus + Grafana 监控中间件
1️⃣ 安装 Prometheus 和 Node Exporter
docker run -d --name prometheus \ -p 9090:9090 \ -v /prometheus.yml:/etc/prometheus/prometheus.yml \ prom/prometheus
docker run -d --name node-exporter \ -p 9100:9100 \ prom/node-exporter
2️⃣ 中间件暴露指标接口（/metrics）
每个实例暴露 HTTP 接口供 Prometheus 定时抓取
支持指标分标签（按 SQL 类型、客户端来源分组）
3️⃣ 使用 Grafana 创建 Dashboard
自定义中间件 QPS、延迟、SQL 分布、慢查询等图表
设置告警规则：延迟 > 100ms / QPS 突增 / 连接数 > 90%
10.6 接入链路追踪（Tracing）
使用 OpenTelemetry 进行 Trace 注入：
每条 SQL 的生命周期会生成 trace-id 和 span-id
支持分布式调用链上下文透传
工具选型：
| 工具 | 说明 |
|---|---|
| Jaeger | CNCF 支持，K8s 友好，生产可用 |
| Zipkin | 轻量，适合小规模部署 |
10.7 日志采集与分析（ELK/EFK）
日志是诊断问题的关键手段。中间件日志可以包含：
SQL 执行语句和返回码
SQL 路由详情
错误信息与异常堆栈
filebeat.inputs: - type: log paths: - /var/log/middleware/*.log
ELK/EFK 实现全文检索与多维过滤分析
10.8 告警机制设计
⚙ 触发条件示例
| 指标 | 阈值 | 告警等级 |
|---|---|---|
| SQL 延迟 | > 300ms | 严重 |
| 慢查询比例 | > 10% | 警告 |
| 后端 MySQL 不可达 | 连续失败3次 | 严重 |
| 中间件内存占用 | > 80% | 警告 |
通知方式
邮件、短信、钉钉、飞书
Webhook → 自定义报警平台对接
10.9 最佳实践建议
| 建议 | 说明 |
|---|---|
| 实时可视化 | 所有监控指标应可图形化展示 |
| Trace 可关联 SQL | trace-id 可还原业务链路问题 |
| 指标与日志关联 | Trace ID 可关联 ELK 日志进行分析 |
| 异常预警 | 告警不能太频繁但需及时 |
| 灰度发布监控 | 新版本指标需重点观察 |
| 数据留存策略 | 日志/指标保留策略应合理控制成本 |
10.10 总结
本篇你将掌握：
数据库中间件的全链路监控指标体系
Prometheus + Grafana 的性能指标采集实践
OpenTelemetry 实现 SQL 全链路追踪
ELK 日志分析与 Trace ID 联动
告警策略设计与系统异常自发现机制