上周末在家闲来无事,于是乎动手帮项目组搭建日志收集的EFK环境,最终目标的部署是这个样子的:
在每个应用机器上部一个Fluentd做为代理端,以tail方式读取指定的应用日志文件,然后Forward到做为汇聚端的Fluentd,汇聚端对日志内容加工、分解成结构化内容,再存储到ElasticSearch。日志内容的展现由Kinana实现。
Fluentd是什么? Fluentd是一个完全免费的、完全开源的日志收集器,可以与125多种系统相对接,实现“日志一切”架构。
由于前面已经在Kubernetes容器平台上部署好了ElasticSearch与Kibana,周末只是忙乎Fluentd的安装配置,以前没有使用过,现学再卖,结果折腾过程中出现了几个问题,在这里念叨记录一下。
Output插件的请求超时时间
在我们的部署中,只使用了Fluentd两种Output插件,一个是代理端用于向后传递日志内容的Ouput-Forward,一个是用于向ES中存储数据的Output-ElasticSearch。
- 代理端Output-Forward插件配置(最初)
<match **>
@type forward
require_ack_response ture
<server>
host 10.xxx.xx.xx
port 24224
</server>
<buffer tag>
@type file
path /xxx/xxx/buffer
flush_interval 10s
total_limit_size 1G
</buffer>
</match>
- 汇聚端Output-ElasticSearch插件配置(最初)
<match xxxxx.xxxxx.**>
@type elasticsearch
host 10.xxx.xx.xxx
port 30172
logstash_format true
logstash_prefix log.xxxxx.xxxxx.xxxxx-
<buffer tag>
@type file
path "/xxx/xxx/fluentd/aggregator/xxxx/buffer"
total_limit_size 20G
flush_interval 10s
</buffer>
</match>
配置完以后,简单测试跑通后,满心欢喜地拿应用某台机器上1-3月产生的日志灌数。从Kibana界面上代表日志数量的绿柱向上增长,几千…几万..百万…两百万,当时还发图片给项目组的显摆了一番。后面想着不可能有这么多日志记录吧!? 登录到应用服务器上去日志目录里wc了一把,所有文件行数总和才150万! 晕死!
跑进Kibana界面细观瞧,才发现入库的日志记录有重复内容,比如:某条记录就重复了233次。 当时也不知道具体原因,猜测着可能是Output-ElasticSearch插件因接收响应超时,叕重发了内容到ElasticSearch,所以试着查到相应参数:request_timeout
加入到汇聚端配置中,参数默认值是:5s