Das Konzept von Observability und die Entwicklung der Werkzeuge

• Konzept von Observability:

  • Ein Maß dafür, wie gut sich aus den externen Ausgaben eines Systems dessen interner Zustand ableiten lässt
  • Ein dynamisches System, das so entworfen ist, dass sich aus der Messung der Ausgaben der Systemzustand schätzen lässt
  • Mit der Verbreitung von Cloud-Umgebungen sowie containerisierten Apps und Microservices-Architekturen wurde Observability notwendig

• Unterschiede zwischen Observability und Monitoring:

  • Monitoring: Etwas, das der Nutzer ausführt. Es zeigt, was falsch ist
  • Observability: Ein übergeordnetes Konzept, das Monitoring einschließt. Es liefert umfangreiche Hintergrundinformationen über interne Abläufe und hilft, tiefergehende Systemprobleme zu lösen. Es zeigt auch, warum etwas falsch ist

• Situationen, in denen Observability in einer Organisation nötig ist:

  • Wenn bei einem Vorfall in der Produktion die Frage aufkommt: „Welche Daten helfen dabei, die Ursache des Problems zu verstehen, wo befinden sie sich und wie sollte man sie betrachten?“
  • Wenn bei einem Dienst, der noch vor einer Minute problemlos lief, plötzlich ein Problem auftritt und man vor der Frage steht: „Wo sollte die Root Cause gesucht werden?“
  • Wenn sich eine Organisation fragt: „Wie kann das Entwicklungsteam Anzeichen von Service-Störungen früher erkennen als Kunden oder Support-/Betriebsteams?“
  • Wenn man wissen möchte, wie sich Service-Fehler und Performance-Probleme in Microservices effektiv nachverfolgen lassen oder ob sich dies über Logs oder Application Performance Monitoring (APM) überprüfen lässt

• Entwicklung von Observability-Werkzeugen:

  • Seit den 2010er-Jahren sind in der IT-Branche verschiedene Observability-Werkzeuge erschienen
  • 2010 stellte Google mit „Dapper“ eine Tracing-Infrastruktur für groß angelegte verteilte Systeme vor
  • Danach entwickelten Uber und Twitter die Distributed-Tracing-Systeme „Jaeger“ (Uber) und „Zipkin“ (Twitter)
  • Danach erschien „Open Tracing“, ein standardisierter Satz von APIs, um das Verhalten verteilter Systeme fortlaufend zu modellieren und zu beschreiben
  • Veröffentlichung von „Open Census“: ein Satz von Bibliotheken für verschiedene Sprachen, der Anwendungsmetriken und Distributed Tracing sammelt und die Daten in Echtzeit an Backends sendet
  • Anschließend erschien „Prometheus“
  • 2019 wurde mit „Open Telemetry (OTel)“ eine Sammlung aus Werkzeugen, APIs und SDKs veröffentlicht, die Open Tracing und Open Census zusammenführt

• Open Telemetry:

  • Ein vendor-neutrales Open-Source-Observability-Framework
  • Zur Analyse von Software-Performance und -Verhalten gibt es Telemetriedaten wie Logs, Metriken und Traces; Open Telemetry wird verwendet, um diese zu instrumentieren, zu erzeugen, zu sammeln und zu exportieren
    • Logs: Zeitstempel-Metadaten. Sie werden verwendet, um die Root Cause eines Problems zu bestimmen
    • Metriken: Statistische oder aggregierte Daten mit Key/Value-Tags, die in einem Service gemessen werden. Messwerte eines Dienstes, die zur Laufzeit erfasst werden
    • Traces: Aufzeichnungen von Ereignissen, die bei Nutzern und Anwendungen auftreten. Sie dokumentieren den Pfad, auf dem sich einzelne Requests ausbreiten
  • Einsatzweise: Das Observability-Werkzeug sendet einen Alarm -> den Alarminhalt prüfen und im Dashboard die Problemstelle identifizieren -> an dieser Stelle gezielt Details abfragen -> die Logs suchen und prüfen -> die zugehörigen Trace-Daten finden und Muster erkennen -> das Problem identifizieren, beheben und so Observability umsetzen
  • Die meisten heute entwickelten Observability-Werkzeuge unterstützen Open Telemetry standardmäßig

• Warum Open Telemetry entstand:

  • Früher hatte jedes Observability-Backend eigene Instrumentierungsbibliotheken und Agents, um Daten aus Werkzeugen zu übertragen, und es gab verschiedene Arten, Code zu instrumentieren
  • Es gab kein standardisiertes Datenformat, um Daten an Observability-Backends zu senden
  • Um anschließend einen gemeinsamen Standard zu schaffen, wurden Open Tracing und Open Census zu Open Telemetry zusammengeführt

• SigNoz: ein Open-Source-APM-Werkzeug

  • Es hilft dabei, Anwendungen zu überwachen und Probleme zu beheben
  • Es verwendet Distributed Tracing, um den Software-Stack des Nutzers zu erfassen
    • Überwacht Anwendungsmetriken wie latency, requests per second und error rates
    • Beobachtet auch Infrastrukturmetriken wie CPU-Auslastung oder Speichernutzung
    • Verfolgt Nutzer-Requests serviceübergreifend
    • Ermöglicht das Einrichten von Alarmen für Metriken
    • Man kann direkt zu dem genauen Trace springen, der das Problem verursacht, und die Root Cause finden
    • Auch detaillierte Flame Graphs für einzelne Request-Traces lassen sich anzeigen

[ninebow]

Vielen Dank für den guten Artikel!

[ironlung]

Vielen Dank für Ihren Kommentar! :)

[kaistj]

Vielen Dank für den guten Artikel~

[ironlung]

Vielen Dank für den Kommentar! :)

[jujumilk3]

Wie überwacht man eigentlich, dass das Monitoring selbst gut funktioniert?

Ich hatte schon einmal ähnliche Gedanken wie in dem Comic Watchmen, aber offenbar gibt es dafür den Begriff Observability, danke.

[ironlung]

Danke! Mir fällt in letzter Zeit auch auf, dass es immer mehr Orte gibt, die Tools entwickeln, um Observability mit AI zu vereinfachen. Ein Bereich, über den ich gerne mehr erfahren würde! :)

[inthelife]

Vielen Dank für den guten Artikel :)

[ironlung]

Vielen Dank! :D