4.13更新
又出现了数次这样的问题，觉得不应该是es问题，又重新分析发现是修改过Logstash的配置文件，增加了日志的grok处理，导致logstash的处理速度跟不上kafka生产数据的速度，进而积压了数据。
看来还需要再优化。
===================以下是原分析================
背景
某天突然日志审计系统不能采集数据，表现为查不到最近1小时的日志。
日志写入ES有几条通路：
1、WebServer API接口服务->kafka集群->logstash->ES集群
2、filebeat syslog 514端口->kafka集群->logstash->ES集群
3、filebeat采集nginx日志目录/var/log/nginx/access.log->kafka集群->logstash->ES集群
4、metricbeat、auditbeat采集系统日志->kafka集群->logstash->独立ES节点（系统监控日志）
前三条通路都无法采集到数据，而第四条通路时而能采集到数据，时而不行。
思路
首先想定位出是哪个地方出了问题
1、先验证kafka集群的状态。
用命令行消费消息：
/usr/local/kafka/bin/kafka-console-consumer.sh --bootstrap-server 192.168.1.180:9092 --from-beginning --topic testtopic
验证结果：能正常的收到日志数据。说明kafka集群状态正常。
2、接着验证logstash输出是否正常
将logstash的配置文件做修改，
output {
stdout {
codec => rubydebug # 将日志输出到当前的终端上显示
}
}
查看输出结果，也是正常的。
3、最后，检查ES集群
重启ES集群发现主节点报错如下
[2020-09-01T15:59:41,129][ERROR][o.e.x.s.a.e.ReservedRealm] [node-3] failed to retrieve password hash for reserved user [elastic]
org.elasticsearch.action.UnavailableShardsException: at least one primary shard for the index [.security-7] is unavailable
参考这篇文章：https://blog.csdn.net/qq_25934401/article/details/108344875
依旧没有。
4、最后重建索引发现是前几天有一次es集群离线，Kafka日志消息积压过多，导致数据恢复较慢。耐心等待1小时，恢复了。。。
网友评论