Fluentd-ElasticSearch配置两三（糗）事

上周末在家闲来无事，于是乎动手帮项目组搭建日志收集的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