Observability: Die Herausforderungen beim Monitoring beherrschen

Observability steht für einen systemübergreifenden Ansatz, der etliche Faktoren für die Überwachung und Beobachtung des Verhaltens von Software berücksichtigt.

In Pocket speichern vorlesen Druckansicht 5 Kommentare lesen
Observability: Die Herausforderungen beim Monitoring beherrschen

(Bild: Pixabay)

Lesezeit: 7 Min.
Von
  • Felix Rössel
Inhaltsverzeichnis

Kubernetes (K8s) und Docker sind zum De-facto-Standard geworden – viele Unternehmen setzen auf Container-Techniken, um ihre Applikationen effizienter zu entwickeln, zu testen und zu betreiben. Sie reagieren damit auf verändernde Marktbedingungen und können neue Standards zum Bereitstellen von Anwendungen und Services etablieren. Erhöhte Agilität, Schnelligkeit und Effizienz stellen die Unternehmen gleichzeitig vor neue Herausforderungen. Die neuen Techniken sind komplex, und diese Komplexität gilt es zu beherrschen.

Eine wesentliche Komponente eines jeden Betriebskonzepts für K8s ist eine Monitoring-Software, die einen ganzheitlichen Blick auf K8s-Deployments erlaubt. Dabei muss das jeweilige Produkt die Dynamik solcher Systeme berücksichtigen und DevOps- beziehungsweise Admin-Teams entlasten.

Observability ist kein Produkt irgendeines Anbieters, es ist vielmehr eine Qualitätsanforderung an eine IT-Anwendung – ähnlich wie Benutzerfreundlichkeit, hohe Verfügbarkeit oder Stabilität. Ziel ist es, Anwendungen und Systeme zu beobachten, Informationen über technische Fehlfunktionen (z.B. Ausfallzeiten, Fehler und langsame Antwortzeiten) zu erhalten und an die Verantwortlichen zu übermitteln. Detaillierte Logfiles, Informationen zur Ressourcennutzung und Anwendungs-Traces aus APM (Application Performance Monitoring) helfen den Administratoren und Entwicklern dabei, die Ursachen zu ermitteln, das Problem zu beheben und künftige Ausfälle nach Möglichkeit zu vermeiden.

Es ist allerdings gar nicht so trivial, diese scheinbar offensichtlichen Ziele zu erreichen. Oft sammeln Monitoring-Produkte nicht genügend oder zu viele Informationen. Manchmal haben die Verantwortlichen auch Probleme damit, die Informationen auszuwerten und die richtigen Erkenntnisse daraus zu gewinnen.

Das Erkennen unerwünschter Verhaltensweisen beginnt normalerweise mit dem Definieren von Service Level Indicators (SLI) und Service Level Objectives (SLO). Das sind die Erfolgsfaktoren für die Produktionssysteme in Unternehmen. Besteht eine vertragliche Verpflichtung, diese Ziele zu erreichen, kann ein SLI/SLO auch zu einem Service Level Agreement (SLA, Vereinbarung über die Diensterfüllung) werden. Beispielsweise kann man die Verfügbarkeit von Systemen (SLI) mit 99,9999 Prozent (SLO) festsetzen – eine häufige Vereinbarung mit externen Kunden. Die internen SLI/SLO-Vereinbarungen sind möglicherweise noch differenzierter. Doch das Überwachen von Produktionssystemen ist das Fundament von Observability.

Darüber hinaus gilt es, zuständige Personen schnell und effizient mit detaillierten Informationen zu versorgen. Nur so können sie die Störung beheben und künftige Probleme vermeiden. In dem Bereich tut sich derzeit einiges, und es gibt etliche innovative Lösungsansätze. Maßgeblich sind die sogenannten drei Säulen der Observability: Metriken, Logs und Anwendungs-Traces.

Als Erstes sei nun die Datenerfassung genauer betrachtet. Derzeit findet das Sammeln von Metriken häufig in einem dedizierten System statt, zum Beispiel mit Time-Series-Datenbanken oder einer Software as a Service für die Ressourcenüberwachung. Für die Logfiles ist oft ein weiteres System zuständig, und so ist es keine Seltenheit, dass Admins Metriken im Browserfenster von Hand mit Protokollen in einem anderen Fenster vergleichen. Ist noch ein drittes Tool zum Application Performance Monitoring im Einsatz, wird es wirklich vertrackt.

Die drei Säulen von Observability (Abb. 1)

(Bild: Elastic)

Der Einsatz von drei verschiedenen Werkzeugen ist nicht nur unübersichtlich, sondern verschwendet im Ernstfall auch wertvolle Zeit und erhöht die Betriebskosten – wie Mehrkosten für unterschiedliche Lizenzen und Hardware sowie zusätzliches Personal. Hinzu kommt bei einem derart verteilten Szenario, dass die Komplexität der Überwachung und Alarmierung je nach Programm (oder Tool) unterschiedlich gelöst sein kann.