Les inputs (entrées) en détail

1. Le rôle des inputs #

La porte d'entrée des données.

Principe #

Un input collecte des données : il lit un fichier, écoute un port, interroge le système ou reçoit un protocole. Chaque enregistrement reçoit un tag (par exemple kube.var.log.containers.api-xyz.log) : c'est lui que les filtres et les outputs utilisent, via Match, pour décider de ce qu'ils traitent.

2. Lire des fichiers avec tail #

L'input le plus utilisé.

Configuration #

pipeline:
  inputs:
    - name: tail
      tag: app.*
      path: /var/log/app/*.log
      exclude_path: /var/log/app/*.gz
      db: /var/lib/fluent-bit/tail-app.db      # positions de lecture
      read_from_head: false                    # nouveau fichier : partir de la fin
      refresh_interval: 10                     # recherche de nouveaux fichiers (s)
      rotate_wait: 30                          # continuer à lire l'ancien fichier après rotation (s)
      skip_long_lines: on
      multiline.parser: docker, cri, java      # recoller les lignes d'une exception
      mem_buf_limit: 50MB
      storage.type: filesystem

Points d'attention #

• path accepte les jokers ; le tag avec * est complété par le chemin du fichier (points à la place des barres).
• Le multiligne se règle dès l'input : docker et cri reconstituent les lignes coupées par le runtime ; java, python, go regroupent les traces de pile.
• Le fichier DB doit être sur un volume persistant (hostPath sur Kubernetes).

3. Autres inputs utiles #

Réseau, journald, OpenTelemetry.

Exemples #

pipeline:
  inputs:
    - name: systemd
      tag: host.journal
      systemd_filter: _SYSTEMD_UNIT=nginx.service
      read_from_tail: on
    - name: syslog
      mode: udp
      listen: 0.0.0.0
      port: 5140
      parser: syslog-rfc5424
    - name: opentelemetry          # reçoit logs, métriques et traces OTLP/HTTP
      listen: 0.0.0.0
      port: 4318
    - name: forward                # depuis d'autres agents Fluent Bit ou Fluentd
      listen: 0.0.0.0
      port: 24224
    - name: node_exporter_metrics
      tag: host.metrics
      scrape_interval: 30

Mémoire et contre-pression #

Quand une sortie ralentit, les données s'accumulent. mem_buf_limit borne la mémoire d'un input : une fois atteint, l'input est mis en pause (risque de perte pour les inputs réseau). Avec storage.type: filesystem, les chunks débordent sur disque et rien n'est perdu.

service:
  storage.path: /var/lib/fluent-bit/buffer
  storage.sync: normal
  storage.backlog.mem_limit: 50M

Bonne Pratique : Pour les inputs réseau (syslog, http, forward), le tampon disque est indispensable : un client qui envoie pendant une pause perd ses messages.