Observability Plattform uMon: Produktvorstellung

Observability: Mehr als ein neuer Trend für unabhängige Cloud-Plattformen

In modernen Cloud- und Plattformumgebungen ist Observability längst kein „Nice-to-have“ mehr, für das noch Zeit ist, wenn die ersten Nutzer ihre Workload in Betrieb nehmen. Gerade im Kontext digitaler Unabhängigkeit wird das Monitoring zu einer tragenden Säule: Wer seine Infrastruktur nachhaltig unabhängig betreiben will, muss ein tiefes Verständnis ihres technischen Verhaltens und der des Charakters ihrer Nutzer haben um sich anbahnende Probleme früh zu erkennen, akute Problemsituationen schnell zu bewältigen und um fundierte wirtschaftliche Entscheidungen im Kapazitätsmanagement zu fällen

Die folgenden Überlegungen basieren auf den Prinzipien, die wir bei UhuruTec in der Entwicklung unserer Observability-Plattform uMon anwenden. 

Warum Observability heute unverzichtbar ist?

Observability adressiert ein fundamentales Problem verteilter Systeme.

Moderne Cloud-Plattformen bestehen aus:

• vielen voneinander abhängigen Komponenten
• dynamischen Workloads (z. B. Kubernetes)
• nicht-deterministischen Fehlerbildern

Klassisches Monitoring reicht hier nicht mehr aus. Es beantwortet in der Regel die Frage: „Ist etwas kaputt?“
Observability hingegen beantwortet: „Warum ist etwas kaputt und was passiert gerade wirklich im System?“

Was unterscheidet Open Source Observability Plattformen von anderen proprietären Lösungen?

Observability-Plattformen ergänzen deshalb Open Source Plattformen ideal, indem sie Transparenz über die Implementierung, Infrastruktur und Betriebsprozesse schaffen und so einen zuverlässigen, effizienten und souveränen Cloud-Betrieb unterstützen.

• Vermeidung von Blackbox-Abhängigkeiten
• Lizenzkostenfrei, da Hersteller unabhängig 
• Handlungsfähigkeit im Krisenfall liegt beim Betreiber nicht beim Hersteller
• Echte Daten-Souveränität durch vollständige Kontrolle über Telemetriedaten
• Anbieterunabhängigkeit bedeutet Wahlfreiheit des Anbieters und der Art der Unterstützung bei der Erweiterung, Implementierung und Support 
• Produktentwicklung steuerbar durch eigene Mitwirkungsmöglichkeiten
• Integrierte Gesamtlösung durch kombinierte, bewährte Open Source Komponenten

Welche Grundprinzipien einer belastbaren Observability-Plattform müssen beachtet werden?

Ein funktionierendes Observability-Setup besteht nicht nur aus einem spezifischen Technologie-Stack, sondern stellt ein System dar, dass sich aus Prinzipien, Konzepten, Technologien und Integrationen zusammensetzt. Erst das Zusammenspiel aller Komponenten und die Adaption der charakterisierenden Eigenschaften macht es aussagekräftig, effektiv und zuverlässig. 

Zentrale Anforderungen an moderne Observability-Plattformen sind:

1. Einsatzbereitschaft („ready-to-use“)
Ein Observability-Setup muss sofort nutzbar sein, nicht erst nach Wochen manueller Integration.

2. Modularität
Nicht jede Umgebung braucht alles. Observability muss sich an Produkte und Nutzungsszenarien anpassen lassen.

3. Hochverfügbarkeit
Das System muss in kritischen Situationen immer verfügbar sein, da es da besonders gebraucht wird

4. Skalierfähigkeit
Das System muss in der Lage sein verschiedene Betriebsumgebungen mit tausenden von Nodes, Millionen von Messpunkten und Milliarden von Datensätzen in einer konsolidierten Observability-Umgebung zu überwachen

5. Compliance und Sicherheit
Das System muss den gängigen Sicherheits- und Zertififizierungs-Anforderungen genügen
(SSO Anmeldung, Zugriffskontrolle, Verschlüsselung, Auditing, …)

6. Anpassbarkeit
Offene Software und Schnittstellen ermöglichen die Einbindung bestehender Systeme und Anwendungen (wie z.B. Ticketsysteme, OnCall Shift Management). Das System kann für spezifische Anforderungen erweitert werden.

7. Integrationsfähigkeit
Offene Schnittstellen ermöglichen die Einbindung bestehender, leistungsfähiger Open Source Observability Technologiestacks, um die Stärken der jeweiligen Systeme nutzen un kombinieren zu können

8. Unabhängigkeit
Observability-Systeme dürfen nicht Teil der zu überwachenden Umgebung sein, sonst verlieren sie im Ernstfall ihre Aussagekraft.

Der eigentliche Kern: Sinnvolle Observability-Mechanismen

Ein häufiger Fehler ist „Monitoring um des Monitorings willen“. Effektive Observability beginnt mit klaren Fragestellungen:

• Welche Funktionen sind für Nutzer kritisch?
• Welche Fehlerbilder treten realistisch auf?
• Welche Abhängigkeiten existieren?
• Wie müssen Fehlerbilder adressiert werden?
• Was benötige ich um meinen Plattformbetrieb zu planen?
• Was benötige ich um meine Produkte und Leistungen zu bewerten?

Daraus ergeben sich folgende konkrete Anforderungen:

• Systemverhalten aus Nutzersicht verstehe
• Die technische Architektur der überwachten technischen Komponenten verstehen
• Konkrete Fehlerszenarien kennen, modellieren und bewerten
• Zusicherung zur Servicegüte definieren, kennen und einbeziehen (SLAs, SLOs und SLIs)
• Abhängigkeiten kennen und analysieren
• Incident Response bzw Mitigationsstrategien vorbereiten

Observability ist ein kontinuierlicher Bestandteil des Betriebs und muss sich gemeinsam mit der Systemarchitektur weiterentwickeln; jede relevante Systemänderung erfordert daher auch Anpassungen an der Observability. Sie dient dem Betriebsteam als zentrales Werkzeug zur Bewertung der Auswirkungen von Änderungen und ist eine wesentliche Herausforderung um aufziehende Probleme effektiv zu adressieren, weshalb das gesamte Team über fundierte Kenntnisse in diesem Bereich verfügen sollte.

Metriken, Logs und Traces: Warum sind alle drei Aspekte wichtig?

Observability basiert typischerweise auf drei Säulen. Erst ihr Zusammenspiel ermöglicht echte Analysefähigkeit:

1. Metrics

• sind Zeitreihen basierte Messwerte (z. B. CPU, Latenz, Requests/s)
• sind ideal für Alerting und Kapazitätsplanung
• können aggregiert effizient genutzt werden um einen Überblick zu erhalten

Typen von Metrics:

• Counter (z. B. Requests gesamt)
• Gauge (z. B. aktuelle CPU-Auslastung)
• Histogramme (z. B. Latenzverteilungen)
• Statusmeldungen

2. Logs

• sind ereignisbasierte, textuelle und strukturierte Daten
• geben detaillierte Einblicke in einzelne konkrete Vorgänge
• sind wichtig für Debugging, Auditing und Detailanalyse

Varianten:

• Application Logs
• System Logs
• Audit Logs
• Kubernetes Events

3. Traces

• verfolgen Aktivitäten über mehrere technische Komponenten hinweg
• liefern detaillierte Informationen zum implementierungs- und architekturspezifischen Verhalten der betriebenen Anwendungen
• liefern einen repräsentativen Ausschnitt des Systemverhaltens; werden in regelmäßigen automatisierten Stichprobentests erfasst
• machen Abhängigkeiten und Latenzketten verstehbar
• sind essenziell in Microservice-Architekturen
•  

Typen:

• Distributed Traces
• Spans (Teilabschnitte eines Requests)
• Execution Context (ähnlich einem Debugger)

Warum ist das Zusammenspiel dieser drei Säulen entscheidend ist?

• Erst die Kombination dieser Daten ergeben eine belastbare Ursachenanalyse.

  • Metriken zeigen, dass ein Problem existiert bzw. wie sich das System aus globaler Sicht verhält.
  • Logs zeigen, was was im System auf der Ebene technischer Komponenten vorgeht.
  • Traces zeigen, wo, wie und warum sich ein spezifisches Verhalten darstellt.

  Ein entscheidender Aspekt ist hier die Konsolidierung bestehender Observability-Landschaften.
  Statt fragmentierter Tools entsteht eine integrierte Sicht auf das Gesamtsystem, die einen Überblick und Ursachenanalyse über die gesamte Cloud-Plattform ermöglicht. 

Die uMon Produkt Prinzipien

Mit uMon verfolgt UhuruTec den Ansatz, Observability-Mechanismen strukturiert und reproduzierbar bereitzustellen.
 

1. Ein standardisiertes Produkt

Bestehendes und bekanntes Betriebswissen ist Teil des Produkts:

• Setup und Betrieb der Observability Struktur
• Datenerfassung, Alarmierung und Integration für typische Komponenten wie z.B. OpenStack, Ceph, Kubernetes und Ceph
• Erfahrung aus der uMon Nutzung und dem Betrieb von Plattformen geht kontinuierlich in das Produkt ein
• Knappe Engineering Ressourcen können beim Betrieb und der Weiterentwicklung eingespart werden
• Die Lernkurve des Betriebsteams kann durch Schulung und Produktreife abgekürzt werden

2. Kollaboration und Unterstützung

OpenSource macht das Produkt durchschaubar, anpassbar und erlaubt eine Zusammenarbeit die bei nicht-offenen Produkten nicht realisierbar ist:

• Problemstellungen und Produktanforderungen können in Kollaboration mit UhuruTec eigenständig asl Beiträge adressiert werden
• Professionelles Feedback zu Contributions
• Schlagkräftige Unterstützung von On-Call-Szenarien bzw. SLA-Level durch standardisierte bzw bekannte Mechanismen
• Für Spezialisten die z.B. für sehr seltene Inselthemen hinzugezogen werden können ist die Implementierung bzw. sind die Mechanismen des Produkts einsehbar
• Eine Open Operation Community of Practice bietet 

3. Produkt-Managment und Produktpflege

In Eigenregie entwickelte Observability Plattformen basierend auf OpenSource benötigen einen dauerhaften personellen Ressourcenaufwand.
Das uMon Kernprojekt schafft hier Erleichterung:

• Problemstellungen und Produktanforderungen können an UhuruTec ausgelagert werden
• UhuruTec kümmert sich um die längerfristige Produktstrategie, Standarisierung und den Produktlebenszyklus 
• uMon wird durch UhuruTec gewartet bzw. sorgt dafür dass das Produkt wartbar bleibt
• Neue Umsetzungen, Funktionen und Architekturentscheidungen basieren auf den unternehmens-übergreifenden Erfahrungen von UhuruTec  

4. Handlungs- und Entscheidungsfreiheit

• Telemetriedaten stehen Ihnen uneingeschränkt für Analysen, Automatisierung und Innovationen zur Verfügung
• Freie Entscheidungen im Krisenfall: Sie bleiben handlungsfähig und können Systeme, Konfigurationen und Daten unabhängig kontrollieren und anpassen
• Neue Funktionen und Verbesserungen werden durch Ihre Anforderungen bestimmt, nicht im Wesentlichen durch die Produktstrategie von UhuruTec
• Eigene Ideen, Erweiterungen und Automatisierungen können direkt umgesetzt und in die Plattform integriert werden
• Umfang und Tiefe der Observability richten sich nach Ihren Anforderungen und nicht nach Lizenzmodellen.
• Aktive Mitwirkung im Opensource Projekt ist ausdrücklich gewünscht und gewollt
• Die Plattform kann an individuelle Anforderungen angepasst und ohne Herstellergrenzen erweitert werden.

OpenSource Observability als grundlegendes Prinzip

Open-Source-basierte Cloud-Umgebungen profitieren stark von einer auf Open Source basierender Observability.
Eine sehr fortgeschrittene Observability, wie sie durch uMon dargestellt wird, nutzt im Moment nur eine überschaubare Menge von Unternehmen, sie ist aber eine unabdingbare Antwort auf die zunehmende Komplexität moderner IT Infrastrukturen. 

Für Operations-Teams bedeutet das konkret:

• schnellere Fehleranalyse
• fundierte Entscheidungen unter Zeitdruck
• bessere Kapazitätsplanung
• höheres Vertrauen in die eigene Plattform
• Handlungsfähigkeit durch Verstehbarkeit und Anpassbarkeit
• von anderen Betriebsteams bzw. aus anderen Betriebsszenarien lernen

Für Organisationen bedeutet es:

• mehr Kontrolle
• weniger Abhängigkeiten
• höhere Resilienz
• eine bessere Investitionssicherheit
• die Nutzungs- und Mitwirkungsmodell im Produkt kann passend zur strategischen Relevanz gewählt werden

uMon Verfügbarkeit und Feeback

uMon ist seit November 2025 offiziell verfügbar und kann eingesetzt werden. Weitere Informationen, technische Details sowie Download-Möglichkeiten finden sich auf der UhuruTec-Website oder direkt in GitLab: https://gitlab.com/uhurutec/umon/umon

Feedback aus realen Betriebsszenarien ist ausdrücklich erwünscht und fließt kontinuierlich in die Weiterentwicklung ein.