日志采集失败需逐层验证Agent运行状态、配置有效性、文件可访问性及系统环境。先确认Logtail等Agent进程真实运行并上报心跳，再核对配置关联与路径权限，检查日志增量及轮转方式，最后排查服务端接收与解析异常。
日志采集失败，核心是确认“日志有没有被读到”和“读到了但有没有被正确送出去”。排查要从 Agent 运行状态、配置有效性、文件可访问性、系统环境四个层面逐层验证，不靠猜，靠可观测证据。
确认 Logtail（或对应 Agent）进程是否真实运行
Agent 没启动，一切无从谈起。不能只看进程名，要验证它是否在持续上报心跳：
- 执行 systemctl status aliyun-sls-logtail（阿里云 Logtail）或 systemctl status rsyslog/systemctl status fluentd（其他常见 Agent），确认 Active 状态为 active (running)
- 登录日志服务控制台 → 目标 Project → 机器组 → 查看该机器的心跳状态是否为 OK；若显示 fail 或无记录，说明 Agent 未连上服务端或已崩溃
- 检查进程日志：主机场景下查看 /usr/local/ilogtail/ilogtail.log，重点搜 ERROR、FATAL、panic；容器场景则需进入容器内执行相同操作
核对采集配置是否生效且路径准确
配置写对了，不等于 Agent 能读到；下发成功，不等于机器组真正匹配。关键动作是双向验证：
- 在控制台确认该采集配置已关联到目标机器组，且机器组中目标服务器 IP 或 hostname 已正确录入
- 检查配置中的日志路径是否真实存在：ls -l /path/to/your/logfile；注意软链接（Logtail 不支持）、挂载点优先级（emptydir > hostpath > NAS）
- 确认日志文件有可读权限：sudo -u root ls -l /path/to/your/logfile（Logtail 默认以 root 运行，需确保 root 可读）
- 容器场景下，用 kubectl exec -it
-- ls -l /path/in/container 确认路径在容器内确实存在并有内容更新
验证日志文件是否有增量、是否被轮转干扰
Logtail 是增量采集器，静止的文件不会触发读取；轮转方式不当会直接导致丢日志或重复：
- 执行 ls -lt /path/to/log*，确认日志文件时间戳是否在更新；若长时间无变化，采集自然为空
- 警惕 copytruncate 模式：logrotate 中若含 copytruncate，极易造成采集丢失或重复；应改用 create 模式（重命名旧文件 + 新建）
- NAS/OSS 类网络存储严禁用于日志采集源：元信息延迟、inotify 不支持、ls 性能差，会导致采集卡顿甚至中断；必须使用本地磁盘或 EBS
检查服务端接收与解析环节
即使 Agent 成功发送，也可能在服务端被拦截或解析失败：
- 进入 Logstore → 点击右上角图标 → 选择基础版诊断或高级版诊断，查看是否有报错代码（如 400: parse_failed、429: too_many_requests）
- 在消费预览中确认是否有原始日志到达；若有日志但查不到，大概率是未创建索引，需在 Logstore 的索引配置中开启字段索引
- 正则解析失败时，可在诊断页点击错误码查看具体哪一行、哪个字段匹配失败；建议先用简单正则（如 .*）测试通路，再逐步收紧
