Neuer Ansatz mit Prometheus und OpenMetrics
Von Richard Hartmann, SpaceNet
Beim Monitoring ist es ein wenig wie beim Heimwerken: Keiner will einen 8er-Bohrer, die Leute wollen ein 8er-Loch. Genauso verhält es sich mit der Infrastruktur in Rechenzentren: Solange gerade alles funktioniert, interessiert es kaum jemand, warum es funktioniert oder wie lange noch. Tritt jedoch ein Fehler auf, muss sofort klar sein, warum er aufgetreten ist und wie er sich in Zukunft verhindern lässt. Die Kollegen aus dem Vertrieb würden zudem gerne wissen, wie viel Kapazität kurzfristig zur Verfügung steht. Und für Entscheider ist natürlich interessant, inwiefern sich Kosten sparen lassen und, falls ja, wie. All diese Anforderungen haben eins gemein: Die Notwendigkeit, frühzeitig Daten zu sammeln, zu speichern und möglichst automatisiert auswertbar zu machen.
Aus Mangel an Borgmon
Mit Nagios, Zabbix, LibreNMS und anderen existieren schon viele Monitoring-Lösungen für diese Aufgabe. Weshalb also noch eine? Warum den Aufwand für einen Umstieg in Kauf nehmen? Die Antwort gibt ein Blick auf die Entstehung von Prometheus: Initiiert wurde Prometheus von Ex-Mitarbeitern von Google, die zeitgleich zu SoundCloud wechselten. Dort vermissten sie schmerzlich das bis dahin geheime, Google-interne Monitoring Borgmon und dessen umfassende Möglichkeiten. Da es am Markt nichts Vergleichbares gab, entschlossen sie sich kurzerhand, Borgmon in ihrer Freizeit in weiten Teilen nachzubauen: Prometheus war geboren.
In der griechischen Mythologie entriss Prometheus den Göttern die Kontrolle über das Feuer und gab es den Menschen. Daran erkennt man auch den Selbstanspruch der Software. Nachdem innerhalb weniger Jahre mehr als 300 Projekte ihre Software zu Prometheus kompatibel gemacht hatten, als sogenannte Integrationen, und inzwischen Zehntausende Firmen mit Prometheus arbeiten, ist dieser Selbstanspruch offensichtlich zumindest teilweise erfüllt.
Schwarz auf Weiß
Dieser Beitrag erschien zuerst in unserer Magazinreihe „Rechenzentren und Infrastruktur“. Einen Überblick mit freien Download-Links zu sämtlichen Einzelheften bekommen Sie online im Pressezentrum des MittelstandsWiki.
Diese rasante Erfolgsgeschichte hat ihre Gründe, und RZ-Betreiber profitieren spürbar davon. Als Erstes ist die konsequente und komplette Automatisierung zu nennen, die eines der Kernziele von Prometheus darstellt. Das geht über das Hinzufügen von Datenquellen über deren Zuordnung bis hin zur Auswertung der Daten und der Ausleitung von Alarmen. Über die sogenannte Service Discovery können Datenquellen zum Beispiel per API direkt übergeben werden. Sind alle Datenquellen sauber im DNS gepflegt, kann Prometheus sich die Information über Datenquellen auch einfach mittels Zonentransfer abholen.
Die meisten Anwender starten üblicherweise aber mit file_sd; ein Shell-Skript holt dann die Quellen in Bestandssystemen ab und schreibt sie in eine Textdatei mit YAML oder JSON, Prometheus erledigt den Rest. Zum Testen lässt sich diese Textdatei auch von Hand innerhalb von Minuten erstellen.
Mehr Kontrolle durch Zeitreihendaten
Ein weiterer Pluspunkt ist das Datenmodell: Prometheus speichert Time Series und macht diese über Name Sets und Label Sets verfügbar. Time Series sind Zeitreihen, also numerische Werte, die sich über die Zeit verändern. Zum jeweiligen Wert speichert Prometheus den exakten Zeitpunkt, wann dieser aufgetreten ist. Klassischerweise würden diese Daten in anderen Systemen in SQL-Tabellen gespeichert werden, was die Handhabung aber unnötig kompliziert macht. Es gibt nicht eine Tabelle mit vielen verschiedenen Daten; jede Zeitreihe ist für sich gekapselt und dadurch leichter weiterzuverarbeiten.
Damit können alle Daten vom Netzwerkdurchsatz über Temperaturen oder Ampere-Werte in einem Rack bis hin zum Füllstand des Dieseltanks gespeichert werden. Daten, die nur als Text vorliegen, werden dabei in Zahlen umgeschrieben. Aus „Battery OK“ wird also zum Beispiel eine 1, aus „Battery missing“ eine 0 und so weiter. Diese bewusste Reduktion ermöglicht eine extrem effiziente Datenspeicherung. Die Daten werden auf ein Zwölftel reduziert, die Kompression kostet dabei nur rund 3 % CPU-Zeit. Auf einem durchschnittlichen Server lassen sich leicht 100.000 Werte pro Sekunde speichern, und das über viele Jahre hinweg. Auf leistungsstarken Servern sind auch 1.000.000 Werte pro Sekunde kein Problem.
Top Ten der höchsten Auslasstemperaturen an Rack-Sensoren eines Clusters; schön zu sehen, wie die Last steigt, auch wenn nicht alle Sensoren exakt in Relation zu den Auslässen positioniert sind. (Bild: Richard Hartmann)
In klassischen Monitoring-Systemen sind Daten hierarchisch abgelegt, also zum Beispiel Land: Stadt: Rechenzentrum: Stockwerk: Raum: Cage: Rack-Reihe: Rack: Kunde. Wenn ein Kunde ein Rack, der andere Kunde einen Cage mietet, stößt dieses System allerdings schon an seine Grenzen. Schlimmer noch: Ein Kunde, der sich seine Racks eincagen lässt oder einen zweiten Raum dazukauft, zwingt den Administrator oft dazu, Daten händisch umzusortieren.
Prometheus geht mit den erwähnten Label Sets einen anderen Weg: Diese Key Value Pairs können an beliebige Time Series angehängt werden, site="SDC", rack="123", und customer="4711" sind gleichberechtigt mit den jeweiligen Daten verknüpft. Die Namen und Label Sets bauen also dynamisch eine n-dimensionale Matrix auf, aus der beliebig selektiert werden kann.
Möglichkeiten der Abfrage per PromQL
Damit sind wir auch schon beim nächsten Vorteil von Prometheus, der Abfragesprache PromQL. Bei PromQL handelt es sich um eine turing-vollständige, funktionale Sprache für Vektormathematik mit mehr oder weniger magischem Label Matching, die speziell für Prometheus entwickelt wurde. Die Sprache ist also sehr mächtig, aber trotzdem sehr kompakt zu schreiben.
Ein Vektor ist eine Aneinanderreihung von Daten. Eine Time Series lässt sich also als Vektor begreifen. Vektormathematik erlaubt es, Formeln zu schreiben, bei denen es nicht darauf ankommt, ob mit Einzelwerten oder Hunderttausenden von Datenpunkten gearbeitet wird. Ohne Umwege über Schleifen, Zwischenwerte oder andere Konstrukte kann so direkt mit den Daten gearbeitet werden.
Meist werden aus Systemen Absolutwerte ausgelesen, PromQL macht mit rate() aus den Absolutwerten einfach Verlaufswerte von „X pro Sekunde“. Ein Beispiel: Aus den üblichen Joule aus Stromzählern werden etwa mit rate(dc_power_consumption_joule[5m]) Watt im Mittel der letzten fünf Minuten, um Verbrauchsdauer erweitert auch Kilowattstunden zur Abrechnung. Falls sich die Absolutwerte, zum Beispiel durch Neustart eines Messgeräts, auf null zurücksetzen, erkennt PromQL dies und passt die Berechnung entsprechend an. Damit gehört das Ausfiltern oder, schlimmer noch, das Ausweisen negativer Verbrauchswerte in der Abrechnung des Kunden der Vergangenheit an.
Label Matching sorgt im Hintergrund dafür, dass die Daten über Label Sets automatisch zu sinnvollen Gruppen zusammengefasst werden. sum(rate(dc_power_consumption_joule[5m])) liefert also den gesamten Stromverbrauch eines RZ-Betreibers, sum(rate(dc_power_consumption_joule{customer="4711"}[5m]))
den Verbrauch des Kunden 4711, und sum(rate(dc_power_consumption_joule{site="SDC"}[5m]))<den Verbrauch für den Standort SDC.
Speicherauslastung eines Ceph Clusters, einmal nach verwendeter Kapazität, einmal als prozentuale Restkapazität. (Bild: Richard Hartmann)
Daten können aber auch nach Labels zusammengefasst werden. So bekommt der Benutzer mit sum(rate(dc_power_consumption_joule[5m])) by (customer) eine Übersicht sämtlicher Kunden. Alle Kunden an einem Standort erhält er mit sum(rate(dc_power_consumption_joule{site="SDC"}[5m])) by (customer) und mit sum(rate(dc_power_consumption_joule[5m])) by (site,customer) bekommt er sie aufgeschlüsselt nach Kunde und Standort. Dank der Vektormathematik spielt es dabei keine Rolle, ob der aktuelle Wert, alle Werte, oder ein beliebiger Zeitraum betrachtet werden sollen.
Unabhängig davon, ob Benutzer sich die Daten von Prometheus als Tabelle, Graph oder vielleicht sogar mit anderen Tools wie Grafana anzeigen lassen: Im Hintergrund wird immer PromQL empfangen und JSON ausgeliefert. Mit curl http://127.0.0.1::9090/api/v1/query_range?query=sum(rate(dc_power_consumption_joule[5m])) können die Daten also beliebig wieder in eigene Tools überführt werden, mit curl http://127.0.0.1::9090/api/v1/query_range?query=sum(rate(dc_power_consumption_joule[5m]))&start=1535025991.911&end=1535630791.911&step=2419&_=1535630750894 die Werte der letzten Woche zum Zeitpunkt der Erstellung des Artikels und so weiter und so fort.
Recording Rules und Alarme mit PromQL
Nicht nur Datenabfrage und -export, auch die Generierung von neuen Daten funktioniert via PromQL. Mit sogenannten Recording Rules können oft durchgeführte Abfragen vorberechnet abgespeichert werden. Prometheus führt diese Abfragen eigenständig an sich selbst durch und speichert die Daten wieder als Time Series. Aus sum(rate(dc_power_consumption_joule[5m])) by (customer) ist dann customer:dc_power_consumption_watt:sum_5m geworden.
Alarme funktionieren ähnlich wie Recording Rules. Kommen bei einer Abfrage Ergebnisse zurück, werden diese zur späteren Auswertung als Time Series gespeichert und ein Alarm wird weitergegeben. dc_ups_battery_ok != 1 reicht bereits aus, um jede Batterie inklusive der automatischen Angaben über Standort, USV und so weiter aktiv zu überwachen, sum(dc_diesel_liter) by (site) < 1000 ist selbsterklärend. PromQL kann aber noch mehr. dc_ups_feed_wattage / dc_ups_feed_wattage_total > 0.9 warnt, wenn ein Feed einer USV mehr als 90 % Last hat, avg_over_time(dc_temperature_celsius{group="cold_aisle"}[5m]) by (site,room,cage,row) < 26 > 20 stellt sicher, dass die Temperaturen im Rahmen bleiben.
Im Echtbetrieb sind harte Werte jedoch zu unflexibel. Es empfiehlt sich daher, Time Series für dc_temperature_lower_warning_celsius, dc_temperature_upper_critical_celsius und so weiter auszuleiten. Damit ist es dann auch möglich, unterschiedliche Schwellenwerte für bestimmte Orte zu vergeben.
Selbst die Berechnung von ausgesprochen kritischen Werten wie dem Taupunkt am Arbeitsplatz des Autors mit den Messwerten des Umweltdatensensors BME280, gefunkt via ESP32, lässt sich rein in PromQL umsetzen – auch wenn dies zugegebenermaßen ein bisschen länger dauert. Im Nachbarzimmer überwacht ein Kollege mit vergleichbarem Setup, wann die Zimmerpflanzen nachzugießen sind. Der MQ135 überwacht die Luftqualität und entlarvt jeden Vaper.
Und PromQL kann noch mehr. Eine statische Analyse mit exponentieller Glättung via holt_winters() erlaubt es, Trends von kurz- und langfristigen Schwankungen zu befreien und damit Aussagen über die wirkliche Entwicklung von Messwerten zu treffen. Und so angenehm es ist, zu wissen, ob noch mindestens 1000 l Diesel pro Site verfügbar sind, mit predict_linear(dc_diesel_liter[1h], 72 * 3600) < 0 lässt sich auch direkt berechnen, ob, basierend auf den Verbrauchswerten der letzten Stunde, noch mindestens Diesel für drei Tage vorhanden ist.
Durch die Zugrundelegung von echten Messwerten sind auch Mehrverbräuche durch eine undichte Leitung oder andere unwahrscheinliche Fälle abgedeckt. Da eine Katastrophe meist entsteht, wenn mehrere Fehler zusammenkommen, wurde PromQL entwickelt, um auf verschiedenen Ebenen zeitgleich und ganzheitlich auszuwerten.
OpenMetrics als nächster Schritt
Wie erwähnt, gibt es bereits jetzt über 300 Integrationen für Prometheus. Bei den klassischen Herstellern, und dazu gehören die Hersteller von RZ-Komponenten definitiv, mahlen die Mühlen aber langsamer. Daher existieren bereits sogenannte Exporter, die Daten aus fast beliebigen Formaten in das Prometheus-Format umschreiben, sei es von SNMP, Modbus, CAN-Bus oder anderen. Auch das Umschreiben per eigenem Skript ist nahezu trivial und jedem Leser dieses Artikels bereits jetzt möglich. Eine Textdatei via HTTP oder HTTPS die Folgendes enthält:
dc_power_consumption_joule{site="SDC",room="201",rack="123"customer="4711"} 123456
dc_power_consumption_joule{site="SDC",room="201",rack="124"customer="4712"} 234567
ist zwar minimal, aber dennoch valides Prometheus Exposition Format.
Trotzdem wäre es wünschenswert, Daten direkt aus den Systemen oder der Gebäudeleittechnik ausleiten zu können. Hier kommt OpenMetrics ins Spiel.
Der Autor hat auf Basis des Prometheus Exposition Formats OpenMetrics ins Leben gerufen, um einen offenen Standard zu schaffen, der nicht an ein bestimmtes Projekt gebunden ist. OpenMetrics hat weiterhin den Anspruch, nicht nur im Cloud-native-Umfeld, sondern in der gesamten IT Fuß zu fassen. So lassen sich Messdaten unterschiedlicher Bereiche schnell und einfach ohne Umwege zueinander in Beziehung zu setzen. Ziel ist es nicht nur, ein RFC zu veröffentlichen, sondern auch Referenzimplementierungen und eine komplette Test Suite zur Verfügung zu stellen. Bereits jetzt haben mehrere Firmen und Projekte die Umsetzung von OpenMetrics zugesagt. Die Hauptarbeit wird allerdings von einem kleinen Kreis getragen; im Wesentlichen von ein paar Prometheus-Mitgliedern sowie Google und Uber.
Seit August 2018 ist OpenMetrics, so wie Prometheus, unter dem Schirm der Cloud Native Computing Foundation (CNCF), einer Tochter der Linux Foundation organisiert. Die CNCF stellt durch ihre Reichweite die Adoption auch von Hardware-Herstellern sicher.
Richard Hartmann ist Systemarchitekt und Projektleiter bei der SpaceNet AG, außerdem Teammitglied der Prometheus-Entwicklergemeinde sowie Initiator und treibende Kraft hinter OpenMetrics. Das Projekt gibt es zwar erst seit 2017, doch bereits rund ein Jahr später, am 10. August 2018 erhob die Cloud Native Computing Foundation auf der PromCon in München das Mutterprojekt Prometheus in den Status Graduation und nahm zugleich OpenMetrics in die Sandbox auf. Zu den Beiträgern der OpenMetrics-Entwicklung gehören Sysdig, OpenCensus, Google und Uber sowie AppOptics, Cortex, Datadog, InfluxData und eben Prometheus.
SpaceNet AG, Joseph-Dollinger-Bogen 14, 80807 München, Tel.: 089-32356-0, info@space.net, www.space.net
