Logs, die dir wirklich helfen: weniger Rauschen
03.02.2024 · 12:05 · Oliver Misch · Kommentieren
Viele Projekte haben Logs, aber kaum jemand nutzt sie gern. Entweder ist es zu wenig und man sieht gar nichts, oder es ist zu viel und man geht im Rauschen unter. Genau da liegt der Punkt: Logging ist kein „wir schreiben mal irgendwas in die Konsole“. Logging ist ein Werkzeug, das im Ernstfall Entscheidungen beschleunigt. Wenn es dich in kritischen Momenten nicht schneller macht, ist es meistens falsch aufgebaut.
Gute Logs sind nicht laut. Sie sind eindeutig. Sie sagen dir: Was ist passiert. Wann ist es passiert. In welchem Kontext ist es passiert. Und sie lassen dich die Ursache eingrenzen, ohne dass du erstmal eine Stunde herumrätst.
Das Problem ist selten fehlendes Logging, sondern falsches
Klassisches Anti-Pattern: überall „DEBUG“, „INFO“ und irgendwelche Texte ohne Struktur. Oder Logs, die ständig denselben Zustand ausgeben, während das eigentlich relevante Ereignis fehlt. Wenn du nach einem Fehler suchst, interessiert dich nicht der dauerhafte Normalbetrieb, sondern die Abweichung. Logging sollte deshalb auf Ereignisse fokussieren, nicht auf Dauerbeschallung.
Log-Level sind nur dann sinnvoll, wenn du sie ernst nimmst
Ein simples Schema reicht meistens: DEBUG, INFO, WARN, ERROR. Entscheidend ist, dass „ERROR“ wirklich nur dann kommt, wenn etwas schiefgelaufen ist. Und dass „WARN“ nicht als Müllkippe benutzt wird. Wenn du Warnungen ignorierst, weil sie sowieso ständig da sind, hast du das System verloren.
In vielen Projekten lohnt es sich, im Live-Betrieb eher weniger zu loggen und bei Bedarf gezielt hochzudrehen. Das setzt natürlich voraus, dass du die relevanten Stellen vorbereitet hast. Der Trick ist: wichtige Events sauber loggen, Details nur bei Bedarf.
Struktur schlägt Text
Logs als freier Text sind schwer filterbar. Strukturierte Logs sind dagegen Gold. Schon einfache Schlüssel helfen: event, request_id, user_id (oder besser pseudonym), route, duration_ms, status_code. Damit kannst du später suchen und gruppieren, statt Logs wie einen Roman zu lesen.
Besonders hilfreich ist eine Korrelations-ID. Ein Request läuft durch mehrere Komponenten, und du willst ihn als Linie verfolgen können. Wenn jeder Schritt dieselbe request_id loggt, findest du die Story in Sekunden. Ohne diese ID findest du zehn einzelne Fragmente und musst raten, was zusammengehört.
Weniger Rauschen heißt: nur loggen, wenn eine Entscheidung daraus wird
Stell dir bei jedem Log die Frage: Was mache ich, wenn ich das später sehe. Wenn die Antwort „nichts“ ist, gehört es meistens nicht rein. Ein Log sollte entweder eine Abweichung markieren, einen Zustand dokumentieren, der später relevant sein kann, oder eine Messgröße liefern, die du wirklich beobachtest.
- Routen, die ungewöhnlich lange dauern
- Fehlgeschlagene Logins oder Rate-Limit Treffer
- Wiederholte Validierungsfehler bei Formularen
- Externe APIs, die sporadisch langsam oder fehlerhaft sind
Sensible Daten gehören nicht ins Log
Das klingt banal, wird aber ständig vergessen. Passwörter, Tokens, komplette Formulardaten, persönliche Inhalte, das alles darf nicht in Logs landen. Selbst E-Mails oder IPs solltest du nur loggen, wenn du es wirklich brauchst, und dann am besten gekürzt oder gehasht. Logging ist schnell ein Datenschutz-Thema, und das wird gerne unterschätzt, weil „ist ja nur intern“. Intern ist nicht automatisch sicher.
Ein praktischer Test für dein Logging
Nimm einen echten Fehlerfall: ein kaputter Deploy, ein 500er, ein Formular das nicht ankommt. Und dann geh nur über Logs. Wenn du in fünf Minuten nicht näher an die Ursache kommst, ist das ein Signal. Gute Logs ersetzen nicht Debugging, aber sie sparen dir die Hälfte der Sucharbeit. Wenn du stattdessen erstmal überall neue Prints einbauen musst, fehlt die Grundlage.
Wenn Logs gut sind, fühlt sich Fehleranalyse weniger nach Detektivarbeit an und mehr nach Handwerk. Du siehst den Kontext, du siehst die Abweichung, du kannst reagieren. Genau darum geht’s: weniger Rauschen, mehr Klarheit.