Container-Monitoring: Ausblick auf Prometheus 2.0

Gerfried Steube on April 27, 2017 - 5:09 pm in Software-Entwicklung

[ad_1]

Nicht mal ein Jahr ist es her, dass Prometheus 1.x erschienen ist. Und doch bringt die hohe Dynamik an Neuerung in der Anwendungs-Containerisierung es mit, dass sich die Entwickler des Monitoring-Systems mit einer neuen Generation auseinandersetzen.

Das Cloud-Monitoring-System Prometheus gehört zu den bekanntesten und wichtigsten Projekten der Cloud Native Computing Foundation (CNCF). Es folgte auf Kubernetes als zweites Softwareprojekt der Open-Source-Organisation und soll sich für das Monitoring der Pods (= Gruppe von Containern) nutzen lassen, die dynamisch über sehr viele Server verteilt ausgeführt werden. Die Veröffentlichung von Prometheus 1.6.1 wurde nun dazu genutzt, auf die derzeit geplanten Änderungen in der nächsten Generation des Werkzeugs einzugehen.

Nicht mehr zeitgemäß

Prometheus 1.x war vor ungefähr einem Dreivierteljahr erschienen, und die Entwickler haben offenbar damit zu kämpfen, mit diesem Releasestrang zeitgemäß zu bleiben, gerade wo sich das Umfeld der Containerisierung weiter so rasant weiterentwickelt. Als Monitoring-System muss Prometheus mit Produkten wie Kubernetes funktionieren, bei denen Hunderte von Containern sehr große und zunehmend mehr Datenmengen erzeugen.

Das bringt Änderungen mit sich, die anscheinend so grundlegend sind, dass es mit Prometheus 2.0 ein neues Haupt-Release geben wird. Derzeit liegt die neue Generation des Systems als sehr frühen Alpha-Vorschau-Version vor.

Neue Speicherschicht

Unter der Haube nutzt Prometheus eine Zeitreihendatenbank. Das bedeutet, dass die Technik viele Zeitstempelwerte erfasst, die mit hoher Geschwindigkeit in der Datenbank landen. Seine jetzige Speicherebene verwendet einzelne Dateien für jedes Zeitreihen- oder Monitoringobjekt, was zu vielen kleinen Dateien auf der Festplatte führt. Sowohl SSDs als auch herkömmliche Festplatten haben jedoch Schwierigkeiten mit diesem Konzept, da bestimmte Operationen so sehr teuer werden können.

Prometheus 2.0 soll nun Dateien erstellen, die statt nach Zeitreihen nach Zeitbereich partitioniert werden. Das jüngste Zeitfenster wird als In-Memory-Tabelle gespeichert, aber auch in Form von Write-ahead-Logging auf die Festplatte kopiert. Schließlich muss Prometheus nur das Write-ahead-Log abschließen, wenn das Zeitfenster voll ist, und ein neues öffnen. Es soll außerdem einfacher werden, Dateien zu erstellen, die der Speicherausrichtung der jeweiligen Festplattentechnik nachkommen, und alte Daten sollen sich leichter löschen lassen.

Die Änderungen stellen kein Hexenwerk dar, sondern sind bewährte Verfahren, die in Datenbanken wie LevelDB, Cassandra, InfluxDB oder HBase zum Einsatz kommen. Erste Benchmarks, die die neue Speicherschicht verwenden, weisen offenbar geringe Reduzierungen im Speicherverbrauch auf, dafür aber drastisch bessere Werte im CPU-Verbrauch und bei Spericher-I/O sowie eine deutlich überschaubare Latenz pro Abfrage, wenn Daten hinzugefügt werden.

Weitere große Verbesserungen sind einerseits die Möglichkeit, dass jeder benutzerdefinierte Remote-Speicher für Prometheus bauen kann, und die Absicht, das eigene Austauschformat bei Metriken zum IETF-Standard zu machen.

Siehe dazu auf heise Developer:

Prometheus-Monitoring für Java-Entwickler

(ane)

[ad_2]