filebeat check file的延时越来越大
匿名 | 发布于2017年10月20日 | 阅读数:8014
架构:filebeat->kafka->logstash
首先,filebeat收集logs, logs在nfs中,我知道filebeat最好不要用于nfs的数据,但是架构不好改,可以接受小段时间的延迟。
问题是,随着filebeat运行时间的增加,filebeat check file造成的延时越来越大,造成下图,可以看出logstash接收数据时filebeat产生的空闲时间越来越大。
在filebeat的日志中也可以印证,INFO Non-zero metrics in the last 30s 的打印信息也增多,但nfs中另一个client是匀速产生log的。
filebeat.yml如下:
首先,filebeat收集logs, logs在nfs中,我知道filebeat最好不要用于nfs的数据,但是架构不好改,可以接受小段时间的延迟。
问题是,随着filebeat运行时间的增加,filebeat check file造成的延时越来越大,造成下图,可以看出logstash接收数据时filebeat产生的空闲时间越来越大。
在filebeat的日志中也可以印证,INFO Non-zero metrics in the last 30s 的打印信息也增多,但nfs中另一个client是匀速产生log的。
2017-10-20T18:44:23+08:00 INFO Non-zero metrics in the last 30s: filebeat.harvester.closed=1422 filebeat.harvester.open_files=-557 filebeat.harvester.running=-557 filebeat.harvester.started=865 libbeat.kafka.call_count.PublishEvents=3 libbeat.kafka.published_and_acked_events=2500 libbeat.output.kafka.bytes_read=39405 libbeat.output.kafka.bytes_write=2112722 libbeat.publisher.messages_in_worker_queues=4 libbeat.publisher.published_events=3282
filebeat.yml如下:
filebeat.prospectors:
- input_type: log
paths:
- /1/2/json/*/*/*/*/*.json
close_inactive: 5m
scan_frequency: 2s
output.kafka:
hosts: ["node2:9092", "node3:9092","node4:9092","node5:9092","node6:9092","node7:9092","node8:9092","node9:9092","node10:9092","node11:9092","node12:9092","node13:9092","node14:9092"]
topic: "filebeat-test"
max_message_bytes: 10000000
请问这是什么原因呀
2 个回复
medcl - 今晚打老虎。
赞同来自:
最好不用。
白衬衣 - 金桥
赞同来自: