 Dann herzlich willkommen zu meinem Vortrag. Der Titel lautet Monitoring mit Prometheus. Im Englischen würde man Prometheus sagen und die ganze Dokumentation und dergleichen ist auf Englisch, aber ich wähle mal die deutsche Aussprache für heute. Zunächst würde ich gerne in die Runde fragen, wer von euch denn schon irgendeine Art von Monitoring oder Alertingsystem einsetzt. Das ist gut die Hälfte, ein bisschen mehr als die Hälfte. Dann bleibt nur noch zu sagen, mein Name ist Michael Stapelberg und mit diesem Vortrag geht es folgendermaßen los. Zunächst beleucht ich ein bisschen den Hintergrund, den ich habe zu Prometheus. Dann machen wir gleich ganz am Anfang ein Anfang bis Ende Beispiel durch. Also ein ganz kleines Go-Programm habe ich vorbereitet, welches wir mit Monitoring ausstatten werden. Damit ihr einfach mal seht, wie sich die Software so anfühlt, damit ihr ein besseres Verständnis bekommt. Und erst danach werde ich euch erklären, was denn für Datentypen unterstützt werden und was Labels, Rules und Alerts usw. sind. Wir werden natürlich auch darauf eingehen, wie man Drittsoft wäre, also welche, die ihr nicht selber geschrieben habt oder selber unter Kontrolle habt mit Monitoring ausstattet. Da gibt es die sogenannten Exporter. Und dann schauen wir uns ein paar Rules an und sprechen kurz über Alertingphilosophie und dann zeige ich auch noch, wie man der Sports zusammenstellt auf Basis von Prometheus. Zunächst zum Hintergrund. Persönlich habe ich bei Prometheus nicht signifikant mitgearbeitet. Ich habe den einen oder anderen Pull Request tatsächlich beigesteuert, aber das ist keine Software von mir. Das ist unüblich für mich auf Konferenzen, aber ich stelle es trotzdem sehr gerne vor, einfach weil ich die Software sehr gerne mag. Jetzt muss man aber dazu sagen, Prometheus habe ich erst vor circa einem Jahr kennengelernt. Zu dem Zeitpunkt gab es das schon für ein paar Jahre. Mein Hintergrund ist, dass ich nicht mit Prometheus selber sozusagen groß geworden bin, sondern es gibt Borg und Borgmon. Borg ist ein Schedulingsystem bei Google, mit dem Millionen von Containern tagtäglich verwaltet werden und auf Computer verteilt werden. Wer es noch nichts von Borg gehört hat, der ist herzlich dazu eingeladen, sich das Paper durchzulesen, was auf der Folie verlinkt ist, das ist ein Superpaper. Ich würde es jedem ans Herz legen. Für Borg gibt es ein Monitoring-System namens Borgmon. Das funktioniert ganz ähnlich wie Prometheus. Mit Borgmon habe ich viel Erfahrung und mit Prometheus mittlerweile auch über einen Jahr, deswegen denke ich, dass ich in der Lage bin, diesen Vortrag zu halten. Prometheus wurde damals von Matt Prout und Julius Volz geschrieben. Die beiden hatten früher bei Google gearbeitet, sind dann aber gegangen und deswegen auch diese starke Ähnlichkeit. Das ist durchaus davon inspiriert, genauso wie beispielsweise H-Base, die diese offene verteilte Datenbankgeschichte auch von Bigtable inspiriert wurde und noch eben so weitere Open Source Projekte. Also Prometheus ist da ein weiteres in der Liste. Und Matt Prout ist dann aber zu Soundcloud gegangen und Julius auch und das Projekt ist dann quasi zu Soundcloud gekommen dadurch. Und Soundcloud entwickelt das auch weiter, mittlerweile aber auch ein paar andere Firmen. Also Docker ist da auch recht früh auf den Zug aufgesprungen und es gibt jetzt Contributions von allerlei verschiedenen Firmen, die gerne Open Source Software benutzen und weiterentwickeln. Es ist tatsächlich sogar so, dass es einige Leute gibt in der Prometheus Community, die mittlerweile sich da so darauf konzentriert haben, dass sie in eine eigene Consulting-Firma gegründet haben und jetzt wirklich hauptberuflich Prometheus machen. Also da ist ein Haufen Momentum dahinter und es sieht so aus, als würde es massiv wachsen. Meiner Meinung nach ist das ganze System, also das Ökosystem Prometheus selber und die anderen Komponenten, die da mitkommen und die Sachen, die Leute so entwickeln, eine Superlösung für Monitoring und Alerting und signifikant besser als alles, was ich vorher in der Open Source Szene gesehen habe. Gut, um vielleicht kurz ein bisschen die Szene zu setzen sozusagen, das Szenario, mit dem ich verstehe, wie solche Systeme funktionieren, ist, ich habe ein verteiltes System, welches aus vielen verschiedenen HTP-Servants besteht. In meinem Fall konkret ist das zum Beispiel Debian Code Search, was ich entwickelt habe, oder Robust IRC, worüber ich schon vorhin einen Vortrag gehalten hatte, den könnt ihr gerne nachsehen, wenn ihr ihn verpasst habt. Das sind beide Systeme, die bestehen aus verschiedenen Computern, die zu einem verteilten System zusammengefasst sind und jeder Computer hat einen Server am Laufen, der einen HTP-Server bereitstellt. Die Motivation war jetzt, dass man den Zustand des Systems aggregieren möchte, weil man kann sich zwar bei kleinen Systemen auf jedem einzelnen Knoten einloggen und dann irgendwie schauen, so mit PS und Top und Logfiles anschauen und vielleicht sogar GDB oder sowas, was das System eigentlich gerade macht, aber sobald man eine gewisse Grenze überschreitet, ist das unhandlich, das zu machen. Also man möchte dann, um Trends zu erkennen, vielleicht lieber auf Grafen schauen. Also statt, dass man sich in sieben Computer einloggt und überall DF-H eintippt, um den Festplattenbelegungszustand zu sehen, möchte man vielleicht einen Graf haben mit sieben Linien und wenn man dann sieht, eine geht nach oben, dann weiß man gleich, was da passiert ist. Damit man den Zustand des Systems so aggregieren und speichern kann, damit man ihn auch in der Vergangenheit, also die vergangenen Werte anschauen kann, gibt es diese Idee, dass man einfach Counter einfügt, also einfach Zählervariablen. Man könnte zum Beispiel sagen, ich habe eine Zählervariable für HDTP-Requests, die erfolgreich waren und welche, die fehlgeschlagen sind. Oder eben auch Variablen, die einfach sagen, wir den freien Festplattenspeicher enthalten und die exportiert man dann einfach über HDTP. Und den Link, den ich hier reingepackt habe, ist auf das Exvar-Package, also exported variable in go, was einfach so ein Key-Value-Format ist, was man recht leicht importieren kann und dann kriegt man sowas. Und wozu das nützlich ist, ist zum einen um Ausfälle zu debaggen, also man kann sich quasi interessante Informationen präparieren, speichern lassen und dann auf Wunsch abrufen. Aber auch, weil alles, was man sich selber anschauen kann und selber debaggen kann, kann man auch dem Computer beibringen, zu einem gewissen Grad, auch um Alertings zu haben bei Problemen, also um wieder auf das Festplattenspeicher-Problem zurückzukommen. Man könnte zum Beispiel sagen, wenn der freie Speicher nur noch, sagen wir, weniger als 1 Gigabyte ist, dann möchte ich einen Alert bekommen und dann kann nicht der Computer darüber informieren. Soweit so gut. Jetzt fangen wir also gleich mit dem Beispiel an, wie angekündigt. Was ihr hier auf der Folie seht, ist der komplette Quelltext von einem HDTP-Server in go implementiert. Es ist nicht so wichtig, wenn ihr noch nichts mit go gemacht habt. Ihr müsst es nicht on-detail verstehen. Das Einzige, was ich kurz illustrieren möchte, ist, es gibt hier einen HDTP-Händler für Slash Search. Und was der macht, wenn er aufgerufen wird, ist, er gibt einfach Ohai aus. Danach sagt man noch, auf welchem Port der Server laufen soll und das war es dann auch schon. Und alles, was ich jetzt tun muss, um so ein simples Programm mit Prometheus Monitoring auszustatten, ist ein bisschen Boilerplate sozusagen, also Einführung. Ich werde zunächst das Prometheus Klein Package importieren ganz oben. Ich werde dann definieren, dass es hier einen neuen Counter gibt für die Queries. Also, das Szenario ist jetzt, wir möchten einfach mal schauen, wie viele Queries kommen denn da so rein, pro Sekunde oder sowas. Dafür definieren wir hier diesen Counter, sagen, der Name ist Queries und geben auch einen Hilfe Text an. Der Hilfe Text ist tatsächlich notwendig für jede Metrik, die ihr mit Prometheus exportiert, was auf jeden Fall auch eine sehr gute Idee ist, weil ihr dann einfach schon implizit Dokumentation habt darüber zumindest auf dieser Ebene. Dann in der Innetfunktion, die von go automatisch aufgerufen wird, bevor die Mainfunktion losläuft, registriert man die soeben angelegte Metrik mit Prometheus und in dem HTTP-Händler an sich, sagt man dann einfach Queries.inc für Increment, da wird der Zähler also um eins erhöht und zusätzlich exportiert man diese Metriken auch, indem man sagt, der Slashmetrics Endpoint, was eine wohl definierte URL in Prometheus ist, wird vom Prometheus-Händler abgehandelt. So, kommen wir also zur Demo. Jetzt die Demo ist in drei Schritte unterteilt. Das erste ist Prometheus-Starten. Dann werden wir das Target einrichten und dann die Metrik interaktiv abfragen. Was ich zuerst noch kurz mache, Entschuldigung, da mache ich mal kurz ein größeres Stift. Okay, das ist besser. Zunächst habe ich hier die Demo-Datei nochmal, nur um zu demonstrieren, dass das wirklich auch genau das ist, was ich auf der Folie hatte, also das habt ihr gerade schon gesehen. Wenn ich hier sage, Go Run Demo, dann gibt er keine Ausgabe, aber er läuft. Ich kann das kurz verifizieren, Localhost 8080. Hier sieht man zuerst mal Slash, habe ich nicht definiert, als Händler, aber wenn ich auf Slash Search gehe, dann sehe ich tatsächlich die Antwort Ohai. Jetzt interessiert es vielleicht manche schon, was passiert eigentlich, wenn ich den Metrics Endpoint im Browser aufrufe und was passiert ist, dass man hier so einen Key-Value-Format bekommt, ganz ähnlich wie das X-Bar-Package, was ich hier schon hatte. Man sieht hier jeweils den Hilfe-Text, man sieht auch, dass da noch ein Type dabei ist und wenn wir jetzt hier ganz nach unten scrollen, dann sehen wir auch die Metrik, die wir gerade eben definiert hatten. Ich zoom hier mal ein bisschen rein, damit man das auch sehen kann. Hier steht also Type Counter und der Hilfe-Text, den wir definiert hatten und Query steht auf 1. Wenn ich jetzt also die Seite nehme und nochmal auf Search gehe, dann sieht man, dass Query jetzt hier auf 2 steht und wenn ich das noch ein paar mal mache, dann sind die ganzen anderen Metriken, die ich jetzt nicht explizit definiert habe, sind Metriken, die Prometheus einem schon automatisch zur Verfügung stellt. Das sind so Sachen wie die Anzahl an File Descriptorn, die Bytes, die belegt sind, die noch frei sind, die Anzahl an Sekunden bzw. der Unix-Time-Stamp, wann der Prozess gestartet ist. Lauter solche Sachen, die früher oder später gegebenenfalls interessant sind, wenn sie nicht interessant sind, kann man sie auch einfach ignorieren. Das ist ein Programm und jetzt können wir Prometheus selber starten. Ich benutze sehr gerne Docker dafür, ganz einfach, weil ich mich dann um nichts kümmern muss. Also ich muss Prometheus nicht runterladen, kompilieren oder darauf warten, dass meine Distro den bekommt. Ich kann einfach direkt von Prometheus die Stellen, das Docker-Paket oder den Docker-Container zur Verfügung, den kann ich einfach starten. Und wie man sieht, ich hatte den schon runtergeladen und der startet dann einfach. Soweit so gut. Das ist der, der auf Port 9090 verfügbar sein soll, damit wir den auch benutzen können. So, jetzt komme ich erstmal hier auf diese Startseite. Ich klick hier aber mal auf Status. Die gehen wir mal zuerst durch. Hier sieht man erstmal ein paar grundlegende Informationen über die Prometheus-Version, die ich jetzt am Laufen habe. Man sieht, die wurde mit Go 1.5 kompiliert am 3.3. Man sieht die Konfigurationsdatei. Das ist einfach die Standardkonfiguration, weil ich ja noch nichts eingestellt habe. Dann sieht man Rules, das ist leer. Man sieht Targets und Startup Flags. Die Flags sind einfach die Kommando-Zeilen-Parameter nochmal hier auf der Startseite gelistet. Und die Targets, das sind alle Endpunkte, die Prometheus kennt, die er also regelmäßig abfragt und von denen er die Metriken sich holt. Man sieht jetzt hier, dass der Standard-Endpunkt, der konfiguriert ist, localhost 9090 ist. Das heißt also, in ein Prometheus, was man einfach so aufstattet, monitort sich einfach selber erstmal standardmäßig. So, soweit so gut. Jetzt möchten wir also eine Konfigurationsdatei erstellen. Ich mache dafür hier mal ein neues Directory und gehe hier in eine Prometheus.conf. Wir klauen uns einfach mal die Standardkonfiguration. Die funktioniert ja offensichtlich. Das ist also ein guter Startpunkt. Hauen die hier rein. Jetzt gehen wir hier wieder zurück, sagen Docker, dass temp.prom auf slash Prometheus gemapped werden soll. Und dann geben wir noch den Parameter an config.file und sagen eben, wo er unsere Konfig findet. Soweit so gut, refresh, kommt immer noch genau das gleiche. Soweit klar, weil wir haben noch nichts geändert. Jetzt gehen wir also nochmal in unser Konfig-File und sagen, statt localhost nehmen wir jetzt hier die IP-Adresse von meinem Computer und sagen 8080. Da läuft er unsere Demo. Auch noch auf er hat Demo. Und dann sehen wir schon mal, okay, hier hat sich das geändert. Und hier unten sieht man das erst mal StateUnknown. Da ist noch kein Scrape-Intervall abgelaufen, er hat also noch nicht geschaut, wie die Metriken so sind. Wenn ich jetzt refreshe, sieht man, okay, State ist auf abgegangen. Das heißt, er konnte das zu monitorende Ziel erreichen. Er zeigt auch an, wann er da zuletzt vorbeigekommen ist. Und wenn ich da zum Beispiel ein Typo drin hätte oder der Server down wäre, dann hätte ich den. Soweit so gut. Jetzt haben wir also die Konfiguration soweit parat gemacht. Und jetzt können wir hier nochmal zurückgehen auf die Seite, mit der er uns eigentlich begrüßt hat. Hier sieht man jetzt zum Beispiel dieses Expression-Feld. Da kann man einfach einen Ausdruck eingeben. Das ist jetzt vielleicht ein bisschen abstrakt, aber ein Ausdruck kann sowas einfach sein, wie die Metrik, die wir gerade definiert haben. Und da gibt es auch dieses Drop-Down-Menü hierfür, wo man die einfach alle auswählen kann. Und man sieht hier, da hatte hier eine Time-Series definiert, die einfach Queries heißt und die noch ein paar Labels hat. Dazu alles gleich mehr. Die steht derzeit auf dem Wert 8. Wenn wir nochmal hier zurückgehen, dann sehen wir, okay, 8, das ist genau das, wie es hier exportiert wurde, soweit so gut alles wie erwartet. Man kann sich das jetzt auch als Graf anzeigen lassen. Das ist jetzt aber noch super langweilig, weil es einfach ein Datenpunkt drin, der steht auf 8. Hier steht das Queries auf 21. Und jetzt kann ich hier nochmal refreshen. Und jetzt sieht man hier auch, okay, der Graf geht von 8 hoch auf die 21. Genau, hier sieht man's. Das Standard Scraping-Interval ist eingestellt auf alle 5 Sekunden. Das will man vielleicht anpassen, das ist mehr oder weniger wird je nachdem, wie geschäftig die eigenen Web-Server sind. Okay, so viel erstmal dazu. Ich denke, jetzt haben wir ja schon mal erstmal eine ganz gute, grobe Idee, wie sich das so anfühlt. Und jetzt können wir uns das in detail anschauen. Als Überblick würde ich vielleicht versuchen, Prometheus folgendermaßen zu definieren. Prometheus ist ein Programm, welches Metriken sammelt und daraus Time Series generiert und speichert. Das ist super nützlich für interaktive Anwendungen, zum Beispiel für Dashboards und Queries, so wie wir es gerade gemacht haben. Man kann sich einfach ein Graf generieren lassen, um zu definieren, wie es sich um die sehr beliebigen Werten, die man vorher definiert. Man kann aber auch Alerting Rules definieren, also so was wie automatische Queries sozusagen, die auf bestimmte Vergleiche machen, zum Beispiel schauen, ob eine gewisse Schwellwerte überschritten wurde. Und dann gibt es eine zusätzliche Komponente, die man separat noch laufen lassen muss, namens Alertmanager. Und Prometheus kann dann diese Alerts an den Alertmanager schicken. Und der wiederum ist dafür zuständig, dass man ganz haltmodisch E-Mail, IRC, Slack, was auch immer. Das ist alles im Alertmanager integriert. Was ich noch interessant finde und wichtig zu erwähnen, ist, dass Prometheus stabil und standalone ist. Und ich habe in Klammern dazu geschrieben, keine Dependencies, das kann man jetzt natürlich ein bisschen nitpicky sein und sagen, aber die LibC und so weiter. Tatsächlich sind Go-Programme für diejenigen, die damit nicht so vertraut sind, statisch kompiliert. Das heißt, alle Go-Dependencies, die da so dabei sind, sind dann letztendlich geblieben. Das heißt, Prometheus an sich, wenn ich das deployen will auf einem Server, ist einfach ein SCP von dem Binary auf den Server und das Config-Fall dazu fertig. Natürlich kann man es auch in Docker laufen lassen, dann hat man Docker als zusätzliche Dependency. Aber mein Punkt ist eben, all diese Sachen, die ich gerade angedeutet habe, die Prometheus macht, das sind alles keine Groundbreaking-Revelations, also nichts Neuerfundenes. Das sind alles Sachen, die es auch vorher schon gab. Es gab schon Time-Series-Databases und Snagios, um so Sachen zu überwachen und so weiter. Aber das Schöne an Prometheus ist eben, dass es das alles in so ein kleines handliches Package verpackt. Und das ist meiner Meinung nach genau die richtigen Features nimmt und die dann miteinander so kombiniert, dass man damit sehr mächtige Sachen basteln kann. Und ich hoffe, dass ich euch innerhalb des Vortrages jetzt noch ein bisschen darin Einblick geben kann, was ich damit meine. Schauen wir uns mal die Datentypen an, die wir zur Verfügung haben. Den Counter, also den Zähler, haben wir ja gerade verpackt. Der eignet sich dafür, also damit zum Beispiel für Requests, also was, was immer nur mehr wird. Das Schöne an den Zählern ist, dass Overflows und Restarts automatisch von Prometheus für mich abgenommen werden. Das heißt, wenn ich meinen Server neu starte, dann ist das gar kein Problem oder wenn der in 64 überläuft, dann ist das auch kein Problem. Dann gibt es Gages, die sind zu benutzen für beliebige Werte, die hoch oder runtergehen könnten. Zum Beispiel die Anzahl an Werte, die gerade laufen oder die Temperatur von irgendeinem Sensor oder so was. Das wäre eine Gage. Dann gibt es Histogramme, die sind aggregierbar und haben feste Buckets. Und dann gibt es noch Summaries, quasi das gleiche, aber man kann beliebige Quantiles berechnen, also man muss vorher nicht festlegen, welche Buckets es gibt, kann sie dafür aber nicht aggregieren. Das heißt, je nachdem, welches von beiden man einsetzen möchte in seinem Dashboard, muss man entweder das eine oder das andere wählen. Das ist so etwas wie, wenn du angenommen du willst messen die Latents von Hard to Pay Requests, dann müsstest du, wenn du feste Buckets brauchst, definieren, es könnte jetzt sein, dass der 2 Sekunden dauert 4, 6, 8, 10 und so weiter. Und dann siehst du auch nur mit dieser Granularität Werte in deinem Histogramm. Gut, dann gibt es Labels. Labels sind dafür da, dass man aus einer Metrik ganz viele gleichartige machen kann. In dem Beispiel von gerade eben, den Query Counter, den wir hatten, da möchte man es vielleicht wissen, jetzt weiß ich, wir kriegen vielleicht sagen, wir 2.000 Queries die Stunde oder so. Aber wie viele Queries davon sind denn erfolgreich und wie viele Schlagen fehlen? Jetzt könnte man sagen, okay, dann definiere ich Queries Successful und Queries Failed, aber besser ist es eigentlich, wenn man ein Label einfügt, ganz einfach, weil man dann mächtigere Rules schreiben kann später. Und wie das funktioniert ist, man ergänzt die Definition, man ändert sie von New Counter auf New Counter weg für Vector und schreibt man hier wie die verschiedenen Labels heißen sollen. In diesem Fall ist es einfach ein Label namens Code. Das wäre also der HTTP Status Code und hier unten habe ich dann noch ein Beispiel Queries.withLabelValues benutzt man, um zu sagen, dass der Counter mit folgenden Werten für die Labels in der richtigen Reihenfolge inkrementiert werden soll. Man kann auch Labels fest konfigurieren für bestimmte Targets. Das heißt, ich könnte sagen, ich habe hier insgesamt 10 Server, die sind unsere Stating-Umgebung und die restlichen 7 sind unsere Production-Umgebung. Damit kann man dann später Aggregieren oder Dashboards auftrennen oder sowas. Dann gibt es Rules und Rules sind eigentlich nichts anderes als automatische Queries. Also sowas, wie wir auch gerade eben gemacht haben, nur, dass die eben automatisch ablaufen. Wozu das gut ist, sind zwei Sachen hauptsächlich zum einen vorberechnen. Man kann also damit deutlich schnellere Dashboards haben, wenn nicht eben für jeden Datenpunkt eine Berechnung ausgeführt werden muss, sondern Prometheus einfach die Daten wiedergeben kann. Und zum anderen für modulare Rule-Files, damit man also das quasi nennen Abstraktionsmittel. Und als Beispiel für so eine Abstraktion habe ich hier persistierte Nachrichten über alle Notes genommen. Das ist ein Beispiel aus RobustRC, wo wir drei verschiedene Knoten haben und ich möchte jetzt wissen, ob das Netz noch Fortschritt macht. Aber da interessiert es mich nicht, welche Knoten von den drei Knoten Fortschritt macht. Und es könnte irgendeiner davon sein, aber es ist immer nur einer. Das heißt, es gibt immer einen Lieder und der schreibt neue Nachrichten. Und deswegen habe ich jetzt hier folgende Regel. Also wenn ich das abbilden möchte in Prometheus, dann nehme ich also die Rate von CommitCount. CommitCount ist einfach mein Counter, der anzeigt, wie viele Nachrichten committed wurden. Ich sage, ich möchte eine Rate haben, das ist eine pro Sekunden Rate über ein Zeitfenster von den letzten fünf Minuten. Und ich sumiere das und ich sumiere es so, dass nur noch das JobLabel übrig bleibt. Das heißt, wenn wir nochmal kurz zurückgehen, damit es vielleicht ein klein bisschen mehr Sinn ergibt, wenn wir uns die Queries nochmal anschauen, sieht man hier, es gibt Job, das ist EHDemo und dann gibt es Instance. Und Instance ist das tatsächliche Ziel, was konfiguriert wurde. Das heißt, bei RobustRC hätte ich hier dann drei Einträge. Job wäre jeweils RobustRC, das heißt, wenn ich aggregieren möchte, möchte ich, dass das InstanceLabel wegfällt am Ende und aufsummiert wird, aber das JobLabel noch da bleibt. Das kann man hier im Übrigen auch mal machen. Also wenn ich hier Queries auf RateQueries fünf Minuten setze, dann kann man sich hier den Graph anschauen und sieht dann, okay, die meiste Zeit ist nichts passiert, dann habe ich ein paar Mal die Seite refreshed und jetzt bin ich die ganze Zeit am Reden, da passiert auch wieder nichts. Also so würde das aussehen, so und in dieser Regeldefinition würde also gesagt, erzeugt mir eine neue Time Series aus diesem Ausdruck und die bekommt dann den Namen Job Committed RateFive Minutes haben. Die Doppelpunkte haben nichts weiter zu bedeuten, das ist einfach eine Naming Convention, die ich benutze. Gut, und das letzte Konzept, was noch zu erklären bleibt, sind Alerts. Mit einem Alert kann man wie schon gesagt einen Ausdruck haben und wenn der auf einmal wahr wird, dann wird ein Alert geschickt, der einen dann erreicht. Das Beispiel, was ich hier gewählt habe, ist Capacity not n plus 1. Die Idee ist, dass man eine bestimmte Kapazität hat, die auf jeden Fall vorhanden sein muss, das ist n und dann möchte man noch mehr Instanzen haben für Redundanz, das sind dann die plus 1 oder plus 2. In unserem Fall haben wir eine Netz bestehend aus drei Knoten, wie gesagt und zwei Knoten sind wichtig, damit das Netz noch funktioniert und der eine Knoten ist für Ausfallsicherheit. Das ist vielleicht 2 plus 1, also 3. Und wie ich das jetzt implementiert habe, ist, ich habe eine Time Series genommen, die Prometheus für mich erzeugt. Das ist die sogenannte Up Time Series und die wird automatisch erzeugt. Die beinhaltet einfach, ob das Ziel, was ich angegeben habe, gerade erreichbar ist. Das können wir uns mal kurz noch anschauen. Wenn ich hier einfach Up eingebe und dann auf Konsole gehe, dann sieht man hier, es gibt Up für die Instance und den Job für den Job. Das ist eine einfache Time Series. Die wird also verglichen mit dem Wert 1 und dann wird das Resultat gezählt. Das heißt, ich habe hier zuerst mal ein paar Werte in meiner Time Series und ich wandle das durch Count in den Scalar um, also einfach in einen Zahlenwert. Den vergleiche ich dann mit 3 und wenn das weniger als 3 ist, dann feiert eben dieser Alert. Dann gibt es hier diese Vor-Directive, wenn er wahr wird, wird der geht sofort in den Status Pending. Aber für die nächsten 30 Minuten bleibt er erstmal in Pending und erst danach geht er in Active und wird tatsächlich ausgelöst. Und damit kann man so false Positives recht gut vermeiden. Also wenn ich zum Beispiel nur ganz kurz die Kapazität verringert würde, sei es, weil ich zum Beispiel gerade einen Reboot mache oder es sonstige Plant Maintenance gibt dann würde zwar der Alert aktiv werden, aber er würde noch nicht feiern. Er braucht da eben erst 30 Minuten dafür. Hier will man so eine Balance finden zwischen, ich möchte früh genug benachrichtigt werden aber ich möchte auch nicht die ganze Zeit benachrichtigt werden, wenn es um Sachen geht, die sich automatisch wieder einkriegen. Dann kann man noch Labels setzen, das ist jetzt in unserem Fall nicht so interessant und Annotations. Annotations sind quasi das gleiche wie Labels, aber man kann nicht darauf filtern diese langen Beschreibungen rein, die dann letztendlich nur für Menschen sind, also für der Sports und die Alerts, die man tatsächlich auf sein Telefon bekommt. In unserem Fall wird eben eine Summary festgelegt und eine Description, also der Titel der Notification wäre das auf meinem Telefon, wenn ich eine Push Notification bekäme, dann würde er sagen Capacity less than N plus 1. Und in der Description habe ich dann ein Text reingetan, in dem ich auch gleich versuche zu sagen, was da eigentlich gemacht werden soll. Man muss halt einen Knoten ersetzen, oder was auch immer. Gut, jetzt kommen wir schon gleich zur zweiten Demo. Ich möchte kurz zeigen, wie man so einen Alert eindrichten würde. Wir haben ja gesehen, also die Ausgangslage ist, das Prometheus haben wir jetzt gerade aus einem Docker Container gestartet und jetzt möchten wir mal einen Alert hinzufügen. So, jetzt gehen wir also in unserer Konfigurationsdatei hier ein bisschen nach oben, kommentieren das aus und sagen, ok, zusätzlich zu dem Konfig-File an sich, letzt du mal bitte Rules.Rules. Jetzt gehen wir in die Datei rein, sagen Alert Demo, if Rate Queries kleiner 0.1, sagen wir 30 Sekunden, Annotations und hier sagen wir dann Summary Demo, Description Demo. Ok, probieren wir das mal aus. So weit so gut. Jetzt können wir hier wieder auf die Status Seite zurückgehen. Wir sehen jetzt hier unten auch, die Rules Definition hat er übernommen, so weit auch ganz gut und jetzt kommen wir auf eine neue Seite namens Alerts und hier sieht man jetzt auch schon, der Alert wurde evaluiert, die Rate ist tatsächlich kleiner 0.1, weil ja gerade niemand auf den Demo-Server zugreift und der Alert ist aber noch im Status Pending, wie ich gerade erklärt hab und nach 30 Sekunden, also wenn dann Prometheus das nächste Mal diesen Alert dann wird der Wechseln in den Status Firing. Genau, hier sind wir, es steht hier State Firing und jetzt würde er dann tatsächlich gesendet, aber dadurch, dass wir keinen Alertmanager konfiguriert haben, geht der noch nicht wirklich raus, also der läuft jetzt ins Nichts. Aber was ich mit der Demo eben zeigen wollte ist, wie schön einfach das ist, einen Alert zu definieren, einfach auf Basis von einer Flight Text Query, was wir uns gerade überlegt haben. So. Ok, so weit so gut. Jetzt haben wir gesehen, wie man das machen kann für Software, die man selber unter Kontrolle hat. Die Library im Übrigen gibt es nicht nur für Go, obwohl Prometheus auch in Go geschrieben ist, sondern für ganz viele verschiedene Sprachen. Also höchstwahrscheinlich ist das, was ihr programmiert, schon abgedeckt, könnte aber sein, dass es noch keine gibt. Wie ist es aber bei Software, die man nicht unter der eigenen Kontrolle hat, also bei Drittsoftware? Hierfür gibt es verschiedene Lösungen. Zum einen gibt es den sogenannten Node-Exporter. Das hat nichts mit Node.js zu tun, sondern ist im Sinne von Knoten gemeint. Und der exportiert einfach grundlegenden Systemzustand, sowas wie Festplattenbelegungen, Speicher und so weiter. Bisschen ähnlich wie das, was wir vorhin auch schon gesehen haben in dem Slashmatrix Endpoint, was Prometheus uns automatisch konfiguriert hat. Aber das Slashmatrix, was wir gesehen haben, war eben auf Prozessebene und der Node-Exporter ist eben auf sozusagen VM-Ebene oder eben Betriebssystem-Ebene. Man kann also diesen Node-Exporter laufen lassen und dann konfiguriert man den in Prometheus als ein Endpunkt und dann kriegt man Informationen über das System. Es gibt zusätzlich eine Stats-D-Bridge, die liest einfach Daten von Stats-D ein und exportiert sie nach Prometheus. Das haben die Leute von SoundCloud deswegen geschrieben, weil sie ursprünglich Stats-D benutzt haben und dann aber auf Prometheus gewechselt sind so nach und nach. Wenn ihr also einen Monitorings-Setup habt, von dem ihr wegwechseln möchtet auf Prometheus, dann wäre das vielleicht ein Weg, sei es jetzt Stats-D oder vielleicht gibt es dafür eine andere Bridge für ganz viele gebräuchliche Software, wie z.B. Redis, MySQL, die JVM und viele andere gibt es schon fertige Exporter. Das heißt, die könntet ihr einfach nebenbei laufen lassen, sofern das Programm, was ihr untersuchen möchtet, oder was ihr monitoren möchtet, nicht selber schon Prometheus-Support mitbringt. Da gibt es auch eine Liste auf der Webseite, welche Programme das sind. Da gibt es tatsächlich immer mehr, die das schon von Haus aus eingebaut haben. Und zu guter Letzt gibt es noch einen Punkt, der Name kommt daher, dass man im Monitoring unterscheidet zwischen Whitebox und Blackbox-Monitoring. Whitebox ist alles, bei dem man den Systemzustand quasi direkt von innen sehen und abschragen kann. Und Blackbox ist alles, wo man sagt, naja, für mich ist das so eine Blackbox und von außen schaue ich, ob das noch so passt. Und was der also macht, ist, der schickt Anfragen, grob gesagt. Also der kann z.B. HTTP-Anfragen schicken, der kann TCP-Verbindungen aufmachen, der kann SMTP-Schicken usw. Das heißt, der wiederholt, den Systemzugang und exportiert dann das Ergebnis. Das heißt, auf diese Art und Weise kriegt man Sachen in Prometos rein, die eher aktiv sind, statt Passiv. So, jetzt hatte ich ja gesagt, wir schauen uns noch ein paar Rules an, damit ein bisschen diese Mächtigkeit von den Rules rüberkommt. Und das Beispiel, was ich jetzt hier anbringen möchte, ist der Leaderwechsel. Wie gerade eben schon angedeutet, in RobustRC gibt es drei verschiedene Knoten und zu jedem beliebigen Zeitpunkt ist nur einer davon der Leader. Jetzt kann es allerdings so sein, dass der Leader häufig wechselt. Also, dass eine andere Knoten sagt, hey, ich bin jetzt der Leader. Und wenn immer das passiert, ist das eigentlich eine Fehlkonfiguration oder irgendein anderes Problem. Zum Beispiel könnte es sein, dass mein Timer zu aggressiv eingestellt ist und meine Netzverbindung schlecht ist und deswegen verlieren die den Kontakt miteinander und dann gibt es wieder eine neue Election und dann wird der andere Leader. Das heißt, ich habe einen Interesse daran, und wie man das jetzt machen kann, ist, ich habe hier eine Variable oder eine Metric in Prometheus-Terminologie namens Raft is Leader. Die frage ich ab. Ich filteriere hier auf Job-Gleich RobustRC, damit ich auch mehrere Jobs in einer Prometheus-Instanz laufen lassen kann. Zum Beispiel mehrere Systeme, die auf Raft basieren. So würde ich die auseinanderhalten. Und dann nehme ich hier von die erste Ableitung, schau also, wie die Veränderung ist, nehmt den absolut Betrag wieder genauso wie vorhin, sodass nur noch das Job-Label übrig bleibt. Das heißt, man schaut hier nicht auf individuelle Knotenbasis, sondern insgesamt gesehen auf das ganze RobustRC-Netz. Am Anfang hatte ich jetzt die Regel einfach nur so definiert. Und das Problem war, dass die dann manchmal gefeiert hat. Dabei war eigentlich gar kein Problem da, sondern was ich damals gemacht hatte, ist, ich hatte einfach zum Beispiel eine neue Software-Version eingespielt und funktioniert so, dass man das neue Binary kopiert und dann den Server neu startet. Und das sorgt natürlich für einen Liederflap, wenn der Server, den man gerade neu startet, zu dem Zeitpunkt der Lieder war. Deswegen hatte ich also immer, wenn ich eine neue Version aktualisiert hatte, habe ich eine Nachricht auf mein Telefon bekommen und das ist natürlich nicht der ideale Zustand, sondern für Routine-Operationen will man nicht benachrichtigt werden. Was ich also mir dann überlegt habe, ist, ich schau einfach, ob die Zeit, also der Zeitstempel, der Unix Timestamp zum Zeitpunkt der Regelevaluation minus die Startzeit des Prozesses größer ist als 5 Minuten. Das heißt, damit wird geschaut, ob der Knoten schon länger als 5 Minuten läuft. Dann sage ich hier Countscaler und schau, ob das größer gleich 3 ist. Das heißt, das komplette Netz muss seit 5 Minuten laufen. Das heißt, im mentalen Modell kann man sich das so vorstellen, wenn ich einen Update einspiele, dann wird das Netz erst instabil gemacht und dann gibt es so 5 Minuten Zeit, in der sich das wieder stabilisieren kann und danach erst schau ich wieder mit meinem Monitoring, ob Star-Lieder-Flaps gibt. Durch die Multiplikation hier kann man also das hier evaluieren, entweder zu 0 oder zu 1, und durch die Multiplikationen werden dann die beiden aneinander geknüpft. Das zweite Beispiel, was ich noch anbringen möchte, ist Verfügbarkeit. Verfügbarkeit bedeutet in dem Fall ein robust Irish-Signets ist Verfügbar, wenn es genug Knoten gibt, die entweder Lieder oder Follower sind. Wenn alle Knoten im Zustand Candidate sind, dann bedeutet das, dass die Versuchenden Lieder unter sich auszumachen, aber es nicht gelingt, zum Beispiel, weil es zu wenig Knoten gibt, die momentan noch laufen können. Und ich habe dann eine neue Variabler eingeführt, also eine neue Metrik namens Seconds in State und die hat ein Label namens State, und dann wird hier geschaut mit dem Rackax-Operator, ob das entweder Lieder oder Follower ist, dann wird davon die Per Second Rate genommen und dann wird hier wieder aufsummiert, diesmal nach Job und Instance. Diesmal müssen wir überhaupt erst aufsummieren, weil Seconds in State eben mehrere Einträge haben kann. Aber diesmal lassen wir das Instance Label drin. Also diesmal sind wir interessiert an einem Pro-Knoten-Punkt. Und dann wird das geteilt durch Seconds in State auch wieder aufsummiert. Und jetzt fragt man sich vielleicht, warum muss das eine durch das andere geteilt werden? Und die Antwort ist, wenn ich nur auf das eine schaue, dann ist das zwar so, dass Seconds in State jede Sekunde aktualisiert wird über eine Go-Routine, die bei mir im Hintergrund läuft. Aber es gibt natürlich unweigerlich so einen kleinen Drift, weil wir hier von mehreren verschiedenen Computern reden, die über das Netz miteinander gekoppelt sind und vielleicht ist gerade ein anderer Prozess dann wird halt der Scheduler nicht mal eine Go-Routine drannehmen können. Das heißt, unweigerlich trifft das so ein bisschen auseinander. Und dann ist die Availability halt nicht immer 100%, sondern knickt manchmal so ein bisschen ein auf 99,95% und dann kriege ich einen Alert. Deswegen zeile ich hier das eine durch das andere, damit Seconds in State quasi angibt, wie viele Sekunden gerade in einem Scrape-Intervall passiert sind. Und das muss nicht notwendigerweise genau die gleiche Zeit sein wie auf dem Monitoring-System. Das ist ein bisschen tricky, da muss man ein bisschen aufpassen. Gut. Dann Alertingphilosophie, da gibt es einen Superartikel drüber. Ich habe den hier auf den Folien verlinkt, der heißt MyPhilosophie on Alerting. Und den möchte ich euch sehr ans Herz legen. Die zwei Sachen, die ich rausgreifen möchte und die ich hier vorstellen möchte, sind zum einen soll man auf Symptome schauen, nicht auf die Ursachen. Was man damit meint, die Ursache von einem Problem ist. Aber euch ist es wichtig, dass der Nutzer zufrieden ist. Das heißt, angenommen, ihr habt eine Webseite, ein bekanntes Blog und das benutzt eine SQL-Datenbank im Hintergrund. Dann wäre ein Symptom, die Webseite funktioniert nicht mehr, die liefert 500er aus. Eine Ursache dafür könnte sein, die Datenbankverbindung kann nicht mehr aufgebaut werden, weil die Datenbank gecrashed ist. Oder die Ursache könnte sein, die Festplatte ist voll und Temp-Dateien können nicht mehr angelegt werden. Es gibt quasi unendlich viele. Es kann alles mögliche schiefgehen. Symptome gibt es nicht so viele. Der Punkt ist, dass einen alert einen gewissen Overhead hat. Ein alert muss gewartet werden. Bei dem kann es sein, dass er zu häufig feuert, wie wir in den Beispielen gerade gesehen haben. Das sollte also wohl bedacht sein. Trotz der Tatsache, dass es so einfach ist, einen neuen alert hinzuzufügen. Angenommen, man monitoriert die Ursachen und ist einfach komplett abgestürzt. Dann könnte es sein, dass man zehn verschiedene Alerts bekommt, die alle zwar wahr sind, aber die alle in dem Fall nicht interessieren. Weil das System ist die Webseite geht nicht mehr. Eigentlich will man da genau das monitoren, was der Benutzer auch sehen würde. Der andere Punkt, den ich sehr interessant fand, ist, dass Alerts actionable sein müssen und nicht automatisierbar. Das heißt, man muss unterscheiden. Actionable bedeutet, wenn man den alert bekommt, man muss automatisierbar sein, was zu machen. Und nicht nur man bekommt einen alert und der sagt einem, irgendwas ist kaputt und das stimmt, aber man kann trotzdem nichts machen. Das andere ist, es darf auch nicht automatisierbar sein. Es darf nicht sein, dass man einen alert bekommt und dann weiß man genau, jetzt muss ich hier wieder den Prozess neu starten, sondern sollte man sich fragen, warum habe ich nicht den Computer beigebracht, dass er den Prozess automatisch neu startet, wenn der dann tatsächlich so Fehler behaftet ist und die Fehler nicht gefixt werden können. Das heißt, man muss sich das nicht ausfinden, damit man es überhaupt rechtfertigen kann, dass hier Menschen Alerts bekommen und aus all dem rausgerissen werden, was sie gerade machen. Das finde ich sind interessante Punkte und interessante Philosophie und der Artikel hat noch mehr davon. Das möchte ich euch empfehlen zu lesen. Zu guter Letzt schauen wir uns doch noch mal ein bisschen Dashboards an. Was wir bislang schon gesehen hatten, war einfach diese Prometheus-Seite mehr so für die interaktive Evaluation. Hier kann ich Queries reintippen und dann kriege ich meinen Graph. Soweit so gut, aber das ist kein sinnvolles Dashboard, wo ich einfach drüber brausen kann. Was ich hier jetzt rausgegriffen habe, ist das Dashboard für RobustRC, was ja auch schon die ganze Zeit aus Beispiel herhalten muss. Hier habe ich jetzt ein recht ausführliches Dashboard. Ich kann mal so ein bisschen durchgehen und das ein bisschen zeigen. Hier zum Beispiel sieht man diese Network Availability. Das war die Geschichte, die ich gerade vorgestellt habe. Diese Regel, die bleibt recht stabil und wenn die auf dem stabilen Wert bleibt, dann ist das Netz wunderbar verfügbar. Hier sieht man den aktuellen Lieder. Hier sieht man auch, dass es hier immer nur eingeben kann und dass die Linie sich aber wechselt. Das heißt, man sieht hier, um 17.08 gab es einen Liederwechsel. Vorher war es alb und jetzt ist es docknull. Soweit so gut. Dann habe ich hier zum Beispiel noch Grafen für CPU Seconds per Second, also wie sehr die verschiedenen Prozesse die CPU auslasten. Da sieht man also immer okay. So ungefähr 9 Uhr, dann 11 Uhr, dann und so weiter. Also in diesem Intervall machen die jeweils was. Für diejenigen, die sich fragen, was das ist, das ist die sogenannte Compaction, bei der alte Nachrichten rausgelöscht werden aus dem Working Set. Dann sieht man hier Process RSS, also wie viel Speicher verbraucht wird. Da kann man das ein bisschen vergleichen. Da würde man also sehen, wenn irgendwie ein Prozess der lange läuft, dann könnte man da vielleicht eine Memory League diagnostizieren oder sowas. Außerdem ist es ganz praktisch zu wissen, wie viel Speicher der Prozess verbraucht, einfach auch damit man schauen kann. Zum Beispiel, wenn man eine VM Provision, wie viel Speicher möchte ich darin geben. Abtime ist auch ganz interessant, dass es hier die Geschichte mit dem Unix Timestamp, wann der Prozess gestartet wurde, also die Definition hier, und da kann ich vielleicht mal reingehen und das zeigen. Okay, ich könnte es zeigen, ob ich das hier gespeichert habe und ob es geht. Das ist einfach Time minus und dann die Metrik. Man sieht hier, dass das hier so einmal nach unten gegangen ist. Also hier oben steht es auf fünf Wochen und dann ist es hier nach unten gegangen. Und was da passiert ist, ist, dass Doc.Null hat einfach neu gestartet. Und Doc.Null ist ein Dockerhost von mir, der auf CoreOS läuft und CoreOS hat diese automatischen Reboots. Das heißt, der rebootet einfach irgendwann mal. Die anderen Knoten halt nicht, weil die nicht auf dem Betriebssystem laufen. Genau, und dann gibt es noch ein paar mehr Grafen, auf die ich jetzt nicht im Detail eingehen möchte. Aber ich finde, die Takeaways sind eben, dass Grafana ein sehr ansprechendes Dashboard ist. Es ist sehr einfach zu konfigurieren und auch sehr dynamisch. Es integriert sich gut mit Prometheus. Das heißt, ich kann einfach mein Query, genauso wie ich es in der Prometheus-Seite an sich eingegeben hätte, und ich habe das auch schon gestalten. Also, vorher hatte ich mich auch noch mit anderen Dashboarding-Lösungen auseinandergesetzt. Es gab früher Prom-Dash, was von dem Prometheus-Projekt selber war. Und es gab auch noch so eingebaute Console-Templates und so was. Aber Grafana ist eigentlich der Platz hier schon. Das hat soweit meine Interpretation jetzt alles verdrängt, was es sonst so an Alternativen gab. Ist auch recht ähnlich vom Konzept her. Also, es ist auch in Go geschrieben. Es ist auch ein einfaches Binary, was man deployen kann. Und es gibt eine einfache Konfiguration. Die Dashboards kann man alle als JSON-Dateien exportieren. Das heißt, wenn man ein Projekt hat, wie ich jetzt zum Beispiel meinen robust ARC, kann ich da in einem Contrap-Folder direkt in den Git-Repository meinen Dashboards in JSON-Form mitliefern. Dass die Leute dann einfach sagen können, die Prometheus-Rules-Files und Konfig importieren können. Gut. Das war soweit auch schon. Prometheus.io ist die Webseite, auf der ihr alles findet. Dort gibt es nicht nur ansprechend gestaltete Dokumentationen, Einstieg, Blockposts und so weiter, sondern auch Links zur Community. Die Community finde ich ausgezeichnet. Es ist ein sehr lebhaftes Open-Source-Projekt. Die Leute sind frontlich. Wenn man Pull Requests vertreibt, dann wird da auch recht flott darauf geantwortet. Das macht also Spaß, damit zu arbeiten und das System zu dem zu machen, was man gerne hätte. Jetzt haben wir noch eine ganze Menge Zeit für Fragen und Antworten. Direkt hier vorne ist die erste Frage. Ich habe zwei Fragen. Erstens hast du schon mal Nagios verwendet. Wie gibt es da Unterschiede, wo du sagst, das ist besser oder schlechter? Du hast Fert Party Plug insgeschrieben. Inwieweit sind die gut gewartet? Es ist speziell, die werden interessant für mich, wenn ich sage, ich will jetzt wirklich Sachen, die ich nicht in der Kontrolle habe. Ich beantworte zuerst das zweite. Die sind recht ausführlich und funktionieren gut. Üblicherweise schreibt man die einmal und dann müssen sie meistens nicht mehr angefasst werden, weil es doch eigentlich alles recht high-level ist. Ich habe aber auch von jemandem gehört, dass die das Monitoring-System gewechselt hatten auf Prometheus und begeistert waren davon, wie ausführlich die Daten sind, die sie jetzt über bestehende Prozesse wie in einem MySQL-Datenbank oder in eine JVM bekommen. Die scheinen schon recht ausführlich zu sein. Ich würde behaupten, wenn du Technologie benutzt, die auch von Soundcloud oder Docker oder anderen großen Firmen, die da beteiligt sind, benutzt wird, dann hast du natürlich bessere Karten, dass das gut gemachte Sachen sind. Aber wie gesagt, wenn du auch von dem Prometheus-Projekt selbst initiiert, hatte dann aber auch nicht alle Features, die ich gerne haben wollte. Das ist recht unkompliziert, auch die zu erweitern. Die erste Frage war bezüglich Nagios. Ich habe Nagios selbst nie sozusagen in Production ausführlich und lange verwendet. Ich habe es immer nur mal kurz mehr angeschaut, aufgesetzt, ein bisschen rumgespielt. Ich fand Nagios immer kompliziert und schwieriger aufzusetzen und die Qualität von den Plugins ein bisschen wechselhaft war. Im Großen und Ganzen bevorzuge ich Prometheus, aber das könnte einfach nur sein, weil ich halt mit dem Modell deutlich vertrauter bin. Also für mich ergibt es Sinn, dass ich quasi diesen Whitebox-Ansatz habe und wie das alles zusammenspielt. Und ich fühle mich einfach deutlich wohler damit, dass Prometheus so self-contained ist. Aber jetzt mit dem aus dem Weg würde ich generell sagen, wenn du damit Erfahrung hast, dann schaust dir lieber selber an. Und wenn du für dich abwägen möchtest und in dem Vortrag wollte ich eigentlich absichtlich keine Comparison machen zwischen den beiden, kein Vergleich, sondern eher zeigen, was Prometheus kann und dann darf man selber einen Urteil treffen, ob das ein oder das andere besser geeignet ist. Da hinten gab es eine Frage. Hi, gibt es für Prometheus kommerziellen Support? Genau, es gibt so eine Consulting-Firma, die welche von den Hauptentwicklern gegründet haben mittlerweile und soweit ich das verstehe, dann habe ich eine Frage. Da vorne ist noch eine Frage. Hat Prometheus immer Lirting-Service-Dependencies? Wenn Service A nicht erreichbar, dann alerte er auch nicht die anderen? Das ist eine gute Frage. Ich glaube so direkt nicht, du könntest natürlich dependencies so abbilden, dass du sagst, dass deine Conditions einfach jeweils gekoppelt sind. Also, dass du schaust, Conditions zum Beispiel, was wäre ein gutes Beispiel. Mir fällt es tatsächlich kein gutes Beispiel ein, aber wenn du dir nochmal schaust, dir nochmal anschaust. Ja, ich glaube für Network Down, na ja, wenn Network Down ist, dann wird auch kein Alert rausgehen. Also, der Punkt ist, hier in dieser If-Bedingung könntest du natürlich einfach irgendwie das Koppeln mit und und ab und dann der jeweilige Dienst. Also, wenn zum Beispiel der Knoten gar nicht erreichbar ist, dann diesen Alert nicht triggern oder sowas. Man kann das genauer nachdenken über den konkreten Anwendungsfall. Und vielleicht noch, hast du Erfahrung mit Influx? Ja. Kannst du ganz kurz sagen, was Prometheus vorne siehst? Bei Prometheus ist dieses ganze Plumbing, also diese ganze Infrastruktur um nicht nur eine Time Series Database zu haben, sondern auch mächtige Queries zu haben und Alerting zu haben und ein Ingress, also das Daten in das System reinlaufen. Das ist alles schon da. Ich hatte tatsächlich vorhin eine Monitoring- und Alerting-Lösung gebaut mit Influx-DB und da hatte ich eben so einen Importer geschrieben dafür und dann die Query Language war immer gerade so ein bisschen nicht mächtig genug. Also, ich bin dann oft an die Grenzen gestoßen und das war alles schwierig. Und mit Prometheus merkt man halt richtig, das System ist für den Anwendungsfall gebaut und deswegen geht es auch alles deutlich leicht davon in der Hand. Gibt es noch weitere Fragen? Ansonsten, falls euch noch Fragen einfallen, ich laufe auch noch die ganze Zeit auf der Veranstaltung rum. Ich würde auch noch so fragen. Oder wie gesagt, die Community ist sehr freundlich und hilft euch auch gerne. Und damit möchte ich auf den Weg geben. Schaut euch mal an, es macht echt Spaß und vielen Dank für die Aufmerksamkeit.