Open Source im professionellen Einsatz
Linux-Magazin 03/2016
© crisferra, 123RF

© crisferra, 123RF

Prometheus für das Cloud- und Enterprise-Monitoring

Großes im Blick

Wer Clouds oder massiv skalierte Setups mit einem konventionellen Monitoringsystem überwachen will, handelt sich Probleme ein. Das von Sound Cloud neu entwickelte Prometheus geht das Thema anders an und ist eine ernst zu nehmende Alternative zu Klassikern wie Nagios & Co.

868

Wo Monitoring gefragt ist, sind auch Alerting und Trending nicht weit. Alerting spielt bei praktisch allen Monitoring-Umgebungen eine große Rolle, denn schließlich gilt es, die verantwortlichen Techniker auf einen Ausfall aufmerksam zu machen. Kaum weniger wichtig ist das Trending. Gerade in massiv skalierbaren Setups hat der Anbieter großes Interesse daran, mögliche Engpässe in Sachen Performance frühzeitig zu erkennen. Nur so kann er angemessen reagieren und von vornherein kritische Probleme, etwa durch Überlastung, verhindern.

Ein Blick auf die verfügbaren Monitoring-Lösungen erklärt, warum Monitoring samt Alerting und Trending (MAT) besonders in stark ausgebauten Umgebungen nicht selten problematisch ist. Nagios, das den Markt lange dominiert hat, erweist sich vielerorts in Sachen Komplexität als Moloch und besitzt diverse inhärente Schwächen seines Designs.

Nagios-Alternativen wie Icinga haben die Situation zwar erheblich verbessert [1], geraten aber schnell an ihre Grenzen, wenn es etwa um die Skalierbarkeit des Monitoringsystems selbst geht. Die oft zwangsweise mitgeschleppte Kompatibilität zu Nagios und seinen Plugins tut ein Übriges. Ein aktuelles Thema wie Trending war im klassischen Nagios ab Werk kaum vorgesehen. Der Name PNP4Nagios [2] lässt manchen Admin schaudern, nennt aber bis heute eine der wenigen Möglichkeiten für brauchbares Trending mit Nagios (Abbildung 1).

Abbildung 1: Hergebrachte Lösungen wie pnp4nagios verursachen beim Generieren von Grafen hohe Last und brauchen trotzdem lange – besonders beim Darstellen größerer Zeiträume.

Sound Cloud als Vorreiter

Vor der Herausforderung, ein Monitoring-Konzept umzusetzen, sah sich auch das britische Unternehmen Sound Cloud. Die Firma betreibt einen Streaming-Dienst nach den Vorbild von Spotify oder Apple Music. Die wirkliche Challenge bestand von Anfang an darin, ein MAT-System so zu bauen, dass es auch bei Tausenden Knoten noch zuverlässig funktioniert. Anstatt vorhandene Komponenten zu einer Besser-als-gar-nichts-Lösung zu kombinieren, ging Sound Cloud neue Wege. Kurzerhand entschloss sich das Unternehmen dazu, ein eigenes Monitoringsystem zu entwickeln. Heraus kam Prometheus [3].

Prometheus weist im direkten Vergleich mit etablierten Lösungen wie Nagios eine große Besonderheit auf: Es bringt sein eigenes Speichersystem mit, um die im Rechnerverbund erhobenen Daten zu verwalten. Hier gibt es eine interessante Duplizität der Ereignisse: Auch der Sound-Cloud-Konkurrent Spotify probierte erst diverse etablierte Monitoringsysteme aus, bevor er schließlich auch ein eigenes entwickelte und dabei ebenfalls auf eine selbst geschriebene Time-Series-Datenbank setzte.

Auch die interne Datenbank von Prometheus fußt auf dem Konzept der Time Series Database. Außerdem denkt Prometheus dabei eher in der Dimension einer kompletten Metrik als in einzelnen Alerts. Um zu verstehen, was das bedeutet, ist ein kleiner Ausflug in die Speicherkunde nützlich.

Wie MAT-Systeme ihre Daten verwalten

Klassische Monitoringsysteme wie Nagios oder Icinga verfügen über keine besonders ausgefeilte Datenverwaltung. De facto brauchen sie die auch nicht: Beim Monitoring ist schließlich vor allem die Frage maßgeblich, ob ein Dienst A im Moment gerade ordnungsgemäß funktioniert oder nicht. Kommt das Thema Trending hinzu, wird die Sache aber kniffliger: Trending setzt voraus, dass über die Verfügbarkeit eines Dienstes oder die Auslastung der vorhandenen Infrastruktur langfristige Aufzeichnungen existieren.

PNP4Nagios etwa nutzt im Hintergrund eine Datenbank wie MySQL, um die benötigten Werte darin lange vorzuhalten. Allerdings ist MySQL für diese Art der Nutzung eigentlich nicht ausgelegt, was zu Problemen führt. Zunächst gilt, dass in entsprechend großen Installationen die Menge zu verwaltender Daten rasant wächst. Der persistente Speicher, auf dem alle Trending-Daten liegen, sollte also genauso gut skalieren können wie die gesamte Plattform. Das gilt vorrangig im Hinblick auf den Speicher, betrifft jedoch auch die Art, wie die jeweilige Datenbank mit immer größer werdenden Datenmengen umgeht.

Darüber hinaus stellt auch das Aufbereiten der Daten eine Herausforderung dar: Die Daten trudeln beim MAT-System nämlich sortiert in zeitlicher Reihenfolge ein, müssen auf der anderen Seite aber meistens bezogen auf konkrete Dienste ausgegeben werden. Beispiel: Das MAT-System wird von seinen Zielsystemen regelmäßig Datenpunkte zu verschiedenen Diensten in zeitlicher Abfolge geliefert bekommen, also etwa "9 Uhr: CPU-Nutzung bei 1, RAM-Nutzung bei 30 Prozent und belegter Plattenplatz bei 15 Prozent". Der Admin hingegen will meist wissen, wie hoch die CPU-Last in einem bestimmten Zeitraum war, also etwa zwischen 9 Uhr und der gleichen Zeit am vorherigen Morgen.

In jedem Fall ist das Speichern der Daten ein Kompromiss, denn die Werte sind entweder beim Ablegen in der Datenbank oder beim Auslesen durch den Administrator zu transponieren. Das allerdings ist eine ausgesprochen Ressourcen-hungrige Angelegenheit und gerade MySQL-Datenbanken sind mit entsprechenden Queries etwa von PNP4Nagios gern lange beschäftigt.

Hier kommt nun das Prinzip der Time Series Database ins Spiel. Denn im Grunde ist eine Time Series Database nichts anderes als eine Datenbank, die auf das Speichern von Daten in zeitlicher Relation ausgelegt ist; dadurch unterscheidet sie sich maßgeblich von klassischen Datenbanken wie MySQL. Das Umrechnen der Daten findet – das ist der Clou – über Algorithmen direkt in der Datenbank statt. Im Grunde bietet eine Time Series Database wie Prometheus bereits über ihr Datenmodell alle Funktionen, die für Trending notwendig sind.

Typisches Monitoring ist dann nicht viel mehr als eine Art Abfallprodukt: Geht für eine spezifische Metrik über einen Zeitraum kein Resultat ein, funktioniert der Dienst vermutlich nicht korrekt und die MAT-Lösung aktiviert das Alerting.

Diesen Artikel als PDF kaufen

Express-Kauf als PDF

Umfang: 6 Heftseiten

Preis € 0,99
(inkl. 19% MwSt.)

Linux-Magazin kaufen

Einzelne Ausgabe
 
Abonnements
 
TABLET & SMARTPHONE APPS
Bald erhältlich
Get it on Google Play

Deutschland

Ähnliche Artikel

  • Prometheus

    In der griechischen Mythologie bringt Prometheus den Menschen das Feuer. Die namensgleiche Software für verteiltes Monitoring erleuchtet hingegen den Geist von Admins in Cloud-Native-Umgebungen. Sie liefert auf recht unkomplizierte Weise Metriken der verfügbaren Systeme.

  • Kubernetes-Monitoring

    In Cloud-Native-Umgebungen stoßen klassische Monitoring-Tools an ihre Grenzen, wenn sie kurzlebige Objekte wie Container überwachen. Diese Lücke schließt Prometheus, das Kubernetes dank der konzeptionellen Ähnlichkeit, des einfachen Aufbaus und einer weitreichenden Automatisierung passgenau ergänzt.

  • Prometheus & Sensu

    Wer eine Monitoringsuite abseits von Nagios & Co. sucht, trifft fast zwangsläufig auf Prometheus und Sensu. Beide versprechen ähnliche Funktionalität, unterscheiden sich aber fundamental voneinander.

  • Grafana-Backends

    Grafana bereitet Messdaten aus verschiedenen Quellen optisch auf und bietet dem Admin eine gute Übersicht. Welche Backends unterstützt es? Eine Übersicht.

  • Prometheus geht zur Linux Foundation

    Die Cloud Native Computing Foundation (CNCF) der Linux Foundation hat heute ihr zweites Projekt nach Kubernetes akzeptiert. Das kommt von Soundcloud, heißt Prometheus und ermöglicht Monitoring mit Time-Series-Datenbanken.

comments powered by Disqus

Ausgabe 11/2017

Digitale Ausgabe: Preis € 6,40
(inkl. 19% MwSt.)

Stellenmarkt

Artikelserien und interessante Workshops aus dem Magazin können Sie hier als Bundle erwerben.