Log-Aggregation bezeichnet das Sammeln von Log-Einträgen aus vielen Quellen wie Servern, Containern, Anwendungen und Cloud-Diensten und ihre Zusammenführung in einem zentralen System. Unterwegs werden Logs geparst, mit Metadaten angereichert und normalisiert, damit sie an einem Ort durchsucht, mit Metriken und Traces korreliert, aufbewahrt und analysiert werden können.
Was Log-Aggregation ist
Ein einzelner Request erzeugt in einem modernen System Logzeilen auf dem Load Balancer, im Ingress Controller, in drei Microservices und in der Datenbank, verteilt auf Dutzende Nodes, die eine Stunde später womöglich nicht mehr existieren. Die Log-Aggregation führt diese Zeilen zusammen. Statt sich per ssh auf einzelne Maschinen zu verbinden und mit grep zu suchen, fragen Engineers einen zentralen Speicher ab, der Logs aller Quellen mit einheitlichen Zeitstempeln und Metadaten enthält.
Aggregation ist die Grundlage für alles, was Teams mit Logs tun: Suche im Incident, Alerting auf Muster, Sicherheitsanalysen, Audit-Anforderungen und die Korrelation mit Metriken und Traces.
Die Pipeline der Log-Aggregation
- Sammeln. Ein Agent auf jedem Host liest Logdateien, Container-Ausgaben, journald oder Syslog. In Kubernetes verfolgt typischerweise ein Agent pro Node die Dateien, die die Container-Runtime unter
/var/log/podsschreibt. Anwendungen können Logs auch direkt per OTLP senden. - Parsen. Rohzeilen in Felder zerlegen: JSON dekodieren, reguläre Ausdrücke oder Grok-Muster für unstrukturierte Formate anwenden und Mehrzeiligkeit behandeln, damit ein Java-Stacktrace ein Eintrag wird statt vierzig.
- Anreichern. Kontext ergänzen wie Service-Name, Kubernetes-Namespace, Pod, Node, Cloud-Region und idealerweise Trace- und Span-IDs.
- Filtern und transformieren. Debug-Rauschen und Health-Check-Zeilen verwerfen, personenbezogene Daten maskieren, sehr gesprächige Quellen sampeln.
- Puffern und versenden. Bündeln, komprimieren und an das Backend senden, mit Plattenpuffer und Backpressure, wenn das Ziel langsam ist.
- Speichern und erschließen. Logs gemäß einer Richtlinie zur Datenaufbewahrung für Suche und Analyse vorhalten.
Verbreitete Collectoren sind Fluent Bit, Fluentd, Vector, Logstash und der OpenTelemetry Collector mit seinem Filelog Receiver.
Speichermodelle
| Modell | Funktionsweise | Abwägung |
|---|---|---|
| Volltextindex | Baut beim Ingest einen invertierten Index über den Log-Inhalt | Schnelle freie Suche; Indexierungsaufwand und Speicher-Overhead wachsen mit dem Volumen |
| Nur Label-Index | Indexiert wenige Labels, speichert Inhalte in komprimierten Chunks | Günstiger Ingest; Inhaltssuchen scannen mehr Daten, Labels brauchen niedrige Kardinalität |
| Indexfreies Lakehouse | Spaltenorientierter Speicher auf Object Storage, Schema-on-Read, massiv parallele Scans | Kein Index zu verwalten oder zu bezahlen; Abfragetempo hängt von der Scan-Engine ab |
Warum das wichtig ist
Ohne Aggregation verschwinden Logs kurzlebiger Container, sobald ein Pod neu eingeplant wird, und das Incident-Team verliert genau die Belege, die es braucht. Zentrale Logs ermöglichen außerdem übergreifende Fragen, etwa welche Services in den letzten zehn Minuten Verbindungsfehler zu einer bestimmten Datenbank protokolliert haben, und erfüllen regulatorische Anforderungen an Audit-Trails und Aufbewahrung.
Die Pipeline skalieren
Kleine Setups senden Logs direkt von den Node-Agents an das Backend. Mit wachsendem Volumen ergänzen die meisten Teams eine Gateway-Schicht: einen horizontal skalierten Pool von Collectoren, der Daten aller Agents empfängt und zentrale Verarbeitung übernimmt, etwa das Maskieren personenbezogener Daten, das Routing an verschiedene Ziele und Rate Limiting. Manche Architekturen setzen zusätzlich eine dauerhafte Message Queue wie Kafka zwischen Erfassung und Speicherung, um Lastspitzen abzufangen und Daten erneut einspielen zu können. Unabhängig vom Aufbau braucht jede Stufe begrenzte Puffer und eine klare Regel für den Fall von Backpressure: blockieren, auf die Platte auslagern oder die am wenigsten wertvollen Daten zuerst verwerfen.
Beispiel: Container-Logs anreichern
Ein beispielhafter Ausschnitt einer OpenTelemetry-Collector-Konfiguration, der Kubernetes-Container-Logs verfolgt, das Format der Container-Runtime parst und Pod-Metadaten ergänzt:
receivers:
filelog:
include: [ /var/log/pods/*/*/*.log ]
operators:
- type: container
processors:
k8sattributes: {}
batch: {}
service:
pipelines:
logs:
receivers: [filelog]
processors: [k8sattributes, batch]
exporters: [otlp]Best Practices
- Strukturiert loggen. Strukturiertes Logging als JSON oder OpenTelemetry Log Records erspart das meiste fehleranfällige Parsen.
- Trace-Kontext mitschreiben. Eine
trace_idin jeder Logzeile führt von einem langsamen Trace direkt zu den zugehörigen Logs. - UTC und präzise Zeitstempel verwenden und die ursprüngliche Ereigniszeit statt der Ingest-Zeit behalten.
- Am Rand filtern. Entscheiden Sie in der Pipeline, was gespeichert werden soll; verrauschte Logs früh zu verwerfen oder zusammenzufassen, ist der wirksamste Kostenhebel.
- Sensible Daten maskieren, bevor sie Host oder Pipeline verlassen, nicht erst nach dem Speichern.
- Die Pipeline selbst überwachen: verworfene Einträge, Pufferauslastung und Verzögerung von Ende zu Ende.
Typische Fehler
Typische Probleme sind unbegrenztes Debug-Logging in Produktion, mehrzeilige Stacktraces, die in einzelne Einträge zerfallen, fehlende Service-Namen, durch die sich Logs nicht zuordnen lassen, und nicht synchronisierte Uhren zwischen Hosts. Häufig wird zudem alles in eine teure indexierte Speicherschicht geschickt und die Aufbewahrung dann aus Kostengründen auf wenige Tage verkürzt. Damit fehlt die Historie, die man für schleichende Probleme braucht.
Wie Obseria unterstützt
Obseria Log Analytics speichert Logs in Obseria Lake, einem indexfreien Lakehouse mit Schema-on-Read, sodass neue Felder ohne Reindexierung durchsuchbar sind. Obseria Pipeline filtert, reichert an und maskiert personenbezogene Daten beim Ingest; gefilterte Daten kosten nur die Ingestion. Logs werden automatisch mit Traces und Topologie verknüpft und lassen sich mit OQL oder SQL abfragen.
