Filebeat写ElasticSearch故障排查思路（上） - 教程
#作者：程宏斌
文章目录
- 一、现象确认
- （一）是完全写不进去，还是写入变慢？
- 1.1.1 完全写不进去的问题现象：
- 1.1.2 写入变慢问题现象：
- （二）是所有日志文件都受影响，还是部分路径/采集源有问题？
- 1.2.1 检查配置文件中input是否正确
- 1.2.2 查看Filebeat的harvester状态（是否正常采集各文件）
- 1.2.3 临时人工追加日志，测试是否被采集
- 二、网络与资源排查
- （一）Filebeat节点排查
- 2.1.1 排查容器资源
- kubectl top pod -n <namespace> | grep filebeat
- 2.1.2 排查宿主机资源瓶颈
- （二）ElasticSearch节点排查
- 2.2.1 磁盘I/O是否饱和
- 2.2.2 线程池是否阻塞（写入慢核心指标）
- curl -XGET "http://<es_host>:9200/_nodes/stats/thread_pool?pretty"
- 2.2.3 GC是否频繁导致停顿
- 2.2.4 节点是否压力过高（负载）
- 2.2.5 Heap使用是否接近上限（影响GC）
- （三）排查网络链路
- 2.3.1 使用ping检查基本连通性或网络抖动
- 2.3.2 使用telnet或nc检查端口可达性（连通性）
- 2.3.3 使用mtr或traceroute诊断链路质量
- mtr -rwzbc 100 <es_host>
- 2.3.4 Filebeat自身日志观察网络错误
一、现象确认
（一）是完全写不进去，还是写入变慢？
1.1.1 完全写不进去的问题现象：
- filebeat.events.added的数值呈现正常增长，filebeat.output.events.acked采集正常，但写入ElasticSearch失败。
- Filebeat日志中有大量：connectionre fused、403、429、bulk request failed明确是写入失败。
- ElasticSearch中无对应索引、indextemplate未配置、写入报错reject或auth entication denied。
- publish_failed、retrying提示频繁确认是完全无法写入。
1.1.2 写入变慢问题现象：
- filebeat.events.added和acked都在增加，但增速慢或者正在写，吞吐下降，比如30秒只写了几条，而业务实际每秒几百条，可能写入瓶颈或pipeline堵塞。
- Filebeat日志中bulk成功率下降，或出现flushtimeout Output队列堆积，或者es写入慢。
- ElasticSearch ingores est pipe line存在处理耗时、mapping冲突，可能是es处理链路问题。
- Filebeat CPU/内存占用较高，或pipe line active持续较大，可能是资源瓶颈或处理慢导致发送阻塞。
（二）是所有日志文件都受影响，还是部分路径/采集源有问题？
1.2.1 检查配置文件中input是否正确
filebeat.inputs:
- type:log
enabled:true
paths:
- /var/log/app1/*.log
- /var/log/app2/*.log- 检查是否存在路径拼写错误、权限问题。
- 某些路径是否实际没有匹配到文件（可用ls /var/log/app2/*.log验证）。
- 若用了exclude_path/ignore_older/multiline，是否误过滤了文件。
1.2.2 查看Filebeat的harvester状态（是否正常采集各文件）
在Filebeat的日志中搜索以下关键词，每30秒有一次统计：
"filebeat":{
"harvester":{
"files":{
"xxx":{
"name":"/var/log/test.log",
"read_offset":80,
"size":80,
"last_event_timestamp":"..."
}
},
"open_files":11,
"running":11,
"started":1
}
}重点看：
- 每个文件是否都在列表中（说明都被采集）。
- read_offset是否在增长（说明该文件有新内容被读取）。
- 是否有start_time但一直没last_event_timestamp（可能没新日志）。
- 某些文件不出现，可能是没被采集or被忽略了（看include/exclude）。
1.2.3 临时人工追加日志，测试是否被采集
可对每个配置路径下的日志执行：
echo"test-$(date)">>/var/log/app1.log
echo"test-$(date)">>/var/log/app2.log然后观察filebeat的metrics日志中是否有对应：
"filebeat.events":{
"added":2,
"done":2
}
"filebeat.output.events.acked":2或者在目标ElasticSearch中检查是否收到了新的写入。
（三）开始时间点是否明确？是否与版本发布、配置变更、网络波动相关？
1.3.1 ElasticSearch监控（IndexingRate）是否有下降趋势？
可以看到采集量是否在某个时间点突然下降。
1.filebeat日志中是否有突发的error/warning？
kubectl logs -f -nlogging filebeat-name
二、网络与资源排查
（一）Filebeat节点排查
2.1.1 排查容器资源
- 是否出现CPU、内存瓶颈（尤其在高并发场景）,查看容器资源使用情况
kubectl top pod -n | grep filebeat
- 查看容器资源限制
确认filebeat容器是否设置了资源限制过低
2.1.2 排查宿主机资源瓶颈
- top/htop查看实时使用
# top -p $(pgrep -d',' -f filebeat)或使用htop看CPU核心压力分布
- 检查系统总体资源
# free-m #内存占用情况
# vmstat 15 #CPU、内存、IO使用趋势
# iostat -x 15 #看IO等待时间- 查看filebeat占用
# ps aux | grep filebeat关注%CPU和%MEM列。
（二）ElasticSearch节点排查
2.2.1 磁盘I/O是否饱和
- 是否有磁盘IO饱和、线程池阻塞、GC频繁等异常？通过OS工具排查
# iostat -x 15%util 磁盘利用率 >80%→IO饱和
await IO请求等待时间（ms） >10ms→可能有磁盘瓶颈
r/s,w/s 读/写次数,持续高说明负载大
- ElasticSearch API查看磁盘使用
# curl -XGET "http://:9200/_cat/nodes?v&h=ip,disk.used_percent,disk.avail" 如果磁盘使用率接近85%以上，ElasticSearch会触发disk water mark限流机制，导致写入受阻。
2.2.2 线程池是否阻塞（写入慢核心指标）
使用_nodes/stats/thread_pool查看写入线程池状态：
curl -XGET “http://<es_host>:9200/_nodes/stats/thread_pool?pretty”
重点看这些线程池的状态：write、index、bulk，一旦bulk.rejected持续增长，则filebeat发过来的写入被拒绝了，直接影响写入吞吐。
2.2.3 GC是否频繁导致停顿
# curl -s http://<es_host>:9200/_nodes/stats/jvm?pretty
重点字段：
jvm.gc.collectors.old.collection_count
jvm.gc.collectors.old.collection_time_in_millis观察：
是否频繁触发Old GC？
每次Old GC是否耗时较高（>500ms）
- 用jstat工具（JVM原生命令）：
# jstat -g cutil 1s 频繁Full GC且内存回收率低，可能说明内存设置不合理或内存泄漏。
2.2.4 节点是否压力过高（负载）
# curl -XGET "http://:9200/_nodes/stats/os?pretty" 查看每个节点的load_average是否超过实际CPU核心数。如果负载飙高，也会影响写入。
2.2.5 Heap使用是否接近上限（影响GC）
# curl -XGET http://:9200/_nodes/stats/jvm?pretty 重点关注：
"heap_used_percent":25,
"heap_max_in_bytes":32212254720Heap使用率接近90%，很可能引发频繁GC，影响吞吐。
（三）排查网络链路
是否有抖动（ping、telnet检查连通性、丢包率）
2.3.1 使用ping检查基本连通性或网络抖动
# ping 2.3.2 使用telnet或nc检查端口可达性（连通性）
# telnet 9200 或
# nc -zv 9200 能成功连接说明端口通畅。若连接超时或失败，存在防火墙、ACL或网络故障问题。
2.3.3 使用mtr或traceroute诊断链路质量
使用方法：
mtr -rwzbc 100 <es_host>
分析链路中各跳的延迟、丢包率，是否集中在某一跳，是否网络设备质量不佳。
2.3.4 Filebeat自身日志观察网络错误
查看Filebeat日志中是否有类似如下报错：
- connection refused
- dial tcp timeout
- i/o timeout
- failed to publish events: client is not connected
这些通常意味着网络连接中断、ElasticSearch异常拒绝连接或网络抖动引发重试。
)
