© Igor Yakovlev / 123RF.com

Monitoring gehört zu den eher lästigen Pflichten. Die Zeitreihendatenbank VictoriaMetrics verspricht jedoch, daraus ein Vergnügen zu machen. Der Dienst hat allerlei Werkzeuge im Gepäck, die Metrikdaten sammeln und auswerten.

Am Stammtisch der lokalen Linux User Group geht es häufig um interessante Themen. Die klassischen Brot-und-Butter-Themen der Systemadministration dagegen tauchen nur selten auf. Backups, Netzwerk, Datenbanken – Standarddienste bieten wenig Fummelpotenzial und lassen den typischen Nerd regelmäßig kalt. Brot-und-Butter-Themen sind sie aber trotzdem, will heißen: Ohne sie geht es nicht.

Monitoring ist so ein typischer Fall: Die wenigsten Administratoren befassen sich wirklich gern mit Werkzeugen wie Nagios oder Zabbix. Das müssen sie aber trotzdem, denn Monitoring ist der einzige Weg für den Administrator, schnell von Problemen zu erfahren und sie idealerweise so flott wie möglich anzugehen. Das verhindert oft größeres Ungemach, klappt aber eben nur, wenn der Admin von den sich anbahnenden Schwierigkeiten weiß. Dementsprechend bildet irgendeine Monitoring-Lösung heute einen festen Bestandteil jeder Umgebung.

Dass Monitoring-Tools kaum Begeisterung beim Administrator wecken, davon möchte man bei VictoriaMetrics [1] allerdings nichts wissen. Explizit tritt das Werkzeug mit dem Versprechen an, das trockene Thema der Überwachung in eine Art Selbstläufer zu verwandeln, den der Admin in Windeseile in Betrieb nehmen kann. Mehr noch: Auch Trending-Daten skalierbarer Systeme sammelt VictoriaMetrics ein und speichert sie so, dass sie sich grafisch abbilden lassen, etwa durch Grafana. Einen ersten Überblick darüber, was hinter der Lösung steckt, wie sie unter der Haube funktioniert und womit Admins rechnen müssen, gibt dieser Artikel.

Neues Paradigma

Aufmerksamen Lesern des Linux-Magazins kommen die Geschichte von und der Ansatz hinter VictoriaMetrics vermutlich bekannt vor. Schon einige Male berichteten wir über Prometheus, quasi den Urahn der momentan erfolgreichen Zeitreihendatenbanken [2]. Prometheus entstand bei Soundcloud vor vielen Jahren aus einem ganz praktischen Bedürfnis heraus. Als damals überaus erfolgreicher Streaming-Anbieter musste das Unternehmen viele harte Erfahrungen des Skalierens in die Breite mühsam selbst machen, weil Erfahrungswerte schlicht nicht existierten. Monitoring bedeutete zu dieser Zeit vorrangig Ereignis-Monitoring.

Im Fokus stand also die Frage: Geht auf meinen Systemen gerade alles so zu, wie es soll, oder stimmen einzelne Parameter nicht? Weicht etwa die Zahl der Httpd-Prozesse auf einem System vom Sollwert (mindestens 1) ab, weiß der Admin, dass Apache abgestürzt ist und er es neu starten muss. Vergleichbare Fragen spielen selbstverständlich auch bei großen skalierbaren Plattformen eine Rolle. Mindestens so wichtig wie klassisches Ereignis-Monitoring sind dabei das Trending und die Fähigkeit des Monitoring-Tools selbst, zusammen mit dem Setup in die Breite zu skalieren. Der Administrator will also nicht nur wissen, ob gerade alles funktioniert, sondern genauso, wie sich Faktoren wie die Auslastung des Setups in den kommenden Wochen und Monaten voraussichtlich entwickeln werden.

Nur dann besitzt er die Möglichkeit, die nötigen Prozesse etwa für den zeitnahen Einkauf neuer Systeme mit entsprechender Vorlaufzeit anzustoßen. Schließlich fällt in kaum einem Unternehmen neue Hardware von heute auf morgen vom Himmel, weil akuter Bedarf besteht. Obendrein will der Administrator sicher sein, dass sein Monitoring-Setup nicht ins Trudeln gerät, wenn das nächste Skalieren in die Breite ansteht.

Verbundene Ansätze

Trending und Ereignis-Monitoring weisen auf den ersten Blick scheinbar keine Schnittmenge auf, sind tatsächlich aber eng miteinander verknüpft: Zu viel Last gefährdet die Stabilität der Umgebung und führt zu langen Phasen unruhiger Bereitschaftsnächte. Früh galt in der Cloud-Community deswegen das Mantra, dass sich zum Monitoring und Alerting – Letzteres wird üblicherweise nicht genannt, schwingt jedoch beim Monitoring stets mit – noch das Trending hinzugesellen müsse.

Trending errechnet auf Grundlage vergangener Verbrauchswerte die künftige Entwicklung eines Setups und gibt durch diese Extrapolation dem Administrator die Freiheit für vorausschauendes Handeln. Die ersten Versuche, so etwas mit klassischen Monitoring-Systemen abzubilden, dürften die meisten Admins noch miterlebt haben. PNP4Nagios (Abbildung 1), PNP4Icinga und Co. sollten vielen noch ein Begriff sein. Alle entsprechenden Ansätze setzten im Hintergrund auf relationale Datenbanken zum Speichern der Daten.

Abbildung 1: PNP4Nagios war eine der ersten Trending-Lösungen im IT-Umfeld, fußte jedoch auf einer relationalen Datenbank und wurde dadurch bald unerträglich langsam. Quelle: Sergio Cayuqueo

Das aber führt unweigerlich zu einem Problem beim Abrufen der Daten: Ein großes Setup aus unzähligen Knoten produziert Millionen von Datensätzen pro Tag. Legen Sie die in eine relationale Datenbank und versuchen dann, einen Teilbereich davon für die grafische Darstellung wieder auszulesen, muss die Datenbank jede einzelne Zeile der jeweils ausgewählten Datenbanktabelle zuerst einlesen und im Anschluss gegebenenfalls aussortieren. Bei Tabellen mit mehreren Hundert Millionen Zeilen dauert das ewig. Entsprechend unbeliebt waren die Ansätze, die auf diesem Prinzip basierten.

Prometheus macht es gut

Zeitreihendatenbanken – und genau dazu gehören Prometheus und VictoriaMetrics – packen das Problem buchstäblich an der Wurzel. Anders als relationale Datenbanken organisieren sie sich intern nicht mit einer Struktur aus Tabellen, Zeilen und Spalten. Stattdessen dient bei Zeitreihendatenbanken ein Zeitstrahl als Wurzelelement, und jeder einzelne Punkt auf diesem Zeitstrahl kann auf von Zielsystemen gesammelte Metrikdaten verweisen. Die Abfrage zeigt sich dementsprechend viel sparsamer im Hinblick auf die benötigten Ressourcen, weil die Daten in der Datenbank bereits sortiert sind.

Aus Client-Sicht genügt es, der Zeitreihendatenbank den Zeitpunkt oder -raum mitzuteilen, für den Sie die darin liegenden Datensätze haben möchten. Genau damit gewann Prometheus im Kontext skalierbarer Systeme die Herzen vieler Administratoren. Inzwischen hat sich das Prinzip von Time Series Databases, so die englische Bezeichnung, weitgehend durchgesetzt und etliche Nachahmer gefunden. Prominente Lösungen wie InfluxDB haben eine große Fangemeinde, obwohl das Werkzeug mittlerweile nur noch unter einer proprietären Lizenz zu bekommen ist.

Prometheus selbst hat sich über die Jahre zwar kontinuierlich entwickelt, einige der Schwächen seines ursprünglichen Designs konnte es allerdings bis heute nicht ablegen. Manche davon sind so grundlegend, dass sie nur mit einem umfassenden Rewrite zu korrigieren wären – ein umso schwierigeres Unterfangen, wenn Prometheus mit bestehenden Systemen kompatibel bleiben soll. Dabei sind einige der Prometheus-Probleme wirklich drängend.

Beispielsweise tut sich Prometheus (Abbildung 2) schwer damit, riesige Mengen von Archivdaten zu speichern und dabei eine gewisse Performance zu erhalten. Je mehr eine Datenbank in Prometheus anschwillt, desto langsamer wird sie deshalb. Ein weiteres großes Manko besteht in der mangelnden Fähigkeit, Cluster zu bilden. Ursprünglich war das als Feature gar nicht vorgesehen. Geht es nach den Prometheus-Entwicklern, sollten Admins stattdessen einen Zirkus aus Prometheus-Knoten bauen, die einzelne Teile eines Setups abfragen. Das bringt allerdings den unschönen Nebeneffekt mit sich, dass es keinen Single Point of Administration gibt und der Administrator den Überblick über eine Art händisches Sharding behalten muss. Zwar gibt es Wege, das Problem zum Teil zu umgehen, beispielsweise Thanos. Der Weisheit letzter Schluss sind diese Versatzstücke aber nicht.

Abbildung 2: Die Zeitreihendatenbank Prometheus hat das Monitoring verteilter Systeme revolutioniert. Ihr Design umfasst jedoch mehrere kaum zu korrigierende Schwächen.

Hinzu kommt, dass Prometheus von Anfang an verschiedene technische Probleme gar nicht lösen wollte. Das Langzeitspeichern von Daten zum Beispiel war nie ein Thema: Dafür hatten die Prometheus-Entwickler andere Lösungen vorgesehen, zum Beispiel InfluxDB. Nach einem Downsampling der Daten, also dem Reduzieren auf wenige statistisch relevante Werte, sollte Prometheus eigentlich InfluxDB als Speicher für Langzeitdaten nutzen. Das aber steht inzwischen nicht mehr kostenlos zur Verfügung, und sinnvolle technische Lösungen für das Downsampling müssen Sie mühsam suchen und implementieren.

VictoriaMetrics macht es besser

Vorhang auf für VictoriaMetrics: Das Tool existiert ebenfalls schon seit ein paar Jahren, nimmt derzeit allerdings erst so richtig Fahrt auf. Haben Sie sich über die lange Einleitung zu Prometheus am Anfang eines Artikels über VictoriaMetrics gewundert, können Sie beruhigt sein – VictoriaMetrics imitiert Prometheus an verschiedenen Stellen und ähnelt ihm unter der Haube stark. Grundkenntnisse über Prometheus bilden dementsprechend das Wissensfundament für VictoriaMetrics.

VictoriaMetrics gehört wie Prometheus zu den Zeitreihendatenbanken, aber eben nicht nur. Hier gilt es, sich nicht von Begrifflichkeiten verwirren zu lassen – und das passiert gerade im Prometheus-Kontext allzu leicht und schnell. Prometheus bezeichnete im Grunde lediglich die Datenbank nach Zeitreihenprinzip, hat sich über die Jahre aber zur Bezeichnung für eine Sammlung mehrerer Werkzeuge gewandelt. So gut wie immer kommt Prometheus im Gespann mit dem Alertmanager und dem Node Exporter daher. Ersterer generiert aus eingehenden Metrikdaten Alarme und versendet sie über vorkonfigurierte Pfade. Letzterer sammelt Metrikdaten auf Zielsystemen ein und stellt sie so zur Verfügung, dass Prometheus sie abrufen kann.

VictoriaMetrics (Abbildung 3) dagegen bezeichnet gerade nicht nur eine einzelne Komponente. Weil es je nach gewählter Version außerdem umfangreiches Clustering beherrscht, bezieht sich der Name auf die Gesamtheit aller Werkzeuge, die diese und andere Funktionen implementieren. Auch bei VictoriaMetrics hat der Administrator es also unter der Haube mit einer Zeitreihendatenbank zu tun. Allerdings besteht sie aus etlichen Kleinteilen und bietet mehr Funktionalität als Prometheus, zumindest in der geclusterten Version. Die Version ohne Cluster nimmt sich demgegenüber nachgerade bescheiden aus und besteht tatsächlich aus nur einem einzelnen Binary.

Abbildung 3: Die Architektur der geclusterten Victoria-Metrics-Variante verheißt grenzenlose Skalierbarkeit auf allen Ebenen der Anwendung. Quelle: VictoriaMetrics

Blick unter die Haube

Zunächst müssen Sie sich bei VictoriaMetrics also entscheiden, ob Sie die Single-Node- oder die Cluster-Version in Ihrer Infrastruktur ausrollen möchten. Für Setups mit weniger als einer Million Metrikdatensätzen pro Sekunde empfehlen die Victoria-Entwickler den Einsatz der Einzeldatenbank. Das ist durchaus eine Menge: Ein Setup aus 200 Knoten, in dem der Administrator pro System alle 20 Sekunden 200 Metrikdaten auslesen lässt, produziert gerade mal einen Bruchteil dieser Menge.

Hier tritt einer der Kernunterschiede zwischen VictoriaMetrics und Prometheus zutage: Der Newcomer geht mit seinen Ressourcen schonender um und verspricht dadurch bei hohem Datenaufkommen eine deutlich bessere Performance. Die Entwickler nennen dazu konkrete Zahlen, nämlich achtmal weniger RAM-Bedarf als Prometheus bei vergleichbarer Last und bis zu zwanzigmal mehr Leistung in allen Kategorien als etwa die ebenfalls sehr beliebte InfluxDB. Obendrein eignet sich VictoriaMetrics laut seinen Erfindern viel besser für Setups in der Public Cloud, denn auf den dort üblicherweise günstig verfügbaren Speicher mit wenig Performance und hoher Latenz haben sie das Werkzeug ganz spezifisch zugeschnitten. Anders als Prometheus soll VictoriaMetrics also selbst dann nicht ins Straucheln geraten, wenn nur langsamer Speicher zur Verfügung steht.

Die Anregung der Entwickler, bevorzugt auf die nicht geclusterte Variante von VictoriaMetrics zu setzen, basiert vor allem darauf, dass sie sich deutlich leichter einrichten lässt. Klar, verteilte Systeme fallen immer komplex aus. Der Rückschluss, die Cluster-Version funktioniere hinter den Kulissen völlig anders als die Variante für den Alleinbetrieb, greift allerdings nicht. Die Funktionen lassen sich durchaus vergleichen. Sehen Sie sich die geclusterte Variante an, erschließt sich einiges der Victoria-Funktionalität aber schneller, gerade weil die einzelnen Komponenten hier sichtbar in Erscheinung treten und sich nicht in einem gemeinsamen Binary verstecken.

Den Kern der Anwendung bildet dabei die Zeitreihendatenbank, aber auch sie besteht bei VictoriaMetrics anders als bei Prometheus aus mehreren Einzelteilen im Stil einer Mikroarchitektur. So existiert in Form von Vmstorage beispielsweise ein eigener Dienst, dessen einzige Aufgabe darin besteht, beliebige Daten im Hintergrund auf den Datenträger zu schreiben. Ihm stehen Vminsert und Vmselect zur Seite. Ersteres sammelt die Daten ein und gibt sie im Anschluss an Vmstorage weiter, Letzteres implementiert die Gegenrichtung: Möchte etwa Grafana Daten aus VictoriaMetrics auslesen, um sie grafisch abzubilden (Abbildung 4), schickt es die Anfrage an Vmselect. Das sucht dann die passenden Daten aus Vmstorage heraus und leitet sie weiter. Damit ist klar, dass Vmstorage nicht nur für das Speichern von Daten zuständig ist, sondern auch für das erneute Auslesen.

Abbildung 4: Produkte wie die Kubernetes-Distribution Kublr haben Prometheus mittlerweile wegen höherer Geschwindigkeit und Effizienz durch VictoriaMetrics ersetzt. Quelle: Kublr / EastBanc Technologies

Nahtlos skalierbar

Der Clou an der Sache: Vor allem im geclusterten Setup skalieren alle Einzelkomponenten von VictoriaMetrics nahtlos in die Breite. Insbesondere von Vmstorage kann es also beliebig viele Instanzen geben. Sie kommunizieren über ein eigenes Protokoll im Hintergrund miteinander und sind nach klassischer Definition redundant sowie hochverfügbar. Dazu replizieren sie Daten im Hintergrund synchron. Dabei enthält nicht jede Vmstorage-Instanz den gesamten Datensatz. Stattdessen betreibt Vmstorage eine Form des automatischen Shardings, bei dem es Daten, auf die VictoriaMetrics anschließend die Replikation anwendet, aufsplittet und so verteilt. Das Einsetzen synchroner Replikation erweist sich potenziell freilich als Flaschenhals in Sachen Performance, dem die Entwickler durch verschiedene Tricks und Kniffe auf der Codeebene aber beizukommen versuchen.

Nahtlos in die Breite skalieren dementsprechend ebenso Vmselect und Vminsert. Logisch, denn solange sie mit den Vmstorage-Instanzen des Clusters kommunizieren können, können sie neue Daten entgegennehmen oder vorhandene Daten ausliefern. Wichtig aus Sicht des Administrators ist dann jedoch, dass er den verschiedenen Vmselect- und Vminsert-Instanzen einen Load Balancer voranstellt, um von außen darauf zugreifen zu können. Wie in der heutigen IT üblich, setzt VictoriaMetrics für die Kommunikation auf eine ReST-Variante, sodass unter der Haube HTTP zum Einsatz kommt. Die Notwendigkeit zum Betrieb eines Load Balancers dürfte jedoch die meisten Administratoren ohnehin nicht mehr aus der Ruhe bringen: Mit Tools wie Ansible lässt sich ein solcher in kürzester Zeit ausrollen.

Weiterhin erwähnenswert im Hinblick auf Vmselect und Vminsert ist, dass sie diverse auf dem Markt etablierte Formate und Standards unterstützen, um interoperabel mit anderen Lösungen zu sein. Wer etwa Daten aus InfluxDB oder Prometheus in VictoriaMetrics zur Langzeitspeicherung übertragen möchte, profitiert davon, dass VictoriaMetrics die Ingestion-Protokolle beider Lösungen versteht und spricht.

Daraus ergeben sich vielfältige Möglichkeiten: Wer beispielsweise bereits ein komplettes und in Summe gut funktionierendes Setup besitzt, kann VictoriaMetrics trotzdem parallel ausrollen und als Langzeitspeicher für sein Prometheus-Setup nutzen. Das bietet sich ganz besonders an, wenn in Prometheus zu viele Daten lagern, die Anwendung bereits träge geworden ist und Alternativen wie Thanos oder Cortex nicht für hinreichende Abhilfe gesorgt haben.

Obendrein versteht Vminsert die Metrikdatenformate verschiedener Tools wie Prometheus oder InfluxDB. Das bedeutet nichts anderes, als dass sich Daten jeder Anwendung im Prometheus-Format in VictoriaMetrics problemlos verwenden lassen. Indem sich das Werkzeug also in das bestehende Ökosystem rund um Prometheus integriert, erweitert es den eigenen Aktionsradius beträchtlich.

In die Gegenrichtung – also beim Auslesen von Daten aus VictoriaMetrics – gilt dasselbe. Auch hier versteht und spricht VictoriaMetrics beispielsweise die Prometheus-Skriptsprache PromQL. Entsprechend kann es als Datenquelle für Grafana nach Prometheus-Standard dienen. Dann allerdings nutzen Sie nicht alle gebotenen Funktionen. Vmselect hat PromQL erweitert und nennt seine eigene Spielart MetricsQL. Sie unterstützt mehr Funktionen und Befehle als das auf Prometheus zurückgehende PromQL und arbeitet flotter (Abbildung 5).

Abbildung 5: Selbstverständlich kann VictoriaMetrics Metrikdaten von sich selbst sammeln und durch Grafana optisch aufbereiten lassen. Dasselbe gilt für die Überwachung von Prometheus-Instanzen. Quelle: VictoriaMetrics

Weitere Werkzeuge

Zwar lässt sich VictoriaMetrics als Backend-Speicher für Prometheus nutzen, aber die Entwickler betrachten es keinesfalls als schlichtes Anhängsel. Stattdessen will und soll VictoriaMetrics ein vollständiger und selbstständiger Monitoring-Stack sein. Daraus ergibt sich implizit, dass in dieser Vorstellung ein paar Komponenten fehlen und in der Tat: Zu VictoriaMetrics gehören auch noch Vmalert und Vmagent. Wenn Sie mit Zeitreihendatenbanken schon Erfahrung gesammelt oder möglicherweise sogar schon einmal Prometheus eingesetzt haben, ahnen Sie, wo die Reise hingeht.

Vmagent übernimmt als Sammelwerkzeug von VictoriaMetrics Metrikdaten und gibt sie an Vminsert weiter. Auch dazu hat VictoriaMetrics sich am Markt orientiert und schöpft aus dem Vollen: Es bietet sowohl Pull-Unterstützung für Prometheus-Exporter als auch eine Schnittstelle, über die Push-basierte Dienste wie Telegraf von InfluxDB ihre Metrikdaten einreichen können. Hier wächst mithilfe von VictoriaMetrics also zusammen, was eigentlich gar nicht zusammengehört.

Ein sinnvoll konzipiertes Victoria-Setup ermöglicht es dem Administrator, quasi die gesamte Welt der Werkzeuge zur Metrikdatenerhebung unter einem Administrationspunkt zu vereinigen. Das vergrößert die Flexibilität erheblich. Der verteilte Objektspeicher Ceph etwa, der häufig in skalierbaren Umgebungen vorzufinden ist, bietet eine eigene native Schnittstelle für Metrikdaten im Prometheus-Format. Die kann Vmagent ebenso abgreifen wie die Metrikdaten, die der vom Prometheus-Projekt angebotene Node Exporter auf Systemen erhebt. Darunter fallen Standardwerte wie CPU-Last, RAM-Nutzung oder die Anzahl laufender Prozesse.

Für andere Programme gibt es keine fertigen Metrikdatensammler. Wo doch, bedienen sie eher nicht Prometheus, sondern Telegraf für InfluxDB. Auch sie lassen sich nahtlos an Vmagent ankoppeln. Unter der Haube unterstützt Vmagent dabei zusätzlich umfassende Labeling-Funktionen der eingehenden Daten. Labels braucht es im Kontext von Prometheus und Co. vorrangig für das Auslesen und die grafische Darstellung; ganz generell ermöglichen sie es, bestimme Metrikdaten gezielt aus der Datenbank zu fischen. Vmagent erkennt und interpretiert nicht nur bestehende Labels der Dienste, die Metrikdaten sammeln. Es kann sie auch verändern und beim Wegschreiben im Hintergrund in veränderter Form der Zieldatenbank mit auf den Weg geben. Wieder gibt Vmagent sich polyglott. Als Schreibziel steht nicht nur Vminsert zur Verfügung, sondern auch jede andere Zeitreihendatenbank, die das Prometheus-Protokoll beherrscht.

Vmalert schließlich markiert das VictoriaMetrics-Gegenstück zum Alertmanager von Prometheus. Der Dienst nimmt eingehende Metrikdaten unter die Lupe und schlägt Alarm, wenn sich darin bestimmte, vom Administrator zuvor festgelegte Muster finden. Vmalert unterstützt die Query-Sprache MetricsQL und zeigt sich dadurch flexibler als der Alertmanager bei Prometheus. Mit dem möchte man sich bei VictoriaMetrics allerdings erkennbar gut stellen, denn mittlerweile kann Vmalert sich gegenüber dem Alertmanager selbst als Alertmanager ausgeben und so einen Cluster bilden. Wieder machen die Victoria-Entwickler es damit den Admins bestehender Setups leicht, eine Migration zu planen.

Fazit: Ausprobieren

Ein Artikel wie dieser bietet kaum genügend Raum, um den umfangreichen Schatz an Funktionen in VictoriaMetrics komplett zu beschreiben. Deutlich auszumachen ist jedoch der Ansatz von VictoriaMetrics als eine Art Prometheus auf Steroiden – quasi als die Inkarnation von Prometheus, die dessen Entwickler mit dem heutigen Erfahrungs- und Wissensschatz von vornherein aufgesetzt hätten. VictoriaMetrics skaliert besser als Prometheus, arbeitet flotter und unterstützt zugleich dessen sämtliche Funktionen.

Unterstellt man jetzt den Entwicklern, sie planten hinterrücks so etwas wie die feindliche Übernahme bestehender Prometheus-Setups, indem sie VictoriaMetrics als 1-zu-1-Ersatz in Stellung bringen, liegt man wohl nicht ganz falsch: Sämtliche zu VictoriaMetrics gehörenden Komponenten liegen in der modernen Container-Form vor und lassen sich etwa innerhalb von Kubernetes sehr flott ausrollen. Zudem kann man VictoriaMetrics innerhalb eines Setups problemlos als Ergänzung zu Prometheus oder parallel als Ersatz in Betrieb nehmen. Offen zugeben würden die VictoriaMetrics-Entwickler den Frontalangriff auf die Prometheus-Userbase aber freilich nicht. Die kommt irgendwann, so wohl das Kalkül, schon von allein auf den Trichter. Ganz unrealistisch erscheint das nicht, denn in vielerlei Hinsicht wirkt VictoriaMetrics Prometheus tatsächlich haushoch überlegen.

Obendrein steht VictoriaMetrics in der kostenlosen Community Edition als vollständig freie Software unter einer freien Lizenz. Geld möchten die Autoren vor allem mit der Enterprise-Variante verdienen, die spezifische Zusatzfunktionen bietet. Dazu gehören beispielsweise eine zusätzliche Integration von Kafka sowie umfassende Mandantenfähigkeit innerhalb ein und derselben VictoriaMetrics-Instanz. Obendrauf kommt selbstverständlich der obligatorische kommerzielle Support.

Falls Sie nun mit dem Gedanken spielen, das Werkzeug einmal auszuprobieren, sind Sie mit der Community Edition und deren ausführlicher Dokumentation erst einmal bestens bedient. Ausprobieren sollten VictoriaMetrics zumindest alle, die bisher Prometheus verwenden und damit nicht zufrieden sind. (jcb/csi/jlu)