Kubernetes-Observability im Zeitalter steigender Service-Kosten Wie eBPF dabei hilft, die Observability-Ausgaben zu begrenzen

Anbieter zum Thema

Rosenberger-OSI GmbH & Co. OHG

Kentix GmbH

PQ Plus GmbH

In Zeiten von verteilten Anwendungen und Microservice-Architekturen ist Observability, das heißt Überwachbarkeit von außen, nahezu unabdingbar. Mit eBPF steht sogar schon ein etabliertes Tool zur Verfügung, um die Datensammlung von Vornherein zu steuern.

„Application Performance Monitoring“- oder kurz APM-Plattformen waren schon immer ein wichtiger Bestandteil der Developer-Toolbox. Immerhin ermöglichen sie die Erfassung und Überwachung verschiedener wichtiger Software-Metriken wie Ressourcen-Auslastung, Latenz und Antwortzeit.

Diese Fähigkeit ist von unschätzbarem Wert bei der Diagnose von Problemen wie schwacher Performance oder Bugs, die die Benutzererfahrung (User Experience, UX) beeinträchtigen können und ansonsten sehr schwer zu erkennen wären. Durch den Einsatz von APM-Plattformen können Entwicklerinnen und Entwickler die Ausfallzeiten ihrer Anwendungen reduzieren und deren Stabilität verbessern.

Der Markt für Observability, der auf über 50 Milliarden US-Dollar (USD) geschätzt wird, zählt zu den größten und am schnellsten wachsenden Segmenten in der Infrastruktur-Software. Obwohl APM-Plattformen seit fast einem Jahrzehnt existieren, ist die Integration in moderne, Cloud-native und voluminöse Umgebungen immer herausfordernder geworden.

Das Skalieren APM-Lösungen in echten Produktionsumgebungen verursacht erhebliche Kosten und ist mit großen Hürden bei der Implementierung verbunden. Bestehende Lösungen bieten häufig entweder ein umfassendes Ablaufverfolgungssystem – oder eben gar keines, was zu hohen Wartungskosten führt. Dies zeigt sich besonders vor dem Hintergrund umfangreicher Datenmengen und komplexer Technologie-Stacks, wobei gut sieben von zehn Teams über keine robuste APM-Ebene verfügen.

Höhere Transparenz zu intransparenten Kosten

Für seine Kubernetes-Umgebung hatte ein enger Arbeitskollege von mir kürzlich die Funktionen einer bekannten Observability-Plattform untersucht. Eine ganze Woche investierte er Zeit darin, die Plattform kennenzulernen – hauptsächlich, um verschiedenen Funktionen für Abläufe, Logs und die Infrastruktur-Überwachung zu testen. Allerdings war er nicht mehr ganz bei der Sache, als eine kritische Funktion eine frühe Freigabe erforderte. Er vergaß das Observability-Werkzeug.

Leider erhielt gab es keine Benachrichtigung oder Warnung darüber, dass die Log-Sammlung der Plattform ohne Volumenbegrenzung erfolgt. Eine Zeile in der YAML-Konfigurationsdatei legte fest, dass alle Logs gesammelt, aufgenommen und gespeichert wurden – ohne Erwähnung der voraussichtlichen Kosten.

Eine Woche später stürmte ein Kollege aus der Rechnungsabteilung in sein Büro und forderte eine Erklärung für eine Observability-Rechnung in Höhe von 33.000 US-Dollar für einen einzigen Monat – ein deutlicher Unterschied zu den erwarteten 1.700 US-Dollar. Mein „Arbeitskumpel“ rang mit der Größe und den Auswirkungen seines Fehlers – während ich mich fragte, ob wirklich alles allein seine Schuld war.

Wenn man sich mit Observability-Preismodellen befasst, ähnelt das dem Zusammensetzen eines schwierigen Puzzles – ein Puzzle, das finanzielle Variablen und vertragliche Feinheiten beinhaltet. Alle potenziellen Kosten im Voraus vorherzusagen, kann eine ausufernde Aufgabe werden. Das Vermeiden von Fehleinschätzungen erfordert eine kontinuierliche Überwachung der Überwachungslösung. Diese Praxis bremst den Geschäftsbetrieb und das geschäftliche Wachstum.

Die Ausgaben für Observability besser steuern

Die steigenden Kosten im Zusammenhang mit Observability stellen eine große Herausforderung dar, vor der sich derzeit viele Organisationen sehen. Gerade im Zeitalter von Cloud-Computing haben IT-Leiter und sogar Top-Führungskräfte erkannt, dass es unerlässlich ist, die allzu häufig außer Kontrolle geratenden Infrastruktur-Budgets einzudämmen.

Die Verbreitung von Microservices und verteilten Architekturen hat eine Flut von Daten mit sich gebracht, die Observability unerlässlich macht. Traditionell betrachtet, resultieren aus mehr Daten höheren Ausgaben, verbunden mit einem erheblichem Ressourcenverbrauch, der wiederum zu steigenden Kosten sowie Ineffizienzen führt.

Leider verfolgen die meisten Observability-Werkzeuge Preismodelle, die sich einer genauen Vorhersage entziehen. Während Anwendungen große Mengen an Log-Daten generieren, gibt diese Datenflut Anlass zur Sorge. Als Reaktion heißt es in aktuellen Best Practices nun, nur das zu überwachen, was wirklich benötigt wird, oder die Aufbewahrungsdauer der gesammelten Daten zu begrenzen.

Dies wirft zwei Fragen auf: Wie soll man im Voraus wissen, welche Daten genau man brauchen wird? Und macht die Begrenzung der Aufbewahrungsdauer auf ein Minimum es unmöglich, aktuelle Daten mit außerhalb des Bereichs liegenden, historischen Informationen zu korrelieren?

Mit eBPF zu besseren, effizienteren Daten

Hier kommt der extended Berkley Package Filter (eBPF) ins Spiel, eine Technologie, die 2014 eingeführt wurde. ePF bietet einen ebenso sicheren wie effizienten Weg, Kernel-Fähigkeiten zu erweitern, ohne den Quellcode zu ändern oder Kernel-Module zu laden. In den vergangenen 36 Monaten hat sich eBPF weiterentwickelt, um neue Anwendungsfälle zu adressieren. Er erscheint als vielversprechende Lösung in Networking-Infrastruktur, Sicherheit und Observability.

Auf moderne Produktionsumgebungen zugeschnitten, stellt eBPF eine umfassende Abdeckung sicher, während nur wesentliche Daten gespeichert werden. Auf diesem Weg können Teams die Observabillity skalieren, ohne sich Sorgen machen zu müssen. Durch den Einsatz von eBPF erhält man tiefgreifende Kubernetes-Einblicke, vom Infrastruktur-Bereich bis hin zu den darauf laufenden Services und Anwendungen.

Indem Unternehmen Observability-Daten direkt vom Linux-Kernel mittels eBPF sammeln, entfällt der Bedarf für umfangreiche Wartungs- und Entwicklungsarbeiten. Sein Edge-Computing-Ansatz sammelt Daten effizient und bietet eine super-granulare aber skalierbare Sicht auf Kubernetes-Cluster-Aktivitäten.

Zu den charakteristischen Merkmalen von eBPF gehört die Fähigkeit, alle Aspekte eines Clusters abzudecken, während nur entscheidende Details gespeichert werden. Dies beginnt bei den Anwendungslogs und reicht über Metriken und Abläufe bis hin zu Kubernetes-Ereignissen. Sichtbarkeit und Kosten sind dank eBPF nicht länger ein Widerspruch in sich, denn es bietet robuste Funktionalität zu einem Bruchteil der vorherrschenden Marktpreise.

Im Gegensatz zu Tools, die eine Code-Instrumentierung der beobachteten Kubernetes-Anwendungen erfordern, vereinfacht eBPF die Installation und sammelt alle Observability-Daten außerhalb der beobachteten Anwendungen. Es nutzt Informationen aus der Kubernetes API, um Daten für jede Anwendung zu kontextualisieren, führt Analysen auf Cluster-Ebene durch und speichert Daten innerhalb des Clusters. Dies birgt Vorteile wie einen reduzierten Netzwerkverkehr, eine minimierte Datenspeicherung für Langzeitanalysen und Alert-Priorisierung basierend auf ihrer Kritikalität.

Zusammenfassend lässt sich festhalten: Observability-Tools sind für die Überwachung von Anwendungsstatus und -leistung unverzichtbar geworden, doch eBPF meistert sogar die Herausforderungen großer und verteilter Umgebungen. Es beobachtet umfassend alle Aspekte des Clusters und liefert nur die wesentlichen Metriken, die für eine effektive Überwachung und Fehlerbehebung benötigt werden.

(ID:49801199)