Gorodenkoff/Shutterstock.comBeobachtbarkeit ist eine Eigenschaft von Softwaresystemen, die einen tiefen Einblick in ihre internen Abläufe bieten. Eine gute Beobachtbarkeit ermöglicht eine schnellere Lösung von Problemen, indem sie den Betriebsteams hilft, die Ursache von Problemen zu identifizieren.
Die einfachste Definition von “Beobachtbares” Software ist ein System, mit dem Sie den internen Zustand ableiten können, indem Sie die von ihr erzeugten Ausgaben beobachten. Wenn Ihr System diese Ausgaben nicht bereitstellen kann, ist es nicht vollständig beobachtbar.
Stellen Sie sich eine Softwareplattform vor, die langsamer als normal zu laufen scheint. Auf den ersten Blick haben Sie nicht genügend Informationen, um herauszufinden, was die Verlangsamung verursacht. Wenn das System jedoch Leistungskennzahlen für jede Phase seiner Ausführung ausgibt, könnten Sie die Komponente mit einem Problem sofort lokalisieren. Die Beobachtbarkeit des Systems wurde jetzt verbessert.
Ist die Beobachtbarkeit nicht dasselbe wie die Überwachung?
< p>Beobachtbarkeit ist nicht gleich Monitoring, obwohl die beiden Konzepte eng miteinander verbunden sind. Gute Überwachungspraktiken tragen zu einem beobachtbaren System bei. Sie bieten keine Garantie für die Beobachtbarkeit. Umgekehrt könnte ein System ohne einen vollwertigen Überwachungs-Stack einigermaßen beobachtbar sein.
Monitoring in DevOps-Begriffen bezieht sich normalerweise auf die Verwendung mehrerer vordefinierter Metriken, um festzustellen, wann ein System die Erwartungen erfüllt. Die abgedeckten Metriken sind normalerweise an die Ressourcenauslastung (CPU-Nutzung, Netzwerkdurchsatz) gebunden, können aber auch grundlegende Daten über den Betrieb Ihres Systems liefern (Anzahl der Anfragen, die einen Fehlercode von 500 verursachen).
Werbung< br>
Die Beobachtbarkeit geht etwas tiefer und erfordert eine nuanciertere Instrumentierung. Im Gegensatz zur Überwachung ist es an Ihr System und seine Eigenschaften und nicht an die Umgebung gekoppelt.
Ein überwachtes System teilt Ihnen mit, dass die Fehleranzahl von 500 erhöht ist und Benutzer Probleme haben. Ein beobachtetes System meldet, dass bei Ihrem Authentifizierungs-Microservice eine Zeitüberschreitung auftritt, sodass Benutzersitzungen nicht wiederhergestellt werden und Ihr Gateway als letzten Ausweg eine 500 ausgibt.
VERWANDT: Einführung für Anfänger in die DevOps-Prinzipien
Wie werden Systeme beobachtbar?
Lassen Sie uns die Unterschiede zwischen den beiden oben gezeigten Beispielen aufschlüsseln. Bei einem herkömmlichen Ansatz würden Sie die Bereitstellung auf Ihrem Server durchführen und die Überwachung einrichten, möglicherweise mithilfe der Metrikwarnungen Ihres Cloud-Anbieters. Wenn ein Problem erkannt wurde, können Sie die Serverprotokolle auf Probleme überprüfen.
Dieses Modell ist bereits zu einem gewissen Grad beobachtbar. Die moderne Verwendung von “Beobachtbarkeit” vermittelt aber etwas mehr. Serverfehlerprotokolle liefern normalerweise das endgültige Ergebnis, aber nicht die Zustände, die dazu geführt haben. Damit ein System wirklich beobachtbar ist, sollten Sie in der Lage sein, die Reihenfolge der internen Zustände zu bestimmen, die zu einer bestimmten Ausgabe geführt haben, ohne zu viel Zeit damit verbringen zu müssen, die Informationen manuell zu sammeln.
Es gibt drei primäre “Säulen” der Beobachtbarkeit, zu der eine gute Überwachung gehört. Die Beachtung aller drei Säulen sollte zu einem beobachtbaren System führen, das eine wirksame Hilfe bei der Diagnose von Problemen ist.
VERBUNDEN: Was ist Low-Code- und No-Code-Entwicklung? ?
Messwerte und Überwachung
Ein beobachtbares System sollte konstante Messwerte für vordefinierte Messwerte bereitstellen. Die besten Metriken sind diejenigen, die umsetzbare Informationen liefern, die für Ihre Anwendung und deren Leistung relevant sind, und nicht unbedingt allgemeine CPU- und Arbeitsspeicherdiagramme.
Protokollierung
Die zweite Säule der Beobachtbarkeit ist die Protokollierung. Dies beschreibt einen strukturierteren Ansatz für die Protokollierung als einen einfachen Schreibvorgang, wenn ein Fehler auftritt. Protokolle sollten hochgradig in Ihr System integriert sein, damit jedes Ereignis in einem zentralen Protokollierungsdienst aufgezeichnet wird. Logs selbst sollten standardisiert strukturiert sein, damit Log-Viewing-Tools sie automatisch indizieren und formatieren können.
Tracing
Die letzte Säule ist das Tracing. Traces erfassen alles, was während eines bestimmten Programmlaufs passiert. Damit erhalten Sie die Informationen, die Sie benötigen, um den genauen Ablauf der Ereignisse zu reproduzieren, die zu einem Problem geführt haben. Tracing ist besonders wichtig für verteilte Systeme, bei denen eine einzelne Anfrage ein Dutzend oder mehr Microservices treffen kann. Es ist unrealistisch, sich allein auf Dienstprotokolle zu verlassen, da Sie nicht sehen können, was mit der Anforderung passiert ist, nachdem sie mit jedem Dienst abgeschlossen wurde. Ein Trace auf Anfrageebene ist effektiver, um Probleme zu lokalisieren.
Sie können damit beginnen, ein System beobachtbarer zu machen, indem Sie sicherstellen, dass alle drei Säulen abgedeckt sind. Denken Sie daran, dass “Beobachtbarkeit” ist nicht eine bestimmte Sache – es ist eine Eigenschaft eines Systems, kein einzelnes Attribut. Möglicherweise ist Ihr System bereits “beobachtbar” durch grundlegende Metriken und Fehlerprotokolle, aber es kann immer noch eine geringe “Beobachtbarkeit” wenn Sie die Ursache von Fehlern nicht ohne weiteres ermitteln können.
VERWANDTE: Wie Event Sourcing Ihnen hilft, den Status Ihrer Anwendung zu verfolgen
Beendet Beobachtbarkeit Fehler?
Es ist erwähnenswert, dass Beobachtbarkeit nicht dazu gedacht ist, Bugs und Fehler zu beseitigen. Stattdessen ist es eigentlich eine Akzeptanz, dass Probleme auftreten können und werden. Anstatt davon auszugehen, dass Ihr System unfehlbar ist, ermutigt Sie die Beobachtbarkeit, für das Undenkbare zu planen. Hätten Sie im Falle eines Ausfalls die nötigen Tools, um die Ursache zu finden?
Um eine Analogie zum Autofahren zu verwenden, ist dies der Unterschied zwischen einer Motorkontrollleuchte und der Diagnosesoftware des Herstellers. So unerwünscht und unwahrscheinlich es auch sein mag, Störungen auf der Straße passieren. Die meisten Menschen ohne spezielle Ausrüstung sehen eine allgemeine Warnleuchte. Ein engagierter Autofahrer oder Techniker hat die Werkzeuge, um die Ursache dieses Lichts abzulesen.
Kehren wir nun zur Cloud zurück. Ein Bildschirm mit roten Messwerten hilft bei einem Ausfall nicht viel. Ähnlich wie ein Kfz-Mechaniker Diagnosen auslesen kann, muss Ihr System besser beobachtbar sein, damit Sie schnell feststellen können, was nicht stimmt, ohne auf die Schrauben und Muttern zu schauen. Es ist wichtig, für Katastrophen zu planen, damit Sie nicht erwischt werden.
Beobachtbarkeit ist kontinuierlich
Die Aufrechterhaltung einer guten Beobachtbarkeit erfordert eine kontinuierliche Wartung. Sie müssen Ihre Instrumentierung evaluieren, wenn Sie neue Dienste hinzufügen. Andernfalls können Sie unwissentlich Lücken in Ihren Protokollen und Traces erzeugen, in denen Anfragen verschwinden.
Werbung
Sie können Lücken in Ihrer Observability-Implementierung identifizieren, indem Sie das System hinterfragen und prüfen, ob Sie die benötigten Antworten erhalten. Sie sollten über die Informationen nachdenken, die Sie benötigen, um ein Problem zu beheben. Wären Sie während eines Ausfalls in der Lage, ohne längere manuelle Eingriffe darauf zuzugreifen?
Ein wirklich beobachtbares System sollte in der Lage sein, eine der drei Säulen zu verwenden, um die von den anderen beiden gestellten Fragen zu beantworten. Warum ist die Speichernutzung im Gefahrenbereich? Warum wurde in den Protokollen des Authentifizierungsdienstes ein Fehler aufgezeichnet? In beiden Fällen sollten die anderen beiden Säulen Ihre erste Anlaufstelle sein, um die Antwort zu finden.
Zusammenfassung
Beobachtbarkeit ist ein erfundenes Wort, das wirken manchmal vage und undurchsichtig. In der Praxis bezieht sich die moderne Verwendung des Begriffs auf etwas ziemlich Einfaches: die Einheit von Überwachung, Protokollierung und Rückverfolgung, um Ihnen zu helfen, den internen Zustand eines Systems aus seinen Ausgaben abzuleiten.
Eine gute Beobachtbarkeit ist für . von entscheidender Bedeutung verteilte Architekturen, bei denen die Funktionalität auf Microservices verteilt ist. Ein unbeobachtbares System wird zu einem schwarzen Loch, das Anfragen aufsaugt, aber nichts zurückgibt. Dies beeinträchtigt Ihre Reaktionsfähigkeit auf Probleme und kann dazu führen, dass Nutzer Probleme melden, bevor Sie sie bemerken.
Umgekehrt hilft Ihnen ein beobachtbares System, Fehlerberichten immer einen Schritt voraus zu sein. Die Zeit bis zur Lösung wird minimiert, da das System bereits mit den gewünschten Informationen wartet.