监控数据异常，多数不是指标本身出错，而是采集环节出了问题。直接看图表数值没用，得先确认数据是不是真被采上来了。

检查采集配置是否生效

配置写了不等于生效了。常见疏漏包括：

• 采集规则未绑定到机器组，日志服务不会把配置推送到目标服务器
• 机器组心跳显示 fail，说明 agent 未运行、网络不通或认证失败
• 配置中指定的日志路径实际不存在，或权限不足（如 /var/log/app/*.log 但目录为空或属主非 ilogtail）
• 容器环境下未开启元信息预览，导致匹配不到目标容器日志路径

验证日志是否真正进入系统

别只盯 Grafana 或控制台图表，分两步验证：

Zynq Linux Hardware Debug

Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。

下载

• 在 SLS 控制台进入对应 Logstore → 消费预览，看是否有原始日志条目实时写入
• 若消费预览有日志但查询无结果，大概率是没建索引或索引字段类型不匹配（比如时间字段设为 text 而非 long）
• 若消费预览也为空，说明采集链路中断，需查客户端日志：/usr/local/ilogtail/ilogtail.log 和 logtail_plugin.log

排查传输与资源瓶颈

日志能读、能发，不代表能稳传。以下情况会导致数据延迟、丢失或截断：

• 单条日志超长（默认上限 512 KB），会被强制截断；可调大 max_read_buffer_size 至 8 MB（需改 ilogtail_config.json）
• 网络带宽不足或跨区域传输不稳定，表现为日志堆积、延迟上升；建议启用日志跨域传输加速（endpoint 改为 log-global.aliyuncs.com）
• 服务器负载过高（如 load > CPU 核数 × 2）、内存吃紧或磁盘 I/O 饱和，ilogtail 进程可能被调度延迟甚至 OOM kill

比对原始数据确认准确性

监控值不准？不一定工具错，可能是采集口径不一致。例如：

• Prometheus 的 node_cpu_seconds_total 是累计值，需用 rate() 计算瞬时使用率，直接取值无意义
• 对比 top -bn1 的 CPU 使用率和 Prometheus 抓取值时，注意采样周期是否对齐（如 top 默认 3 秒刷新，Prometheus scrape_interval 设为 15s 就会平滑掉尖刺）
• 内存可用量应以 MemAvailable 为准，而非 free；可用 free -h 和 cat /proc/meminfo | grep MemAvailable 双向印证