Fluentd configuration haute disponibilité et les doublons

Question

J'ai le problème suivant:

Nous utilisons fluentd dans une configuration à haute disponibilité: quelques K de transitaires -> agrégateurs pour la région géographique et ES/S3 à la fin à l'aide copier le plugin. Nous avons rencontré un problème (les journaux ne sont pas restés ouverts pendant quelques jours) et, depuis la récupération, nous recevons des tonnes d'enregistrements dupliqués de notre cluster ES (y compris des données dupliquées après la récupération). Y at-il des problèmes connus avec le @type copy plugin qui pourraient causer ce genre de comportement?

Nos de la config:

# 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> 

Nos agrégateurs de transitaires de config:

# 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

La solution pour nous était d'ajouter un champ d'identité et de le définir dans la configuration fluentd (plugin elasticsearch) en utilisant id_key. Depuis lors, nous n'avons plus de problèmes, peu importe à quel point td-agent réessaye :)

Answer 2

Je sais que c'est un vieux fil, mais je posterai cette réponse juste au cas où quelqu'un atteint ici la recherche de la solution.

Il existe un élément de configuration appelé "retry_wait" dans tous les plugins bufférisés. La valeur par défaut de cette configuration est 1s (1 seconde). Cela signifie que fluentd envoie une requête à Elasticsearch et si elle ne reçoit pas de réponse dans la seconde qui suit, elle réessaye d'envoyer la requête. Du côté de Elasticsearch car il n'y a pas de concept de transactions, ils ne peuvent pas identifier si la même demande est encore envoyée sur non. Donc, en plus de ce qui a déjà été indexé à partir de la première requête, toutes les valeurs vont à nouveau essayer d'être indexées, ce qui se traduira par des doublons.

Dans notre cas, nous avons enregistré environ 40 à 50 doublons pour la plupart des enregistrements.

Une solution possible pourrait être d'augmenter le délai d'expiration. 30 secondes travaille pour nous normalement, vous pouvez jouer avec cette valeur et trouver un nombre qui fonctionne pour vous.