Damit Sie als Admin stets über alle Parameter Ihrer IT Bescheid wissen, befasst sich IT-Administrator im Juni mit dem Schwerpunkt 'Monitoring'. Darin lesen Sie ... (mehr)

Storage auf lokalem Speicher

Weil die Hauptaufgabe des Prometheus-Servers darin besteht, eingehende Daten sinnvoll abzuspeichern, ist der größte Teil der in Go geschriebenen Komponente dieser Aufgabe gewidmet. Wer sich mit skalierbaren Lösungen schon ausgiebig beschäftigt hat, stolpert hier über eine Ungereimtheit: Der Prometheus-Server nutzt nämlich keine verteilte Speicherlösung im Hintergrund. Die Metrikdaten, die ein Prometheus-Server einsammelt, speichert er anschließend lokal ab. Hier setzt Prometheus auf LevelDB, um die in ihm abgelegten Daten zu indexieren. Für das Ablegen der Nutzdaten verwendet es ein eigenes Format.

Das Beharren auf lokalem Speicher stößt sauer auf, weil Prometheus auf diese Weise nur begrenzt in die Breite skalieren kann. Die Open Time Series Database OpenTSDB böte zwar entsprechende Funktionalität. Doch gerade die haben die Entwickler von Prometheus ja für ihre Lösung ausgeschlossen, weil sie ihnen zu schwierig in der Handhabung war. So sehen sich Prometheus-Admins aktuell mit einer hässlichen Skalierbarkeitsgrenze konfrontiert: Bis zu 1000 Knoten sollen sich mit einer einzelnen Instanz des Prometheus-Servers problemlos nutzen lassen. Wer mehr braucht, greift zu einem Ansatz, der mit dem Sharding von E-Mail-Servern gewisse Ähnlichkeit hat: Dabei gibt es viele Prometheus-Server, die einzelne Teilbereiche des Setups überwachen. In einer solchen Lösung hat der Admin allerdings nicht mehr den Vorteil, dass er nur ein Frontend für sein Monitoring hat. Stattdessen muss er unterschiedliche Prometheus-Server in Abhängigkeit der Daten abfragen, die er gerade sehen möchte. Wenigstens kann er aber das Federation-Feature von Prometheus nutzen, um zwischen den Servern des Set-ups eine Synchronisation für Teile der Daten zu erreichen.

Bild 3: Diverse Exporter von Drittanbietern finden sich im Netz bereits, etwa zum Überwachen von MongoDB.

Auf die Möglichkeit, mehrere Prometheus-Server für Hochverfügbarkeit zu betreiben, hat das Storage-Thema keine Auswirkung. Natürlich lassen sich viele Prometheus-Server gleichzeitig nutzen, die dieselben Metrik-Daten aus dem Set-up sammeln und entsprechend speichern. Nur das Skalieren in die Breite, um die Gesamtlast auf viele Knoten zu verteilen, ist in Prometheus aktuell ein großes Problem, weil zwischen den einzelnen Prometheus-Servern einfach keine sinnvolle Datenreplikation stattfindet, auch nicht mit Federation.

 PromQL als SQL-Verschnitt

Damit das Monitoring dem Admin hilft, muss er bei Bedarf Daten auch wieder aus ihm herauskriegen. Metrik-Daten helfen beispielsweise nur, wenn sie sich auch grafisch ansprechend darstellen lassen. Für diesen Zweck hat der Server von Prometheus eine HTTP-basierte API nach dem REST-Prinzip. Mittels einer eigens für diesen Zweck erfundenen Query-Sprache namens PromQL lassen sich die Werte von dort problemlos auslesen. PromQL ähnelt in vielerlei Hinsicht tatsächlich der Syntax von SQL. Auch Admins, die sattelfest in Sachen SQL sind, werden aber nicht um die Lektüre der PromQL-Dokumentation [2] herumkommen.

Nun da die wesentlichen Aufgaben des Prometheus-Servers soweit klar sind, steht eine weitere Frage im Fokus: Woher bekommen die Prometheus-Server denn nun ganz konkret ihre Daten? Es leuchtet ein, dass der Admin am Ende nicht beim Prometheus-Server selbst etwa einträgt, er wollte von Dienst X auf Maschine Y regelmäßig Messwerte empfangen. Denn das würde bei einer größeren Anzahl von Knoten im Cluster kaum sinnvoll skalieren. Stattdessen setzt Prometheus auf eine Kombination von automatischer Dienste-Erkennung und Agenten, die auf den einzelnen Servern laufen und Prometheus als Anlaufstelle für den Host dienen.

Bei der automatischen Diensterkennung setzt Prometheus auf vorhandene Dienste wie DNS, Kubernetes oder Consul. Anhand bestimmter DNS-Einträge erkennt ein Prometheus-Server genauso zu überwachende Systeme wie anhand der Informationen aus der Container-Verwaltung Kubernetes oder dem State-Monitor Consul. Ist ein Server Teil eines Consul-Clusters und Prometheus direkt mit dem Consul-Cluster verbunden, erfährt er von dort, dass der jeweilige Server zu überwachen ist. Konkrete Informationen über die Dienste des Servers bekommt Prometheus hier aber noch nicht. Dafür sind die Agenten zuständig, die auf jedem Host laufen und im Prometheus-Sprech "Exporter" heißen.

Die Bezeichnung Exporter mag im ersten Augenblick etwas verwirren, doch sie weist letztlich wieder auf das Pull-Prinzip des Prometheus-Servers hin: Die Exporter auf den Hosts sammeln die relevanten Metriken ein und bieten sie dem Prometheus-Server zum Download an. Auf einem Host können viele Exporter gleichzeitig laufen. Prometheus selbst steuert mehrere Exporter bei: Der "Node Exporter" etwa liest die grundlegenden Systemwerte wie CPU-Last und Speichernutzung aus. Andere spezifische Exporter können etwa den Status von einzelnen Diensten überwachen und beispielsweise prüfen, ob Apache läuft oder nicht. In gewisser Weise lassen sich Exporter also mit den einzelnen Checks aus Nagios vergleichen, auch wenn sie deutlich potenter sind und mehr Infos an Prometheus liefern.

Prometheus bietet auch eine Lösung für Dienste an, die zu Monitoring-Zwecken ihre eigenen Metrik-Daten zwangsweise per Push-Prinzip verteilen: Hier nutzt der Admin das Prometheus-Pushgateway, das einerseits eingehende Daten annimmt und andererseits eine Schnittstelle zum Prometheus-Server besitzt. Ist Prometheus richtig konfiguriert, wird durch die Kombination aus Server und Exportern das Hinzufügen neuer Knoten zum Setup ein Kinderspiel: Sobald der Server Teil des Kubernetes- oder Consul-Clusters ist, identifiziert der Prometheus-Server ihn als Monitoring-Ziel. Die auf dem neuen Server idealerweise per Ansible & Co. ausgerollten Exporter stellen automatisch die benötigten Daten bereit. Das manuelle Editieren von Konfigurationsdateien entfällt vollständig (Bild 3).

comments powered by Disqus

Artikel der Woche

Eigene Registry für Docker-Images

Wer selber Docker-Images herstellt, braucht auch eine eigene Registry. Diese gibt es ebenfalls als Docker-Image, aber nur mit eingeschränkter Funktionalität. Mit einem Auth-Server wird daraus ein brauchbares Repository für Images. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2021