排查Linux系统延迟问题，关键在于理清监控链路中各环节的职责与数据流转关系。延迟可能出现在采集、传输、存储、计算或展示任一环节，不能只盯着最终图表上的毛刺或高值。
采集层：指标源头是否准确及时
监控数据的第一环是采集器（如Prometheus的exporter、Telegraf、Zabbix agent等）。若采集本身滞后或失败，后续所有分析都失真。
- 检查采集器进程状态和日志，确认无OOM、频繁重启或连接拒绝
- 验证采集间隔（scrape_interval）是否合理：过长会漏掉瞬时抖动，过短则加重目标负载和网络压力
- 观察采集耗时指标（如prometheus_target_scrape_duration_seconds）是否持续偏高，超时说明目标响应慢或网络拥塞
- 对高频率指标（如每秒网络包数），优先用汇总型exporter（如node_exporter的--collector.systemd）而非逐进程轮询
传输与存储层：数据是否被积压或丢弃
从采集端到存储端（如Prometheus TSDB、InfluxDB、VictoriaMetrics）之间存在缓冲与序列化过程，网络抖动、队列满、磁盘I/O瓶颈都可能导致延迟累积。
- 查看采集器的prometheus_target_scrape_samples_post_metric_relabeling与prometheus_target_scrape_series_added差值，过大说明relabel规则过滤激进或样本爆炸
- 监控TSDB WAL写入延迟（prometheus_tsdb_wal_fsync_duration_seconds）和head内存使用（prometheus_tsdb_head_series），WAL fsync超时或head暴涨常预示磁盘或CPU瓶颈
- 检查远程写（remote_write）队列长度（prometheus_remote_storage_queue_length）和发送失败率，持续非零说明后端存储写入能力不足或网络不通
查询与计算层：Dashboard延迟不等于系统延迟
Grafana面板卡顿、PromQL查询超时，常被误判为“系统变慢”，实则是查询复杂度、数据量或函数使用不当所致。
- 避免在大时间范围内直接用rate()或histogram_quantile()，先用sum by()或avg by()降维再计算
- 确认查询时间范围（$__range）与step参数匹配：查7天数据却设step=1s，会触发数万点计算，极易OOM或超时
- 用explain或/api/v1/status/tsdb查看活跃series数和label基数，高基数（如含UUID、URL路径）是性能杀手，需通过relabelling聚合或过滤
反向验证：用基础命令交叉比对
当监控数据显示异常但业务无感，或反之，需脱离监控系统，用Linux原生命令验证真实状态。
- 用sar -u 1 5看实时CPU，对比监控中1m load与cpu_usage是否趋势一致
- 用pidstat -d 1 5抓IO等待进程，验证node_disk_io_time_weighted_seconds_total突增是否对应具体进程
- 用tcpretrans（bpftrace）或ss -i查重传与RTO，判断网络层是否真丢包，而非Exporter上报延迟
监控链路不是单向流水线，而是一个带反馈、有状态、可中断的协同系统。定位延迟，要像查故障一样分段隔离、双向印证，而不是在Grafana里反复缩放时间轴。
