filebeat
容器平台最近发布有点问题,整个平台每日产生日志量大约在300GB ,filebeat采用sidecar的方式采集std管道内的日志;
如此巨大的日志量对filebeat的pod性能造成巨大的压力,刚刚开始filebeat每个daemonset的性能配置为200M Hz的cpu和200 MB内存,在此次冲击之下部分filebeat的pod性能不足直接hang死;
后续将filbeat的cpu性能提升到1G Hz的cpu和2GB的内存,大规模的日志量测试中发现filebeat性能正常,未出现hang死的情况;
但是又发现了另外一种情况,由于短时间内部分容器平台的主机节点产生了大量的docker日志,导致节点主机的/var/log目录被大量占用,触发监控告警;
按照docker日志的log rotate的原理,docker自己会控制日志量,即使段短时间内堆积了大量日志,docker会通过加快删除旧日志的方式,维持本地磁盘的日志文件占用量;
但是在此次的场景中,发现docker日志的log rotate功能好像并未正常应用,通过lsof命令发现,filebeat保持着的文件资源,可以发现许多被filebeat占用空间的失效文件(deleted)文件。
此时,通过直接kill掉filebeat的daemonset可以快速释放这些deleted文件,但是此方法并非长久之计,需要通过改变filebeat的文件句柄占用时长参数。
对于我上面的这个问题,之所以有大量的(deleted),未释放文件句柄,还有个背景,就是由于磁盘空间非常有限,临时加了任务,每小时删除12小时前的日志,换句话说,定时任务会自动删除此时filebeat正在打开着的一些文件,于是这些文件,就变为了未释放的文件,因此实际文件删除了,但空间未被释放。
filebeat的配置文件filebeat.yml,其实有两个参数,
# close_older: 1h 说明:Close older closes the file handler for which were not modified for longer then close_older. Time strings like 2h (2 hours), 5m (5 minutes) can be used.
即如果一个文件在某个时间段内没有发生过更新,则关闭监控的文件handle,默认1小时。
即当文件名称有变化时,包括改名和删除,会自动关闭一个文件。
这两个参数结合起来,根据应用需求,一个文件30分钟内不更新,则需要关闭句柄,文件改名或删除,需要关闭句柄,
close_older: 10m #释放速度加快6倍
force_close_files: true
可以满足,filebeat采集日志,以及定时删除历史文件,这两个任务的基本要求。
Filebeat holding deleted files which consumes disk space
Filebeat holds open deleted file descriptions with close_removed
联系客服