iX 9/2019
S. 80
Report
Cloud-Monitoring

Werkzeuge zum Überwachen von Clouds und Cloud-Workloads

Wolkenvorhersagen

Martin Gerhard Loschwitz

Auch in der Cloud spielt das Thema Monitoring eine wichtige Rolle. Doch die Anforderungen sind andere als von klassischen Set-ups gewohnt. Fünf Open-Source-Tools zeigen, was sie draufhaben.

Na klar, mit der Cloud wird alles besser: Weil künftig alle Entwickler nur noch zur „Cloud Native“-Architektur greifen, sind Applikationen automatisch implizit redundant. Geht mal etwas kaputt, macht das der App nichts aus: In bester VW-Käfer-Manier läuft sie einfach und läuft und läuft. Aus Administratorensicht beginnen paradiesische Zeiten: Eben weil immer alles automatisch wie von Geisterhand läuft, kommt das Thema Monitoring zu kurz. Ein Monitoringsystem wie Nagios oder Icinga wird in der Cloud schlicht nicht mehr gebraucht, weil alles so schön automatisch funktioniert.

Sattelfesten Cloud-Admins wird ein gewisser Sarkasmus in den vorherigen Zeilen nicht entgangen sein. Während die „Cloud Native“-Architektur in der Tat bewirkt, dass Admins weniger oft aus dem Bett geklingelt werden, ersetzt sie freilich nicht das Monitoring der Umgebung. Zwar wollen manche Hersteller genau das ihren Kunden weismachen, doch wer sich schon mal mit dem Betrieb von Clouds beschäftigt hat, merkt schnell: Ohne Monitoring ist auch in Cloud-Umgebungen kein Blumentopf zu gewinnen. Faktisch wäre das auch sehr seltsam, schließlich läuft der Workload in Clouds ja immer noch auf Computern. In denen ist Hardware verbaut, die bisweilen kaputtgeht. Und auch Cloud-Anwendungen werden noch immer von Menschen programmiert, die Fehler machen. Zwingt also ein Fehler ein Programm in die Knie, ist es gar nicht so unwahrscheinlich, dass eben nicht nur eine der Instanzen des Programms dran glauben muss, sondern dass gleich alle ins Nirwana verschwinden. Und so leicht Clouds laut diversen Herstellern auch wartbar sein sollen – wenn etwas schiefgeht, möchte der Admin das merken, und zwar schnell. Kaum etwas ist noch peinlicher als ein Kunde, der auf ein Problem hinweist, das das eigene Monitoringtool noch nicht erkannt hat.

Allein: Welche Werkzeuge eignen sich besonders gut zum Verwalten von Clouds? Spielt die Riege der klassischen Monitoringwerkzeuge hier überhaupt noch eine Rolle oder kann der Admin sein Zabbix- und Nagios-Wissen in der Mottenkiste auf dem Dachboden verstauen? Aber welches sind im letzteren Fall die Alternativen? Und wie gehen Unternehmen mit der Tatsache um, dass sie in Clouds eigentlich zwei Dienstarten überwachen müssen: jene in der Cloud und die der Cloud selbst? Fragen über Fragen – im Folgenden liefert iX die wichtigsten Antworten.

Die Power von Open Source

Monitoringwerkzeuge finden sich am Markt wie Sand am Meer. Da sind etwa die klassischen Tools wie Nagios, Zabbix oder Icinga. Dann existiert eine ganze Reihe neuartiger Werkzeuge, deren Funk­tionsumfang ein ganzes Stück über ein­faches Monitoring hinausreicht, etwa InfluxDB oder Prometheus, natürlich im Tandem mit ihren jeweiligen Helferlein. Und während die vorgenannten Tools samt und sonders Open-Source-Werkzeuge sind, buhlen natürlich auch eine ganze ­Reihe kommerzieller Werkzeuge um die Gunst der Admins. Die Tabelle „Kommerzielle Cloud-Monitoring-Tools“ listet ohne Anspruch auf Vollständigkeit eine Reihe gängiger Vertreter auf.

Wollte man alle Tools dieser Art gegenüberstellen, würde ein Artikel wie dieser gerade für die Einleitung reichen. Es ist deshalb unbedingt notwendig, den ­Scope stark einzugrenzen. Freilich haben Eingrenzungen dieser Art immer etwas Willkürliches – warum etwa hat das Tool, das man aus eigener Erfahrung seit etlichen Jahren gerne nutzt, es nicht in die Wahl geschafft? Dennoch hat der Autor dieses Artikels auf Grundlage der eigenen Erfahrung versucht, ein möglichst breites Kandidatenfeld zusammenzustellen. Die einzige Anforderung an alle Probanden war dabei, dass sie zur Riege der Open-­Source-Werkzeuge gehören müssen. Kommerzielle Werkzeuge bleiben im folgenden Artikel deshalb unbeachtet.

Monitoring der Gegenwart

Bevor es daran geht, den einzelnen Werkzeugen auf den Zahn zu fühlen, steht ein bisschen Theorieunterricht auf dem Programm. Denn wer sich bisher vor allem im Kontext konventioneller Monitoring­ansätze mit dem Thema beschäftigt hat, denkt beim Begriff Monitoring vermutlich an Nagios, Icinga oder einen der anderen klassischen Vertreter. Dagegen ist im Grundsatz nichts einzuwenden, denn diese Werkzeuge haben über viele Jahre und teils über Jahrzehnte hinweg wichtige Dienste geleistet.

Nagios ist die klassische Monitoringlösung, allerdings geraten das Tool und seine Abkömmlinge im Cloud-Kontext zusehends unter Druck (Abb. 1).
wikipedia.org, CC BY-SA 4.0

Nagios und Co. sind vorrangig Werkzeuge, die den Zustand einzelner Ressourcen überwachen und Alarm schlagen, falls dieser sich in ungewollter Art und Weise verändert. Ein entsprechender Test ist etwa: „Läuft auf dem System wenigstens eine Instanz des Dienstes httpd?“ Ist das der Fall, schließt das Monitoring daraus, dass Apache läuft und funktioniert. Für konventionelle Umgebungen ist das völlig ausreichend: Hier ist nicht selten ein Monitoring-Cluster Bestandteil des Gesamtkonzeptes und wird mit dem Rest des Set-ups ganz am Anfang bereits ausgerollt.

In Cloud-Umgebungen schadet ein umfassendes Event-Monitoring zwar nicht, aber hier ist ein anderer Faktor mindestens ebenso wichtig: das Trending. Im Kontext des Cloud-Computing hat sich deshalb der Begriff „Monitoring, Alerting und Trending“ eingebürgert, üblicherweise abgekürzt mit MAT. Um die Bedeutung von Trending für Clouds zu verstehen, hilft ein kurzer Blick hinter die Kulissen gängiger Set-ups.

Warum Trending wichtig ist

Betreiber von Cloud-Umgebungen sind eigentlich Plattformanbieter. Wo man früher für einzelne Kunden einzelne Set-ups gezimmert hat, beschränkt man sich heute darauf, eine General-Purpose-Plattform für zwei Dienste zu bieten: Speicher und Compute. Den größten Teil der Konfigurationsarbeit gibt man an die Kunden ab und verkauft ihnen das schrägerweise sogar noch als „On-Demand-Funktionalität“; die Demarkationslinie zwischen der eigenen und der Kundenverantwortung ist üblicherweise der Punkt, an dem auf dem System die Kontrolle über Workload an eine virtuelle Maschine oder den Storage-­Dienst übergeht. Plastisch formuliert: Der Anbieter hat sicherzustellen, dass der Kunde einen qemu-kvm-Prozess starten kann und dass die daraus entstehende VM Speicher und Netz hat. Alles andere regelt der Kunde alleine.

Damit das klappt, hat der Anbieter ein gewisses Sicherheitspolster für neue Kunden zu pflegen. Jederzeit kann sich schließlich ein Kunde einen Account für die Plattform erstellen, seine Kreditkarte durchziehen und anfangen, quasi unbegrenzt Ressourcen zu verwenden; das gilt zumindest für Public Clouds. Und so mancher Einfaltspinsel war auch schon davon überrascht, auf wie viel Liebe eine ­Private Cloud stieß, nachdem sie erst mal aufgesetzt war und funktionierte.

Kommentare lesen (2 Beiträge)