Latest / Coding Buddies | Tech & Dev-Mindset / DevOps #6 - Die 3 Säulen der Observability

Transcript

DevOps #6 - Die 3 Säulen der Observability · Coding Buddies | Tech & Dev-Mindset

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