Log-Sampling bei Ereignissen mit hohem Volumen: jeden Fehler behalten, die repetitiven Zeilen sampeln

Worum es geht

Log-Sampling zeichnet nur einen gewählten Anteil von Ereignissen auf, die sich sonst mit wenig Variation tausendfach wiederholen würden: Debug-Zeilen je Anfrage, Cache-Treffer, Health-Check-Anfragen, Wiederholungen in einer Schleife. Das zerolog-README zeigt die gängigen produzentenseitigen Formen: einen einfachen Sampler, der ein Ereignis von N behält, einen Burst-Sampler, der pro Zeitraum eine bestimmte Anzahl Ereignisse durchlässt und den Rest anschliessend an einen Eins-von-N-Sampler übergibt, sowie einen Level-Sampler, der diese Regeln nur auf Debug-Ereignisse anwendet, während andere Level nicht gesampelt werden. Werkzeuge auf Pipeline-Seite tun dasselbe nachträglich; Vectors sample-Transform behält eine konfigurierbare Rate (eins von N) oder ein Verhältnis, kann ein key_field hashen, sodass alle Ereignisse mit demselben Wert gemeinsam behalten oder verworfen werden, trägt die angewandte Rate in ein Feld ein und nimmt eine Ausschlussbedingung für Ereignisse entgegen, die nie gesampelt werden dürfen. Die OpenTelemetry-Seite zum Sampling beschreibt das Gegenstück auf Trace-Seite: Head Sampling entscheidet früh und günstig, Tail Sampling entscheidet, nachdem der gesamte Trace gesehen wurde, und kann deshalb jeden Trace mit einem Fehler behalten, was Head Sampling allein nicht garantieren kann.

Warum es wichtig ist

Log-Volumen wird dreifach bezahlt: CPU und I/O beim Produzenten, Bandbreite und Indexierung in der Pipeline sowie Speicherplatz für die Aufbewahrungsdauer. Sampling senkt alle drei, aber nur, wenn das Überlebende weiterhin die Fragen beantwortet, die während eines Vorfalls gestellt werden.

So wird es angewendet

• Warnungen, Fehler, Audit- und Sicherheitsereignisse nie sampeln; Sampling nur auf Informations- und Debug-Level anwenden.
• Das Sampling an der Request- oder Trace-ID festmachen, damit eine behaltene Anfrage vollständig ist und eine verworfene ganz fehlt, statt dass jede Anfrage halb geloggt wird.
• Die Sampling-Rate in die behaltenen Ereignisse schreiben (sample_rate: 100), damit Zählungen zurückgerechnet werden können und Lesende wissen, was sie vor sich haben.
• Zählen zuerst auf Metriken verlagern; ein Zähler kostet je Scrape eine Messung, egal wie viele Ereignisse er gezählt hat, während Logging eine Zeile je Ereignis kostet.
• Für Ereignisse, bei denen ihr erstes Auftreten zählt, Burst-dann-Rate gegenüber reinem Eins-von-N bevorzugen: Die ersten Vorkommen eines neuen Fehlermusters kommen ungesampelt an.
• Einen Schalter bereithalten, um das Sampling für einen einzelnen Dienst während einer Untersuchung zu deaktivieren – und daran denken, ihn wieder einzuschalten.

Stolpersteine

Das Hashen eines Schlüssels mit ungleichmässig verteilten Werten verändert die effektive Rate, wie die Vector-Dokumentation anmerkt. Alarme oder Dashboards, die Log-Zeilen zählen, brechen still, sobald Sampling einsetzt. Sampling beim Produzenten und erneut in der Pipeline multipliziert die Raten. Compliance-Logs, die vollständig sein müssen, sind kein Kostenproblem, das sich mit Sampling lösen lässt.