4. 存储层故障排查：时序数据库写入瓶颈、查询超时、磁盘IO打满的排查方法

时序数据库（TSDB）是监控系统的核心存储组件，其性能直接决定告警延迟、查询响应与数据完整性。本章聚焦 Prometheus 与 InfluxDB 两类主流 TSDB，从写入瓶颈、查询超时、磁盘 IO 打满三个维度，给出架构视角的排查路径与根因定位方法。

4.1 写入瓶颈排查

写入瓶颈的典型现象：指标数据出现断点、Prometheus remote write 报 503、InfluxDB 写入延迟飙升。排查路径分为三层：客户端限速 → 服务端队列 → 存储引擎背压。

4.2 查询超时排查

查询超时通常由索引扫描过大、全表扫描或并发查询排队引起。Prometheus 与 InfluxDB 的查询路径差异较大，需分别对待。

4.2.1 Prometheus 查询链路

• Step 1：检查查询范围与时间跨度。大跨度查询（如 30d）会触发大量 block 合并扫描。
• Step 2：查看 prometheus_tsdb_queries_total 与 prometheus_tsdb_query_duration_seconds 分位数。
• Step 3：确认是否命中 --query.max-concurrency 限制（默认 20）。

# 查看当前活跃查询
curl http://localhost:9090/api/v1/status/active_queries

# 查看查询延迟分布
prometheus_tsdb_query_duration_seconds{quantile="0.99"}

4.2.2 InfluxDB 查询链路

• Step 1：检查查询是否触发全表扫描（无时间范围或 tag 过滤）。
• Step 2：查看 SHOW QUERIES 识别慢查询。
• Step 3：确认 max-concurrent-queries 与 query-timeout 配置。

# 查看当前运行中的查询
SHOW QUERIES

# 终止超时查询
KILL QUERY <query_id>

4.3 磁盘 IO 打满排查

磁盘 IO 打满是 TSDB 故障中最具破坏性的场景，通常由 Compaction 风暴、WAL 写入放大或查询临时文件溢出引起。排查需区分读写 IO 与IO 等待。

4.4 典型故障场景与根因对照

4.5 架构级优化建议

• 存储分离：将 WAL 目录与数据目录分别挂载到不同磁盘（WAL 使用低延迟 NVMe，数据使用大容量 SSD）。
• 写入限速：在采集端（如 Prometheus Agent 或 Telegraf）配置 max_samples_per_send 与 capacity，避免突发写入压垮 TSDB。
• 查询超时兜底：设置合理的 query-timeout（Prometheus 默认 2m，InfluxDB 默认 30s），并启用慢查询日志。
• Compaction 窗口：在业务低峰期（如凌晨）手动触发 Compaction，避免与写入高峰重叠。