[Musik]
Hallo und herzlich willkommen zur zwölften Folge des Focus on Linux Podcasts.
Heute reden wir über ein Thema, das ich persönlich sehr spannend finde.
Das war auch einer der Hörerwünsche.
Und zwar geht es heute um das Thema Monitoring.
Und da das Thema Monitoring nicht unbedingt ein Thema ist,
das man mit ein, zwei Sätzen abhandeln kann,
habe ich mir natürlich Gäste zu dem Thema rein geholt.
Und da wollen wir einfach heute mal schauen,
was sich hinter dem Wort Monitoring so verbirgt
und welche Tools denn da so in Frage kommen.
Und mit dabei ist zum einen der Gerd Stolz.
Guten Tag zusammen.
Was bringt dich denn zum Thema Monitoring?
Wer bist du, was machst du und wie bist du zu diesem Thema gekommen?
Erzähl doch mal kurz.
Ach Gott, viel zu lange mache ich Monitoring schon.
Also eigentlich seit ich irgendwie bei der SVA bin, glaube ich,
also offiziell eingestellt als Linus-Administrator,
am Tag drei beim Kunden vor einem Isinka gelandet.
Und dann ging es abwärts oder aufwärts, wie man die mal betrachten möchte.
Ein paar Jahre Isinka gemacht, bei dem Kunden, dann bei der SVA intern.
Und dann irgendwann als Isinka 2 noch nicht fertig war.
Und wir gemerkt haben, Isinka 1, das geht so nicht mehr.
Zu Check-in-Ka gewechselt.
Und das mache ich jetzt seit sieben Jahren, glaube ich, kann ich sagen, in Vollzeit.
Und irgendwie ist immer noch abwechslungsreich.
Sehr schön.
Ja, es gibt ja auch genügend Tools.
Also man kann ja mit einem Tool beginnen und dann gibt es ja genügend andere Tools,
auf die man migrieren kann.
Also mit Isinka hast du auch direkt ein Tool angesprochen, in dem ich mich auch sehe.
Also ich habe irgendwann mal vor langer, langer, langer Zeit mit einem Nagios 2.0 oder so begonnen.
Das war so zu Ausbildungszeiten.
Wie alt bist du denn?
Also ich bin jetzt offiziell 32 Bit alt.
Von daher, aber das war damals schon sehr angestaubt.
Und wie das ja häufig so ist, aus historischen Gründen existierte das.
Die Person, die das installiert hat, hat das Unternehmen schon lange verlassen.
Und keiner hat den Perlcode verstanden, die die Person dann noch selbst eingebaut hat,
der natürlich keinen Abgröth überlebt hat.
Das war meine Aufgabe dann während der Ausbildung natürlich.
Genau, und da bin ich dann irgendwann bei dem Nagios 3.0 gelandet
und irgendwann bei einem Isinka 1.0 und dann bei einem Isinka 2.0.
Aber da können wir bestimmt später nochmal mehr im Detail drüber sprechen.
Schön, dass du dabei bist.
Vielleicht kann es auch jemand erklären, ob wir Isinka eigentlich richtig aussprechen,
weil ich habe immer irgendwann gehört, dass es eigentlich ein "Tsch" oder sowas ist.
Aber ich traue mich nicht, das anders auszusprechen.
Ich bin auf jeden Fall gespannt, die Person, die das nachher so ein bisschen vorstellt,
wie dies ausspricht.
Und danach werde ich mich dann für den Rest des Podcasts dran halten.
Des Lebens.
Sehr gut.
Ja, mit dabei ist auch der Philipp Bayer.
Ja, schönen guten Abend zusammen. Hallo.
Grüß dich. Schön, dass du dabei bist.
Erzähl doch mal, was machst du so im Monitoring-Komplex und wie bist du dazu überhaupt gekommen?
Ja, wie bin ich dazu gekommen?
Ich habe das Thema Monitoring jetzt seit knapp sechs bis sieben Jahren auf meinem Zettel stehen.
Ich habe das bei meiner alten Firma, wo ich nach dem Studium angefangen habe,
als ersten Punkt sozusagen angefangen, um mich da reinzuarbeiten.
Ich bin dadurch dann auch so ein bisschen ins Thema Linux reingerutscht, logischerweise.
Und habe damit dem Konstrukt Icinger 1 und einem Zentrion als Konfigurationsoberfläche begonnen,
mich erstmal da reinzuarbeiten, wie funktioniert das Ganze überhaupt.
Und das dann hinterher bei Kunden installiert, betreut, administriert, kleine Anwendungsschulungen gehalten.
Und dann ging es irgendwann darum, dafür einen Nachfolger zu finden.
Und das ist dann Icinger 2 geworden.
Und das mache ich jetzt dann seit, ich würde mal sagen, knapp sechs Jahren.
2016 haben wir damit angefangen.
Und dann bin ich vor zwei Jahren zur SVA gekommen und durfte das freundlicherweise weitermachen.
Das hat mich auf jeden Fall sehr gefreut und ist so mein Hauptaufgabengebiet hier.
Auch weiterhin Kundensysteme einrichten, Kundensysteme betreuen,
ein bisschen Betriebsunterstützung machen.
Und das alles mittlerweile dann zu, ich sage mal, 99 Prozent auf Icinger 2 Basis.
Sehr schön.
Also ich freue mich ja auch immer, wenn ich mit euch in eurem Team mal zu tun habe.
Ihr haltet ja die Icinger 2 Flagge immer schön hoch, während andere Teams, ohne jetzt jemanden anzuschauen,
eher die Jack-in-the-Car-Fahne hochhalten, finde ich das immer gut, auch nochmal die andere Seite zu hören.
Wobei beide natürlich ihre Daseinsberechtigung haben.
Also sie haben alle ihre Vor- und Nachteile.
Das werden wir auf jeden Fall im Laufe des Podcasts auch noch ein bisschen skizzieren.
Gut, und dann haben wir jemand mit dabei.
Wer sich mit Nagios und Icinger beschäftigt, der ist bestimmt in der Vergangenheit schon mal über seinen Namen gestolpert.
Und das ist niemand Geringeres als der Michael Friedrich.
Grüß dich, schön, dass du dabei bist.
Servus, freut mich.
Ja, wo fange man?
Ich würde mal sagen, mit Monitoring angefangen habe ich 2006 herum, wie ich in Wien Studenten war.
Berufspraktikum, Diplomarbeit.
Und wir haben versucht, irgendwie die Netzwerklandschaft mit Nagios auszustatten.
Ich glaube, das war Nagios 303 oder irgend sowas.
Die NDO hat, also die Datenbank mit MySQL und dem Output hat nicht ganz funktioniert.
Wir wollten aber nackt was sehen, also Visualisierung.
Und das ist mir so ein bisschen in Erinnerung geblieben damals.
Und wie ich dann 2009 auf der Uni Wien im Zentralen Informatikdienst mich beworben hatte,
habe ich irgendwann noch mal so in einem Meeting fallen gelassen.
Naja, das Nagios, damit kenne ich mich ja aus.
Und die Uni hat das auch installiert gehabt.
Und sie haben, weil die Uni eben kein MySQL hatte, sondern Oracle,
quasi die Aufgabe, ein Oracle-Pack ein für Nagios weiter zu bauen.
Und ich habe mir so gedacht, naja, MySQL und Oracle, das ist eh das Gleiche so in der Richtung.
Also jung und ungestüm, um dann zu lernen von unseren DBAs.
Nein, das ist nicht das Gleiche.
Und habe mir dann in der Form weiter damit beschäftigen dürfen, in meinem Job, neben DNS, Curies und Monitoring und anderen Geschichten.
Und dann bin ich irgendwann noch mal auf einen sogenannten Fork, eine Kopie von Nagios gestoßen,
namens eSinger, eSinger, wie auch immer.
Es gibt irgendwo ein Audiophile, wie man es ausspricht, zumindest im Webarchiv, wenn es nicht auf der Webseite ist.
Und habe dann zu meinem Chef gesagt, naja, vielleicht können wir da was reinbringen,
weil bei Nagios halt die Entwicklung schon ein bisschen eingeschlafen war.
Und das zieht sich dann über mehrere Jahre oder eigentlich über Jahrzehnte,
was mich auch nach Nürnberg gebracht hat von Wien 2012, einfach mehr mit Open Source zu machen, mehr in dem Bereich Monitoring zu tun,
bis hin zu der Idee 2019 viele verschiedene Dinge, die nicht funktioniert haben,
mit Businessmodell und anderen Geschichten zu sagen, ich bin ausgebrannt oder ich war wirklich in einem Burnout drinnen, ich suche mir jetzt was anderes.
Ich habe meine GitLab-Schulungen für mich entdeckt und habe mir dann bei GitLab beworben, Anfang CICD mehr,
bewege mich aber mittlerweile mit Promises und Observability in allen Facetten.
Also ich bin dem Thema wieder treu geblieben und kann natürlich stundenlang oder tagelang darüber sprechen.
Sehr schön. Genau deswegen wollten wir dich auch mit dabei haben, weil jetzt haben wir ja wirklich alles bunt gemischt.
Wir haben Leute, die Isinka nutzen, wir haben Leute, die Jack'n'Kar nutzen. Jetzt haben wir dich auch noch mit dabei, du bist ja auch mit anderen Tools beschäftigt.
Ich glaube, das kann eine sehr, sehr spannende Runde werden.
Und vielleicht beginnen wir einfach mal damit, bevor wir uns jetzt wirklich in den Details verlieren.
Und wir müssen glaube ich so ein bisschen erst mal abstecken, welche Arten von Monitoring gibt es überhaupt.
Also ich könnte mir vorstellen, klar, jeder hat schon mal in irgendeiner Art und Weise über das Wort Monitoring nachgedacht oder auch das ein oder andere Tool schon benutzt.
Aber es gibt ja viel Interpretationsmöglichkeiten. Vielleicht beginnen wir erst mal so damit.
Wenn ich jetzt an das Wort Monitoring denke, dann denke ich vor allen Dingen an meinen ersten Job, wo ich das auch als Administrator in irgendeiner Art und Weise zu verantworten hatte.
Und denke auch so an das typische Infrastruktur Monitoring.
Was fällt da, wenn ihr das Wort hört, für euch da so rein? Woran denkt ihr da spontan? Oder fallen euch noch andere Arten des Monitorings ein?
Ich denke gerade bei der Infrastruktur, das ist ja so das, was man heutzutage als unsexy bezeichnet, weil es ist eben das, wo noch Blech dabei ist.
Das kann ja unten bei der Lüftung PDUs, USVs losgehen. Das ist USV, wie auch immer.
Dann eben die Serverbleche, wirklich noch Netzwerkswitchel, die vielleicht noch nicht mal managet sind oder am Ende nicht noch ohne SDN auskommen müssen.
Bis eben über ein Hypervisor Betriebssystem. Alles, was man so noch in einem klassischen deutschen Mittelständler auf jeden Fall findet.
Und eigentlich auch bei jedem großen Unternehmen. Die reden halt nur nicht so oft drüber.
Aber eigentlich das, was jeder braucht und ich glaube, wo auch wir noch herkommen und das immer noch betreiben.
Und dann geht die Infrastruktur, würde ich sagen, mittlerweile bis eigentlich hoch auch in Kubernetes-Themen, weil Kubernetes ja auch kein Selbstzweck ist, sondern halt genauso Teil der Infrastruktur wird.
Von daher ist ja das schön, dass sich Infrastruktur Monitoring da mitentwickelt.
Und in dem Moment, wo eben Themen aus dem Hype in die Masse übergehen, wird es halt relevant auch für die klassischen Infrastruktur Monitoring Tools,
wenn sie relevant bleiben wollen, da sich ein bisschen Gedanken zu machen, wie sie das auch noch mit monitoren können.
Ja, ich glaube auch, dass der Shift Richtung die Cloud oder Microservices das ganze Thema noch mehr beeinflusst.
Dass man die Infrastruktur jetzt nicht als Blech oder VM sieht, sondern das kann jetzt ein Cloud Service sein.
Das ist ein volatiler Dienst oder Service, der erreichbar sein muss. Wie überwache ich den, wenn ich kein klassisches Host Service Konstrukt habe und so weiter und so fort.
Also gerade im Cloud Bereich, wenn man sich AWS anschaut, was man zum Beispiel an Ressourcen bekommen kann, aber gleichzeitig dann auch überwachen muss.
Das ist genauso komplex oder noch komplexer geworden als jetzt eine klassische Infrastruktur.
Ja, also für mich ist Infrastruktur Monitoring, würde ich mal sagen, das klassische Monitoring.
Zumindest bin ich damit, ich sage mal in Anführungszeichen, jetzt aufgewachsen in der Zeit.
Ich bin jetzt hier derjenige, der am jüngsten in dem Thema Monitoring sozusagen drin ist.
Und das ist für mich einfach das klassische Thema beim Monitoring.
Die Hardware unten drunter zu überwachen, VMs, Hypervisor, Storage Sachen. Gert hat es gerade auch schon angesprochen.
PDUs gegebenenfalls, USB und dann alles, was so ein bisschen da drauf noch direkt aufbaut.
Also irgendwelche Web Services, Dienste, die man überwacht.
Und ab der Schicht verschwimmt es dann halt so ein bisschen Richtung anderen Arten von Monitoring, würde ich mal sagen, wo dann auch andere Tools wieder relevanter werden, denke ich.
Ja, geht mir ähnlich. Also ich denke ja auch primär an die Zeiten, wo man dann sich Nagios Plugins oder Isingas Plugins heruntergeladen hat, um eben seinen Lokalen.
Wir haben WebVisual Cluster zu Monitoren, den Switch zu Monitoren, den man irgendwo stehen hat. Hauptsache, man muss sich nicht mit SNMP rumschlagen.
Lieber irgendwelche kuriosen Skripte von SourceForge oder von GitHub runterladen, damit man nicht mit SNMP rumkonfigurieren muss.
Das ist so das erste, was mir da so mit reinfällt.
Und wie würdet ihr das gegenüber Cloud Monitoring abstecken?
Ist das für euch ein Unterschied im Sinne von naja, da gibt es halt andere Plugins oder wie würdet ihr den Unterschied klassifizieren?
Ich würde schon sagen, also gerade weil du lustigerweise das Thema SNMP angesprochen hast, ich bin da ein wenig, ich will nicht sagen, gebrannt,
aber zumindest tippt die Wippe da bei mir in eine etwas andere Richtung. Also ich bin durchaus ein Fan von SNMP eigentlich, gerade weil ich Monitoring seitlich durch das Monitoring von Cisco-Geräten sehr gute Erfahrungen damit gemacht habe,
weil die einfach sehr viel darüber preisgeben. Und im Vergleich zu einem Cloud Monitoring, Cloud Monitoring würde ich jetzt so ein bisschen, wie will man es sagen, Richtung Api-Skripte oder sowas schieben.
Also da zumindest das, was ich bisher jetzt damit gemacht habe, Apis anzapfen beispielsweise bei Microsoft Azure und dann da sich die Informationen rausziehen zu, weiß ich nicht, Credits, die VMs noch haben oder Plant Maintenance,
die man irgendwo überwachen muss, die die eigene Infrastruktur betreffen. Ja, das wäre so mein Unterscheidungsgebiet davon.
Es hat auch eine gewisse Ähnlichkeit zu VMWare und v4 Monitoring, wo man ja früher gesagt hat oder versucht hat mit einem Check Plugin mal auf den Host draufzugehen, auf die Services draufzugehen, um dann festzustellen,
ok, über die Api bekomme ich mehr Informationen oder bekomme es korreliert sozusagen, dass ich nicht sterbe in Alerts, weil die Api in Summe etwas anderes sagt zum Status der Verfügbarkeit.
Und das hat sich im Prinzip verlagert, dass du in Azure, in AWS, in Google Cloud oder auch in kleineren Plattformen bekommst du eine Rest-Api oder eine Api in einer gewissen Art und Weise und im besten Fall dann auch schon Check Plugins oder Infrastructure Code oder irgendwas anderes in der Form,
um das Ganze anzuzapfen und gleichzeitig auch zu verwalten und zu managen. Ich glaube, das ist so ein bisschen so da, es ist immer noch Infrastruktur Monitoring, aber es ist sehr Api, ich würde nicht sagen belastet, Api ist aber ein gewissen Vorteil,
weil sie hoffentlich auch gut dokumentiert sind und auch Anwendungsbeispiele dafür gibt oder Kleingleiber ist, dass man zum Beispiel in Python selbst schnell mal was bauen kann, ohne jetzt das Rad neu erfinden zu müssen.
Ich denke auch, man gibt da so ein bisschen die Arbeit ab, also das, was man on-premise in seiner eigenen Infrastruktur selbst lösen muss im Sinne von, ich muss mir beispielsweise überlegen, welche Metriken ergeben denn in irgendeiner Art und Weise Sinn,
wie kann ich die korrelieren, konsumiere ich das hier einfach bei meinem Hyperscaler, da gibt es dann halt eine Metrik, die sagt dann eben, Ressourcen sind erschöpft oder drohen bald auszulaufen und das kann ich dann natürlich einfach auch wieder konsumieren.
Also man kann so ein bisschen dann korrelieren, wie das ihr auch schon dargelegt habt, was ich an meinem Lokal Monitoring habe, kann ich mit dem abgleichen, was eben der Anbieter mir so rausgibt.
Ich glaube in vielen Fällen, abgesehen davon, dass SNMP kein Cloud Monitoring ist, ich glaube das ist einer der wenigen Punkte, die man nicht debattieren muss, das ist mir gerade auch als aufgefallen, als ihr das so gesagt habt,
aber ich habe das Gefühl, oft fällt Cloud Monitoring so ein bisschen, wahrscheinlich auch zusammen mit dem ganzen Container-Thema, gar nicht unbedingt, weil Cloud immer Container bedeutet, aber weil es jetzt öfter so ist, dass man Ressourcen plötzlich hat, die verhältnismäßig kurzweilig sind und die man vielleicht auch nicht direkt selbst ansprechen kann, sondern man hat eben irgendeinen Orchestrator dahinter, der einem sagt, es gibt jetzt diese Ressourcen und ich glaube das ist so mit dem Monitoring die Hauptherausforderung,
dass man eben nicht mehr die Sachen einzeln definiert, sondern schon allein für die Information, was muss ich denn überhaupt monitoren, was gibt es denn dafür, Objekte, sind ja dann auch nicht mehr unbedingt Hosts, das können ja dann auch einfach nur irgendwie eine Datenbank-Instanz sein und was da für ein Host darunter ist, interessiert mich ja gar nicht mehr.
Und diese Informationen zu nehmen und dynamisch ins Monitoring zu bringen und dann auch gegebenenfalls nach wenigen Stundentagen was auch immer wieder wegzuschmeißen, ich glaube das ist so ein bisschen das Hauptumdenk-Ding, weil theoretisch gefühlt, was heißt theoretisch gefühlt, ich habe es auch immer wieder anfragt, wenn jemand sagt, hey könnt ihr Cloud Monitoring, dann frage ich nach was es ist und dann sagt es ja, die haben da ihre Linux und Windows VMs, die werden in der Cloud gehostet und das ist mir halt glatt egal, weil dann, ob ich die in einem Rechenzentrum zwei Racks weiter monitieren kann,
über TCP oder in der Cloud, das macht halt gar keinen Unterschied.
Also deswegen Cloud Monitoring an sich sagt erst mal gar nichts aus, bis man ungefähr, also außer, dass es kein SNMP ist, aber sonst ist es halt, ja genau, sonst kann es halt, kann es anders sein, muss es aber irgendwie gar nicht eigentlich.
Aber du hast ein gutes Thema angesprochen, von wegen du hast sehr viele Events, du hast sehr viel was schon eigentlich da ist durchaus in der Cloud oder jetzt nehmen wir mal jetzt einen Container Cluster als Beispiel hier, muss ja jetzt nicht Kubernetes sein,
wo wir uns einfach wegbewegen von diesem klassischen Pool-based Monitoring, wo du sagst, ich alle fünf Minuten oder jede Minute polle ich etwas, sondern die Daten sind quasi da und ich kann sie ja streamkonsumieren oder sie stehen über eine REST API, HTTP API wie auch immer zur Verfügung,
wo ich natürlich in der ersten Form mit Autodiscovery von zu vielen Daten erschlagen werden kann, was aber mitunter gewisse Vorteile hat, wenn, ok, Machine Learning wird jetzt nicht in jedermanns oder jederfraues Firma schon laufen,
aber es gibt halt einfach Möglichkeiten heutzutage, man sagt, man wird diesen, man kann diese vielen Daten, die man zur Verfügung hat, man kann auch damit was machen und kann das dann entsprechend aggregieren versus ich hab genau gar nichts und ich muss auf der grünen Wiese anfangen
und mir überlegen, welches Plugin oder welche Integration das hier mal installieren muss und ich glaube, dieser Wandel oder diese Challenge, die wird uns noch viele Jahre begleiten, um dann zu schauen, wo Monitoring in Zukunft sein wird.
Ich denke, das verschwimmt auch so ein Stück weit, also wenn ich mir jetzt mal eure Definition von Cloud Monitoring durch den Kopf gehen lasse, haben wir ja festgestellt, es geht zum Beispiel auch so in die Richtung, was kann man einfach konsumieren,
ihr habt ja auch über Container in dem Kontext gesprochen, wo man sich einfach keine Gedanken machen will, wo läuft jetzt die Anwendung, läuft die in Pod A, B, C oder sonst wo, das geht ja auch noch ein Stück weiter, wenn ich mich jetzt einfach mal in der Rolle eines Entwicklers oder einer Entwicklerin sehe,
dann will ich ja auch mir um diese Dinge nicht unbedingt Gedanken machen und ich glaube oftmals wird Cloud Monitoring mit Anwendungsmonitoring auch ein Stück weit verwechselt, was ja eigentlich doch ein ganz anderes Thema ist.
Vielleicht sollte man da auch noch mal kurz darauf eingehen, warum das jetzt für Entwickler*innen interessant sein könnte, direkt bei der Entwicklung einer neuen Anwendung direkt schon an Monitoring zu denken. Wie ist da eure Meinung dazu?
Mein erster Gedanke wäre da so zu, wenn ich jetzt Änderungen in meiner Applikation vornehme, code-seitig oder was auch immer, habe ich durch das Monitoring natürlich direkt eine Sicht darauf, wie sich das auf die Infrastruktur unten drunter auswirkt,
raucht mir die VM dann ab oder ist das so ein Rammfresser oder was auch immer oder ist mein Dienst dann überhaupt noch erreichbar nach meiner Änderung, die ich gemacht habe.
Also das wären so die ersten ganz simplen Punkte, die man da mit überwachen könnte.
Ich kann da aus Nähkästchen plaudern. Wie wir Isinga 2 entwickelt haben vor vielen Jahren hatten wir so ein Staging-System und so ein Anwendungsmonitoring-System nicht.
Das heißt unter Umständen hast du beim Programmieren einen Fehler gemacht und dann hat ein Git-Commit oder eine Serie von Änderungen dazu geführt, dass der Memory-Verbrauch ums Zehnfache gestiegen ist oder ums Doppelte.
Das würde schon reichen und das Problem an der ganzen Geschichte ist, natürlich verwendest du CI/CD und Tests und Builds und Sonstiges, aber irgendwann wird halt eine neue Version, ein neues Release geteckt und dann rollt der Kunde aus oder der User und sagt, naja das funktioniert nicht mehr.
Out of Memory-Crashes oder Deadlocks oder wenn DNS nicht funktioniert, dann crash das Ding. Alles so eine wunderschöne Mischung.
Viele Jahre später dann, als ich mir das Thema wieder angeschaut habe, habe ich mir überlegt, es wäre doch eigentlich schön gewesen, wenn die Applikation, in dem Fall ist es ein Monitoring-Tool, was gemonitort werden sollte, wenn das einfach ausgerollt wird irgendwo und ich kann die Metriken abgreifen und sehe dann in meinem Merch-Request oder Pull-Request einfach Hoppala, Memory geht mit diesem Commit ums Doppelte hoch, der Merch ist jetzt geblockt.
Und ich muss nicht um, keine Ahnung, drei Uhr früh oder wenn der Kunde anruft vorgestern, schnell einen Buck Fix bauen, wo ich eh nicht weiß, was das Problem eigentlich ist, was unter Umständen zur Entwicklerburnout führt.
Und so ist es halt im Endeffekt, es ist nicht überall so, dass man jetzt sagt, man kann jetzt eine Staging-Umgebung sofort bauen oder sofort verfügbar halten, aber es ist durchaus ein wichtiges Thema, um auch einem Entwickler oder Entwicklern die Möglichkeit zu geben, frühzeitig auf Änderungen zu reagieren, die man nicht wirklich vorhersagen kann.
Sagt mal eine Deadlock voraus oder sagt mal Memory Leaks voraus, da würde ich einen anderen Job machen, wenn ich das wüsste.
Schwierig, da habe ich gehört, da ist so ein Life Hack einfach immer, wenn man neue Funktionen schreibt, in jede Funktion, in jede Schleife erstmal ein Sleep von ein paar Sekunden reinzubauen, das auszurollen, wenn der Kunde genervt ist, die Sleep-Zellen rauszunehmen, weil dann denkt der Kunde, boah, guck mal, die haben so krass optimiert, die Transaktionen laufen jetzt alle doppelt so schnell.
Das Problem ist Open Source, also Problem, man sieht, was gemacht worden ist, also das wird vielleicht im Enterprise-Umfeld funktionieren mit properer Therencode, aber Open Source ist Gott sei Dank so, dass jeder mitmachen kann und jeder reinschauen kann, aber klar, mit diesem Gedanken hatten wir auch schon mal gespielt, so ist es nicht.
Sehr schön. Wie sieht das bei dir aus, Gerhard? Thema Anwendungsmonitor, hast du dich damit schon mal auseinandergesetzt?
Ich meine, es kommt immer wieder vor und gefühlt ist es dann oft eins von zwei Extremen, man hat dann entweder Anwendungen, die da halt gar nichts hergeben, so die schreiben einen Log vielleicht mal, wenn sie selbst einen Fehler haben, aber das war es auch, und auf der anderen Seite Anwendungen, die sagen, ja, ich bin hier so eine tolle Java-Applikation, hier ist JMX, hier sind 8000 Werte, welcher davon relevant ist für die Performance?
Das weiß der Entwickler, der das JMX vor 5 Jahren eingebaut hat, das kann dir heute keiner mehr sagen, und irgendwie fehlt mir manchmal so der Mittelweg, wo ich mir denke, jemand, der die Applikation geschrieben hat, müsste da ungefähr wissen, was sind so eigentlich die Eckdaten, wo es richtig der Applikation schlecht geht, und das dürfte dann wahrscheinlich oft, ist für uns dann oft die Schwierigkeit, da rauszufinden, wann läuft das Ding denn eigentlich, was können wir denn machen?
Wenn wir jetzt eine Applikation durchziehen, oder bei irgendwelchen Web-Applikationen, dann sagen die App, ganze Geschichte ist so komplex geworden, die einzelnen Komponenten zu monitoren, klar, das kriegen irgendwie einen Netflix-Sinden und so was, die alles selber bauen und jede Komponente im Griff haben, aber normalerweise sag ich, wenn es insgesamt gut läuft, dann bin ich ja irgendwie glücklich, und dann simuliere ich mir halt irgendwie einen User, der sich da durchklickt, und sag dann halt, okay, wenn es, und gehe dann ins Tram-Shooting, überlege, was ist denn schief gegangen, wenn es bis gestern lief, und heute Nacht wurde irgendwas gemacht, und seit heute Morgen ist alles halb so schnell nur noch, oder?
Wird gar nicht mehr fertig, dann wird dann nachgeguckt, aber das wird dann eher im End-to-End, oder ich glaube, der Ami-Hype-Begriff ist jetzt "Synthetic Monitoring", jetzt so reines Applikations-Monitoring kriegen wir jetzt aus Infrastruktur-Sicht vielleicht seltener mit, mit richtig mit Release-Taggen, aber da kommt vielleicht auch einfach, da ist vielleicht auch mein Selection-Bias drin, dass ich einfach sowas als Kundenanfrage nicht so häufig sehe.
Stimmt, ja, ich finde es auch schön, immer wenn man so eine Frage stellt, die in Richtung Anwendungs- und Performance-Monitoring geht, dass bei, egal mit wem man spricht, das erste Beispiel immer eine Java-Anwendung ist, wie jetzt auch bei dir. Also da heilt der Ruf der Sprache dann doch etwas voraus, ob das gerechtfertig ist, ist eine andere Sache, aber schön, wäre jetzt nämlich auch genau mein Beispiel gewesen.
Ich glaube, das war Zufall, ich habe eigentlich gar nicht so oft irgendwelche Java-Anwendungen, aber das kam mir jetzt irgendwie gerade in den Kopf, als ob wir mal in Daten ertrunken sind und niemand wusste, was eigentlich davon gewollt ist, aber das gibt es mit Apis genauso, also es hat auch schon mal jemand eine Api hingeworfen, die hatte 800 Funktionen, aber keiner konnte uns sagen, was jetzt eigentlich wichtig ist davon.
Aber du hast gerade ein gutes Stichwort genannt. Du hast mich gerade an meine Abenteuer in JMX4Pearl erinnert vor 10 Jahren oder so, im Consulting unterwegs war.
JMX4Pearl, das klingt nur falsch.
Es ist ein gutes Tool. Ich finde nur die Kombination geil. Es ist halt in Pearl geschrieben und du konntest dann auch das ganze Inventor und Checkplugin verwenden. Das ist von dem Konsol-Team entwickelt worden, die auch in Niemann und ich spreche das sicher falsch aus, Thruk involviert sind und an anderen Geschichten im Nagelsumfeld.
Und das war halt auch so, ich hatte keine Ahnung, wie ich hier in WebSphere oder Java überwachen kann, aber hier JMX4Pearl und dann schaut man halt mal und dann dokumentiert man dann auch für den Kunden, welche Metriken sind interessant und was kannst du komplett wegignorieren so in der Richtung.
Aber sagen wir so, es ist halt sehr schön, dass es im Open Source Umfeld Leute gibt, die sich Gedanken zu dem Thema machen und das dann auch der Gruppe oder allen Leuten zur Verfügung stellen.
Was eben in anderen Close Source Enterprise Umgebungen ein deutlich schwieriger ist.
Wo du dann vielleicht mit der DB2 CLI irgendwie die Datenbank abfragen kannst und dann funktioniert es aber doch wieder nicht.
Ja, Gerd hat eben auch ein gutes Stichwort genannt und zwar hast du ja davon gesprochen, so eine End-to-End-Monitoring Sache vielleicht vorzunehmen.
Und das ist für mich auch so ein bisschen das, was ich mit dem Synonym End-User-Monitoring in irgendeiner Art und Weise verbinde. Also da stelle ich mir so Dinge vor, wie beispielsweise man hat so eine tolle Web-Anwendung, wo User sich Dinge bestellen können oder andere Dinge tun können.
Und dann hat man eben einfach einen dokumentierten Prozess, klicke auf Button sowieso, trage das ein und dann wird hier eben End-to-End diese ganze Performance mal gemessen.
Wie viel Millisekunden braucht das Ganze? Wie lange dauert es, bis die Transaktion auch wirklich in der Datenbank ist?
Also gerade für Betreiber*innen von Webshops ist das glaube ich eine interessante Sache. Habt ihr euch damit schon mal auseinandergesetzt?
Auseinandergesetzt ja und sage ich mal. Ich versuche ehrlich gesagt so dieses ganze Thema Anwendungs-Monitoring, End-User-Monitoring so ein Stück weit von mir wegzuschieben, wenn es um ein System geht, was Infrastruktur überwacht.
Also wenn ich jetzt wirklich da mit einem Icinger arbeite und jemand sagt, ich möchte jetzt aber hier gerne wissen, wie oder ob mein Login in XY funktioniert, dann sage ich noch, das kriegen wir vielleicht noch irgendwie hin über einen Check-HTTP mit irgendwie Username, Passwort mitgeben oder sowas.
Auch das wird schon ein bisschen, ich will nicht sagen eklig, aber unschön teilweise. Aber wenn es dann wirklich an User-Aktionen geht, die Sachen simuliert durchzuführen, dann versuche ich das ehrlich gesagt immer zu vermeiden.
Also ich weiß, dass es, ich glaube auch von den Konsol-Leuten so ein Tool, Zerkuli heißt es glaube ich, gibt, was sowas machen kann und wahrscheinlich auch gut.
Haben wir glaube ich sogar bei der alten Firma damals irgendwann mal dran überlegt, sowas zu machen, um so Sachen wie Ticket-Eröffnungen oder sonst irgendwas zu simulieren und zu monitoren.
Aber ja, ich weiß nicht, es ist dann irgendwie immer an dem großartigen Sinn gescheitert, sage ich mal.
Und mittlerweile gibt es dafür ja auch sehr, sehr spezielle Tools oder sehr spezialisierte Tools.
Wenn es nicht speziell spezialisiert ist, denke ich mal besser sowas wie App Dynamics von Cisco mittlerweile, was das halt extrem gut kann und sich aber auch extrem gut bezahlen lässt.
Ja und das ist, also ich habe in der Vergangenheit vor vielen, vielen Jahren glaube ich mal Casper Jazz gesehen und Web-Inchecked glaube ich hieß das Ganze. Aber es verlagert sich natürlich auch das Frontend, das ist jetzt nicht nur eine Seite, sondern das ist hinter dem Load Balancer mehrere Knoten unter Umständen.
Das Backend läuft irgendwo und was ich zum Beispiel jetzt bei GitLab und unseren SREs und Ingenieurs sehe ist Sentry für Error Tracking, wo du eben aus vielen verschiedenen Teilen mehr oder weniger den Trace dann rausziehen kannst.
Der Trend geht natürlich auch in die Richtung, zu sagen mal Instrumentation, das deutsche Wort ist schwierig, mit Open Tracing, Open Telemetry, anderen Themen, wo man halt weggeht von klassischen Metriken oder Logs Richtung Observability Themen sozusagen.
Aber das bedeutet natürlich auch, dass man umdenken muss, umlernen muss, unter Umständen einen Code anfassen, wo hoffentlich schon Logzeilen drinnen sind.
Und auch wenn der Benutzer jetzt sozusagen einen 500er sieht zum Beispiel, ist nicht dieses Event des 500ers jetzt wichtig, sondern die Error Rates gehen im Backend hoch oder der Load vom API Server oder den Pots dahinter.
Das führt zu diesem Problem und das wird dann auch entsprechend alarmiert, landet im Pager Duty, landet im Slack und derjenige oder diejenige, die on Call sind, werden entsprechend notifiziert.
Und unter Umständen ist man hoffentlich schneller als der User, der dann auf GitLab.com den 500er sieht.
Aber man kann es natürlich unter Umständen auch nicht vermeiden, dass Fehler auftreten, aber sie lassen sich schneller lösen heutzutage.
Ich glaube, das ist so ein bisschen die Luxus, das ist falsch.
Klar, wenn man selbst die ganze Applikation kontrolliert und überall in den Code rein fassen kann und also nicht nur, weil es Open Source ist, sondern weil man vielleicht auch noch technisch dazu in der Lage ist, das zu verstehen,
dann ist es natürlich geiler, wenn ich in jede Komponente einzeln reingehe und dann kann ich mir den Luxus gönnen, um zu sagen, ich kriege das mit, bevor es wirklich bei den Usern auffällt.
Wir sehen halt immer noch bei vielen Kunden, die dann halt irgendwelche Software einsetzen, die sie halt irgendwo zukaufen.
Und selbst wenn die Open Source wäre, würde glaube ich keiner in dem Unternehmen aus der ABT-Abteilung sagen, ich hack mich da jetzt rein.
Und für die ist dann natürlich so ein End-to-End-Monitoring cool, weil dann können sie einfach nachvollziehen, was die Nutzer machen und kriegen es zumindest schneller mit.
Und es klingt jetzt doof, aber selbst wenn manchmal die Lösung nur ist, zu sagen, wir wissen, wenn das passiert, dann müssen die Kollegen hinten irgendwie einen Message-Pass nochmal durchstarten, weil der sich da irgendwas verhaspelt hat.
Sie kriegen es halt trotzdem schneller mit und wissen auch, ja, das ist nicht der User, der jetzt hier gerade anruft, der sagt, Applikation XY geht nicht, sondern sie wissen es etwas genauer.
Ich kam früher dazu, Web Inject und Selenium kommen aus einer ähnlichen Richtung, da habe ich das im Studium schon mal gesehen.
Wir haben es jetzt dann lange nicht gemacht, weil auch oft Kunden sagen, naja, wollen wir wirklich da den User nach simulieren, weil man dann halt auch idealerweise braucht, man ja dann auch ein System, was den User komplett simuliert.
Aber es wird jetzt halt leichter, also wir haben im Checkmk gibt es jetzt eine schöne Integration, die hat der Simon Meggle gebaut, der war mal bei der Console, glaube ich.
Und der hat jetzt um das Robot-Framework, was glaube ich von irgendwelchen Norwegern kommt, wenn ich das jetzt nicht verwechsel,
hat er quasi Robot-MK drumherum gebaut, damit man wirklich schön sich relativ leicht so komplette Guides basierte oder Webbrowser basierte, aber auch wir können auch eine klassische Subguide durchklicken, was wirklich keinen Spaß macht.
Kann man sich halt dann schön in den Test Case bauen, der wird vom Checkmk ausgeführt und mit Screenshots dokumentiert, dass man sieht, wo bleibt das ganze Ding hängen.
Und dadurch ist die Hürde jetzt schon ein bisschen gesunken, weil man plötzlich die Übersetzung von diesen grafischen Checks in einen Monitoring-Check, der Nagios oder Checkmk kompatibel ist, hat.
Und das soll auch weitergehen, also es steht auf der Roadmap vom Checkmk, dass sie es einem noch einfacher machen wollen.
Von daher, ich vermute, das wird mehr, weil einfach in dem Moment, wo es einfacher ist, kommt den Leuten auch eher die Idee, das könnte man doch da und da auch noch einsetzen.
Und ich glaube, das hat wahrscheinlich jeder von uns schon mal erlebt, dass beim Monitoring ganz oft so ein bisschen der Appetit beim Essen kommt.
Wenn man dann erstmal paar Sachen gemonitert hat, die und die haben einem eine Nacht am Wochenende erspart, dann kommt man auf die nächsten Probleme, die man gerne verhindern würde oder früher erkennen würde.
So ein bisschen.
Definitiv.
Absolut, ja.
Also ich kann mich da auch dran erinnern. Irgendwie die erste Nagios oder Isingar-1-Home-Lab-Installation, nachdem das Hello World gemeistert war, waren da nach dem langen Wochenende auf einmal ruckzuck 150 Services, die da drin waren.
Und ich habe mir danach die Frage gestellt, dass ich nicht erwartet hätte, dass so viele Dinge bei mir im Lab irgendwo laufen könnten.
Also da gibt es viel Möglichkeit, die Sichtbarkeit zu erhöhen auf jeden Fall.
Es hat mich jetzt auch gerade an so 2010, 2011 erinnert auf der Uni Wien, wo wir das Nagios wie die Isingar ersetzt hatten und dann so, ja, wir müssen jetzt Switches und Netzwerk-Hardware überwachen.
Und dann haben wir Check & Car entdeckt oder ich habe das nicht entdeckt.
Das waren meine Kollegen im Admin-Team.
Und ja, da können wir quasi eigene Checks in Python schreiben.
Es hat dabei gar nicht keine Programmierer.
Ja, denn das geht schon.
Und das Interface ist einfach zu lernen.
Und da kann ich so viele Dinge rausziehen, also ein Catalyst 7509 oder irgendwie so.
Und der Kollege, der da mit mir in diesem Projekt war, was glaube ich 15 Monate dann gedauert hat, der hat so viele Checks geschrieben und hier diese Daten.
Und das ist noch relevant.
Und da muss ich nicht debuggen in der Konsole.
Und ich glaube, das läuft immer noch.
Ich habe keinen Kontakt mehr.
Aber das war wirklich so mit dem mit dem Tool wird man quasi alt.
Und da kannst du wahrscheinlich auch klassische Open Source Wenderlocken.
Da kannst du nie wieder weg.
Aber das hat hat damals auch Spaß gemacht, Sachen zu bauen.
Also weil Plugin API bin ich kein Fan davon.
Check & Car hat schon ein bisschen hat es ein bisschen frühzeitig erkannt, wo die Reise hingehen muss.
Absolut. Also da hatte ich auch mal einen Bock gemacht bei meiner ersten Firma.
Da war nämlich auch die Überlegen, ob man vielleicht von einem Nagelsauf in Check & Car geht.
Und gerade so dieses Auto Discovery.
Du schreibst halt rein, welche Systeme dich interessieren und Check & Car geht halt einfach her und guckt mal, was gibt es denn auf dem System?
Was könnte man denn über überwachen?
Das ist halt ein ganz anderer Ansatz gegenüber dem Ich konfiguriere deklarativ, was ich mit welchen Schwellen werden, wo überwacht haben möchte.
Das macht es dann doch schon um einiges leichter.
Aber ich merke, wir verlieren uns schon so ein bisschen in den Tools hier gerade, was auch okay ist, weil vielleicht können wir das einfach mal als Überleitung nutzen und mal so ein bisschen drüber sprechen.
Was sind denn so übliche Monitoring Tools?
Wir haben ja schon alles so ein bisschen angerissen, sehr oberflächlich.
Aber ich glaube, den den meisten Zuhörenden wird es so gehen, wie es mir geht. Wenn ich das Wort Monitoring und Infrastruktur Monitoring höre, dann denke ich meist unweigerlich an Nagels und dann Isinga.
Vielleicht fangen wir mal damit an. Was hat es denn damit so auf sich? Wo kommt das Ganze her? Und wie ist denn da heutzutage so das Stellenwert?
Vielleicht magst du kurz mal einleiten, Michael?
Ich drehe mal das Rad. 1999 war es mehr als 20 Jahre zurück, wo der Isengard Stats NetSaint entwickelt hat.
Damals war er selber Admin und wollte etwas überwachen, was nicht nur Shell und Pearlscripter sind und hat das Ganze als NetSaint veröffentlicht.
Das Problem war dann, dass eine andere Firma eine Trademark auf NetSaint hatte und er wurde gezwungen, das umzubenennen.
Und Nagels ist ein Akronym für NetSaint Ain't Gonna, keine Ahnung, Wikipedia weiß mehr.
Wo ist man aber in Erinnerung geblieben?
Insist. Nagels Ain't Gonna Insist on Sainthood.
Ja, das war sozusagen ein Wortspiel. Und es war dann effektiv so, dass das Tool populär geworden ist als Open Source in CVS gehostet.
Irgendwann wurde es dann auf SVN mitgekriegt und es haben andere Firmen, die es sozusagen verwendet haben und dann veredelt haben,
also quasi ein Enterprise Produkt oder zusätzliche Plugins oder irgendwas anderes rundherum noch gebaut haben. Die haben dann mitgemacht.
Zwischen drinnen, glaube ich, der Tom Woon von Ops View und Andreas Ericsson von OP5 damals.
Und wie dann das Ganze, wie dann sozusagen jede eine Firma rund um Nagels hatte, nur da ist er nicht, wurde dann 2007.
Ich weiß gar nicht, war das? Na, 2007 war das nicht. Nagels Enterprise, das gab es schon früher, aber das Enterprise Produkt wurde, glaube ich, 2010 oder 2011 herum angekündigt.
Da sind wir nämlich auf der Open Source Monitoring Konferenz in Nürnberg gewesen und irgendwie aus allen Wolken gefallen. Nagels XI.
Da gab es dann die Scherze mit Extended Income, aber das stimmt natürlich nicht, weil sozusagen die ganzen Add-on Entwickler, so PNP von Nagels,
das ist Daten sammeln, Metriken mit RID Tool und das Ganze schön visualisieren und dann ins Monitoring einbinden.
Der Jörg Linge damals wusste, glaube ich, nichts von Nagels XI und dass das halt PNP auch verwendet.
Und er durfte dann Support machen für die Enterprise Version oder so irgendwie.
War, glaube ich, eine interessante Zeit, wo jeder so ein bisschen versucht hat, Geld mit Open Source zu verdienen.
Manche haben es halt ein bisschen besser gemacht. Bei Nagels XI war es dann, glaube ich, eher so,
dass alle Community-Projekte, die irgendwie Nagels im Namen hatten, mussten dann mal umbenannt werden.
Was irgendwie dazu geführt hat, dass es dann diverseste Forks gab.
Also einer der ersten Forks von Nagels waren natürlich eSinger.
eSinger, eIsinger, eIsinger, wie gesagt, es gibt irgendwo ein Audiophile, wie man es genau ausspricht.
Das darf, glaube ich, jeder aussuchen.
Ja, heißt auf Zulu to Monitor. Also ein Name, der quasi schwierig zu traden, also den noch niemand irgendwie in einer Trademark hatte.
Und war durchaus auch witzig, weil es jeder falsch ausspricht.
Und die Idee oder sagen wir so, die Reise geht dann noch weiter, dass die Entwicklung von Nagels schon wieder ein bisschen Fahrt aufgenommen hatte.
Aber in der Community dann ein Python-Rewrite oder Fork entstanden ist, namens Schinken.
Die ja einige Dinge im Bereich Netzwerk Monitoring und verteilte Umgebungen, was Nagels damals nicht wirklich konnte.
Oder wenn man jetzt gemein ist, noch immer nicht kann, dass das sozusagen Schinken diese Probleme löst.
Dann muss ich sehr weit zurückgehen und nachdenken.
Ja, das glaube ich.
Kurz kurze Zwischenfrage. Hast du je Nagels XI irgendwo benutzt oder gesehen?
Weil ich stürze immer wieder auf Doku und dann holt man eine halbe Seite runter und hat das Gefühl.
Okay, also Marketing ist top, aber irgendwo kommt dann plötzlich rein und dann konfigurierst du diesen Befehl und musst wieder alles per Hand machen.
Also ich würde mal interessieren, ob das mal jemand benutzt hat und ob die auch irgendwas Cooles gemacht haben.
Ich habe es einfach selber nie benutzt, muss ich gestehen.
Ich glaube, es entspringt mehr des amerikanischen Marktanspruch, wo du quasi ein Produkt kaufst und Support bekommst.
Und du hast vom Team-Onboarding zum Beispiel schöne Visats, wo du dir Windows Monitoring zusammenklicken kannst.
Und das war durchaus am Anfang etwas, was es bei Nagels Singer 1, ich glaube Jack MK, auch noch nicht wirklich gab.
Zumindest in dieser Form. Wir reden jetzt von 2011, 2012 um den Dreh herum.
Es gab dann, ich habe das auch eine Zeit lang verfolgt, was sich bei Nagels so tut, diverse Produkte wie einen Log Manager,
der im Prinzip ein Vorgang vom Elkstack war oder eine PRP Oberfläche mit Elkstack.
Es gab einen Manager, der im Prinzip ein Puppet war für Infrastrukturmanagement.
Also viele Dinge einfach selbst entwickelt, weil wahrscheinlich der Kunde es gezahlt hat oder auch nicht.
Aber so wirklich durch die Decke gegangen ist es halt auch nie.
Also ausprobiert habe ich nur die Webdemo, die sich auch unter Umständen mit Admin-Rechten ausführen ließ.
Aber gegenüber jetzt einer, wenn wir jetzt von Enterprise Produkten sprechen im Rahmen von einem Ops View oder von OP5 in der Form, was es damals gab,
oder auch Groundworks, war Nagels XI halt irgendwo, also irgendwo weit hinten.
Dann hat natürlich Jack MK ordentlich Gas gegeben, was die Weiterentwicklung betrifft und diverse andere.
Ja, Centran hat auch Nagels dann geforkt in die Centran Engine irgendwann und hat den hässlichen C-Code in C++ umgebaut.
Aber ja, da ist einiges passiert und dann hat sich der Andreas Ericsson mit dem Eastern irgendwie zerstritten eben.
Dann ist Niemann geforkt worden von Nagels IV, was damals der Andreas in Eigenregie eigentlich entwickelt hat.
Nagels IV hat dann einige Dinge besser gemacht mit verteilten Monitoring und ich muss jetzt überlegen, das ist schon so ewig lang her.
Ich habe versucht, das damals dann irgendwann auch in Singer 1 rüberzuziehen, weil die GPL als Lizenz ja kompatibel ist.
Aber ja, war nicht von Erfolg gekrönt, wenn man es mal so nennen will.
Da war die Zeit von Isingar 1 ja eigentlich auch schon glaube ich quasi vorbei, oder?
Als in den angenanke 4 kam, war doch Isingar 2 schon fast fertig, kriegst du gerade Zeit nicht mehr ganz hin, aber gefühlt war das relativ ähnlich zeitlich.
Ja, also ich kann mich, also wir waren im Frühjahr 2012 waren die Kollegen von Netway in Wien zu Besuch und wir haben über Isingar 2 gesprochen, damals Codename "Strawberry".
Also findet man sicher irgendwo noch im Internet.
Und da gab es eben sozusagen, wir machen es jetzt in C++ auf Basis von Boost Framework und anderen Themen, weil davor gab es schon diverse Versuche Richtung, wir nehmen jetzt einen Message Bus, ähnlich wie ModGearmen, das quasi gelöst hat.
Also die Checks werden in Jobs in eine Queue geschoben, wird irgendwo ausgeführt und blockiert den Chor nicht, weil alles was du Single Threaded in einem Prozess ausführst, blockiert natürlich.
Das war glaube ich mein Hauptproblem von Nagios 3 und Isingar 1, dass das einfach nicht in die Breite und auch nicht in die Höhe eskaliert hat und einfach nicht mehr zeitgemäß war.
Und diese Isingar MQ wurde auch mal vorgestellt auf einer Konferenz, aber dann glaube ich wieder eingestampft.
Und Isingar 2 war dann sozusagen die Idee, mal von vorne anzufangen und sich zu überlegen, was kann man der Config Sprache ändern, eben neue Config Sprache, was auch nicht zu viel Liebe geführt hat bei den Admins am Anfang, weil das natürlich was komplett Neues war und es gab keinen Migrationsscript.
Ich habe eins in Perl geschrieben, aber das hat nicht gut funktioniert und das ist auch schon acht Jahre her. Aber damals war es noch eine schöne Zeit.
Über die, wie sagt man da, Isingar 2 ist einfach 2014, also nach zwei Jahren oder zweieinhalb Jahren Entwicklungszeit, ich würde nicht sagen fertig gewesen, aber es war ein Stand, den man als erste Iteration halt releasen konnte.
Da gab es noch keine Agenten, da gab es noch keine AP, aber ja und Isingar 1 wurde trotzdem weiter maintained, weil es doch noch viele User gab in dem Umfeld, die gesagt haben, Isingar 1 und ModGearMan, geil, braucht nichts anderes.
Man ist, glaube ich, geschockt. Fast so häufig wie Kunden, die gar keinen Monitoring haben, findet man dann auch immer noch welche, die wirklich einen Nagios 3.3 oder 3.5 im Einsatz haben, wo man sich denkt, ihr hattet einfach seit acht Jahren keine Zeit, hier drüber nachzudenken, oder?
So ist es dann manchmal. Aber klar, ich glaube, es ist immer noch sinnvoller, einen Nagios zu haben, wo man nicht mehr viel macht, weil man die Zeit nicht hat und dafür weiß man aber die Warnungen, die rauskommen, darauf reagiere ich auch.
Genauso haben wir Kunden, die sagen, ich hatte hier das und das Tool, aber das hat von Anfang an 800 Warnungen am Tag geschmissen, wir haben es nie in den Griff bekommen. Das ist so Kandidatskomm, wo man nach vier Jahren sagt, lass das abbauen, weil niemand versteht, was das Ding alles anmeckert und wir kriegen es nicht eingestellt und außerdem ist es langsam.
Manchmal ist vielleicht wenig Monitoring, und da ist ja, wenn man über jeden Check nachdenken muss wie im Nagios, das hat ja auch einen Vorteil, weil dann ballert man sich nicht irgendwie das Monitoring mit Checks voll, die man eigentlich gar nicht haben will. Hat hier schon auch seinen Vorteil.
Ich glaube, einer der Knackpunkte war, also damals gab es wieder Nagios Exchange und dann auch irgendwann den Singer Exchange als Marketplace. Die Suche nach Plugins für deinen Zweck, die dann nicht funktioniert haben oder eine PHP oder Python Version brauchen, die vor zehn Jahren aktuell war.
Ich glaube, das hat unter Umständen immer wieder mal zu Problemen geführt. Also ich habe auch schon öfters mal in die Tastatur gebissen, weil du einfach das nicht findest, was du brauchst.
Natürlich kann man dann hergehen und sagen, ich kann ein bisschen entwickeln und bin dann auch von Pearl auf Python gewechselt, was Plugin-Entwicklung betrifft. Aber das kann halt nicht jeder und das kannst du dann nicht voraussetzen, dass jemand, der quasi zuständig ist fürs Monitoring und auch für die Administration Infrastruktur, dass du dich jetzt hinsetzt und sagst, so jetzt schreibe ich mir meinen Plugin selbst.
Also dieses an die Hand nehmen und vielleicht schon eben deswegen JackMK sehr schöne Idee mit integrierten Plugins oder mit Frameworks, weil du damit einfach viele Dinge an die Hand bekommst, die du sonst halt mühsam nicht finden würdest im Internet unter Umständen.
Das stimmt ja. Also ich finde es auch immer wieder noch interessant. Also ich habe vorher auch einige Monitoring Plugins geschrieben und habe die dann halt eben auch auf GitHub zur Verfügung gestellt, habe die eben im Monitoring Exchange auch verknüpft, dass da auch andere von profitieren können. Und ich kriege da teilweise heute echt noch Bugreports rein. Und neulich hat irgendwie einer gesagt, hier dein Plugin funktioniert nicht. Und dann war das so ein acht Jahre altes Plugin, das natürlich nicht Python V3-kompatibel war.
Und das haben wir dann halt gefixt. Und ja, also ich sehe auch teilweise echt bei manchen Kundinnen noch ein super altes Nagios 3. Nagios 4 ist immer noch die aktuelle Major Version.
Und ja, ich finde halt auch, so wie Gerd sagte, lieber ein altes Nagios als gar kein Monitoring. Aber so irgendwann sollte man dann schon den Absprung schaffen und sollte dann ein moderneres Tool in irgendeiner Art und Weise finden.
Es ist halt ein sehr ungeliebtes Thema immer noch bei vielen Unternehmen. Also ich glaube so von der Priorität ist für viele so, erst mal muss alles laufen, dann können wir anfangen über Backup nachzudenken.
Und dann, wenn das halbwegs geklärt ist, dann fangen wir an über Monitoring nachzudenken. Und das ist das ist ein bisschen schade, wenn man halt in vielen Unternehmen dann merkt, okay, da ist einfach nicht der Zug dahinter.
Führt aber letztlich auch dazu, dass oft finde ich, dass das Leben als Monitoring-Admin auch ein bisschen entspannter ist, weil ich habe quasi nie den IT-Leiter vom Kunden im Nacken, weil er sagt, oh, dass der Check und der Check im Monitoring funktioniert nicht, weil das interessiert ihn halt auch einfach nicht.
Also es ist einfach im Monitoring ist der Puls meistens ein bisschen niedriger, weil das Problem ist dann ja eher woanders.
Und das kann ich nicht verstetigen. Ich finde auch, also gerade so das Thema Monitoring hast du ja gerade schon gesagt, es wird gerne stiefmütig behandelt, wenn es vorhanden ist, oftmals gerne nach dem Motto Never Touch a Running System, dass man das einfach mitnimmt, was man hat.
Ich meine, wir haben bis 2016 auch noch als Inga 1 verwendet als Monitoring-System, was auch gut funktioniert hat.
Und ja, das. Das macht es dann halt einfach aus, wenn es gut funktioniert.
Ich wollte noch kurz für die für den für Zuhörer und Zuhörerinnen, die nicht wissen, was ein Plugin ist oder was ein Check tatsächlich bedeutet.
Die Idee ist zu sagen, ich habe jetzt einen Dienst, ich habe eine Möglichkeit, ich möchte etwas überwachen.
Wie bekomme ich den Zustand von dem Ganzen? Und die ein Plugin ist sozusagen ein Skript, was jetzt in einem Schell Skript oder in einer anderen Sprache geschrieben sein kann.
Und die Idee davon ist, man bekommt einen Output quasi am Terminal oder im Web Interface, wo drin steht, die Festplatten sind OK oder die der Wert überschreitet einen Threshold,
einen, das deutsche Wort für Threshold. Schwellwert. Danke, Schwellwert.
Und man kann dann sozusagen den Status davon ändern und weil es eben weil Narios aus der Linux Ecke ursprünglich kommt oder Unix Ecke einfach mit einem Exit Code Exit Code 0 ist OK.
1 ist Error Code ist quasi im Narios Sprech ist das oder in der Narios Plugin API ist das Warning.
2 ist Critical und 3 ist Unknown. Und mit dieser minimalistischen API sozusagen oder Plugin API habe ich die Möglichkeit, einfach meine ganzen eigenen Dienste zu überwachen.
Kann da mit dem Raspberry Pi meinen Temperatursensor zum Beispiel überwachen damit oder andere Dinge tun.
Und diese Plugin API gibt es seit über 20 Jahren. Dazugekommen sind sogenannte Performance Daten, die mir dann die dann auch die Werte in passbarer Version sozusagen für für Metrics Sammler verfügbar machen.
Das werden wir uns dann später noch ein bisschen drüber sprechen.
Aber im Wesentlichen geht es um Plugins, um diese API, um Jax, die dann zyklisch ausgeführt werden und in Narios und Narios und Check and Count, anderen Tools sozusagen die Datensammler, die Datenkraken sind.
Also ohne Plugins kannst du da in Narios oder Narios hinstellen und es wird genau nichts tun.
Also es ist essenziell für die Funktionalität, dass du diese Plugins eben findest. Und es gibt die Narios Plugins oder Monitoring Plugins auch eine unschöne Vorgeschichte 2014 gewesen.
Aber im Endeffekt eine Sammlung von den besten Plugins, aber damit du leichter starten kannst.
Und ansonsten musst du im Endeffekt im Internet suchen oder Exchanges durchwühlen oder Blogposts lesen oder hoffentlich doch Schmentation haben oder eigene Git Repos haben und pflegen.
Und die dann auch ewig verfügbar machen. Ich habe vor einiger Zeit mal welche gelöscht. Da waren die User nicht so happy.
Aber ja, so ist es heute im Endeffekt. Also es geht wirklich um diese Check Plugins und die sind die Quelle der Wahrheit in der Form.
Aber wir haben jetzt sehr viel über alte Sachen gesprochen und bei Narios gab es dann auch noch die.
Ja, es ist einfach alt und heutzutage verwendet man vielleicht kein Narios oder E-Singer 1 mehr.
Die CGI oder auch Classic UI, wie sie dann genannt wurde, das ist in C geschrieben.
Es hatte Meld, was zwar funktioniert hat damals, aber nicht mehr maintainbar ist.
Und die Datenbank auch ein sehr interessantes Thema.
Es skaliert sehr schlecht. Neue Versuche skalieren angeblich auch nicht so gut.
Aber schauen wir mal, wo die Reise sozusagen hingeht.
Und dadurch, dass wir jetzt mit Philipp jemanden in der Runde haben, der sich mit den Singers Warteffekten auskennt oder auch
oder ich würde sagen Anwendungserfahrung hat, also der jetzt kein Entwickler von dem ganzen Ding ist, sondern eben die Anwenderseite und Administrationsseite bedienen kann.
Magst du vielleicht ein bisschen einsteigen, was es ist, wo du siehst, wie du es verwendest?
Gar keinen Druck, ja. Ihr meint ja, man hat einen Singer 2 entwickelt.
Danke, dass du von Experten nochmal auf Anwendungserfahrung runter geregelt hast.
Aber gerne. Also ist ja das Tool, was ich wirklich hauptsächlich nutze oder nicht hauptsächlich, eigentlich nur,
was ich hauptsächlich anwende, was ich hauptsächlich implementiere. Und ja, so einfach als kleine Quick Facts hat es ja eben, glaube ich, auch schon gesagt.
Erstes Final Release 2014, Juni meine ich, habe ich mir da nochmal vorhin so ein bisschen reingelesen,
weil das sind einfach Sachen, die hatten wir sowieso nicht wirklich im Kopf.
Ich glaube 2012 habe ich damit angefangen, wo du ja auch dann dabei warst, Michael, mit der Entwicklung.
Und ja, sind halt viele neue Sachen reingekommen. Ist ja eine komplette Neuentwicklung gewesen.
Kein Fork mehr von Nagios oder Icinga 1 irgendwie aufgebohrt und weiterentwickelt, sondern wirklich komplett neu.
Viele neue Features dazugekommen, was glaube ich eins der größten und wichtigsten war, ist die Cluster Funktionalität oder Distributed Monitoring auch,
was dann da reingekommen ist mit Rollenteilungen, nenne ich es jetzt einfach mal, dass man in diesem Zonenkonzept,
das Icinga 2 dann nutzt, in eine Zone mehrere Master-Satelliten reinstellen kann, die sich die Arbeit dann teilen.
Das ist sicherlich für mich eines der größten Features, weshalb wir uns auch unter anderem dafür entschieden haben,
dann die ganze Kommunikation innerhalb dieses Clusters über eine eigene CA verschlüsselt.
Das ist auch, ich denke mal, wichtiger geworden im Laufe der Zeit, um da auch so ein bisschen, ich will nicht sagen,
Traffic zu sparen, aber zumindest den zu kanalisieren über einen Port und nicht hier SNMP, da über eine API,
über irgendeinen proprietären Port auf irgendwas anderes, sondern das gegebenenfalls dann über den einen, ich sag mal,
in Anführungszeichen Icinga Port zu kommunizieren und natürlich auch die ganze Cluster Kommunikation darüber laufen zu lassen.
Dann, was für uns damals hat jetzt nicht wirklich was mit, ein bisschen schon, aber nicht wirklich was mit Icinga 2 an sich zu tun,
aber der Icinga Director, die Module, die es für das Webinterface gibt, für uns, ich würde sagen, fast der ausschlaggebende Punkt gewesen,
uns für Icinga 2 damals zu entscheiden als Monitoring System, weil man einfach ein wirklich in die Weboberfläche schön integriertes
Konfigurationsinterface hat, was zudem noch schöne Möglichkeiten zu so einer Teilautomatisierung, Pseudoautomatisierung,
wie man es auch immer dann nennen will, mitbringt mit Importieren aus verschiedenen Quellen, sei es aus einer CMDB, sei es aus der alten Datenbank von einem Icinga 1 System
oder, ja, ich glaube hinterher ist auch sogar noch irgendwas mit Integration von INI und Excel Files und so was dazugekommen,
wo man sich dann seinen Monitoring oder seine ganzen Hostobjekte wieder rausziehen kann, was es halt fürs initiale Aufsetzen wirklich dann sehr angenehm gemacht hat.
Und, ja, das, was du gerade schon angesprochen hast, mit der Datenbank benutzt Icinga 2 ja, soweit ich das korrekt im Kopf habe, auch eins zu eins weiter,
was Icinga 1 verwendet hat, korrigiere ich gerne, wenn ich da falsch liege, aber es ist zumindest bis vor zwei Monaten noch der Standard gewesen.
Zu dem neuen Icinga DB, was die Icinga-Kollegen da jetzt rausgebracht haben, kann ich gar nicht viel sagen, außer dass deren Aussage halt ist,
dass es dadurch deutlich performanter werden soll in Zukunft, basiert halt im Unterbau auch wieder auf einer MySQL DB,
hat aber als Zwischenschritt, sage ich mal, noch eine Redis, die in Memory läuft, um halt einfach die ganzen Datenbankabfragen,
die an die IDO-Datenbank, so heißt das MySQL Schema oder die MySQL-Datenbank unten drunter, halt einfach zu reduzieren
und auch redundante und wiederkehrende Abfragen dann einfach sich zu sparen.
Zumindest ist das so meine Punkte, die ich mir dazu abgespeichert habe.
Ja, ansonsten, was gibt es da noch zu Icinga 2, es ist kompatibel zu den ganzen bekannten Nagios-Plugins, Monitoring-Plugins,
verwendet im Hintergrund die gleiche Plugin-API mit 01.2.3 als Return Codes mit der Formatierung von Output- und Performance-Daten,
sodass da keine Umstellung seitens der Anwender passieren muss.
Alles, was in Nagios oder Icinga 1 verwendet wurde, kann dann auch in Icinga 2 verwendet werden.
Ja, mehr plumpst mir gerade nicht aus dem Kopf raus, deswegen, wenn der Michael da noch mehr anzumerken hat,
gerne vielleicht fällt mir da noch mehr ein.
Ich würde hinzufügen, dass Icinga Data Out heißt, oder Data Out, habe ich viele Jahre auch nicht gewusst bei der NDO.
Und die andere Frage, die mir jetzt gerade im Kopf herumgeistert ist, wie löst ihr quasi das Metriken oder Visualisierung von Graphen?
Ist das ein Thema in eurer Umgebung?
Definitiv, das auf jeden Fall. Wir benutzen InfluxDB als Back-up für die Performance-Daten.
Also Icinga 2 kann die Performance-Daten, die die Plugins im Prinzip an den Core liefern,
schön über ein integriertes Feature in Influx-Datenbank schreiben.
Und benutzen dann in dem SVA-internen Projekt einen Grafana zum Visualisieren der Daten, was dann die Influx-DB anzapft.
Und in den kleineren Kundenumgebungen, die ich so als Single-Master-Lösung mit allem auf einem Server aufgesetzt habe,
ist es in der Regel auf den Graphite hinausgelaufen.
Und früher noch, es gibt mit Sicherheit noch so ein, zwei Systeme bei Kunden, wo ein PMP von Agios auch noch läuft.
Aber Visualisierung der Performance-Daten, definitiv ein Thema gerade für das Betrachten von Verläufen.
Wie lange hat es gedauert, meine Festplätze zu füllen? Wie lange war die CPU auf dem Critical-Wert? Solche Sachen.
Also definitiv wichtig. Und es ist schön bunt.
Ich wollte es gerade sagen. Das ist eigentlich so der Selling-Point. Ich kann mich daran erinnern,
ich habe auch mal einen Pock gemacht für meinen ersten Arbeitgeber, wo es dann in Richtung Icinga 2 ging.
Das war für mich echt ein sehr, sehr spannendes Release.
Du hast ja schon die ganzen Vorzüge genannt, aber diese neue Domainspecific-Language, glaube ich, so kann man es einkategorisieren,
dass man es eher programmatisch definiert. Das fand ich, das war ein absoluter Game-Changer,
dass ich mich nicht mehr mit irgendwelchen Security-Issue-behafteten NSCA-NRPE-Tools mit rumärgern musste.
Das fand ich auch spannend. Und die neue Web-UI, die ja thembar war.
Ich kann mich daran erinnern, es gab relativ schnell, als Icinga Web 2 draußen war, so lustige Themes,
wo irgendwie alles mit pinken Einhörnern da war oder das LSD-Theme auf GitHub. Das war ja auch wirklich omnipräsent.
Das war super.
Da muss man den Carsten Köpke lobend erwähnen.
Definitiv.
Der uns viele schöne Stunden bereitet hat oder auch Easter Eggs.
Auf jeden Fall. Ich bin da eigentlich zufällig drauf gestoßen, weil ich habe gesehen, es gibt das Icinga Web 2-Theme.
Dann habe ich gesehen, okay, da gibt es einen Ordner, da liegen die CSS drin.
Dann habe ich halt mal gesucht, naja, wie kann ich das denn themen?
Und dann war halt der erste Hit dieses Unicorn-Theme und der zweite das LSD-Theme.
Das habe ich dann genommen und habe es halt auf das Corporate-Design irgendwie angepasst.
Ich habe natürlich auch gerne bei Kundendemos die Unicorn-Variante gezeigt und die hat doch breiten Anklang gefunden.
Toppen konnte man das natürlich, wenn man sich einfach einen Grafana nebendran stellt.
Oder es gab ja auch andere Plugins, die die Performance-Daten auch direkt dem Icinga angezeigt haben.
Wir haben ja immer dann so schön gesagt, das ist die Manager oder die Management-Oberfläche.
Die haben wir dann auch auf so einen großen Fernseher geworfen mit Icinga Dashing und so.
Das hat schon gut ausgesehen. Das war auch echt ein Game-Changer für mich damals.
Ich habe bei Kunden gerne, wenn ich das vorgestellt habe und das nur IT-Admins waren, gerne das Always Green-Theme vorgestellt,
wo alles schön grün war. Critical ist grün, Warning ist grün, Unknown ist grün, alles ist grün.
Ich habe echt eine Wissenslücke. Ich habe das gar nicht mitbekommen.
Ich wusste nicht, dass Icinga das MySpace der Monitoring-Tools war.
Schön mit Schnee und Alm. Schöner Vergleich. Icinga2.de.v.u.
Ein Winter-Theme gab es glaube ich eine Zeit lang. Aber ich habe mich jetzt auch erinnert an die...
Es ist immer noch drin, glaube ich.
Es gab zu Web2-Modulentwicklung nie wirklich gute Doku. Ich glaube, das hat sich über die Jahre gebessert.
Aber am Anfang haben die Leute reverse-ingeniert, was an Source Code herumgeflogen ist.
Und da Carsten hat, glaube ich, damals... Also er konnte kein PHP und kein JavaScript, soweit ich weiß.
Und dann hat irgendjemand gesagt, das schaffst du nie, dass du in einer Woche ein Globe-Modul baust,
wo du quasi Google Earth Globos hast, wo du dann die Checks irgendwie draufsiehst mit so erhöhten Farben oder so irgendwie.
Und der hat das dann halt hingebaut und ich habe das ja zufälligerweise irgendwo entdeckt.
Und ich habe so "Hui".
Ich habe vor vielen Jahren mal auf eine IcingaCamp an Talk gemacht, eben mit Community-Addons,
wo es dann auch das Maps-Modul gab vom Nikolaj Buchwitz.
Und du merkst dann einfach auch Community-Zuspruch oder Leute, die sich halt dafür interessieren.
Ich bin mir aber nicht sicher, ob es irgendwo noch eine Seite gibt, wo die ganzen Community-Addons gelistet sind.
Aber im Endeffekt, wenn du noch Green Theme suchst und die Singer-Web 2 solltest du sicher fündig werden.
Auf jeden Fall. Das ist super. Also da habe ich auch drüber gelacht.
Das erinnert mich auch an die Volkswagen CI. Kennt ihr die?
Das ist so ein Tool, das packst du in deine Pipeline rein.
Und die erkennt, wenn der Unit-Test in der Pipeline läuft, dann ist der Test halt immer grün, auch wenn er eigentlich rot ist.
Der Elchtest, ja.
Ja, das geht in die gleiche Richtung. Also da gab es echt viel.
Um auf die Frage zurückzukommen, ich glaube, diese Community-Newsletter, die gibt es noch.
Also da bin ich auch über das Theme vom Nikolaj Buchwitz damals gestolpert.
"Grüße gehen raus", das war auch super, dieses Nugwiz-Plugin, was er geschrieben hat.
Das habe ich auch gerne eingesetzt. Tolle Sache.
Vielleicht noch einen Satz kurz zum Isinka Director. Den fand ich auch ziemlich nützlich.
Also klar, da konnte auch CSV, man konnte damit auch LWAP machen.
Und das habe ich mal genutzt, um eben aus einem Windows Active Directory abzugreifen, welche Server in welchen UUs stehen.
Und habe die automatisch dann monitoren lassen.
Und das war natürlich auch echt so ein Moment, wo man gemerkt hat, okay, ich muss jetzt nicht doppelt Arbeit machen.
Ich greife das einfach ab. Das ist eine feine Sache.
Also das ist auch ein Plugin, das ich sehr nützlich fand damals.
Ist gerade bei kleineren und Mittelstandskunden genau das, was es mir dann deutlich leichter gemacht hat, so ein Monitoring-System einzurichten,
weil ich nicht irgendwie 30 bis 80 Server irgendwie von Hand ins System reinhaken muss,
sondern mir die schön aus dem Active Directory ziehen kann, über den Director noch ein paar Felder füllen mit,
also nicht Betriebssystemversionen und Hostnamen auflösen zu IP-Adresse und solchen Sachen.
Hat das schön vereinfacht, definitiv. Gefällt mir auch immer noch gut.
Fällt so gegenüber der Icinga DSL, also der Config-Sprache, ich sage mal teils logischerweise.
Andererseits auch ein bisschen schade im Funktionsumfang hinten ein bisschen runter an der Director.
Da würde ich mir teilweise noch ein bisschen mehr Funktionalität wünschen.
Vielleicht kommt es noch, keine Ahnung.
Aber so die Kombination aus der Icinga DSL und dem Icinga Director, da kann man schon sehr gute und sehr gut automatisierte Systeme
sich mit aufsetzen, dass man da, wenn eine neue Infrastruktur hochgezogen wird, beispielsweise nicht mehr viel klicken muss.
Absolut. Hat denn einer von euch, um mal das Tool zu wechseln, mal mit Tabx gearbeitet?
Um ehrlich zu sein, nicht.
Ich habe es 2005 im Studentenheim von Ruta gesehen, oder für Netzwerk-Monitoring,
und habe es immer so ein bisschen im Hinterkopf gehabt. Also ich habe es jetzt nicht wirklich aktiv in Verwendung kennen,
aber natürlich die Diskussion oder die Idee, so quasi Tools handhoch, dass Tabx durchaus sehr verbreitet ist im deutschsprachigen Raum auch.
Wo es, glaube ich, sehr, wo es extrem stark ist, ist Japan oder Asien.
Und was mir ins Auge gestochen ist letztens, weil die 6.0 Version rauskam, oder 6.2 mittlerweile schon,
dass sich die auch zum Beispiel Gedanken machen, wie kann ich Tübernettes überwachen,
oder wie kann ich so etwas wie Vis4 Center einfach nativ integrieren und andere Bereiche.
Sie haben auch, und das Konzept von Tabx ist, ich muss jetzt überlegen, in welcher Sprache das geschrieben ist.
Das ist PHP, das ist Perl. Auf jeden Fall braucht es eine Datenbank, wo dann auch die Performance-Daten da drinnen gespeichert werden.
Haben aber sehr viel auch investiert. Die lange Architektur, die sie auch im Buckel haben, seit 2001,
und die erste stabile Version 2004, haben sie das Ding ja auch erneuert. Es gab mal einen, oder es gibt es immer noch einen Sebex Agent quasi,
damit du auf deinem Linux, auf deinem Windows, auf dem Mac quasi einen Datensammler installieren kannst und unter Umständen keine Plugins brauchst.
Und den haben sie in Go neu geschrieben vor einiger Zeit, um das Ganze skalierbarer zu machen, wachbarer zu machen.
Man kennt die Crux mit C und C++, man muss unterschiedlich programmieren auf den Plattformen. Macht übrigens keinen Spaß.
Für sie getestet bei Singa 2 damals. Und im Endeffekt bei Sebex, ich muss gestehen, ich weiß nicht, wie es mit Distributed Monitoring genau funktioniert,
aber es gab ähnliche Konzepte mit einem Sebex Proxy, der dann sozusagen ein Satellit in der Mitte ist, um zwischen DMZs hin und her wandern zu können mit dem Agenten.
Unterstützt das Prinzip der aktiven und passiven Checks. Und hat auch die Idee von Metriken und Graphen einfach nativ mit drinnen.
Also das, was du in vielen Interfaces bei Singa und Nagas einfach noch dazu bauen musst mit Addons, ist halt bei Sebex mit Out of the Box schon mit dabei.
Und das hat mir, glaube ich, auch damals schon einfach angesprochen, weil du was siehst im Web-Interface, ohne dass du, ich sag mal, Excel-Tabellen durchscrollen musst, um rauszufinden, warum das Ding rot ist.
Sehr gut. Also steht bei mir auch schon lange auf der Liste. Ich wollte mir das mal anschauen, aber bin bisher noch nicht dazu gekommen.
Bin da irgendwie immer noch im Isingaeinlichen Toolset drin, aber vielleicht sollte ich mir das mal anschauen.
Gut, natürlich gibt es noch ein weiteres Tool, das auch ziemlich on vogue ist. Gerd, vielleicht willst du mal ein bisschen was zu Checkimk sagen, denn damit kennst du dich ja ganz gut aus.
Oh Gott, ich werde nicht mehr aufhören zu reden. Mir tut es jetzt schon leid für alle, die diesen Podcast angemacht haben. Ich dachte, heute höre ich mir mal richtig schön entspannt was an, wie sie über PRTG und Scomm reden.
Und jetzt erwähnen wir das gar nicht. Es ist...
Wir sind ja im Focus on Linux Podcast, da ist ja Scomm schon mal raus.
Ja, stimmt. PRTG glaube ich auch. Aber es gibt ja wirklich Monitoring Tools für die Sand am Meer. Man muss dazu sagen, unser Auswahl ist schon hart begrenzt eigentlich, aber man kann halt nur über das reden, womit man sich wirklich gut auskennt, sonst hat es auch nicht so viel Wert.
Ja, Checkimk. Ich bin immer überrascht. Ich habe immer im Kopf, die sind so 10 Jahre alt, aber ich glaube es sind mittlerweile 14 Jahre. Ich sollte das mal im Kopf updaten.
Ich glaube die Grundidee, die der Matthias Kettner, dafür ja das MK, damals hatte, war ja, dass er gesagt hat, es ist ja irgendwie, ich glaube, weiß gar nicht, ob Security die Hauptmotivation war oder Funktionalität, aber es ist ja irgendwie Unsinn, dass immer das Monitoring System anfragen muss,
er sagt mir mal irgendwie, wie voll die Festplatte ist und wie voll die Festplatte ist und gibt mir mal immer ganz konkrete Infos und stattdessen halt seinen einen Linux Agent geschrieben hat, der einfach einen Haufen Rohdaten zurückliefert halt.
Und das ist die Liste aller Prozesse, das ist die Liste aller Festplatten und daraus hatte er dann ja oben nages herum eben diesen Rapper mit Checkimk gebaut, der dann gesagt hat, okay, anhand dieses Monitoring Outputs von dem Agent, den ich auf einmal bekomme, erstelle ich eine Liste an Services, die ich jetzt monitoren kann, ohne dass der Admin sich da vorher groß Gedanken drüber machen muss und das ist ja dann mit der Zeit immer weiter gewachsen mit halt mehr Agents, zusätzliche Plugins, die dann eben auch erkennen, da laufen auch Datenbanken und
da gibt es noch eine Veeam Instanz, die ich mit abfragen kann und die gleiche oder vielleicht nicht ganz gleiche Logik hat Checkimk ja dann noch mit in die in die SNMP Welt gebracht, die ja doch immer noch sehr groß ist, halt einfach zu sagen, naja, es gibt ja zum Glück im SNMP Standard jetzt nicht viel an, dass sich alle halten, aber doch einiges und zumindest die meisten Geräte lassen sich halt auch über ihre System Description oder die System Description OID identifizieren und dann muss ich ja nicht als Admin wissen, was ich tue, sondern dann ist doch schön, wenn das Tool weiß,
wenn ich da ein Cisco Gerät habe, dann frage ich halt Cisco OIDs ab oder ich gucke einfach immer nach, ob das Gerät zufällig Netzwerk, Ports hat und fange halt an, wenn ich welche finde, die zu monitorn.
Das ist halt, ich glaube, man könnte sicher noch weiter automatisieren mit mehr Scans und Port Scans und es schießt mich tot, aber dass man prinzipiell in einem Checkimk nur jetzt sagt, hier ist ein IP und versuch mal das anzusprechen wie ein Betriebssystem oder versuchst mal auf SNMP anzusprechen und guck mal, was rauskommt.
Das macht einem das Leben schon schon sehr viel leichter, sodass man sich echt viel Zeit spart.
Und ja, es ist ja doch über die Community, aber natürlich auch klar den Hersteller, der dahinter steht, über die letzten Jahre mehr und mehr Plugins dazugekommen, sodass es einfach immer seltener wird, dass man als Admin gleichzeitig noch Entwickler sein muss und sich eigene Plugins entwickelt, weil wir sind jetzt bei über 2000 Monitoring Plugins.
Bisschen eine andere Architektur natürlich als es Nagios und Asynga machen, aber man nennt sie trotzdem Monitoring Plugins, die so schon fertig mitkommen und dann halt in der Community auch nochmal ein paar hundert plus natürlich.
Und das ist immer ein schönes Argument, wenn man irgendwie über Migration nachdenkt.
Wenn der Asynga Plugin kompatibel ist, kann ich ja eins zu eins im CheckMk auch einsetzen. Das heißt, mir geht eigentlich nie irgendwas verloren und ich glaube spätestens da hat man dann die meisten Admin, die sagen, ich muss mir keine Gedanken drum machen, weil ich gucke erstmal, was ich alles von out of the box vom CheckMk kriege und wenn ich irgendwas ganz spezielles habe für irgendein komisches Gerät, wo man hier ein Admin eben ein Perl-Script geschrieben hat, was sich keiner traut anzufassen, dann muss ich nur gucken, ob das Perl-Script wenigstens mit einem halbwegs aktuellen Perl auf meinem neuen CheckMk-Server noch funktioniert und dann kann ich eigentlich weiter monitoren.
Also die Abwärtskompatibilität ist da wirklich schön gegeben und ich glaube, ich musste vor kurzem auch dran denken, dass das wirklich jetzt im Podcast scheint es einem so plausibel, wenn man so zurückgeht, ja, was damals ganz toll war, dass eine grafische Oberfläche dazugekommen ist, das war ja beim CheckMk damals auch dann irgendwie, gab es auch mal einen Punkt, wo das cool war zu sagen, ey man muss gar nicht die Config-Dateien per Hand anpassen, sondern man kann das über die Web-Oberfläche machen.
Und das ist natürlich auch ein Punkt, das ich auch in der Web-Applikation selbst konfrontiert habe, weil ich mir das auch schon mal vorhin auch schon mal gesagt habe, dass man ja auch mal eine Web-Applikation in der Web-Applikation selbst konfrontiert hat, die man dann auch mal in der Web-Applikation selbst konfrontieren kann.
Und das ist auch irgendwie schade, ist auf der einen Seite, aber es ist auch vollkommen plausibel, weil man ja natürlich doch mittlerweile im Jahr 2021 oder 2022 ja mittlerweile ist und dann ist es auch okay, Sachen als Standard mal anzunehmen, dass man eben eine Web-Applikation auch in ihrer Web-Applikation selbst konfigurieren kann. Man muss nicht, aber man kann.
Ja von daher.
Das ist ja schön. Ich wusste nicht, was VATU heißt.
Ich löse heute alle Akronyme auf.
Genau. Ja und ich glaube dadurch, dass es sich so leicht, so schön erweitern lässt durch eigene Plugins, aber eben komplett auf diese diesen riesigen Fundos aus Nagios und Singer Plugins zurückgreifen kann, findet man eben echt selten noch Sachen, die nicht schon out of the box vorhanden sind.
Und wenn, dann ist man oft nicht der erste, der es findet. Also irgendwo findet man zumindest schon eine Spur, wo jemand angefangen hat.
Das finde ich schon immer noch sehr schön.
Jetzt müssen wir natürlich aber glaube ich fairerweise dazu sagen, Jack MK ist jetzt hier das erste Tool, was raussticht, was nicht komplett Open Source ist.
Während ja Singer, Nagios, Nagios XI nicht, aber das haben wir auch nicht wirklich besprochen und sehr wenigstens ist ja alles frei.
Im Jack MK ist da ein bisschen eine Trennung. Die haben ihre Raw Edition, wo noch wirklich ein Nagios Core darunter hängt.
Und dann ist aber wenigstens so alle Check Plugins, zumindest Stand heute, ich glaube es wird sich ein bisschen ändern, wenn ich es richtig im Kopf habe, sind da.
Das heißt vor allem zum Testen, bis ich mir sicher bin, ja Jack MK ist das, was ich dauerhaft bei mir in der Umgebung nutzen will, kann ich das mit den kostenlosen und auch komplett freien Jack MK Versionen machen.
Da bin ich auch nicht direkt in einem wegendure Login drin.
Aber wenn ich dann sage, ok ich brauche jetzt irgendwie so fancy Manager Shit wie PDF Reports oder natürlich auch ein paar hilfreichere Sachen wie automatische Agenten Updates und sowas,
dann muss ich mich halt mit einem Jack MK Enterprise auseinandersetzen und ein bisschen was dafür zahlen.
Wobei das ja ist es selten ausschlaggebend für die Entscheidung, sage ich mal, weil es doch verhältnismäßig günstig noch ist.
Und ja, ich finde es interessant. Ich glaube, als ich mit Jack MK angefangen habe, da war das Unternehmen auch so knappe zehn Mann groß.
Und jetzt mittlerweile sind die glaube ich über 60 und haben jetzt vor kurzem irgendwie erst das Büro in den USA aufgemacht.
Also da tut sich ganz gut was. Aber interessanterweise auch muss ich sagen, es läuft gut, dass Matthias Kettner ist noch quasi da und hat immer noch einen starken Einfluss.
Aber er kontrolliert halt nicht mehr alles. Und man merkt es auch hin und wieder, dass es einfach Sachen gibt, wo es vor fünf, sechs Jahren von Matthias Kettner Aussagen auf einer Konferenz gab,
warum er etwas nicht mag. Und jetzt gibt es es halt trotzdem, weil einfach die Nachfrage da ist und die Leute Bock drauf haben und es einfach genug Entwickler in der Tribe 29,
wie es ja mittlerweile heißt das Unternehmen, gibt es einfach jetzt mittlerweile genug Entwickler, die sagen, ne, das ist sinnvoll, wir machen das jetzt.
Und sein Veto gilt halt nicht mehr gegen alles, sondern er muss halt glaube ich überzeugen.
Das ist jetzt so mein Blick von außen und ich habe aber das Gefühl, es geht immer noch in eine gute Richtung.
Und auch die Community ist glaube ich immer noch sehr lebendig, also was da im Forum unterwegs ist,
also wie die Anzahl der Leute und auch wie schnell einem da oft geholfen wird, das ist schon immer noch eine schöne Community.
Und sie verwenden ja glaube ich auch Discourse als Forum Plattform, soweit ich gesehen habe vor einigen Jahren.
Was mir noch im Kopf herum geistert, bei der Enterprise Edition damals war das ein eigener Micro-Core.
Genau, der Jack-in-the-Car Micro-Core, da tauschen sie dann Nagios quasi komplett aus.
Also mit Nagios hat man dann nichts mehr zu tun, wenn man im Enterprise Umfeld unterwegs ist.
Kann man, aber will natürlich niemand.
Es hat viele Probleme gelöst, was halt in die Breiteskalieren betroffen hat.
Ich habe den Source Code natürlich nie gesehen, weil es Close Source ist, aber ich glaube es war in C++ geschrieben,
war kompatibel mit dem Live-Status-Modul, wo du eben auch schnell Daten aus dem Core rausbekommst,
was eigentlich, ich glaube einer der Faktoren war, warum Jack-in-the-Car auch so bekannt geworden ist, wegen MK Live-Status.
Das Modul, dass du aus einem Nagios oder Isingas 1 Daten rausziehen kannst, ohne dass du irgendwelche Files oder Dateien passen musstest oder eine langsame Datenbank.
Und Nagviz war eines der ersten Module für Maps und Visualisierung, was halt Live-Status verwendet hat.
Und ich glaube so dieses Ökosystem hat sich so ein bisschen gegenseitig beeinflusst und deiner Folge ist nicht ausgeblieben.
Live-Status ist ja noch einen Ticken älter, glaube ich sogar, als Jack-in-the-Car.
Also das hat der Matthias Kettner vorher noch geschrieben und von daher ist es ja plausibel.
Ich glaube nicht. - Echt? Ich dachte schon, aber...
Also ich erinnere mich an die OSMC 2009, wo ich es erst einmal in Nürnberg hatte.
Und der Matthias hat damals draußen auf der Couch mehr oder weniger Leuten Live-Status gezeigt, also einen Prototyp.
Es ist noch nicht MK Live-Status. Und ich habe mir so gedacht, das wäre super, wenn das in Isingas nativ drinnen wäre.
Dann ist es aber ein bisschen im Sand verlaufen und auf einmal große Ankündigung MK Live-Status, die Datenbank ist tot oder irgendwie so damals.
Ich war natürlich nicht so begeistert davon, aber eigenes Add-on war auf den Nagios headerkompiliert,
was die Entwicklung bei Isingas unter Umständen gehemmt hat.
Und ich habe da öfters wieder Sachen kaputt gemacht und revertiert.
Aber so ist es halt, wenn man keine Testsysteme hat.
Aber es war halt vor zwölf Jahren, also lange Zeit.
Ja und ich habe dann auch mitbekommen, dass der Lars Michelsen, der eben Nuggets lange Zeit entwickelt hat,
auch so Matthias Kettner GmbH bzw. Tribe29 gewechselt ist und dort glaube ich das Entwicklerteam mittlerweile leitet oder so.
Ja, gewechselt ist es. Das klingt so, als wenn es da schon Unternehmen gab.
Ich glaube, ich meine sogar, Matthias Kettner hat das Unternehmen gegründet, um dann Lars Michelsen einzustellen.
Also es ist glaube ich Mitarbeiter Nummer eins gewesen. Und er entwickelt Narcviz immer noch.
Aber man sieht, es ist ein Hobbyprojekt. Das ist so, wenn Lars Michelsen nach einer ganzen Woche Check-MK glaube ich noch nicht genug hat,
dann macht er Samstag abends irgendwie noch Commits im Narcviz-Gitab.
Aber ja, ich glaube, die Narcviz-Entwicklung ist doch ein bisschen eingefroren dadurch.
Also es tut immer noch. Es gibt noch Security-Patches und sowas. Aber funktionell hat sich da halt nicht mehr viel getan.
Vor allem optisch. Ich glaube, das Funktionellen müsste es gar nicht so viel tun.
Vielleicht ein bisschen mehr Automatisierung mit unterstützen.
Aber optisch ist es halt ein bisschen in die Jahre gekommen. Aber es existiert glaube ich.
Es kann man super tun.
2003 glaube ich war es ursprünglich auch aus der, von Michael Lüppen damals, der das Monitoring-Portal initiiert hat.
Und der Jörg Linge war da glaube ich auch dabei. Irgendwie ganz, ganz am Anfang.
Also 2003, 2005 herum kann ich mich entsinnen. Kann man wahrscheinlich auch anhand von der Git-Historie auch lesen.
Was mir bei Jackamk auch gefällt, ich meine, ich habe es jetzt nicht wirklich im Einsatz,
aber was man so liest in den Release-Blogposts, dass sie sich auch umschauen, wie sie Metriken zum Beispiel reinbekommen.
Also dass zum Beispiel eine Grafana-Integration einfach mit dabei ist.
Dass sie sich anschauen, wie sie Kubernetes überwachen können, ohne jetzt das Rad neu zu erfinden.
Sondern sagen, ich zappfe ein Promises zum Beispiel an oder mache die Integration in dieser Form.
Ohne jetzt mich großartig verbiegen zu müssen.
Das macht das Ganze also aus meiner Sichtweise nochmals mehr interessanter, weil man einfach am Zahn der Zeit mitgeht
und sich auch Gedanken macht, wie kann ich jetzt, und das wird uns nicht ausbleiben in den nächsten Jahren,
wie kann ich auch Kubernetes überwachen? Einfach so.
Und das ist etwas, und da springe ich jetzt kurz zu "Ezinger 2" zurück.
Aus der Entwicklerbrille gesehen haben wir uns auch über das Thema Gedanken gemacht, aber es war einfach nicht der Demand da.
Oder es war einfach kein Konsens zu finden, zu sagen, wir bauen das jetzt im Director ein Containerobjekt ein
und in "Ezinger 2" im Core 1 ein und im Web muss es auch eingebaut werden und das Backend braucht es auch.
Also da waren viele unterschiedliche Teams, die unter Umständen auch gegeneinander gearbeitet haben.
Deswegen funktionieren auch Dinge im Director nicht so, wie sie in "Ezinger 2" design sind und umgekehrt.
Aber das ist halt einfach im Laufe der Zeit und schön wäre es natürlich, wenn man als Kubernetes mit "Ezinger 2"
auch überwachen könnte. Muss ich übergestehen, weiß ich nicht, ob es da ein Roadmap oder Agenda zu dem Thema gibt.
Macht aber natürlich sozusagen jetzt auch SubEx oder CheckMK interessanter, wenn man sich mit dem Thema auseinandersetzen möchte in Zukunft.
Mit der Zeit gehen ist ein gutes Stichwort und das meine ich jetzt im doppelten Sinne.
Also zum einen habe ich gerade mit Schrecken festgestellt, dass wir hier schon über eineinhalb Stunden auf der Uhr haben.
Und wenn ich hier so auf unsere eigene Roadmap schaue, welche Themen wir noch ansprechen wollen, dann haben wir noch ein bisschen was vor uns.
Und du hast auch gerade ein Tool genannt, was für mich sinnbildlich immer so auch für das Next-Gen-Monitoring steht.
Und zwar Grafana, vor allen Dingen in Kombination mit einer InfluxDB oder mit einer Prometheus.
Das ist ja auch schon mal genannt worden und das ist auch so ein bisschen immer die große Frage, wenn heute jemand wirklich beginnt,
mit dem Thema Monitoring neu einzusteigen. Man hat so einen kleinen Kunden oder man will im Home Lab einfach mal beginnen,
Dinge zu visibilisieren, die man da irgendwie betreibt. Dann muss ich doch feststellen, dass da selten die Antwort ist, ja, ich beginne mit einem Nagios.
Also das sehe ich zum Beispiel echt selten und was ich aber viel häufiger sehe und das ergibt auch Sinn, wenn wir über so Dinge wie Kubernetes reden,
hat man halt eben doch häufiger mal so Zeitreihen, Datenbanken in Kombination mit so einem Grafana Dashboard.
Wie steht ihr dazu? Ist das für euch Next-Gen-Monitoring oder seht ihr da durchaus auch noch andere Tools wie so ein Check-in-Car oder wie dem Sensu?
Das ist ja auch ein Tool, was in dem Kontext mal gerne genannt wird.
Ich würde einfach ganz kurz was zu sagen, weil es da bei mir sehr dünn wird mit Output, den ich dazu geben kann.
Also für mich ist das definitiv Next-Gen, weil einfach das das nächste ist, womit man sich wahrscheinlich irgendwann mal beschäftigen muss,
gerade wenn es in diese Container-Kubernetes-Richtung geht. Aber es ist halt bisher bei mir, bei den Kunden,
zumindest diesen kleineren Kunden, die ich da mit Monitoring-Systemen versorgt habe, nie sinnvoll gewesen oder nie auch nur angesprochen worden.
Von daher gebe ich das Wort da aus meiner Sicht einfach nur, damit ich was gesagt habe, gerne an die anderen beiden weiter und lasse mich da mal ein bisschen aufschlauen.
Also ich finde Next-Gen ist immer ein ganz böses Passwort, aber gut, wir wissen ja, wie du es meinst.
Prinzipiell ja, man sieht, es ist so gefühlt 30-40% der Zeit, wenn die ChecknK Leute über ihre Roadmap reden, dann reden sie über Container-Monitoring und dann auch Cloud-Themen.
Man merkt auch, wenn Kunden selbst vor einer neuen Herausforderung stehen, dann ist es das.
Aber ich glaube, da wird ja immer wieder so ein bisschen umgewiselt. Deutschland ist da was Cloud angeht hinterher.
Aber ich merke das echt, wir haben unglaublich viele Kunden, die irgendwo fangen die mal an, sich dann in einer Abteilung mit Kubernetes zu beschäftigen,
meistens getrieben durch irgendeinen Software-Entwickler, der irgendwie dann sagt, er wird das jetzt nur noch als Container herausgeben, gar nicht, weil sie selbst so unbedingt überzeugt davon sind.
Deswegen ist es dann auch oft ein Thema, wo wir sagen, ja, das ist ein Baustein, den sie halt in ihr Monitoring mit reingeben.
Und ich bin da aktuell ganz froh, dass es so langsam ist, sodass ich den Eindruck habe, ja, die ChecknK Jungs kommen hinterher mit ihrem Kubernetes Monitoring.
Und da, wo sie es nicht können, kann man eben noch, wie es der Michael schon gesagt hat, noch ein Prometheus mit anbinden.
Ich sage, ich spreche jetzt einschaltdeutsch aus, das ist bestimmt auch richtig.
Und von daher, ja, ich denke, man wird sich damit beschäftigen müssen, aber ich stelle mir schon die Frage, ist es denn damit alleine getan?
Und ich glaube, bei manchen ja im Unternehmen, aber wenn man halt eine IT-Abteilung hat und die muss das alles unter einen Hut bringen,
dann werden die oft froh sein, wenn sie ein Tool haben, mit dem sie zumindest 90 Prozent ihrer Anforderungen oder vielleicht 95 abdecken können.
Und dann läuft vielleicht eher so, ja, das Prometheus läuft vielleicht mit, weil das bringt irgendeine Applikation eh von sich aus.
Ich glaube, der SUS Manager macht das, manche von KubaMatic macht das, also verschiedene Orchestrator schubsen das einfach mal mit rein.
Aber ob ich es dann fertig einrichte oder erst mal nur so, um Daten zu sammeln, um im Zweifelsfall nachzugucken und das Alerting hole ich mir doch noch woanders her,
so ist so mein Eindruck bisher auf SUS, dass man sich für die Anbindung dann wirklich ans Ticketsystem, an Anrufbereitschaften nimmt,
dann doch lieber das adaptierte Tool. Und das ist zum Glück für mich und meine Kollegen ist das auf Check-in-Car, weil man dann halt nicht das Rad gleich zweimal neu erfinden muss.
Also wenn ich was gelernt habe in meiner bisherigen Berufskarriere, dann ist es so "want to rule them all" gibt es halt in den seltensten Fällen.
Also ich habe am Anfang gedacht, das wäre im Bereich Multitasking möglich und habe auf Biegen und Brechen auch versucht, immer nur einen Tool einzusetzen.
Ich habe aber gemerkt, dass es da durchaus Ecken gibt, wo das halt nicht funktioniert.
Also wir hatten zum Beispiel auch beim ersten Job Nagios, beziehungsweise später E-Synchr 2 im Einsatz da auch dann mit einer Graphite hintendran, mit Performance-Daten und so weiter.
Aber es gab halt trotzdem Teams, die nochmal ihr eigenes Tool brauchten.
Also zum Beispiel die Netzwerk-Kolleginnen, die wir da hatten, die hatten dann halt einen PRTG noch im Einsatz, dann hatten wir die Windows-Applications-Server-Verantwortlichen, die hatten dann noch ja SCOM oder wie es heißt im Einsatz.
Und wie du schon richtig sagst, so dieses 90% von dem, was man braucht, das lief zentral schon im E-Synchr, aber für das sehr applikationsspezifische, da hat man durchaus noch ein eigenes Tool.
Also zum Beispiel ein Subadmin, der wird niemals all seine Metriken in einem E-Synchr irgendwie sehen oder in einem ChecknKa,
aber dafür gibt es den Sub-Solution-Manager, der genau dafür entwickelt wurde beispielsweise auch.
Also ich glaube, man muss sich von dem Gedanken lösen, einen Tool für alles zu haben.
Und gut, dass du auch vom Suse-Manager redest, also da sehe ich halt eben auch kleine Kunden, die mit dem Thema erst beginnen, die noch kein eigenes Monitoring haben.
Die nutzen halt das, was der Summa mitliefert. Und dann hast du automatisiert so ein schickes Grafana-Dashboard, wo du deine ganzen Metriken drin hast, welche Systeme, wie viele Patches ausstehen haben, wie da RAM und Disk sich verändern, also diese typischen Infrastruktursachen.
Aber so Sachen wie Alerting ist halt erst mal nicht eingerichtet, da musst du dich darum kümmern.
Und ja, also im Endeffekt, das ist, glaube ich, alles noch nicht so ganz definiert, dass es ein Tool für alles gibt. Oder wie siehst du das, Michael?
Es wäre natürlich schön, wenn es ein Tool für alles geben würde, aber dadurch, dass unsere Infrastruktur oder unsere Landschaften unterschiedlich sind, und da kommen wir wieder zum Thema Cloud Monitoring oder Infrastruktur Monitoring.
Was du nicht machen solltest, ist versuchen, jetzt ein Host Service Modell in ein Containermodell reinzubressen. Also versuchen, Methologien oder Workflows umzubiegen und sagen, das geht schon irgendwie.
Sondern das nehmen, was die breite Masse sozusagen an Erfahrungen schon gesammelt hat. Und wie wir schon richtig festgestellt haben, im deutschsprachigen Raum ist manches an Technologie immer ein bisschen hinterher. So fünf Jahre im Schnitt hin und wieder.
Was aber gar nicht so schlecht ist, wenn man jetzt auch wieder den Anspruch hat, gemeinsam zu lernen und zu sagen, naja, ich würde gerne Zeitreihen sehen oder bunte Grafen in Grafana.
Wie bekomme ich das? In meinem Kubernetes installiere ich ein Promises, roll dort einen Promises Operator aus oder wie auch immer und habe da die Möglichkeiten mit Service Discovery und verschiedensten anderen Mechanismen einfach schnell was zu sehen.
Kann damit arbeiten, bin aber sozusagen in meiner Umgebung da drinnen. Wenn ich jetzt ein Promises für Infrastruktur Monitoring verwenden möchte, muss ich mir Gedanken machen, wie kann ich Promises, sogenannte Promises Exporter verwenden, die dann zum Beispiel von einem Linux oder Windows System,
ähnlich wie der Check and Car Agent, die die Sachen einlesen, sammeln und verfügbar machen. Das heißt, der Promises Server macht ein sogenanntes Scraping von diesen HTTP Endpunkten und sammelt dann die Metriken entsprechend ein.
Das ist ein Konzept, mit dem man sich auch auseinandersetzen muss, aber der Vorteil von dem ganzen ist, meiner Meinung nach, ich habe Metriken, das heißt, ich habe nicht mehr statische Werte und irgendwelche Performance Daten, die sich nicht pasen lassen, sondern es ist tatsächlich ein Wert und auch Tags, um das entsprechend filtern zu können.
Und was mir gefällt, und das ist auch Trend, Richtung wie speichere ich Logs, wie speichere ich andere Eventtypen ab, du hast eine Query Language oder du hast eine SQL-artige Sprache, wo du Ausdrücke berechnen kannst, wo du auch Trendberechnung machen kannst, weil Performance Daten und Graphen sind ja schön, wenn sie bunt sind und du siehst, dass aktuell so vielleicht was nach oben geht.
Aber im Endeffekt, ja, also ich habe gerade, wir reden ja nur, ich habe gerade mit den Händen quasi den Pfeil nach oben gemacht.
Das ist etwas, was mit Prometheus und mit der eigenen TSTP und dann auch Thanos oder Cortex als Long Storage möglicher wird. Und meiner Meinung nach ist so Metric Monitoring eigentlich mittlerweile Standard, würde ich sagen, ich würde das nicht als Next-Gen bezeichnen, aber es ist sozusagen, wo man einfach mehr sieht und man kann sich das Leben leichter machen.
Ich kann diese Metriken oder diese Graphen auch Entwicklern zur Verfügung stellen, um eben frühzeitig Dinge zu erkennen, weil du mit einem Graph oder mit einem Alert-Strich oder einer Annotation, du siehst einfach mehr im Frontend als jetzt mit irgendeinem Wert, den du halt noch lesen musst im Falle des Falles, wenn du heute aufgeweckt wirst, wenn dir jemand eine SMS schickt oder irgendwas in der Form passiert.
Und Prometheus ist einer der Vertreter, InfluxDB ist schon angesprochen worden, auch eine Variante jetzt Metriken abzuspeichern.
Ich muss gestehen, ich habe die Version 2.0 noch nie ausprobiert, aber da wurde auch einiges an der Performance gedreht.
Bei InfluxDB ist es so, es gibt eine freie Version und es gibt eine Enterprise Version und ich glaube in der Enterprise Version ist mehr auf Distributed und Scaling Wert gelegt oder irgendwie so.
Prometheus ist ein CNSF Projekt, was Open Source ist, also eine Patsche lizenziert, kann jeder verwenden.
Grafana ist mittlerweile RGBLv3 lizenziert, wurde relizenziert vor einem Jahr oder so.
Ja, was gibt es dann sonst noch an Tools?
Senso hatten wir uns überlegt, Senso verfolgt Monitoring Pipelines, also du hast quasi Event Streams und auf Basis dieser Inputwerte oder Inputtypen definierst du dann Correlation, Grouping und andere Themen.
Das war immer sehr interessant und sehr innovativ, die letzten Jahre das zu verfolgen.
Die sind mittlerweile von Sumo Logic aufgekauft worden und arbeiten da jetzt quasi weiter an Senso, aber mehr als Enterprise Projekt, soweit ich es verstanden habe.
Ja, es gibt generell sehr viele Tools, die wir hier nicht thematisiert haben und auch nicht thematisieren können.
In den klassischen Infrastrukturmonitoring Tools, Open IT Cockpit fällt mir da spontan ein, OPN wurde angesprochen, da müssen wir vielleicht demnächst noch mal eine zweite Folge machen oder vielleicht verabreden wir uns für das Jahr nochmal und machen so ein bisschen Lessons Learned und reden über die anderen nochmal.
Wie so ein Azubi Projekt, wir haben uns das dann alle mal angeschaut und erkennen es nicht so richtig, aber wir reden jetzt trotzdem drüber.
Es gibt ja schon Tools, über die wir geredet haben, die wir auch genutzt haben, von daher haben wir hoffentlich für die Zuhörenden dann doch schon den einen oder anderen Mehrwert hier.
Nein, ich meinte dann in einem Jahr, wenn dann jeder muss dann was vorstellen.
Gute Idee, gute Idee.
Ich habe für die aktuelle IX einen Artikel über Logmanagement geschrieben, aber da geht der Fokus halt Logmanagement und wie sind die ersten fünf Minuten, um zum Erfolg zu kommen.
Und da habe ich dann auch die Möglichkeit gehabt, mir endlich einmal ein aktuelles Elastic Stack in der Version 8 zu installieren, mir mal anzuschauen, wie Splunk funktioniert, Datadog, Dynatrace, was es dann auch im Enterprise-Segment an Möglichkeiten gibt.
Jetzt natürlich nicht nur Logstuff arbeiten, sondern eben auch Metriken, Monitoring-Daten und andere Themen.
Und da geht die Bandbreite noch viel weiter, weil da kasten mit, es gibt sonst, was gibt es sonst noch? So Honeycomb und Logs.io und so weiter und so fort.
Also da haben wir auch viele Möglichkeiten und das ist unter Umständen dann auch interessant für, möchte ich das Ganze selber hosten, also mein Monitoring oder lasse ich es irgendjemanden in der Cloud machen und die kümmern sich um Retention,
also Langzeitaufbewahrung von wichtigen Daten oder mir sind eigentlich die Langzeitdaten völlig egal, ich möchte wissen, wenn ein Incident passiert ist, ein Tag reicht mir und ich muss mir keine Gedanken machen,
wie ich jetzt einen Elasticsearch skaliere und brauche dafür 48 Cores und ein Therapeutermann oder irgendwie so in der Form. Das sind auch Gedanken, die jetzt…
Das sind auch Kandidaten wie New Relic oder so, die da auch schon seit Jahren ziemlich als Sass Offering ziemlich stark unterwegs sind und auch extrem detailliert in Sachen reingucken lassen,
aber ich glaube, ich weiß noch, wer hat es mal irgendwo gesehen, wo man dann wirklich jeden MySQL Call runterverfolgen konnte für eine Applikation, solange man überall die Exporter drin hat und das Ganze lief auch komplett in der Cloud und dann war quasi egal, wie viel Daten man da sammelt,
also da gibt es schon schöne Sachen, wenn man bereit ist, auch etwas tiefer in die Tasche zu greifen, sage ich mal.
Ja und wenn dann auch sozusagen die… also wenn du jetzt ganz tief reinschauen möchtest und jeden MySQL Call oder Syscall tracen möchtest, wenn du den Ernspruch eben hast, wo du Applikationen baust wie vorhin angesprochen Netflix oder wo das einfach hochskalierbar sein muss, dann musst du auch tief reinschauen und dann nimmst du auch leicht einmal 10.000 Euro in die Hand,
zu sagen, das Tool kann das und wenn es nicht kann, dann rufe ich ihn support an, also zu sagen, wir basteln es oder wir bauen es rund um die Open Source Lösung.
Das heißt, es ist nicht, dass Open Source schlecht ist, aber es ist halt einfach die Entscheidungsfrage für Firmen, zu sagen, was bringt denn jetzt das Team jetzt voran oder wir bauen es halt in den nächsten drei Monaten.
Was mich ein bisschen zu dem Thema bringt, was wir noch aufgeschrieben haben, quasi Monitoring versus Observability oder und Observability.
Wie definiert sich Observability? Was ist die Draufsicht auf viele Eventtypen? Dinge erkennen, die man noch gar nicht kennt, also Probleme erkennen, die du oder die noch gar nicht bewusst sind, dass sie vorhanden sind.
Also ein Beispiel, was ich gerne verwende, ist du hast sehr hohe Cloud Kosten und die CPU und Memory Usage geht nach oben.
Das Ganze liegt daran, dass in deiner CI/CD Pipeline Jobs laufen, die aber länger brauchen, weil die DNS Latenz zu hoch ist.
Und so ein Problem findest du mit klassischen Monitoring normalerweise nicht raus, sondern du brauchst dann jeden an den unterschiedlichsten Punkten deine Messproben mehr oder weniger.
Und wenn du dann entsprechende Tools oder Möglichkeiten nimmst, das zu sammeln, hast du eine bessere Draufsicht.
Und am Anfang hat man von den drei Säulen von Observability gesprochen, aber das ist eigentlich nicht mehr relevant, wo es um Metriken, Logs und Traces geht.
Und da Trace ist im Wesentlichen ein, kann man sich ein bisschen vorstellen wie im Webbrowser, wenn man die Dev-Konsole aufmacht mit den entsprechenden Lade-des-Seite, Lade-Java-Script, brauche ewig zum JavaScript ausführen und so weiter und so fort.
Das Ganze appliziert auf zum Beispiel End-to-End Monitoring, wo man sagt, ich Trace jetzt den kleinen Request von HTTP zum Server, zum Backend, wieder retour und schaue eben, wo ich es optimieren kann.
Und dann geht es auch nicht nur darum, die einzelnen Sachen eben anzuschauen, also kein Grafana Frontend für Metriken und ein Jäger für Tracing und so weiter und so fort,
sondern man kann das Ganze zu kombinieren und zu sagen, es ist was kaputt gegangen, ich sehe es im Graf, was ist sozusagen die White Box, was passiert drinnen, die Traces und was ist sozusagen der Fehler, Logs und da umstehen.
Das sind so die markanten Punkte. Man kann noch viel tiefer reingehen und sagen, gut, was ist jetzt noch mehr Observability, wie verhält sich das?
Der Trend ist natürlich auch zu sehen, wenn du verteilte Umgebungen hast, Distributed Tracing kommt auch aus der Ecke.
Hast du in deinem Kubernetes Cluster links die Load Balancer mit HTTP laufen, rechts irgendwo Steadful, eine Datenbank und in der Mitte den API Server.
Wie sehe ich denn jetzt, dass es dem System gut geht oder nicht gut geht?
Da kommt auch die Idee davon her, dass es eben Open Source Projekte gab wie Open Tracing oder Open Census, was mittlerweile in Open Telemetries Spezifikation und Framework vereint worden ist,
was ein ziemliches Hype-Thema aktuell ist und jeder möchte es auch lernen.
Das heißt, ich bin jetzt gemein, in Deutschland in fünf Jahren dann? Nein.
Ich habe letztens mit Splunk den Observability Report gemeinsam in einem Webinar mir angeschaut.
Und es ist durchaus so, dass diejenigen, die z.B. Kubernetes jetzt schon verwenden, in die Richtung auch stoßen.
Observability und der Markt gibt es auch her.
Also die Jobangebote gehen auch in die Richtung DevOps Engineer, Observability, Kubernetes und dann hast du halt eine Auswahl von den Tools.
Und wenn dir das Tool halt nicht zusagt, dann bewirbst du halt zum Beispiel nicht.
Das heißt, die Firma, die du aussuchen kannst von dem, was du schon weißt.
Also für Karriereplanung, wenn man sagt, ich möchte mich in der Ecke einfach weiterentwickeln oder mal was Neues machen, wenn man sich selber Wissen aneignet.
Das ist sehr deutlich einfacher geworden über die Zeit.
Man hat auch Chancen, einen neuen Job anzufangen und sich das Gehalt einfach einmal zu verbessern im Markt.
Das ist auch etwas, was ein bisschen übers Ziel jetzt hinausschießt.
Aber das ist etwas, was ich ja mitbekommen habe, dass die Akzeptanz und die Anforderungen haben sich einfach geändert.
Das bedeutet für uns, wir müssen mehr lernen, Zeit investieren, versuchen nicht in einen Burnout hineinzufahren und sehr einfach zu sagen, desinteressiert mir, das möchte ich jetzt lernen.
Und wenn morgen jemand mit Kubernetes Monitorung um die Ecke kommt, ja, das ist schön, aber das werden wir auch noch lernen.
So in der Richtung.
Ich denke, das ist auch ein guter Punkt, was du gerade sagtest, so technischer Burnout.
Das ist ja auch immer so das große Problem.
Man hat einen spezifischen Use Case, eine Anforderung.
Man recherchiert, liest Fachartikel und sieht sich auf einmal einer horrenden Auswahl an potenziellen Lösungen gegenübergestellt.
Also gerade weil du auch hier über Log-Analyse und eben Observability gesprochen hast, werden wir auf jeden Fall auch deinen Artikel verlinken.
Es ist ja die Frage so, wo beginnt man, wenn man heutzutage mit dem Thema Monitoring nochmal neu beginnt?
Also so generell die Frage, welches Tool für welchen Use Case?
Und da würde mich mal interessieren, wie ihr zu dem Thema steht.
Was würdet ihr denn jemandem empfehlen, wenn heute jemand kommt und sagt, hier, ich will mit dem Thema beginnen?
Was würdet ihr der Person an die Hand geben wollen, so als Tipp?
Ich glaube, das kommt extrem darauf an, was man alles monitorn möchte.
Also für was ist mein Team alles zuständig oder für was bin ich zuständig?
Geht das eben runter bis in die klassische Infrastruktur oder sage ich, ich hole mir das aus der Cloud und meine Verantwortung fängt eben an beim Kubernetes oder vielleicht sogar noch drüber, wobei ich glaube, das ist schon sehr ungewöhnlich.
Und klar, wenn ich für die Applikation zuständig bin, dann ist wahrscheinlich Check-in-Car auf jeden Fall nicht das Richtige.
Also dann habe ich von den 2000 Plugins nichts, sondern dann brauche ich etwas, was mir flexibel eben da Telemetrien und solche Sachen rauszieht.
Aber ich glaube, da, wie wir vorhin schon gesagt haben, dieses "one to rule them all" gibt es halt nicht.
Und da muss man erstmal sich klar werden, was möchte ich monitorn und was ist aktuell mein größter Schmerz, den ich versuche, damit zu lösen?
Und dann kann man sich anfangen, umzuschauen.
Habe ich da gerade richtig rausgehört, dass du in den letzten anderthalb Minuten eigentlich "it depends" gesagt hast?
Natürlich.
So die typische Berater Antwort, ne? "It depends".
Ja, ist ja auch so. Und ich setze noch eine Berater Antwort drauf.
Also ich würde in den meisten Fällen, glaube ich, empfehlen, nicht einfach loszulegen ohne eine Schulung oder ohne Beratung, weil die Tools oft so extrem vielseitig sind,
dass man halt auch, wenn man ziemlich sicher die erste Umgebung, die man aufbaut, nach einem halben Jahr komplett abreißt und neu aufbaut,
wenn man sagt, ich habe so viel gelernt, wenn man die Zeit und die Energie dafür hat, super gerne, ich glaube, man lernt viel dabei.
Aber wenn man sagt, man muss das jetzt im Unternehmen aufbauen, dann lohnt es sich zumindest, selbst wenn man jetzt sagt, ich will es selber betreiben,
dann muss man sich trotzdem jemanden zum Aufbau dazuzuholen, um ein paar typische Fehler nicht zu machen, in die man sonst immer wieder reinlaufen kann.
Aber ja, "it depends" bin ich dabei.
Ich muss mich da aber auch ehrlich gesagt leider echt anschließen bei dem "it depends".
Und das hat Gerd ja gerade schon gesagt, Jackmk, iSingar sind halt klassische Infrastruktursysteme.
Wenn da jetzt jemand wirklich den Use-Case hat, zu gucken, wie performant ist meine Webseite,
wird ihm da nicht ausreichen, zu gucken, wie schnell das HTTP 200 von der über Port 443 irgendwie da reinkommt.
Von daher, ja, immer definitiv abhängig von dem, was der Anwender oder der Kunde sich da wünscht.
Anagios ist die falsche Antwort, das können wir schon sagen.
Ich würde sozusagen den Open-Source-Gedanken wählen in der Form, ich möchte es bei mir ausprobieren können,
also vielleicht auf einen Raspberry Pi oder im Home Lab unter Umständen, um es dann vielleicht auch in der Arbeit oder für einen Kunden ausrollen zu können.
Und ich schreibe das öfters mal auf Twitter in Replies, wenn es um die Auswahl von Open-Source-Projekten geht.
Aber dass es halt im Endeffekt eine aktive Community hat, und mit "aktiv" meine ich, dass jemand um die Issues kümmert, dass jemand umschaut, gibt es Pull-Requests.
Was ist die Roadmap? Gab es in den letzten drei Monaten ein Release? Hat das Projekt zum Beispiel Security Scans mit drinnen?
Die ICD, also heutzutage geht man ja davon aus, dass das ein Standard ist.
Wie einfach kann ich was beitragen zu dem Projekt? Das heißt, wenn ich dann irgendwann mal sage, ich möchte selbst was hinzufügen oder jemandem beauftragen,
wie offen sind sozusagen die Schnittstellen? Gibt es zum Beispiel eine Public Roadmap oder eine Direction, wo man nachlesen kann,
was ist denn so die Idee der nächsten ein bis drei Jahre zum Beispiel? Oder auch so Dinge wie "das machen wir definitiv nicht", um es dann in fünf Jahren zu machen. Aber anderes Thema.
Wie ist die Verfügbarkeit von Installationsmethoden? Also wenn jetzt zum Beispiel ein Projekt hergeht und sagt,
für DBM gibt es Pakete, aber für Red Hat nicht, dann ist das für mich halt so ein Entscheidungsmerkmal zu sagen,
naja, dann kann ich es aber in der Firma in meiner Red Hat oder Zentrumsumgebung nicht installieren, einfach so.
Das hat dann einen faden Beigeschmack, wenn man das versteckt. Genauso wenn es darum geht, ich möchte es jetzt in meiner Kubernetes-Umgebung installieren.
Und es gibt keinen Helm-Chart oder keine Cloud-Native-Installations-Methode, außer ein Kontaktform, wo man sich eintragen muss.
Hatten wir auch schon, und da muss man einfach auch dann auf die Leute zugehen und sagen, naja, es wäre halt schön, wenn die Installation funktioniert, ohne Einschränkungen.
Und alles weitere hinaus kann man natürlich darüber reden, dass jemand Geld verdienen möchte und so weiter und so fort.
Und die andere Sache, die mir bei Open-Source-Projekten heute auch noch wichtig ist, ist, wie ist die Community-Pflege?
Ist das Forum aktiv? Gibt es ein Code of Contact? Wie schaut es rundherum aus?
Also diese Mundpropaganda klingt blöd, aber wie ist denn so der Tenor in der Community? Was ist denn gut?
Wird da auch zugehört, wenn jetzt jemand sagt, ja, das, was du da eingebaut hast, das macht alles kaputt und das ist Murks und das wird irgendwo ignoriert?
Also so ein bisschen ein Stimmungsbild der Community einzufangen.
Was natürlich, wenn man jetzt im Enterprise-Umfeld was findet und sucht, schwieriger zu finden ist.
Aber es ist ja, man muss jetzt selbst auch ein bisschen so dann der Evangelist oder der Advokat von dem Tool dann auch sein intern, wenn man es in der Firma auch reinbringen möchte.
Also ich vergleiche das jetzt gern mit, ich möchte GitLab irgendwo installieren oder ich möchte Promises irgendwo installieren.
Da muss ich mir natürlich auch ein bisschen auskennen, damit beschäftigen und vielleicht einen Anwendungszweck für mich selber finden.
Also wiederum, ich möchte meine Temperatursensoren oder ich möchte meinen, also das sieht man jetzt im Podcast,
ich möchte meine Millennium Falcon, den ich im Hintergrund stehen habe, irgendwie überwachen oder was damit machen können.
Also in irgendein Fall sich ausdenken und sagt, das macht mal Spaß und da bin ich bereit, vielleicht eine halbe Stunde am Tag zu investieren.
Und kann dann, kann ich dieses Wissen dann für meine eigenen Tools verwenden.
Oder ich probiere ein SaaS-Angebot aus, weil es halt einfach schneller ist, sich mal was zusammenzuklicken und mir zum Beispiel,
ich sage jetzt irgendwas, Datadog oder Dynatrace mir anzuschauen und komme damit genauso zum Ziel.
Ja, das war jetzt zu lange. Das Wichtigste ist, Fragen, Fragen, wenn man sich nicht auskennt und auch nicht scheut,
sondern sagen, naja, das ist jetzt ein Anfängerding, wenn ich das frage, schaut das blöd aus? Nein, es gibt keine dummen Fragen.
Wichtig ist, dass es in der Community Leute gibt, die sich gegenseitig helfen und man auch mal auf eine Meetup oder mal auf ein Event,
auf eine CubeCon, auf eine PromCon, die PromCon EU ist übrigens in München Anfang November, mal einfach hingehen,
Leute treffen, Erfahrungen austauschen, lernen, vielleicht einen neuen Job finden in der Zukunft, wenn man wen kennengelernt hat.
Ja, das ist glaube ich so das Wichtigste, zusammenkommen und Leute treffen, gemeinsam Probleme lösen im Monitoring-Umfeld.
Ja, kann ich nur zustimmen. Also Community ist definitiv ein wichtiger Faktor.
Also ich kann jetzt von mir sprechen, weil ich da durchaus auch aktiv bin in der Singer-Community,
aber es macht dann durchaus auch einfach Spaß, wenn man sieht, dass das, was man anderen Leuten mit an die Hand gegeben hat oder geschrieben hat,
zu einem Ergebnis und negativ, positives Ergebnis egal, aber dass die Leute von ihren Problemen weggekommen sind
und im Idealfall logischerweise eine zufriedenstellende Lösung gefunden haben.
Weil du gerade sagst Community, wollen wir verraten, wer du bist? Das Nickname.
Und was eigentlich dein Name ist, unter denen dich die meisten Leute kennen dürften,
weil die meisten Leute, mit denen ich irgendwie über dich kurz spreche, die können mit deinem, ich nenne es jetzt mal Real Name,
wie wir 90er-Jahre-Kids das so genannt haben, die meisten können damit nichts anfangen.
Aber wenn ich mit deinem Nickname um die Ecke komme, dann sagt jeder, ach klar, natürlich, den kenne ich.
Na ja, können von mir aus tun.
Ja, dann sag mal.
Ja, in der I-Singers-Community, falls sich da jemand hin verirren sollte, ist mein Nickname Logic.
Ist noch schön in schön early 2000er Lead-Speak mit einer 1 als i.
Schönen Song Goku und Vegeta als Profilbild. Also damit sollte ich jetzt sehr leicht zu identifizieren sein.
Ja, genau.
Also mein Nickname ist nicht ganz so alt, aber er kommt aus den Uni Wien-Zeiten mit DNS.
Und ich habe immer so das Problem gehabt, ich wusste nie, wie er einen Nickname wählen konnte.
Also ich habe an der Fachschule Hagenberg studiert in Österreich, Hardware Software Systems Engineering,
und hatte dann den Nickname HSE Michi.
Den konnte niemand aussprechen, ich war dann der Hesse Michi oder der Hasse Michi oder der Hasse Michi.
Und auf der Uni Wien war es dann so, ah, DNS Michi.
Also super. Und dann irgendwann später, na ja, jetzt müsstest du eigentlich der I-Singer Michi sein und der GitLab Michi und Schieß mich tot.
Konnte irgendwie aber den Nickname nicht mehr ablegen.
Habe aber jetzt festgestellt, der Name funktioniert wunderbar im deutschsprachigen Raum.
Bei GitLab sprechen wir Englisch und das CH ist halt im Englischen halt schwierig auszusprechen.
Und man muss jetzt, ich sage dann halt meistens so, ja, DNS im MICHI.
Michael ist total okay. Aber so ist es halt.
Und jeder kennt mich unter dem Kürzel. Aussprechen ist nicht immer so einfach.
Aber ja, ja, das heißt, ich habe den Nickname jetzt 2009.
Alt.
Sehr schön, sehr schön. Ich finde auch das Thema Community ist wirklich wichtig.
Also wir haben ja gerade schon festgestellt, drei Leute kennen sich über verschiedene Communities.
Und ich finde auch, dass das wirklich ein Kriterium sein sollte, wenn man sich so ein Tool anschaut.
Also ich finde auch, man sollte vielleicht nicht unbedingt mit dem größten Legacy Tool starten.
Ich weiß jetzt nicht, ob ich so weit gehen würde, Narcos direkt als Legacy bezeichnen würde.
Da gibt es bestimmt Use Cases für. Aber ich würde mir halt ein paar Tools angucken,
würde abwägen, was da irgendwie Sinn ergibt. Und ich finde auch ein gutes Tool ist eins,
das eine gute Community hat, dass sie eben auch auf GitHub eine öffentliche Roadmap irgendwie hat,
dass da Dinge tut, dass auch Beiträge von der Community annimmt.
Das gehört für mich zu einer aktiven modernen Kultur mit dazu.
Und ich muss auch zugeben, die meisten Tools, mit denen ich bisher zu tun hatte,
die habe ich auch irgendwo mal im Home Lab irgendwie eingesetzt.
Und jetzt würde ich dann vielleicht nicht unbedingt ein Tool nehmen, das einen proprietären Core hat.
Und bin aber auch der Meinung, das war ja das, was du vorhin sagtest, Gerd.
Es ist natürlich schön, wenn man alles selbst gelöst bekommt, wenn man autodidaktisch in der Lage ist,
sich auch komplexe Themen anzueignen, muss aber auch zugeben, nach doch zehn Jahren jetzt in der Branche,
mit der Einstellung eckt man an, landet in einem Burnout oder kriegt verfrüht graue Haare.
Also es ist voll okay, sich mal so für zwei, drei Tage einen externen oder einen externe einzukaufen
und sich da mal das Grundsetup hinstellen zu lassen und so Grundfunktion beibringen zu lassen.
Und dann, glaube ich, wenn man da weitermacht ambitioniert, dann ist man auf einem guten Weg.
Aber man kann nicht alles selbst machen. Das ist so die Lektion, die ich auch in den letzten Jahren dann lernen musste.
Fallen euch spontan so typische Do's und Don'ts ein, also so Dinge, die man auf gar keinen Fall tun sollte,
die ihr unseren Zuhörenden mitgeben wollt?
Ja, ich nehme direkt was als Monitoring-Admin.
Ich bin komplett schmerzfrei darin geworden, wenn die Leute sagen, ich will diese Meldung nicht haben.
Weil es bringt nichts, wenn ich mich als Monitoring-Admin hinstelle und sage, das ist aber total wichtig,
das ist voll kritisch, du musst diese E-Mail kriegen.
Wenn die Leute nicht darauf reagieren wollen, dann ist es nicht mein Job, sie dazu zu erziehen.
Dann kann ich die Meldung ruhig stellen und wenn sie irgendwann fällt,
dann fällt ihnen das auf die Füße oder vielleicht auch nicht.
Und dann können sie immer noch nachgucken, ob es das Monitoring gesehen hätte
und ob sie vielleicht in Zukunft alarmiert werden wollen.
Aber ich glaube, ein indischer Dienstleister hat mal gesagt, this is not actionable for us.
Und ich fand das Wort actionable sehr schön, als wird eine Aktion daraus abgeleitet, wenn nicht,
dann stellt es Stummweiß, dann hat es auch keinen Sinn, dann ist es nur Spam.
Und das Monitoring kann noch so präzise sein, wenn die Leute sagen, ich habe aber, ich verstehe das nicht
oder ich habe keine Zeit darauf zu reagieren, weil natürlich ist es wichtig,
aber ich habe fünf andere Sachen, die sind wichtiger, dann muss man das akzeptieren.
Und dann ärgert man sich ja auch nicht als Monitoring-Admin, kann ich nur empfehlen.
Ja, sehr guter Punkt. Weil ich habe das schöne Wort "benachrichtigungsblind"
bei mir irgendwann mal bei irgendeinem Kunden gefallen, das ist mir so im Kopf geblieben.
Wenn das Monitoring-System da im acht-Stunden-Takt zu einem Problem, die die Mails raushaut
oder die Leute per Teams oder irgendeinem anderen Messenger nervt,
dann interessiert die das irgendwann nicht mehr.
Also wenn zu einem Problem x Nachrichten gekommen sind, wird es irgendwann wegsortiert.
Das ist bei mir auf jeden Fall so hängen geblieben.
Benachrichtigungen im Monitoring am besten so einrichten, dass sie einmalig passieren
und wenn dann keiner darauf reagiert, dann ist es nicht mein Problem.
Das muss dann der entsprechende Anwender wissen, ob er darauf reagiert.
Was mir gerade noch ganz schnell einfällt, was für mich auf jeden Fall ein Don't ist,
was ich aber immer wieder als Anfrage kriege im Prinzip, ist, kannst du hier mal bitte
die Schwellenwerte erhöhen, damit ich da keine Benachrichtigungen mehr zu kriege.
Und dann mit dem Monitoring im Prinzip so um das Problem rumarbeiten,
dass es im Monitoring nicht mehr auftaucht.
Das ist halt einfach nicht Sinn der Sache im Prinzip.
Und damit macht man glaube ich hinterher nur mehr kaputt
oder hört sich nur mehr Ärger ins Haus, als man damit auf kurze Sicht umgeht.
Ich würde hinzufügen und das Alerting und Incident Management ist ein riesen Thema,
das haben wir eigentlich gar nicht wirklich besprochen.
Ich finde Dokumentation sehr wichtig.
Zum einen, wenn jetzt ein Incident passiert, dass irgendwo ein Wiki oder Git Repository
mit Markdown-Files, je nachdem wie Dokumentation geschrieben wird,
dass du ein Runbook oder einen Maßnahmenkatalog, wie es damals auf der Uni Wien hieß,
dass du die Schritte da drinnen siehst und sagst, dieses Problem, so kannst du es lösen,
so kannst du es troubleshooten, debuggen, hier ist der Link in Celestic oder Kibana oder wie auch immer.
Dieser zusätzliche Low-Context, damit du sofort im Fehlerfall reagieren kannst
und nicht davor stehst und sagst, das ist schön, aber eigentlich interessiert es mich nicht,
weil ich weiß ja gar nicht, wie ich anfangen soll.
Viele Incidents sind dann auch so, dass du nicht alleine an Call bist,
sondern dass halt der Team aktiv reinschaut und zusammenarbeitet.
Unter anderem ein Tipp für jemanden, der jetzt einsteigt oder auch schon ein bisschen Erfahrung sammelt,
Dokumentation im Sinne von einem Git Repository, dass du dir aufschreibst,
wie funktioniert die Installation, vielleicht das Ganze automatisierst mit Ansible
oder mit irgendeiner anderen Art und Weise, damit du das Monitoring,
sollte es mal weg sein oder irgendwie komplette Cluster oder Datencenter abbrennen,
wo du das wieder herstellen kannst, dass du Runbooks zum Beispiel zur Verfügung stellst,
die jetzt an Service neu starten können, die verteilte Umgebungen im Monitoring auch managen können
oder mal Datenbankcluster neu starten oder irgendwelche anderen Dinge,
wo du normalerweise googeln musst, wie funktioniert jetzt der Befehl mit 5x Pipegrab,
dass das einfach in dieser Form verfügbar ist, weil dann ist es auch für jemanden,
der jetzt an Call ist oder einen Alert bekommt, einfach es ist nicht dieses,
ich muss jetzt da mal was machen und ich hasse diese Arbeit, sondern du hast diese Schritte,
du kommst im besten Fall schnell zu einer Lösung und dann legst du den Pager wieder auf die Seite
und entweder schläfst weiter oder du kannst einfach untertags wieder in Fokuszeit arbeiten.
Ich glaube, so Gitrepositore, Dokumentation, Automatisierung, Backups sind viele Dinge,
die am Anfang ungeliebt sind, aber wenn du sie etablierst in deinen Workflows, in den Teams mit drinnen,
dann kannst du dir das Leben leichter machen in Zukunft.
Ja, auf jeden Fall, das klingt valider. Ich persönlich habe auch eine Zeit lang als Monitoringadmin gearbeitet
und habe deswegen vor ihm so lachen müssen, als Philipp sagte, hier kannst du dich mal etwas anpassen,
weil das ungelogen täglich vorkam und ich bin da echt ein Fan von Standards geworden.
Also so nach Möglichkeit, echt eine Baseline zu haben für alles, was irgendwie sinnvoll ist,
klar, natürlich Abweichungen mal auch vorzunehmen, wenn es sinnvoll ist, aber halt nicht wirklich
für jeden User, für jede Anwendung eine Ausnahme zu definieren, weil das dann irgendwann zu überblicken,
das wird einfach ein Ding der Unmöglichkeit. Das funktioniert definitiv nicht.
Was auf jeden Fall auch wichtig ist, nichts zu brechen, einfach nur, weil es hip ist, jetzt auf ein anderes Tool zu wechseln,
ist es vollkommen okay, einen Nagios, Isingas, was auch immer einzusetzen, obwohl jeder andere vermeintlich
modernere Tools nutzt, wie jetzt Prometheus oder irgendwie sowas. Man muss nicht das Tool wegen,
einfach ein anderes Tool einsetzen, das muss auch nicht unbedingt sein. Auf der anderen Seite muss man aber auch nicht
alles selbst entwickeln. Also bevor man sich jetzt das 300. Isinga Plugin oder Monitoring Plugin zu Tool XYZ programmiert,
einfach mal ein bisschen recherchieren, gibt es da vielleicht jemand, der das schon getan hat, weil es natürlich schön,
wenn man was entwickelt und das auch produktiv eingesetzt wird, aber man muss da auch seinen eigenen Stolz für dich
ein bisschen zurückschrauben, weil mit jedem Tool, das man entwickelt, holt man sich natürlich auch eine Maintenance
mit ins Haus, die es dann auch wieder gilt, abzubilden. Und es ist sehr schön, dass ich ein Plugin habe, aber wenn ich
halt jede Woche da vier Stunden investieren muss, um das zu warten, dann habe ich mir halt in Summe eigentlich
keinen Gefallen getan gegenüber, ich nehme was, was schon jemand anders programmiert hat. Das sind so meine Do's und Don'ts,
die ich dann noch ergänzend mit dazu bringen kann. Und ich glaube, damit haben wir so grob zusammengekehrt.
Wir haben natürlich nicht jedes Tool besprochen. Es gibt sicherlich noch viele Tools, die wir hier ergänzen könnten.
Vielleicht machen wir wirklich noch mal eine zweite Folge, so in einem Jahr oder so, das fände ich persönlich sehr interessant.
Und vielleicht kommen wir mal zum Tooltip oder den Tooltips dieser Folge.
Und ich habe ein Tool rausgesucht, das mit Molentong zu tun hat, und zwar ist das Glances. Und mich erinnert das so ein bisschen an das
kostenpflichtige Glance, das es damals für Hap UX gab. Also sage, dass du alt bist, ohne zu sagen, dass du alt bist.
Ich musste mal Unix administrieren, immer am ersten Job. Und obwohl ich unter 40 bin, das nochmal, um das Ganze abzustecken,
da gab es halt ein sehr gutes proprietäres Tool, das kostenpflichtig war. Und ich glaube, Glances ist so ein bisschen daran angelehnt.
Man kann das, glaube ich, zusammenfassen als Top oder Hardtop und Steroids, so könnte man es glaube ich sagen.
Es ist halt ein Seal Eye Tool und ist ein System Monitoring in dem Sinne. Darüber haben wir ja heute auch so gar nicht gesprochen.
Wir haben jetzt sehr über Applikations und Cloud und Plattform Monitoring gesprochen. Aber es gibt natürlich auch noch das System Monitoring,
wo ich eben auf meiner VM, auf meinem Server, in meinem Container gucken kann, was da gerade so vor sich geht.
Und da finde ich Glances sehr nützlich. Das hat einfach super viele Plugins. Man hat hier verschiedene Metriken, die man sehen kann.
Also wirklich angefangen bei den Klassikern CPU und Memory bis hin zu so Sachen wie "Wie ist denn gerade die IO-Wait Time?"
Es gibt ja unter Linux extrem viele Metriken und extrem viele Tools, die ich dafür zu Rate ziehen kann.
Und Glances versucht das so ein bisschen zu vereinen. Und es gibt eben auch so Plugins, die es zum Beispiel ermöglichen,
über so ein Remote Web Interface auf so ein System drauf zu gucken, dass ich halt eben nicht meine 500 SSH Terminals offen haben muss.
Es gibt für einzelne Applikationen wie Kafka oder InfluxDB gibt es Plugins, die da halt eben Exports ermöglichen.
Es gibt aber auch so Sachen wie Temperatursensoren, Monitoring für Docker und so weiter und so weiter.
Also die Liste ist außerordentlich lang und ich glaube, ich kenne vielleicht so ein Prozent der Features, die das Tool so bringt,
finde das aber sehr nützlich und deswegen ist das mein Tooltip für diese Folge.
Ich finde es total geil, wie du von der Tonlage so leicht gewechselt bist, als wenn du das jetzt, wie so in manchen Podcasts,
wo dann so ist, Werbung und dann sagt aber der Host, liest dann die Werbung vor. Man hört die Stimme, aber es ist so ein bisschen anders.
Aber für so ein Open Source, finde ich es trotzdem cool.
Wie viele Hardtop auf Steroids gibt es eigentlich? Ich glaube gefühlt gibt es nichts, was öfter neu entwickelt wurde.
Und ich ärgere mich dann immer rum auf Systemen, wo ich mir denke, ich will meinen Hardtop installieren, oh, kein Repository.
Okay, doch wieder Top benutzen, ist nichts anderes da.
Ja, absolut. Also Hardtop ist auch mein Default. Das gehört auf jedes System drauf, sonst kann ich da echt nur sehr schwerlich arbeiten.
Und es gibt glaube ich, also die Antwort, wie viele Forks gibt es, ist Ja.
Ich glaube, in jeder Programmiersprache gibt es ein Hardtop-Klon.
Von daher, ja, aber das Standard Hardtop ist schon echt ein absoluter Mehrwert, wenn man auf so einem Vanillasystem beim Kunden ist.
Und ja, die Folge ist natürlich hier gesponsert vom Entwickler von Glenses.
Nein, sowas machen wir natürlich nicht.
Der nächste Fork ist dann in Rust neu geschrieben.
Da gibt es garantiert schon was eher Hardtop oder sowas.
Hardtop gibt es bestimmt auch.
Ich kannte das jetzt nicht und es ist auch in Python geschrieben.
Also würde mir sehr entgegenkommen, wenn ich mehr Zeit hätte.
Aber ich werde es definitiv mal ausprobieren und auch in meinen nächsten, ich mache jetzt ein bisschen Werbung, obscendev.news Newsletter einbauen,
weil ich es super finde, einfach so Tooltips gegenseitig sich an die Hand zu bringen, um mal ein bisschen über den Tellerrand auch schauen zu können.
Ich sehe auch, da steht ein Prometheus Klein, den gibt es auch.
Aber mal schauen. Nächste Woche in Hamburg habe ich hoffentlich mehr Zeit.
Ich springe jetzt in Richtung meines Tooltips und das habe ich auch in letzter Zeit irgendwann mal entdeckt.
Das ist Vidi mit vi, doppelt, dy und ist ein Watch-Ersatz mehr oder weniger.
Watch habe ich in der Vergangenheit immer öfters verwendet, wenn du auf ein System bist und hast iostart oder vmstart oder irgendein Command,
worauf du auf etwas wartest und unter Umständen ein Fortschrittspalken sollte passieren.
Watch -N1 und dann der Befehl und dann vielleicht dann doch wieder N2 und die restlichen Befehle, keine Ahnung.
Und das Manual ist dann auch sehr lang.
Und das ist mir ins Auge gesprungen, deswegen, weil es auch für Mac OS zur Verfügung steht, also ist ein Home Pro drinnen, gibt es für Linux.
Ich weiß jetzt nicht, ob es es für Windows auch gibt, aber es ist in Go geschrieben, also theoretisch schon.
Und hat eben auch die Möglichkeit, es ist nicht ein klassisches Watch abzufedern, sondern auch die Möglichkeit, dass du sozusagen so
Time-Maschinenartig zurückscrollen kannst. Also das fängt quasi dann die Bewegung ein, wenn du so möchtest, und du kannst halt zurückgehen.
Was unter Umständen einfach hilfreich ist, wenn man den Moment gerade versäumt hat.
Und ansonsten, ja, es ist einfach eine schöne Möglichkeit, mal wieder mal was Neues auszuprobieren.
Gerade im Bereich von Qubesidel, GetPods oder anderen Themen, das zu verwenden.
Habe aber natürlich auch gehört, dass man in Qubesnet das dann eher K9s und andere Tools verwendet.
Aber für jemanden, der langjähriger Linux-Admin war und vielleicht ein bisschen immer noch ist, Watch ist halt einfach Standard-Werkzeug.
Und wenn es ein bisschen schöner geht, ist es ähnlich wie Hardtop, dann hilft es auch.
Mein Tooltip ist gar nicht wirklich ein Tool, sondern ich bleibe einfach mir mal treu mit Infrastrukturmonitoring.
Und empfehle einfach mal zwei Skripte oder Plugins, die mir sehr gut gefallen, die ich häufig einsetze.
Gerade da die Systeme, die zu monitorieren sind, wirklich Infrastruktur sind.
Das ist einmal Check_Redfish für Monitoring von Server-Hardware basierend auf der Redfish-API,
die der neue quasi Standard ist, der IPMI ablöst.
Das hat ein Monitoring-Kollege von Telekom oder T-Systems geschrieben, ist auf GitHub veröffentlicht.
Passiert auch immer wieder was, ist im Moment in einem echt guten Status, funktioniert.
Einwandfrei, man braucht nicht mehr für jeden Hardware-Wender HP, Dell, Cisco, Lenovo ein eigenes Plugin,
sondern kann die in der Regel alle mit diesem einen Plugin erschlagen, hat schönen Output,
den man sich sehr detailliert oder minimalistisch zurückgeben lassen kann.
Gefällt mir sehr gut.
Als zweites einfach noch ein bisschen SVA Eigenwerbung sozusagen.
Ein Kollege, Alexander Krogloth, der mittlerweile auch bei der SVA ist,
der eine schöne Pluginsammlung für NetApp/Seedot-Systeme geschrieben hat, die ich auch sehr gerne verwende,
sind zu finden unter dem GitHub-Handle von ihm Alex mit 2e und einer 42 am Ende
und dann NetApp/Seedot Nagios heißen sie noch als Sammlung.
Gute Skripte reichen in der Regel für den Standard bei NetApp Überwachungen aus
und benutze ich immer noch sehr gerne.
Ich weiß gar nicht, ich glaube Christian du hast ein GitHub oder irgendwas gefunden für meinen Tooltip
und der landet bestimmt in den Show Notes, aber den braucht man überhaupt nicht,
weil ich bin so oldschool, meinen Tooltip gibt es glaube ich in jedem System in den Repositories,
weil ich habe die MoreUtils genommen, weil die irgendwie ironischerweise wurden sie glaube ich von Joey Hess zusammengestellt,
um mal so viele kleine ganz alltägliche Programme zu nehmen und zu bündeln, damit sie nicht so unbeachtet sind
und trotzdem sind sie es immer noch und ich muss zu meiner Schande gestehen, als ich die Liste angeschaut habe,
dachte ich mir auch, ich kenne wahrscheinlich auch nur 4 oder 5 davon, aber sie machen das Leben einfacher.
Bekanntesten aus der MoreUtils-Sammlung ist eigentlich Spongebob, normalerweise hat man ja das Problem,
man will zum Beispiel eine Datei sortieren unter Linux und macht ein Sort auf diese Datei
und wenn man das versucht direkt wieder in die Datei zu redirecten, dann leert man die Datei dabei
und das kann man jetzt einfach über Spongebob erstmal an Spongebob pippen und der sammelt dann den ganzen Input und schreibt ihn danach aus
und das sind einfach so Kleinigkeiten, die immer das Leben leichter machen.
Ich liebe auch gerade fürs Monitoring TS, kleines Commandos-Tool, Parameter braucht aber keine,
man pipet einfach irgendeinen Input rein und wenn der halt nicht wie ein Cut auf einer Datei alles auf einmal kommt,
sondern zeitlich verzögert, dann schreibt ein TS schön einen Timestamp vor jede Zeile.
Ich glaube manche Admins haben AWK-One-Liner dafür rumliegen, aber TS macht das eigentlich ganz hervorragend
und da ist noch ganz viel anderes dabei, was man vielleicht braucht und das Schöne ist einfach, man hat sie überall,
egal wie abgeschottet die Systeme beim Kunden sind, meistens kommt man an die More Utils ran und muss nicht erst gucken,
wie man irgendwie seine geliebten Tools benutzen kann, sondern kann sich zumindest ein bisschen die Arbeit damit leichter machen.
Ja cool, ich habe gerade die Seite offen, das sind auch echt Tools, die ich noch nie gesehen habe
und wenn ich mir so die Beschreibung durchlese, die hätten auch das ein oder andere Fingerbrechen am Terminal dann doch irgendwie vereinfacht.
Ja und gefühlt gibt es seit 30 Jahren.
Also P irgendwie, da steht so T Standard Input, was dann das Ganze in Pipes weiterleitet, das ist dann irgendwie doch eleganter,
als sich da mit mehreren Kommandos oder mit AWK und Redirections herum zu ärgern.
Ich bin ja eh ein Fan davon, wenn ich AWK und Set verhindern kann, dann mache ich das gerne, weil ich einfach zu faul bin,
trotz 15 Jahren Linux mich mal hinzuhocken und allen Ernstes mal den vollständigen AWK Syntax zu erlernen.
Da bin ich hin und wieder am Überlegen, ob sich das lohnt.
Ich habe mal ganz am Anfang von meiner IT-Karriere glaube ich die ersten 120, 150 Seiten vom O'Reilly Regex Buch gelesen
und natürlich 90 Prozent wieder vergessen, aber damit hat man immer noch mehr Regex Wissen als viele
und ich glaube, das würde sich bei AWK genauso lohnen.
Man muss gar nicht viel davon kennen, aber einfach nur so ein bisschen und plötzlich ist das Leben wahrscheinlich viel einfacher.
Ganz allgemein, gar nicht nur die IT, alles ist einfacher, aber ein bisschen mehr Regex und AWK könnte ich glaube ich.
Also wenn du zu Regex Hilfe brauchst, ich nehme immer noch regex101.com, also Webseite.
Kenn ich super, absolut grandios.
Wo du quasi testen kannst und mittlerweile dann auch so wie extra hier ich bestimmte Gruppen und geht das dann auch,
weil jetzt auf der Schedl eine, also ok, ich weiß eine Regex auswendig, wie ich aus einer Konfig-Datei alle Hashes und Leerzeichen rauslösche
und die Datei printe, damit ich nur die Konfig-Optionen sehe.
Das kannst du mit e-grab -v quotes circonflex-dachral hashpipe circonflex-dollar-quote Dateinahme machen.
Lass uns das nicht in die Show Notes schreiben, damit jeder immer wieder zu diesem, wie bei so einem Telefonanruf,
wo man dann wieder zurück muss, oh Gott wie war die Telefonnummer.
Kann dreimal anhören bis man es abgeschrieben hat, finde ich super.
Wer mir auf Twitter folgt, genauso DNSmichi, findet das irgendwo im Archiv.
Sehr schön. Ich habe neulich im anderen Podcast gehört, es gibt jetzt irgendein Machine Learning Driven as a Service Angebot,
wo du ein Premium-Account für einen Service hast, wo du reinschreibst, was du gerne als regulären Ausdruck hättest und eine KI.
Interpretiert dann deinen Input so und schreibt dir dann den richtigen regulären Ausdruck.
Ich bin mir sicher, dass das oft falsch ist. Allein weil man gar nicht dran denkt, es richtig zu formulieren.
Absolut, glaube ich auch. Ich glaube als Free-User kannst du eine Anfrage pro Tag stellen.
Das klang so absurd, aber vielleicht sollte man sich das mal angucken. Bisher habe ich es nicht gebraucht.
Wenn ich mir so anschaue, wie die Webformulare die E-Mail-Adressen prüfen mit Regex, ist das sicher eine gute Investition.
Auf jeden Fall. Sehr gut.
Ich glaube, das war die längste Podcast-Folge, die wir bisher in diesem Format hatten.
Nichtsdestotrotz hat es mir enorm viel Spaß gemacht, mit euch darüber zu reden und kann da auf jeden Fall nur sagen, vielen lieben Dank, dass ihr dabei wart und so viel Input geliefert habt.
Gleichfalls hat es sehr viel Spaß gemacht.
Ich kann überhaupt nicht einschätzen, wie viele Zuhörer du normalerweise hast, aber ich glaube, wer bis zum Ende zugehört hat, der muss großer Focus-On-Linux-Fan sein.
Hoffentlich, wenn der oder es jetzt zugehört hat, einfach mal gerne auf Social Media, Twitter, LinkedIn, die Leute suchen, erwähnen, in Kontakt treten, sagen, wie es gefallen hat, was wir besser machen können.
Natürlich nicht so lange reden, aber ich habe es eingangs schon gesagt, ich kann da tagelang darüber reden.
Ja, und wenn Fragen offen sind zu Tools oder anderen Dingen, die wir jetzt erwähnt haben, einfach auf uns zu kommen.
Vielleicht sehen wir uns ja auch mal in Person irgendwo auf einem Event oder Community Meetup.
Auf jeden Fall würde ich mich auch darüber freuen, euch alle mal wieder in Natura zu sehen oder den einen oder anderen überhaupt mal das erste Mal in Natura zu sehen.
Und natürlich vollkommen richtig. Wir freuen uns immer über Feedback, das ist uns sehr wichtig.
Das heißt, wenn ihr Ideen, Wünsche oder Tooltips habt, dann schickt die gerne an podcast@sva.de oder über Twitter, über unseren Handel sva_focuson.
Und natürlich sind wir auch immer dankbar über Bewertungen über euren Podcasts, also beispielsweise Spotify oder Apple Podcasts.
Und wer es bis hierhin durchgehalten hat, herzlichen Glückwunsch. Das war ein langer, wilder Ritt, hat mir aber sehr viel Spaß gemacht.
Und ich würde sagen, wir hören uns bestimmt in einer der weiteren Folgen nochmal.
Also bleibt mir nur zu sagen, vielen Dank und bis zum nächsten Mal.
[Musik]