Möchtest du als Entwickler oder Entwicklerin Samstag Nacht oder früh oder wann auch immer aus dem Bett gerissen werden, weil du jetzt dran bist und on Call quasi das fixen möchtest, ist es ist dieser Alarm so unglaublich? Wichtig, dass der jetzt fliegen muss. Coding Buddies Dein Podcast rund um Softwareentwicklung und aktueller Tech News herzlich Willkommen. Halli Hallo, es geht wieder los.
Neue Folge, neue Runde für den Coding Buddies Podcast und zwar natürlich mit mir, fabi und natürlich auch dem Tino, den der darf natürlich nicht fehlen, ist doch klar und der sitzt ja auch schon vor mir, halt die neuen. Was geht ab, was? Geht wie geht's? Wie steht's hast? Du da nochmal die Kurve gekriegt in der Anmoderation die. Ganz. Ja, alles gut bei mir und bei dir. Wie geht es dir?
Auch sehr gut. Wir sind ja gerade quasi schön mitten im in unserem Turnier, was ja gerade läuft beziehungsweise in der Implementierungsphase unseres neuen Programmierwettbewerbs Flaping Buddy und ich bin schon ganz gespannt auf die möglichen Einreichungen, das geht ja bis zum 6.4. Dem zufolge noch mal ganz kurz angemerkt, Liebe zuhören, lieber zuhören, guckt doch da mal rein.
Auf unserer Homepage www.codingbuddies.de findest du alle Infos und auch das Repository zum Turnier macht da mit, weil es gibt echt was Cooles zu gewinnen und das möchte Tino jetzt glaub ich gleich mal ganz kurz an teasern. Ja, und zwar werden wir von der We are Developers Konferenz in Berlin dieses Jahr gesponsert, in dem Sinne, dass sie uns 2 Tickets zur Verfügung stellen, die an den ersten Platz gehen.
Das heißt, wenn du das Flappy Buddy Turnier gewinnst, gewinnst du 2 Tickets für die Konferenz im Juli dieses Jahr in Berlin, es ist die größte Entwicklerkonferenz Europas und sie ist einfach unfassbar geil, wärmste Empfehlung. Und mach mit. Es lohnt sich aber Platz 2 und 3 werden auch nicht leer ausgehen, da haben wir uns auch was
überlegt. Es gibt eine limitierte Flabby Buddy Tasse für Platz 3 und 2 und Platz 2 kriegt auch noch 150€ Wunschgutschein oben drauf, deswegen es lohnt sich macht mit außerdem der Spaß steht im Vordergrund, es ist ein sehr witziges Spiel geworden und es wird richtig Bock machen dafür einen Bot zu schreiben. Auf jeden Fall. Und jeder, der sich denkt, EY, hab ich doch keinen Bock, kann trotzdem noch mit Coding Buddies 10 auch zum Beispiel n Ticket für die Real Developers kaufen und 10.
Prozent genau. Falls ihr nur auf die Konferenz wollt. Ganz genau so. Dann würd ich sagen, fangen wir mal an mit der Folge Tino, Es geht. Werbung Ende, meinst du? Werbung Ende und jetzt geht es los. Wir haben ja heute NN tolles Thema wieder mitgebracht, und zwar im Bereich Def Ops. Das heißt, wir setzen uns wird. Mal wieder Zeit. Ganz genau.
Wir setzen unsere Def Ops Reihe fort und da geht es heute um auch wieder n nicht zu vernachlässigendes Thema und zwar geht es um Monitoring und Observability sehr sehr wichtig und dabei wollen wir natürlich erklären was eigentlich
Monitoring ist. Was der Unterschied zu Observability ist, was es für, nennen wir es mal, 3 Säulen der Observability gibt, kurz angemerkt, Logs, Metriken und Traces und genau damit kann man halt im Endeffekt dann grob gesagt verstehen, wie die Systeme funktionieren, die man da aufgesetzt. Hat es ist ja n wichtiger Punkt,
weil du ja schon meintest. Um die Systeme zu verstehen, wir haben uns ja bisher in der Reihe angeguckt, wie man überhaupt so beispielsweise ne CICD Pipeline aufbauen kann. Noch mal so als kleiner Rückblick, wir haben über Staging gesprochen und wir sind quasi an dem Punkt, wo wir diese das ganze System aufgebaut haben und es funktioniert, aber was ist, wenn doch nicht oder wenn irgendwas schief läuft und genau diese Aspekte fehlen uns heute noch und da wollen wir heute
dann drüber sprechen. Und ich find es halt sehr gut, dass du direkt am Anfang sagst, das ist unglaublich wichtig, weil ich hoffe, das können wir heute herauskristallisieren, dass du, liebe Zuhörer, liebe Zuhörer, erkennst wow, es ist wirklich verdammt wichtig. Ja, ich bin gespannt, ich freu mich drauf. Ich meine, es ist ja so, dass du es, es wird nicht passieren, dass du niemals Fehler irgendwie hast. Ne. Das heißt, selbst wenn du nach gutem Gewissen arbeitest im Pair
Programming vielleicht. Dann vielleicht noch nach anderen Methoden, die möglichst versuchen, Fehler zu vermeiden. Man hat zum Beispiel, man arbeitet zum Beispiel nach Test Driven Development, man hat permanent Tests laufen, um seine Software zu integrieren, es wird dazu kommen, dass es irgendwie, dass irgendwie Fehler auftreten, sei es einfach nur, weil zum Beispiel Nutzer die Anwendung, die man programmiert hat, anders verwenden, als man sich das gedacht hat.
Ne, also es kann ja durchaus sein und ich weiß nicht wie es dir geht, Tino, aber ich hab schon so viele interessante Dinge erlebt, dass man ne Anwendung programmiert hat und user sich dachten ich mach jetzt einfach das und das und du denkst dir so, aber das war doch gar nicht vorgesehen, aber es wird. So funktioniert das Feature nicht. Aber es wird dazu kommen, dass User das Halt einfach. Anders verwenden als man denkt.
So also ich kenn dazu so n lustiges Video wo so n du hast so n Vater und n Sohn und der Sohn hat so ne Anleitung geschrieben wie der Vater sich das Brot schmieren soll ne und dann kommt es halt zu dem Punkt, dass es heißt packt das Messer in die Erdnussbutter oder so ne und er packt es halt einfach falsch rum rein und der Sohn fängt dann übelst an zu heulen weil er sich so denkt so nein das war voll und genau so kann man sich das ungefähr vorstellen manchmal.
Ne. Da sind wir dann auch wieder bei Anforderungen. Das ist auch n spannendes Thema. Hat mir mal ne Folge zu gemacht, auf jeden Fall kannst du auch darauf mappen, dann ja definitiv, es ist sehr spannend sag ich mal wie der User, also wie verwendet der User am Ende dein System beziehungsweise dein dein Angebot, deine Lösung wo wir uns auch immer befinden, es ist aber wie du schon meintest so vielseitig was alles passieren kann.
Welche Kombinationen an Ereignissen zusammenkommen können, damit irgendein Ereignis ausgelöst wird, das sind ja Sachen, die kannst du einfach nicht mehr im Blick haben irgendwo. Und dann ist es eigentlich das Wichtigste. Nicht nur eigentlich streicht das eigentlich, es ist das Wichtigste. Zu erkennen, dass etwas passiert ist.
Und dann noch wichtiger, deswegen möchte ich da heute den Fokus ein bisschen auf Monitoring packen, weil es ist ein wichtiger Punkt, aber noch mehr auf observility Oh mein Gott, Knoten in der Zunge, weil es noch viel wichtiger ist zu sagen, warum ist es passiert, das ist der entscheidende Punkt, warum damit man es beim nächsten Mal verhindern kann. Es hilft ja nicht nur jedes Mal zu erkennen, ah, es ist schon wieder passiert. Es ist schon wieder passiert.
Oh, es ist schon wieder passiert, nein, sondern es abstellen zu können und deswegen ist das warum sehr wichtig und weil das aber so n riesen Feld ist, möchte ich hier noch mal anmerken und ich finde das ist auch nur fair, es wird keine Deep Dive Folge, das geht nicht, dafür ist das jetzt zu riesig das Feld deswegen würde ich sagen Fabi lass uns mal heute n Überblick geben und gegebenenfalls falls auch die
Nachfrage kommt. Immer gerne schreibt uns können wir dann in weiteren Folgen der Def Ops Reihe noch gezielter auf Teilbereiche eingehen, sonst wird es den Rahmen sprengen. Das nur mal so als Disclaimer am Anfang. Genau, wir machen ne Überblicksfolge ungefähr über 2 Stunden, weil wir gerne reden. Es gibt ne 5 Stunden Einführung jetzt und dann noch mal 10 Stunden deepdive.
Ja, genau, nee, aber ich find es einfach so lustig so, weil wir sitzen ja manchmal vor so einer Folge und sagen, komm, lass uns das Thema mal jetzt nicht zu lange in die Länge ziehen, so und dann hinterher och guck mal, war doch wieder n bisschen länger na gut, also starten wir auf jeden Fall mal rein und gucken uns mal an, was ist eigentlich Monitoring, also Monitoring heißt ja auf Deutsch, wenn man es jetzt mal genau wissen will, Überwachung so genau, aber es geht ja in erster
Linie beim Monitoring darum, du hattest es ja eben eigentlich schon gesagt, dass man guckt. Dass etwas nicht stimmt, also einfach nur du hast irgendwas und es stimmt irgendwas nicht. Also wenn du es jetzt zum Beispiel als kleine Analogie hast, du, wenn du zum Beispiel im Auto fährst und irgendeine Kontrollleuchte leuchtet auf, dann weißt du etwas stimmt nicht, aber die genaue Diagnose dahinter kennst du noch nicht, du weißt nicht, was genau, also selbst wenn du ins Handbuch
guckst, wirst du sehen. Ja, OK, es könnte jetzt entweder das sein oder das oder das, man weiß es nicht genau. Ne, also du weißt quasi es wurde überwacht, dass etwas von der Norm abweicht, könnte man zum Beispiel sagen. Ne, also du hast halt einfach n Ereignis, was nicht normal ist. Wie du so schön gesagt hattest. Und da find ich ne Kontrollleuchte ist halt so n super geiles Beispiel weil. Es ist nicht, es entspricht nicht mehr dem Normalzustand.
Es ist gerade ein Ereignis aufgetreten und das wird dir angezeigt. Am Ende gehen wir mal vom technischen Weg, das im Prinzip Monitoring hast du auch in ganz allgemeinen alltäglichen Sachen. Gehen wir zum Beispiel mal in den medizinischen Bereich, du fühlst dich nicht, sowohl irgendwas stimmt nicht, ne dein Körper signalisiert dir so gesehen auch hier stimmt irgendwas nicht und mal
angenommen du misst. Fieber einfach so n Fieberthermometer und dann kriegst du als Monitoring wert, der sagt erhöhte Temperatur so das ist das Ereignis, es ist was passiert sozusagen du hast ne erhöhte Temperatur, du weißt aber nicht woran das liegt, also der Arzt kann zu diesem Zeitpunkt auch nicht sagen woran das liegt, also selbst wenn du jetzt quasi das beim Arzt messen lässt wird er sagen Hey.
Sie haben ne erhöhte Temperatur. Ja OK, aber warum warum ist ja das Entscheidende, aber Monitoring geht halt sag ich mal nur in Anführungszeichen. Es ist schon unglaublich wertvoll, aber nur soweit zu sagen es ist was passiert und ich sag dir was passiert ist. Du hast ne erhöhte Temperatur oder keine Ahnung, die Ölkontrollleuchte ist angegangen. Genau. Also wenn wir jetzt noch mal. Wieder zurück sozusagen den Bogen schließen zur Technik, sage ich jetzt mal.
Dann kannst du halt über Monitoring sehen, dass beispielsweise deine CPU Auslastung sehr hoch ist, dass dein Speicherverbrauch, sage ich mal gerade piekt oder dass du einen sehr sehr starken Netzwerk Traffic hast, deine Antwortzeiten vom Server auf einmal in die Höhe schießen oder solche Dinge, und das sind halt. Mögliche Sachen, die du überwachen kannst, wo du gucken kannst. OK, halt stopp, irgendwas funktioniert hier gerade nicht
so richtig, ne? Genau das sind nämlich, das ist nämlich schon der erste Punkt, das sind im Prinzip Metriken, die du verwenden kannst, um sowas festzustellen, genau ja, also die Körpertemperatur wäre ja auch zum Beispiel eine. Jetzt hast du gesagt CPU Auslastung im technischen Bereich, Speicherverbrauch, das sind ja alles Metriken anhand du. Festmachen kannst, was ist normal und was ist nicht normal. Sozusagen. Das ist halt ein wichtiger Punkt.
Also beim Monitoring verwendet man halt oft solche Metriken, um überhaupt so Ereignisse erkennen zu können, also gehen wir mal. Noch einnehmen wir noch mal ein anderes Beispiel, zum Beispiel Du hast ein E Commerce System und. Du kündigst jetzt n großes Sale Event an 30% heute und den nächsten 24 Stunden und dein Monitoring zeigt eben Moment mal in diesem Sale, den wir gerade laufen haben, steigen unsere Antwortzeiten oder unser Traffic steigt extrem an und.
Das zeigt ja einfach, dass quasi dieser Sale angenommen wird und die Leute drauf einsteigen und dass man quasi beobachten kann, oder was heißt beobachten? Nee, aber man sieht einfach, es passiert mehr und daraus könnte man ja auch dann Reaktionen ableiten, zum Beispiel zu sagen, Hey, Pass auf, da müssen wir jetzt meinetwegen unsere Server hochskalieren oder so, weil wir erkennen gerade, was los ist. So nur mal jetzt rein den Punkt zu sagen. Das ist gerade der Zustand.
Genau interessant an der ganzen Geschichte ist ja natürlich also du, du kriegst es ja irgendwie mit, also irgendwie wie du gerade meintest, ne du dein Monitoring sagt erhöhte Antwortzeiten die interessante Sache an der ganzen Geschichte ist ja, wie kriegst du das zum Beispiel mit, weil du könntest dich ja jetzt zum Beispiel hinstellen und sagen, ja, ich habe jetzt irgendwo, muss ich mich irgendwo.
Muss ich mich irgendwo drauf schalten und muss in irgendeinem System nachgucken, wo jetzt was, ob jetzt zum Beispiel irgendwie was nicht stimmt oder so ne so und dann machst du das vielleicht so einmal am Tag, guckst da manuell drauf und siehst ja OK irgendwas stimmt nicht, hast aber zum Beispiel sagen wir mal du guckst 16:00 Uhr drauf, hast aber schon seit um 08:00 Uhr, also seit 8 Stunden irgendein Problem, was du dann nicht mitkriegst, das heißt an der Stelle vom
Monitoring ist es natürlich auch unglaublich wichtig zu vermerken und. Dass man nicht einfach, also dass man ne Art System dahinter braucht, wie zum Beispiel diese Information an zum Beispiel das Entwicklerteam getragen wird, ne, also als Beispiel können. Also wir hatten das zum Beispiel, ich hatte das Mal in einem Projekt so, dass immer, wenn wir hatten, das dann quasi so eingestellt, dass angenommen,
du hast zum Beispiel ne erhöhte. Wie sagt man erhöhtes Vorkommen von 5 hundertern ne, also Server Internal Server Error nennt sich das Ganze in einem Backend und und da sind 5 hunderter Fehler geflogen ne so also als Antwort sozusagen vom Front vom Backend zum Frontend. So und dann hatten wir ne gewisse n gewissen Thresh Hold also n Schwellenwert festgelegt
und gesagt OK ab diesem. Schwellenwert ist es wohl ne komische Anomalie und dann wird quasi eine Nachricht an unseren Messenger, die unser Team verwendet, gesendet und dann?
Hat hatte man das, man kennt es, man verwendet in der im Alltag irgendein Messenger um sich halt auch mit dem Team auszutauschen und da gab es halt n dedizierten Channel der dann halt eben ne Nachricht bekommen hat wo dann drin stand Ey pass mal auf hier das und das ist gerade passiert, war aber nur wie gesagt irgendeine Art von Metrik, das heißt du wusstest irgendwas stimmt nicht aber du wusstest noch nicht genau was stimmt nicht ne. Ja, das ist n ganz ganz
interessanter Punkt, weil das ist auch so ne Kategorie. Die ja schon in Richtung von Alerts gehen. Also dass du alarme verwendest um quasi dann auch drauf
aufmerksam gemacht zu werden. Ne, also so die Metriken, die wir eben besprochen haben, sind ja Sachen, die guckt man sich an wie du ja schon meintest, da muss ich ja quasi mich irgendwo einwählen, also einloggen und mir das anschauen, zum Beispiel so ne Alerts wie du sie gerade beschrieben hast, weil das würde ich jetzt mal so klassifizieren, sind ja dafür da zu sagen ey. Wir haben irgendein kritisches Ereignis und ihr müsst sofort
darauf hingewiesen werden. Ja, und das muss also da geht es dann wirklich um Schnelligkeit, auch weil es scheint kritisch zu sein, da gibt es aber diesen einen Punkt und deswegen finde ich das mit dem Threshold was du meinst interessant. Es gibt nämlich diesen Begriff der Alarmmüdigkeit und der kickt da denn halt auch rein, wenn du sagst ey wir filtern das gar nicht oder es gibt kein Threshold n 5 Hunderter Error, der wird sofort alarmiert. Na. So, und jetzt weißt du aber, OK, pass auf.
Es gibt aber so ne gewisse so n gewisses Rauschen, dass das einfach passiert und dann hast du die ganze Zeit irgendwelche Alarme die da reinkommen und dann wirst du so gesagt so gesehen müde diesen Alarm gegenüber und gibst denen quasi keine Bedeutung mehr. Also das Desensibilisiert und das ist halt sehr gefährlich und deswegen müssen so Alarme auch wirklich gezielt eingesetzt werden und nicht in.
Übertriebenem Maße sag ich mal. Also du kannst dich nicht hinstellen und sagen, Ah, na ja, aber das könnte ja auch wichtig sein. Ah, das Alarmier ich lieber mal. Ah, das meld ich mal lieber so nach dem Motto, da muss man halt aufpassen und deswegen gutes Beispiel von dir zu sagen OK nee ihr habt gesagt, OK da muss es n Threshold geben, alles andere ist betrachten wir als Rauschen sag ich mal.
Ich find das aber auch interessant, da kann ich auch noch mal kurz was zu sagen, weil ich da hatte ich mich auch mal mit einem ehemaligen Kollegen unterhalten und. Es war auf jeden Fall super interessant, weil wir hatten auch bestimmte Alarme, die wir hatten. Ne, also so oder Alerts, die dann in den Channel kamen und die Frage ist dann aber auch weil wir hatten teilweise echt auch viele, also es kommt ungefähr hin was du hattest.
Also was du gerade gesagt hast ne erstmal das der erste Effekt war, dass sich erstmal ne Zeit lang auch oder manchmal gab es so Momente wo sich keiner verantwortlich gefühlt hat. Dann haben wir irgendwann. Gesagt, OK ist schwierig, es gibt. Quasi Hauptverantwortlichen in der und der Woche oder so, der sich das sozusagen der sich dem
annimmt. Ne wenn irgendwas ist um dann halt sozusagen im im Side Hustle, da sozusagen noch so n bisschen sich darum zu kümmern und zu checken was da los ist. Und das interessante fand ich aber wenn du Alarme schmeißt. Dann bist du vielleicht nicht gerade in einem Team unterwegs, wo du sagst, okay, du musst dich jetzt sofort darum kümmern.
Es geht noch alles, aber das Gedankenexperiment mal zu machen, um zu sagen, stell dir mal vor, ein Alarm kommt an einem Samstag so, weil Leute an einem Samstag damit arbeiten, wie. Hoch. Würdest du diesen Alarm einschätzen? Wie kritisch würdest du das einschätzen? Möchtest du als Entwickler oder Entwicklerin Samstag?
Nacht oder früh oder wann auch immer aus dem Bett gerissen werden, weil du jetzt dran bist und on Call quasi das fixen möchtest, ist es ist dieser Alarm so unglaublich wichtig, dass der jetzt fliegen muss. Und dieses Gedankenexperiment, finde ich, war wirklich sehr, sehr interessant. Es muss ja nicht immer so sein, aber denkt doch mal darüber nach, was du mitteilst, deinem Team sozusagen aus dieser Automatisierung heraus, was nicht stimmt.
Und das ist genau der Punkt, dass man halt nicht in diese Müdigkeit reinkommt und alle irgendwie sich denken am Ende ja, Alarm, OK, ich bin dran, aber so what ne, also dieses Gedankenexperiment was du meintest ist halt genau der richtige Weg zu sagen ist es so kritisch, dass wir jetzt n Alarm rausgeben müssen dafür und dafür sind diese Mechanismen super, aber müssen halt auch wirklich verantwortungsvoll eingesetzt
werden, sag ich mal. Und ich mach es mir noch so bei sorry, was mir bei Monitoring noch gerade so n bisschen fehlt. Wir haben ja gesagt OK, Metriken anschauen, mal reinschauen was so los ist. Ne, dass du so aktiv reinschaust alarme, da haben wir jetzt so einen Punkt noch nicht besprochen und den finde ich später im zweiten Teil, wenn es so über das warum geht wichtiger, aber ich würd mich hier schon mal anreißen, weil es bei Monitoring auch mit
Reinspielt und zwar. Dass es Logs gibt, die man sich anguckt. Und es kann ja sein, dass jemand jetzt mit dem Begriff Log oder Logs noch nicht so richtig vertraut ist. Deswegen lass uns mal ganz kurz definieren, was Logs eigentlich sind und im Prinzip kann man sich das so vorstellen. Dein System hat ja verschiedene Eingaben, ausgaben, Aktivitäten sag ich mal.
Und Logs haben die Aufgabe das ganze chronologisch aufzuzeichnen, also der Ereignisse und der Aktion innerhalb deines Systems. Das kann jetzt Teilsysteme sein, je nachdem auf welcher Ebene diese Logs aufgezeichnet werden, aber grundsätzlich haben sie immer die gleiche Aufgabe und zwar dir chronologisch das ganze aufzuzeichnen, das heißt?
Kleines Beispiel, jemand verwendet so ne so ne Desktop application von dir und du hast n log dafür, dann siehst du halt OK er hat sie um Zeitpunkt X gestartet, hat dann zum Beispiel ne Datei da drin geöffnet oder irgendwas bearbeitet und du siehst genau wann er was gemacht hat. Wenn die Logs gut sind. Und siehst halt auch, wann die Session sozusagen beendet ist und würdest dann da drin sehen.
Zum Beispiel ein Log, der sagt, in der Mitte der Dauer, die ja quasi die Software verwendet hat, ist auf einmal ein Error Log da drin, da ist was passiert und schon kannst du anhand des Logs erkennen Monitoring, oh da ist was passiert. Genau. Und ich sehe, was passiert ist, nicht warum das. Da kommen wir gleich zu, aber ich sehe. An der Stelle zu der Uhrzeit, als er das gemacht hat, ist das passiert.
Genau genau also wie gesagt sehr wichtiger Punkt bei Logs ist auf jeden Fall logischerweise der Timestamp, damit man auch weiß wann das passiert ist. Genau und chronologisch wichtiger Punkt und genau dieses diese, diese diese Alarmierung dann auch die Frage, was schreibt man in die Logs das
sind. Sehr, sehr wichtige Dinge, weil du kannst dich natürlich hinstellen, sagen, ich alarmiere in jedem Fall sofort bei jedem Error, du kannst dich hinstellen, sagen, ich logge jeden, ich nenne es jetzt mal wirklich scheiß so, aber am Ende bringt dir das nicht wirklich viel, weil du dann eben diese, dieses, diese Alarmmüdigkeit vielleicht bei den Alerts hast und gleichzeitig dir die Loks so voll müllst, dass du am Ende dich selber behindert dadurch.
Ne, das heißt, das ist auf jeden Fall n sehr sehr wichtiger Punkt auch. Vielleicht ist es einigen total klar, anderen ist es vielleicht überhaupt nicht klar, dass es einfach NN wichtiger Punkt an dieser Stelle ist. Wann macht man was und was lockt man und so weiter. Und das ist keine einfache Sache. Genau also muss man ja sagen, das ist ja wirklich auch ne übungssache, n gutes Logging umzusetzen. Wie du schon meinst, du kannst nicht alles loggen.
Du kannst nicht zu wenig loggen, du musst halt im Prinzip dir überlegen, was brauch ich später um Detektiv spielen zu können und rauszufinden was passiert ist, wieviel Logs brauch ich, was ist wichtig an der Stelle. Ganz genau. Aber bevor wir ganz kurz bevor wir zum Beispiel zur Observability vielleicht gleich mal übergehen, ne, würde ich gern noch mal in so ne kleinen n kleinen Side Note noch mal anbringen, sag ich jetzt mal was. Ja, sehr gerne. Monitoring an sich kannst du für
sage ich mal. Das Entwicklerteam kannst du, solltest du es wichtig brauchst du eigentlich und gleichzeitig ist die Frage und ich finde das gehört für mich in Monitoring mit rein. Wie transparent ist deine Anwendung auch gegenüber den Usern, also gerade auch wenn du jetzt beispielsweise noch mal von diesem, von diesem
Gedankenexperiment ausgehst. Du möchtest ja nicht am Samstag sozusagen belästigt werden im optimalen Fall oder am Sonntag mit irgendwelchen Aufgaben. So, und jetzt stell dir vor, du benutzt als User eine Anwendung und irgendwas funktioniert nicht so richtig und. Du hast aber und und und. Die User denken sich so hä, das funktioniert nicht. Ich will aber die Anwendung gerade benutzen.
Ich schreib jetzt mal ne support Mail, ich ruf da an, die Telefone klingeln, die Postfächer laufen voll weil ist ne riesen Anwendung 1000 Leute haben mit diesem Problem zu tun so und die wissen aber nicht was los ist. Und wenn du jetzt aber sagst OK ich habe ich schaffe eine hohe Transparenz gegenüber auch dem User.
Ne, dann kannst du ja zum Beispiel so eine Art Statuspage machen, auf die die User drauf gucken können und sagen können, warte mal, irgendwas funktioniert nicht, guck erstmal auf die Statuspage bevor ich mich jetzt zum Beispiel wirklich irgendwie bei den entsprechenden Verantwortlichen nenn ich es jetzt mal melde ne so und dann siehst du vielleicht zum Beispiel okay du hast zum Beispiel weiß nicht 10 grüne Lampen und eine ist aber gelb oder rot.
Ne, und da steht dann zum Beispiel daneben, ja System XY ist aber gerade in Wartung für 2 Stunden. Bitte gehen Sie davon aus, dass jetzt vielleicht in dieser Zeit irgendwas eingeschränkte Nutzung ist. So und in diesem Fall hast du direkt den Effekt, dass wahrscheinlich die meisten User, wenn du das denn auch so etabliert hast und die wissen, dass es sowas gibt, so ne statuspage ne, hast du den Effekt, dass die Leute dich damit nicht behelligen? Und sagen, Ah OK, in 2 Stunden
geht es wieder. Passt schon. So ne, das ist auch ne wichtige Sache. Das ist auch ne super geile practice auch so Statuspages zu haben. Bekanntes Beispiel von einem guten und großen Unternehmen wir ja zum Beispiel die Github statuspage genau so so in die Richtung meintest du das ja, also kann ja jeder sich mal anschauen wenn man die nicht kennt, das ist einfach wirklich ne sehr gute Hilfe zur Selbsthilfe am Anfang und erspart dir halt. Mails und Anrufe ja sehr, sehr guter Punkt.
Auf jeden Fall. Also dann würde ich sagen, haben wir eigentlich über das Monitoring so jetzt im Allgemeinen ganz gut drüber gesprochen und man kann sich was drunter vorstellen und weiß auch wie das ganze grob umzusetzen ist. Wir wollten ja wie gesagt das sehr allgemein erstmal machen, aber dann sagt oder erklär doch mal warum es beim Monitoring nicht bleibt, also warum reicht es nicht aus zu sagen. Ich habe doch erkannt, dass was passiert ist. Ja genau, also Monitoring.
Wie gesagt, Wir hatten das ja schon mal so ein bisschen gesagt, Monitoring ist ja die ist ist, da geht es ja darum, du siehst das, was nicht stimmt, so du hast eine Motorkontrollleuchte, die dir sagt, Ey, dein Auto läuft gerade nicht rund, aber du weißt nicht genau was und observability geht jetzt sozusagen ein bisschen weiter und sagt, warum stimmt denn irgendetwas nicht, weißt du also, dass du nicht nur sagst okay, was stimmt nicht, sondern warum?
Was ist die Ursache dahinter? Und wenn du jetzt zum Beispiel bei gerade beim Auto diese Motorkontrollleuchte die Analogie weiter treibst, dann fährst du mit deinem Wagen in die Werkstatt beispielsweise und dann kannst du halt in der Werkstatt zum Beispiel dir angucken okay, du hast vielleicht eine Metrik, du hast Logs im im Fehlerspeicher wo du nachgucken kannst was da los ist.
Du hast vielleicht irgendwie, sagen wir mal traces, die dir dabei helfen nachzuverfolgen, warum das denn auftritt, dass du zum Beispiel Verkettungen von Ereignissen siehst, zum Beispiel keine Ahnung, das Öl ist niedrig, der Motor überhitzt und deswegen keine Ahnung, ne hast jetzt einen Motorschaden, solche Sachen ne und dann hast du im Endeffekt, und das sind jetzt würde ich jetzt mal schon mal anschneiden, die. 3 Säulen sozusagen der Observability, die aber auch zusammengehören.
Ne, also du hast diese Metriken, die du brauchst, damit du weißt, OK, was ist da überhaupt los, dann geht es weiter mit du hast deine Logs, die dir chronologisch erschließen sozusagen oder dir zeigen, OK dann und dann ist das und das aufgetreten und du hast deine Traces, die dir ne gewisse. Plausibilität geben welches Ereignis trifft auf welches ein?
Da können wir ja auch noch mal n bisschen genauer drauf eingehen und mit diesen 3 Dingen zusammen kannst du, wie du es vorhin so schön genannt hast, Detektiv spielen und dann herausfinden, warum ist es denn passiert, genau ja. Das ist ja auch, weil wir das Beispiel hatten. Ich hab jetzt Fieber, also ich hab jetzt Fieberthermometer genommen und ne erhöhte Temperatur, dann geht es ja genauso los zu ergründen warum hab ich das und dann hab ich ja
auch verschiedene Möglichkeiten. Also ich will jetzt nicht irgendeine ne Diagnose stellen, aber keine Ahnung was würde man so machen. Dann macht man vielleicht NEKGN. Blutbild ist so n klassisches Beispiel n Blutbild ist ja am Ende auch nichts anderes, als dass du nachher Werte hast und Metriken und sagst, das sind Normalwerte und hier sind haben wir Ausreißer beispielsweise oder Logs.
Wenn du so NEKG Aufzeichnest ist so gesehen auch ne Art Lock am Ende. Ne du hast halt Werte über n zeitlichen Verlauf. Und so weiter und mit allen Untersuchungen kommst du ja am Ende hoffentlich dann zu dem Punkt, warum ist es so und was können wir jetzt dagegen tun?
Und das ist ja das Entscheidende, weil wir eingangs meinten, es hilft ja nicht zu sagen, es ist passiert, es ist wieder passiert und es ist schon wieder passiert, wow, ich kann dir jedes Mal sagen, wann es passiert, die wichtige Info ist ja, warum passiert ist und wie können wir dafür sorgen, dass es nicht wieder passiert und. Ich find es halt schön die 3 Säulen das zu nennen. Muss man an der Stelle aber sagen, das haben wir auch einfach mal gelesen und fanden
diese Analogie so gut. Ne, also nicht die Props jetzt hier komplett an uns, sofern muss man sein, aber es ist einfach sinnbildlich die 3 Balken geil die 3 Balken es sind die 3 Balken, es ist halt einfach sinnbildlich so geil zu sagen OK wir haben 3 Säulen und darauf. Basiert das ganze oder steht das Ganze?
Weil wenn du eine Säule davon wegnimmst, dann wird das Ganze nicht halten und in sich zusammenbrechen und deswegen ist diese Analogie so gut da drin, weil wie du schon meintest, es gibt logs, es gibt Metriken, es gibt traces OK, aber es reicht nicht zu sagen, Hey wir machen nur traces. Hey, wir haben Logs, das reicht. So funktioniert das nicht, dann bricht dir das Kartenhaus sozusagen zusammen.
Du musst halt ne Kombination aus allen nehmen um dann ne gute Überwachung umsetzen zu können und beobachtbarkeit unbeobachtbarkeit genau, ja jetzt hab ich es falsch übersetzt. Oh mein Gott, lass mal von vorne anfangen. OK, aber dann lass uns noch mal jetzt explizit auf diese 3 Säulen eingehen.
Also Logs haben wir ja schon besprochen, deswegen meinte ich ja, lass später dann noch mal drauf eingehen, das ist jetzt quasi wir haben erklärt was Logs sind und es ist im Prinzip genau das gleiche wie bei Monitoring. Ja Logs haben gewissen Aufbau sag ich mal oder n Sinn ne jetzt gibt es aber unterschiedliche Arten von Logs. Darüber würde ich ganz kurz mal sprechen, weil ich ja vorhin meinte immer, es ist die Frage, ob es fürs Teilsystem ist, fürs gesamte System, für deine
Applikation, wie auch immer, Logs haben immer den gleichen Sinn, am Ende, können aber nen anderen Scope haben sozusagen. Das heißt du hast halt zum Beispiel Application Logs, die so für die gesamte Applikation Logs ergeben und dann halt auch auf dem Level sich bewegen, das heißt da könnte man oder sagen wir mal System logs noch allgemeiner ne wenn du jetzt
dein ganzes. Dass das System aus mehreren Applikationen besteht, fangen wir mal ganz oben an und dann siehst du einfach zum Zeitpunkt x keine Ahnung.
Um 11:00 Uhr ist ein Error aufgetreten, dann kriegst du die ersten Hinweise und sagst okay warte mal das ist hier aber in Applikation ABC, dann schaue ich doch da mal in den Log rein und so gräbst du dich quasi immer tiefer rein und kommst halt irgendwann hoffentlich zu dem Punkt allein über Logs zu sagen, ich weiß wo etwas passiert ist und an welcher Stelle. Das ist quasi jetzt wieder so n Stück weit Monitoring, aber es hilft dir einfach schon mal das warum zu ergründen.
Weißt du, dass du in deinem Gesamtsystem verstehst? Was ist hier gerade passiert oder n anderer Punkt, weil wir auch bei Sicherheits relevanten Sachen waren oder kritischen Sachen? Es gibt ja auch sogenannte Audit Logs. Oder auch Sicherheitslogs genannt, die dann halt wirklich noch mal so eine spezielle Art von Logs sind, die wirklich nur sicherheitsrelevante Ereignisse und Aktionen innerhalb deines Systems aufzeichnen.
Also die sind dann halt wirklich essentiell, wird hier halt irgendein Mist gerade mit meinem System getrieben, sehe ich das hoffentlich in diesen Logs halt ne. Ja genau. Also das ist auf jeden Fall auch
wichtig. Diese diese verschiedenen Arten von Logs auch noch mal zu benennen, weil es im Endeffekt ist was, was halt wirklich wichtig ist, ist ja die Frage auch, wie, also was schreib ich in die einzelnen Logs rein, dafür ist man ja selber rein theoretisch zuständig ne zu zu definieren was in den Logs steht.
Um halt eben sich, wie du meintest zum Beispiel von von oben nach unten, vom vom Allgemeinen zum speziellen Durchzugraben um zu sagen, OK, was ist denn jetzt, wo ist denn jetzt genau das Problem und je schneller man das hinbekommt, desto besser sind eigentlich auch die Logs und die die Praktik dahinter, ne also. Wenn du jetzt zum Beispiel 3 Stunden brauchst, um zu finden, was eigentlich genau das Problem ist, dann sind die Logs wahrscheinlich relativ schlecht.
Sag ich jetzt mal oder definitiv nicht optimal. Wenn du aber in kürzester Zeit in diesen Logs zumindest an die an die Stelle kommst zu sagen, was ist denn hier genau das Problem, dann bis dann, dann sind die halt gut ne, also wenn du irgendwann zum Beispiel weißt, ey, der User kann sich nicht authentifizieren, dann. Dann weißt du ja zumindest OK, warte mal ich, ich bin jetzt an einem Punkt wo ich weiß, OK es könnte zum Beispiel an dem Endpunkt liegen, dass da
irgendwas schief geht. Es könnte sein, dass jemand falsche Daten mit Absicht geschickt hat, ne, also das ist ja zum Beispiel ne Sache, das wäre beispielsweise ne Sache, über die sollte man sich vielleicht, über die sollte man nicht unbedingt alarmieren, in erster Linie, weil das ist halt einfach Schabernack von außen. Der getrieben werden kann.
Es kann natürlich auch eine Art von ein Hackingversuch sein, aber was ich meine ist, ist, dass du natürlich rein theoretisch über Calls von außen mit falschen Inputdaten oder was auch immer, wenn du es drauf anlegst, es schaffen kannst, dass du zum Beispiel 5 Hunderter, also Internal Server errors, zum Beispiel Triggerst ne so und deswegen das ist finde ich, ein ganz gutes Beispiel, dass du.
Du hast einen Log und dieser Log gibt dir irgendwie einen Hinweis darauf okay vielleicht könnte es jetzt irgendwie am Endpunkt liegen, aber vielleicht auch nicht mal gucken, da muss man dann noch ein bisschen weiter recherchieren, das ist halt sehr sehr wichtig und wenn man jetzt zum Beispiel sagt Okay angenommen, du hast noch eine Metrik dazu, die dir sagt, der Netzwerktraffic ist extrem hoch gerade.
Dann weißt du ja zum Beispiel, na OK, also es könnte natürlich sein, dass jetzt vielleicht zum Beispiel so eine Art wirklich ein großer Angriff gefahren wird. Das heißt, dein Server wird bombardiert, es sollen sehr viele Authentications sozusagen gleichzeitig passieren, dass vielleicht ein Authentication Server abschmiert, sag ich jetzt mal. Oder ist es einfach so, dass vielleicht noch ein anderes Problem gerade beherrscht, warum, warum das zum Beispiel jetzt auftritt, ne?
Genau. Und das ist halt auch schon ein gutes Beispiel, dass du sagst, okay, ich muss mir jetzt nicht, also ich kann nicht nur die Loks nehmen, sondern ich ziehe mir jetzt zum Beispiel auch Metriken wie beispielsweise die Auslastung, die du gerade genannt hattest, dazu, um einfach noch mehr zu verstehen, was in meinem System gerade los ist. Ich würde noch mal ganz kurz auf Logs noch ein Punkt eingehen, weil ich fand es gut, dass du gesagt hast, es ist immer die Frage, wie gut.
Gut sind meine Logs und wie schnell kann ich quasi da durch Navigieren, um zur entscheidenden Stelle zu kommen und da kann man ja sagen oder sollte man auch noch mal anmerken, dass da natürlich strukturierte Logs einfach sehr hilfreich sind. Wie auch immer die aufgebaut sind. Beispielsweise im JSON Format, damit man einfach wirklich besser analysieren kann.
Und dafür gibt es natürlich unfassbar viele Tools und auch sehr gute Tools, da möchte ich jetzt auch nicht drauf eingehen, aber die ja genau das einen Abnehmen und sagen Ey pass auf, wir bieten dir die Möglichkeit richtig gute strukturierte Logs zu erzeugen, damit man halt ne schnelle Analyse fahren kann. Ne das ist halt wirklich entscheidend, also wenn man sich jetzt sag ich mal selbst so n logger schreibt wenn man da Bock drauf hat. Gibt es auch Gründe, warum man
das machen kann oder sollte? Wie auch immer sollte man das im Hinterkopf behagen, also behalten, weil es wird ja zur Zeitpunkt kommen wo du in diese Logs guckst und dann Gnade dir Gott, wenn die echt schlecht umgesetzt sind und du gar nicht verstehst was eigentlich los war. Auch die Erfahrung hat man auch schon mal gesammelt, ist von
abzuraten, definitiv. Ja, ich meine, man lernt ja aber auch mit der Zeit und das ist ja auch genau das Wichtige, dass man vielleicht auch mal durch n gewissen Pain durchgeht, um dann zu sagen, Hey OK, ich hab was gelernt und dann die Erfahrung vielleicht auch einfach mal mit anderen Leuten zu teilen. Gute Sache. Genau. Außerdem schärft es ja die das Verständnis für gute Logs.
Richtig, richtig. Aber das das Schwierige, weil du gerade meintest so bei Tools. Es gibt diverse Tools auf jeden Fall und das ist immer die Frage in welchem Umfeld bewegt man sich gerade ne weil du wirst zum Beispiel kein Logging Tool von zum Beispiel einem Cloud Service nutzen wenn du auf einem anderen Cloud Service gerade unterwegs bist. Mal als Beispiel so also die Cover solche sagen ja nimm das und dann ist ist es aber gar nicht möglich, es ist Stack.
Abhängig dann am Ende auch ja. Weil wir jetzt schon die Metriken hatten. Lass dann noch mal so ein bisschen über Metriken sprechen. Ich fand, du hast schon ein ganz gutes Beispiel gebracht, fallen dir denn noch mehr Beispiele ein, wo du sagst okay Logs reichen nicht aus, ich muss mir da einfach die Metriken noch dazu angucken oder was wären so Metriken noch mal um das noch mal festzuhalten für dich die entscheidend und essentiell sind am Ende. Also was auf jeden Fall finde ich wichtig.
Als Metriken sind sind zum zum Beispiel Antwortzeiten. Das ist zum Beispiel auch ne ne wichtige Sache um halt zu erkennen ob vielleicht irgendwie n Problem im System besteht. Also und, und da ist es halt auch wieder die Frage, wenn du hohe Antwortzeiten hast, woraus schließt sich das?
Hast du vielleicht gerade zu viele Nutzer, die gerade auf einem System arbeiten und das System die zugrundeliegende Rechenlast ist zu gering beispielsweise, das heißt du brauchst eigentlich eine größere Powervollere wie sagt man denn also eine Maschine mit leistungsfähiger genau mit mehr Power, eine leistungsfähigere Maschine oder vielleicht liegt auch. Auch das Bottlenegg irgendwo an einem Amt, Amt, sozusagen am Zugriff auf die Datenbank.
Dass du zum Beispiel sagst, Ey, meine Datenbank ist weg, genau, meine Datenbank hat zum Beispiel Bottlenegg, oder also es muss ja nicht immer nur rein die Konfiguration sein, es kann ja auch zum Beispiel sein, dass du die Verbindung zur Datenbank einfach nicht mehr abbaust, dass du programmatisch quasi aus versehen nen Fehler drin hast, wo du sagst, ey ich.
Bauen ne Verbindung zur Datenbank auf, aber die wird quasi nicht geschlossen und im Normalfall hast du eigentlich ne ne begrenzte Connectionanzahl die die du zu einer Datenbank aufbauen kannst. Solche Sachen sehr sehr wichtig um einfach. Also das meine ich Antwortzeiten ist ne wichtige Metrik, aber du weißt noch nicht genau was steckt jetzt dahinter ne also das ist zum Beispiel ne Sache wieviel Nutzer sind da gerade am Start? Ne wie hoch ist die Speicherauslastung, wie hoch ist
die? Cpu Auslastung, solche Sachen, das sind halt als sehr sehr wichtige Punkte um zu erkennen, also oder um Anreize zu haben um zu sagen wo könnte es denn überhaupt herkommen. Genau, weil das ist genau der Punkt, dass du am Ende sagen kannst, das sind alles so Puzzleteile. Ne, also du hast halt viele Metriken und auch bei Metriken gilt das gleiche wie bei Logs.
Du hast immer so n gewissen Scope ne, also du hast zum Beispiel systemweite Metriken, die sehr allgemeinen Einblick geben, dann natürlich auch wieder anwendungsspezifisch. Du kannst auch Custom Metriken haben, die einfach wirklich für dein System gerade entscheidend ist. Das das ist ja nicht so, dass du quasi so n Template hast und sagst, Hey das sind deine Metriken, nimm dir und das läuft, so wird es ja am Ende auch nicht sein, sondern du hast
ja auch. Sag ich mal anwendungsspezifische oder systemspezifische Metriken. Alles kein Thema, das ist so einfach, ja, aber wichtig ist, dass du deine Metriken, sag ich mal, werten kannst, deuten kannst und auch zusammen mit den Logs dann quasi in die richtige Richtung kommst, um zu verstehen was los ist. Wie du ja schon meintest, ich hab extrem erhöhte Antwortzeiten gerade. OK, warum?
Das ist eine Metrik, die anschlägt und abweicht von der Norm, dann guckst du zum Beispiel in die Logs, was da so passiert siehst hm OK, beim Datenbankzugriff zum Beispiel stimmt irgendwas nicht, siehst OK, ja da hab ich wirklich n bottle in der hast die nächste Metrik und so hangelst du dich quasi immer weiter und spielst Detektiv bis du.
Da hoffentlich ankommst, wo du siehst okay hier ist, liegt gerade unser Problem. Ich habe das warum gefunden, worum es ja dann bei dem Beobachten am Ende geht, ja. Ich meine, so blöd kann es ja nicht denken. Vielleicht hast du irgendwas implementiert, was einfach so Imperformant auf einmal ist, weil du das irgendwie gerade nicht auf dem Schirm hattest. Dass es daher zum Beispiel kommt, ne, also das ist halt genau das, ja. Was zum Beispiel bedingt ist einfach, was halt auch nur ab
und zu mal auftritt. Genau, und das ist halt und und da ist halt die Kunst, wirklich zu sagen, okay.
Wie baue ich das denn alles auf um am Ende wirklich relativ schnell wirklich zu diesem Punkt zu kommen weil wie gesagt metriken sagen dir geben dir eine grobe Richtung dann hast du logs die dir vielleicht nicht nur die grobe Richtung sondern auch noch punktuell sagen OK da ist es gerade da hat es zum Beispiel gerade geknallt oder so ne oder da ist ein Fehler geflogen was auch immer aber manchmal brauchst du halt sogar auch noch mehr? Wie zum Beispiel solche Traces.
Ne, das heißt, das ist ja so jetzt mal die dritte Säule, dass du halt wirklich verfolgen kannst, also sozusagen ne Art von Plausibilität erzeugst und sagst, ey, da ging irgendwas los, dann ging das nach da, dann haben wir sozusagen da ne Berechnung durchgeführt und dann ging es sozusagen weiter zur Datenbank oder was auch immer ne und. Ich find das hat gerade auch schon gezeigt.
Als wir jetzt so über diese Beispiele gesprochen haben, dass du dich halt so durchhangelst um die richtige Stelle zu finden, zeigt einfach, dass diese Säulen nicht unabhängig voneinander funktionieren können. Weil damit haben wir ja schon so indirekt angefangen, über Traces zu reden, dass du überhaupt in der Lage bist, dich durchzuhangeln von System zu System, gerade so in Zeiten von Riesen System und Verkettung an Micro Services. Du musst ja auch wissen.
Quasi von wonach, wo spring ich und wann bin ich überhaupt da, wo mein Problem liegt und er kann das warum ergründen und dafür sind traces halt unfassbar essentiell um einfach diesen Weg nachvollziehen zu können. Genau um mal n kleines Beispiel zu bringen, ne. Also wenn du jetzt zum Beispiel sagst gehen wir mal von einem von einem so einem Web Frontend aus ne und du sagst OK das Web Frontend feuert ne Abfrage an und die Abfrage also die die Anfrage ne. Dauert vielleicht 20 Millisekunden.
So und dann wird es quasi, kommt es vom die Anfrage kommt vom Web Frontend sozusagen als API Gateway beispielsweise und die leitet dann das API Gateway, leitet die Anfrage dann weiter ne dauert vielleicht 15 Millisekunden, das siehst du in deinem Trace dann genau ne oder kannst du sehen ne es kommt drauf an wie du es selbst sozusagen konfigurierst. Dein Tool oder selbst schreibst oder was auch immer ne wie gesagt aber. Da geht es dann weiter.
Das API Gateway leitet das dann zum Beispiel einen Authentifizierungsservice, weil wir vorhin schon über Authentifizierung gesprochen haben, und da werden dann die Userdaten geprüft. Dauert vielleicht, sagen wir mal 30 Millisekunden an der Stelle ne so und dann auf einmal kommt sozusagen die Datenbank query an. Also vom vom Authentifizierungsservice an die Datenbank und das dauert. Zum Beispiel siehst du im Trace 200 Millisekunden und denkst dir dann okay warum dauert es 200
Millisekunden? Normalerweise dauert es nicht 200 Millisekunden 200 Millisekunden ist echt lange so und dann kannst du dir ja rein theoretisch erschließen, dass im Endeffekt da das Bottle neck ist so. Genau, und das ist halt das Tracen, dass du das sehen kannst. Und diese Verkettung der. Der Ereignisse von von der Gesamthandlung nenn ich es mal ne, also du hast halt eine Interaktion und willst gucken was in deinem System jetzt, gerade wenn es so n verteiltes
System ist. Einzeln an den gewissen Stellen passiert und wann du quasi diesen Roundtrip gemacht hast und weißt, OK, das war jetzt einmal die Kette durch mein Gesamtsystem und kann gucken wo denn was passiert ist und in welcher Reihenfolge das abgearbeitet wurde, weil ich stell dir vor du hättest keine Traces und hättest jetzt nur Logs und du guckst erst mal ganz oben und siehst hat lange gedauert, OK. Hat lange gedauert, hat zu lange
gedauert, hat vielleicht n Timeout oder was auch immer und denkst dir OK, aber was passiert da drin? Und jetzt musst du quasi die Leistung erbringen, dir zu überlegen, was passiert jetzt alles also was für Teilsysteme werden jetzt angesteuert bis mein Hauptsystem im Log hat, Timeout zum Beispiel und dann hast du halt nicht diese Verkettung und musst in die einzelnen Logs durchsuchen bis du quasi irgendwie mal erschließen kannst durch Timestems in welcher Reihenfolge was passiert ist.
Und das ist halt die Hölle. Also da, da wirst du nicht mehr glücklich am Ende. Es ist einfach so und deswegen spielt das Halt finde ich alles so krass zusammen, dass es kein es ist kein da gibt es kein wenn oder aber das ist einfach, das muss einfach alles zusammen spielen.
Ja, auf auf jeden Fall. Es ist ja auch so, dass ich finde, das ist wichtig, auch noch finde ich, noch mal zu sagen, du. Du kannst je mehr, also sagen wir mal, je mehr oder je besser deine Logs sind, je besser deine Metriken sind, je besser deine Traces sind, sozusagen je besser deine vielleicht Tools sind, die du nutzt, je besser deine Tools konfiguriert sind, die du nutzt, was auch immer, ne sagen wir mal desto besser und schneller wirst du Dinge erkennen können und
nicht nur das warum also was ist aufgetreten, so auch warum ist es aufgetreten, aber am Ende. Wird immer noch so ein kleiner, eine kleine Detektivarbeit. Der die übrig. Bleiben, um zu sagen okay aber noch mal ganz kurz, was ist denn jetzt wirklich das Problem? Du musst am Ende trotzdem noch mal sagen okay woran liegt es denn jetzt? Also du kannst eine Menge Hilfe haben, je mehr Hilfe desto besser das. Versprach sich immer, weißt du doch genau, aber es ist halt ja im Prinzip, wenn du.
Also ich weiß genau was du meinst. Du wirst ja nie zu dem Punkt kommen zu sagen ich hab noch 100% Abdeckung. Ich weiß genau was passiert du es ist immer noch diese Arbeit drin die du reinstecken musst. Das sind ja im Endeffekt nur Hilfsmittel und Tools und Konzepte die dir helfen schnell das warum zu ergründen, damit du schnell das Problem beheben kannst. Das ist so mal ganz Basic gesagt das Ziel dahinter.
Weil Fakt ist auch je nach Anwendung was was hatten wir für Beispiele so NE Commerce System zum Beispiel da geht es am Ende um Geld, also wirklich um Einnahmen des Unternehmens wenn einfach Sachen langsam werden oder Leute sich auf einmal nicht mehr einloggen können, keine Bestellung abschließen können was auch immer, denn das Problem ist aber Fakt ist es ist unfassbar wichtig und essentiell so schnell wie möglich das Problem zu ergründen das warum zu kennen und das Ganze zu
beheben und darauf kommt es ja dann am Ende an. Definitiv. Und ich finde wie gesagt, je besser deine. Also du hast ja eine riesen Datenflut, die da auch auf dich einprasseln kann und je besser du an der Stelle sage ich jetzt mal filtern kannst im Vorfeld, also zum Beispiel auch in deinen Logs, in deinen Metriken, dass du sozusagen die wichtigsten Metriken vielleicht für dich herauskristallisiert, die Traces gut sind, dass du halt nicht da
auch. Dass du auch nicht zu viele hast, das nicht jeden Scheiß, sage ich jetzt mal mit Logs und so weiter oder mit Traste das ist wichtig und ich glaube, man kann vielleicht auch noch so einen kleinen Ausblick geben. Ich glaube gerade auch mit KI kann da vielleicht auch noch Tool mäßig noch ein bisschen mehr sage ich jetzt mal, Daten zusammenfassen und analysieren, so dass du dann was.
Wahrscheinlich noch schneller irgendwie zukünftig auf einen gewissen Nenner kommst, um zu sagen okay, da könnte das Problem liegen, aber wahrscheinlich es kommt immer auf die Komplexität der Anwendung darauf an, wird es eher selten zu dem Punkt kommen, dass man sich sagt, so okay, das Kriege ich sofort raus, das ist es zack so selbst mit KI, also dass du immer noch diesen diese diese gewisse Detektivarbeit am Ende hast. Vielleicht weniger, sehr
wahrscheinlich weniger. Ja, lass uns das Ganze noch mal kurz und knapp zusammenfassen. Das sind ja jetzt unfassbar viele Punkte, die wir trotz der Überblicksfolge quasi gegeben haben. Magst du schon mal so einen ersten Punkt geben in der Zusammenfassung? Was wäre so eine Take Home Message jetzt für dich? Also wichtig ist, Monitoring ist nicht observability, das muss
man klar auseinanderhalten. Monitoring ist das, was ist, irgendwie, was stimmt nicht und observability ist noch mal zu sagen, warum stimmt es nicht, was genau ist der Punkt welcher wo liegt die Ursache so ne. Ja, sehr gut. Das ist halt wirklich n Punkt, also muss ich sagen, am Anfang hab ich es auch immer n bisschen vermischt, aber es sind ist halt wirklich 2 paar Schuhe muss man einfach so sagen. Die ja trotzdem beide wichtig sind und beide ins System
gehören. Aber man kann sie halt nicht zusammenpacken. So ne, dann hatten wir über die 3 Säulen gesprochen, logs, Metriken und Traces bei Observability und. Man muss sagen, dass eine umfassende Strategie oder eine gute Strategie halt genau diese 3 Säulen beinhaltet, um halt Probleme effizient zu identifizieren und vor allen Dingen zu also ne Diagnose erstellen zu können am Ende um genau das warum zu ergründen und das wird halt, das hast du auch so schön gesagt, je komplexer
dein System ist. Und wir sind ja in einer Welt der Microservices, Cloud native Architekturen. Da wird es halt umso wichtiger, diese Strategie zu haben, um Fehler schnell in diesem Gesamtsystem finden zu können.
Genau. Und ich find vor allem ein Punkt dabei ist ja auch, es geht ja nicht nur um Fehler, noch mal angemerkt, sondern auch einfach wie du vorhin meintest, bottle next also Performance Optimierung ist ja genauso n Punkt dabei, es muss ja nicht immer das Kind im Brunnen gefallen sein, sondern einfach festzustellen EY, unter gewissen Umständen haben wir Performance Einbrüche warum und dann haben wir es wieder warum? Und das ist halt wichtig.
Einfach um also dev Ops oder der Operation Style ist ja auch dafür da, dass du wirklich ein Überblick wissen darüber hast, was passiert in deinem System. Genau das ist wichtig, nicht nur um Fehler zu erkennen wie du meintest. Das ist ein guter Punkt, dass du es noch mal angesprochen hast, sondern auch zu sagen, OK, wie agiert mein System eigentlich. Wie kann ich mein System optimieren?
Das ist halt auch wichtig, da also diese Lehren sozusagen daraus zu ziehen und ich finde, um es noch mal um um diese 3 Säulen noch mal zusammenzufassen, ich finde, die bauen für mich so ein bisschen, also wenn ich sozusagen an die Sache rangehe, ein bisschen aufeinander auf, ich glaube, ich würde mir erst mal mal Metriken angucken, das ist auch eigentlich das erste, was sozusagen dann als Alert oder wo
Alerts draus entstehen. Dann vielleicht auch noch aus Logging. Also Logging ist das nächste, also erstmal money, also Metriken sind das erste so da hast du erstmal einen groben Überblick, dann kannst du weitergehen in die Logs und dir sagen, OK was ist denn gerade wie in welcher Abfolge passiert, wo ist denn ein Error und dann hinterher vielleicht noch in die Traces zu gucken um wirklich noch mal zu sehen, OK was ist denn in in in der in der
Abfolgeverkettung genau und was man sagen muss ist, dass es natürlich. Super ist, dass je früher du den Fehler kennst, also angenommen du findest den Fehler, weißt schon direkt was ist der Fehler oder das Optimierungspotenzial anhand der Logs, ohne dass du in die Traces gucken musst.
Ist natürlich besser, je weniger du dich damit beschäftigen musst, je weniger Daten du ranziehen musst, desto besser ist es natürlich ne, das ist ja wie bei Tests beispielsweise je früher deine Tests failen, je früher du sozusagen einen Aufschuss darüber kriegst, was in deiner Software vielleicht jetzt. Von von den Tests her nicht läuft, desto besser wie früher. Desto besser kann man sich als
Analogie vorstellen. Du hast halt sehr viele Puzzleteile, aber wenn du die richtigen Guten am Anfang schon wählst, kannst du das Bild wahrscheinlich schon erkennen und das ist es am Ende ne, du musst es nicht fertig puzzeln um zu erkennen was drauf abgebildet ist, sondern es geht einfach nur darum schnellstmöglich das zu erkennen und da hast du natürlich absolut recht und ist auch n gutes Schlusswort. Deswegen würde ich sagen, lass uns die Folge an der Stelle
beenden. Also vielen Dank fabi, Ich liebe es mit dir über Def Ops zu reden, wir sind ja auch einfach Fans von dem Bereich und er ist nicht mehr wegzudenken und unserer Meinung nach sollte auch, selbst wenn man nicht mit Def Ops in Berührung ist, im Sinne vom vom Arbeiten her oder von dem womit man sich beschäftigt, sollte man guten
Überblick darüber haben. Es ist auf jeden Fall ein spannender Bereich, der auch zunehmend immer mehr Bedeutung bekommt und deswegen genau an dieser Stelle den Aufruf. Liebe Zuhörer, liebe Zuhörer, falls du Erfahrung damit hast, vielleicht Dinge anders siehst oder ergänzen möchtest, lass es uns bitte wissen. Wir lieben Feedback.
Schreib uns in den Shownotes findest du die e Mail Adresse oder auch unsere anderen Plattformen, du kannst dich auf jedem Kanal bei uns melden sehr sehr gerne würden wir uns freuen, wir hören gerne eure Meinung, deswegen haltet euch da
nicht zurück. Ansonsten, wenn dir die Folge gefallen hat oder die Def Ops Reihe, lass doch gerne ne Bewertung da like unseren Podcast abonniere ihn, gib ihnen ne Sterne Bewertung auf dem Provider deiner Wahl, das würde uns mega freuen und unterstützt unsere Arbeit enorm.
Genauso findest du den Shownotes einen kleinen Spenden Link falls du Lust hast uns auf diese Weise zu unterstützen, dann vielen vielen Dank schon mal im Namen uns von uns beiden und ansonsten Vergesst das Flappy Buddy Turnier nicht und. Ich wünsche euch ne geile Zeit euch allen, dir fahr wie dir, liebe Zuhörer, liebe Zuhörer und bis zum nächsten Mal deine Coding Buddies gemeinsam besser.