Question

我有以下问题：

我们在高可用性设置中使用fluentd：几K个转发器 - ＆gt;最后使用复制插件的geo region和ES / S3聚合器。我们遇到了一个失败（日志没有经过几天），而且自从恢复以来，我们正在从流畅的ES集群中获取大量重复记录（包括恢复后的重复数据）。 @type copy plugin是否存在可能导致此类行为的已知问题？

我们的货运代理商＆＃39;配置：

# TCP input
<source>
    @type forward
    port X
</source>

# Logs Forwarding
<match XXX>
    @type forward

    # forward to logs-aggregators
        <server> 
#...
        </server>

    # use tcp for heartbeat
    heartbeat_type tcp

    # use longer flush_interval to reduce CPU usage.
    # note that this is a trade-off against latency.
    flush_interval 10s

    # use file buffer to buffer events on disks.
    # max 4096 8MB chunks = 32GB of buffer space
    buffer_type file
    buffer_path /var/log/td-agent/buffer/forward
    buffer_chunk_limit 4m
    buffer_queue_limit 4096

    # use multi-threading to send buffered data in parallel
    num_threads 8

    # expire DNS cache (required for cloud environment such as EC2)
    expire_dns_cache 600
</match>

我们的聚合商＆＃39;配置：

# TCP input
<source>
    @type forward
    port X
</source>

# rsyslog
<source>
  @type syslog
  port X
  tag  rsyslog
</source>

# Logs storage
<match rsyslog.**>
  @type copy
  <store>
    @type elasticsearch
    hosts X
    logstash_format true
    logstash_prefix rsyslog
    logstash_dateformat %Y-%m-%d


    num_threads 8

    utc_index true
    reload_on_failure true
  </store>
</match>

# Bids storage
<match X>
  @type copy

  # push data to elasticsearch cluster
  <store>
    @type elasticsearch
    hosts X

    # save like logstash would
    logstash_format true
    logstash_prefix jita
    logstash_dateformat %Y-%m-%d

    # 64G of buffer data
    buffer_chunk_limit 16m
    buffer_queue_limit 4096
    flush_interval 5m

    num_threads 8

    # everything in UTC
    utc_index true

    #  quickly remove a dead node from the list of addresses
    reload_on_failure true
  </store>

  # additionally store data in s3 bucket
  <store>
    @type s3
    aws_key_id X
    aws_sec_key X
    s3_bucket X
    s3_region X
    s3_object_key_format %{path}/%{time_slice}_%{index}.%{file_extension}
    store_as gzip
    num_threads 8
    path logs
    buffer_path /var/log/td-agent/buffer/s3
    time_slice_format %Y-%m-%d/%H
    time_slice_wait 10m
    utc
  </store>
</match>

Answer 1

我知道这是一个旧帖子，但我发布了这个答案，万一有人到达这里寻找解决方案。

有一个名为＆＃34; retry_wait ＆＃34;的配置项在所有缓冲插件中。此配置的默认值为1秒（ 1秒）。

这意味着fluentd向Elasticsearch发送请求，如果它在1秒内没有收到响应，它将再次重试发送请求。

从Elasticsearch方面来看，由于没有交易概念，他们无法识别是否再次发送相同的请求。因此，除了已经从第一个请求索引的内容之外，所有值都将再次尝试编入索引，从而导致重复。

在我们的案例中，大多数记录的结果大约有40-50个重复。

一个可能的解决方案可能是增加超时。通常30秒对我们有用，你可以玩这个值并找出一个适合你的数字。

Answer 2

我们的解决方案是添加一个标识字段，并使用id_key在流畅的配置（elasticsearch插件）中定义它。从那以后，无论td-agent重试多么艰难，我们都没有问题：）

流畅的高可用性设置和重复

2 个答案: