 Einen wunderschönen guten Morgen an Tag 3 der Gulasch-Programmier nach 2019. Es ist 13.30 Uhr. Schön, dass ihr schon sozialrecht da seid zu dieser frühen Stunde. Bei diesem Talk dürft ihr sogar gerne Zwischenfragen stellen. Wenn ihr eine Zwischenfrage stellen wollt, wartet bitte, bis ich mit dem Mikro bei euch bin, damit wir die Frage auch auf dem Stream und im Recording haben. Das wäre ganz lieb von euch. Ansonsten kein Housekeeping, das heißt wir können sofort beginnen und ich überlasse die Bühne einem Vortragenden, der über das Thema spricht, das auf der Liste der Ja, das sollten wir jetzt wirklich demnächst einmal dringend einrichten, Dinge auf Platz 2 steht, kurz hinter Backups, nein, Platz 3, weil zuerst Backups, dann Restore und dann Monitoring, so üblicherweise. Das heißt auf der Bühne mit Monitoring, mit einer Kiste, aber mehreren Leuten, chatte. Schönen guten Morgen. So, einen wunderschönen guten Morgen. Genau, also es geht in diesem Talk um Monitoring, deswegen mal alle mal die Hände in die Höhe, so zum Wachwerden als Wachwerdeübung. So, jetzt nehmt eure Hände runter, wenn ihr keine eigene Infrastruktur betreibt. Okay, die allermeisten betreiben jedoch eigene Infrastruktur. Behalt eure Hände oben, wenn ihr dafür schon Monitoring habt, anderenfalls nehmt ihr mal runter. Okay, die meisten haben sogar Monitoring für die Kisten. Nicht schlecht, nicht schlecht. Gut, Monitoring, Monitoring ist so eine Sache, die sollte man haben, die will man aber eigentlich, also man braucht sie, aber man will sie eigentlich nicht und wenn man irgendwie so einen Server betreibt, dann müsste man sich ja fürs Monitoring eigentlich noch einen Server holen, dann irgendwie zwei Server haben, nur um den einen dann zu monitoren und eigentlich braucht man ja für redundantes Monitoring haben, wird dann irgendwie dreist. Es wird sehr schnell, sehr, sehr viel teurer, als man das eigentlich haben möchte. Deswegen haben wir uns was überlegt, wie man das eventuell lösen kann, indem man sich einfach Monitoring-Infrastruktur teilt. Wir machen einfach eine Monitoring-Kiste irgendwo hin und die Monitor hat die gesamte Infrastruktur. Wie machen wir das Monitoring? In diesem Vorschlag, wie man das bauen kann, basieren, kurz über die Grundidee, was wir haben wollen. Wir wollen einen Komplettpaket haben, das heißt wir wollen nicht nur, also je nachdem wie man Monitoring definiert, Komplettpaket heißt wir wollen auch Allerting haben, wir wollen auch irgendwie eine Information kriegen, wenn Dinge kaputt gehen und nicht nur sehen, ah ja, jetzt hätte ich da sehen können, dass Dinge kaputt gewesen wären, toll. Das ist irgendwie unhilfreich. Wir wollen es möglichst günstig haben, weil das eine Komponente ist, die wir idealerweise nie brauchen werden und wir wollen es möglichst einfach haben, damit es uns nicht im Weg herum steht. So, Monitoring in diesem Vorschlag machen wir mit Prometheus. Alle Hände noch mal in die Höhe. Lasst eure Hände oben, wenn ihr Prometheus kennt. Okay, lasst eure Hände oben, wenn ihr schon mal mit Prometheus gearbeitet habt und dann noch weniger und lasst eure Hände oben, wenn ihr momentanen Prometheus im Produktivbetrieb habt. Alles klar, wunderbar. So, was ist eigentlich dieses Prometheus? Gucken wir uns das doch mal an, ich habe da mal was vorbereitet. So, das ist einfach ein Ordner. Könnt ihr das alle lesen? Wahrscheinlich nicht. Ja, okay. Ich kann noch ein bisschen größer machen. So, genau. Also, was wir hier haben, ist ein Ordner, da liegen so ein paar Dinge drin und zum Beispiel liegt da ein Prometheus-Jammel drin. Das ist die erste Konfig, die wir uns anschauen werden. Also Prometheus funktioniert folgendermaßen. Man hat erstmal seinen Prometheus-Server. Dieser Prometheus-Server ist einfach eine Software, die geht hin und holt sich in regelmäßigen Abständen einfach Informationen bei den zu monitorenden Gerätschaften ab. Das kann zum Beispiel eine Maschine sein, das kann eine Software sein, das kann irgendwas anderes sein. Das kann man dieses Prometheus rein konfigurieren. Wenn wir das einfach mal anschauen, haben wir da oben eine globale Konfig. Das Scrape-Interval ist genau das, wie oft diese Maschine dabei bei den anderen Maschinen vorbeigeht und sich Dinge abholt. Das Evaluation-Interval ist etwas, wie häufig die Rules ausgewertet werden. Die Rules ist das, wo ich dann tatsächlich Alerts definiere. Also, wenn ich eine Information bekommen möchte, dass irgendwas nicht so ist, wie ich das gerne hätte. Und hier unten haben wir dann Scrape-Config. Diese Scrape-Config sind genau die Konfigurationen, wo ich einstelle, was Prometheus scrapen soll, wo er sich regelmäßig Informationen abholen soll. Da gibt es verschiedene Varianten. Zum Beispiel habe ich hier, das ist gegliedert in Jobs. Hier habe ich den Job Prometheus, der hat einfach eine statische Konfiguration, nämlich Localhost 9090. Das ist Prometheus selber. Und dann habe ich noch einen Job für den gesamten Rest. Da habe ich statt der statischen Config einfach eine File-Service-Discovery-Config. Da sage ich einfach, wir haben hier Files, und zwar im Ordner Targets. Haben wir Files mit den Endungen Y, ML, Jamel und JSON. Ja, wir hatten eine religiöse Diskussion über die korrekte File-Extension von Jamel. Deswegen supporten wir die einfach beide. Und auf diese Weise kann ich jetzt einfach dieses Prometheus mal starten. Und das Prometheus läuft. Das kann ich mir hier irgendwie Localhost 9090 anschauen. Und ich sehe, mein Prometheus, das läuft. Ich habe hier mein Graph-Interface. Und da kann ich mir zum Beispiel anschauen, die Abmetrik. Das ist einfach die, die mir zeigt. Ja, da lebt gerade was. Unter Status Targets kann ich mir auch ansehen, was ich gerade habe. Ich habe nämlich genau im Job Prometheus habe ich diesen einen Endpoint, nämlich das Prometheus selber. Das ist gerade ab. Und wenn ich dann neulade, dann sehe ich der letzte Scraper irgendwie sonst wann. Und wenn ich jetzt weitere Informationen zu packen möchte, dann gehe ich wieder rüber. Und kann zum Beispiel einfach einen Node-Exporter starten. Der Node-Exporter ist sozusagen das, was mir so Metriken für eine Maschine exportiert, wie zum Beispiel RAM, CPU-Auslastung, Dateisysteme, irgendwas mit XFS-Dateisystemen, ZFS-Dateisystemen, was mit Time, was über U-Name. Also es gibt ne ganze Liste von Dingen, die der Node-Exporter kann. Und was ich jetzt machen kann ist, noch sehen wir da nix von. Und ich kann jetzt einfach hingehen. Und wir hatten das ja, wir hatten ja diese File-Service-Discovery. Das heißt, ich kann einfach meine Targetspunkt, meine Targets jammeln nach Targets bewegen. Und wenn ich das gemacht habe, dann taucht ihr jetzt auf einmal was auf. Momentan noch im State Unknown, weil das Ding noch nie gescrap worden ist. Das heißt, Prometheus weiß nicht, ob es da ist. Und mittlerweile ist es ab. Und wenn wir uns jetzt das Graphing-Interface nochmal anschauen und uns die App-Metric anschauen, dann sehen wir, da sind jetzt beide da. Und auf diese Weise kann ich jetzt auch meine Alerts schreiben. Wir hatten in der Konfiguration die Rules. Die werden zu Alerts. Wir haben zum Beispiel hier einen Alert Instance Down. Der guckt, wenn ab 1 ist, dann soll er mich informieren. Das ist eigentlich genau falsch rum. Denn wenn ab 0 ist, ist halt nix da. Wenn 1 ist, dann ist alles in Ordnung. Aber schauen wir mal, ob wir noch einen Firing sehen in der Zwischenzeit. Aber dann, man sieht auch hier, er wartet jetzt fünf Minuten, damit ich bei jedem Netzwerkkickup direkt eine Alertkaskade losgeht. Und sobald die fünf Minuten abgelaufen sind, wird der Pending Alert zu einem Firing Alert. Und dann kriege ich tatsächlich eine Notification. Genau. Und hier unten habe ich noch einen anderen Alert, wo ich einfach sagen kann. Also ich kann ja einfach so eine Metric nehmen, zum Beispiel ab. Ich mache einfach einen Bullien-Vergleich drauf und kann dann sagen, wenn diese Bedingung erfüllt ist, dann gibt mir mal eine Information. Prometheus basiert auf Time-Series. Das heißt, ich kann auch irgendwie sowas machen wie Not. Ich kann mir irgendwie irgendwas nehmen. Sieh dann hier einen Wert. Kriegt diesen Wert auch schön visualisiert und kann dann einfach sagen, wenn das kleiner ist als 1000. Ich behaupte nicht, dass das ein sinnvoller Alert ist, aber dann kann ich irgendwie sagen, okay, das ist gerade offensichtlich nicht der Fall. Wenn es größer ist als 1000, dann ist das der Fall. Und wenn ich sozusagen mit diesem Expression in Alert formuliere, kriege ich dafür dann den entsprechenden Alert. Alerts werden von Prometheus zum Alertmanager weitergegeben. Das ist eine separate Komponente. Das heißt, um vollständiges Monitoring zu haben für so eine Maschine braucht man ein Prometheus-Server, einen Alertmanager und dann irgendwo eine Note Explorer. Und dann hat man schon alles, was man braucht. So, das war jetzt eine Kurzeinführung in Prometheus. Haben wir noch irgendwas Schickes, was man zeigen kann? Genau, man hat noch irgendwie die Test Rules, die sehen entsprechend genauso aus, wie wir es eben gesehen haben. Man definiert einfach eine Gruppe, definiert einen Alert mit einem Expression und gegebenenfalls eben so einem Zeitraum, den erwarten soll, bevor er dann wirklich losgeht. Und damit hat man eigentlich schon funktionierendes Monitoring. So, so viel zum Thema Prometheus. Und jetzt ist die Frage, wie kriegen wir eigentlich Daten in dieses Prometheus rein? Also gerade haben wir das so gemacht, wir hatten diese Confectartei und in diese Confectartei haben wir dann irgendwie statisch reingeschrieben und dann hat Prometheus das gefunden. Nur wenn man es irgendwie geteilte Infrastruktur hat, könnte man das so machen, dass irgendwie jeder User einfach in diesem Prometheus Jammel rum schreibt, das kann man aber auch lassen, denn das geht früher oder später irgendwie schief. Und wenn diese Confectartei halt kaputt ist, dann ist es halt für alle das Monitoring tot. Deswegen, was wir stattdessen machen ist, wir haben einfach diese Monitoring-Maschine und jeder Benutzer kriegt einfach einen SSH-Zugang auf die Maschine. Und im Home Directory ist dann einfach ein Ordner, der nennt sich ScrapeTargets und genauso wie wir das schon gesehen haben bei der Fileservice Discovery, kann dann einfach ein Nutzer beliebig viele von diesen Dateien in diesen Ordner werfen und Prometheus findet ihn dann einfach. Wie konfigurieren wir das in der Confect? Das sieht dann so aus, wir haben einen Job, nämlich in dem Fall Alice und Alice hat in Prometheus alles in Jobs gegroupt und es kriegt einfach jeder User einen Job. Das ist so ein bisschen gegen die eigentliche Idee von Prometheus, weil Prometheus quasi sagt oder die Idee ist, dass unter dem Job wir gleiche Systeme gruppen, also zum Beispiel alle Datenbank-Server werden unter dem Job Datenbanken gemonitort, alle Node-Exporter werden unter dem Job-Node gemonitort. Aber da das hier für kleine Setups konzipiert ist und diese Notion für uns dann einfach, wenn man eine Maschine hat, nicht existent ist, hijacken wir dieses Label einfach und sagen, dass wir darüber die Benutzer gruppieren. Das heißt, Alice kann jetzt beliebige von diesen Dateien da rein werfen und jetzt möchte man vielleicht auch noch einen Passwort vor diesem Endpoint haben, weil er ja potenziell Daten rausgegeben wird oder da Daten described werden können, die irgendwie nicht jeden was angehen und deswegen können wir da auch noch irgendwie harte DPS und Basic Auth davor setzen. Eine Einschränkung ist tatsächlich die Basic Auth können wir nur pro Job konfigurieren, die können wir nicht in diese Dateien überführen. Das ist einfach eine Sicherheitsüberlegung, dass man eben keine Credentials in der Service Discovery haben will. Deswegen kann man da leider nur ein Basic Auth für den Endpoint, also für den Reverse Proxy, der zum Beispiel vor eurem Node-Exporter klebt, haben. Dieser Job, wenn wir uns das im Prometheus anschauen, wenn wir uns das mal im Prometheus anschauen, sehen wir auch, dass der Job hier entsprechend als Label übernommen wird und ich kann ja so Dinge machen wie zum Beispiel, ich will nur die Metriken sehen, bei denen der Job Rest ist. Mein Prometheus interessiert mich gerade nicht und zack habe ich ein Filter auf meinen Job und das ist die Kernidee, auf der wir das ganze Ding dann aufbauen. Genau, jetzt hatten wir die Scrape Targets, die kriegen wir einfach über die File Services Discovery rein, das ist relativ einfach. Jetzt will man natürlich auch irgendwie lots formulieren, damit man auch Informationen kriegt, wenn Dinge schiefgehen. Dafür geben wir den Leuten noch einen Rules Ordner, auch im Home Directory und da können die Leute einfach Rules reinkippen auf genau dieselbe Weise. Das ist ein ganz kleines bisschen komplizierter, weil wir zum einen den Nachteil haben, dass die Rules in Prometheus nicht per Job definiert sind, sondern global. Das heißt, wir müssen da noch einen Schritt mehr tun und denn die Rules, falls werden auch nicht dynamisch neu geladen, sondern davon müssen wir tatsächlich einmal den Prometheus reloaden. Plus, wir haben noch ein weiteres Problem. Ich kann zwar so einen Job hier, oder so ein Alert hier formulieren, nur wenn ich den jetzt so schreibe und den so in das Prometheus rein füttere, dann kriegt, halt wenn, dann triggert der eben nicht nur auf meinen Kram, sondern der triggert wirklich auf den Kram von jedem auf diesem System. Das heißt, ich kann Leuten irgendwie beliebige Alerts unterschieben und gerade wenn ich irgendwie meine Alerts super sensitiv habe oder aktiv Leuten auf den Keks gehen möchte, dann ist das irgendwie nicht so hübsch. Deswegen müssen wir eine kleine Modifikation machen. Wir müssen nämlich tatsächlich in dem Expression dieses Filtering machen, was ich gerade gezeigt habe, in dem wir wirklich sagen, wir filtern den Expression so, dass der Job entsprechend vom Benutzer da drin ist. Und dann schreiben wir ganz nebenbei auch nochmal eben kurz für Übersichtsgründe irgendwie in den Alert Namen und so rein, wem das eigentlich gehört. Das ist eher optional. Der crucial Teil ist das hier. Aber das hier ist ganz nett, weil die Alerts tatsächlich alphabetisch sortiert werden. Das heißt, man hat das direkt gruppiert nach seinen eigenen Alerts. Genau. Das heißt, was man macht ist, man nimmt sich irgendwie dieses Rules File. Das erste, was man macht ist, man kann ein Tool von Prometheus benutzen, PromTool. Man guckt mal, ob das Rules File auch in Ordnung ist, sonst packt man es besser nicht an. Und dann überführt man es in diese Form, schmeißt es an einen anderen Ort, wo Benutzer nicht selber schreiben können, sondern irgendwie nur dieses Skript schreiben kann und dann sagt man einmal Prometheus reloademal und dann sind tatsächlich alle Rules spezifisch für den Benutzer da drin. Das kann man übrigens machen, also das kann man sich behandklöppeln, tut es nicht. Benutzt einfach den PromQL Label Injector, der übernimmt es für euch. Also zumindest den Job. Das Jammelpasen muss man noch einmal per Hand drum umstricken. So, auf diese Weise haben wir jetzt Scrape Targets und Alerts in unser System reingefüttert und jetzt müssen wir eigentlich gucken, wie kriegen wir den Daten aus diesem System wieder raus. Eins haben wir schon gesehen, wir können einfach in diesen Query Interface Metricen eingeben und gucken mal, wie die aussehen. Wenn ich das mache, dann sehe ich irgendwie erst mal grundsätzlich alle Metricen in dieses Prometheus, hat, weil Prometheus so gesehen keine Notion von Benutzern hat. Das heißt, ich mache irgendwie einen Up Query und dann sehe ich irgendwie die vier Maschinen, die die Leute da drin haben, von den vier Leuten, die das System benutzen. Was ich aber eigentlich haben möchte, ist ja so was hier. Ich möchte eigentlich, also es interessiert mich ja nicht, was andere Leute mit ihren Systemen machen, sondern eigentlich interessiert mich nur Mein Kram. Das kann ich machen, indem ich einfach hier den Query Updater mit Job, gleich Jonas, aber das ist ja verlästig. Außerdem kann ich es auch sein lassen und gucken, was andere Leute zu machen und das ist ja schon ein bisschen unhöflich. Und deswegen gucken wir uns doch mal an, was macht eigentlich Prometheus, wenn ich sage Up und dann die Curly Brackets mit dem Filter? Prometheus macht da halt so einen HTTP Get Request und wenn wir uns diese etwas längliche URL mal angucken, sehen wir, hier haben wir graph0.expression, gleich Up, Job, Prozent, 3D, das ist URL-Sprech für Gleich und da steht es genau drin. Das heißt, die intuitive Lösung wäre, na ja, wir pflanzen halt mit einem HTTP Reverse Proxy dazwischen und gucken halt an, was dafür ein Request reinkommt und malen den halt um. Also tun wir genau das, wir haben unseren Benutzer, der geht durch irgendeine Art von Authentication Layer durch, denn wer irgendwie doof, wenn ich irgendwie die ganze Arbeit mache und dann kann sich doch jeder irgendwie als jeder Benutzer anmelden, der geht durch irgendeinen Authentication Layer durch, der Authentication Layer prüft irgendwie Username und Password, in unserem Fall ist es einfach HTTP Basic Off, schreibt dann einen Prometheus Injectable Header, dann wird das ganze weitergeleitet an den Prom of Proxy und der Prom of Proxy macht dann eben genau dieses Ersetzen von dem Job Label und dann geht das ganze durch an den Prometheus und dann geht sozusagen das gerendete Ergebnis zurück an den Benutzer. Das funktioniert folgendermaßen, wir haben unser HTTP Requests Total zum Beispiel, das hat irgendwie einen Job foo, aber mein User ist irgendwie bar und dann haben wir diesen ex Prometheus Injectable Header, den der Prom of Proxy sieht und der schreibt das entsprechend um, dass der Job dann auf bar zeigt, wenn kein Job drin ist, malte den halt einfach rein. Und auf diese Weise sieht jetzt jeder User wirklich nur noch die Metriken, die zu dem Job gehören, dem der User gehört. Genau, Prometheus ist eine recht ausführliche API, man kann irgendwie für die Queries, für die Query Range, man kann irgendwie Time Series abfragen, man kann Labels abfragen und noch einige mehr. Und der Prom of Proxy malt einfach für alle relevanten AP Endpoints dieses Update hier berein. Und für AP Endpoints wo das irgendwie nicht so gut funktioniert, wo man aber trotzdem irgendwie das Informationen über andere Benutzer rausholen kann, da sagt der Prom of Proxy einfach, ja, dieser AP Endpoint ist in eurem Land leider nicht verfügbar. So, jetzt haben wir unser Prometheus, wir kriegen Daten weder durch die API noch durch das Graph Interface von anderen Leuten außer uns. Und jetzt haben wir irgendwie unsere Rules und jetzt kann dieser Prometheus eben, wenn er einen Alert hat, diesen Alert an den Alert Manager weitergeben und der Alert Manager kümmert sich drum, dass das Ganze irgendwie schön aggregiert wird, dass ich nicht irgendwie ständig unterschiedliche Alerts kriege, dass die Alerts an die richtige Person gehen und dergleichen. Und das sieht dann irgendwie so aus, das ist das Interface von Alert Manager. Ich habe hier wieder so ein Filter, ich sehe gerade haben wir keine Alerts, aber ich habe irgendwie so ein Filter, wo ich irgendwie genauso wie ich das eben bei den Graphen gemacht habe, matchen konnte, zum Beispiel End Production. Und hier sehe ich natürlich erstmal alle Alerts. Jetzt will ich aber natürlich, dass die Benutzer nur die Alert sehen, die auch zu ihnen gehören, denn das wäre ja sonst ein bisschen nervig, wenn ich ständig irgendwie meine Alerts aus den ganzen Alerts rauspropeln muss, von denen es hoffentlich nicht viele gibt. Also gucken wir uns doch mal an, wie der Alert Manager das denn macht. Da gibt es so einen HTTB Get Request und da gibt es so einen Filterparameter und der sieht irgendwie verdächtig ähnlich aus, wie das, was wir eben hatten. Also kleben wir einfach Gesundheit, also kleben wir einfach einen Prom of Proxy vor den Alert Manager und der kümmert sich. Und dann haben wir aber noch ein weiteres Problem, das ist ein, also ich kann auch Silences definieren, zum Beispiel ich will irgendwie meine Infrastruktur umbauen. Das heißt, ich werde den Server runterfahren, ich werde meine Software kaputt spielen oder so. Und jetzt kann ich entweder die entsprechenden Alerts alle rausnehmen oder ich mache einfach einen Silence rein und sage dem Alert Manager, hey du, ich weiß, dass da in dem Moment, dass da in dem und dem Zeitraum Dinge kaputt gehen, aber geh mir damit nicht auf den Keks, ich weiß Bescheid, das ist beabsichtigt. Das heißt, ich kann einfach sagen, ich habe irgendwie einen Start, ich habe einen End und kann dann sozusagen auf diese unterschiedlichen Label matchen, zum Beispiel kann ich sagen, das soll nur für die Instance Alarm Clock sein, weil ich die nächsten 7 Tage Urlaub habe und die Säume halt eben keine, keine Alerts geben. Sieht jemand das Problem? Dieser Alert macht nicht nur meinen Wecker aus, dieser Alert macht den Wecker von jedem aus, der auf diesem System ist. Das erblüht. Deswegen müssen wir hier auch sicherstellen, dass wir immer wenn ein Silence gesetzt wird, dass wir auch hier einen Matcher auf den Job von den Users setzen, damit der User, damit kein User versehentlich den Alert von anderen Leuten silenced, denn dann ist es irgendwie mit dem Monitoring nicht so cool, wenn die Alerts nicht funktionieren. Genau, das kann der Prom of Proxy, den klebt man einfach davor und der kümmert sich. So, Alert Routing ist jetzt auch relativ simpel, wir können, das ist ein Snippet aus der Alert Manager Config, wir sagen einfach, wir machen einfach einen Match auf das Job Label, gucken, wenn der Job auf den entsprechenden Benutzernamen matcht, dann sagen wir einfach, das ist der entsprechende Receiver unten. Wir haben dieses Label, wir können das einsetzen und unten ist dann eine Receiver Section definiert, in der drin steht irgendwie Valerie kriegt eine E-Mail und Daniel kriegt einen HTTP Post Request an eine von ihm definierte Adresse oder irgendwie sowas und kann darüber eben sein ganz eigenes persönlichen Alert bekommen. Und dann ganz unten gibt es noch ein Catch All, wo man dann sagt, also wenn das irgendwie gar nicht matcht, dann schickst ihr den Alert bitte an das Operation Team, damit die Wissen, dass da was kaputt ist. Ist aber bis hin noch nie vorgekommen. So, der gesamte Architektur Überblick ist dann der hier, wir haben hier unsere Prom of Proxy, einer Form Prometheus, einer Form Alert Manager. Der Alert Manager spricht dann mit den Usern für die Alerts. Die User haben hier ihre Ordner, wo sie einfach ihre Targets reinwerfen können und das Prometheus kümmert sich dann um das Monitor von den Maschinen. Da oben haben wir noch den Blackbox Exporter, zu dem komme ich gleich, der ist ziemlich cool. Und hier ganz vorne sitzt einfach ein Engine X, der HTTP Basic Off Reverse Proxy spielt und diesen Exprometheus Injectable Header für den Prom of Proxy da reinmalt. Das heißt, die User können sich gegen den Engine X einfach authentifizieren und dann können sie das System benutzen. Statt das Engine X kann man da eine beliebige Authentication Lösung vorkleben, was auch immer ihr gerade lustig seid oder wie ihr euch da verkünstigen wollt, solange dieser Header am Ende für den Prom of Proxy da drin landet. So, wir haben ja schon ein bisschen über Lockdown gesprochen, in dem Sinne, dass wir sicherstellen wollen über den Prom of Proxy, dass man wirklich nur seine eigenen Metriken kriegt. Und das würden wir natürlich auch, wenn wir uns schon die Arbeit machen, dass wir da irgendwie vorfiltern, dass jeder nur an seiner eigenen Metriken sehen kann, dann sollten wir das auch konsequent zu Ende tun. Das offensichtliche ist, alles außer dem Engine X lauscht nur auf Localhost und das einzige, was nach außen spricht, ist der Engine X und der macht eben die Authentication. Alle anderen Komponenten sind einfach auf Localhost gesetzt. Dann setzen wir die Permissions folgendermaßen. Wir haben einen Prometheus-User für das Monitoring Setup und die einzelnen Nutzer haben einen Username und eine Gruppe, die genauso heißt wie sie selber. Und in ihrem Home Directory, diese Ordner, die Scrape Target Ordner, die Rules Ordner und die beiden Beispielfals, die wir mit bereitstellen, die gehören einfach den Prometheus-User und sind aber in der Gruppe von dem entsprechenden User. Der Vorteil von dem ganzen Spiel ist, dass auf diese Weise die Leute diese Ordner nicht umbenennen, bewegen, change modernen können oder irgendwas anderes. Das heißt, es kann nicht passieren, dass ein User versehentlich sich irgendwie da was absägt, sondern es ist sichergestellt, dass dieser Ordner dann immer lesbar ist vom System. Was da drin passiert, ist dann wieder eine andere Frage. Da können die User natürlich irgendwie unlesbare Fals machen, aber hey, dann taucht das Target halt einfach nicht auf. Und dann können die User das sehen, bzw. nicht sehen und können dann einmal prüfen, ob sie da alles richtig eingestellt haben. Genau. Dann haben wir natürlich diese API, die ist von außen unzugänglich, weil wir den Prom of Proxy davor kleben haben, aber die ist natürlich von der Maschine selber noch erreichbar. Das heißt, ich kann irgendwie einfach ein Python-Script definieren und Python-Script schreiben, das einfach mit einem HTTP-Request an die lokale API rangeht. Wie könnte man das beheben? Na ja, kann man irgendwie über NoExec nachdenken, aber NoExec bei einem Python-Script heißt, dass ich mir selber Python unter Hintern wegziehe und das brauche ich leider in dem System, weil ich bei das, weil ich in Python dieser Pasa für die Rules implementiert ist. Das heißt, was wir einfach machen, ist wir legen einfach eine NF-Tables-Rule an, könnt ihr auch mit IP-Tables machen, aber ich finde NF-Tables einfach viel lesbarer. Einfach eine Output-Chain, das ist eine Filter, der hockt sich in den Output rein und hat einfach standardmäßig die Policy accept, das heißt, standardmäßig ist das Ding in a No-Op. Und jetzt gucken wir einfach auf die User-ID und wenn die tatsächlichen Benutzer auf unserem System irgendwas mit Outgoing- Netzwerk-Traffic machen wollen, dann sagen wir einfach, gibt's nicht. Und auf diese Weise haben wir die komplette, die komplette AP zugenagelt, weil wir, weil die User eben über diese Weise keinen, also die können schon irgendwie Netzwerk machen, aber das ist dem System halt egal. Fallen euch noch weitere Möglichkeiten ein, wie man an dieser AP rankommen könnte. Einen habe ich noch. Ich könnte ja einfach, also was man euch nämlich machen könnte, ist man könnte irgendwie einen SSHD-Lokal laufen lassen und über den dann irgendwie reverse-proxying oder so, was aber nicht geht, weil wir hier einfach den Reject für alles, was der User gestartet hat, drin haben. Was aber geht, ist, wir haben ja diesen System SSHD und der kann das auch, außer wir sagen halt, er kann das nicht und deswegen sollten wir noch sagen, er kann das nicht. Das heißt, wir schalten noch TCP-Forwarding ab und dann ist auch das Problem gelöst. Ja, wir sind da sehr konsequent. Es gibt tatsächlich noch einen weiteren Aspekt, wie man noch Daten aus dem System extrahieren kann, der jetzt nicht so besonders offensichtlich ist. Man kann in so Alerts Annotations ran schreiben. Zum Beispiel kann ich sagen Summary, Metric, Value is Value und auf diese Weise, da kann ich, da kann ich dann irgendwie wenn ich meine Alerts, Alert Emails, Alert SMS, Alert PagerDuty, whatever schreibe, kann ich da irgendwie so einen schönen Text mit Erklärung und irgendwie noch einen Link aufs Run Book oder so, wo dann drin steht, wie man diesen Alert behebt oder sowas reinschreiben und da kann ich auch direkt inline Daten mit reintun, dass man sozusagen nicht erst in den Alert Manager gehen muss und nachzugucken, was, was da eigentlich jetzt gerade Phase ist. Bedauerlicherweise können diese Template Expressions fullest prompt QL, das heißt theoretisch könnte man hier rüber wie der andere Leute Zocks extrahieren und deswegen unterbinden wir das bedauerlicherweise einfach generell, das gibt es auf dem System einfach nicht. Das wird dann beim Paasen der Alerts, wenn wir die sozusagen in die anderen Falsch schreiben, wird es einfach weggeschmissen. Gut. Bedenkenswert ist so far das ist ein System, wo alle voneinander lernen können sollen. Das hat ein paar Implikationen. Rules sind in der gegenwärtigen Ausgestaltung für alle Leute sichtbar. Das heißt, alle Leute können voneinander lernen, wie man gerade, wenn es darum geht, wenn Leute sozusagen noch nicht so viel mit Prometheus gearbeitet haben und andere Leute auf dem System haben da schon mehr Erfahrung, kann man halt schauen, was haben andere Leute so für Alerts und was davon ist für mich eigentlich auch tauglich. Das heißt natürlich, dass alle Rules für alle Leute sichtbar sind. Aus demselben Grund haben wir die Konfiguration, man kann in Prometheus einfach auf die Konfiguration gehen unter Status Konfiguration und da sieht man die komplette Konfiguration mit auch allen Optionen Optionen ist einfach auch mal aufgefüllt. Das haben wir uns explizit entschieden, dass wir das offen lassen, damit sich auch alle Leute falsch hier, damit sich auch alle Leute angucken können, wie dieses System gebaut ist. Das heißt allerdings auch, dass die alle User sichtbar sind auf diesem System, dass die Basic-Auth-Usernames, die wir am Anfang in der Konfig gesehen haben, für alle benutzer sichtbar sind, die Basic-Auth-Passwörter werden vom Prometheus allerdings in der Ansicht ausgebiebt. Das ist ganz praktisch. Das heißt, die Passwörter sind nicht zugänglich und niemand kann auf eurer Endpoints kommen. Und Mail-Adressen im Alert-Manager oder was auch immer ihr für Alerting benutzt, sind dann auch für alle sichtbar. Das ist aber ein Trade-off für den wir uns gegenwärtig entschieden haben, dass wir das einfach machen. Wenn man das nicht will, die letzten beiden sind relativ einfach zu fixen. Man macht einfach den Config Endpoint, also diese Seite, wo die Config drauf ist zu und schon hat sich das Problem gelöst. Gut, Blackbox-Exporter. Der Blackbox-Exporter ist eine relativ coole Sache. Und wie wir diskonfiguriert haben, ist wie folgt, wir haben einfach noch ein Ordner Blackbox-Targets und in dem liegen dann verschiedene Unterordner. Das sind dann verschiedene Module, zum Beispiel HTTPS 200, IPv4. Das ist einfach ein Modul, da kann ich einfach einen Websites-Punkt Jammel reinwerfen. So ein Websites-Punkt Jammel kann ich euch auch zeigen. Nehmt mal da. Blackbox, hab ich es genannt. Ja, genau, man sieht hier einfach hier. Man kann nicht einfach, ich kann hier einfach irgendwie sagen, HTTPS Wurstpunktbrot ist für das HTTPS-Modul, zum Beispiel, dann wird einfach mit dem HTTPS 200er-Modul wird einfach auf IPv4 geschaut. Gibt diese Adresse ein HTTPS, eine HTTPS Antwort mit Status Code 200er und wenn das der Fall ist, ist okay. Wenn das nicht der Fall ist, dann kriege ich einen Probe Failure. Dann habe ich, also HTTPS brauche ich gar nicht. Ich kann auch einfach irgendwie das Käsebrot nehmen und das funktioniert auch wunderbar mit dem HTTPS-Modul. Ich kann für das TCP-Modul irgendwie sagen, Prometheus IOPort 80, dann kann ich irgendwie schauen, ob der ob der TCP-Handshack funktioniert. Genau, wir haben momentan auf dem System HTTPS 200er-Modul für V4 und V6. Wir haben TCP-Connect. Was Prometheus auch kann, ist so Dinge wie ich kann schauen, ob der ob der S&TP-Handshack funktioniert bei meinem Mail Server. Ich kann schauen, ob der ob der SSH-Handshack funktioniert, damit ich auch da, sozusagen, eine Information kriege, ob mein SSHD irgendwie kaputt ist, bevor ich den brauche. Denn dann habe ich meistens andere Sorgen. Genau, und der Blackbox-Sport kann verschiedene Dinge. Er hat halt einmal das Probe-Success. Das ist eben, ob das Modul tatsächlich sozusagen positiv geendet ist. Dann gibt es noch so was wie Probe-Duration-Seconds. Das ist eben die Frage, wie lange hat das Ganze gedauert? Damit kann ich eben gucken, ist die Latence besonders groß oder ist sie im Rahmen, der noch okay ist? Ich kann den HTTPS-Status-Code auch explizit abfragen. Was ich ziemlich cool finde, ist, ich habe einfach eine Metrik, die sagt mir, Probe-SSL earliest cert expiry. Und dann kann ich einfach eine Leut schreiben mit Probe-SSL earliest cert expiry minus time, die einfach als Funktion in dieser Abfragesprache von Prometheus bereit steht. Und wenn das irgendwie weniger als fünf Tage sind, dann schickst du mir bitte eine Leut, dass ich mal auch mal ein Zertifikat gucken soll, bevor es ausläuft. Gut, jetzt, das ist sozusagen dieses System. Jetzt fragt ihr euch vielleicht möglicherweise, wie kriegt man denn das? Was muss ich tun, um das zu kriegen? Was ihr machen könnt, ihr könnt das selber klöpeln. Ihr nehmt euch die entsprechenden Prometheus-Komponenten, also Prometheus, Alertmanager, Nanodexporter, den könnt ihr, oder den könnt ihr im Zoll zwar irgendwie aus eurer Distro nehmen oder sonst was. Der Prom of Proxy, den gibt's hier, könnt euch einfach Klonen selber bauen, Grogetten, whatever floats your boat. Dann haben wir hier noch den PromQ-Label-Injector, den wollt ihr auch haben. Den könnt ihr dann irgendwie in einem Python-Script benutzen, der, das dann sich darum kümmert, dieses Rules, jammel einfach einmal einzulesen, da durchzulaufen und gegen den Expression einmal diesen PromQ-Label-Injector zu werfen oder ihr klont euch einfach, das hier macht Ansible Playbook Multitenant Prometheus-Punkt jammel und seid fertig. Das ist ein Ansible-Repo mit allen Komponenten drin. Gut, was ihr noch reintun müsst, ihr müsst euch die ganzen, ihr müsst euch die ganzen Binarys von hier, die müsst ihr euch trotzdem nochmal runterladen. Ich dachte mir jetzt irgendwie so ein 72 Megabyte Go Binary wollte ich jetzt irgendwie nicht in dieses Repo einkommenten. Deswegen, ihr holt euch die Komponenten, tut die in das entsprechende Directory in diesem in diesem Ansible-Repo rein und dann könnt ihr einfach das Ansible Playbook, das beigelegt ist, ausfüllen euren Usern und dann entsprechend los treten und danach habt ihr ein fertiges System. Das ganze, das, das Repo basiert oder ist gebaut für einen Debian und ihr könnt einfach in dem Playbook alles eintragen, was euren Nutzern brauchen. Das ist nämlich einmal ein Nutzernahme, mit dem Sie sich beim Engine X einloggen, dann Passwords, mit dem Sie sich da einloggen, dann Username und Password für die HTTP Basic Off, die man vor die Endpoints kleben kann und dann SSH-Key, um sich auf das System einzuloggen. Das wäre sozusagen einmal der der Überblick über dieses System. Was haben wir noch vor? Das ist bis her leider noch to do ist, hat leider nicht mehr geschafft, das bis heute noch fertig zu machen. Wir wollen das gerne noch redundant bauen, das heißt, wir wollen zwei Promethees parallel bauen. Das Schöne an Promethees ist, wenn man das redundant machen will, nimmt man einfach zwei und man ist fertig. Die brauchen überhaupt nicht miteinander zu reden, die brauchen überhaupt mich voneinander wissen. Das einzige, was wir machen müssen, ist, wir müssen Rules und Targets zwischen den beiden synchronisieren. Und dann nehmen wir uns einfach noch zwei Alertmanager, die sollten voneinander wissen, ansonsten kriegt jeder User eben zwei Alerts, aber die Alertmanager sprechen einen Gossiping-Protokoll, mit dem Sie sich unterhalten können und wenn einer einen Alert kriegt, dann sagt der anderen Bescheid, dass er den Alert gekriegt hat und wenn der andere Alertmanager den Alert auch kriegt, dann sagt er, oh ja, der andere kümmert sich ja schon. Ich muss mich um gar nichts kümmern, auf diese Weise kriegt man eben nur einen Alert. Außer durch irgendein Netzwerk Issue können die beiden nicht miteinander reden, dann schicken die einfach beide einen Alert raus. Auf diese Weise hat man so zu sagen genau was man haben möchte, idealerweise nur einen, aber lieber zwei als keinen. Das ist im Moment in Arbeit. Es gibt bei dem Ansible Repo einen Issue, das Issue Nummer eins. Da könnt ihr euch subscriben, wenn ihr wissen wollt, wann das tatsächlich fertig ist. Ich hoffe bald. Und dann haben wir auch schön redundantes Monitoring. Das wäre soweit grundsätzlich einmal ein Overview über das System, das wir gebaut haben. Wenn es Fragen gibt, wäre ich offen für Fragen. Falls jemand Interesse hat, habe ich auch noch die Konfigurationen für den Blackboard Exporter. Diesen bisschen hässlich. Deswegen habe ich sie mal ans Ende gestellt. Aber ich würde sagen, bekommen erst mal zu den Fragen, so denn welche da sind. Dankeschön. Gibt es Fragen mit der Handzeichen, dass ich mir Mikro zu euch komme? Was ist Prometer ist auch in der erlaubte Frage oder? Ja, natürlich. Sollte ich irgendwen abgehängt haben, gerne sagen, ich kann auch gerne Dinge nochmal detaillierter erklären. Wenn es keine Fragen gibt, könnte ich noch einen kurzen Einblick in die Blackbox Konfigurationen geben. Möchte die jemand sehen? Alles klar. Das ist jetzt schon so ein Thema hier. Ihr werdet alle früher fertig und dann habt ihr noch ja, ich habe den noch 20 Folien. Ja, besser so als andersrum. Ja, auch war. Gut, dann genau. Also, der Blackbox Exporter ist relativ hübsch, außer man will ihn so konfigurieren, dass man tatsächlich ihn mit der Service Discovery benutzt. Denn dann muss man sich. Gut, das ist der unspannende Part. Wir haben einfach, wir definieren, was wir machen, ist, wir definieren einfach weitere Jobs. Wir definieren, jeder User hat einen Job. Für mich wäre das der Job Jonas. Und ich kriege jetzt einfach einen weiteren Job, nämlich Jonas Blackbox. Modulname, Protokollname und dann kriegt der kriegt der Blackbox Exporter. Was Prometheus macht, das Prometheus scraped jetzt quasi den Blackbox Exporter als als Wersten Target und gibt ihm sozusagen bei diesem Scrape hier die Parameter noch mit. Und was wir machen ist, pro Modul, das wir anbieten, geben wir einmal, geben wir das Einzelne sozusagen mit. Wir müssen den Matrix Path auf Slash Probe umschreiben. Und wir machen hier wieder diese klassische Service Discovery. Diesen Job reproduzieren wir jetzt für jedes Modul, was wir haben in allen Kombinationen der entsprechenden der entsprechenden IP Version. Daher kommt eben genau diese Ordner Struktur, die wir hier sehen, dass wir den Blackbox Ordner haben und darunter eben einzelne Ordner für die entsprechenden Module. Dann müssen wir das Ganze ein bisschen relabeln, nämlich wir müssen ein bisschen hererschieben von Zeugs machen, dass was man hier tut, deswegen ist es ein bisschen hässlich. Als Source Label nehmen wir uns underscore underscore Address. Das ist sozusagen die Address, die Prometheus tatsächlich scrapen möchte. Die verschieben wir in underscore underscore ParamTarget. Und dann die ParamTarget schreiben wir in die Instance rein. Auf diese Weise steht dann im Instance Label von der Metrik am Ende nicht mehr drin, dass wir den Blackbox Explorer gescrapt haben, sondern das Ziel, was wir eigentlich geBlackbox Probe haben. Und ganz am Ende schreiben wir in die Address das, was Prometheus tatsächlich zum Scrapen benutzt, einfach 127.01. 91.15 rein. Das ist das, wo der Blackbox Explorer läuft. Totally straightforward. Ja, es ist ein ganz kleines bisschen hässlich. Aber wenn man das so macht, kann man tatsächlich den Benutzern einfach einen Ordner geben, wo sie einfach diese Jammels reinwerfen können, oder Jasons oder Jammels mit A. Und kriegen einfach ihre Blackbox Probing, ohne dass sie sich darum kümmern müssen. Das ist das, was ich unter anderem meinte mit es soll möglichst einfach sein. Das hier ist halt nicht einfach, aber das macht man halt einmal in der Konfig und aus User-Sicht mit den Ordnern ist es dann wieder relativ einfach. So, dann macht man noch ein bisschen andere Magie. Das Ganze ist jetzt ja im Job Jonas Blackbox, htdp2xxipv4. Der Prom of Proxy lässt uns den Letzensmetriken dieses Jobs natürlich nicht sehen. Also malen wir einfach über das Job Label drüber und schreiben da rein, wie es auch immer gehören soll. Macht das nicht ohne, ohne irgendwie Ansible Templating, es ist die Hölle. Das sind, glaube ich, drei Nested Loops im Ansible Template. Genau, und dann machen wir noch ein bisschen Mary Labeling, nämlich, wir schreiben einfach zwei weitere Metriken ran, nämlich einmal die IP Version, nämlich Obst V4 oder V6 ist, und einmal Blackbox-Modio, wo dann drin steht, was für ein Modul das eigentlich ist, dann können die User auf diese Weise nämlich tatsächlich einfach im Graphing-Interface oder beim Allerting spezifisch aussuchen, welche Blackbox-Module sie haben wollen oder auf welche Blackbox-Module sie welchen Allot schreiben sollen. Und es ist relativ simpel zugänglich. Genau, das wäre die Konfiguration für den Blackbox-Exporter, ist nicht die Most straightforward, aber wenn man das einmal so gebaut hat, finde ich das auch relativ komfortabel zu benutzen. So, das wäre die Konfiguration für den Blackbox-Exporter. Das Parsing-Script für das Parsing-Script, was die Rules so pass, dass ihr sie am Ende wieder benutzen könnt und euren Prometheus reloaden könnt, ist hier übrigens auch drin, falls ihr das nicht selber schreiben möchtet. Da gibt es nur kein eigenes Repo für deswegen. Ja, genau. Das wäre dann alles, was ich so weit vorbereitet hätte. Falls es dann doch noch Fragen aufgekommen sein sollten, entweder jetzt oder ihr greift mich einfach irgendwann auf dem Rest der Veranstaltung ab. Fragen? Keine Fragen. Gibt es jetzt noch Fragen? Alle erschlagen. Ja, komplett. Genau, falls... Ah, danke. Bura! Wenn ich dich richtig verstanden habe, macht ihr das ja privat. Ja, nicht geschäftlich. Ihr kennt euch untereinander? Ja. Warum dann der ganze Aufwand? Na ja, wir haben... Dann gibt doch einfach jeden Rout auf dem Rechner und lass jeden treiben, was er will. Nein, nein. Das ist ein... Das ist ein hübschkuratiertes System, wo eben die Idee ist, dass eben nicht jeder Rout auf der Kiste ist und drum rumfummelt, sondern wir haben einmal dieses System. Und es kann ja auch sein, dass das zum Beispiel Leute eben nicht wollen... Dass Leute sich verkennen, aber das trotzdem irgendwie nicht jeder möchte, dass alle Details über die eigenen Server irgendwie exponiert ist für alle anderen. Möglicherweise passiert das auch irgendwie mal, dass es zwei Leute, dass zwei Leute auf dem System landen könnten, die sich dann nicht so gut kennen in dem Polk von Leuten, die auf dem System sind. Deswegen haben wir halt gesagt, wir machen das konsequent und wir ziehen das einfach bis zum Ende durch und nahe in die Kiste zu. Wenn wir damit schon mal anfangen, dann machen wir es gleich richtig. Insbesondere, weil der Node-Exporter auch so coole Dinge kann, wie der kann mir... Der hat ein System-DiExporter und da kann ich dann alle meine Units exportieren und ich kann darauf alerten, wenn eine Unit fällt. Das heißt, aber ich habe wirklich alles exponiert, was auf der Kiste läuft, weil halt alle Unitsfalls rausgehen. Das ist dann vielleicht eine Sache, da will ich nicht, dass die irgendwie jeder abfragen können, weil ich da... Und um eben, damit sich eben niemand Sorgen machen muss, wer dann irgendwie in die eigenen Metriken reinschauen kann, dann haben wir einfach gesagt, wir machen es zu und wenn wir es einmal zu machen, dann machen wir es richtig zu. Danke schön, super Frage. Weitere Fragen. Da vorne? Ach doch, ja. Ich brauche mehr Mathe. Vielleicht ist es eine blöde Frage, aber was ist der Unterschied zwischen den Rules, die man so definiert und die man für den Blackbox-Exporter definiert? So gesehen keine. Du schreibst einfach, habe ich das... Ja, aber warum gibt es da zwei verschiedene? Was ist der Sinn mit dem? Normalerweise macht Prometheus Whitebox Monitoring. Du kriegst also wirklich Insight in die Maschine. Du kannst direkt abfragen, wie ist der Status von der CPU? Wie ist der Memory? Wie ist das Dateisystem? Wann läuft's voll vermutlich? Der Blackbox-Exporter macht wirklich Blackbox-Probing. Da schickst du eine Probe hin und guckst von außen, verhält sich das System entsprechend. Dass wenn du zum Beispiel, du kannst zum Beispiel einmal das Whitebox Monitoring machen, dass der Engine X noch lebt und gleichzeitig setzt du zusätzlich noch eine Probe auf, die einfach guckt, ob er auch richtig ausliefert. Einfach als weitere Sicherheit. Oder auch wenn du eine Website hast, die du bei irgendeinem Hoster hast, die nicht unter deiner Gewalt liegt, dann kannst du einfach eine Blackbox-Probe drauf setzen und sagen, ich will zumindest mal wissen, wann ich mal bei meinem Hoster anrufen muss, weil meine Website nicht mehr da ist. Oder wenn die Latence zu groß ist. So ein Ding kannst du relativ einfach mit dem Blackbox-Exporter machen. Zum Beispiel auch das SSL-Sert-Expiry-Ding. Das ist viel einfacher, wenn ich einfach von außen eine Probe drauf schicke und mal gucken, wie sieht es denn von außen aus, als wenn ich mir innen angucke und meine Zertifikate und wann laufen die eigentlich aus und so. Genau, das ist sozusagen diese Unterscheidung zwischen Blackbox und Whitebox Monitoring. Prometheus hat angefangen oder ist eigentlich ein Whitebox Monitor System und der Blackbox-Exporter rüstet eben das Blackbox Monitoring zusätzlich noch nach. Wunderbar, weitere Fragen. Es ist so dunkel hier, ich sehe die Hände so schlecht. Es scheint aber nicht so zu sein, wenn das der Fall ist. Oh, danke. Das wäre jetzt super, danke schön. Wir haben ein erleuchtetes Publikum. Ja. Gut. Jetzt schauen Sie aber ganz geschamig am Boden, dass es gibt anscheinend keine weiteren Fragen mehr. Dann würde ich sagen, ganz, ganz herzlichen Dank und einen großen Applaus noch mal für Chatty. Dankeschön.