Fluentbit

De wiki.nexiat.fr
Aller à la navigation Aller à la recherche
Fiche express
Type Agent de collecte et de transport de logs
Écosystème Projet Fluentd, hébergé par la CNCF
Pendant plus lourd Fluentd (même modèle de pipeline, agrégateur central)
Déploiement K8s typique DaemonSet (un pod par nœud)
Voir aussi Loki · Grafana · OpenTelemetry

Fluent Bit est un agent de collecte de logs léger du projet Fluentd (hébergé par la CNCF), écrit en C pur sans dépendance externe : un binaire statique de quelques Mo, taillé pour tourner sur chaque nœud d'un cluster ou dans des environnements contraints (edge, IoT) sans peser sur les ressources allouées aux workloads applicatifs. Il partage son modèle de pipeline et sa philosophie avec son grand frère Fluentd, plus riche en fonctionnalités mais nettement plus lourd — les deux se combinent souvent plutôt que de s'exclure : Fluent Bit en agent léger sur chaque nœud, Fluentd en agrégateur central qui reçoit, enrichit et route vers le backend final.

Caractéristique Fluentd Fluent Bit
Langage Ruby + C C pur
Empreinte mémoire ~40 Mo et plus de l'ordre du Mo
Plugins Environ un millier (gems Ruby) Une centaine, intégrés au binaire
Extensibilité Plugins Ruby Plugins C, Go, scripts Lua, WASM
Dépendances Runtime Ruby Aucune
Rôle typique Agrégateur central Agent / forwarder sur chaque nœud

Le pipeline commun

Fluentd et Fluent Bit partagent le même modèle de traitement d'un événement de log : celui-ci entre par un input, est décodé par un parser (texte brut → champs structurés), enrichi ou filtré par des filters, mis en tampon par un buffer, puis aiguillé selon son tag vers le ou les outputs finaux. Un événement porte toujours trois éléments : un tag hiérarchique servant au routage (par exemple kube.var.log.containers.app), un timestamp, et un record (le contenu, en paires clé/valeur).

Fluent Bit en pratique

Pipeline et formats de configuration

Le pipeline se déclare via des sections INPUT / FILTER / OUTPUT, au format classique .conf ou, sur les versions récentes, en YAML : 

[SERVICE]
    Flush         5
    Log_Level     info
    Parsers_File  parsers.conf
    storage.path  /var/log/flb-storage/

[INPUT]
    Name              tail
    Path              /var/log/containers/*.log
    Parser            cri
    Tag               kube.*
    Mem_Buf_Limit     5MB
    DB                /var/log/flb_kube.db

[FILTER]
    Name                kubernetes
    Match               kube.*
    Kube_URL            https://kubernetes.default.svc:443
    Merge_Log           On
    K8S-Logging.Exclude On

[OUTPUT]
    Name            forward
    Match           *
    Host            fluentd.logging.svc
    Port            24224

L'équivalent YAML, plus lisible sur des pipelines complexes à plusieurs inputs/outputs : 

service:
  flush: 5
  log_level: info
  parsers_file: parsers.conf

pipeline:
  inputs:
    - name: tail
      path: /var/log/containers/*.log
      parser: cri
      tag: kube.*
      mem_buf_limit: 5MB
      db: /var/log/flb_kube.db
  filters:
    - name: kubernetes
      match: kube.*
      merge_log: on
  outputs:
    - name: forward
      match: '*'
      host: fluentd.logging.svc
      port: 24224

Buffer et persistance

Fluent Bit bufferise en mémoire par défaut, ce qui est rapide mais borné par Mem_Buf_Limit : au-delà, l'input est mis en pause (backpressure) pour ne pas saturer la RAM du nœud, quitte à ralentir la collecte. Activer storage.type filesystem sur un input bascule sa persistance sur disque, ce qui évite la perte de lignes en cas de redémarrage ou de pic de charge côté output, au prix d'un stockage local à surveiller.

Le cas Kubernetes

C'est l'usage le plus répandu de Fluent Bit : déployé en DaemonSet (un pod par nœud), chaque instance monte en lecture seule /var/log/containers/ et /var/log/pods/ du nœud hôte, et suit ces fichiers via un input tail. Le parser cri décode le format écrit par containerd/CRI-O (), puis le filtre kubernetes interroge l'API server pour enrichir chaque ligne avec les métadonnées du pod d'origine (namespace, labels, annotations, nom du conteneur) avant émission.

Quelques points de vigilance récurrents sur ce déploiement :

  • Position de lecture — la base DB de l'input tail retient l'offset lu, pour reprendre après un redémarrage sans relire ni perdre de lignes.
  • Multiline — une stack trace Java ou Python s'étale sur plusieurs lignes physiques ; sans un parser/filtre multiline, chaque ligne remonte comme un événement séparé, rendant le log illisible en aval.
  • Rotation — containerd applique sa propre rotation de fichiers ; Fluent Bit gère la réouverture, mais un Rotate_Wait mal calé peut faire perdre les toutes dernières lignes avant rotation.
  • RBAC — le filtre kubernetes a besoin d'un ServiceAccount autorisé à lire les pods sur l'API server ; son absence se traduit par des logs non enrichis plutôt que par une erreur bloquante.

Architecture combinée recommandée

  [Nœud 1]           [Nœud 2]           [Nœud N]
  Fluent Bit (DS)     Fluent Bit (DS)    Fluent Bit (DS)
      |                   |                   |
      +-------------------+-------------------+
                          | (protocole forward)
                   Fluentd (agrégateur)
                   - enrichissement, buffer disque, multi-sortie
                          |
          +---------------+----------------+
          |               |                |
     Loki / ELK      S3 (archivage)   Kafka (streaming)

Cette répartition limite le nombre de connexions frappant directement le backend final (Fluent Bit ne parle jamais directement à Elasticsearch depuis N nœuds), tout en gardant la logique de parsing lourd et de routage multi-destination centralisée sur un nombre restreint d'instances Fluentd.

S'intégrer à une chaîne d'observabilité existante

Fluent Bit dispose d'un output natif vers Loki : dans une pile déjà construite autour de Grafana et Loki pour les métriques/logs, il peut pousser directement les lignes de log étiquetées (namespace, pod, labels Kubernetes), sans passer nécessairement par un Fluentd intermédiaire si le volume et la complexité de routage restent modérés. Sur un périmètre observabilité plus large englobant aussi traces et métriques applicatives, voir OpenTelemetry : la collecte de logs et le Collector OpenTelemetry poursuivent un objectif de convergence proche de celui de Fluent Bit, avec un écosystème et des standards différents (à comparer selon le reste de la chaîne déjà en place).

Choisir entre Fluentd et Fluent Bit

Besoin Recommandation
Agent sur chaque nœud Kubernetes (DaemonSet) Fluent Bit
Contrainte mémoire/CPU forte Fluent Bit
Agrégation centrale, routage multi-destination complexe Fluentd
Plugin très spécifique, écosystème large Fluentd
Transformation personnalisée en Ruby Fluentd

Voir aussi

  • Loki — backend de logs souvent ciblé en output direct depuis Fluent Bit
  • Grafana — visualisation des logs collectés
  • OpenTelemetry — convergence logs/métriques/traces, à comparer selon le périmètre visé
Récupérée de "https://wiki.nexiat.fr/index.php?title=Fluentbit&oldid=2663"