Compatibilité de la configuration pour Fluentd en amont

Lorsque vous migrez de l'agent Logging vers Fluentd en amont, vous pouvez rencontrer des incompatibilités de configuration qui nécessitent des solutions de contournement pour éviter les erreurs de démarrage. Ce document explique comment résoudre les incompatibilités de configuration.

Modifications de la syntaxe entre l'ancien agent Logging et Fluentd en amont

Alors que l'ancien agent Logging s'appuie sur la syntaxe Fluentd v0.12, Fluentd en amont adopte la norme v1. Cette transition implique l'abandon de divers paramètres et l'introduction de nouvelles directives imbriquées pour gérer les fonctionnalités de base, en remplacement des structures de configuration plates utilisées précédemment.

Pour éviter les échecs de démarrage et vous assurer que vos journaux sont traités correctement, vous devez supprimer ou remplacer les paramètres obsolètes. Les sections suivantes expliquent comment mettre à jour les paramètres obsolètes.

Configuration du plug-in de sortie

Le tableau suivant liste les paramètres qui doivent être mis à jour dans la configuration de votre plug-in de sortie pour éviter les erreurs :

Ancienne syntaxe de l'agent Logging Syntaxe Fluentd en amont Remarques
N/A <buffer> Les plug-ins de sortie Fluentd sont compatibles avec une section <buffer>, sous la section <match>, pour configurer la mise en mémoire tampon des événements. Pour en savoir plus, consultez la section Config: Buffer Section de la documentation Fluentd.
buffer_type @type
buffer_path path
buffer_chunk_limit chunk_limit_size
disable_retry_limit retry_forever
retry_limit retry_max_times
max_retry_wait retry_max_interval
num_threads flush_thread_count
partial_success N/A Supprimez ce paramètre. Fluentd en amont active définitivement la réussite partielle par défaut, en supprimant uniquement les lignes non valides.

Voici un exemple de configuration du plug-in de sortie google-cloud dans l'ancien agent Logging :

<match **>
  @type google_cloud
  buffer_type file
  buffer_path /var/log/google-fluentd/buffers
  buffer_chunk_limit 512KB
  flush_interval 5s
  disable_retry_limit false
  retry_limit 3
  retry_wait 10
  max_retry_wait 300
  num_threads 8
</match>

Une fois les mises à jour effectuées, la configuration se présente comme suit :

<match **>
  @type google_cloud
  <buffer>
    @type file
    path /var/log/google-fluentd/buffers
    chunk_limit 512KB
    flush_interval 5s
    retry_forever false
    retry_max_times 3
    retry_wait 10
    retry_max_interval 300
    flush_thread_count 8
  </buffer>
</match>

Configuration du plug-in d'entrée

Le tableau suivant liste les paramètres qui doivent être mis à jour dans la configuration de votre plug-in d'entrée pour éviter les erreurs :

Ancienne syntaxe de l'agent Logging Syntaxe Fluentd en amont Remarques
format <parse> Pour en savoir plus, consultez la documentation Fluentd sur la section d'analyse de la configuration.
protocol_type <transport> Indiquez le protocole de transport syslog, soit udp, tcp, ou tls.
auto_typecast Supprimez ce paramètre lorsqu'il est utilisé dans le plug-in d'analyse json.

Voici un exemple de configuration de plug-in d'entrée dans l'ancien agent Logging :

<source>
    @type tail
    path /var/log/my-app.log
    format json
</source>

Une fois les mises à jour effectuées, la configuration se présente comme suit :

<source>
    @type tail
    path /var/log/my-app.log
    <parse>
      @type json
    </parse>
</source>

Sérialisation des objets Ruby Time

Fluentd en amont nécessite un casting explicite pour les objets Ruby bruts Time utilisés dans les filtres <record>, tels que record_transformer. Sans conversion explicite, ces objets entraînent une erreur de sérialisation fatale lors du vidage du tampon.

Si votre configuration utilise ${time} avec enable_ruby true, vous devez caster explicitement l'objet en type primitif, entier ou chaîne.

Voici un exemple de configuration d'un plug-in de filtre dans l'ancien agent Logging :

<filter foo.bar>
  @type record_transformer
   enable_ruby true
  <record>
    raw_timestamp ${time}
  </record>
</filter>

Une fois les mises à jour effectuées, la configuration se présente comme suit :

<filter foo.bar>
  @type record_transformer
   enable_ruby true
  <record>
    raw_timestamp ${time.to_i}
  </record>
</filter>

Valeurs par défaut du transport et de la compression gRPC

Le plug-in de sortie google_cloud vous permet de configurer l'utilisation de gRPC au lieu de REST/JSON pour communiquer avec l'API Cloud Logging.

Pour améliorer les performances, nous vous recommandons d'activer le transport gRPC et de configurer grpc_compression_algorithm gzip. Cette combinaison minimise la surcharge réseau et la consommation de processeur, en particulier lors du traitement de volumes de journaux importants.

Pour implémenter ces optimisations, utilisez la configuration suivante :

<match **>
  @type google_cloud
  use_grpc true
  grpc_compression_algorithm gzip
</match>

De plus, comme gRPC repose sur le streaming HTTP/2 sur le port 443, vous devez vous assurer que votre infrastructure réseau autorise le trafic gRPC/HTTP/2. Dans les environnements où gRPC est limité, vous devez définir explicitement use_grpc false pour revenir à la communication HTTP/REST standard.

Modèle d'expression régulière RabbitMQ

Les modèles d'expressions régulières utilisés par l'ancien agent Logging pour l'ingestion des journaux RabbitMQ sont souvent incompatibles avec les formats de sortie des versions modernes de RabbitMQ. Ces écarts peuvent entraîner un traitement incorrect des journaux ou leur suppression silencieuse lors du processus de collecte.

Les journaux RabbitMQ modernes intègrent une précision à la milliseconde dans les codes temporels, comme YYYY-MM-DD HH:MM:SS.L, et comportent des indicateurs de gravité et de PID spécifiques, comme [info] <0.213.0>, que l'ancienne expression régulière ne pouvait pas identifier.

Si votre agent Fluentd est configuré pour collecter les journaux RabbitMQ, vous devez mettre à jour la section <parser> pour gérer correctement le format de journal actuel.

Voici un exemple de configuration du plug-in d'entrée RabbitMQ pour l'ancien agent Logging :

<source>
  @type tail
  path /var/log/rabbitmq/*.log
  pos_file /var/lib/google-fluentd/pos/rabbitmq.pos
  tag rabbitmq
  format multiline
  format_firstline /^\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2}/
  format1 /^(?<time>\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2}) \[(?<severity>\w+)\] (?<message>.*)/
  time_format %Y-%m-%d %H:%M:%S
</source>

Une fois les mises à jour effectuées, la configuration se présente comme suit :

<source>
  @type tail
  path /var/log/rabbitmq/*.log
  pos_file /var/log/fluentd/pos/rabbitmq.pos
  read_from_head true
  tag rabbitmq
  <parse>
    @type multiline
    format_firstline /^\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2}\.\d{3}/
    format1 /^(?<time>\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2}\.\d{3}) \[(?<severity>[^\]]+)\] <(?<pid>[^>]+)> (?m:(?<message>.*))$/
    time_format %Y-%m-%d %H:%M:%S.%L
  </parse>
</source>