Ich beschäftige mich mit Zeitreihenbasierenden Datenbanken (TSDB) seit ich bei (ehem.) Gruner+Jahr für eine CoreMedia Installation einen Monitoringstack designed und aufgebaut habe.
Das sind jetzt gute 5 bis 6 Jahre her. In der Zwischenzeit habe ich so ziemlich alle Platzhirsche durchgespielt:
- graphite
- influxdb (in Version 1)
- prometheus
Un noch heute bin ich der Meinung, das graphite mit seinen Tools und seiner Berechenbarkeit eine der besseren TSDB ist. Leider hat man irgendwann die sichtbare Entwicklung heruntergefahren.
Im Laufe der Zeit änderten sich die Projekte und deren Anforderungen und so bin ich mittlerweile bei Prometheus gelandet, obwohl ich deren technische Implementierung eher suboptimal finde.
Aber warum denn jetzt goodbye?
Datenimport (von historischen Daten)
Hier lungert einiges an historischen Daten herum.
Wir können zum Beispiel die Daten unserer Waage exportieren, oder die vom Blutdruckmessgerät, oder von der Notify App für das Mii Band.
Daten die man dann gern auch mal Visualisieren oder aber auf einem größeren Bildschirm mit freiem Graphendesign sehen möchte.
Diese Daten reichen aktuell so zirka 2-3 Jahre in die Vergangenheit.
Den Import solcher Daten konnte man schon immer bei einer graphite oder einer influx durchführen.
Deren API und das stream Protokoll machten das ziemlich einfach.
Prometheus bietet das nicht. Aus technischen Gründen (deren Erklärung ich nicht finden konnte).
Technische Aspekte
Die Architektur von Prometheus ist stark auf kubernetes ausgerichtet.
Der Service pullt sich alle Informationen von seinen Exportern.
Also genauso viele zusätzliche Prozesse wie man Services überwachen möchte. (Wer denkt sich denn bitte so etwas aus!?)
Jeder der Exporter hat seinen eigenen (völlig offenen und ungeschützten) HTTP Port.
Enige von denen kollidieren dann auch richtig mit alteingesessenen Services.
Man google bitte einfach mal nach Port 9100 und Print Server, Port 9100/TCP ..
Kann man also so machen .. ist dann aber auch Scheiße
Beispiele
Jetzt betreue ich ja nicht unbedingt nur Kubernetes Cluster, sondern auch klassische Stacks.
So mit real existierender Hardware, oder eben virtuelle instanzen.
Gern auch über ein stark fragmentiertes Netzwerk und mit entsprechenden (gemanageten) Firewalls dazwischen.
Und diese Firmen haben gute Netzwerker, die sich einen Kopf machen, wie man das ganze sicher bekommt.
Beim blanken Einsatz von Prometheus in solch einem Netz und die Netzwerker nehmen dich ganz schnell und hart in “hab-acht”.
Also landen diese Exporter im Endefekt alle hinter einem Webserver. Mit TLS Zertifikat und einer Basic Authentication.
Klar könnte man auch die Federation benutzen!
Aber dann kann man dieses “Keep-it-Simple” auch gleich in die Tonne treten!
Jeder zusätzliche Service mehr, ist einer zuviel!
Also ein Webserver … (Anzahl der zu überwachenden Services *2 +1 … Ressourcenverschwendung mit Ansage.)
Graphite oder InfluxDB betankt man mit einem einzigen Agent. Dieser wiederum pushed seine erhobenen Daten in Richtung seiner TSDB (Aus Sicht der Netzwerker und Firewallkonfiguration das deutlich bessere Model).
Jeder Agent kann über Plugins erweitert werden und somit auch auf gewachsene Anforderungen reagieren.
Damit reduziert sich - je nach Art der Architektur - die Anzahl von Services, die das Monitoring ausmachen, auf 3 oder 4.
Data Retention
TSDB wachsen.
Je mehr Messpunkte, desto schneller.
Das potentiert sich zusätzlich noch, je mehr Services man überwachen möchte.
Das ganze kann - wenn man hier Plan- und Kopflos herangeht - ganz schnell explodieren.
Weder InfluxDB noch Prometheus bieten so etwas wie den whisper-calculator mit welchem man den geschätzten Datenverbrauch bei einer Graphite berechnen kann!
Damit einem also der Storage nicht unterm Arsch wegbrennt, gibt es die Data Retention .. das reduzieren oder ausdünnen von Datenpunkten.
Die Graphite kann das sogar dynamisch, man kann die Retention Konfiguration im späteren Verlauf anpassen und anschließend über den
bestehen Datenbestand jagen.
Bei der InfluxDB war es schon komplexer, ein abgestuftes Model einzurichten. Ich habe das leider nie verstanden und die
Dokumentation dazu war … naja, fragwürdig trifft es auch irgendwie.
Prometheus kennt nur genau 2 Wege:
- “Wie lange soll ich Daten aufheben?”, oder
- “Wie groß darf die Datenmenge werden?”
Darüber hinaus wird gnadenlos gelöscht. Nichts mit reduzieren oder ausdünnen … m(
Also, ‘welcome (back) InfluxDB’
Ich habe mich schweren Herzens dann doch für die InfluxDB in Version 2 entschieden.
Mir fehlt die Zeit und das Nervenkostüm mich mit all den Pythonabhängigkeiten herumzuschlagen, obwohl ich dass schon einmal in einem
Docker Container “eingesperrt” habe.
Datenmigration
DAS wird dann wohl der einzig richtig harte Bruch, bzw. deutlich komplizierter.
Wie bekomme ich jetzt die Bestandsdaten von A (Prometheus) nach B (InfluxDB)?
Die API von Version1 kannte ich ja bereits, die hatte ich bereits früher schonmal mit Python benutzt.
Das einzige Migrationstool, welches ich finden konnte, funktioniert auch nur mit Version 1 :(
Entweder, ich baue mir - mal wieder - etwas eigenes, oder das Internet spuckt mir doch noch etwas brauchbares vor die Füße.
Datenimport
Mitterlerweile habe ich meine Temperatursensoren erfolgreich von Prometheus auf Influx mitgriert. Das lief deutlich einfacher als ich es anfangs vermutet hatte.
Die ersten Imports von historischen Daten (z.B. die der Waage) sind bereits erfolgt.
Hier gab es anfangs nur Probleme mit den unterschiedlichen Zeitformaten.
Der Code ist nicht schön … funktioniert aber zufriedenstellend.
Und er wird meine Ausgangsbasis für den Import der Notify App sein.