Monitoring und Observability: Was Sie mindestens brauchen

Worin unterscheiden sich Monitoring und Observability?

Monitoring beantwortet Fragen, die Sie vorher gestellt haben. Sie legen fest, dass die Antwortzeit unter 800 Millisekunden bleiben soll, und bekommen ein Signal, wenn sie es nicht tut. Das funktioniert gut, solange Sie wissen, was schiefgehen kann.

Observability ist die Eigenschaft eines Systems, auch Fragen zu beantworten, die vorher niemand gestellt hat. Wenn am Montagvormittag nur die Aufträge eines bestimmten Kunden hängen bleiben, hilft kein vorbereiteter Schwellenwert. Dann brauchen Sie Daten, in denen sich diese Spur nachträglich verfolgen lässt.

Der Unterschied ist kein Werkzeugstreit. Er beschreibt, wie tief Sie graben können, wenn ein Vorfall nicht in Ihr Raster passt. Kleine Systeme kommen lange mit gutem Monitoring aus; sobald mehrere Dienste zusammenspielen, wird die zweite Fähigkeit unverzichtbar.

Praktisch entscheidet sich das an einem einzigen Merkmal: Lassen sich zusammengehörige Vorgänge über alle Datenarten hinweg wiederfinden? Wenn jede Anfrage eine mitlaufende Kennung trägt, die in Protokollen, Metriken und Traces auftaucht, können Sie einer Beschwerde bis zur einzelnen Zeile folgen. Fehlt diese Kennung, bleibt Ihnen Raten.

Welche drei Datenarten sammeln Sie und wofür?

• Metriken sind Zahlenreihen über die Zeit: Anfragen pro Minute, Fehlerquote, Speicherverbrauch. Sie sind kompakt, günstig zu halten und beantworten „wie viel“ und „seit wann“.
• Protokolle sind Textzeilen mit Zeitstempel, die einzelne Ereignisse beschreiben. Sie beantworten „was genau ist passiert“, brauchen aber deutlich mehr Speicher.
• Traces verfolgen eine einzelne Anfrage über alle beteiligten Dienste hinweg und zeigen, wo die Zeit geblieben ist. Sie beantworten „warum war das langsam“.

Die drei ergänzen sich in genau dieser Reihenfolge. Eine Metrik zeigt, dass etwas nicht stimmt. Protokolle zeigen, was geschehen ist. Ein Trace zeigt, an welcher Stelle im Zusammenspiel es hakt.

Für eine überschaubare Anwendung mit einer Datenbank reichen Metriken und Protokolle. Traces lohnen sich, sobald eine Nutzeranfrage durch mehr als zwei oder drei eigenständige Dienste läuft — bei einem Logistikdienstleister etwa durch Auftragsannahme, Tourenplanung und Telematikanbindung.

Ergänzen Sie die technischen Größen um wenige fachliche. Wie viele Aufträge wurden in der letzten Stunde angelegt, wie viele Rechnungen versandt, wie viele Anmeldungen sind gescheitert? Solche Zahlen erkennen Störungen, die technisch unauffällig aussehen: Wenn ein Formular seit dem Vormittag niemanden mehr durchlässt, meldet kein Server einen Fehler, aber die Auftragskurve fällt auf null.

Warum reicht es nicht, das System von innen zu beobachten?

Ein Server kann sich selbst für gesund halten, während von außen niemand zu ihm durchkommt. Abgelaufene Zertifikate, fehlerhafte Namensauflösung, ein defekter vorgeschalteter Verteiler oder eine Störung beim Rechenzentrumsbetreiber sind von innen unsichtbar.

Eine externe Prüfung ruft deshalb in kurzen Abständen von mehreren Standorten aus eine echte Adresse Ihrer Anwendung auf und protokolliert Antwortzeit und Statuscode. Prüfen Sie nicht die Startseite, sondern einen Pfad, der wirklich arbeitet: eine kleine Prüfseite, die Datenbankverbindung und wichtigste Abhängigkeiten anfasst und mit HTTP 200 oder 503 antwortet.

Legen Sie zugleich fest, was die Prüfseite überhaupt melden soll. Eine Seite, die bei jeder kleinen Störung einer Nebenfunktion auf rot springt, erzeugt Fehlalarme; eine, die nur bestätigt, dass der Webserver antwortet, übersieht die Hälfte. Sinnvoll sind zwei Stufen: eine harte Prüfung der unverzichtbaren Abhängigkeiten und eine weiche, die Einschränkungen sichtbar macht, ohne jemanden zu wecken.

Zwei Kennzahlen tragen dann den Alltag: die Fehlerrate, also der Anteil fehlgeschlagener an allen Anfragen, und die Antwortzeit. Bei der Antwortzeit ist der Durchschnitt wertlos — er versteckt genau die langsamen Fälle, über die sich Nutzer beschweren. Sehen Sie stattdessen auf das 95. und 99. Perzentil: die Zeit, unter der 95 beziehungsweise 99 von hundert Anfragen bleiben.

Wie alarmieren Sie, ohne dass Ihr Team abstumpft?

Alarmmüdigkeit entsteht, wenn Meldungen häufiger falsch als richtig sind. Nach zwei Wochen nächtlicher Fehlalarme reagiert niemand mehr zügig, und der eine echte Vorfall geht unter. Der Schutz dagegen heißt Sparsamkeit, nicht bessere Formulierung.

• Alarmieren Sie auf Symptome, die Nutzer spüren, nicht auf jede technische Kennzahl.
• Trennen Sie zwei Stufen: was jemanden nachts weckt, und was am nächsten Werktag reicht.
• Verlangen Sie zu jedem weckenden Alarm eine hinterlegte Handlungsanweisung — gibt es keine, ist es kein Alarm.
• Setzen Sie Schwellenwerte mit Dauer: „Fehlerrate über fünf Prozent für mindestens fünf Minuten“ statt eines einzelnen Ausreißers.
• Prüfen Sie monatlich, welche Alarme ausgelöst und welche davon zu einer Handlung geführt haben; der Rest wird entschärft oder gelöscht.

Bereitschaft braucht eine Vereinbarung, keine stille Erwartung. Wer ist wann erreichbar, über welchen Kanal, mit welcher Reaktionszeit, und was geschieht, wenn niemand abhebt? Für ein kleines Team genügt oft eine Regelung für Werktage plus eine bewusst benannte Lücke am Wochenende — Hauptsache, sie ist ausgesprochen.

Das Fehlerbudget als Gesprächsgrundlage

Wenn Sie sich auf ein Verfügbarkeitsziel einigen, etwa 99,5 Prozent im Monat, ergibt sich daraus eine erlaubte Ausfallzeit von rund dreieinhalb Stunden. Diese Spanne ist das Fehlerbudget. Sie ist kein Versagen, sondern eingeplant.

Wählen Sie das Ziel bewusst niedrig genug. Jede weitere Neun kostet überproportional: Von 99,5 auf 99,9 Prozent zu kommen bedeutet, die erlaubte Ausfallzeit von dreieinhalb Stunden auf gut vierzig Minuten im Monat zu drücken — mit doppelt ausgelegter Technik, geregelter Bereitschaft rund um die Uhr und geprobten Abläufen. Für die meisten mittelständischen Anwendungen ist das weder nötig noch bezahlbar.

Der Nutzen liegt im Gespräch zwischen Fachbereich und Technik. Ist das Budget im laufenden Monat aufgebraucht, gehen Stabilitätsarbeiten neuen Funktionen vor. Ist es weitgehend unangetastet, dürfen Änderungen zügiger fließen. Aus einer Stimmungsfrage wird eine Zahl, über die sich sachlich streiten lässt.

Ein Alarm, auf den niemand etwas tun kann, ist keine Information, sondern Lärm.

Was ist bei Protokolldaten mit Personenbezug zu beachten?

Protokolle enthalten schneller Personenbezug, als man denkt: IP-Adressen, Nutzerkennungen, E-Mail-Adressen in Fehlermeldungen, vollständige Anfrageinhalte bei Formularfehlern. Bei einem Personaldienstleister landen so mühelos Bewerberangaben in einer Zeile, die anschließend jahrelang aufbewahrt wird.

• Legen Sie fest, welche Felder überhaupt protokolliert werden, und filtern Sie den Rest bereits an der Quelle.
• Ersetzen Sie Kennungen durch Pseudonyme, wo der echte Wert für die Fehlersuche nicht gebraucht wird.
• Vergeben Sie Leserechte auf Protokolle gezielt, nicht pauschal an alle Entwickler.
• Halten Sie Aufbewahrungsfristen je Protokollart fest und lassen Sie sie automatisch ablaufen.

Die Aufbewahrung bestimmt zugleich maßgeblich die Kosten der Überwachung. Protokolldaten wachsen linear mit dem Verkehr, und viele Dienste rechnen nach Volumen ab. Üblich und meist ausreichend sind 14 bis 30 Tage für ausführliche Protokolle, während verdichtete Metriken zwölf Monate und länger vorgehalten werden — sie brauchen einen Bruchteil des Platzes und beantworten Fragen nach Trends besser als Rohtext.

Wie besprechen Sie Störungen, ohne Schuldige zu suchen?

Nach einem Vorfall lohnt eine kurze schriftliche Nachbesprechung — bei kleinen Teams eine Seite, verfasst innerhalb weniger Tage, solange die Erinnerungen frisch sind. Ihr Zweck ist, die Bedingungen zu ändern, unter denen der Fehler möglich war, nicht die Person zu markieren, die ihn ausgelöst hat.

• Zeitleiste: Was geschah wann, wann fiel es auf, wann war es behoben?
• Auswirkung: Wer war betroffen, wie lange und in welchem Umfang?
• Beitragende Umstände statt einer einzigen Ursache — meist wirken drei bis vier Dinge zusammen.
• Maßnahmen mit Verantwortlichen und Termin, höchstens drei, sonst passiert keine davon.

Nützlich ist eine feste Schwelle, ab der überhaupt nachbesprochen wird — etwa jede Störung, die Nutzer länger als fünfzehn Minuten betroffen hat. Ohne Schwelle geschieht eines von beidem: Es wird gar nichts aufgeschrieben, oder jede Kleinigkeit erzeugt Papier, das niemand liest. Sammeln Sie die Berichte an einem Ort und lesen Sie sie einmal im Quartal gemeinsam durch; die wiederkehrenden Muster sieht man erst im Rückblick.

Ein Satz gehört in jede solche Runde: Die beteiligte Person hat mit dem Wissen, das ihr zu diesem Zeitpunkt zur Verfügung stand, vernünftig gehandelt. Wenn das nicht zutrifft, fehlten Informationen oder Sicherungen — und genau die sind dann die Maßnahme.

Was ist die Mindestausstattung für ein kleines Team?

Sie brauchen keine Werkzeuglandschaft. Für eine mittelständische Webanwendung mit einer Handvoll Diensten genügt das Folgende, und es lässt sich an ein bis zwei Tagen einrichten:

• Externe Verfügbarkeitsprüfung im Minutentakt auf eine echte Prüfseite, mit Benachrichtigung an mindestens zwei Personen.
• Zentrale Sammlung der Protokolle aller Dienste an einem Ort, durchsuchbar, mit begrenzter Aufbewahrung.
• Vier Kennzahlen sichtbar auf einer Seite: Anfragen, Fehlerrate, Antwortzeit im 95. Perzentil, Auslastung der Datenbank.
• Höchstens fünf weckende Alarme, jeder mit hinterlegter Handlungsanweisung.
• Eine ausgesprochene Bereitschaftsregelung, auch wenn sie nur Werktage abdeckt.

Der Aufbau lohnt sich in dieser Reihenfolge. Die externe Prüfung bringt sofort Nutzen und ist in einer Stunde eingerichtet. Die zentrale Protokollsammlung zahlt sich beim ersten unklaren Vorfall aus. Die Kennzahlenseite braucht am längsten, weil sie fachliche Abstimmung erfordert — und ist gerade deshalb der Punkt, an dem viele Teams stehen bleiben.

Was Sie damit erreichen, ist bescheiden und wertvoll zugleich: Sie erfahren von Störungen, bevor der erste Kunde anruft, und können nach einem Vorfall belegen, was passiert ist. Alles Weitere — verteilte Traces, Nutzerverhalten in Echtzeit, automatische Erkennung von Auffälligkeiten — hat seinen Sinn, aber erst danach.