Prometheus ist ein Open-Source-System zur Überwachung und Alarmierung, das Metriken von Anwendungen und Infrastrukturen sammelt und verarbeitet. Prometheus arbeitet nach dem Pull-Modell, d.h. es sendet regelmäßig HTTP-Anfragen, um Daten von konfigurierten Zielen abzurufen. Die gesammelten Daten werden lokal in einer benutzerdefinierten Datenbank gespeichert und können mit der Sprache PromQL abgefragt werden. Prometheus ist besonders effizient bei der Überwachung verteilter Systeme und optimiert für moderne Technologien wie Docker und Kubernetes.
Bild 1: Architektur von Prometheus mit Komponenten wie Client Libraries, Exporters, Service Discovery, Scraping, Storage, Dashboards, Recording Rules and Alerts, Alert Management und Long-Term Storage.
Anwendungen generieren Metriken meist nicht automatisch. Entwickler müssen eine Instrumentierung in den Code integrieren. Client Libraries vereinfachen diesen Prozess: Mit wenigen Codezeilen können Metriken definiert und direkt in den Code integriert werden – direkte Instrumentierung. Prometheus bietet Client Libraries für gängige Sprachen wie Go, Python, Java/JVM, Ruby und Rust. Drittanbieter bieten Bibliotheken für Sprachen wie C#/.Net, Node.js, Haskell und Erlang.
Nicht immer ist der Zugriff auf den Quellcode möglich, um Code einzufügen und direkte Instrumentierung durchzuführen. Exporter sind kleine Programme, die mit der zu überwachenden Anwendung installiert werden. Sie empfangen Anfragen von Prometheus, sammeln Daten von der Anwendung, konvertieren diese in ein Prometheus-verständliches Format und geben die Ergebnisse zurück. Exporter fungieren als Datenadapter zwischen Anwendung und Prometheus. Im Gegensatz zur direkten Integration mit Client Libraries verwenden Exporter Custom Collectors oder ConstMetrics.
Nach der Integration von Prometheus in Anwendungen und der Konfiguration von Exportern muss Prometheus wissen, wo sich Anwendungen und Exporter befinden, um sie zu überwachen. In dynamischen Umgebungen wie der Cloud können sich Dienste ständig ändern (erstellt oder gelöscht werden). Eine statische Liste von Anwendungen und Exportern wäre schnell veraltet. Daher benötigen wir Service Discovery. Prometheus integriert sich in gängige Service-Discovery-Mechanismen wie Kubernetes, EC2 und Consul und findet automatisch zu überwachende Anwendungen. Für Systeme ohne diese Dienste bietet Prometheus allgemeine Integrationsmethoden.
Bild 2: Service Discovery in Prometheus ermöglicht die automatische Erkennung und Überwachung von Diensten in dynamischen Umgebungen und sorgt für eine genaue und effiziente Datenerfassung.
Nachdem Prometheus über Service Discovery und Relabeling die Ziele identifiziert hat, ruft es Daten von diesen Zielen ab. Dazu sendet Prometheus HTTP-Anfragen, sogenannte Scrapes, um Metriken zu sammeln. Prometheus zeichnet dabei Informationen auf, z. B. ob der Scrape erfolgreich war und wie lange er dauerte. Scraping wird regelmäßig konfiguriert, in der Regel alle 10 bis 60 Sekunden pro Ziel. Prometheus verwendet das Pull-Modell, in dem es aktiv Daten von den Überwachungszielen abruft (im Gegensatz zum Push-Modell).
Prometheus speichert Daten direkt auf seinem Server mithilfe einer benutzerdefinierten Datenbank. Anstatt ein komplexes verteiltes Speichersystem zu entwickeln, wurde die lokale Speicherung gewählt, um den Betrieb einfacher und zuverlässiger zu gestalten. Die aktuelle Prometheus-Version 2.0 kann Millionen von Datenpunkten pro Sekunde erfassen und ist leistungsstark genug, um Tausende von Maschinen mit einem einzigen Prometheus-Server zu überwachen. Prometheus verwendet einen effizienten Komprimierungsalgorithmus mit einer Komprimierungsrate von 1,3 Byte pro Datenpunkt. SSDs werden für die Geschwindigkeit empfohlen, sind aber nicht zwingend erforderlich. Da Prometheus Daten nur lokal speichert, ist die Speicherkapazität durch die Festplattengröße begrenzt. Dies kann bei der Langzeitspeicherung problematisch sein. Prometheus bietet keine Clustered-Storage-Lösung. Die Remote-Read- und Remote-Write-APIs ermöglichen jedoch die Anbindung externer Speichersysteme. So können Daten sowohl lokal als auch remote abgefragt werden, ohne die Abfragemethoden zu ändern.