Observability
Zwei Ausgangslagen führen auf diese Seite. In der einen gibt es nichts zu sehen: Ein Ausfall wird vom Kunden gemeldet, nicht vom System. In der anderen gibt es zu viel – Dashboards, die niemand öffnet, Alarme, die niemand mehr liest, und eine Rechnung fürs Beobachten, die keiner erklären kann. Beide haben denselben Ursprung: Es wurde gemessen, bevor entschieden war, welche Frage beantwortet werden muss.
Aufnahme und Zielbild als abgegrenztes Zwei- bis Vier-Wochen-Mandat, Umsetzung danach nach Umfang. Der Betrieb bleibt bei Ihrem Team, dafür ist die Übergabe Teil der Arbeit.
Remote aus Deutschland. Direkt mit mir, ohne Agentur dazwischen.
Die Ausgangslage
Logs, Metriken und Traces sind Mittel, keine Ziele. Bevor eines davon eingerichtet wird, gehören vier Fragen beantwortet: Ist es kaputt? Für wen? Seit wann? Und woran liegt es? Ein System, das diese vier in Minuten beantwortet, braucht überraschend wenige Signale. Ein System, das sie nicht beantwortet, wird auch mit dem zweihundertsten Dashboard nicht besser – es wird nur teurer.
Der zweite Fehler ist eine Preisfrage, die wie eine Technikfrage aussieht: Kardinalität. Eine Metrik je Host ist billig. Dieselbe Metrik je Host, Container, Kunde und Endpunkt ist dasselbe Werkzeug und ein Vielfaches der Rechnung, weil jede Kombination eine eigene Zeitreihe ist. Dazu kommen Logvolumen und Aufbewahrung. Anbieter von Alternativen nennen Wachstumsraten von dreißig bis fünfzig Prozent im Jahr – die Zahl hat einen Absender, aber der Mechanismus ist echt und in jeder Rechnung nachrechenbar. In einem meiner AWS-Projekte war genau das ein Posten der Einsparung: ungenutzte, hochkardinale CloudWatch-Metriken entfernt und die Aufbewahrung an den tatsächlichen Bedarf angepasst.
Der dritte Fehler passiert nach der Einführung. Ein Alarm ohne Adressaten ist kein Alarm, sondern eine Benachrichtigung, und Benachrichtigungen lernt ein Team wegzuklicken. Nach vier Wochen mit falschen Alarmen ist die Bereitschaft eine Gewohnheit des Ignorierens, und der erste echte Vorfall geht in derselben Bewegung unter. Deshalb gehört zu jedem Alarm eine Schwelle, die aus einem SLO kommt, ein Mensch, der zuständig ist, und ein Runbook, das sagt, was zu tun ist.
Kommt Ihnen etwas davon bekannt vor?Was ich mache
Welche Geschäftswege dürfen nicht ausfallen: Bestellung, Zahlung, Anmeldung, Freigabe. Für die entstehen SLIs, die aus Kundensicht messen, und SLOs, die eine Zahl nennen statt eines Gefühls. Alles Weitere wird daran gemessen, ob es eine dieser Fragen beantwortet. Was keine beantwortet, wird nicht eingerichtet.
Die Instrumentierung läuft über OpenTelemetry, nicht über die Bibliothek eines Anbieters. Das ist keine Ideologie, sondern eine Preisverhandlungsposition: Wer seine Signale in einem herstellereigenen Format erzeugt, kann den Anbieter nicht wechseln, ohne die halbe Anwendung anzufassen. Mit OTel liegt die Grenze im Collector, und dahinter ist Datadog, Grafana oder CloudWatch eine Konfiguration.
Hier entsteht die Rechnung, deshalb wird sie hier entschieden und nicht nachträglich reklamiert. Je Signal: Welche Dimensionen braucht es wirklich, welche Auflösung, wie lange. Hohe Auflösung für wenige Tage, grobe Aggregate für lange Zeiträume, und Logs mit einer Stichprobe statt vollständig, wo Vollständigkeit nichts beantwortet.
Ein Alarm entsteht aus einem SLO, nicht aus einem Schwellwert, der plausibel aussah. Dazu je Alarm: wer ihn bekommt, was der erste Handgriff ist, wann eskaliert wird. Alarme ohne Runbook werden abgeschaltet – sie kosten Aufmerksamkeit, die beim nächsten echten Vorfall fehlt.
Ein Beobachtungssystem beweist sich im Vorfall, nicht im Dashboard. Deshalb wird der Vorfall geprobt: eine Abhängigkeit langsam machen, eine Instanz wegnehmen, eine Warteschlange volllaufen lassen – und nachsehen, ob die vier Fragen beantwortet werden und ob das System sich vorhersehbar verschlechtert statt umzufallen.
Zum Abschluss die Dinge, die das Ergebnis haltbar machen: Dashboards und Alarme als Code im Repository, ein Runbook je Alarm, eine Notiz, wer wann welches SLO überprüft, und eine Übergabesitzung mit Ihrem Team. Der Betrieb bleibt bei Ihnen. Das ist keine Sparmaßnahme, sondern das Ziel.
Wissen Sie gerade, ob es für Ihre Kunden funktioniert?
Schreiben Sie mir, was Sie heute sehen und was Sie im letzten Vorfall vermisst haben. Sie bekommen eine Einschätzung, bevor Sie etwas beauftragen.
Ablauf
Vier Schritte, und nach dem zweiten steht das Zielbild samt Kostenrahmen. Kein Schritt setzt voraus, dass Sie den nächsten beauftragen.
Was ist im Einsatz, was kostet es, was hat im letzten Vorfall gefehlt. Dazu die Geschäftswege, die nicht ausfallen dürfen. Zugänge braucht es dafür noch nicht, ein Gespräch und ein Blick auf die Rechnung genügen.
Welche Signale, welche SLOs, welche Alarme – und was das je Monat kostet, aufgeschlüsselt nach Kardinalität, Volumen und Aufbewahrung. Damit können Sie entscheiden, auch gegen mich.
Ein Geschäftsweg nach dem anderen: instrumentieren, SLO setzen, Alarm mit Runbook, dann der nächste. Jeder Schnitt ist einzeln nützlich und einzeln zurückdrehbar.
Ein geübter Vorfall, an dem sich zeigt, ob die vier Fragen beantwortet werden. Danach die Übergabe: Konfiguration im Repository, Runbooks, Zuständigkeiten.
Das Ergebnis
Nicht der Kunde, nicht Twitter, nicht der Vertrieb. Das ist der ganze Unterschied zwischen einem Vorfall und einem Vorfall mit Publikum.
Wenn jeder Alarm einen Adressaten und einen Handgriff hat, sinkt die Zahl und die Bereitschaft nimmt sie wieder ernst.
Kardinalität, Volumen und Aufbewahrung sind entschieden statt gewachsen. Damit ist die nächste Preiserhöhung des Anbieters eine Rechenaufgabe und keine Überraschung.
Mit OpenTelemetry als Grenze ist ein Wechsel eine Konfiguration statt eines Projekts. Das wirkt auch dann, wenn Sie nie wechseln.
Eingesetzte Technologien
Aus der Praxis
Gewachsener Code ohne Tests, ohne dokumentierte Infrastruktur, mit regelmäßigen Incidents. Testnetz, Migration und Sichtbarkeit kamen zusammen; danach lagen die Incidents 90 Prozent niedriger. Sichtbarkeit war nicht die einzige Ursache, aber die Voraussetzung: Was niemand sieht, kann niemand abstellen.
Case Study lesenEbenfalls aus echten Projekten
Grafana, Prometheus, CloudWatch und Sentry so aufgesetzt, dass Probleme sichtbar werden, bevor sie zu Ausfällen werden. Bei Zahlungen ist das keine Bequemlichkeit: Jeder Ausfall ist unmittelbar Umsatz.
Case Study lesenUngenutzte, hochkardinale CloudWatch-Metriken entfernt, Athena-Daten partitioniert, Aufbewahrung an den tatsächlichen Bedarf angepasst. Ein Posten unter mehreren, die die AWS-Rechnung um 83 Prozent gesenkt haben.
Case Study lesen
Mit wem Sie es zu tun haben
Ich bin Tim Rutte. Über 20 Jahre Softwareentwicklung, und die meisten Ausfälle, die ich gesehen habe, waren vorher sichtbar – nur nicht für den, der sie sehen musste. Sie sprechen mit der Person, die Ihren Code anfasst, vom ersten Gespräch bis zur Übergabe.
Häufige Fragen
Vielleicht, und die Antwort gehört nicht an den Anfang. Datadog ist stark, wenn viele Signalarten an einer Stelle zusammenlaufen sollen und das Team keine Plattform betreiben will. Es ist teuer, wenn Kardinalität und Aufbewahrung nicht entschieden sind – dann zahlt man für Daten, die keine Frage beantworten. CloudWatch reicht öfter, als es Anbieter empfehlen, und ein Grafana-Stack ist die richtige Wahl, wenn Sie Betriebskompetenz haben und behalten wollen. Ich instrumentiere über OpenTelemetry, damit diese Entscheidung revidierbar bleibt.
Ja, und meistens ist es dieselbe Arbeit. Eine zu hohe Rechnung ist fast immer ein Kardinalitätsproblem oder ein Aufbewahrungsproblem, und beides wird gelöst, indem man festlegt, welche Frage jedes Signal beantwortet. Die Seite zu den AWS-Kosten ist die Nachbarseite dazu: Dort ist die Rechnung von AWS das Thema, hier die Rechnung für das Beobachten.
Nein, und das ist eine Festlegung, keine Kapazitätsfrage. Ich baue es auf, probe es mit Ihnen und übergebe es. Ein Beobachtungssystem, das von einem Externen betrieben wird, macht genau das Wissen extern, das im Vorfall intern gebraucht wird. Wenn Sie dauerhafte Bereitschaft brauchen, brauchen Sie ein Team oder einen Dienstleister mit Schichtbetrieb, und beides bin ich nicht.
Abgerechnet wird nach Aufwand, Aufnahme und Zielbild als abgegrenztes Zwei- bis Vier-Wochen-Mandat. Die Größenordnung nenne ich im Erstgespräch, sobald klar ist, wie viele Geschäftswege es gibt und was heute im Einsatz ist. Anders als bei den Upgrade-Seiten gibt es hier bewusst kein Festpreispaket: Die Ausgangslagen gehen zu weit auseinander, um sie in eine Lieferung zu pressen – zwischen „wir sehen nichts" und „wir sehen zu viel und zahlen dafür" liegt unterschiedliche Arbeit.
Nein. Vorhandene Dashboards sind eine Fundgrube: Sie zeigen, was jemand einmal für wichtig hielt, und daran sieht man die offenen Fragen. Was bleibt, bleibt. Abgeschaltet wird nur, was keine der vier Fragen beantwortet und trotzdem Geld oder Aufmerksamkeit kostet.
Weniger als Sie denken. Anfangen würde ich mit zwei bis vier: die Wege, an denen unmittelbar Geld hängt. Ein SLO je Dienst zu setzen erzeugt eine Tabelle, die niemand liest, und verwässert die Aussage – wenn alles ein Ziel hat, hat nichts Vorrang.
Ja, aber mit anderem Zuschnitt. Ohne Bereitschaft ist ein Alarm um drei Uhr nachts wertlos, also wird stattdessen dafür gesorgt, dass das System sich vorhersehbar verschlechtert statt umzufallen, und dass am Morgen in Minuten erkennbar ist, was in der Nacht passiert ist. Graceful Degradation und ein gutes Vorfall-Protokoll ersetzen keine Bereitschaft, holen aber den größeren Teil des Nutzens.
Dort besonders. Ein Sprachmodell fällt selten aus, es antwortet schlechter – und das ist mit klassischen Signalen unsichtbar. Dazu kommen Kosten je Anfrage als eigene Messgröße. Die Wege dafür sind dieselben: entscheiden, welche Frage beantwortet werden muss, dann instrumentieren. Die Kostenseite davon hat eine eigene Seite.
Weitere Leistungen
Backends für SaaS und Plattformen, die unter echter Last halten: in Go und PHP 8, event-getrieben, mit Mandantentrennung und Wiederanlauf im Entwurf.
Mehr erfahrenDamit ein einzelner Fehler nicht die ganze Anwendung mitnimmt: Abhängigkeiten und Single Points of Failure gefunden, Wiederanlauf geprobt statt dokumentiert, Änderungen als Terraform.
Mehr erfahrenVon einer Pipeline, die niemand anfassen will, zu Deployments am Dienstagvormittag: ein Artefakt durch alle Stufen, Zugänge ohne Langzeitschlüssel, geprobter Rückweg.
Mehr erfahren