Filebeat写ElasticSearch故障排查思路（上）

#作者：程宏斌

一、现象确认

（一）是完全写不进去，还是写入变慢？

1.1.1 完全写不进去的问题现象：

1. filebeat.events.added的数值呈现正常增长，filebeat.output.events.acked采集正常，但写入ElasticSearch失败。
2. Filebeat日志中有大量：connectionre fused、403、429、bulk request failed明确是写入失败。
3. ElasticSearch中无对应索引、indextemplate未配置、写入报错reject或auth entication denied。
4. publish_failed、retrying提示频繁确认是完全无法写入。

1.1.2 写入变慢问题现象：

1. filebeat.events.added和acked都在增加，但增速慢或者正在写，吞吐下降，比如30秒只写了几条，而业务实际每秒几百条，可能写入瓶颈或pipeline堵塞。
2. Filebeat日志中bulk成功率下降，或出现flushtimeout Output队列堆积，或者es写入慢。
3. ElasticSearch ingores est pipe line存在处理耗时、mapping冲突，可能是es处理链路问题。
4. Filebeat CPU/内存占用较高，或pipe line active持续较大，可能是资源瓶颈或处理慢导致发送阻塞。

（二）是所有日志文件都受影响，还是部分路径/采集源有问题？

1.2.1 检查配置文件中input是否正确

filebeat.inputs:
- type:log
enabled:true
paths:
- /var/log/app1/*.log
- /var/log/app2/*.log

1. 检查是否存在路径拼写错误、权限问题。
2. 某些路径是否实际没有匹配到文件（可用ls /var/log/app2/*.log验证）。
3. 若用了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 排查容器资源

1. 是否出现CPU、内存瓶颈（尤其在高并发场景）,查看容器资源使用情况

kubectl top pod -n | grep filebeat

2. 查看容器资源限制
   确认filebeat容器是否设置了资源限制过低

2.1.2 排查宿主机资源瓶颈

1. top/htop查看实时使用

# top -p $(pgrep -d',' -f filebeat)

或使用htop看CPU核心压力分布

2. 检查系统总体资源

# free-m       #内存占用情况
# vmstat 15    #CPU、内存、IO使用趋势
# iostat -x 15 #看IO等待时间

3. 查看filebeat占用

# ps aux | grep filebeat

关注%CPU和%MEM列。

（二）ElasticSearch节点排查

2.2.1 磁盘I/O是否饱和

1. 是否有磁盘IO饱和、线程池阻塞、GC频繁等异常？通过OS工具排查

# iostat -x 15

%util 磁盘利用率 >80%→IO饱和
await IO请求等待时间（ms） >10ms→可能有磁盘瓶颈
r/s,w/s 读/写次数,持续高说明负载大

2. ElasticSearch API查看磁盘使用

# curl -XGET "http://<es_host>: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是否频繁导致停顿

1. # 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）

2. 用jstat工具（JVM原生命令）：

# jstat -g cutil <pid> 1s

频繁Full GC且内存回收率低，可能说明内存设置不合理或内存泄漏。

2.2.4 节点是否压力过高（负载）

# curl -XGET "http://<es_host>:9200/_nodes/stats/os?pretty"

查看每个节点的load_average是否超过实际CPU核心数。如果负载飙高，也会影响写入。

2.2.5 Heap使用是否接近上限（影响GC）

# curl -XGET http://<es_host>:9200/_nodes/stats/jvm?pretty

重点关注：

"heap_used_percent":25,
"heap_max_in_bytes":32212254720

Heap使用率接近90%，很可能引发频繁GC，影响吞吐。

（三）排查网络链路

是否有抖动（ping、telnet检查连通性、丢包率）

2.3.1 使用ping检查基本连通性或网络抖动

# ping <es_host> 

2.3.2 使用telnet或nc检查端口可达性（连通性）

# telnet <es_host> 9200

或

# nc -zv <es_host> 9200

能成功连接说明端口通畅。若连接超时或失败，存在防火墙、ACL或网络故障问题。

2.3.3 使用mtr或traceroute诊断链路质量

使用方法：

mtr -rwzbc 100 <es_host>

分析链路中各跳的延迟、丢包率，是否集中在某一跳，是否网络设备质量不佳。

2.3.4 Filebeat自身日志观察网络错误

查看Filebeat日志中是否有类似如下报错：

1. connection refused
2. dial tcp timeout
3. i/o timeout
4. failed to publish events: client is not connected
   这些通常意味着网络连接中断、ElasticSearch异常拒绝连接或网络抖动引发重试。