高可用系统日志丢失本质是采集链路中断，需按“应用输出→本地写入→agent采集→网络传输→平台存储”五段逐级验证：先查进程与本地日志是否产生，再验filebeat等agent存活及配置，接着测kafka/es连通性与积压，最后检索引模板与es写入失败指标。
高可用系统日志丢失，本质不是“没打日志”，而是日志在从产生到可查的链路中某处断了。排查要按路径逐段验证，不能只盯着最终平台有没有记录。
先确认日志是否真在本地产生
登录对应节点，直接检查应用进程的标准输出或日志文件：
- 用 ps aux | grep java 或 systemctl status your-service 确认进程仍在运行且未被OOM kill
- 查看日志文件最后更新时间：ls -lt /var/log/your-app/*.log，确认写入时间是否停滞
- 用 tail -f 实时观察是否有新内容输出；若无，说明应用层已中断写日志（如线程卡死、日志框架初始化失败）
检查采集Agent是否存活并正常读取
Filebeat、Fluentd 等采集器挂掉是日志丢失最常见原因，且往往无声无息：
- 执行 systemctl status filebeat 或 ps aux | grep fluentd 看进程是否存在
- 检查采集器配置中日志路径是否匹配实际文件位置（注意通配符、权限、SELinux限制）
- 查看采集器自身日志：journalctl -u filebeat -n 50 或其配置的 log.path，重点找 “Failed to stat”, “permission denied”, “offset file corrupted” 类报错
验证传输链路是否通畅
日志从采集端发出后，需经 Kafka/Pulsar 或直连 ES 等中间件，任一环节积压或阻塞都会导致延迟甚至丢弃：
- 若走 Kafka：用 kafka-topics.sh --describe 查 topic 分区 LAG；用 kafka-console-consumer.sh 手动消费确认消息是否到达
- 若直连 ES：检查采集器 output 配置中的 hosts 是否可达，curl -I http://es-host:9200/_cluster/health?pretty 看集群状态
- 留意采集器日志中是否频繁出现 “connection refused”、“timeout”、“429 Too Many Requests”
排查存储与索引层是否漏收或丢弃
即使日志进了 ES 或 ClickHouse，也可能因配置不当被静默过滤或拒绝：
- 检查索引模板（index template）中是否有 ingest pipeline 做了条件过滤或 drop 操作
- 在 Kibana 或 Grafana 中用 Discover 功能，将时间范围拉宽、关键词设为 “*”，确认是否有原始 raw 日志存在
- 查看 ES 的 _nodes/stats/indices 接口，比对
indexing.index_total和indexing.index_failed，失败数突增即为线索
