Eine Fluentd-Pipeline – sammeln, transformieren, senden – wird vollständig in einer Konfigurationsdatei ausgedrückt, die aus einer kleinen Menge von Direktiven besteht. Diese Anleitung behandelt, was jede Direktive tut, wie Tags sie verbinden und wie du eine Konfiguration prüfst, bevor du ihr echten Traffic anvertraust.

Wo die Konfigurationsdatei liegt

Fluentds eigene paketierte Distribution heißt fluent-package (der Nachfolger des älteren Namens td-agent; wenn du Dokumentation oder Tutorials liest, die td-agent erwähnen, ist es dasselbe Projekt unter seinem früheren Namen). So installiert liegt die Konfigurationsdatei typischerweise unter /etc/fluent/fluentd.conf. Eine separate Distribution, Calyptia Fluentd, die von einer anderen Organisation gepflegt wird, verwendet einen eigenen Pfad. Prüfe die Dokumentation deiner Installationsmethode auf den genauen Ort, statt einen anzunehmen.

Die drei Kerndirektiven

• <source> definiert, woher Logdaten kommen. Jede Source deklariert ein Plugin @type (tail, um einer Datei zu folgen, http, um Einträge per HTTP anzunehmen, und weitere) und, entscheidend, einen tag, das Label, das jeder Eintrag dieser Source durch den Rest der Pipeline trägt.
• <filter> verarbeitet Einträge, die auf ein gegebenes Tag-Muster passen, an Ort und Stelle, bevor sie eine Ausgabe erreichen. Übliche Verwendungen: Felder hinzufügen (Anreicherung), Felder entfernen (Schwärzung) oder Einträge, die auf ein Muster passen, ganz verwerfen.
• <match> ist der Ort, an den passende Einträge tatsächlich gesendet werden. Wie <filter> ist es auf ein Tag-Muster beschränkt, aber statt Daten an Ort und Stelle zu transformieren, ist es die Ausgabestufe der Pipeline: ein Ziel und das Plugin @type, das weiß, wie man dorthin schreibt.

<source>
  @type tail
  path /var/log/apache2/access.log
  pos_file /var/log/fluent/apache-access.log.pos
  tag apache.access
  <parse>
    @type apache2
  </parse>
</source>

<filter apache.access>
  @type record_transformer
  remove_keys host
</filter>

<match apache.access>
  @type elasticsearch
  host localhost
  port 9200
  index_name fluentd-apache
</match>

Von oben nach unten gelesen: Die Source verfolgt Apaches Access-Log, parst jede Zeile mit Fluentds eingebautem Parser für das Apache-Logformat und taggt jeden entstehenden Eintrag mit apache.access. Der Filter, auf dasselbe Tag beschränkt, entfernt das Feld host aus jedem Eintrag, bevor er weitergeht. Das Match, ebenfalls auf dieses Tag beschränkt, sendet die (nun geschwärzten) Einträge an Elasticsearch.

Tag-Matching, nicht nur Tag-Gleichheit

Das Tag-Muster eines <filter>- oder <match>-Blocks muss kein exakter String sein. apache.* passt auf jedes Tag, das mit apache. beginnt; ** passt auf alles. Das macht das Routing flexibel: Ein <match **>-Block kann als Catch-all-Ziel dienen, während spezifischere Muster bestimmte Sources unterschiedlich behandeln – die Daten einer Source schwärzen, die einer anderen nicht, oder verschiedene Sources an ganz unterschiedliche Ziele senden.

Daten lesen: der verschachtelte <parse>-Block

Eine rohe Logzeile in strukturierte Schlüssel-Wert-Daten zu verwandeln, ist die Aufgabe eines Parsers, konfiguriert als verschachtelter <parse>-Block innerhalb einer Source (diese verschachtelte Form ist die aktuelle Fluentd-Syntax; ältere Konfigurationsbeispiele zeigen Parsing-Optionen manchmal als flache Parameter direkt an der Source, was veralteter Stil ist und nicht mehr so von aktuellen Versionen erwartet wird). Fluentd liefert Parser für gängige Formate von Haus aus mit: json, apache2, nginx, syslog, csv sowie einen regexp-Parser für alles, was auf kein eingebautes Format passt:

<parse>
  @type json
</parse>

Den richtigen Parser für eine Source zu wählen verwandelt eine unstrukturierte Textzeile in Felder, die du einzeln filtern, anreichern und abfragen kannst, statt in einen undurchsichtigen Textblock.

Eine Konfiguration mit Includes strukturieren

Sobald eine Konfiguration mehrere Sources abdeckt, wird alles in einer Datei unhandlich. Die Direktive @include verteilt die Konfiguration auf mehrere Dateien:

# fluentd.conf
@include apache.conf
@include containers.conf
@include outputs.conf

Jede eingebundene Datei enthält ihre eigenen <source>-, <filter>- oder <match>-Blöcke, und Fluentd setzt sie zusammen, als wären sie inline geschrieben. Das ist rein organisatorisch; es ändert nichts daran, wie Tags, Matching oder Verarbeitung funktionieren, nur daran, wie lesbar die Konfiguration bleibt, wenn sie wächst.

Validieren, bevor du startest

Bevor du Fluentd wirklich startest, prüfe, ob eine Konfiguration überhaupt wohlgeformt ist:

fluentd --dry-run -c /etc/fluent/fluentd.conf

Das parst und validiert die Konfiguration, ohne echte Logdaten zu verarbeiten. Ein sauberer Dry Run garantiert nicht, dass die Pipeline tut, was du beabsichtigst – das muss weiterhin mit echten Daten getestet werden –, fängt aber ausgesprochene Syntaxfehler und Plugin-Fehlkonfigurationen ab, bevor sie als verwirrender Laufzeitfehler auftauchen.

Ausführen und beim Arbeiten zusehen

Für manuelles Testen (im Gegensatz zum Betrieb von Fluentd als verwalteter Hintergrunddienst, wie es normalerweise in der Produktion läuft):

fluentd -c /etc/fluent/fluentd.conf

Mit einer Source, die eine Datei verfolgt, und einem Match, das auf @type stdout schreibt, kannst du Einträge in Echtzeit durch die Pipeline fließen sehen, während neue Zeilen in die Quelldatei geschrieben werden. Das ist ein schneller Weg zu bestätigen, dass eine neue Source oder ein Filter tatsächlich das tut, was du erwartest, bevor du sie auf ein echtes Ziel richtest.