So, hallo. Lautstärke passt? Gut. Monitoring, Technik, ich hab mir überlegt, modernes Monitoring muss man immer noch drüber reden oder nicht.

Deshalb gibt's mal so die kleine Baumkunde im Tap-Ops-Wald. Weil, guten Wald kennt jemand, man sieht ab und zu die Bäume vom Wald nicht mehr. Also, den Baum fordert der Bäumen nicht. Und ist die Frage, mit den ganzen Tools, die es auf dem Markt gibt, gibt es bloß ein kleiner Ausstatt, um mal keinen Bock mehr Logos zu sammeln.

Was nimmt man da eigentlich? Da gibt's irgendwie von den Schedulern, also die Werte einsammeln, Anzeigen, gibt es total viele Tools. Fünf bis zehn, wenn man so langweilig guckt, wenn man intensiver guckt, findet man noch viel mehr. Dann als Datenspeicher hintendran, mit Times-Use-Databases gibt es auch irgendwie spontan fünf, fallen mir so ein, wenn man nachdenkt, noch mehr.

Was macht man da eigentlich? Was kann man nehmen? Was gibt's auf dem Markt? Wo sind die Unterschiede? Ich gebe mal so einen groben Einblick, wie ich da so um den Wald zurechtkomme. Kurz auf mir, ich bin Spezialexperte für Computerdinge, habe schon in meiner kurzen Karriere mit einigen Monitoring-Tools gearbeitet.

Solche Nagios, Check-MKs, Sendos, Prometheus, habe festgestellt, einige sind für einige Use-Cases besser geeignet als andere. Andere lassen sich immer schwer bedienen, schlecht skriptbar und man muss mal gucken, was passt eigentlich zu einem. Zum Graphing, Grafana ist jetzt so das Tool der Wahl heutzutage, davor war RD-Tool aktuell.

Die meisten Zeit in meiner Karriere war ich halt System-Engineer, Admin, verwandte Themen drumherum und bin jetzt halt bei der BKON GmbH als System-Engineer, Bereich Monitoring. So, so viel zu mir, zu euch. Wer nutzt oder kennt jemand, hat einen Bekannten, der ein Monitoring-Tool nutzt. Wie sieht es denn bei euch so aus?

Vereinzelte Meldungen, ok, also das Thema tangiert anscheinend einige. Dazu eine Frage, sind die eher so check-basiert, wie Nagios, Sabix, E-Singer, ich sehe nicken und metric-basiert mit so einer Times-Fuels-Database im Hintergrund, so was wie Prometheus oder SMP-basiert, ok, auch einige so verteilt.

Gut, dann haben wir ja festgestellt, einige haben Monitoring, einige kennen das, aber warum muss man immer noch oder schon wieder drüber reden? Und da habe ich festgestellt, ok, IT-Systeme verändern sich, es gibt nicht mehr

so diese monolithischen Systeme, wo man den Server-Namen gibt, irgendwie sich tatsächlich drum kümmert, die anderen Kollegen hat den anderen Server, ich habe meine fünf, die anderen hat die anderen zwanzig und so ein IT-Setup heutzutage in Unternehmen, die sind anders geworden, die sind gewachsen, die sind dynamischer, die skalieren auch dynamisch, das heißt, ich weiß gar nicht mehr, welche Instanzen auf welchen Server rennen, was machen die eigentlich zum anderen.

Also das ist das eine herausfrohendes Monitoring, da muss man gucken, skaliert das Monitoring mit, mit der Infrastruktur, wenn nicht dann um 18 Uhr, wenn die Leute nach Hause gehen, irgendwie ihre Fahrgastauskunft ziehen, neue Instanzen hochskalieren, skaliert das Monitoring mit, sind die Instanzen auch

im Monitoring drin, das ist das eine Problem und das andere ist, ständig kommen Daten abhand, also ist meine Infrastruktur immer noch up to date, habe ich da irgendwelche Lücken irgendwo, werden Daten abgeflossen, wo ich nicht weiß, dass die da irgendwie gerade abhand kommen, wie kann ich das irgendwie noch mit feststellen, das ist ja vor zwanzig Jahren nicht ganz so

das Thema gewesen, so, jetzt habe ich dieses Baumthema normalerweise als Thema genommen oder als Aufhänger genommen, habe überlegt, wie visualisiere ich das denn halbwegs, habe festgestellt, ok Monitoring, da haben wir zum einen Tools und Werkzeuge, die wir benutzen und zum anderen Methoden, wie wir die benutzen,

das ist nicht vollständig, ich habe mir mal so ein paar rausgegriffen, die ich so in der halben, dreiviertel Stunde abreißen kann und will und da hangeln wir uns mal zuerst den Tools entlang, mal gucken, welche Methoden gibt es so zum Scheduling, also Scheduler ist für mich zum Beispiel so Nagel oder Senso, der die Checks schedules und zum anderen die Kollektoren,

so sind die Skripte drunter, die die Messwerte quasi erheben und das ist ja bloß ein Teil davon, da kann man auch noch dieses ganze Lock-Processing, das ist dazu abgegrenzt, was lesen können, habe ich den Baum nochmal gekippt und wir hangeln uns jetzt so von links nach rechts durch,

Monitoring geht nicht um Monitore, sondern, oder Monitore verstehe ich im Rahmen des Vortrags jetzt, dass ich zum einen Werte sammle, also ich will irgendwie gucken, läuft ein Prozess, ist die Festplatte voll, wie geht es dem Server oder dem System an sich oder dem Service, die gesammelten Werte will ich irgendwie visualisieren, die will ich für mich als Mensch sichtbar machen

und danach, wenn ich das irgendwie schon habe, kann ich darauf zum einen Trending sagen, ich kann gucken, okay, wie verhalten sich meine Systeme über die letzten 13 Monate, muss ich da irgendwie skalieren, hoch runter, wie auch immer, gebe ich zu viel für meine Systeme aus, habe ich vielleicht das Spitzen, wo die User unzufrieden sind und deshalb vielleicht

weniger Wachstum als möglich wäre oder auch die Alarmierung geht da drauf auch. Was werde ich nicht so betrachten, zum einen Logging, das ganze Log Aggregations, Log Sammeln, Logs verwalten, da irgendwie Korrelationen finden, was auch immer, Tracing Profiling, was meine ich damit, wenn ich jetzt so eine moderne Web Applikation habe, dann kann ich ja auch tiefer rein gucken,

richtig so, wie wird ein Request durch die ganzen Applikationen, die dem Mikroservice Architektur vorhanden sind, abgefrühstückt, das ist ein eigenes Thema an sich, das kann man zum Beispiel einsetzen, wenn ich ein neues Release plane, dann mache ich mein Monitoring vor dem Release ein bisschen Gespräch hier,

gucke so eine Woche zu, wie verhält sich das, mache das Upgrade, gucke noch mal eine Woche zu und sehe dann zum Beispiel, ob ich irgendwelche Degradations habe, werden die Datenbank Connections langsamer, hängt da irgendwas, ist irgendwas mit dem Release schief gegangen, das hielt so für mich in diese Richtung mit rein und das ganze Debugging, das ist eher so nachgelagert, wenn ich zum Beispiel feststelle,

auch mein Dashboard, irgendwas stimmt nicht, dann kann ich anhand dessen tiefer reingehen gucken, ist jetzt wirklich bloß der Apache, hängt der oder ist das irgendwas anderes in einem nachgelagerten oder vorgelagerten System, ist irgendwie ein Teilsystem, Festplattenproblem, was auch immer, das Debugging ist quasi nachgelagert zum Monitoring,

also das Monitoring ist das Hilfstool dafür, um weiter reinzugehen. So, Werte sammeln, erheben, ich muss ja irgendwie, wenn ich jetzt so ein System habe, was auch immer, das läuft, das läuft nicht, das sehe ich ja von außen nicht, das heißt, ich muss irgendwie Werte sammeln,

da gibt es verschiedene Ansätze, das kommen wir nachher noch, also mein Zimmer kann auch gleich drauf reingehen, zum Beispiel ich kann sagen, ich will ein komplexes Skript ausführen, um den Status festzustellen, dann gibt es dann eine Abfolge vom Befehl im Programm, ich kann die Smartmonstool aufrufen, im einfachsten Fall, ich kann auch richtig Abfolgen haben,

wo ich dann einen Status kriege, einfach so, okay, nicht okay, dann ist das fix, aber ich kann auch sagen, okay, ich sammle einfach bloß Metriken, wie ist die CPU-Auslastung, wie lange dauern die ganzen Request-Dichte ab, Frühstücke, sammle diese Metriken und speichere die erstmal weg und aggregiere die über verschiedene Systeme,

wenn ich jetzt so eine Web-Applikation habe mit irgendwie 50 Application-Server, dann interessiert mich ja nicht, ob irgendwie ein Application-Server ein bisschen langsamer ist, sondern wie verhält sich das in der großen Summe, weil ein paar Fehler sind immer, oder der User geht mit seinem Telefon in ein Funkloch rein, dann ist der Request irgendwie auch abgebrochen, es liegt nicht an mein System,

so, dann haben wir die Werte gesammelt, irgendwie gespeichert, und Times-Viewers-Database zum Beispiel, auch kann ich noch eingehen, und zwar, Sonagios sammelt halt die Checks ein, Cache-Decode, alles schick, vielleicht noch historisch, und wenn ich so Metriken einsammle, dann will ich die in eine spezielle Datenbank packen,

weil es da effektiver gespeichert wird, wenn ich da so alle 15 Sekunden oder alle Minute so ein System mit irgendwie 50 Werten anspreche, dann will ich die auch wegspeichern, weil die 50 Werte pro System oder pro Service, die teilen sich auch auf den ganzen Applikationsserver, also die multiplizieren sich hoch, wenn ich dann 50 mal 100 Services,

das geht halt in die Menge, und dass die effektiv gespeichert werden, gibt es so Times-Views-Databases wie Influx oder was Prometheus in drinnen mit benutzt, so Visualisierung, früher wurde es ja mit RRD-Tool gemacht, das sind diese ganzen kleinen Bildchen, die man noch teilweise sieht und kennt,

haben ein charakteristisches Aussehen, das Problem war, die sind halt statisch, da muss man dann, wenn man so historische Daten hat oder verschiedene Time-Ranges hat, rein skalieren, mehrere rendern, und mit einem Graphaner heutzutage kann man dynamische Dashboards bauen, kann verschiedene Dashboards nebeneinander packen und rein- und raussuchen,

so, und ein Graph, mehrere Graphen zusammen, auf so ein Dashboard gehen man dann so Einsichten, die man über das ganze System kriegen kann, und wenn ich das habe, dann kann ich von mir auch fürs Management noch Reports rausgenerieren, oder Jahresberichte, wie auch immer,

so, dann haben wir uns quasi als Mensch die Metriken schonmal angeguckt, oder die Resultate im Befahren von Graphen, und die Metriken können wir noch irgendwie auswerten, zum einen können wir quasi mit Schwellwert arbeiten, ein gutes Beispiel finde ich immer, nicht die Festplatte so 80% voll,

weil Festplatten oder Moundpoints sind unterschiedlich groß, von ein paar Gigabyte bis zu ein paar Petabyte, und 80% bei 80 Petabyte sind eine ganz andere Hausnummer, als bei 5 Gigabyte für so ein Routerfest, deshalb sind so Schwellwerte, die man evaluiert,

so kommt es noch, extra polieren kommt jetzt, dass ich sage, okay, ich brauche eine Reaktionszeit von 4 bis 12 Stunden, um Plattensplatt zu erweichern, das heißt, nehme eine Zeitserie, extra poliere die, und sag dann, wenn in 4 Stunden irgendwie 95% erreicht bin, würde ich ein Alert losschicken, das Vorteil daran ist, dass ich nicht wie früher irgendwie

zigtausend Alarme generiere, bloß weil irgendwas so 90% voll ist, was mich gar nicht interessiert, sondern ich habe wirklich einen Alert generiert, wo der Mensch am Ende der Schlange was machen kann, wirklich so eine Actionable-Handlung, also im Sinne von Alerts rausschicken zu den Engineers, sollte maßvoll und nicht in Massen sein,

weil sonst kommt bloß Frust auf, und keiner guckt sich die Alerts mehr richtig an. So, dann gehen wir mal in den Baum rein, in den Tools-Bereich, und die Monitoring-Tools, ich habe festgestellt, nicht jedes Tool passt zu jedem Team, man muss halt gucken, wie ticken die Leute,

wie arbeiten die, haben die Hilfstools im Sinne von Ansible, Puppet, nutzen die Automation, machen die noch alles per Hand, weil die bloß eine Handvoll Server haben, und die bloß alle 5 bis 10 Jahre ausgetauscht werden, da ist die Frage, welches Tool passt zum Team, und auch zum Thema Ausrollen,

wenn ich jetzt das Thema ausrollen will, ist es automatisiert oder nicht, z.B. Senzu ist im Core darauf ausgelegt, automatisierbar zu sein, das Ding per Hand zu konfigurieren, das will man nicht unbedingt, aber wenn ich jetzt ein Ansible drunter habe, dann ist es kein Problem, da ist es komplizierter,

Nagels auszurollen, wenn ich das per Hand habe, da muss ich auch einen Isingar 2H mit einem Direktor davor, wo ich auch einen Excel Import machen kann, wenn ich darauf stehe oder auch nicht, und diese Tools sind zu Edge and Basier, d.h. ich habe auf dem system, einen kleinen Dienst laufen, den der Scheduler anfragt

und sich die Werte abholt, oder der Trigger, die ausgeführt werden und die Werte zurückgeben, und Edge and Less Systeme, die setzen auf SNMP, Polen, Netzwerke, oder andere Services oder Geräte, wo ein SNMP-Demon draufläuft,

die scrapen alle Metriken, die sie kriegen raus, einen ähnlichen Ansatz hat auch Prometheus, Prometheus ist der neue Sterner Monitor, das geht steil seit fünf Jahren oder länger, und er hat einen ähnlichen Ansatz, dass ich in einer Applikation, oder wenn die Applikation das nicht unterstützt,

dann werden die Metriken rausgegriffen, ähnlich wie SNMP, dazu komme ich gleich noch im Detail, also der große Unterschied ist, zwischen ich habe einen Edge and Laufen Dienst, der läuft, den ich vielleicht noch konfigurieren muss in einer Art und Weise,

oder ich habe einfach Systeme, die rolle ich einmal aus und dann werden die Metriken exposed und die kann ich mir einfach abholen. Der Unterschied zum Beispiel hier, das ist jetzt das Nagios-Check-Format, das haben einige andere Systeme auch, also weiter genutzt,

das ist vom Format her, ich habe einen Status Code, den sieht man hier nicht, dann den Leerspawn-Pal, dass der Ping okay ist, Pinpack geschlossen, eine gewisse Rauntrittkeim, und dahinter kann ich hinter der Pipe, Performance-Daten haben die das genannt anhängen,

in irgendeiner Art Datenbank packen und dann mit NUCWIS oder was auch immer visualisieren, das ging früher schon, wurde jetzt aber nicht so flächendeckend genutzt, zumindest habe ich das nicht so beobachtet. Ein neuer Ansatz ist dieser Metrigoni-Ansatz, dass ich eine Metrik habe, die hat einen gewissen Namen, zum Beispiel

Prom-HTTP-Metrik-Händler-Request-Total, das heißt, das Ding wird wahrscheinlich irgendwelche HTTP-Händlers aggregieren, für einen gewissen Status Code, das ist der Label, und zum Beispiel mein lokaler Prometo, das hat irgendwie schon 4.900 HTTP-Requests abgefrühstückt, erfolgreich,

und da sieht man schon den Unterschied, also man agiert hier bloß mit Werten, da gibt es zum Beispiel, da hat man keinen Status mehr, sondern ich erhebe nur die Werte, schreibe die weg und mache damit später die Interface,

also die Reputation der Daten. Wenn ich jetzt so Skripte schreibe, oder die die Tool zum Erheben, so Hilfstools waren früher irgendwie so CREP, AWK, ein neuerer Ansatz ist MTAIL, der hat ein intelligenteres Handling zum Thema Log abwerten,

also abgreifen, dann kann man zum Beispiel irgendwie die EngineX Log nehmen und ein guter Ansatz ist, noch die Metriken in so ein time-serious-Database zu schreiben, um die später auszuwerten. Zu den Methoden,

wenn man jetzt die ganzen Prometos benutzt hat, um die Metriken zu erheben, dann ist so eine beliebte Methode die Use-Methode, die kommt so, ich glaube, von diesem Brendan Gregg, der auch das solare Steetrace-Umfeld kommt, auch bei den ganzen Linux-Tools,

also die Utilisation von so einem System, dazu die Saturation und die Error-Rate. Und man guckt sich halt nicht an, ob die CPU irgendwie 80%, 90% Load hat, weil es dem Engineer und den Nutzer vor allem am Ende gar nicht interessiert, interessiert nicht, ob irgendwie da die CPU gerade wegdampft oder nicht,

er will die Katzenvideos sehen. Und deshalb ist es für den Nüsseer spannender, oder auch für den Engineer, der draufgucken muss, die Utilisation, die Saturation und die Error-Rate, kann man feststellen, wie ist das System ausgelastet, werden die ganzen Anfragen noch ausgeliefert, gut,

oder steigt die Error-Rate über einen gewissen Prozentsatz, weil einen gewissen Prozentsatz Fehler habe ich immer, wenn ich jetzt in ein Funkloch reinlaufe in mein Telefon, ist der Request eh weg, und andere Geschichten, Pakete gehen verloren, da kann einiges passieren. Wenn man danach googelt, irgendwie Brendan Gregg Use-Method,

man betreut, ist das ein guter Ansatz, und für andere Anwendungsfälle passt das halt gar nicht. Ein ähnlicher Ansatz ist die Web-Method, da geht es um die Request-Rate, die Request-Error und die Request-Duration. Man sieht es ist ähnlich, aber ein bisschen anders, und vielleicht kann man die Probleme, die man im täglichen Album,

im Alltag beobachtet, damit besser erschlagen, als mit der Use-Method. Aber diese Ansätze gehen eher so Richtung diesen Metric-Only-Ansatz wenn man eine technische Anwendung hat, ist die Frage, wie weit das funktioniert für so eine Datenbank vielleicht noch, aber für irgendwelche Fach-Applikation vielleicht schon nicht mehr.

Was habe ich nicht bedacht oder wo finde ich es noch bedarf? Zum Beispiel Workstation Monitoring. Da einige meinen, das braucht man nicht, ich sehe, wenn mein Notebook irgendwie ausgeht vor mir, ich bin der Meinung, vielleicht könnte ich doch vorher was machen,

dann würde ich das mit einem Notexporter benutzen, um zu gucken, wie sich das Notebook vor- und nachupgradet, dann habe ich noch ein anderes Tool entdeckt, Netdata, das kann ich gleich noch mal im Browser zeigen, das hat so einen dynamischen Ansatz, und ja, muss man überlegen, wie man die Log-Aggregation machen will. Dann gehe ich mal kurz rüber,

das ist jetzt Netdata, ich habe das einfach bloß installiert, irgendwie Debian Unstable Package Upgrade Install Netdata,

und so ähnlich sieht auch ein Grafana aus, das ist im Browser schön dynamisch bunt, und ich kann halt auch über die verschiedenen Ebenen gucken, wenn ich jetzt hier so einen Spike habe, wie hat sich das mit anderen Systemkomponenten verhalten? Und das Ding greppt halt automatisch relativ viel weg,

irgendwie CPU-Last, oder irgendwelche Network Traffic. Also wenn ihr euch das mal angucken wollt, das ist auch ganz interessant, das habe ich letztens entdeckt, da dachte ich mir, das erwähne ich mal, aber habe dann noch nicht so die Erfahrung. So, dann gehen wir zu den Fragen über.

Dankeschön. Also ich habe privat schon recht viele Erfahrungen gemacht, mit InfluxDB und Grafana, und mich würde mal interessieren, ob ihr bei Wecon vielleicht auch Erfahrungen gemacht habt, mit sehr großen Überwachungsinstanzen,

also jetzt schon mehrere Dutzend oder 100 oder mehr Klienz oder Server, die ihr überwachen müsst, und ob ihr uns da vielleicht irgendwelche Do's and Don'ts da empfehlen könntet. In welchen Tool war das? Bei mir war es jetzt gerade InfluxDB mit Telegraph und CollectDemon.

Ja gut, Telegraph nutzen wir nicht, also Influx als Backend, z.B. mit Sensuderfordern kommen die Metriken rein, Grafana zum Anzeigen halt, die bis in die Millionen Metriken skaliert.

Also so Lastprobleme habe ich noch nicht beobachtet. Weitere Fragen? Du hattest vorhin Agent und Agentless unterschieden,

und SNMP auch zu den Agentless gezählt, aber ist das nicht eigentlich auch, da müssen eigentlich auch Prozesse laufen, die wie Agent funktionieren. Ich glaube beim NetSNMP heißt das sogar so, NetSNMP Agent. Ja, der Unterschied finde ich ist, wenn man jetzt so ein,

also bei SNMP ist es noch ein bisschen anders als bei den Metriken ansatz, die jetzt danach gekommen sind, da kann ich das ja auch diesen ganzen Support in die Applikation mit einbauen. D.h. die Applikation hat einen HTTP Endpoint slash Metrix, wo ich die Metriken einfach abgreifen kann und keinen extra Dienst haben muss, oder ich muss keine extra Skripte schreiben

wie irgendwie ein spezielles Skript, was irgendein profitaires Rate abgreift. Von daher habe ich das so unterschieden, dass ich dann mit dem Agent oder mit dem SNMP quasi einfach rüber gehe und sage, okay, ich greife jetzt für alle MIPS, die ich finde, das ab

und habe jetzt nicht konkret irgendwelche einzelnen Checks definiert, z.B. für Linux Server, Festplatten-Check, auf der Art und Weise für die Windows Server andersrum. Sodass ich da nicht so speziell viel Hand anlegen muss.