数据库自身的可观测性
时序数据库在工业数据平台中承担数据存储的核心职责，其自身的运行状态是平台稳定性的基础。数据库可观测性指通过指标（Metrics）、日志（Logs）、追踪（Traces）三类数据，观测数据库的运行状态、定位性能问题、预测容量趋势。
监控数据库自身存在一个自洽问题：监控数据本身也存储在数据库中。若监控系统依赖被监控数据库存储监控数据，则数据库故障时监控数据也随之丢失，观测能力失效。因此数据库的自监控通常采用外部监控系统，或至少将被监控实例与监控存储在物理上分离。
可观测性的目标是提前发现异常而非事后排查。数据库问题的典型表现是写入延迟上升、查询响应变慢、内存增长、复制延迟扩大。这些问题往往在业务侧表现为性能下降之前，已经在数据库内部指标上显现。基于内部指标的监控可以在问题影响业务前预警。
指标体系
数据库的可观测指标可分为几个维度。
吞吐类指标反映数据库的处理能力：写入TPS（每秒写入行数）、查询QPS（每秒查询数）、数据点摄入速率。吞吐指标直接反映负载水平，是容量规划的依据。
延迟类指标反映响应时间：写入P50/P95/P99延迟、查询P50/P95/P99延迟、WAL刷盘延迟。延迟的分位数比平均值更能反映用户体验——P99延迟的恶化往往被平均值掩盖。
资源类指标反映系统资源占用：CPU使用率、内存占用（含缓存与缓冲）、磁盘IO吞吐与IOPS、磁盘使用率、网络带宽。资源指标是性能瓶颈定位的入口。
连接与状态类指标反映服务健康：活跃连接数、连接池使用率、线程/协程数、后台任务队列长度。连接数突增往往预示上游异常或连接泄漏。
复制与一致性类指标反映集群状态：复制延迟、副本同步状态、节点存活状态、分片分布。分布式场景中复制延迟是关键告警项。
指标类别 | 代表指标 | 告警意义 | 采集频率 |
吞吐 | 写入TPS/查询QPS/数据点速率 | 负载水平 | 10-60秒 |
延迟 | P95/P99写入/查询延迟 | 用户体验 | 10-60秒 |
资源 | CPU/内存/磁盘/网络 | 瓶颈定位 | 10-60秒 |
连接 | 活跃连接数/队列长度 | 上游异常 | 10-60秒 |
复制 | 复制延迟/节点状态 | 集群健康 | 10-60秒 |
存储 | 磁盘使用率/压缩比 | 容量规划 | 1-5分钟 |
指标采集架构
指标采集的架构由”数据库导出指标→监控系统采集→存储→可视化与告警”构成。
数据库导出指标的方式有三种。内置HTTP接口（如 /metrics）暴露Prometheus格式的指标端点，是最通用的方式。系统表（information_schema、performance_schema类）通过SQL查询获取指标，灵活但查询开销需控制。日志导出将指标写入日志文件，由日志采集器解析，开销低但延迟高。
采集侧的架构有Pull与Push两种模式。Pull模式由监控系统定期抓取数据库暴露的指标端点，部署简单、目标发现灵活。Push模式由数据库侧主动推送指标到监控系统，适用于网络受限或短生命周期实例。
数据存储选择需要与监控规模匹配。数据库指标属于高基数场景（每个实例、每个分片、每个表都可能是有区分度的实体），用Prometheus本地存储会面临保留期短的问题，用专用时序存储承担长期存储更合适。指标采集频率通常为10-60秒，长期保留的聚合指标（如日峰值）数据量可控。
关键指标阈值与告警策略
阈值设定需要结合业务负载特征，而非套用通用值。同一指标在闲时与忙时的合理范围不同，静态阈值容易产生误报或漏报。
写入延迟告警方面，P99写入延迟超过基线数倍（如基线20ms，阈值100ms）时告警。延迟告警需要区分持续性升高与瞬时抖动，瞬时抖动可能由GC或后台任务引起，持续性升高才指向瓶颈。
内存使用率告警方面，内存使用率持续超过阈值（如80%）时需要关注，但需区分缓存占用与真实内存压力。时序数据库的缓存（数据块缓存、元数据缓存）会主动占用内存，内存使用率高但缓存命中率好属正常状态。
磁盘使用率告警最为直接。达到阈值（如85%）时应触发扩容或数据清理。磁盘使用率的增长速率（写入速率减去清理速率）用于容量预测。
复制延迟告警方面，分布式集群中从节点复制延迟持续增长意味着从节点处理能力不足或网络异常。复制延迟超过阈值时读请求可能读到旧数据，影响一致性。
告警策略需要分级与抑制。分级是按严重程度设置不同通知渠道；抑制是在上游故障引发大量下游告警时，只保留根因告警，避免告警风暴。
指标 | 参考阈值 | 持续条件 | 建议动作 |
P99写入延迟 | >基线3倍 | 持续5分钟 | 排查瓶颈 |
内存使用率 | >85% | 持续10分钟 | 分析缓存/泄漏 |
磁盘使用率 | >85% | 即时 | 扩容/清理 |
复制延迟 | >10秒 | 持续2分钟 | 检查节点/网络 |
慢查询比例 | >5% | 持续5分钟 | 分析SQL |
连接数 | >池上限80% | 持续5分钟 | 检查上游 |
慢查询分析与容量预测
慢查询分析是数据库性能治理的核心。慢查询日志记录执行时间超过阈值的查询，包含SQL文本、执行计划、扫描行数、耗时。分析慢查询可以识别缺失的索引、低效的查询模式、数据结构设计缺陷。
时序数据库的慢查询典型成因包括：超出预期的扫描范围（未按时间范围过滤）、标签过滤未命中分区、聚合查询扫描量过大、并发查询抢占资源。慢查询的分析需结合执行计划，判断瓶颈在扫描、计算还是IO。
容量预测依据历史增长趋势推算未来资源需求。写入速率、数据保留量、磁盘使用率的增长曲线用于预测何时触及容量上限。容量预测需要区分自然增长（业务数据增长）与异常增长（配置错误导致的无效数据累积），前者需扩容，后者需治理。
结语
数据库自身的可观测性建设常被忽视——它不像业务功能那样直接产生价值，却是平台稳定性的基础。一个成熟的数据平台，其数据库监控的完善程度往往与运维成熟度成正比。从技术演进看，数据库监控正从”被动告警”走向”主动容量规划与自动调优”，指标数据的价值从故障排查扩展到资源调度决策。TDengine提供的内置监控指标与系统表，使数据库自身状态可被外部监控系统采集，配合专用时序存储的长期保留能力，为数据库可观测性提供了相对完整的数据基础。
