📚 课程目录第1章监控体系概述

1. 监控体系概述：可观测性三大支柱与 SQL 监控的关系

在构建现代数据驱动的运维体系时，可观测性（Observability）已成为核心原则。它超越了传统监控的“已知故障检测”，旨在通过外部输出推断系统内部状态。业界公认的可观测性模型由三大支柱构成：Metrics（指标）、Logs（日志） 和 Traces（链路）。对于数据库与 SQL 监控而言，这三大支柱并非孤立存在，而是从不同维度共同描绘出查询性能的全貌。

核心认知： SQL 监控是可观测性在数据层的具体投射。一条慢查询，在 Metrics 中表现为高延迟与低吞吐，在 Logs 中表现为具体的 SQL 文本与执行计划，在 Traces 中则表现为跨服务调用链上的阻塞点。

1.1 三大支柱的定义与数据特征

下表从数据形态、存储成本、查询模式三个维度，对比了三大支柱的本质差异，这直接决定了我们在设计 SQL 监控策略时如何选择数据源。

支柱	数据形态	典型 SQL 监控场景	存储成本	查询模式
Metrics	时序数值（Counter, Gauge, Histogram）	QPS、查询延迟 P99、连接数、锁等待计数	低（聚合后存储）	聚合查询、趋势分析、报警触发
Logs	非结构化/半结构化文本（JSON, 明文）	慢查询日志、错误日志、审计日志、死锁日志	高（需索引与压缩）	关键词搜索、模式匹配、上下文检索
Traces	有向无环图（Span 链）	端到端请求中数据库调用耗时、ORM 生成的 SQL 映射	中（采样后存储）	分布式追踪、依赖分析、瓶颈定位

    运维实战建议： 在 Grafana 中构建 SQL 监控仪表盘时，应优先使用 Metrics 作为仪表盘的主轴（如实时 QPS 面板），用 Logs 作为下钻详情（如点击高延迟点跳转到慢日志详情），用 Traces 作为根因分析链路（如查看该 SQL 是由哪个上游服务发起的）。

1.2 三大支柱与 SQL 监控的协同关系

下图展示了在一个典型的微服务架构中，一次数据库查询请求如何被三大支柱分别捕获，以及它们之间的数据流转与关联逻辑。

1.3 SQL 监控在三大支柱中的具体落地

理解了三者的关系后，我们需要在具体的数据库监控场景中，明确每个支柱应该采集什么数据，以及如何利用这些数据驱动报警。

1.3.1 Metrics 维度：量化数据库健康状态

吞吐量： QPS (Queries Per Second)、TPS (Transactions Per Second)。
延迟： 平均查询延迟、P50/P95/P99 延迟、慢查询数量。
资源饱和度： 连接数使用率、磁盘 IOPS、CPU 使用率、内存缓冲池命中率。
锁与并发： 行锁等待计数、死锁发生频率、活跃事务数。

报警设计陷阱： 不要仅依赖平均值（Avg）设置报警。例如，平均延迟 50ms 可能掩盖了 P99 延迟 5s 的严重问题。在 Grafana 报警规则中，应优先使用 Histogram 分位数（如 histogram_quantile(0.99, ...)）作为报警指标。

1.3.2 Logs 维度：捕获查询细节与异常

慢查询日志： 记录执行时间超过 long_query_time 的 SQL，包含锁等待时间、扫描行数、返回行数。
错误日志： 记录连接失败、死锁回滚、主从切换等异常事件。
审计日志： 记录 DDL/DML 操作，用于安全审计与变更追踪。

# 典型慢查询日志条目 (MySQL)
# Time: 2025-03-21T10:15:30.123456Z
# User@Host: app_user[app_user] @  [10.0.1.100]
# Query_time: 12.345678  Lock_time: 0.001234
# Rows_sent: 100  Rows_examined: 500000
SET timestamp=1742544930;
SELECT * FROM orders WHERE status = 'PENDING' ORDER BY created_at DESC;

1.3.3 Traces 维度：定位端到端瓶颈

数据库 Span： 记录 SQL 执行的开始与结束时间、数据库实例地址、SQL 语句摘要。
调用链上下文： 通过 TraceID 关联上游服务（如 API Gateway、Web Server）与下游数据库。
依赖拓扑： 自动发现服务与数据库之间的调用关系，识别扇出（Fan-out）与热点数据库。

    Grafana 调优技巧： 在 Grafana 中，可以使用 Tempo（链路数据源）与 Loki（日志数据源）进行关联查询。例如，在 Tempo 中查看一个慢 Trace，点击 Span 可以直接跳转到 Loki 中对应的慢查询日志，实现“一键下钻”。

1.4 本章小结：从监控到可观测性的思维转变

传统的 SQL 监控往往只关注 Metrics（如 CPU 高、慢查询多），这是一种“已知问题”的被动响应。而基于可观测性三大支柱的 SQL 监控，要求我们构建一个能够主动探索未知问题的体系：

Metrics 告诉我们“系统变慢了”。
Logs 告诉我们“是哪条 SQL 变慢了”。
Traces 告诉我们“是哪个用户请求导致了这条 SQL 变慢”。