数据库可观测性：从日志到指标的全链路监控

从"监控"到"可观测性"的范式跃迁

传统数据库监控关注的是"已知的已知"——CPU 是否超阈值、磁盘是否快满、连接数是否达到上限。可观测性则更进一步，回答"未知的未知"——为什么昨晚 3 点 QPS 突降？哪个微服务在大量执行全表扫描？

可观测性三支柱：Logs（发生了什么）、Metrics（量有多大）、Traces（链路在哪里卡住）。三者缺一不可。

支柱一：结构化日志

MySQL 慢查询日志增强

开启慢查询日志并解析为结构化数据：

SET GLOBAL slow_query_log = ON;
SET GLOBAL long_query_time = 0.5;
SET GLOBAL log_queries_not_using_indexes = ON;
SET GLOBAL log_slow_extra = ON;  -- MySQL 8.0.14+

使用 pt-query-digest 分析慢查询模式：

pt-query-digest /var/log/mysql/slow.log \
  --since "24h ago" \
  --report-format=query_report \
  --limit=10

支柱二：实时指标采集

OpenTelemetry Collector 配置

receivers:
  mysql:
    endpoint: "mysql-db:3306"
    username: exporter
    password: ${MYSQL_PASS}
    collection_interval: 15s

exporters:
  prometheus:
    endpoint: "0.0.0.0:9104"

service:
  pipelines:
    metrics:
      receivers: [mysql]
      exporters: [prometheus]

支柱三：全链路追踪

通过在应用层注入 SQL 注释来关联数据库查询与业务请求：

// Hibernate + OpenTelemetry 自动注入
// 生成的 SQL 自动包含 trace 信息：
// SELECT * FROM orders WHERE user_id = 123 
// /*traceparent="00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01"*/

Grafana 仪表盘搭建

基于采集到的指标，建议搭建以下关键面板：

1. QPS/TPS 趋势：按读写分离展示，配合时间轴定位异常时段。
2. 连接数水位：当前连接数、活跃连接数、等待连接数。
3. 慢查询 Top-N：按执行次数和平均耗时双重排序。
4. 锁等待分析：InnoDB 行锁等待时间趋势 + 死锁次数。
5. 复制延迟：主从同步延迟秒数。

告警规则设计

总结

数据库可观测性不是一次性搭建就能一劳永逸的工程。随着业务演进和查询模式变化，需要持续调整仪表盘和告警阈值。关键是先搭建最小可用的观测体系，再根据实际故障复盘逐步完善。