 Hallo und herzlich willkommen zu meinem Vortrag. Mein Name ist Michael Stapelberg und der Titel des Vortrags ist Monitoring mit Prometheus. Im Englischen nennt sich das Ding Prometheus, aber ich nehme mir jetzt einfach mal das Recht, aus Prometheus zu sagen. Es geht mir ein bisschen einfacher von den Lippen. Bevor wir mit dem eigentlichen Vortrag beginnen, möchte ich kurz eine kleine Publikumsbefragung machen. Wer kennt denn Prometheus vor diesem Vortrag schon? Bitte Hand heben. Okay, zwei vereinzelter Hände, gut. Wer hat vor Prometheus privat einzusetzen oder macht Monitoring privat eher? Hand heben, bitte. Okay, na okay, elfundviertel. Wer denkt, dass es sei vielleicht beruflich interessant? Okay, deutlich mehr, gut. Okay, zunächst mal skizzier ich worum es in dem Vortrag gehen wird. Ich möchte zuerst mal einen Hintergrund geben, sowohl über meine Haltung zu Prometheus. Wenn man mich dazu, als auch über die Situation heraus aus der Prometheus entstanden ist, dann möchte ich erst mal ein Beispiel machen. Also ich werde erst mal nicht versuchen zu definieren, was es eigentlich genau ist und was es so besonders macht, sondern wir fangen direkt Hands on an. Ich zeige euch ein Beispiel, ein ganz kleiner HTTPServer in Go geschrieben und den starten wir mit Monitoring aus und dann basteln wir erst mal ein bisschen. Ich denke, das ist eine sehr schöne Einstiegsweise in das Thema könnt ihr auch viel besser verknüpfen, wenn ich über irgendwas rede. Was ist das in tatsächlichen Features, die ihr schon gesehen habt? Dann geht es um die Datentypen, die Prometheus unterstützt, um ein paar Begriffe, Labels, Rules, Alerts, was sind das eigentlich? Dann geht es darum, wie bindet man Drittsoftware ein, das ist wahrscheinlich sehr wichtig für euch und was sind eigentlich Exporter? Ich werde dann ein paar Rules vorstellen, also ein paar Beispiele geben, damit ihr seht und verstehen könnt, warum Rules so mächtig sind und warum sie cool sind. Es wird ein klein wenig um Alertingphilosophie gehen und dann zeige ich noch ein paar Dashboards. Und dann schauen wir mal, ich möchte gerne viel Zeit für Fragen geben und wenn wir noch ein bisschen Zeit haben, dann kann ich das auch schon ein bisschen füllen. Gut, zu Fragen, wo wir gerade dabei sind, wie gesagt, am Ende des Vortrags wird es Zeit geben für Fragen, aber sofern ihr eine Frage habt, die unglaublich wichtig ist und euch unter den Nägeln brennt, die also das weitere Vorgehen in dem Vortrag beeinflusst, dann bitte einfach Handzeichen geben und dann versuche ich euch dran zu nehmen. So, zunächst zum Hintergrund. Ich persönlich habe mit Prometheus noch gar nicht so lange zu tun. Ich habe das Projekt erst kennengelernt vor circa fünf Monaten, als das offiziell vorgestellt wurde. Ich persönlich habe aber mit anderen Systemen gearbeitet, die ganz ähnlich sind. Der erste Begriff hier, der verlinkt ist und den lad ich direkt nach dem Vortrag hoch ins Wiki, ist Borg. Und Borg ist das Cluster Management System bei Google. Darüber kam von der Weile in den Paper raus und das ist hier verlinkt. Und wer das noch nicht gelesen hat, der sollte das unbedingt lesen, weil es wirklich sehr prägend ist, für mich persönlich zumindest, was dem Begriff Cloud angeht. Und Borgmon ist das Monitoring System, welches man eben Zusammenspielen mit Borg verwendet. Prometheus ist sehr, sehr ähnlich und das liegt daran, dass der Prometheus angefangen hat und dann später zu SoundCloud gegangen ist und damit ist das Projekt dann auch zu SoundCloud gegangen. Matt Prout war früher bei Google und hat also gesehen, wie funktioniert Borgmon und hat dann das Konzept genommen und hat es noch mal versucht zu verbessern und schön und frei zu implementieren. Und deswegen haben wir jetzt Prometheus als Monitoring System und deswegen gibt es jetzt diesen Vortrag. Und ich habe also mit Borgmon schon einige Jahre gearbeitet und deswegen denke ich, dass ich ein guter Kandidat dafür bin, zu verstehen und euch zu erklären, wie Prometheus in etwa funktionieren sollte. Meiner Meinung nach ist es eine großartige Lösung für Monitoring und Alerting und alles andere, was wir bislang in der Umsource-Welt haben, kommt einfach da nicht dran, weil Prometheus so ein bisschen andere Herangehensweise hat. Und ich hoffe, dass ihr am Ende des Vortrags das auch versteht und auch ein bisschen in der Lage seid, zu skizzieren, wie sich das unterscheidet von Nagios und Konzerten. Gut, zum ursprünglichen Szenario. Angenommen, ihr macht so eine kleine Firma und ihr schreibt, sagen wir, eine Suchmaschine, die ihr in viele HTTPServer designed. Also ihr habt, sagen wir, 10, 20, 50, 100 von Rechnern und auf jedem läuft ein HTTPServer. In meinem Fall habe ich zwei Beispiele, die da ganz ähnlich organisiert sind, z.B. Debian Code Search, über das ich gestern hier einen Vortrag erhalten habe oder auch robust RSC, wobei es auch einen Vortrag gab. Beide sind Systeme, die aus vielen zusammengeschlossenen HTTPServern bestehen. Und was da also naheliegt, wenn man einfach nur die Server hat, also man setzt einfach Software ein, ist, dass man sehen will, wie funktioniert denn das System, wie verhält es sich im Moment. Also man könnte sich jetzt natürlich auf jeden Server einloggen und kann die Logfiles schauen und dann schaut man, okay, ist hier alles gut so bezüglich der Response-Zeiten und dergleichen. Aber eigentlich muss man das aggregieren, weil man zu viele von diesen Servern hat. Also es ist nicht mehr machbar, sich einzeln in die ganzen Server einzulogen. Und was liegt da näher, als zu sagen, na gut, die einfachste Methode, die uns in den Sinn kommt, um einen HTTPS-Server-System zu instrumentalisieren, ist es, wir führen einfach, sagen wir, Zählervariablen ein, wie viele Requests kamen, wie viele davon sind erfolgreich gewesen, wie viele sind fehlgeschlagen. Und dann exportieren wir die. Und den Link, den ich hier gesetzt habe, ist auf das EXPVAR-Package in Go. Das macht also genau das. Also da kann man einfach sagen, diese Variable möchte ich gerne exportieren. Und das ist hier der grundlegende Zustand. Und was man dann damit machen kann, man kann Ausfälle debaggen und man kann Alerting bei Problemen einführen. Also was meine ich damit? Man hat dadurch, dass man diese Variable exportiert und dann mit einem Monitoringsystem wie Prometheus automatisch aggregiert und speichert, kann man sich schöne Grafen zeigen lassen, die einem helfenden, aktuell laufenden Ausfall verstehen, weil man sieht, was hat das System gemacht, was macht das im Moment. Und man kann das auch gleichzeitig nutzen, weil man dann sagen kann, okay, wenn ich das damit verstehen kann, hey, wenn es so und so viel fehlgeschlagene Request gibt, dann ist wahrscheinlich gerade was im Busch und dann kann man eben einen Alert setzen. So, das ist erstmal recht schwammig und ihr müsst es auch noch nicht vollständig verstanden haben. Deswegen schauen wir uns jetzt das Beispiel an. Das, was hier auf der Folie abgedruckt ist, ist ein vollständig funktionierender HTTPServer in Go, diejenigen, die mit Go noch nichts gemacht haben, keine Sorge. Das muss man jetzt auch nicht ordentlich verstehen. Das einzige, worauf ich ein bisschen das Augenmerk richten möchte, ist, dass es hier ein Handler gibt für Slash Search. Das ist also unser Endpunkt. Und das Einzige, was der macht, wiederum, ist, ohai auszugeben. Und dann sage ich, okay, das soll bitte auf Port 8080 laufen und damit habe ich dann den HTTPServer fertig. So, soweit klar, denke ich. Und jetzt ist natürlich die naheliegende Frage, was muss ich jetzt tun, damit ich diesen HTTPServer mit Prometheus abfragen kann? Also, wo kann ich jetzt diesen Zustand, also wie viele Request waren okay, wie viel sind fehlgeschlagen? In dem Fall ist es natürlich klar, alle werden okay sein, weil es gibt ja keine Möglichkeit, dass hier irgendwas fehlschlägt. Wie kann ich den exportieren? Und das funktioniert so, das ist jetzt nicht mehr ganz vollständig, muss den paar Zeilen oben weglassen, um genug Platz auf der Folie zu haben. In der ersten Zeile importieren wir das Client Package von Prometheus für Go. Und in den nachfolgenden Zeilen definieren wir eine Variable, einfach eine Variable vom Typ Zähler, also ein Counter, die Highs Queries und die hat auch einen Hilfetext. Im Prometheus muss jede Variable, die wir exportieren, einen Hilfetext haben, einfach weil man sonst am Ende nicht mehr durchblickt. Also, das ist quasi ein sehr starker Andreiz für euch, das zu dokumentieren. Und eure Kollegen werden es euch danken. In der Initfunktion, die von Go aufgerufen wird, bevor die Mainfunktion aufgerufen wird, wird dann der Zähler registriert, damit Prometheus auch weiß, welche Zähler es gibt in dem Code. Und dann führen wir einen neuen Handler ein für den Endpunkt Slash Matrix. Der wird von Prometheus bereitgestellt und das Einzige, was dann noch bleibt, für jeden Request, der reinkommt, zählen wir diese Zählervariable um eins hoch. So, jetzt kommt es also gleich schon zur ersten Demo. Was wir machen ist, wir werden Prometheus starten, werden Target einrichten, nämlich diesen HDDP-Server, den ich gerade vorgestellt habe, und dann die Metrik interaktiv abfragen. Ich habe da mal was vorbereitet. Das Beispiel, was ich gerade auf der Folie hatte, ist hier also nochmal genau so im Quelltext. Ich habe es euch nur nochmal gezeigt, damit ihr sichergehen könnt, dass das wirklich genau das ist, was ich vorgestellt habe. Ich sage, go run, example.go, und wenn ich jetzt auf localhost 8080 gehe, einfach mal erst auf Slash, dann gibt es keine Seite, aber auf Slash Search, dann sagt er mir, oh hi, soweit, also alles gut, ich kann das auch paar mal refreshen, passiert immer das Gleiche. Das sollte jetzt keinen überraschen, aber jetzt schauen wir es doch mal an, was in Metrics verfügbar ist. Und jetzt sehen wir, okay, das ist ja schon eine ganze Menge, die, das ist zum Beispiel Process Go Routines, und ein Value, das ist 12. Und diese ganzen, die hier jetzt oben sind, die hat uns Prometheus schon geschenkt. Also die sind einfach in jedem Go Binary drin, wenn ich die Prometheus Klein Library verwende. Das Ganze hier unten ist jetzt die Metrik, die wir selber definiert haben. Und wenn ich jetzt also auf dem HTTP server eine Seite abrufe, dann und hier Neulade, sieht man, da passiert nichts, aber wenn ich search aufrufe, hier unten von 5, eins hoch auf 6, wenn ich das ein paar mal mache, dann geht der um so höher. Soweit so gut. Bevor sich jemand wundert, das Format, was wir hier sehen, ist nicht das ideale Transferformat, das ist plaintext, das ist vielleicht schwierig zu pasen und so weiter, das ist für Human Consumption, also für Menschen, die sich das anschauen wollen. Wenn Prometheus das abfragt, dann setzt es in einen entsprechenden Accept Header und sagt, hey, ich möchte das bitte Prometheus steht zur Verfügung entweder im Quelltext, dass ihr euch das selber bauen könnt oder als Docker-Container und das ist eigentlich ganz angenehm. Wir können also sagen Docker run prom slash Prometheus und dann sehen wir, okay, der startet hier hoch. Jetzt müssen wir natürlich zunächst mal noch sagen, dass wir auf port 9090 das verfügbare haben wollen. Das ist der Standardport, den Prometheus wählt und dann können wir uns hier anschauen, ich zoom mal ein klein wenig rein. Ich hoffe, das sollte groß genug sein, dass das jeder sehen kann. Das ist die Status-Seite von Prometheus. Man sieht hier oben die Abtime, man sieht Bildinformationen und dann kommt die eigentliche Konfiguration. Die Konfiguration von Prometheus ist im Moment in einem so genannten ASCII Protocol Buffer. Das ändert sich aber gerade in Yammel und das wird ein Migrationstool dafür geben, dass man die Alte in die Neue übernehmen kann. Das wurde lange auf der Mailing-Liste besprochen. Wieso dann Yammel? Ich würde gerne nachlesen, wenn euch das interessiert. Hier ganz unten sieht man die ganzen Flags. Das sind alle Kommando-Zeilen-Parameter. Da gibt es einige davon, aber einer ist besonders wichtig. Das ist, wo das Konfig-File liegt. Das werden wir gleich noch anpassen. Dann sieht man Rules, die sind bei uns leer, komme ich später noch dazu. Target ist besonders interessant. Wenn man Prometheus einfach so startet, ohne eine spezielle Konfig anzulegen, dann ist es zumindest mit dem Docker-Container so, dass er sich einfach erstmal selber monitornt. Das zeigt auf Prometheus selber. Wenn ich hier auf Matrix gehe, dann sehe ich, da gibt es ein Haufen Zeug drin, was man alles monitoren kann. Und was man hier sieht, ist, das State ist healthy. Das bedeutet, Prometheus konnte das Ziel erreichen. Wenn euch zum Beispiel ein Server ausfällt, dann würdet ihr das hier sehen. Oder wenn es Netzwerkprobleme gibt oder irgendetwas. Und man sieht auch, wann er zuletzt mit dem Target geredet hat. So, so weit so gut. Jetzt müssen wir natürlich schauen, dass unsere Target, was ich gerade gezeigt habe, in Prometheus konfigurieren. Dazu logge ich mich hier mal ein. Erstelle einen neuen Ordner für Prometheus. Und dann sage ich, Prometheus.conf. Ich nehme einfach mal die Konfiguration, die wir hier exportiert sehen. Sag, okay, das ist ein guter Default. Der hat offensichtlich funktioniert. Hier ersetze ich das durch die IP-Configuration. Hier ersetze ich das durch die IP-Adresse, auf dem der Server läuft. Das ist diese, sage, 8080 Metrics. Okay, so weit so gut. GPN-Demo. Das Scrape-Interval hier ist standartmäßig auf fünf Sekunden eingestellt. Das bedeutet, wie häufig Prometheus die Metricen holen soll. Das lassen wir mal auf fünf. Das ist ganz gut. Dann sage ich, quit. Und hier sage ich dann, okay, ich muss ein neues Volumen einführen. Und dann sage ich, slash-temp-prom soll unter slash-prometheus zur Verfügung gestellt werden. Und dann muss ich ihm noch sagen, dein Konfig-File ist jetzt nicht mehr in slash-etc, sondern in prometheus.conf. Okay. Ich refreshe das hier mal. Man sieht auch, okay, das Flycat hat sich jetzt geändert. Man sieht hier oben, die Konfig hat er übernommen. Das ist ein doppeltes HTTP. Das entfernen wir mal. Man sollte jetzt aber hier sehen, okay, das steht jetzt auf unhealthy. Damit kann ich nichts anfangen. Das ist keine gültige URL. Wir starten bei neu. Er legt das Konfig-File neu. Er sagt, state unknown, last scrape never. Und jetzt hat er zum ersten Mal das Target gescraped. Man sieht, okay, jetzt steht das auf healthy. So. So weit so gut. Aber damit können wir ja PC erst mal noch nichts anfangen. Wir haben noch keinen einzigen Graph. Und wir haben noch keinen Alert und so weiter. Jetzt gehen wir also hier oben mal auf Graph. Und prometheus präsentiert uns jetzt hier diesen ... diese Schnittstelle, in der man zum einen eine Konsole hat und zum anderen einen Graphtab. Und man kann hier eine liebige Expression eingeben. Die Expression komme ich gleich noch. Aber hier gibt es auch so ein Dropdown für die verschiedenen Metricen, die prometheus momentan kennt. Und jetzt sieht man hier okay. Es gibt hier ein Ergebnis. Sorry, ich mach das ein bisschen größer. Mit dem Wert 10, wenn wir jetzt also zurückgehen, auf Metric sieht man okay. Hier unten links steht tatsächlich 10. Passt. Man sieht Job gleich GPN-Demo. Das war das, was ich eingetragen hatte in meinem Konfig-File. Man sieht auch die Instanz. Das ist, wo das läuft tatsächlich. Und das Code Lab Monitor kommt aus der original Konfig. Jetzt kann ich auch sagen, okay, ich möchte das mal grafen. Ich summe wieder ein bisschen draus, dass man den Graph sieht. 15 Minuten gebe ich mal ein. Und jetzt sieht man, okay, hier unten, das ist nicht besonders spannend. Da ist jetzt unten eine Linie auf dem Nullpunkt quasi. Dann sagen wir doch, okay, ich lade Ihnen ein paar mal neu. La, la, la. Und jetzt lade ich hier die Seite nochmal neu. Es steht immer noch auf 15 Minuten. Wir müssen natürlich warten, bis Prometheus vorbeikommt. Und jetzt sehen wir okay. Jetzt sehen wir hier diesen Spike. Ist jetzt auf 26 Grills angestiegen. Und vorher waren es noch 10. Das ist jetzt ein sehr einfacher Ausdruck. Ich gebe einfach an, okay, das sind meine Queries. Jetzt will ich vielleicht sowas machen, wie die Rate of Queries. Und jetzt wird es schon interessanter. Eine Rate bedeutet, dass ich eine Per Second Rate haben will. Und jetzt sieht man, okay, hier unten, die ganze Zeit war es auf Null, weil wir die Seite ja nicht geladen haben. Aber jetzt, als wir die Seite geladen haben, geht es hoch auf 0,29. Wir haben jetzt also in Erfahrung gebracht, ich kann 0,29 Requests pro Sekunde abschicken, wenn ich gerade eine Demo halte. Das ist schon mal interessant. Okay, so viel Datse. Das ist die erste Demo. Und jetzt versuche ich euch ein bisschen zu erklären, was ihr da gerade gesehen habt. Prometheus in a nutshell. Es sammelt Metriken. Das ist das, was wir gerade eingerichtet haben und speichert sogenannte Time Series. Also einfach Datenwerte, die einen entsprechenden Zeitstempel dran haben. Warum ist das praktisch? Weil man das eben sowohl interaktiv, als auch über alerting rules abfragen kann. Mit interaktiv ist gemeint Dashboards und Queries. Queries ist das, was wir gerade gemacht haben. Wir haben einfach eine Expression eingegeben, haben die abgefragt, bekommen entweder eine tabularische Auflistung zurück oder wir bekommen einen Graph angezeigt. Ein Dashboard ist eine Zusammenfassung von vielen Graphs. Also wenn ich mir das Monitoring zusammen baste, dann will ich natürlich nicht jedes Mal von neuem wieder die Expressions mir zurechtformeln müssen. Wir überlegen, okay, was will ich jetzt hier genau anzeigen, sondern da bastelt man das einmal und dann wirft man das in ein Dashboard und dann können sich das die Kollegen und man selber anschauen und da muss man nicht so viel Zeit verwenden. Der Punkt ist allerdings, dass wenn man möchte, kann man das machen. Also wenn man ein Dashboard sieht und sieht, aha, okay, da sehe ich jetzt, okay, hier ist ein Spike. Da möchte ich doch nochmal genauer schauen, was da passiert ist. Da möchte ich hier reingehen mit die Expression nehmen, die Expression ein bisschen verändern, vielleicht die andere Funktion ausprobieren, vielleicht mir nicht alle Time Series anzeigen lassen, aber ja, solche Sachen, das kann man machen. Und das ist ein großer Vorteil im Vergleich zu anderen Systemen, die statisch aufgebaut sind. Also zum Beispiel vieles, was auf RDD-Tool basiert, also diese Round-Dropping-Databases. Da kriegt man einfach PNGs, sondern kann man mit denen nichts machen. Und das geht bei Prometheus viel, viel schöner. Okay, das ist die interaktive Query-Abfrage-Seite und die Alerting Rules funktionieren dann so, dass man Prometheus beibringt, hey, diese Time Series, zum Beispiel Queries in diesem Fall, wenn zum Beispiel die Rate an Queries pro Sekunde unter 1 sinkt, dann ist wahrscheinlich irgendwas am Schieflaufen. Das ist vielleicht unser komplettes Netz kaputt oder so. Das kann man machen, wenn man sagt, okay, wir haben einen Dienst, der hat Hunderte von Queries pro Sekunde. Und dann kriegt man einen Alert. So was könnte man bauen. Aber da kommen wir später noch darauf, warum das vielleicht keine so gute Idee ist. Diese Alerting Rules werden dann von Prometheus ausgewertet und werden an den sogenannten Alert Manager geschickt. Über den werde ich nicht so viel sprechen heute, es sei denn, ihr fragt mich Fragen dazu später, weil er eigentlich ein recht unbedeutendes Stück Infrastruktur im Hintergrund ist. Was der Alert Manager nämlich macht, ist, er nimmt einfach von einer oder mehrerer Prometheus-Instanzen Alerts an. Also, ein Alert ist in diesem Kontext, da läuft gerade was schief. Also, eine Alerting Rule wurde evaluiert und sie hat mir gesagt, sie feuert jetzt. Und dann wird es an den Alert Manager geschickt und der wiederum kann es an verschiedene andere Dienstes schicken. Der kann euch zum Beispiel eine E-Mail schicken, der integriert sich mit Push Over, damit ihr auf euer Android-Telefon Push Nachrichten bekommt oder mit PagerDuty, all solche Sachen. Das kann man also an dieser Stelle einbauen. Der Clue bei Prometheus ist, dass all das, was ich gerade gezeigt habe, ist alles nicht wirklich neu. Es gibt schon Time Series Databases, es gibt OpenTSDB, es gibt InfluxDB. Es gibt auch Programme, die mehr oder minder komplexe Alerting Rules erlauben. Es gibt auch schon Sachen, wo man sich der Sports zusammenstellen kann. Es gibt Stats, D-Graphite und so weiter. Aber was der Clue wirklich ist, ist, dass Prometheus das alles packt und es in ein sehr handliches, robustes Standalone Package zusammenfasst. Prometheus an sich hat keine Dependencies. Weil es in Go geschrieben ist, das kompiliert man einmal, dann kriegt man ein statisch gelingtes Binary und dann kann man das einfach deployen. Ihr habt es gerade gesehen, wie einfach das war, diesen Docker-Container zu starten. Aber wenn ich das Binary deployen würde, wäre es auch nicht schwieriger. Es wäre auch nicht so schwer, dass man das Binary an sich verabschiedet, auf das man schauen will, wenn man gerade eine Outage hat in seinem Production-System. Weil sonst ist vielleicht das Monitoringsystem auch kaputt. Bei OpenTSDB zum Beispiel, das erfordert einen H-Base-Cluster, in das es seine Daten speichert. Da braucht man zumindest schon mal ein paar Knoten. So viel hat man vielleicht als Privatanwender gar nicht. Und dann muss man das Ganze auch alles maintainen. Und bei Prometheus startet man einfach und dann ist es bereit. Es ist also eine sehr viel geringere Hürde für diese Daten. Okay, dann kommen wir jetzt auf die Datentypen. Den Counter habt ihr gerade schon gesehen. Was euch aber vielleicht nicht ganz klar geworden ist, ist wo ist der Unterschied zwischen dem Counter und einer Gauge. Das ist der zweite Datentyp. Ein Gauge ist ein beliebiger Wert, zum Beispiel die Anzahl an GoRoutines. Das ist das mit dem Process GoRoutines, was ihr vielleicht kurz gesehen habt auf dem Slashmetrics-Output. Und eine Gauge kann hoch und runter gehen. Die ist einfach ein beliebiger Wert. Man kann zum Beispiel für Requestes benutzen. Also den Zähler, den wir gerade eingebaut haben, da ist das ideal dafür. Und was ist der Vorteil, wenn man den Monitoringsystem sagt, welches ist welches, dann kann das System nämlich für ein Overflows und Restarts handeln. Das heißt, wenn mein HTTPServer crashed und von neuem aufstattet, dann geht der Counter ja wieder bei Null los. Aber Prometheus handelt das für uns. Und wenn wir zum Beispiel einen Rate nehmen, dann ist da nicht so ein Riesen Spike, sondern das wird einfach richtig gemacht. Die zwei Datentypen, Histogramm und Summary, die sind beide recht ähnlich. In beides kann man solche Sachen reinwerfen, wie das man sagt. Ich möchte jetzt alle Queries mitloggen bzw. möchte mitloggen, wie lange jeweils die Queries gedauert haben. Also ich könnte sagen, in jedem HTTPS-Händler möchte ich mein Monitoringsystem sagen, so, das hat jetzt 50 Millisekunden gedauert, alle Werte aus der Datenbank zu holen und die Seite zusammenzubauen. Und dann kann man darüber einen Histogramm haben. Also dann kann man sehen, okay, ich habe schon so viel, also 90 Prozent meiner Requests, sind, sagen wir, 100 Millisekunden gehandelt und es gibt ein paar Ausreißer weiter oben. Und es gibt deswegen zwei Datentypen, weil es echt schwierig ist, sowas abzubilden. Also es gibt das Histogramm, das hat den Vorteil, es ist aggregierbar, aber man muss feste Buckets einrichten. Das heißt, man muss vorher sich festlegen und sagen, ich möchte einen Bucket von 0 bis 25 Millisekunden, eins von 25 bis 50, dann sagen wir noch eins von 100 bis 1000, eins noch für 5000, alles drüber ist uns dann egal. Also dann gibt man die Granularität seines Histogramms vor. Dafür kann man es aggregieren. Bei einer Summary ist es andersrum. Da kann man beliebige Quantiles berechnen, hat also keine festen Buckets, die man sich vorüberlegen muss, kann es aber nicht aggregieren. Das ist daher also in Summaries meistens wahrscheinlich nicht so wertvoll wie in Histogramm. Da muss man im Einzelfall jeweils schauen und es gibt auch ein Dokument auf der Prometheus-Webseite, was das genau erklärt, wann man welches verwendet. So, jetzt sagt ihr vielleicht, okay, diesen Queries Counter, da ist ja schön und gut, aber der ist ja nicht ausführlich genug. Was mache ich jetzt? Mache ich auch Queries, die auf eine harte TP 200 geendet haben oder mache ich neue Counter für einen 400er, oder wie aggregiere ich das? Und die Antwort darauf ist Labels. Man kann also mit Labels eine Metrik in viele gleichartige Metriken verwandeln. Der einzige Unterschied zu dem Code, den wir vorher hatten, ist hier diese Zeile und die Zeile hier unten. Das heißt, in der Definition von der Metrik gebe ich jetzt an, welche Labels es geben soll, und das ist einfach ein Stringeray. Das heißt, es kann ein oder mehrere Labels hier geben und wenn ich dann die Metrik verwende, also in diesem Fall den Counter hochzähle, dann muss ich angeben, was meine Label-Values sein sollen. Das ist in diesem Fall mal HardCode 200, aber man würde hier natürlich reinschreiben, welche HTTP Return Code das wäre. Und das ist sehr praktisch, weil man dann schön auch aggregieren kann. Also man kann dann in Prometheus auf diese Labels auch matchen. Man kann sagen, ich möchte jetzt alle HTTP, ich möchte alle Queries zählen, die mit einem HTTP Status kamen, der mit einer 2 anfängt. Also man kann da so einen Rackaxe-Match machen. Oder man könnte sagen, ich möchte alle 4.04 zählen oder alle 4.03, wenn man an bestimmten Metriken interessiert ist, oder einfach über alles drüber aggregieren und sagen, okay, das Label lässt mal außen vor, ich will nur alle Queries zählen. Das kann man auf die Art und Weise recht schön aufspalten. Und in anderen Systemen, soweit ich weiß, in StatsD und GraphFile macht man das normalerweise so, wie man seine Daten aufbaut und strukturiert, dass man das in den Namen reinpackt und dass man nicht spezifisch ein Label dafür haben kann. Und das ist hier, finde ich, eleganter gelöst. Zudem kann man Labels auch festkonfigurieren für bestimmte Tages. Man könnte zum Beispiel sagen, in meiner Config definiere ich ein paar fixe Labels, die auf diese drei Instanzen angewendet werden, aber nicht auf die anderen zählen. Und so könnte man zum Beispiel trennen zwischen der Staging-Umgebung und der Production-Umgebung. Und dann kann man da später verschiedene Graphs verbauen. Man könnte einfach, wenn man die Expression-Abfrage sagt, man in geschweiften Klammern okay, Environment equals Staging oder so, wenn man ein Environment-Label angelegt hat. Und dann kriegt man nur die entsprechenden Graphen. So, Rules. Rules sind einfach Regeln, die das machen, was wir auch gerade eben schon in der Sport gemacht haben. Also die haben einen Ausdruck auf der rechten Seite. Das ist hier ganz unten die Zeile. Und dann mit einem Ist gleich getrennt, werden die Seiten voneinander. Und auf der linken Seite ist der neue Name für eine Time Series, die erzeugt werden soll, basierend auf den Ergebnissen auf der rechten Seite. Wozu sollte man das brauchen? Also Rules sind quasi automatische Queries und die sind sinnvoll, wenn man zum Beispiel vorberechnen möchte. Also wenn man ein Dashboard haben will, was sehr schnell lädt, weil es einfach nur Werte abfragen muss und nicht Werte berechnen muss. Und zwar viele Werte, wenn man weit in die Zeit zurückgeht. Also wenn man sagt, okay, es ist ja ganz schön, dass ich die letzte Stunde habe, aber das langt mir nicht. Ich muss da einen besseren Überblick haben. Ich sage jetzt, statt einer Stunde möchte ich die letzten 90 Tage sehen, dann wartet man normalerweise eine ganze Weile. Aber wenn man sagt, okay, alle Arten von Berechnungen verlagern wir aus dem Dashboard raus in unsere Rules, dann macht Prometheus das auf einer kontinuierlichen Basis und damit verteilt man quasi, wann diese Berechnung stattfinden soll. Außerdem erlaubt es einem, die Rules, falls ein bisschen modularer zu halten. Je nachdem. Das ist ein bisschen Geschmackssache. Das ist nicht nur eine Art Werte. Das ist ein Verspieler der Rules. Beide, die nicht mehr auf die Werte werden können auch schon ganz schön lang werden. Als Beispiel für so eine Rule habe ich die persistierten Nachrichten über alle Notes genommen. Das ist ein Beispiel motiviert aus robust IRC. Und dort ist es so, dass wir drei verschiedene Knoten haben oder auch mehr. Was wir machen ist, wir schauen uns die Metric namens Commit Count an, die ist hier unten dem Job-Label. Also das Job-Label soll vorhanden bleiben, aber alle anderen Labels, die Instance-Labels zum Beispiel, fallen dabei weg. Somit aggregieren wir das über alle Knoten und erhalten nur noch eine Time-Series. Wie als hätten wir quasi einen magischen Knoten abgefragt, der alle diese Werte vereint? Wie man die benennt, ist einem freigestellt. Also nur falls sich jemand fragt, ob diese Doppelpunkte irgendeine Bedeutung haben. Das ist einfach ein Namenschema, was mehr geläufig ist und was ich ganz gut finde. Da unterscheidet man einfach zwischen, worüber aggregiert man, also in dem Fall Job, also alle Robust-ARC-Notes und nicht alle, nicht über Instanzen, dann wie diese Time-Series heißen soll, die man erzeugt, in dem Fall Committal. Und was sie eigentlich genau macht auf einer hohen Ebene und in dem Fall ist es eine Rate über 5 Min und dann eine Sum. Da behält man so ein bisschen den Überblick und es wird klarer, worüber man eigentlich spricht, wenn man mit vielen solchen Rules handiert. Okay, das andere wesentliche Feature ist nicht nur das Prometheus, die Daten aggregiert und einem über Queries ausführen kann, sondern eben auch Alerts. Und ich habe ja schon angesprochen, wofür sie gut sind. Jetzt schauen wir uns doch mal einen On-Detail an. Die Syntax ist, man hat diese uppercase-Keywords hier, man sagt Alert und dann gibt man einen Namen an. Ich habe hier einen Camel-Case-Namen gewählt, Capacity not n plus 1 und dann sagt man, welche Bedingungen hier feuern soll, wie lange sie feuern soll, welche Labels gesetzt werden sollen. Die Summary und die Description. Jetzt noch mal langsam und Schritt für Schritt. Die Bedingung in diesem Fall ist ein Count über die Time Series Up und die Up Time Series ist jetzt eine, die ist ein bisschen speziell. Die wird nämlich von Prometheus selbst erzeugt. Also eine sogenannte Pseudo Time Series und die beschreibt einfach nur, konnte Prometheus im letzten Scrape-Zyklus auf dieses Tage zugreifen oder nicht. Also wenn das Down ist, dann steht hier 0 drin für den Zeitstempel. Wenn das Target Up ist, dann steht da 1 drin. Und jetzt schauen wir einfach, okay, wir schauen ab gleich gleich 1, zählen die Anzahl an Ergebnissen, schauen, ob das kleiner 3 ist, weil 3 ist die Anzahl an Knoten, die wir haben wollen. Also von der Kapazitätsheer ist das n plus 1. Wir brauchen zwei Knoten, das unser n und das plus 1 steht für den dritten Knoten, der also Ausfallsicherheit gewährleistet. Und falls das erfüllt ist, dann soll dieser Alert feuern. Das 430 Minutes steht dafür, dass der Alert nicht sofort loslaufen soll. Also wenn, nämlich angenommen, wir rebooten einen von unseren Servern, dann wollen wir ja nicht sofort einen Alert bekommen, der sagt, hey, deine Kapazität ist zu gering. Ja, das wissen wir ja, wir haben ja den Server rebooted oder vielleicht haben wir ihn nicht selber rebooted, dann ist es natürlich blöd. Aber die Entscheidung ist jetzt hier, es ist so eine Abwägung zwischen, wie schnell will ich alertet werden und wie lange will ich meine Ruhe haben für Routine-Operationen. Und das muss man natürlich dann für jeden Fall genau schauen, so was soll da als Wert reinstehen. Üblicherweise ist es oft wohl auch so, dass man mit einem bestimmten Wert anfängt und den Wert dann später noch tuned, basierend auf Ausfällen, die man gehabt hat. So, das heißt, wenn diese Bedingung hier oben für 30 Minuten lang am Stück auf wahr evaluiert wird, dann wird ein Alert geschickt mit der Summary Capacity less than n plus 1. Das wäre also das, was ich in meiner Android-Notification sehen würde und eine Description, in der ich nochmal mehr Details reinpacken kann. In diesem Fall habe ich gesagt, please replace defaulty nodes, also eine klare Anweisung, was da gemacht werden soll, um Abhilfe zu schaffen. Und in dem ersten Satz gebe ich nochmal an, wie viele Notes im Moment eigentlich da sind. Also das Dollar Value in geschweiften Klammern wird evaluiert zu dem Wert, den dieser Ausdruck hier oben gibt. Gut, hierzu auch nochmal eine Demo, dass ihr seht, wie das Ganze aussieht. Was wir hier zu machen müssen, ist, wir müssen gleich zwei Dateien editieren. Ich mache hier mal eine Rules-Datei, da sagen wir, if rate queries one minute less than 0.1, damit das auch jemals feuern kann, one minute Summary und Description. Das ist jetzt natürlich alles nur für die Demo. Und dann, man kann mehrere Rule-Files hier reinladen. Ich kann mir immer nie merken, ob es Rule-File oder Files ist, das sehen wir aber gleich. Schauen wir mal, ob er das geschluckt hat. Gehen wir wieder auf die Status-Seite hier. Okay, super. In den Rules sehen wir jetzt, also hier steht Alert, Gpn, Demo, if und dann der Ausdruck. Wenn wir auf den Ausdruck klicken, dann sehen wir das hier auch gleich, da sagt er jetzt noch no data points found. Ich glaube, er hat noch nicht gescraped oder ich habe mich irgendwo vertippt. Und genau, darauf gehe ich jetzt im Moment nicht ein. Was wir uns aber noch anschauen können, genau ist das hier. Wenn man oben also auf Alerts klickt, wo ich vorhin auf Graph geklickt habe, dann sieht man eine Übersicht über alle Alerts und die kann man dann aufklappen. Und dann sieht man hier, okay, der ist State-Pending. Pending bedeutet, die Bedingung ist wahr, aber die Hold-off-Time ist noch nicht vorbei. Er sitzt eine Minute, ist noch nicht abgelaufen. Und das wird sich jetzt gleich ändern. Ah, ist auch schon. Ah, nee, noch nicht. Okay, er steht also active, aber wird noch rot, wenn er dann tatsächlich feuert. Okay, da müssen wir jetzt nichts darauf warten. Aber was dann passiert ist, er zeigt ihn hier als rot an und er schickt ihn dann an den Alert-Manager und der Alert-Manager, sofern er denn läuft, ich habe jetzt hier noch keinen gestartet in dieser Demo-Instanz, würde mir dann zum Beispiel auf mein Handy den entsprechenden Alert schicken. Okay, die Demo hauptsächlich dazu, dass ihr seht, wie einfach das ist, einen neuen Alert zu definieren und der ist jetzt da. Also es soll einfach sein, zu sagen, wann soll ich benachrichtigt werden, damit man es auch tatsächlich macht. Wenn das zu schwierig ist, dann kümmert sich keiner darum, das einzurichten. Ihr könnt das mal gedanklich vergleichen, mit wie lange hat es gedauert, das letzte Nagios-Plugin zu schreiben, was ihr geschrieben habt. Okay, jetzt fragen Sie sich natürlich bestimmt einige von euch, das ist ja schön und gut, aber den Hauptteil der Software, den ich monitoren will, den habe ich ja nicht selber geschrieben. Was mache ich denn da? Ich kann ja nicht in allen diese Klein-Libraries rein linken und dazu gibt es mehrere Antworten. Der erste Bullet-Point beschreibt den Node-Exporter. Das ist ein blöder Name. Das hat nichts mit Node.js zu tun oder so, sondern das steht quasi für Knoten in unserem Cluster. Und das ist einfach ein Stück Software von Prometheus, das kann man laufen lassen und dann exportiert der Statistiken über die Festplatten, den Arbeitsspeicher, CPUs Lastung, sowas. Also zu grundlegenden Statistiken, sowas wie man zum Beispiel auch mit Collect die erfassen würde, sowas in die Richtung und was der halt macht ist okay, der schaut sich das an und dann stellt er Prometheus Metricen zur Verfügung. Also der hat, wie wir jetzt gesehen haben, auch in unserem Beispiel so einen Matrix Endpoint und dann sagt man seinem Prometheus, hey, scrape doch mal diesen Node-Exporter und dann kriegt man diese grundlegenden Systemstatistiken. Es gibt auch eine Stats-D-Bridge, es gibt vielleicht auch mehrere, also für andere Protokolle dann und was eine Bridge macht, ist sie überträgt von einem ins andere Protokoll. Also in diesem Fall liest sie Stats-D-Daten und exportiert dann Prometheus-Daten. Und das kommt einfach daher, dass bei Soundclouds sie einen Stats-D-basierendes Monitoring-Setup hatten und das dann auf Prometheus migriert haben und da haben sie diese Bridge für geschrieben, damit das schnell funktioniert. Und zu guter Letzt gibt es sogenannte Exporter sowie den Node-Exporter, aber eben für andere Software. Es gibt zum Beispiel ein Exporter für Redis, es gibt ein für MySQL, für Apps, die auf der JVM basieren für einige Sachen und wenn es noch keinen gibt, den man braucht, dann kann man einschreiben und den dort kontributen und dann freuen sich die Leute. So funktioniert das also konzeptionell. Das heißt immer, wenn man ein Stück Software hat, sagen wir eine MySQL-Datenbank, die noch nicht selber Prometheus-Metering exportieren kann, dann lässt man eben noch ein kleines Programm daneben laufen und das macht das dann für einen. Gut, jetzt zeige ich mal noch ein paar Beispiel-Rules, damit man auch sehen kann, dass das recht schnell recht komplex werden kann, aber auch recht schnell recht mächtig. Worum es hier geht, ist ein Leaderwechsel. Auch wieder ein Robust-ARC-Beispiel, wie man an den Job-Labels hier sehen kann. Und Robust-ARC basiert auf RAFT und bei RAFT gibt es das Konzept, dass Knoten entweder in einem Leader-Zustand sind oder im Follower-Zustand oder in der Election. Und was man also schauen will, in diesem Fall ist, wie häufig passiert einen Wechsel zwischen Liedern, weil eigentlich sollte das Netz ja stabil laufen und der aktuelle Leader sollte lange Leader bleiben, bis ein anter Knoten ausfällt. Und was man jetzt damit checken kann, ist, wenn der Wechsel zu häufig passiert, dann ist vielleicht irgendwas falsch konfiguriert. Vielleicht sind die Timeouts zu aggressiv gesetzt, vielleicht gibt es einen Bug, vielleicht restartet die Software oder sowas. Da will man sich auf jeden Fall mal mit befassen. Wie machen wir das jetzt? Es gibt eine Metrik namens RAFT ist Leader und die ist einfach 0 oder 1, das ist ein Bool sozusagen. Und da schauen wir uns das Derivative an, also die Ableitung davon. Wenn das gleich bleibt, dann ist das 0, wenn es höher wird oder tiefer wird, dann 1 oder minus 1. Und deswegen nehmen wir auch gleich noch den Absolutwert davon, weil wir nur interessiert sind, ändert es sich oder ändert es sich nicht. Dann aggregieren wir das Ganze, so wie vorhin auch wieder, some by job bedeutet also, die einzelnen Instanzen sind uns egal. Wir möchten dieses Monitoring auf Netzwerkebene machen, also RAFT-Netzwerkebene in diesem Fall. Und jetzt kommt der Clue, der wahrscheinlich ein bisschen schwieriger zu verstehen ist. Jetzt hat sich rausgestellt, am Anfang hatte ich nur den ersten Teil dieser Regel. Und dann passierte Folgendes. Ich habe zwar mitbekommen, wenn sich der RAFT-Leader zu häufig gewechselt hat, also wenn das unabsichtlich war, aber auch wenn ich einen Knoten aktualisiert habe, also eine neue Software-Version gepusht habe und dann die Knoten neu gestartet habe, hat diese Alerting Rule gefeiert. Das einfach deswegen, weil dadurch, dass sich alle Knoten neu starten muss, bei einem Software Update, muss auch unweigerlich der Leader neu gestartet werden, wodurch er eben nicht mehr der Leader ist und dann gibt es einen Leader Flap. Deswegen habe ich mir überlegt, wie könnte ich das unterdrücken? Also wie könnte ich das so machen, dass Leader wechseln nur dann, dass ich nur dann einen Alert bekomme, wenn es Leader Flaps gibt, obwohl das Netz eigentlich stabil sein sollte. Und das versuche ich hier mit dem Leader Flaps stable zu sagen. Und wie das umgesetzt ist, es gibt hier eine Process Start Time Metric und die sitzt einfach fix auf dem Unix Time Stamp, wann die Software gestartet wurde. Und wenn ich mit der Time Funktion mit den aktuellen Zeitstempel, also zu dem Zeitpunkt des Scrapes geben lasse, minus die Process Start Time, dann kriege ich quasi die Abtime des Prozesses in Sekunden raus, dann vergleiche ich, ob das größer ist als 5 mal 60, also 5 Minuten, zähle das Ganze und wenn das größer gleich 3 ist, dann kommt hier also eine 1 raus, ansonsten eine 0 und dann multipliziere ich das Ganze. Das heißt, so habe ich quasi verkettet, wenn das Netz schon lang genug läuft, also schon 5 Minuten läuft und das flappt immer noch der Leader, dann ist irgendwas im Busch. Das bedeutet hier dieser lange Ausdruck. Gut, ich habe noch einen. Hier möchte ich illustrieren dieses Filtern basierend auf den Labels. Also hier habe ich mir überlegt, was bedeutet eigentlich Verfügbarkeit in robust RSC? Also was interessiert eigentlich die Kleins? Ja, die interessiert ja nicht, wie häufig wechselt sich der Leader. Das ist ein Implementationsdetail. Die interessiert eigentlich nur, wenn ich eine Nachricht schicke, kann die angenommen und verarbeitet werden von dem Netz. Und damit das der Fall ist, muss es so sein, dass genug Knoten entweder im Leader oder im Follower-Zustand sind. Und das mache ich also hiermit. Ich habe eine neue Metrik eingeführt, namens Seconds in State und ich habe eine Godoutine, also so was wie ein Threat, der einmal in der Sekunde läuft und schaut, in welchem Zustand bin ich gerade und dann zählt er den jeweiligen Zustand hoch. Das heißt, der setzt einen Label für den jeweiligen State. Der State kann entweder Leader oder Follower oder Candidate sein oder leer. Und hier ist jetzt der Clue, wenn ich jetzt einfach die naive Herangehensweise nehmen würde und sage, okay, ich nehme Seconds in State und teile das durch, also ich nehme Seconds in State über eine Minute und teile das durch 60 Sekunden, dann werde ich feststellen, dass die Availability manchmal so ein klein bisschen unter 100% sagt, obwohl das Netz okay ist. Und das liegt ganz einfach daran, dass es einen gewissen Time Drift gibt im Scheduling von meiner Godoutine, was aber jetzt nicht inherrennt für Go ist, sondern einfach generell bei Computern ebenso ist. Man kann ja nie immer die Arbeitsschädulung, die man gerade machen möchte. Und man läuft nie so präzise, dass das nicht auftritt. Und deswegen machen wir das so, dass wir schauen, okay, wie viele Sekunden sind überhaupt da? Also wir nehmen die Rate of Seconds in State ganz ohne Labels und dann nehmen wir die spezifischen Labels und kriegen so also einen Prozentsatz raus, wie viel Prozent der abgelaufenen Zeit waren wir im Leader oder im Follower Zustand. Und das wiederum wird dann eben unter Job Instance Availability Some Rate gespeichert. Und wenn ich mir das plotten lasse in einem Graf, dann sehe ich, okay, wenn das eine gerade Linie ist auf der 100 oder auf der 1 in dem Fall, weil es eine Percentage ist, dann ist mein Netz perfekt verfügbar und immer wenn es da einen Drop gibt, dann war da irgendwas. Da müsste ich mir das vielleicht anschauen. Gut zu Alerts möchte ich, wo ich hier gerade die Bühne hab, noch ein bisschen drauf eingehen, dass es wichtig ist, auf was man alertet. Und viele Leute machen sich da intuitiv erst mal gar keine Gedanken. Es gibt einen super Artikel, den ich euch empfehlen möchte zu lesen, der nennt sich My Philosophy on alerting. Und ich hab mal zwei Punkte rausgegriffen, aber die sind bei weitem nicht alles, aber die zwei Punkte sind für mich meiner Meinung nach am wichtigsten. Das erste ist, dass man auf Symptome alerten sollte, nicht auf Ursachen. Ich möchte das an einem Beispiel verdeutlichen. Ein Symptom wird zum Beispiel die Webseite lädt so langsam oder sie liefert einen Fehler aus. Eine Ursache wäre die Festplatte ist voll von meinem Knoten, die MySQL Datenbank läuft nicht, die MySQL Datenbank ist falsch konfiguriert. Da gibt's eine Million Gründe, warum irgend so was schiefgehen könnte. Aber der Clue ist jeden Alert, den man hinzufügt. Der hat auch eine gewisse Maintenance-Cross. Da muss man schauen, wenn der fired, ist das tatsächlich ein Problem oder hat der jetzt geired, weil irgendwas passiert ist, was wir entweder erwartet haben oder weil unsere Definition falsch war. Das kann alles passieren und das passiert in der Praxis. Und deswegen ist es ratsam, wenig Alerts zu haben, die genau auf das schauen, was das Symptom ist, was ihr nicht haben wollt. Und der zweite Punkt ist, dass die Alerts actionable sein sollen. Ich entschuldige mich ein bisschen für das Manager-Sprecher, aber mir ist kein besseres Wort in den Sinn gekommen. Actionable bedeutet, ihr könnt auch tatsächlich was machen. Also, wenn ihr den Alert bekommt, dann bekommt ihr den nicht nur und seht, okay, ist klar, weil ich mache ja gerade XY, das ist dann vielleicht ein Fehler in eure Definition oder ja, ist klar, aber was soll ich machen? Ich kann hier nichts machen. Wenn man Sachen hat, auf die man alertet, bei denen man nichts machen kann, dann braucht man auch nicht Alerten. Das nervt nur die Leute und dann bekommen sie Alerts und können nichts machen. Das ist ein sehr frustrierendes Gefühl. Und der zweite Punkt ist, das soll auch nicht automatisierbar sein. Also, wenn man den Alert bekommt, das Einzige, was man macht, ist, man gibt irgendwie drei, vier Befehle ein. Dann ist die Frage, warum haben wir nicht dem Computer gesagt, wenn das passiert, dann macht das. Ja, das ist ein Programm. Das könnte man doch programmatisch lösen. Und solche Sachen sind in diesem Dokument beschrieben. Ich würde es euch raten, das zu lesen, ist sehr erleuchtend. Okay, jetzt die dritte und damit vorläufige letzte Demo in diesem Vortrag, ein paar Dashboards. Wir haben jetzt uns das angeschaut und sind ein bisschen in die Theorie abgeschweifft. Und jetzt dann doch noch mal, wie kann das aussehen und was sind eigentlich die Unterschiede zwischen den drei Dashboards Lösungen, die ich hier zeige. Es gibt mit Sicherheit noch mehr, aber das sind die drei Hauptlösungen, die mir bekannt sind. Das erste, ich erkläre es erst kurz und dann schauen wir es uns an. Das erste sind Console Templates. Was das bedeutet, ist, dass man ein HTML Template nimmt und es in seinen Prometheus Directory legt und Prometheus liefert das dann aus über htdp. Der Vorteil davon ist, dass man diese Console Templates in Versionskontrolle haben kann. Also die kann man in den Git werfen und dann sieht man genau, was sich man, wo wie ändert. Und zusätzlich werden sie von Prometheus ausgeliefert. Das heißt, sie sind sehr ausfallsicher. Also wenn das Monitoring System da ist, sind automatisch auch die Dashboards da. Das ist eine gute Eigenschaft zu haben. Schauen wir uns doch mal an, wie das Ganze aussieht. Ich habe hier ein ganz simples Console Template gebaut. Man sieht hier wieder Prometheus-Header. Da muss ich ein bisschen rauszoomen, damit das schöner aussieht. Nicht alle Grafen funktionieren, weil, als ich das gebaut habe, hat sich rausgestellt, eigentlich möchte ich das nicht verwenden. Hier oben rechts sieht man ein paar Sachen, die evaluiert wurden. Also wo einfach der letzte Wert angezeigt wird. Hier sieht man ein paar Queries. Das ist genau dieselbe Anzeige, wie sie Prometheus selber auch zur interaktiven Benutzung anbietet. Hier sieht man ein paar Grafen, die ich da eingebaut habe. Soweit so gut. Der Vorteil ist, dass man das unter Versionskontrolle haben kann und dass es sehr verfügbar ist. Der Nachteil ist, man hat auch nicht so furchtbar viel Möglichkeiten und es sieht auch nicht so super gut aus. Da muss man wirklich abwägen, ob das was ist, was man tatsächlich möchte. Die zweite Dashboard-Lösung ist Prom-Dash und das zeige ich hier mal. Da sind leider die Grafen leer. Muss ich kurz mal schauen, ob ich das aktualisiere? Wird es auch nicht besser. Warum? Okay. Ich beschreib es erst mal konzeptionell und vielleicht fällt mir da noch ein, warum die alle leer sind. Prom-Dash ist eine Ruby on Rails-Applikation, die auch von Prometheus geschrieben wurde und das ist das, was die verwenden. Und der Punkt ist, dass man sehr einfach und interaktiv hier Dashboards zusammenklicken kann. Also man kann hier ganz unten hat man so Buttons und dann kann man sagen add Graph und dann kann man sagen, ich adde hier eine Expression, sagen wir z.B. Queries, dann Autocompletet er das sogar und dann, dass ich mir das hier anzeige und dann sieht man, aha, okay, so sieht das aus, dann sage ich, okay, raid, one minute, mache ich vielleicht das, klick hier auf refresh, dann macht er irgendwas und wenn ich dann zufrieden bin damit sage ich, safe changes und der speichert das in der MySQL-Datenbank. Der Vorteil ist, das ist sehr interaktiv und funktioniert recht gut und damit habe ich auch sehr lange meinen Monitoring gemacht für robust RSC und das läuft auch immer noch darauf. Der Nachteil ist, es ist natürlich eine komplett separate App, um die man sich kümmern muss, es ist den Ruby on Rails geschrieben, es erfordert MySQL, das ist vielleicht nicht was, was man im kritischen Pfad haben will in seiner Monitoring-Infrastruktur. Deswegen war ich dann recht happy, als ich die dritte Lösung gesehen habe, nämlich Grafana. Grafana ist ein sehr cool aussehendes meiner Meinung nach Tool, welches einem erlaubt, aus verschiedenen Datenquellen grafen zu bauen. Ich habe das früher auch schon verwendet zusammen mit Influx-DB, bevor ich wusste, dass es Prometheus gibt und ich zeige euch einfach mal hier, wie das aussieht. Ich hoffe, das kann man, denke ich, gut genug sehen. Das ist jetzt das Debian Code Search Monitoring und in Grafana kann man jetzt verschiedene Dashboards anlegen. Hier habe ich mal zwei verschiedene Dashboards. Ich habe zum Beispiel noch ein spezifischeres für die verschiedenen Indexbackends. Also hier sehe ich jetzt für jede VM. Man sieht hier, das ist vm.0. Ich kann hier auch sagen, okay, ich möchte jetzt auch vm.1 schauen und dann sehe ich die Grafen, die sich aktualisieren dafür. Man kann da durchgehen und das hat dieselben Vorteile, wie auch Prom-Dash. Also man kann das editieren und dann direkt hier die Expressions ändern, lauter so Sachen. Also es bedient sich meiner Meinung nach sehr angenehm. Es hat coole Möglichkeiten. Also man hat hier diese Unterteilung in seinem Dashboard und so weiter. Also mir gefällt das persönlich sehr gut und es ist auch sehr einfach aufzusetzen. Früher war das so, dass das einfach ein bisschen JavaScript war und ein paar HTML-Files und Assets, die man in den Webserver gelegt hat und da wurde das geserved. Mittlerweile haben sie es so gemacht, dass es ein eigener in Go geschriebener Webserver ist, also wieder selbe Charakteristiker. Man hat einfach einen Binary, es wird statisch kompiliert, dann läuft das oder läuft auch nicht. Und dann kann man damit auch Benutzer anlegen und so weiter. Also sie haben quasi den ganzen Teil, den man vorher aus und drum selber konfigurieren musste, jetzt in so einen Go-Server gepackt. Man kann es aber natürlich immer noch hinter einem eigenen Server laufen lassen. Meine persönliche Zusammenfassung von der Dashboard-Situation ist, dass wenn ihr wirklich sehr viel Wert darauf legt, dass eure Dashboards hoch verfügbar sind und unter Versionskontrolle sind, dann verwendet die Console-Templates. Sie sehen zwar nicht besonders hübsch aus, aber die haben eben diese Charakteristiken. Und wenn ihr ein ordentliches Dashboard haben wollt, also ein schönes Dashboard, was sich einfach und schön bedienen lässt und sehr dynamisch ist, dann schaut euch doch mal Grafana an. Okay, so viel dazu. Jetzt zuerst noch, ich habe ein Feedback- Formular vorbereitet, weil es mich sehr interessieren würde, ob euch der Vortrag gefallen hat. Also gebt mir doch bitte Feedback zum Vortrag. Da unten ist die URL, das ist auch dieser QR-Code, wenn ihr es jetzt sofort gleich machen wollt. Ansonsten auch im Fahrplan wird das nochmal gelingt. Unter Prometheus.io findet ihr die Webseite von Prometheus. Ich kann das sehr empfehlen. Die Dokumentation ist sehr gut. Die Webseite ist grafisch ansprechend. Die Community ist auch sehr lebhaft. Es gibt einen IRC-Channel, es gibt eine Mailing-Liste, die Github-Isschüs sind, werden sehr schnell bearbeitet. Wenn man einen Pull-Request schickt, bekommt man sehr schnell Feedback und so und die nehmen auch gerne Fixes für Dokumentationen auf und so weiter. Also es ist ein sehr lebhaftes, aktives Open Source-Projekt, was hauptsächlich von SoundCloud getrieben wird, aber auch von anderen Firmen benutzt wird. Ich glaube, in Docker gibt es Leute und das Team, was das Hauptentwickel ist, so ein bisschen zusammengesetzt aus verschiedenen open-source-freundlichen Firmen. Gut, damit bin ich jetzt mit dem, was ich vorbereitet habe am Ende und jetzt haben wir Zeit für Fragen. Okay, Moment, Mikro, damit das auch auf der Aufzeichnung dann später zu hören ist, ohne dass ich es noch mal alles wiederholen muss. Bei Grafana, wo werden da die Konfigurationssachen abgespeichert? Die Konfiguration in Grafana wird auf dem Data-System des Servers abgespeichert, wo du das laufen hast, also den Grafana-Server. Du kannst aber auch dir das komplette Dashboard einfach als JSON-Konfiguration exportieren lassen. Und das ist nicht ein Exportformat, sondern der Speicher das intern auch wirklich in JSON ab. Das heißt, du kannst das, so mache ich das momentan, also wenn man das robust RSC, beziehungsweise das Code Search Repo auscheckt, dann findet man da im Contract Folder sowohl die Alerting Rules als auch die Konfigurationen, als eben auch das Grafana-Dashboard als JSON-Export, so dass man das auch einfach schnell wieder reinladen kann, wenn man eine neue Instanz davon aufsetzt. Weitere Fragen. Okay, hier vorne zuerst. Gibt es Möglichkeiten, dass sich die Services irgendwie registrieren bei Prometheus, als Prometheus selber kennt, dass ich nur sage, ja, das ist mein 3-Server. Und da mache ich Ihnen ein Stratzeug und bitte mach, lasst mich nicht konfigurieren. Ich möchte einfach eine schöne Grafen haben und am besten erst dann, wenn es kaputt geht. Und vorher will ich von Ihnen was wissen. Ja, es ist eine schöne Frage. Es gibt in Prometheus momentan, ich glaube, zwei oder drei implementierte Strategien, wie man die Tagels finden kann. Die eine Strategie ist das, was ich vorgestellt habe. Du hast einfach das Konfig, weil du schreibst einfach eine Hostport Kombination rein. Also URL ist besser gesagt. Dann gibt es DNSSD-basierten Lookup, also du machst ein DNS Query und schaust, welche Werte kommen da zurück. Und das kannst du kombinieren mit sowas wie Zookeeper, wo du also eine Dienste-Registration hast. Also alle Dienste melden sich in dem Zookeeper-Cluster an und Prometheus fragt einfach, okay, welche Dienste sind da? Kriegt die Hostports zurück von allen und fragt die an. Wenn du irgendwas hast, was darüber hinausgeht, also was nicht über DNS gemappt werden kann, dann kannst du sich sicherlich auch mit denen Verbindung setzen, dasselbe implementieren. Kann ich für alles, was ich so in Code gießen kann, auch so einen Exporter schreiben? Wenn ich mir überlege, beispielsweise bei einem Mail-Server, will ich ja eigentlich wissen, kann ich da jetzt gerade Mails durchschicken und ich will nicht erst darauf warten, bis mir jemand eine Mail schickt und dann guckt, ob das klappt oder nicht. Das ist eine sehr gute Frage. Da muss man ein bisschen ausholen. Also die Infrastruktur ist üblicherweise bei solchen Set-ups, wie hier, bisschen 2 geteilt. Also man hat so ein, das Monitoring, dann das Alerting und dann hat man ein separates Set an Infrastruktur, was mir unter dem Namen Prober geläufig ist. Und Kanla, was ich im vordrängen Jahr hier vorgestellt habe, ist zum Beispiel ein solcher Prober. Das heißt, das ist ein Programm, da konfigurierst du, ich möchte, dass dieser Dienst hier verifiziert wird und dann macht er das. Also dann würde er sich zum Beispiel jede Minute auf deinen Mail-Server verbinden und versuchen, eine Mail über SMTP abzuliefern. Und das kannst du natürlich kombinieren. Zum einen kannst du deinen Prober-Monitorn und kannst schauen, okay, im letzten Run war der erfolgreich oder nicht und dann alertest du auf das. Oder du kannst an beiden Seiten dann schauen. Du kannst schauen, war der Prober erfolgreich und hat der Mail-Server in diesem Fall jetzt eine bestimmte, bestimmten Wert in dieser Metrik exportiert, werdend Air Traffic gehandelt hat. Und dadurch, dass der Prober läuft, weißt du, da ist auch Traffic da. Also ich könnte quasi mir den Prober schreiben und da dann sozusagen das Prometheus-Logging reinhängen und dann den einfach als Binary auf dem Ding laufen lassen. Genau. Du sagtest, dass es Exportort gibt für Applikationen, die man dann daneben betreiben kann, wenn man jetzt Geräte hat, die von den man Metriken erfassen will, auf den man jetzt nicht Applikation installieren kann. Es ist dann ein valider Weg, dass man sagt, ich exportiere Daten, die ich per SNMP hole oder es ist eine dumme Idee. Das ist auf jeden Fall eine gute Idee, denke ich. Also wenn du, also genau, SNMP bei Geräten wie Switches, zum Beispiel, Netzwerkenfrastruktur, da würdest du einfach auf einer Kiste, die vielleicht im selben Rack hangt oder so, die du dort ohnehin schon stehen hast, so einen Exporter laufen lassen. Eine dritte Lösung ist folgende. Du kannst dieses Slashmetrics, was ich vorhin vorgestellt habe, wo wir gesehen haben, in plaintext kommen da einfach die Key Value Paare. Tatsächlich kann Prometheus nicht nur JSON lesen, sondern auch diese plaintext Rezentation. Das heißt, sofern du irgendwie dein vielleicht Embedded Device oder Gerät, was auch immer jetzt mal im generischen Fall, dazu bekommst, dieses Format zu sprechen und da Daten zu exportieren, könntest du es direkt scraten. Danke. Hier vorne rechts, genau. Gibt es für das Alerting schon eine Anomalie Detection, also, dass man sozusagen deine Tageslastkurven hat und dann wirklich die Ausreißer da auch erkennen kann? Auch eine schöne Frage. Meines Wissens nach Nein. Ich denke auch persönlich von dem, was ich so mitbekommen habe, ist Anomalie Detection ein wirklich schwieriges Thema in dem ganzen Monitorium-Umpfeld. Also es gibt immer wieder Leute, die sagen, hey, wir haben da was, sondern stellt sich raus, funktioniert doch nicht so gut, wie man sich das gerne, wie man sich das vorstellt. Und soweit ich weiß, Nein, aber vielleicht einfach mal auf der Mailing-Liste fragen, vielleicht hat tatsächlich schon mal jemand, was damit gebastelt. Danke. Noch weitere Fragen. Hier vorne, ja. Kann man auch die Rate der Alerts abfragen. Das heißt, ich schicke normal eine E-Mail und wenn ich mehr als zum Beispiel 10 Alerts in 10 Minuten habe, schicke ich eine SMS. Ja, gute Frage. Ich denke, am ehesten würdest du zu sowas hinkommen, indem du Pager-Duty verwenden würdest. Die machen nämlich genauso was, also, dass du verschiedene Eskalationsstufen hast, auch mit verschiedenen Leuten, dass du so ein Schichtesystem hast. Und der Alertmanager, von dem ich vorhin kurz gesprochen habe, der kann sich mit Pager-Duty integrieren. Da müsstest du also auf diesen Trittdienst zurückgreifen oder dir vielleicht selber was basteln und dann mit dem Alertmanager kombinieren. Da gab es noch eine Frage, genau. Wie skaliert das Ganze oder wie viele Checks sozusagen oder wie viele Hosts kann ich da auf einen Host monitoren? Wie ist das Datenablag eskaliert? Gute Frage. Die Prometheus-Leute selber sagen, dass du Tausende Tagels konfigurieren kannst auf einem Prometheus-Knoten und hunderttausende Time-Series. Also ich denke, selbst in großen Firmen tust du dich schwer, mehr als irgendwie, keine Ahnung, zwei, drei, vier Prometheus-Knoten aufsetzen zu müssen für die Last, die man wahrscheinlich damit hat. Nachtrag? Muss ich die dann alle einzelnen ansprechen? Ich zum Beispiel für eine Applikation wende ich mich dann an die eine Instanz für die andere an die andere Instanz oder gibt es da eine Art Federation? Auch eine sehr gute Frage. Im Moment würde man wahrscheinlich es so aufbauen, dass du wie du vorgeschlagen hast für eine Anwendung auf einen Prometheus-Knoten schauen würdest. Der Plan ist und das ist auch dokumentiert in GitHub Issue Nummer 9, dass es eine Federation gibt. Das heißt, dass du mit einer Prometheus-Instanz, anderer Prometheus-Instanz in Scrapes sozusagen wahrscheinlich nicht über dasselbe Protokoll, sondern über was Besseres für diesen Anwendungsfall und darüber dann Metriken aggregieren kannst, auch über verschiedene Prometheus-Knoten hinweg. Hier vorne gab es noch eine Frage. Du hast ja vorhin Nagius erwähnt, das wird ja oft für so 0815-Standard-Dinger benutzt. Ich will jetzt wissen, der HTTPS wird da, der HTTPS wird da, ist das Zertifikat noch gültig, diese ganzen 0815-Anwendung. Gibt es da fertiges Sachen oder muss ich das selber instrumentieren? Es gibt für gewisse Sachen fertige Sachen, also es gibt zum Beispiel fertige Console-Templates für verschiedene Dienste. Ich könnte mir auch gut vorstellen, dass so wie ich das zum Beispiel mache mit CodeSearch, dass Dienste einfach in Zukunft selber ihre passenden Monitoring-Regeln mitbringen oder dass man so ein Community-Report aufzieht, wo eben ganz viele verschiedene vorgefertigte und erprobte Lösungen schon drin sind. Da hinten noch eine Frage. Kann ich um die Report, die Prometheus sich holt, irgendwie unter Authentication setzen? Ich könnte mir vorstellen, wenn ich irgendwelche sicherheitskritische Sicher-Infrastruktur habe, will ich ja nicht, dass jeder lesen kann, was da gerade abgeht. Auf jeden Fall. Also das Einfachste ist natürlich Basic Authentication bei HTTPS und dann über HTTPS Scrape. Das machen wir so für robuste RC und damit hast du dann klar, ja, Authentifizierer. Okay, dort noch eine Frage. Du hast ja vorhin ganz kurz Influx, die wir erwähnt. Damit habe ich auch schon mal ein bisschen rumgespielt. War die Datenmigration da einfach oder hast du alles weggeschmissen einfach nur aufgesetzt? Ich habe alles weggeschmissen einfach, ja. Ich weiß gar nicht, ob die Migration einfach gewesen wäre. Also es gibt ja manchmal es gibt manchmal Möglichkeiten für so ein Badge-Import. Also dass man einfach sagt, ich habe hier hoffenweise Times-Series, ich möchte jetzt da reinknallen und das sind auch schon die Times-Stamps dabei. Aber ich habe nicht gesehen bislang beim drüberlesen, dass Prometheus so was anbieten würde. Deswegen denke ich auch, dass es das momentan nicht hat. Müsste es aber vielleicht nochmal genau nachschauen. Vielleicht ist das auch geplant. Noch weitere Fragen hier vorne. Wie schaut es aus mit Failover und Availability von Prometheus selber? Also wie handelt Prometheus das? Die Idee ist, dass du mehrere Prometheusknoten, also verteilt in verschiedenen Failure-Doments laufen lassen kannst, die dann alle mit dem Alertmanager sprechen. Jetzt natürlich die nächste Frage, wie macht man den Alertmanager face-safe? Und da ist die Antwort, dass der Alertmanager so wie momentan ist, wahrscheinlich eine schlechte Wahl war und dass sie ihn neu schreiben wollen. Vermutlich mit Raft oder sowas unten drunter, so dass du dann auch wieder mehrere Knoten laufen lassen kannst und damit dann High Availability erreichen kannst. Okay, danke. Noch weitere Fragen? Ja, ganz dahinten. Wenn man für High Availability jetzt mehr Instanzen hat und es wie vor angesprochen noch nicht die Federation gibt, heißt es dann, man muss die alle einzeln konfigurieren? Das kommt darauf an, wie du deine Konfiguration erledigst. Also wenn du ein System hast, welches seine Konfig verteilt auf verschiedenen Instanzen dann nicht. Ansonsten, ja. Okay, noch andere Fragen? Ja, davon noch mal. Du hattest die Go-Bibliothek gezeigt, mit der man Prometheus was sagen kann, gibt es das auch für andere Sprachen? Ja, genau. Das gibt es auch für einige andere Sprachen. Und sie bitten auch darum, dass wenn ihr eine Sprache benutzt, in der es noch keine Bibliothek gibt, dann vielleicht was beisteuern. Es ist, wie man gesehen hat, relativ einfach zumindest mal so ein plain Text-Format hinzubekommen und für alles Abgefahrenere, also für dann Labels und Histogramme und so was müsste man dann halt eine kleine Library haben. Aber für die meisten großen Sprachen ist das alles schon erledigt. Ich glaube, dahinten gab es noch eine Frage? Oder auch nicht mehr? Okay, ansonsten noch jemand eine Frage? Ja, davon. Ich hätte eine Frage zu dem du hast ja die L-Art so gebaut, dass die darauf reagieren, wenn du es in Upgrade fährst, dann gleistert es aus, doch die Kompensität der Regel. Wäre es nicht sinnvoller, dass du quasi sagst, ich habe ein System, das deployt meine Updates und wenn Updates deployt werden, dann disabel ich den L-Art. Ist das nicht einfacher oder weniger anfällig? Guter Punkt, das wird in der Praxis auch gelegentlich so gemacht. Also das würde dann über den Begriff Silence fallen. Also du kannst Alerts silenzen. Du könntest dann sagen, okay, meine Rollout Automatisierung schickt einfach vorher einen Request an Prometheus und sagt, hey, bitte mal diese Alerts alle silenzen. Ich mache jetzt ein Update und dann entfernt er die Silence wieder. Durch jetzt auch ein legitimer Ansatz. Ich habe das bei mir einfach ich habe für den Anwendungsfall, den ich habe, keine Automatisierung für die Rollouts. Also ich habe Automatisierung für die Rollouts, aber nicht irgendwie zentral oder irgendwo. Und deswegen möchte ich diese Abhängigkeit zwischen dem Monitoring System und der Automatisierung gerne vermeiden. Deswegen habe ich einfach gesagt, dann mache ich einfach die Regel robuster. Geht auch. Okay, danke. Okay, zum Abschluss noch eine letzte Frage. Ansonsten ist es auch so, wenn euch noch Fragen einfallen oder ihr sonst noch Anmerkungen, Kommentare habt, bin ich auch noch auf der Veranstaltung. Ihr dürft mich auch gerne dazu ansprechen. Ansonsten wendet euch einfach an die Community. Sie ist sehr gut. Damit Danke für die Aufmerksamkeit und viel Spaß.