Monitoring von produktiven Kubernetes-Plattformen

Autoskalierung benötigt Auto-Monitoring

Dynamische IT-Infrastrukturen sind dadurch gekennzeichnet, dass sie IT-Ressourcen für Anwendungen je nach Bedarf der Fachbereiche schnell nach oben oder unten skalieren können. Doch gleich, in welchem Umfang die Ressourcen zur Verfügung stehen: Sie müssen ordnungsgemäß überwacht und protokolliert werden.

Ein Unternehmen in der Automotive-Branche stand vor der Herausforderung, ein dynamisch skalierendes System übersichtlich zu halten. Die Dynamik ergab sich durch mehrere, autoskalierende Infrastrukturen und eine komplexe, sich bewegende Microservice-Anwendung. Daher musste der manuelle Aufwand für die Langzeitspeicherung der Beobachtungsdaten auf ein Minimum reduziert werden und gleichzeitig kosteneffizient sein.

Die Anforderungen

Ein Legacy-Überwachungs- und Protokollierungs-Stack, der die Anforderungen nicht erfüllte, ebenso wie fehlende Standards im gesamten System, stellten dabei zentrale Hürden dar.

• Das Überwachungs- und Protokollierungssystem musste Skalierungen erkennen und durfte keine falsch-positiven Alarme auslösen

• Traditionelle Überwachungssysteme stützen sich auf Hostnamen oder IP-Adressen, also statische Informationen, die sich nicht ändern. In dynamischen Umgebungen ändern sich diese Parameter teils sehr oft, weshalb diese Informationen nicht genutzt werden konnten

• Die Überwachungs- und Protokollierungssysteme mussten mit dem System über verschiedene AWS-Accounts skalierbar sein. Deshalb benötigten die Beobachtungssysteme Autoskalierungsfunktionen

Konfigurierte Open-Source-Projekte

Liquid Reply hat eine Überwachungsumgebung eingerichtet, die die Anforderungen mit der besten Möglichkeit, Infrastruktur und Anwendungen zu überwachen und zu protokollieren, erfüllt.

Für die Implementierung wurden die Projekte Prometheus, Thanos, Loki und Grafana der Cloud Native Computing Foundation (CNCF) verwendet.

Dabei zeigte sich der fehlende Einsatz von Standards im gesamten System, besonders bei der übergreifenden Überwachung verschiedener AWS-Dienste. Liquid Reply baute deshalb ein kontenübergreifendes Netzwerk mit nativen AWS-Diensten auf.

Um den Legacy-Überwachungs- und Protokollierungsstack zu überwinden, setzte Liquid Reply auf Helm-Charts, die von der Open-Source-Community entwickelt wurden. Diese erweiterte das Team um verschiedene Funktionen, die den Anforderungen des Klienten entsprachen.

Automatisierte Überwachung von neuen Clustern

In kurzer Zeit gelang es Liquid Reply, einen neuen, stabilen und sicheren Monitoring- und Logging-Ansatz aufzubauen. Durch die Integration der Lösung von Liquid Reply ist der Klient nun in der Lage, neue Kubernetes-Cluster zu erstellen, die vom zentralen Monitoring-Cluster automatisch überwacht und protokolliert werden. Das reduziert das Potenzial für manuelle Ausfälle der IT-Ressourcen und reduziert indirekt Kosten.

Warum das über dieses Projekt hinaus relevant ist

Monitoring, das bei jeder Skalierung von Hand nachgezogen werden muss, läuft der Plattform, die es beobachten soll, immer hinterher. Der entscheidende Schritt in diesem Projekt war deshalb nicht die Tool-Auswahl, sondern das Betriebsmodell: Observability als Code definiert, standardmäßig mit jedem neuen Cluster ausgeliefert und so zentralisiert, dass Langzeitspeicher, Alerting-Regeln und Dashboards genau einmal existieren.

Dieselbe Architektur – Prometheus für die Erfassung, Thanos für die Langzeitspeicherung über Accounts hinweg, Loki für Logs und Grafana darüber – hat sich inzwischen als verbreitete Basis für Kubernetes-Plattformen etabliert und bleibt unsere Standardempfehlung, wenn ein Legacy-Monitoring mit dem Autoscaling nicht mehr Schritt hält: durchgehend Open Source, skalierend mit der Plattform und ohne die manuelle Fleißarbeit, durch die Monitoring-Lücken überhaupt erst entstehen.