Das Dashboard ist grün, und dennoch beschweren sich Kunden darüber, dass der Checkout kaputt ist. Wenn Sie in dieser Position waren, verstehen Sie bereits den Unterschied zwischen Überwachung und Beobachtbarkeit. Ihre Überwachung hat nur das überprüft, was Sie überprüfen wollten, und dieser Fehler ist etwas Neues.

Dieser Leitfaden erklärt beide Ideen ohne die Marketingsprache und verfolgt einen fiktiven Vorfall von der Warnung bis zur Grundursache. Die Protokolle, Spuren und Zahlen werden erfunden, um den Prozess zu veranschaulichen. Sie sollten auch wissen, dass Anbieter und Praktiker diese Grenze unterschiedlich ziehen und einige sie teilweise als Marketingunterscheidung betrachten. Wir konzentrieren uns auf den praktischen Teil.

Die kurze Antwort

Überwachung ist eine Aktivität. Sie entscheiden im Voraus, was Sie beobachten möchten, z. B. CPU, Fehlerrate oder Speicherplatz, und legen Schwellenwerte fest, die Warnungen auslösen. Es antwortet: „Ist das passiert, worüber ich mir Sorgen gemacht habe?“

Beobachtbarkeit ist eine Eigenschaft Ihres Systems. Der Begriff stammt aus der Kontrolltheorie und beschreibt dort, wie gut man aus seinen externen Ausgängen auf den internen Zustand eines Systems schließen kann. In der Praxis lautet die Antwort: „Was passiert und warum, auch bei Problemen, mit denen ich nie gerechnet habe?“

Denken Sie an ein Auto. Die Warnleuchten auf dem Armaturenbrett überwachen. Sie decken eine Reihe bekannter Probleme ab. Der vollständige Diagnoseanschluss eines Mechanikers, der es jemandem ermöglicht, neue Fragen zu jedem Teil des Motors zu stellen, ist eher beobachtbar.

Überwachung und Beobachtbarkeit nebeneinander

Dies ist keine Wahl zwischen den beiden. Sie benötigen weiterhin Benachrichtigungen, die Ihnen sagen, wann Sie nachsehen müssen.

Warum Überwachung allein nicht ausreicht

Bei einer Anwendung auf einem Server ist die Liste der Dinge, die schief gehen können, ziemlich kurz, sodass Sie sie alle im Auge behalten können. Ein modernes System verfügt möglicherweise über Dutzende von Diensten, Warteschlangen und APIs von Drittanbietern sowie über Container, die kommen und gehen. Fehler werden zu Kombinationen, die niemand vorhergesehen hat: eine Region, ein Kundentyp, eine bestimmte App-Version und eine einzige langsame Abhängigkeit.

Sie können nicht im Voraus ein Dashboard für eine Frage schreiben, an die Sie noch nicht gedacht haben. Sie benötigen Daten, die es Ihnen ermöglichen, sie im Nachhinein abzufragen.

Protokolle, Metriken und Traces

Diese drei Arten der Telemetrie werden oft als die Säulen der Beobachtbarkeit bezeichnet. Jeder beantwortet eine andere Frage:

Metriken

http_requests_total{service="checkout", status="500"} 1832
http_request_duration_seconds{service="checkout", quantile="0.95"} 2.4

Metriken sind kostengünstig zu speichern und schnell abzufragen, was sie ideal für Dashboards und Warnungen macht. Seien Sie vorsichtig bei Etiketten mit hoher Kardinalität, wie z. B. einer Benutzer-ID, in vielen metrischen Systemen, da diese die Kosten erheblich erhöhen können.

Spuren

Ein Trace folgt einer Anfrage dienstübergreifend. Jeder Schritt ist eine Spanne mit einer Startzeit und einer Dauer:

POST /checkout                      2410 ms
├─ auth-service: verify token         18 ms
├─ cart-service: load cart            42 ms
├─ pricing-service: calculate       2290 ms   <-- slow
│  └─ SELECT coupons ...            2265 ms
└─ payment-service: not reached

Ein Trace macht einen langsamen Schritt offensichtlich, der in separaten Protokollen verschiedener Dienste nur sehr schwer zu erkennen ist.

Protokolle

Protokolle liefern detaillierte Informationen darüber, was zu einem bestimmten Zeitpunkt passiert ist. Wir schauen uns gleich an, wie wir sie nützlich machen können.

Eine exemplarische Vorgehensweise für den Vorfall

Hier sehen Sie in einem fiktiven Beispiel, wie die Teile zusammenpassen.

Die Überwachung behandelte Schritt 1. Alles danach war Beobachtbarkeit. Beachten Sie, wie jede Frage aus der vorherigen Antwort hervorgegangen ist. Niemand hätte im Voraus ein Dashboard für die „Abfrage von Gutscheinen für mobile Apps aus der heutigen Kampagne“ erstellen können. Für den Fix selbst zeigt unser Leitfaden zur SQL-Abfrageoptimierung, wie man einen solchen Plan liest.

Bessere Protokolle

Nur-Text-Protokolle sind für das menschliche Auge gemacht und schwer abzufragen. Strukturierte Protokolle verwenden Felder, nach denen eine Maschine filtern kann:

# Hard to search
ERROR Payment failed for user 42 after 3 tries

# Easy to search
{"level":"error","event":"payment_failed","user_id":"42",
 "attempts":3,"provider":"acme","trace_id":"a1b2c3","duration_ms":2410}

Mit dem zweiten Formular können Sie sofort fragen: „Wie viele Ausfälle pro Anbieter in der letzten Stunde?“ Das Feld trace_id ist besonders wertvoll, da es eine Protokollzeile mit der gesamten Anfrage verknüpft, und zwar über jeden Dienst hinweg, den sie berührt.

Protokollieren Sie niemals Passwörter, Token oder Kartennummern und gehen Sie vorsichtig mit persönlichen Daten um. Wie unser Leitfaden erklärt, können JWTs von jedem wiederverwendet werden, der sie aus einem Protokoll liest.

Die goldenen Signale

Sie sind sich nicht sicher, was Sie überwachen sollen? Das Site Reliability Engineering-Buch von Google schlägt vier Signale für benutzerorientierte Systeme vor:

Verwenden Sie Perzentile für die Latenz, da Durchschnittswerte langsame Anfragen verbergen, wie wir in Lasttests im Vergleich zu Stresstests gezeigt haben.

Warnt Menschen, denen Menschen vertrauen

Wenn ständig Warnungen ausgelöst werden, hören die Leute auf, sie zu lesen. Gute befolgen einige Regeln:

• Warnung zu Symptomen, die Benutzer spüren. „Checkout-Fehler über 2 %“ schlägt „CPU bei 85 %“. Eine hohe CPU, die niemandem schadet, sollte niemanden aufwecken.
• Machen Sie jede Warnung umsetzbar. Wenn niemand etwas tun muss, machen Sie sie zu einem Dashboard-Element oder entfernen Sie sie.
• Link zu einem Runbook. Sagen Sie dem Antwortenden, wo er suchen und was er ausprobieren soll.
• Überprüfen Sie sie regelmäßig. Löschen oder korrigieren Sie alle Warnungen, die letzten Monat ignoriert wurden.

Service-Level-Ziele

Ein SLO verwandelt „die Website sollte schnell und zuverlässig sein“ in ein messbares Ziel, wie zum Beispiel „99,9 % der Checkout-Anfragen innerhalb von 30 Tagen erfolgreich“. Dies ermöglicht etwa 0,1 % der Ausfälle, was als Fehlerbudget bezeichnet wird. Wenn Sie noch viel übrig haben, können Sie schneller versenden, und wenn es fast aufgebraucht ist, können Sie der Zuverlässigkeit Priorität einräumen. Dies ist eine hilfreiche Möglichkeit, Streitigkeiten zwischen Liefergeschwindigkeit und Stabilität beizulegen.

OpenTelemetry und Tools

OpenTelemetry ist ein herstellerneutraler Open-Source-Standard zum Generieren und Exportieren von Telemetriedaten. Es handelt sich um ein Projekt der Cloud Native Computing Foundation. Durch die Instrumentierung können Sie Ihr Backend später ändern, ohne Ihren Code neu schreiben zu müssen. Da es sich selbst nicht um ein Speicher- oder Dashboard-Produkt handelt, koppeln Sie es mit einem:

Überprüfen Sie selbst die aktuellen Funktionen und Preise, da sich diese Produkte häufig ändern. Mit der Datenmenge können die Kosten schnell steigen. Nutzen Sie daher Stichproben und legen Sie Aufbewahrungsgrenzen fest.

So fangen Sie an

1. Beginnen Sie mit den goldenen Signalen für Ihren wichtigsten Dienst.
2. Fügen Sie eine oder zwei Warnungen hinzu zu Symptomen, die Benutzer bemerken.
3. Wechseln Sie zu strukturierten Protokollen mit einer Anforderungs-ID in jeder Zeile.
4. Fügen Sie Tracing zu Ihrer Hauptbenutzerreise mit OpenTelemetry hinzu, da die automatische Instrumentierung viele gängige Frameworks abdecken kann.
5. Verknüpfen Sie Bereitstellungen mit Ihren Diagrammen, damit Sie sehen können, ob eine Veröffentlichung aus Ihrer CI/CD-Pipeline eine Änderung verursacht hat.
6. Lernen Sie aus jedem Vorfall. Fragen Sie nach jedem Vorfall, welche Daten eine schnellere Lösung ermöglicht hätten, und fügen Sie diese hinzu.

Ein kleines Team mit einem Service benötigt keine riesige Plattform. Grundlegende Messwerte, gute Protokolle und ein paar Warnungen können ausreichend sein. Die Rückverfolgung verdient ihren Lebensunterhalt, da die Zahl der Dienste wächst.

Häufige Fehler

• Ein Tool kaufen und es Beobachtbarkeit nennen. Der Wert ergibt sich aus einer guten Instrumentierung und der Art und Weise, wie Sie die Daten nutzen.
• Drei Säulen als Checkliste behandeln. Wenn Sie Daten ohne Möglichkeit zur Verknüpfung trennen, müssen Sie sich durch Tabs wühlen. Geteilte IDs sind wichtig.
• Alles sammeln. Ungefilterte Telemetrie wird teuer und verursacht zusätzliches Rauschen.
• Zu viele Dashboards. Ein paar vertrauenswürdige Ansichten sind besser als hundert, die niemand öffnet.
• Ich denke, es ersetzt das Testen. Sie benötigen vor der Veröffentlichung noch Tests. Canary-Veröffentlichungen passen jedoch gut zu diesen Signalen.

Fazit

Die Überwachung sagt Ihnen, dass etwas schief gelaufen ist, und die Beobachtbarkeit gibt Ihnen die Möglichkeit, herauszufinden, warum. Der praktische Test ist einfach: Wenn ein unbekanntes Problem auftritt, können Sie die Ursache finden, ohne neuen Code zu versenden? Wenn Sie das nächste Mal in einen Vorfall verwickelt werden, schreiben Sie jede Frage auf, die Sie nicht beantworten konnten. Diese Liste ist Ihre Roadmap.

Häufige Fragen

Lerne weiter