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

#作者：程宏斌

文章目录

一、现象确认
- （一）是完全写不进去，还是写入变慢？
- - [1.1.1 完全写不进去的问题现象：](#1.1.1 完全写不进去的问题现象：)
  - [1.1.2 写入变慢问题现象：](#1.1.2 写入变慢问题现象：)
- （二）是所有日志文件都受影响，还是部分路径/采集源有问题？
- - [1.2.1 检查配置文件中input是否正确](#1.2.1 检查配置文件中input是否正确)
  - [1.2.2 查看Filebeat的harvester状态（是否正常采集各文件）](#1.2.2 查看Filebeat的harvester状态（是否正常采集各文件）)
  - [1.2.3 临时人工追加日志，测试是否被采集](#1.2.3 临时人工追加日志，测试是否被采集)
二、网络与资源排查
- （一）Filebeat节点排查
- - [2.1.1 排查容器资源](#2.1.1 排查容器资源)
[kubectl top pod -n <namespace> | grep filebeat](#kubectl top pod -n <namespace> | grep filebeat)
- - [2.1.2 排查宿主机资源瓶颈](#2.1.2 排查宿主机资源瓶颈)
- （二）ElasticSearch节点排查
- - [2.2.1 磁盘I/O是否饱和](#2.2.1 磁盘I/O是否饱和)
  - [2.2.2 线程池是否阻塞（写入慢核心指标）](#2.2.2 线程池是否阻塞（写入慢核心指标）)
[curl -XGET "http://<es_host>:9200/_nodes/stats/thread_pool?pretty"](#curl -XGET "http://<es_host>:9200/_nodes/stats/thread_pool?pretty")
- - [2.2.3 GC是否频繁导致停顿](#2.2.3 GC是否频繁导致停顿)
  - [2.2.4 节点是否压力过高（负载）](#2.2.4 节点是否压力过高（负载）)
  - [2.2.5 Heap使用是否接近上限（影响GC）](#2.2.5 Heap使用是否接近上限（影响GC）)
- （三）排查网络链路
- - [2.3.1 使用ping检查基本连通性或网络抖动](#2.3.1 使用ping检查基本连通性或网络抖动)
  - [2.3.2 使用telnet或nc检查端口可达性（连通性）](#2.3.2 使用telnet或nc检查端口可达性（连通性）)
  - [2.3.3 使用mtr或traceroute诊断链路质量](#2.3.3 使用mtr或traceroute诊断链路质量)
[mtr -rwzbc 100 <es_host>](#mtr -rwzbc 100 <es_host>)
- - [2.3.4 Filebeat自身日志观察网络错误](#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://<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是否频繁导致停顿

# 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 <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日志中是否有类似如下报错：

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

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 | grep filebeat

2.1.2 排查宿主机资源瓶颈

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

free-m #内存占用情况

vmstat 15 #CPU、内存、IO使用趋势

iostat -x 15 #看IO等待时间

ps aux | grep filebeat

（二）ElasticSearch节点排查

2.2.1 磁盘I/O是否饱和

iostat -x 15

curl -XGET "http://<es_host>:9200/_cat/nodes?v&h=ip,disk.used_percent,disk.avail"

2.2.2 线程池是否阻塞（写入慢核心指标）

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

2.2.3 GC是否频繁导致停顿

jstat -g cutil <pid> 1s

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自身日志观察网络错误