Engineering-Handwerk · Tag 4: Observability von Tag 1

Willkommen zu Tag 4 unserer Serie Engineering-Handwerk. Es ist 3:12 Uhr nachts, dein Handy vibriert, ein Kunde schreibt „Die App geht nicht“ – und du starrst auf ein System, das dir nichts erzählt. Kein Log, das etwas verrät, keine Kurve, die den Ausschlag zeigt, keine Spur, die den Weg der kaputten Anfrage nachzeichnet. Genau dieser Moment entscheidet, ob du in zehn Minuten oder in zwei Stunden wieder im Bett liegst. Observability ist der Unterschied zwischen beidem. In dieser Episode zeigen wir dir, wie du Observability pragmatisch von Tag 1 einbaust – ohne teures Over-Engineering, aber mit genug Substanz, dass dein System dir bei einem Problem tatsächlich antwortet.

Der Begriff klingt nach großen Tools und noch größeren Rechnungen. Ist er aber nicht. Im Kern bedeutet Observability nur eines: Du kannst von außen verstehen, was innen passiert, ohne den Code neu deployen zu müssen. Und das erreichst du mit drei Bausteinen, die jeder von uns kennt, aber die selten sauber zusammenspielen: Logs, Metrics und Traces.

Die drei Säulen: Logs, Metrics, Traces – und wofür jede wirklich taugt

Diese drei werden gern in einen Topf geworfen, dabei beantworten sie völlig unterschiedliche Fragen. Wer sie verwechselt, baut das Falsche und wundert sich, warum das Debugging trotzdem weh tut.

Logs beantworten „Was ist genau passiert?“

Ein Log ist ein diskretes Ereignis mit Kontext: Diese Bestellung wurde angelegt, diese Zahlung schlug fehl, dieser Nutzer meldete sich an. Logs sind detailreich und teuer im Volumen. Sie sind dein Werkzeug, wenn du bereits weißt, dass etwas schiefging und den genauen Hergang rekonstruieren willst. Ihre Schwäche: Bei Millionen Zeilen pro Stunde findest du die eine relevante Zeile nur, wenn du vorher sauber strukturiert hast.

Metrics beantworten „Wie geht es dem System gerade?“

Eine Metrik ist eine über die Zeit aggregierte Zahl: Requests pro Sekunde, Fehlerrate, Antwortzeit im 95. Perzentil, offene Datenbankverbindungen. Metrics sind billig zu speichern und ideal für Dashboards und Alerts. Ihre Schwäche: Sie sagen dir, dass die Fehlerrate von 0,3 auf 6 Prozent gesprungen ist, aber nicht, warum. Für das Warum brauchst du wieder Logs oder Traces.

Traces beantworten „Wo im Weg ist die Zeit verloren gegangen?“

Ein Trace folgt einer einzelnen Anfrage durch alle beteiligten Systeme – vom Frontend über die API, den Auth-Service, die Datenbank bis zum externen Zahlungsanbieter. Jeder Abschnitt wird als Span mit Dauer erfasst. Traces sind unschlagbar, wenn eine Anfrage langsam ist und du nicht weißt, welcher der sieben Hops schuld ist. In einer Microservice- oder auch nur Backend-plus-Datenbank-Welt ist das oft die einzige Säule, die dir die Wahrheit über Latenz zeigt.

Die pragmatische Reihenfolge für ein junges Projekt: Fang mit strukturierten Logs an, ergänze schnell ein paar Kern-Metriken plus Health-Check, und führe Tracing ein, sobald du mehr als einen Dienst über Netzwerkgrenzen hinweg betreibst. Alles auf einmal am Tag 1 ist genau das Over-Engineering, vor dem wir warnen.

Strukturiertes Logging – ohne PII, mit Kontext

Der häufigste Fehler ist nicht das Fehlen von Logs, sondern ihre Form. Ein Log wie „Fehler beim Speichern“ ist wertlos. Es fehlt der Kontext, und es ist unstrukturierter Fließtext, den keine Maschine filtern kann.

Strukturiertes Logging heißt: Jede Zeile ist ein Objekt mit klaren Feldern statt eines Satzes. Statt eines vollen Prosatextes protokollierst du die Nachricht plus benannte Schlüssel – die Nutzer-ID, den betroffenen Endpunkt, die Dauer in Millisekunden, den Fehlercode. So kannst du später gezielt nach allen Ereignissen eines Kunden oder aller Fehler eines Typs filtern. In unserem Go-Backend nutzen wir dafür slog, im Frontend ein zentrales Logger-Util – nie das rohe Ausgeben auf die Konsole in Produktion.

Ein Grundsatz, der nicht verhandelbar ist: keine PII in Logs

Logs landen in Suchindizes, werden repliziert und länger aufbewahrt, als dir lieb ist. Personenbezogene Daten – E-Mail-Adressen, Klarnamen, Zahlungsdetails – haben dort nichts verloren. Das ist kein Nice-to-have, sondern DSGVO-Pflicht. Logge die Nutzer-ID als undurchsichtige UUID, niemals die E-Mail. Wenn du einen Request-Body zum Debuggen brauchst, maskiere sensible Felder vorher. Ein Datenleck über den Log-Aggregator ist genauso teuer wie eines über die Datenbank, wird aber viel häufiger übersehen.

Korrelation über eine Request-ID

Vergib pro eingehender Anfrage eine eindeutige Request-ID und häng sie an jede Log-Zeile, die aus dieser Anfrage entsteht. Damit wird aus verstreuten Einzelzeilen eine zusammenhängende Geschichte, und du hast gleichzeitig die Brücke zum Tracing schon halb gebaut.

Die wichtigsten Metriken – und die Alerts dazu

Du musst nicht hundert Metriken erfassen. Für die meisten Systeme reichen eine Handvoll, die sich an den „vier goldenen Signalen“ orientieren: Latenz, Traffic, Fehler und Sättigung.

• Fehlerrate der HTTP-5xx-Antworten – Warnung ab etwa einem Prozent, kritisch ab fünf Prozent. Das ist dein erster Indikator, dass etwas Grundlegendes kaputt ist.
• Antwortzeit im 95. Perzentil – nicht der Durchschnitt, denn der versteckt genau die langsamen Ausreißer, die deine Nutzer spüren. Warnung ab 500 Millisekunden, kritisch ab zwei Sekunden.
• Datenbank-Querydauer und Pool-Auslastung – der häufigste stille Killer. Wenn der Verbindungspool zu 90 Prozent voll ist, ist der Ausfall nur noch eine Frage von Minuten.
• Fehlgeschlagene Background-Jobs und die Größe der Dead-Letter-Queue – Fehler, die kein Nutzer direkt sieht, aber die sich zu einem Datenchaos auswachsen.

Wichtig ist nicht die Zahl selbst, sondern der Alert darauf. Eine Metrik ohne Schwellenwert ist nur Dekoration. Und ein Alert, der zu oft grundlos feuert, ist schlimmer als keiner – nach der dritten Fehlwarnung schaut niemand mehr hin. Alert-Müdigkeit ist ein echtes Betriebsrisiko, deshalb definieren wir Schwellen bewusst konservativ und trennen „Warnung“ (kann bis morgen warten) sauber von „kritisch“ (jemand muss jetzt aufstehen).

Tracing über Systemgrenzen und der Health-Check

Sobald eine Anfrage mehr als einen Dienst berührt, wird Tracing unverzichtbar. Der Trick ist, den Trace-Kontext über die Netzwerkgrenze hinweg weiterzureichen – üblicherweise über einen HTTP-Header, den jeder beteiligte Dienst liest und weitergibt. Der Standard dafür heißt OpenTelemetry und ist bewusst herstellerneutral, damit du dich nicht an ein einzelnes Tool kettest.

Der kleinste, aber wirkungsvollste Baustein ist der Health-Check. Ein Endpunkt, den Load-Balancer und Monitoring alle 60 Sekunden abfragen, und der nicht nur „ich lebe“ zurückgibt, sondern auch prüft, ob Datenbank, Cache und Worker erreichbar sind. So merkt dein System selbst, wenn eine Abhängigkeit wegbricht – bevor der erste Kunde es tut. Ein Health-Check kostet dich eine halbe Stunde und ist die günstigste Observability-Investition überhaupt.

Praxisbeispiel: der Fehler, den du ohne Observability nie findest

Ein konkreter Fall aus einem unserer Projekte. Ein Kunde meldete sporadisch: „Der Checkout hängt manchmal ewig.“ Manchmal. Nicht immer. Auf dem eigenen Rechner nie reproduzierbar. Das Frustrierendste, was es gibt.

Ohne Observability wäre das eine Woche im Nebel geworden: Code lesen, raten, hier ein Logausgabe-Statement einfügen, deployen, warten, wieder von vorn. Reines Stochern, weil niemand weiß, wo die Zeit verloren geht.

Mit Observability war es eine Sache von zwanzig Minuten. Die Latenz-Metrik zeigte klar: Das 95. Perzentil des Checkout-Endpunkts lag bei acht Sekunden, während der Median bei 300 Millisekunden blieb – also nur jede zwanzigste Anfrage betroffen. Das erklärte das „manchmal“. Der Trace einer dieser langsamen Anfragen zeigte dann den Schuldigen: Ein Span zum externen Zahlungsanbieter dauerte 7,5 Sekunden, aber nur, wenn zuvor ein bestimmter Cache-Eintrag abgelaufen war. Ohne Cache-Treffer lief jede Anfrage synchron gegen eine langsame Fremd-API. Der strukturierte Log mit der Request-ID lieferte den letzten Beweis: genau bei den langsamen Requests fehlte der Cache-Hit-Eintrag. Diagnose, Ursache, Fix – alles aus den drei Säulen heraus, ohne einen einzigen Debug-Deploy.

So gehst du vor

Wenn du ein neues Projekt startest oder ein bestehendes nachrüstest, ist das die pragmatische Reihenfolge:

• Schritt 1: Strukturiertes Logging einführen. Ein zentrales Logger-Util, JSON-Ausgabe, Request-ID pro Anfrage, harte Regel gegen PII. Das ist die Basis und an einem halben Tag erledigt.
• Schritt 2: Health-Check-Endpunkt bauen, der die kritischen Abhängigkeiten mitprüft und einen sauberen Status zurückgibt.
• Schritt 3: Die vier bis sechs Kern-Metriken erfassen – Fehlerrate, Latenz-Perzentil, DB-Auslastung, Job-Fehler – und ein einfaches Dashboard darauf aufsetzen.
• Schritt 4: Alerts mit bewusst konservativen Schwellen definieren, getrennt nach Warnung und kritisch, mit klarem Kanal für jeden.
• Schritt 5: Tracing über OpenTelemetry einführen, sobald mehr als ein Dienst beteiligt ist. Den Trace-Kontext konsequent über alle Grenzen weiterreichen.
• Schritt 6: Für jeden neuen kritischen Pfad ein kurzes Runbook schreiben – was tun, wenn dieser Alert feuert. Das spart dem müden Menschen um 3 Uhr morgens das Nachdenken.

Wichtig ist der letzte Grundsatz: Observability baut man von Anfang an ein, nicht nachträglich. Nicht weil man alles am Tag 1 fertig braucht, sondern weil das Nachrüsten unter Zeitdruck – nämlich während eines echten Ausfalls – nie gelingt. Ein System, das dir nichts erzählt, kannst du nicht reparieren, während es brennt. Pragmatisch heißt hier: die einfachen Bausteine früh, die aufwendigen erst wenn die Komplexität sie rechtfertigt. Kein Tracing-Overkill für einen einzelnen Monolithen, aber auch kein Produktivbetrieb ohne Health-Check und Fehlerrate-Alert.

Fazit

Observability ist kein Luxus für große Konzerne, sondern das Werkzeug, das aus Rätselraten strukturiertes Debugging macht. Die drei Säulen ergänzen sich: Metrics sagen dir, dass etwas nicht stimmt, Traces sagen dir wo, und Logs sagen dir warum. Baue strukturiertes Logging ohne PII, einen ehrlichen Health-Check und eine Handvoll Kern-Metriken von Tag 1 ein – und ergänze Tracing, wenn die Systemgrenzen es verlangen. Der Aufwand ist überschaubar, die Ersparnis in der ersten echten Nachtschicht enorm.

Das war Tag 4. Alle bisherigen Episoden findest du in der Serien-Übersicht. Wenn du Software bauen willst, die dir im Ernstfall antwortet statt schweigt, unterstützen wir dich bei der Softwareentwicklung – von der Architektur bis zum sauberen Betrieb. Erzähl uns von deinem Projekt: Kontakt aufnehmen.