Moin, hier ist einfach komplex mit euren Hosts Burkhard und
Gerrit und heute wieder mit einem Gast zum Thema
Observability der Heinrich Hartmann von Zalando.
Hallo Heinrich. Hallo Gerrit, vielen Dank für
die Einladung. Ich freue mich, hier bei euch zu
sein heute. Ja, schön, dass du da bist und
man darf es vielleicht sagen. Die Einladung ist entstanden
durch einen gemeinsamen Kollegen und Freund, den Cornelio, also
an dieser Stelle Grüße an Cornelio.
Grüß dich, cor von mir. Dann lass uns starten.
Also Observability soll das Thema sein, aber Heinrich,
erstmal magst Du dich kurz vorstellen, damit die Leute
wissen, mit wem sie es hier eigentlich zu tun haben heute.
Ja, sehr gerne. Ja.
Mein Name ist Heinrich, Ich bin Senior Principal Engineer bei
Zalando in der Infrastruktur, also, betreue quasi die die
gesamte Plattform für uns n bisschen mit und ja, ich bin
seit ungefähr 10 Jahren im Reliability Engineering und auf
diesem observability Thema unterwegs, also meine
weitreichende Vergangenheit ist aus der Mathematik, ich bin
gebürtiger Mainzer, hab dann auch in in Bonn studiert.
Und ne Promotion abgeschlossen und dann ja wie es vielen Leuten
dann auch in der Akademie ja so geht, irgendwann in die Software
abgebogen und ich bin bisschen bei diesen Grundlagenproblemen
hängen geblieben. Also ich hatte dann auch meinen
wordpress Blog und so meine ersten Python Web Apps, die ich
dann selber gestartet hab und dann so meine Güte das am Laufen
zu halten, dass My Sequel nicht immer abstürzt und sich dann von
meinen Usern irgendwie erzählt bekomme.
Ich kann mich hier für n Event nicht registrieren, das hatte
mich so n bisschen zu oft dann irgendwie geärgert.
Dass ich gedacht hab, so, das muss man mal richtig verstehen.
Und Na ja, sind wir 10 Jahre später, ich weiß nicht, ob ich
es richtig verstanden hab, aber auf jeden Fall hab ich das Thema
jetzt aus aus verschiedensten Ecken gesehen und auch relativ
viel da drüber erzählt oder mich damit beschäftigt.
Also ich war 5 Jahre dann Chief Data Scientist bei einer
Monitoring bendor hab da so n bisschen Anomalie Detection auf
Zeitserien gemacht. Und dann bei Zalando hab ich
zwischenzeitlich das Reliability Engineering geleitet als Head of
Engineering und genau guck halt jetzt wieder in einer
Engineeringrolle als ja so Architekt Slash, Principal
Engineer bei Zalando, über diese Reliability Fragen.
Super. Vielen dank Heinrich klingt
super spannend und ich bin echt gespannt gleich zu hören wie es
so läuft bei euch bei Zalando. Jetzt hast du gerade schon
gesagt, du warst mal tätig in einer Firma die Monitoring
gemacht hat und. N bisschen in meiner
Vorbereitung hab ich gesehen Monitoring oder oder anders
gesagt Observability ist irgendwo Monitoring, aber mehr
magst du vielleicht in dem in dem Kontext auch mal uns
observability erstmal zum Start erklären und definieren.
Ja, ist n sehr guter Einstieg, weil bei Observability wieso bei
so vielen Sachen in der IT gibt es total viele überschneidende
Definitionen, je nachdem mit wem du sprichst.
Und ich würde die Begriffe eigentlich sehr gerne sehr weit
fassen. Also so wie programmieren.
Im Prinzip ist Tell the Computer what to do sagt dem Computer was
ich, was er tun soll ist für mich obsibility genau das
Gegenteil davon. Also ich möchte verstehen, was
der Computer gerade tut und das ist tatsächlich ein erstaunlich
schweres Problem. Beim Auto kannst du einfach die
Motorhalber öffnen und siehst okay hier kriegst Geräusche die
dir entgegenkommen, du siehst irgendwie, da funktioniert
irgendwas nicht, da sollte was vibrieren oder so.
Unsere Rechner sind jetzt meistens in der Cloud, das
heißt, ich hör noch nicht mal die Festplatte irgendwie
rauschen, wenn Sie irgendwie Daten liest.
Also die Informationen, die man von von den Rechnern gesendet
bekommt, sind eigentlich per se erstmal sag mal sehr sehr wenige
und auch wenn man so aus einer Anwendersicht kommt, ich hab ja
früher auch auf Windows System viel Zeit verbracht, da war
immer so ne sehr große Barriere von OK ich hab das UI aber guck
da mal hinter was wie was macht der eigentlich, warum hängt das
Programm? Oder wie ist jetzt n Fehler ja
entstanden oder wo kommt der her oder was muss ich jetzt tun,
damit das aufhört? Und für mich ist so
Observability im Prinzip genau dieser Quest.
Du hast n Programm oder n System, das tut irgendwas jetzt
das mal n Nutzer oder wenn jetzt hier so n so n Operator oder
Incident Responder im Zweifel interessiert einen das am
meisten wenn irgendwas nicht klappt verstehen.
Was was macht das? Und das fängt bei ganz einfachen
Sachen an, die Debugging, also Logging wo ich so debuglogs in
meinem Code injiziere um zu verstehen, hey wann wird eine
gewisse Zeile irgendwie ausgeführt.
Das geht in in Debugging rein, wo man an den Postes quasi
attached und guckt hier speicherstellen Ausliest und
variablen Ausliest und probiert das rauszufinden und das geht
halt in diese so mal klassische so mal Enterprise Obsibility
rein, wo wir dann auch große Logging Systeme haben.
Das ist im Prinzip ja genau wieder dasselbe, die
Applikationen die die Spucken auch Log Dateien oder Loglines
aus, die werden zusammengefasst, aber eben auch andere Telemetrie
Typen und da ist vor allen Dingen.
Die Metriken relevant das sind Zeitserien, die aufgenommen
werden und eventdaten oder Tracingdaten.
Und da geht es einfach um um Events oder Interaktionen
zwischen verteilten Systemen, die zu speichern und so
zugänglich zu machen, dass man auch verteilte Systeme
analysieren kann. Und ja, je nachdem, welches
konkrete Problem man hat, da sind die Tools für Observability
natürlich sehr unterschiedlich. Also bei einem Hobbyprojekt, was
ich an der Seite mache in meinem Blog nutze ich auch einfach
Standard Outlogging der Prozess spuckt einfach Sachen aus, das
klappt. Aber aber was ganz kurz, was ich
aber trotzdem manuell dafür also im Code dafür sorgen muss oder
irgendwo in meiner Anwendung, dass das passiert, dass diese
Logs ausgespuckt werden, das ist ja kein, ist ja nicht
gottgegeben, oder dass dass Code solche Logs ausspuckt.
Ja, das stimmt. Also in aller Regel ist das OK
Print. Statement da gibt es noch n paar
Tricks, die man anwenden kann um das zu externalisieren wenn man
möchte, aber im wesentlichen ist es das und ja, an anderer Stelle
hat man vielleicht ressourcenproblem, wo man oft
irgendwie in Sachen reinläuft. Hey Speicherplatz läuft läuft
zu, ich hab irgendwie memory Probleme, da sind Metriken
klassischerweise einfach sehr gut um zu verstehen wie sind
Ressourcenauslastungen da und dann letztlich diese diese Event
und Tracing Daten, die sind dann wichtig wenn man verteilte
Systeme hat, also nicht 34 Anwendungen hat die mit
Miteinander sprechen und. Dann ist die Frage, wo genau
liegt denn der Fehler? Sehr schwer zu diagnostizieren,
wenn man einzeln auf die Anwendungen guckt und da helfen
diese Destibierte Tracing Tools. OK, ich hak noch mal nach
Metriken, das kann ich mir so vorstellen.
Da meinst du wahrscheinlich so Operating System Monitoring,
also so wieviel CPU Last hab ich gerade im Moment, wieviel
Displays hab ich noch frei? Und so weiter.
Also die ne die Last vom Rechner zum Beispiel sowas.
Also es hat ja jetzt nicht direkt was mit der Anwendung zu
tun, sondern mit dem Environment, in der die
Anwendung gerade eingebettet ist.
Wie geht es dem ne und das hat ja auch was damit zu tun, wie
hält sie meine, wie weit hält sie meine Anwendung ist Kurs,
was meinst du oder? Genau richtig also, wenn du
Hardtop aufmachst oder nen Systemtool, dann siehst du
einfach Metriken, die aufgezeichnet werden.
In der Kommandozeile sind die oft sehr recent mit einer hohen
Sampling Frequenz. Jede Sekunde wird n neuer
Datenpunkt aufgezeichnet, ne Metrik in einem Enterprise
Kontext wird halt über längere Zeithorizonte aufgezeichnet,
dann in der Regel NN kleineres Sampling Intervall hoff ich jede
Minute und Infrastrukturmetriken die wir gerade besprochen haben,
also einfach wie sind die CPUS ausgelastet, wieviel Speicher
hab ich frei sind so der. Red and Butter, so dieser Chor,
wo Metriken wirklich richtig gut sind und wo die auch
normalerweise anfangen. Es gibt natürlich auch
Application Matrix und da Klassiker ist zum Beispiel Cash
Sites oder irgendwelche Q Längen.
Es gibt viele Entwickler die dann auch sehr viel
feingranularere Metriken, rausschreiben teilweise
irgendwelche Counts von Events oder teilweise dann auch für
jeden Nutzer noch mal. Wie oft hat er denn diesen
Button geklickt? Das kann man natürlich als
Zeitserie modellieren, wo man dann quasi für jeden Nutzer
zählt. Na ja, wie oft wurde dann ne
gewisse Anfrage gemacht, aber dann kommt man genau in so nen
an so nen Punkt wo das kein kein gutes Datenformat mehr ist um
diese um diese Daten aufzunehmen.
Also Genetiken sollte man klassischerweise eher an Sachen
knüpfen die so statischen Ressourcencharakter haben.
Also lass uns das noch mal aufdröseln und und normal in ne
Box packen. Wir haben Observability
besprochen und du sagst besteht aus ist sehr weiter Begriff hab
ich verstanden. Besteht aus mehreren
Komponenten. Ich würd es mal von abstrakt
nach feiner versuchen durch zu deklinieren.
Du Schüttelst sofort den Kopf, wenn ich Quatsch erzähle, ich
hab verstanden, es gibt quasi die niedrigen, also es geht
erstmal um Software Punkt Software läuft auf Hardware, die
Hardware selber kann man observen Monitoren ob ihres
Gesundheitszustandes also zum Beispiel CPU Last Auslastung,
RAM Netzwerk Traffic der gerade ein und abgeht.
Das sind die, würde ich sagen, die außen die Hardware Metriken.
Dann hast du gesagt in der Applikation selber kann ich noch
mal spezielle Metriken haben, also ich während ich den
gesamten Rahmen eines Systems mir angucken kann, habe ich in
der Anwendung läuft ne Software Anwendung auch n bestimmten
Arbeitsspeicher den die für sich allokiert, so ist es
typischerweise. Wer das jetzt noch nicht gehört
hat und auch und das ist quasi auch erstmal unabhängig von dem
was ich da programmiert hab und ob ich Python genommen hab oder
Java Script oder Java und ob ich da irgendwelche logs rausfeuer
das ist was was ich. Grundsätzlich bei jeder Software
ist unterschiedlich in der Technologie, aber das kann ich
im Prinzip rausbekommen. Wie ist meine, oft ist das
Stichwort Heepsize so, ja wie ist die Größe, wie ist die
Allokation von meiner von meiner Anwendung, ja es kann wichtig
sein, denn es kann zum Beispiel sein, ich habe ein
Datenbankprozess in in meiner Programmiersprache und jetzt
Hallo, jetzt habe ich eine schlechte Anfrage und die
braucht zum Beispiel mehr als 4 Gigabyte in ihrem eigenen
Speicher, dann kann es sein, obwohl ich irgendwie 128
Gigabyte auf meinem Server hab. Puren RAM zur Verfügung.
Dass das Ding abstürzt. Dann steht da so was drin wie
Heep Allocation failed, weil nämlich zum Beispiel Programme
in der Standarddefinition irgendwie nur 4 Gigabyte greifen
dürfen ja, aus Sicherheitsgründen oder
Irgendsowas also das wäre das zweite Level um es klar zu
machen, also haben wir Hardware, dann haben wir quasi
anwendungslevel als Metriken und dann dazu gesagt erklärt, dass
wir auch aufspeichern können, die Custom Logs, wofür jeder
Entwickler dann selbstständig ja in die Tasten greifen muss.
Damit da irgendwelche Nachrichten rauskommen, was
gerade im Programm passiert und all das, da muss man bei Zalando
dann sehen, haben wir nicht nur eine Kiste und eine Anwendung
und ein Programm, sondern ganz viele Server mit ganz vielen
Microservices, die da drauf laufen, die quasi wieder
Prozesse sind in eigener Anwendung, mit ganz vielen
verschiedenen Codes der Laufen und dann bekomme ich jede Menge
Daten und ich glaube, jetzt kommt es glaube ich, wo du dann
auch oder vielleicht auch ein Mathematiker gefragt ist.
Ja, wie kriege ich denn aus dieser Datenwolke?
Informationen geschöpft und Inhalte raus, die mir die mir
erklären warum System gut funktioniert oder auch nicht
oder an der einen Stelle n Hick up hat und so weiter hab ich es
richtig verstanden? Ja genau OK.
Also zum zum Zalando Scale kann ich ein bisschen was erzählen.
Also wir haben ungefähr 10000 Nodes, auf denen Applikationen
laufen, laufen, wir haben 2000 plus Softwareentwickler, über 3
dreieinhalbtausend Microservices.
Die miteinander reden. Also wir haben so n
Architekturdiagramm, es ist schon schon relativ alt, wir
haben das mal so geplottet und man kann einfach sehr wenig
Struktur so erkennen von der gesamten Ding, es sieht einfach
aus wieso n riesiger Todesstern von Verknüpfungen, da gibt es so
n paar architektonische Bestrebungen auch so n nennen
wir domaingateways diese dependent Citroen n bisschen
stärker zu strukturieren, aber. Man kann sich vorstellen, also n
Problem, was Zalando auch in der Vergangenheit wirklich gehabt
hat ist, wenn jeder einzelne Entwickler jetzt nur auf seinen
Applikationen guckt und wir haben auch wirklich dieses You
Build it your Unit, das heißt die Entwickler die ne ne
Applikation bauen, die sind nachher auch in incident
Situationen diejenigen die das die backen, aber wenn die alle
nur auf ihre Applikation gucken ist für die einfach sehr schwer
zu sagen, sind wir denn jetzt gerade schuld an einer User
seitigen Funktion die nicht funktioniert weil wir haben?
Im Zweifel in der Call Chain irgendwie 10 Services, die
diesen Request alle sehen, also vom Nutzer auf der Webseite.
Da sind 10 verschiedene Rechner im Zweifel mit verschiedenen
Applikationen. Also wenn ich irgendwas in
meinen Warenkorb legen würde, dann passieren im Hintergrund 10
Aktionen an an 10 Microservices zum Beispiel.
Das können auch Hunderte sein, aber das sind mal mindestens 10
oder an vielen Stellen. Also genau.
Und wenn du dann dieses Spiel spielst, du hast erst mal alle
in dem Call irgendwie das der Checkout funktioniert gerade
nicht. Wir verdienen kein Geld.
Ja und du hast dann vielleicht 30 Applikationen die dann an
dieser Checkout Journey hängen und dann versucht jeder einzelne
Entwickler zu sagen Hey wo liegt denn das Problem und die gucken
alle auf ihre Dashboards mit den Metriken und sagen hier ist
grün, hier ist grün, hier ist grün, wir sehen in unseren Logs
nicht und dann sagen wir OK aber der Nutzer das klappt nicht und
dann hat man sehr. Langwierige Fehlersuchprozesse,
weil einfach der das Surface so lang ist.
Du kannst jetzt nicht sagen, OK, nehme diesen einen Java Prozess,
das muss irgendwo da sein und dann guck ich halt so lange bis
ich es da finde, sondern du hast so viel Kommunikationsoverhead
zwischen den Teams und das ist tatsächlich so n Punkt wo einem
dieses sag mal auch relativ klassische Metrik und
Loggetriebene Debugging nicht mehr weiterhilft, wo es einfach
sehr sehr schwierig wird und selbst wenn du nur ne Datenbank
und nen Webserver hast. Teilweise bei den Logs zu
verstehen, welcher Request von dem Webserver passt jetzt zu
welchem Sequiry die in der Datenbank waren?
Das ist oft ziemlich haarig und das ist so ein Problem, das
wurde innerhalb der Applikation schon lange gelöst.
Mit den Stack Traces, weil Stack Traces sind letztlich auch du
hast irgendwo einen Fehler und du kriegst ganz genau eine so
eine Call Chain die dir angezeigt wird warum wurde?
Dieser Fehler geworfen? Na ja, weil diese Funktion
aufgerufen wurde, teilweise mit diesen Parametern.
Warum wurde die Funktion aufgerufen?
Na ja, weil eine andere Funktion diese Funktion aufgerufen hat
und so gehst du halt bis ganz nach oben und dann fängt es
irgendwie an. Warum wurde ne Funktion
aufgerufen? Na ja ich hab n netzwerkpaket
irgendwo gekriegt oder ne webanfrage und dann hast du so
ne kausality Chain und im Prinzip ist die Grundidee von
diesem. Distributed Tracing oder
verteilten Tracing diese Stact Traces fortzusetzen.
Cross Application. Ah cool.
Ich verstehe es. Genau, du gehst dann quasi hin.
Auch nimm TCP Layer und sagst OK, wo kommst du denn eigentlich
her? Und dann gehst du quasi in den
Stact Trace von der Anwendung, die dich gecallt hat und solange
du wirklich mal keine, also asynchrone Komplikation der
Mitte hast in der Mitte hast, sondern wirklich einfach eine
Applikation microservice Macht, hat http call an den nächsten
Microservice was. So mal zumindest. 85% aller Use
Cases abdeckt. Das ist also wirklich ne sehr
sehr standardisierte Systemarchitektur, dann kann man
mit diesem Konzept konzeptionell sehr sehr klar nachverfolgen.
Der Nutzer trifft unsere Edge trifft den ersten Load Balancer
von uns, dann machen wir quasi den ersten sogenannten Span auf
und dann gucken wir OK, welche Funktionen werden ausgeführt und
welche Applikation wird danach gecallt und jetzt kann man sich
leicht vorstellen, wenn wir das für jeden Request machen, wir
kriegen irgendwie keine Ahnung. 3000000 Requests pro Sekunde
wird das ne sehr sehr, sehr große Datenmenge, die da die da
entsteht und und selbst die zu speichern das System kommt da
alles von Google, das ist einfach völlig outside jenseits
von gut und böse das das das kriegt man nicht hin wenn man
das für jeden Function Call macht, das heißt das erste was
man macht. Um es explizit zu sagen, ich
möchte nicht jede jede function Call mir angucken, sondern nur
spezifische und in Python ist es auch in einem SDK sehr schön
gelöst, dass ich einfach eine Annotation an meine Funktion
mache und sage, Hey die interessiert mich aber jedes Mal
wenn die ausgeführt wird bit capture, das quasi in diesem
Distributed Tracing. Wie wähle ich die aus?
Dann vorher diese Funktion, also sind das die ist es, basiert das
auf Verfahrung das eine Funktion?
Also die Idee ist das ja es es geht nicht unbedingt um Fehler,
es geht um die Business Processes zu verstehen.
Also du möchtest quasi von dem von dem Produktlevel die der der
Button funktioniert nicht untergehend auf auf Architektur
Level zu verstehen, Na welche Systeme sind da drin und was ist
so die Business Logic die da die da kaputt geht?
Und wie gesagt, es muss irgendwie human parsible
bleiben. Das heißt, idealerweise möchte
ich so n so n so n Trace haben, der sehr konzeptionell ist.
Also wir haben irgendwie nen Order Reservation Service, der
Gecallt wurde und der hat dann ne Datenbank query gemacht mit
den und den was weiß ich high Level, die heißt irgendwie
Reserve Stock oder sowas und die hat n Timeout gehabt und dann
dann kann ich danach immer noch in den Code springen oder nen
Debugger anmachen um dann n feineres debugging zu machen
weil man möchte in diesem verteilten Trace.
Quasi high Level, die die Business Logik nachvollziehen.
Ich. Verstehe, denn du musst denn,
denn wenn du dann einmal siehst, überhaupt in diesem High Level
Stack Trace, dann weißt du überhaupt erst mal, welche
Datenbank auf welchem Server nen Timeout hatte und damit damit
bist du erst mal eingenordet. Wo kann ich mich erst mal
einloggen und wo hol ich mir denn jetzt die Detail
Detailinformationen aus den Logs zum Beispiel raus von dieser
Datenbank, vorher weißt du es ja noch gar nicht, ja.
Genau. Und dann stell dir vor, für
jeden. Request, den du bei der Zalando
Webseite machst über Suche oder View Pages haben wir einen
Stacktrace der ungefähr 1000 Einträge hat, nachher im
Telemetrie System. Krass, also ist ne extreme Load
implification. Da habt ihr ja ne retention
policy hoffentlich drauf. Ne.
Also wie das ist ja das nächste. Also ja jetzt jetzt sagst du das
ich verstehe das also man ich spreche das noch mal so n
bisschen in in in anderen Worten auf die Spur also man was ihr
wissen wollt ist wenn ein Fehler entsteht.
Wo ist der überhaupt in so einem riesigen System?
Ja, ja, das heißt eure und was ich verstanden hab, eure
Strategie ist, dass wenn jeder User klickt oder in irgendeinen
User klickt einmal dann passieren jetzt zig Sachen, ja
das muss man jetzt der Zuhörer, der jetzt nicht so tief in Cloud
und so weiter drin ist, aber es werden Netzwerk Calls gemacht
von einem Server zum nächsten und so weiter das das können
irgendwie genau also mit Microservices zusammen und so,
das können ganz viele Server sein die irgendwas gemacht haben
und ganz viele Komponenten in der Datenbank wird das
eingetragen irgendwo wird das ausgetragen und sofort ja.
Was du jetzt sagst, ihr schneidet quasi so ne Art Fluss
durch die Architektur, durch die Komponenten mit gut ausgewählt,
das ist wahrscheinlich schon einer der Künste, dass man das
nicht zu dicht macht und auch nicht zu dünn, sodass man genau
später sich quasi lang hangeln kann und weiß, wo muss ich genau
gucken und der tut das quasi für jeden Klick und jetzt wär mal ne
Frage, das kannst du ja machen. Aber wahrscheinlich nicht ewig
lange. Also du wirst doch nicht sagen
können, was war vor einem halben Jahr, als der als der gesagt,
weil du hast ja gesagt, sind sowieso viele Daten, ja, das
heißt, die Macht das wahrscheinlich so Last Day oder
Last Two Days oder darfst du das, darfst du das sprechen, was
habt ihr da so? Ja, das das hat sich verändert.
Das waren früher eher hours, jetzt haben wir irgendwie n paar
Days, da das das, da ändert sich auch so die Capabilities von den
verschiedenen Zulieferern die diese Systeme betreiben, das
machen wir auch nicht selber. Ja und die andere Sache die man
auch dazu sagen muss. Wir speichern nicht alle dieser
Traces ab. Wir haben da ne Sampling Rate
drauf. Aktuell ist das glaub ich so bei
rund 30%, was immer noch sehr viel ist.
Andere Firmen sind eher so bei ein oder 0 Komma ein Prozent und
da ist tatsächlich in meinen Augen ist es die richtige Art
und Weise damit umzugehen. Wir haben in diesem ganzen
obsibility Prozess so ne nen fundamentalen Trader auf den wir
immer machen müssen, das ist einfach Datenvolumen und damit
auch Kosten mit Resolution. Und da muss man ein bisschen
smart sein, wenn man einfach jeden function Call und jeden
was heißt. Register Assignment Rauslockt
aus dem Prozess, da macht die CPU nachher überhaupt nichts
anderes mehr als nur ständig zu berichten.
Was hast du gerade gemacht und das ist letztlich auch nicht
wirklich zielführend, sondern man muss bei den Daten, die man
wirklich rausschreibt und sagt die Zentralisiere ich und die
speichere ich und die indiziere ich nachher auch, da muss man
schon so mal ökonomisch mit umgehen und wir haben Phänomene,
es gibt einige. Operationen nennen wir die zum
Beispiel Reset Passwort oder Change Adress oder
Profilseitenänderungen. Die sind teilweise auch wichtig
für die User Experience, aber die sind sehr selten und da
wollen wir jetzt schon jeden einzelnen Reset Passwort request
gerne haben, weil das sind 10 pro Minute vielleicht ja, da
kommen wir, da kommen wir alle Mitsteinen in voller Detailgröße
aber View Gender Home ja wenn du einfach einfach auf die Webseite
kommst. Da reicht n Promille locker
locker und das heißt, da möchte man so dynamisch n bisschen die
Granularität Unterfahren und die zweite Sache, die ich da gerade
noch anfügen möchte, ist, ich glaube, auch wenn man dieses
Obsibility Endgame anguckt, ich mein, Wir sind jetzt irgendwie
keine Ahnung 15 Jahre drin in diesem Obsibility Game,
vielleicht noch n bisschen länger seit.com vielleicht auch
ja OK, dot com hatte auch schon obsibility, insofern jetzt gut,
vielleicht 25 Jahre, aber wir sind noch nicht am Zielen.
Ich glaube, dass man immer noch diese diese Fragen, die man an
den Prozess stellen kann, dass die immer noch sehr limitiert
sind und ich hoffe, dass wir in der Zukunft immer mehr in der
Lage sind, immer präzisere Fragen an an an Systeme zu
stellen und die Antworten nicht zu bekommen, weil wir alles
weggelockt haben und so ne riesige Datenbank haben, wo
alles was das System die gemacht hat drin ist, sondern weil wir
an das System selber rantreten und quasi dynamisch fragen.
Sag mal, was ist denn in dieser Variable drin?
Sag mal, wie oft hast du das denn ausgeführt und dass wir
sehr viel quasi näher an die an die Anwendung kommen und dann
näher an den Prozess kommen und den direkter auf diese Daten
zugreifen, das ist zumindest langfristig denke ich wo wo wir
auch wieder was sehen werden, dass wir näher in die Richtung
kommen, ja. Ein kurzer Hinweis in eigener
Sache. Kennst du das auch, dass von
neuer Software zur Digitalisierung der Produktion
zurückgeschreckt wird? Ihr seid gefangen zwischen
starrer, veralteter Standardsoftware und endlosen
Individual Entwicklungsprojekten.
Unsere Mission bei Heisenware ist es, das zu beenden mit
unserem App Baukasten geben wir dir die Möglichkeit,
maßgeschneiderte Software für den Shopfloor schnell und ohne
Code zu erstellen. Denk an Maschinendatenerfassung
moderne Visualisierung für die Produktionsleiter oder eine
mobile App zur Buchung von Zeiten direkt am Arbeitsplatz
und das beste du kannst deine Lösungen ganz einfach ohne it
Aufwand selbst betreiben. Sagt günstiger als eine externe
Entwicklung unendlich passender als Software von der Stange.
Weitere Infos und eine kostenlose 30 Tage Testphase
findest du auf heisenware.com. Slash einfach minus komplex als
Träumhörer bieten wir dir im Anschluss 20% Rabatt auf alle
Pakete im ersten Jahr und jetzt viel Spaß mit der weiteren Folge
ich hab darf ich noch eine Frage stellen zu den zu den Traces
oder den den Spuren vielleicht ein bisschen naiv, aber dafür
bin ich ja da. Für irgendeinen Request jetzt
auf der Website sagen wir mal den den Passwort.
Du hast gerade den den Passwort Change und den einfach den
Website Aufruf quasi als als 2 Beispiele gebracht, ist diese
Trace diese Spur vorher schon definiert?
Wisst ihr wo dann die wie der Flow quasi ist?
Durch all eure Microservices und Funktionen oder werden die dann
dynamisch auch wieder mitgeschnitten und man weiß es
danach eigentlich erst? Wie ist es gelaufen?
Also ja, das ist das ne Gute. Frage also das System
funktioniert. Das hat 2 Komponenten die das
zum Funktionieren bringen. Das eine ist quasi ID
propagation in dem Moment wo wo der Request zum ersten Mal die
Infrastruktur trifft wird ne UUID generiert und diese UID
wird propagiert, das heißt ich muss vorher keinen Flow
definieren oder irgendwas, sondern ich muss nur wissen
jeder ITTP request hat so n Header.
Und da steht ne Flow ID drin und die muss ich dann wieder
aufgreifen. Das muss quasi dieses API
Framework machen und das muss auch die Applikation können,
dass sie diesen diesen Header weitergibt und jetzt die zweite
Sache ist. Centralized Storage, also jede
Applikation die managt so ne Q von diesen ganzen Events die sie
gespeichert hat und die schreibt die dann asynchron an ein
zentrales Backend und was das Backend jetzt macht, das guckt
einfach und kriegt kriegt den von den ganzen Applikationen.
Kriegt das jetzt diese diese diese Spuren oder Traces
zugesandt? Und das macht jetzt so nen Join.
Das guckt sich quasi, wenn der Nutzer da ne Anfrage macht guckt
sich das an. Na ja, was waren denn die ganzen
Events die ich mit dieser Trace ID gesehen hab und dann baut die
das zu einem Stack Trace View zusammen, das heißt nachher der
Entwickler der der der klickt dann auf so n so n so ne Trace
ID und dann sieht er diesen Baum wie du das aus einem Debugger
auch kennst. Wo du diese Frames untereinander
hast und dann sieht er halt. Oft halt auch mit Timing.
Informationen wie lang so n Spam ist.
Das zeigt immer wie lange ne Operation gedauert hat, aber es
ist letztlich so ne Stack Trace artige Datenstruktur die dann
visualisiert wird, das heißt der.
Request identifiziert sich in jedem Schritt als der Request
über die UID und dadurch habt ihr nachher den Flow, aber
keiner muss den vorher definieren.
Das ist gegeben durch den durch den Code selbst.
Der Flow wird quasi. Discovered, aber du hast pro
Applikation instrumentierungsaufwand und das
ist tatsächlich die praktische Hürde, wo ganz viele Firmen dran
scheitern. Nachher, wenn man das alles in
allen Systemen drin hat, ist das mega cool.
Also ganz, ganz viele Probleme sind halt einfach OK.
Du machst das auf, ist völlig offensichtlich, es ist OK, ich
weiß irgendwie 10 Service ist tief, es ist der Datenbank
kriegt weiß nicht ich kann den Error direkt sehen OK ich weiß
es war irgendwie n overload oder irgendwie n parameterproblem und
dann ist die D Bogging Journey einfach sehr schnell.
Aber wenn du erstmal da bist, du hast noch keine Applikation
instrumentiert, du bist einfach noch auf auf auf Schritt 0, dann
fängst du an, eine Applikation zu instrumentieren und dann
Mehrwert ist einfach nahe 0. Weil du kriegst noch keine Trace
ID übergeben. Du schreibst vielleicht deine
Trace id weiter, aber die wird im nächsten Schritt wieder
ignoriert und das heißt, selbst wenn du 34 hast, siehst du
einfach noch keine Traces die wirklich zusammenhängen, sondern
sobald du immer einen dazwischen hat, der dieses System nicht
respektiert. Fallen deine Traces auseinander,
was die Usability davon geringer macht.
Was du bekommst ist n Access log, das hab ich tatsächlich bei
mir in meinem Homelab hab ich auch ziemlich viel Monitoring
laufen, aber ich hab kein Tracing oder kein gutes Tracing,
ich hab nur Tracing auf dem Load Balancer und dann hab ich n
nettes Access log, man hat halt keinen keine weiteren
Informationen, damit fängt es halt an und dann hat man so ne
Journey wo man dann anfängt OK jetzt hab ich vielleicht die
ersten Layer oder die ersten 2 Layer instrumentiert und
irgendwann wird es dann mega cool.
Weil, Hey, du hast auf einmal Discovery von Clients.
Also wer sind eigentlich der callt dich eigentlich von mal?
Verstehst du das total gut, weil die alle ihre Trace IDS
mitschicken und dann kannst du sagen Hey OK ich weiß nicht nur
wer mich gecallt hat, ich weiß auch warum der mich gecallt hat
und welche User Journey quasi dahinter steckt auf unserer
Webseite solche Sachen kann man dann machen aber das sind so
Netzwerkeffekte die dann zum Tragen kommen wenn du halt
relativ weit schon bist. Ist es dann nicht.
So dass also ich kann davon auch n Lied singen, immer im kleinen
ne, also ich hab nie mit Zalando gearbeitet, dann noch nicht mal
halb so groß, aber die Probleme sind die gleichen, auch wenn du
n kleineres System hast. Du willst es trotzdem alles
wissen und wenn du so n bisschen anfängst dich zu verteilen, dann
dann dann hast du technisch mathematisch die gleichen
Probleme nur auf n kleineren Scale sag ich mal aber ist nicht
das eine schwierige, dass du n sehr guten Systemarchitekten
brauchst? Der sagt wenn man einmal dann
das ist glaub ich ne Architekturentscheidung die alle
deine wie viele waren es Developer respektieren müssen.
Dass man sagt, Pass auf wir, wir machen das so mit dieser ID, so
wie du es gesagt hast. Deshalb von der UNIQUE ID und es
funktioniert. System funktioniert ja nur dann
perfekt, wenn jeder einzelne Entwickler der n Code schreibt
jetzt kommen wir nämlich noch mal zurück und ich glaube du
sagst wieder dann falsch wenn ich falsch liege, aber ich
glaube es ist so, dass jeder einzelne Entwickler muss das
quasi kennen und akzeptieren und in seine Logs dir ne Applikation
rausschreibt, das ist nämlich jetzt wichtig, die Applikation
macht jetzt zum Beispiel NSQL Query irgendwo drauf auf ne
irgendeine Datenbank, ja. Da muss dann in in dem Log der
dazugehört, den ich als applikationsentwickler schreibe,
diese ID mit abgeloggt werden, dass die irgendwo steht, ja oder
abgeschickt werden oder wie auch immer, ja dekollation muss
entstehen und das was du sagtest glaub ich um das auch noch mal
zu sagen ist dabei, dass er quasi wieso n Baum ist.
Du fängst oben an und dann geht es wieso n wieso ne wieso n
Gewitter quasi wieso Blitze die sich verteilen geht es runter
ins System. Und wenn nur ein, wenn nur ein
System quasi die ID nicht weiter nach unten leitet, dann hast du
quasi so n Bruch drin und kannst schlechter verstehen.
Was war da los? Ja und kurz noch mal um Gerrit
zu sagen warum, warum kann man das im Prinzip eigentlich nur
post mortem irgendwie analysieren was da los ist, weil
tatsächlich solche hochverteilten Systeme und jetzt
quetscht er mich wieder weg wenn es nicht so ist bei Zalando im
Prinzip nicht vorhersagbar sind, weil nämlich diese Load
Balancer, von denen der Heinrich spricht, das sind quasi Server
die entscheiden jeder. Für jede Anfrage neu.
Wo geht die gerade hin? Die Entscheidung, das können
statische Algorithmen sein, wo man sagt, Ich mach einfach Round
Robin immer der nächste und so weiter dann kann man sich das
vielleicht zusammenreihen was so ist, aber da gibt es viel
kompliziertere Algorithmen die wisst die die die überlegen
quasi woah der hat jetzt hier ganz wenig gekriegt und so
weiter und sofort, ja unglaublich schwer
vorherzusagen, wer am Ende der deine Anfrage abkriegt, selbst
für denjenigen der den Code da geschrieben hat, ja weil.
Genau, dass die Idee ist, dass das System quasi mit diesen Load
balancern irgendwie so belegt wird, dass irgendwie alle
gleichmäßig busy sind und nicht der eine schwitzt und die
anderen feiern so. Ja, also die 2 Sachen noch mal
gerade nachgesprochen. So das glaub ich, gibt noch mal
so n vielleicht so n Verständnis warum man diese warum man warum
das wichtig ist, diese ID immer weiterzureichen, warum man
vorher nicht weiß wer eigentlich das Abkriegt, den ganzen Kram.
Ja, das ist konzeptionell genau richtig.
Und auch gerade dieses Problem bei dem Monitoring Bindor hatten
wir noch kein so verteiltes System, das war noch irgendwie
2000 Zehner Jahre, da war das ja schon vielleicht n bisschen
später 15, aber da, da haben wir noch irgendwie auf einzelne
Server deployed und auch uns da eingeloggt mit SSH und ich hab
da auch ständig die Logs getailt und ich wusste auch OK, in
unserem Webstore waren wir vielleicht 3 Nodes bei unserer
Datenbank 10. Aber ich seh einfach jeden 10.
Rick fest und ich konnte auch 10 SSH Fenster aufmachen.
Wenn ich jetzt ganz genau wissen wollte, wo wo es wo der
hinkommt. Die hab ich dann teilweise dann
manuell in ne Datenbank reingeschoben und dann irgendwie
meine Creps da drüber gemacht. Ja das funktioniert bei Zalando
einfach nicht mehr, weil teilweise sind die einfach auf
5000 Nodes hochgescaled also da wird es mit SSH Fenster
aufmachen n bisschen schwierig und so n großen Bildschirm.
Genau. So große Bildschirme haben wir
nicht, ja. Und du hast auch noch diese
dynamischen Sachen, dass du du kommst mit Kybernet, das sowieso
nicht gut ran. Und selbst wenn du rankommst,
dann ist der Pott vielleicht weg oder es kam irgendwie n Neuer
dazu. Das ist alles n bisschen
dynamischer, das heißt also diese diese Idee ich, ich
arbeite mit der Applikation selber oder mit diesem
Deployment selber, das ist es ist sehr sehr schwierig, obwohl
ich ich denke, dass das Unterdeveloped ist.
Ich glaube, an vielen Stellen sollten wir das tatsächlich tun,
und das ist auch so dieser Gedanke, ganz viel von also.
Die Sachen, die wir bei Zalando machen, sind nicht konzeptionell
anders als auf jeder Scale. Auch ich mach ne ganze Menge
Prototyping in meinem Home Lab, wo ich einfach 20 Container hab
auf einer Note und konzeptionell sind die Sachen mehr oder
weniger dieselben, auch was der Entwickler sieht ist dieselbe,
die Plattform ist natürlich n bisschen anders und was du schon
angesprochen hast dieses Governance Thema, wie stelle ich
denn sicher, dass wir hier alle zusammenarbeiten ist natürlich
wichtig, weil sonst kriegst du diese Broken traces und das ist
tatsächlich genau die Krux an der Sache.
Wie du es dargestellt hast mit diesem OK, die Entwickler müssen
genau diese ID in die Loginline reinmachen, da sind wir n
bisschen weiter, da gibt es mittlerweile open Standards, das
ist vor allen Dingen das Open telemetry Projekt, was einen
Satz von Libraries anbietet, wo alle sagen wir mal a Mainstream
Frameworks mit supported sind und sobald du dann Open
telemetry importierst macht er dieses.
ID Forwarding Layer macht der im Wesentlichen automatisch und für
ne ganze Menge Standard Library ist.
Gerade Datenbankadapter gibt es dann auch Autoinstrumentations
wo der dann einfach sagt, OK jede Datenbank kriegt fest,
kriegt ne standardisierte Spam zugeordnet, da gibt es auch ne
ganze Menge Felder die automatisch gefüllt sind, also
da da wurde wurde schon ne Menge abstrahiert und der der Datapart
ist auch ein bisschen ein anderer also wir schreiben das
nicht in den Log Stream rein der in das Login System geht sondern
es gibt einfach einen parallelen Datenstream.
Der dann direkt in dieses Tracing System geht.
Da kommst du jetzt nämlich. Auf den Punkt, da würde ich
gerne noch mal aus Eigeninteresse noch mal n
bisschen tiefer reinhaken, weil ja erstmal für den Zuhörer noch
mal also das die Anwendung selber würde natürlich am
schönsten am schnellsten laufen, wenn sie gar nichts preisgeben
würde von ihr. Also man muss einfach dazu
sagen, das ist so wenn ich was ablogge wenn ich was
hinspeichere Informationen wegspeicher über das was ich
gerade gemacht hab, dann ist es einfach zusätzlicher Aufwand
erstmal weil ich es einfach speichern muss.
Und zweitens, weil, weil ich es irgendwo, also weil ich, weil
ich es im Prozess machen muss, das heißt, mein mein Code kommt
irgendwie, request kommt an, jetzt mach ich irgendwie SQL
Call, jetzt will ich ihn eigentlich wieder
zurückschicken, kann ich nicht, weil ich muss hinschreiben, mein
Code, mein mein Call kommt an, jetzt mach ich den SQL Call und
jetzt log ich erstmal das was ich da gecallt hab und das frag
ich dich gleich wohin auch immer ja auf die Festplatte oder
vielleicht schick ich ihn ab oder so aber immerhin in diesem
Programm gibt es halt eine Zeile Code die dafür.
Zuständig ist nur mal darüber zu zu benachrichtigen, dass das
passiert ist. Das macht das Programm
langsamer. Punkt ja, und das heißt, man
will eigentlich im Idealen, in der idealen theoretischen Welt
will man zwar alle Informationen haben, aber möglichst non
intrusive ja, ich mach mal n Bild ja wenn wir sagen, der
Zalando Architektur Stack mit den ganzen Servern im ganzen
Kram ist sowas wie n komplizierter Organismus, wieso
n Mensch ja und jetzt füttern wir irgendwas rein um den
Menschen irgendwas funktioniert nicht mehr.
Dann ist ja halt schon so komplex geworden, dass wir gar
nicht mehr genau wissen, wieso welche, welche Magenkehre hat.
Jetzt, da hier irgendwas abgekriegt, ne und jetzt
könntest du mittelaltermäßig intrusiv ja steckst du halt in
den Menschen irgendwelche Elektroden rein, so die zeichnen
dir das irgendwie mit ja und du weißt was los ist.
Das tut den Menschen aber nicht so gut und das tut halt auch der
Zalando Anwendung nicht so gut, das heißt du willst eigentlich
dich hin entwickeln zu so einem Bild wo du Raumschiff Enterprise
mäßig steht halt Pille da und macht halt mit diesem mit diesem
Scanner da ja einmal der Organismus hoch und runter.
Das hat den nicht dabei gestört zu verdauen.
Ne der verdaut ist super, läuft alleine rum, ist alles andere
Systeme werden nicht gestört, weiß aber trotzdem wie es ihm
geht und jetzt komme ich zu meiner Frage wenn man als normal
Entwickler irgendwie gibt es ja auch so loglybe Reason so weiter
wenn ich jetzt no GS programmiere oder Python oder
wie auch immer im Backend dann schreibe ich halt irgendwie im
besten Fall schon mit dem Timestamp und so n bisschen
schön aufbereitet den Kram hin log line dann legt er sich aber
wohin denn? Ja in meinem Docker Volume.
Und in dein Docker Volume ist halt wieder auf der Festplatte
von dem Server, wo ich halt gerade lebe.
So, ja das kann ich machen, ist auch relativ schnell, weil
Festplattenschreiben ist ja auch schon relativ schnell, macht ihr
das noch so und und greift ihr dann quasi mit?
Weil meine Frage ist jetzt wie kommen diese ganzen Daten, die
müssen ja irgendwie mit zentral irgendwo aggregiert ankommen,
davon hast du auch schon geredet, dafür gibt es Software
aber wird das live abgeschickt während dieses Log Event
entsteht oder wird das erstmal auf die Festplatte gehauen?
Dann gibt es den zweiten Prozess der scannt das und schickt das
in Dingern weg weil ich will ja irgendwie schaffen.
Dass mein mein ganzes Logging und Monitoring System nicht
meine Anwendung langsam macht und kannst du da uns noch n paar
Insights geben oder mir vor ich bin da auch noch auf der Suche
nach der idealen Lösung für n für ne Mittel für mittelgroße
Architektur sag ich mal ja übrigens.
Ist echt wirklich sehr sehr schön auf den Punkt, weil genau
um die Sachen geht es und es ist im Prinzip auch nicht
schwieriger als das die die meisten die meisten Sachen.
Bei bei Telemetrie du machst eigentlich immer was ähnliches
als so n Print F Statement und das sind 2 Sachen die da ne
Rolle spielen. Das eine ist die Serialisierung,
die Serialisierung, also das Stringformetting und das ist
schon relativ teuer weil du alliziierst n relativ großen
Speicherbereich und dann machst du so CPU intensive Sachen, also
jeder der auch json parsing oder json seriilization gemacht hat,
das ist oft das langsamste was dein Microservice macht und
jetzt machst du noch mal was was potenziell sehr langsam ist
nämlich. Dein schönes Event, quasi als
schönes Human Readibles String aufzubereiten, in irre großes
Ding. Und dann machst du was zweites,
was auch sehr langsam ist, nämlich normalerweise IO du
schreibst es auf die Festplatte oder du schreibst es über das
Netzwerk, das heißt es geht aus deinem Arbeitsspeicher rum, geht
einmal um ein System wo es geht in die in die Netzwerkkarte
rein, das ist alles teuer, das ist ziemlich teuer und gerade
diese ganzen Sachen no JIS Dummel mit asing quinness IO und
was weiß ich, da haben wir ja auch als Entwickler sehr viel
gehört. Wie man das jetzt besser macht,
das ist alles total relevant in dem Kontext.
Manches kann man einfach offloaden, wo man sagt, OK
asynchron, wenn die CPU mal nichts zu tun hat, dann dann
schieben wir das dann irgendwie weg oder haben irgendwie NDMA
Lösungen, dass das nicht mehr über die CPU muss, aber das ist
im wesentlichen ist es dieses Spiel und das ist auch genauso
komplex, also Invariance of Problem und dann ist n
kostendifferencial da wieviel kostet mich ein Prozent
Performance overhead, wieviel kostet mich?
5% Performance Overhead wieviel kostet mich 50% Performance
Overhead und je nachdem wie fein ich logge sind wir auf diesen
Skalen unterwegs. Was mich n bisschen schockiert
hat oder enttäuscht hat ist, dass die Commercial Incentives
nicht unbedingt da sind zu sagen, wir machen Performance
Oriented Programming bei Zalando, also ist es oft nicht
so entscheidend wichtig, ob wir ein Prozent schneller oder
langsamer sind. Weil die Profit margins, die
hängt tatsächlich nicht da dran. Machen wir 100 Milliarden
Requests die Sekunde, sondern wir haben irgendwie n paar
Requests von jedem Nutzer, die dann hoffentlich hoffentlich mit
relativ high Commercial Revenue konvertieren.
Also wir haben ne so ne Menge Spielraum, also die
Infrastrukturkosten sind kein so immens, der Kostenfaktor in
einem großen Zalandokosten wenn du es jetzt mit Returns
Management oder so vergleichst. Ja das heißt.
Die Incentives sind nicht jetzt zu sagen, da polieren wir eher.
Die Incentive ist eher zu sagen, Hey, wenn unser Shopdown ist,
dann können wir gar nichts verkaufen und wir müssen das um
jeden Preis verhindern, weil das ist einfach absolut
schweineteuer Verfügbarkeit. Müsst ihr optimieren als erste
im Parameter genau Verfügbarkeit.
Ist extrem wichtig im E Commerce, wo du wirklich auch so
ne direkte Korrelation hast. Wenn der Shopdown ist, verdienst
du kein Geld, das hast du bei einer Bank zum Beispiel nicht
so, das ist auch ne Logistik nicht so und das verschiebt
quasi wie diese wie diese. Trade Offs gemacht werden.
Selbst würde ich generell sagen, Zalando ist eher auf der Seite
mehr loggen und mehr Daten rausschreiben als jetzt
Performance orientiert zu programmieren, das muss
natürlich trotzdem nicht stupidly wasteful sein, aber da
sind wir schon so mal eher bereit Trade offs zu machen, zu
sagen wir sind da eher verbos orientiert ja cool, danke für
die. Inzeit und ist dann jetzt jetzt
mal ne soziale Frage in so n Team.
Also. So n Job kann ja ganz schön hart
sein, weil ich ich meine jetzt, du bist ja genau die Person, die
im Wind steht, wenn was nicht funktioniert.
Ja so, du sagst ja verfügt, also warum macht ihr das alles um um
wenn was nicht funktioniert möglichst schnell weil
Schnelligkeit hast du gesagt Key ja rauszufinden was los ist
müsst ihr das trainieren also ich ich kenn mich selber ich
weiß nicht ob es anderen Entwicklern geht wenn bei uns
was kaputt ist. Ja manchmal krieg ich so ne
Nachricht von Gerrit Ich hab das und das gemacht das geht
überhaupt nicht es ist für mich das Schlimmste.
Also wenn ich hab ich ich hab den schönsten Tag ja und wenn
dann sowas kommt, so weißt du so ne standardsache wo du sagst
Alter das ne ich ich geb mal n Beispiel Time Series Database
hatten wir heute morgen ja Time Series Database ich drück da auf
den Knopf da kommt nichts und als Entwickler geht in deinem
Schädel ab wenn da nichts kommt dann dann ist die das ist
richtig scheiße und du weißt gerade was alles noch alles
sterben wird weil weil das gerade nicht geht ja.
Und ich krieg dann das große P in die Augen.
Ich bin echt wirklich, also ich muss richtig dran üben, ich bin
wirklich richtig unentspannt und kann dann gar nicht mehr meiner
normalen Arbeit nachgehen, weil das eigentlich so brennend ist,
dass ich eigentlich noch nicht mal Lust oder den Mut habe,
irgendwie das fertigzumachen, was ich gerade hab, was sinnvoll
wäre und und mich das völlig aus dem Takt bringt.
Ja, ist das denn nicht auch so bei euch?
Also vor allen Dingen auch wenn ich, wenn du sagst, also die
Entwickler werden da mit Rangezogen so und irgendwie der
Shop ist tot, jemand drückt da, also es gab oder hier
krasserweise es gab neues Release ja.
Irgendwas, was immer, immer ging, ja irgendwo ist.
Da gab es doch keinen Test oder irgendwas ist jetzt kaputt.
Ja, dann ist ja, das ist ja wie wenn die, wenn es brennt so oder
kannst du da mal so n so n Inside geben, so wie wie macht
ihr das? Da diese Analogie zu
firefighting ist tatsächlich auch sehr, sehr adäquat.
Aber Hektik und Aufregung bringt nichts, selbst wenn du viel Geld
verlierst. Jede Minute ist es, die die
Attitüde muss Professional sein, in dem in dem Moment.
Und deswegen übt man das auch. Deswegen gibt es eine ganze
Menge Material. Auch die, die Teams
bereitstellen für ihre Incident Responder, diese sogenannten
Playbooks, so Standardprozeduren, die
durchführbar sind. Oft sind auch Gamedays, wo das
trainiert wird, es ist ein relativ standardprozess, es ist
OK, der Order Drop Alert kommt OK check die commercials Check
die SLOS welche Systeme sind es? Wir haben oft sind die Leute,
die es betrifft, schon direkt selber alerted, weil die Teams,
die die Applikation bereitstellen, in der Regel sehr
gutes Alerting Coverage haben. Dann wird n Incident aufgemacht
im Chat, wenn es wirklich n großer Major Incident ist, wird
sofort n Video Meeting dazu gemacht.
Wir gucken durch, wir in den Traces, was sehen wir, können
wir die Fehlerdiagnose machen, welche Teams brauchen wir, um es
zu beheben? Ihr macht n Video.
Meeting aber nicht um zu quatschen, sondern ihr macht
einfach das auf und dabei sitzt ihr und jeder guckt in die Dings
und ihr sprecht einfach wieso n in unserem Online Game hier.
Ich seh das und das und so weiter kann man sich so
vorstellen, einfach die schnell mal alle zusammen, also die die
großen. Incidents die laufen so ab, wenn
man wirklich weiß, die Scheiße ist am dampfen, dann haben wir
einen Incident Commander, der so Koordinator des Incidents ist.
Der hat formal keine Aufgaben im Debugging, der Macht nicht groß
seine Konsole auf und versucht es zu verstehen, sondern der ist
Koordinator und der stellt sicher, dass alle Leute, die das
betrifft, die die Meaningvoll an der Incident Resolution
beteiligt sein sollen, in dem Raum sind und arbeitsbereit sind
und dass auch Leute, die ablenken, einfach
rausgeschmissen werden. Gibt es auch teilweise, dass
dann auch teilweise Senior Management Stakeholder mal da
gewesen sind und irgendwie so. Status haben wollten.
Und er hat dann auch gesagt, Bitte nicht jetzt, ihr werdet
informiert über ein so ne regelmäßige so n Form was du
dann ausfüllst als Incident Commander wo dann quasi
Management Board und Management Chain informiert werden.
Man kann im Chat irgendwie folgen wenn man das als
Entwickler auch gerne wissen will, wo stehen wir gerade oder
wenn man vielleicht auch helfen kann aber das wichtige ist es
ist n standardprozess. Es ist Full Attention, alles
stehen und liegen lassen. Wir fixen das jetzt also alle
anderen Sachen haben Pause nicht noch irgendwie n wichtiges OK,
dann ist ja mein. Gefühl immer richtig, dass ich
alles andere erstmal stehen und liegen lasse.
Alles stehen und liegen lassen. Wenn Commercial Impact da ist,
auf jeden Fall. Es gibt natürlich Abstufungen,
wir haben da so n so n Threshold, was ist n Incident,
aber generell sobald für User Experience im großen Stil, also
mal mehr als 100 User oder mehr als 1000 user.
Beeinflusst ist ist es n Incident und das wird mit Höchst
der Priorität gemacht bis er mittigiert ist.
Also das heißt bis das Bleeding gestoppt ist und danach ist so
OK. Geht mal nach Hause.
Wir fangen jetzt nicht noch an irgendwie den Code zu fixen
nachts um 9, sondern das machen wir am nächsten Morgen aber als
erstes und dann schreiben wir auch n Dokument direkt das
postmorton Dokument Dokument und das ist auch relativ
standardisiert, ist nicht so arg lang aber es wird halt
aufgeschrieben na ja was ist schiefgelaufen?
Was sind die, was war die, was war die Ursache und was wollen
wir besser machen? Dass das in nächster Zeit nicht
mehr passiert und das durchläuft dann auch n Standardprozess, da
gibt es dann auch auf Zalando Ebene noch mal so nen gesamten
Operational Review, wo wir aber die letzte Woche zurückgucken
und sagen Hey wieviel Sachen sind denn schiefgelaufen, gibt
es irgendwie auf globaler Ebene noch Sachen die wir besser
machen müssen? Ja, du habe.
Ich bei bei euch. Jetzt habe ich verstanden
Incidents oder Major Incidents Messe ihr an der Anzahl der
betroffenen Nutzer. Also es kann n ganz kleines
Problem eigentlich im in der Software sein, aber Incidents
bemisst sich, also die Schwere des des Incidents bemisst sich
nachdem wie viele User betroffen sind quasi so das erste Teil der
Frage zweite ist wenn jetzt jemand was noch nicht macht wie
definier ich denn gute Major Minor oder überhaupt Incidents
Kennzahlen für mich ja sehr gute.
Frage. Also das ist allgemein
Hochdimensional das Problem und das ist auch nach nach Business
unterschiedlich. Also das ist für ne Logistik
oder ne Bank unterschiedlich viel von E Commerce Company und
es es gibt da Standardliteratur zu und es gibt auch glaub ich
dokumentiert was Google oder andere Companies macht machen.
Ich glaube was am meisten Sinn macht sich ist erstmal über
Impact die menschens Gedanken zu machen was sind Art und weisen
wie ich Messe Impact Messe und. Bei jedem, also E Commerce
Company hast du immer commercial impact.
Das ist quasi den Revenue, den du einfach nicht machst.
Den kannst du oft relativ genau messen, weil du weißt wieviel du
wieviel Orders du pro Minute rein kriegst.
Und wenn du weniger Orders rein kriegst, das kannst du dann so
einen Pi mal daumenfaktor anlegen um zu verstehen wie groß
ist der Impact, aber ganz viele Incidence, zum Beispiel wenn
Reset Passwort nicht funktioniert haben keinen
Commercial Impact. Weißt du, dass die trotzdem
irgendwie nicht wichtig waren? Natürlich waren die wichtig.
Und du brauchst dann pragmatische KPIS, die dir so
erlauben, so n Daumen dran zu machen.
Du kannst da beliebig das Weitertreiben und irgendwie
gucken, was war denn jetzt der Impact zu so zu so NKPI im
Produktbereich, der ist Customer Lifetime Value, aber wie willst
du den jemals berechnen? Also diese Sachen bringen
nichts, sondern ganz pragmatisch.
Wir haben noch Dimensionen kosten, wenn manchmal waren
keine User Experience da, aber wir haben dummerweise n
grafikkartencluster was Wochenende laufen lassen ja ist
auch n incident. Der dann irgendwie bepreist
wird. Oder wir haben diese
Userdimension wieviel Nutzer waren beeinflusst oder wieviel
Employees waren beeinflusst. Davon ist auch wichtig und das
sind so mal 445 KPIS und dann kann ich umgekehrt sagen, Na ja,
wenn weniger als 100 User beeinflusst sind, dann fangen
wir jetzt nicht an nachts um 3 dieses Problem zu fixen.
Es ist dann auch wichtig für die Teams dann zu sagen, OK, nur
weil wir jetzt n Problem sehen. Wenn das unter so einem gewissen
Threshold ist. Wenn wir wissen, No Financial
impact oder no Major Financial Impact oder nur so wenig Nutzer
beteiligt. Es gibt dann so
Ausschusskriterien, wo man mit gutem Gewissen sagen kann, wir,
wir machen dieses Thema jetzt erstmal wieder zu und genau und
jetzt die letzte Frage, wie definiere ich severity da gibt
es auch in der in der Community verschiedene Meinungen zu was
wir machen ist wir haben einfach Beispiele genommen, wir haben
gesagt hier haben wir ne Handvoll Incidents, das waren
für uns die SEV Einser. Das sind so, wenn du auf n
halbes Jahr zurückguckst. Das sind die, die die in
Erinnerung bleiben. Wir haben zum Beispiel in der
Cyberweek einmal unsere gesamte DNS Config genjuckt in AWS, das
ist so ein memorable SEV One, wo einfach alle internen Tools
nicht mehr funktioniert haben, ja und externen Tools ja
telefonbuchseite. Zerrissen quasi für die Leute,
die jetzt das nicht ganz verstanden haben.
Also DNS irgendwie DNS verjuckt heißt die die.
Du erreichst nichts mehr, wo es mal irgendwie sein sollte.
Die Telefonbücher und die Nummern haben sich irgendwie,
die Zuordnung hat sich irgendwie verändert, aber kurz
zwischendurch ja. Genau und zum schlechtest
möglichen Zeitpunkt. Und wir haben dreieinhalb
Stunden gebraucht, bis wir den Shop wieder im Laufen hatten und
11 Stunden bis wir internen Tools wieder am Laufen hatten.
Ja also ja es ist ne sehr sehr nette Geschichte, ich hätte dir
dieses Jahr schon mal auf einer Konferenz erzählt, deswegen fühl
ich mich jetzt hier auch komfortabel das zu scheren.
Da gibt es auch n blogspot zu. War sehr memorable ist da
metapata Incident oder tatsächlich von einem Typo wo
immer Meta Data stehen sollte, da hat sein Infrastruktur
Engineer NP zu viel eingefügt und dann ist Automation
Losgetriggert und hat einfach alle die NS entrys Ausgejuckt
von allen Clustern. Also ich glaube ja, dass diese.
Story von dem die, die kennt ihr alle mit dem Schmetterling oder
dem Falter, der dann den den den, den den Falterschlag macht
und dann steht steht irgendwo auf der anderen, auf dem anderen
Kontinent n Orkan. Das gibt es ja hier.
Ne die wie heißt das gleich? Ich hab es vergessen, Butterfly
Effect der Butterfly Effekt danke den gibt es eigentlich in
der Software viel stärker als jetzt hier über irgendein
Butterfly. Ja das ist nämlich tatsächlich
so, manchmal reicht n Komma oder n doppelter Buchstabe oder
irgend so was an der falschen Stelle zur falschen Zeit falsch
deployed und man kann sich das nicht vorstellen als
normalsterblicher und dann gehen halt weiß weiß ich zehneinhalb
Millionen teilen Code und die entsprechende Infrastruktur
einfach bar. Das sind aber dann auch die
schönen Dinger, muss man sagen. Die sind dann die Dinger hat,
wenn man sie dann findet, sind sie auch schnell gefixt, ja,
also weil dann stellen pack ich das kommen wir halt wieder hin
und und dann geht es auch schon wieder einigermaßen, stimmt
nicht ganz, weil in der Zwischenzeit ist halt alles
mögliche, weil die Leute Leute empfangen ja also ihr habt ja
einfach viele requests ne und ich dann krieg ich in
konsistente Daten oder Irgendsowas und sofort da hab
ich Notfall dann muss ich was abräumen danach noch hab viel
ich hab glaub ich viel bereinigungsarbeit und so weiter
da hat mir da Konsistenz hinzuschieben und sofort ja.
Ja, kommt. Immer drauf ankommt, drauf an.
Denn wenn keine Daten reinkommen, dann ist oft nicht
so schwer, wenn falsche Daten reinkommen ist horrible.
Ich mag noch mal. Also wie ich würd gerne noch mal
kurz auf dem Incident bleiben, aber ich mag noch mal n bisschen
anderes Thema anschneiden und wir gehen auch so n so n
bisschen in die Verlängerung sag ich mal.
Aber das das würd ich gerne schon noch mal irgendwie auf die
Tonspur bringen und zwar incident detection fänd ich
jetzt mal ganz spannend. Du hast jetzt ganz am Anfang
gesagt ich hab dir direkt gleich das auf meinen Zettel
geschrieben, find ich total spannend weil.
Klar, jetzt haben wir da gesprochen, wir wissen nen
Incident und wir gehen dann durch die Stack traces, aber
woher wissen wir denn überhaupt, dass es n Incident gibt?
Das ist ja auch n Riesenthema das du sitzt halt im Sessel und
guckst im Notfall irgendwie auf irgendeine Konsole von irgendwo
hin, da weißt du ja auch nicht, dass Zalando kaputt ist.
So ja und also meine Frage zielt darauf hin, ich verstehe Ihr
habt eine riesen Datenbank mit Riesen vielen Daten die da
einfließen von allen Systemen auf allen möglichen
Abstraktionsebenen und jetzt wär es ja schick vielleicht sogar
mit KI. Zu sagen, OK, das hier ist der
Normalzustand und jetzt will ich quasi alarms kriegen, wenn sich
diese Wolke von datenpunkten und von Parametern und Prozessen,
die sich normalerweise so die normalerweise so wabert, ich sag
es mal ganz grob ja, wenn die jetzt irgendwie anders wabert,
ja, wenn ich irgendwie n Zacken klickt oder irgendwie so, das
muss ich ja irgendwie erkennen können und dann müsste ich
eigentlich so n Incident Report bekommen und schon mal.
Also du müsstest wahrscheinlich irgendwie ne e Mail bekommen und
sagen, so, hier ist irgendwas anders als sonst, ja oder ergibt
sowas, habt ihr sowas? Wie kriegt ihr sowas mit?
Es ist echt ne tolle. Frage und auch diese diese
Beschreibung, wie man sich das naiv vorstellt, es ist ist sehr
sehr gut und das ist n Pfad wo sehr viele Leute diesen Pfad
runtergehen und extrem verbrannt werden, weil es stellt sich
raus, dass dieses System jedes IT System was hinreichend
komplex ist, sehr instabil ist. Du hast am Tag irgendwie 100
Deployments oder 1000 deployments ja, aber auch schon
bei einer kleineren Architektur, da du hast ja irgendwie
wenigstens ein Team, das verändert dieses System
andauernd. Und dann hast du load pattern
changes, dass du teilweise OK, du siehst einfach keine
Requests, weil die Leute alle aufs Klo gegangen sind.
Oder du siehst zehnmal so viele Requests, weil irgendwie gerade
n Product Release war oder n Marketing push, wo irgendwie
Leute viel gekommen sind. Das heißt du hast ne enorme
Varianz in diesen Daten drin und das ist für ne KI oder für n
automatisiertes System ganz ganz ganz schwer zu sagen ist das
expected variance ist es auch wenn du errors hast.
Das ist interessiert das überhaupt jemanden oder ist das
brennst gerade und das diese Korrelation von OK du kriegst
diese diesen Schwall an Daten und das The Business Care ist
extrem schwer und was in aller Regel passiert, es funktioniert
ganz OK, aber du hast dann ne false positive Rate von
vielleicht auch nur 2% aber. Diese 2% auf ne sehr hohe Basis
an quasi Requests oder Events die reinkommen.
Die verhageln dir komplett die deine on Call rotations, weil du
ständig gefragt wirst. Jetzt ist nicht nur oh Scheiße,
die teilzehn Datenbank macht gar nichts, sondern es ist Hey guck
mal, ich hab diese Anomalie gefunden, diese Daten sehen
nicht so aus wie meine Baseline, willst du nicht vielleicht mal
gucken und du bist ich hab grad das Meeting und ich soll
eigentlich hier was entwickeln und ja.
Vielleicht machst du es dreimal und kannst aber nichts finden.
Oder du machst es dann irgendwann gar nicht mehr, weil
es dich einfach nur noch nervt. Und da sind eigentlich seit 10
Jahren laufen in dieses Problem alle rein, wieviel Unternehmen
die das alle probiert haben, es hat einfach nie funktioniert,
vielleicht jetzt mit Large language models wir bessere
Shots I don't know wir machen es ganz anders.
Jetzt kommt es. Jetzt bin ich gespannt.
Genau. Also meine meine Philosophie
oder eine andere Dynamik, die du auch oft hast, ist OK.
Du hattest n Incident und dann fragst du dich, na ja, welchen
Alert musst du jetzt konfigurieren, dass du mit
dieses Problem das nächste Mal detektierst läuft in dasselbe
Phänomen rein. Auf einmal hast du ganz viele
Sachen, das heißt, was wir eigentlich sagen, lass mal die
Rechner Rechner sein, lass mal die errors Error sein wir wir
kümmern uns gar nicht so drum ob die ob die Datenbank sich gerade
in die Hosen scheißt oder ob die Applikation gerade.
Jede Menge Logs ausspuckt We Care.
Ob die Nutzer happy sind, wir wir, wir kümmern uns drum können
die Nutzer die Homepage surfen, können die Nutzer einen Checkout
machen, können die Nutzer ihren Warenkorb benutzen, können die
Nutzer ihre Adresse ändern das sind die Sachen, die wir gerne
hätten, solange die Nutzer alles machen können keine Alerts, kein
kein Grund sofort alles stehen und liegen zu lassen und zu
sagen sagen zu OK müssen jetzt sein.
Man kann vielleicht n Ticket aufgemacht werden oder da kann
ne e Mail geschrieben werden an das Team die sagt Hey das sollte
man sich mal angucken, aber es sollte nicht sein.
Alle stehen und liegen lassen sofort hier ran an den Speck und
die Technik die wir da verwenden um dieses High Level alerting
hinzukriegen, das sind SLOS da hattet ihr glaub ich auch vor
vor kurzem mal ne Folge zu Service Level Objectives die
sind bei uns sehr sehr stark von der produktjourney geankert also
wir haben quasi die Frukmanager gefragt was sind denn die
Funktionen die Zalando so hat? Und dann?
Dann haben wir versucht, jedes einzelne Ding zu messen und
meistens ist es einfach eine spezielle Query gegen diesen
Datenstream von Traces, den wir gesehen haben.
Es ist einfach OK, es ist dieser Button oder in dieser
Applikation muss genau diese Funktion aufgerufen werden und
dann man will wissen was ist die Errorrate von dieser Operation
und so das High Level Alerting for Zalando funktioniert im
Prinzip so, du hast so n Satz von vielleicht 102 100 SLOS die
quasi diese User Journeys abcovern und wenn die alle grün
sind. Da gibt es schon mal keinen
Grund, Panik zu so, und das ist jetzt.
Irgendwie quasi nen Bot, der ist programmiert und zieht diese
Requests durch und kriegt hier entsprechenden erwarteten
Antworten n bestimmten Zeitfräser oder wie und das
läuft die ganze Zeit oder wie stell ich mir das vor?
Nee, es ist. Kein Bot, das ist der echte User
Traffic, das ist der echte Nutzertraffic, den Wir nehmen.
Ah. OKOKOK jetzt hab ich OK das OK
verstanden. Magst du quasi ob ich hab?
Noch was anderes. Im Kopf.
Man könnte ja auch sagen, ich, ich, ich, ich, ich programmiere
einen Roboter user. Und dann kenn ich meine User
Journeys und der klickt halt diese ganzen User Journeys
durch, automatisiert, und zwar immer wieder ja und weil das der
Roboter User ist, hat er ne spezielle ID und der zahlt halt
nix oder irgendsowas der darf das halt alles machen, aber der
kriegt diese User Journey trotzdem jetzt stell.
Dir vor paypal ist Broken für Nutzer in Spanien hast du nen
Nutzer, der immer aus Spanien kommt und immer paypal
auscheckt. Und du hast so kombinatorische
Probleme. Du hast dann irgendwie 5 Feature
flags und verschiedene Nutzergruppen.
Android war irgendwie Broken, in gewisser Hinsicht musst du
wieder NP komplett. Das Problem irgendwie gefühlt
haben die die Kombinatory. Explodiert komplett.
Du hast bei jedem Service irgendwie 3 verschiedene
Varianten und im Vorhinein quasi Roboter finden zu wollen die die
dynamisch genug sind es es funktioniert nicht.
Du hast quasi Unit Testing was wenn du einen kleineren
kombinatorischen Raum hast funktioniert.
Und du hast natürlich an einzelnen Stellen noch n paar
Probs. Also jetzt so was wie Red Reset
Passwort wo du wenig Varianz hast.
Das kannst du so proben, aber die Idee, dass du den gesamten
Shop mit der ganzen Komplexität mit Robot Usern abcovert das das
funktioniert nicht und es wäre auch sehr sehr teuer wenn du es
probieren würdest, weil du musst diese ganzen Journeys ja alle
konfigurieren, das heißt No hanging Fruit und auch sehr sehr
nah an der Business Relevanz ist einfach observed the behavior of
the actual users ja du hast also.
In jeder. User Story, die du so hast auf
deiner Website oder in eurem Shop ein bestimmtes Key Element
oder eine Key Event oder mehrere, vielleicht sogar die,
wenn sie funktionieren, auf Grün stehen und in dem Moment wohl
ein User nicht in der Lage ist dazu das durchzuführen, sagst du
der kann. Nicht machen, was er eigentlich
gerne möchte und dann wird es rot.
Ja und dann kriegt er da Leute oder so und beim ersten aber
auch nicht, vielleicht nicht die Grundidee, die Grundidee.
Ist wichtig, aber du aggregierst natürlich.
Du sagst irgendwie in der letzten Stunde haben mehr als 2%
der Nutzer n Problem gehabt, da müssen wir mal reingucken.
Ja OK ist. Immer für uns n bisschen anderer
Scale. Ja ist immer spannend für euch
ist das ja richtig Statistik sag ich mal an der Stelle dann ja,
das ist dann. Das Gesetz der großen Zahlen der
großen User, das ist auch total krass.
Man kann sich irgendwie. Also selbst wenn du nen Cloud
Anbieter bist und aber wenn seine Kunden alle aus
Deutschland kommen, dann hast du schon mal n ganz anderes
reduziertes Problem als wenn die halt dich auf dem Globus
verteilen, weil das hatte ich auch gerade nicht im Kopf, das
ist ja so, die Uhren ticken alle anders, da stehen noch mal
andere Datencenter, dann gibt es Kabel die im Wasser liegen und
so 1000 Sachen die der ganzen Komplexität eigentlich noch noch
den den Rest geben so ja da muss man sich echt mal überlegen wie
man es macht. Ja also ich ich.
Glaube ganz ehrlich gesagt, dass.
Diese Sicht, was macht denn, was interessiert den Nutzer, dass
das extrem vereinfacht, weil wenn du auf dieses auf wenn du
auf dieses Problem Zalando soll reliable sein drauf guckst mit
ich hab 10000 Rechner und hab 1000 Applikationen die sich da
ständig verändern du hast keine Chance da wird immer eine ganze
Menge Broken sein und du bist quasi bei diesem Haufen hast
ganz schwer haben rauszufinden was interessiert eigentlich
gerade jemanden bei wo lohnt es sich zu investieren?
Wenn du umgekehrt guckst, was ist die User Experience ist
wirklich sehr UI driven was sind die Funktionen, die High Level
bereitgestellt werden müssen und versuchst genau da anzusetzen
mit deinen Messungen, idealerweise sogar im Browser
oder nah an so nah am Nutzer wie möglich und dann sicherstellst
Hey, denn die Nutzer die haben keine großflächigen Probleme und
das ist die ist das der Gold Standard für Alerting.
Ja wir haben natürlich unser Datenbank Team hat auch
Datenbank Alerts ja wir wollen einfach nicht, dass die Customer
Datenbank Out of Memory läuft ja das das sollen wir verhindern.
Aber wenn wir mit Alerts einfach anfangen, immer was ist wer sind
unsere Customer? Was sollen unsere Customer tun?
Auch auf den verschiedenen Plattformenlayern?
Ja, was ist von einem CDP System was wenn du internes System
hast? Was sind die Customer, was
sollen die Customer tun und da sollten deine Alerts geankert
sein, die sollten nie geankert sein oh OK ich weiß wenn Reddits
mehr als 50% Memory hat, dann krieg ich potenziellen Problem,
dann mach ich mir n paging Alert der mich sofort notified wenn
Reddits über 50% Memory hat. Kein Business Impact ja bringt
nichts, ich verstehe. Ihr dreht das, ihr dreht das
die, die dreht die Kausalität da quasi rum, das macht Sinn, ja.
Passt es noch rein, wenn. Wir noch mal über dieses Open
Telemetry sprechen oder diesen Open telemetry Standard.
Du hattest das so mal vorhin so erwähnt, ja, den gibt es da
genau das. Ist vielleicht auch was für die
Nutzer oder die Zuhörer oder dich, lieber Zuhörer, den du das
gerade hörst, was du vielleicht auch selber mal ausprobieren
möchtest. Open Telemetry ist tatsächlich
NN Offener Standard, den man im Internet findet.
Da gibt es Libraries für alle möglichen, alle möglichen
Sprachen, es ist n Vendor Neutraler Standard, der uns auch
einfach als als Plattform dient, als als Zalando, um auch
Independence von speziellen Vendoren herzustellen, also
eigentlich auch immer aus kommerzieller Sicht interessant
und es gibt ne Menge Sachen zu entdecken, diese
autoinstrumentation Libraries für alle möglichen, alle
möglichen Telemetrie Typen und. Im homelap Kontext.
Ich hab es ist on Ramp ist natürlich n bisschen, man muss
sich da erst mal n bisschen reinfuchsen bis man das alles am
laufen hat. Man gibt da so ne
Kollektorkomponente die man auch lokal verwenden kann um zu
verstehen wie sehen die Daten aus die da rausgeschrieben
werden und so weiter aber wenn man das alles mal aufgesetzt
hat, was tatsächlich richtig cool ist, ist so die
Flexibilität die das bietet die Backends zu ändern.
Also du kannst ja bei Graphana einen Demo Account machen.
Du kannst bei Datadock einen Demo Account machen, du kannst
bei Chronos 4 einen Demo Account machen, du kannst bei der Zero
und Demo Account machen und dann kannst du die Daten einfach an
alle schicken oder an 1 schicken und dann woanders hinschicken,
aber das ist irgendwie wirklich nur 22 Klicks fast ja also 2
konfigurationslines die du in so ein konfigurationsding droppst
und dann bist du hast du deine ganzen Daten in ein anderes
Backend umgezogen und. Das ist tatsächlich ziemlich
sexy. Mit diesen Demo Accounts bin ich
auch im private Bereich gerade eher unterwegs als Self hosted
Telemetry, irgendwie Prometheus und Loki und was weiß ich alles
am Laufen zu halten und diese Tracing Datenbanken, das ist
nicht so Joy Ful Time die man da hat.
Also insofern denke ich im kommerziellen Kontext ist man
sowieso meistens auf diesen Vendor basierten Lösungen.
Home Context kann es Sinn machen mit diesen Demo Accounts zu
arbeiten oder Small Pate Accounts und dann bietet.
Open Tenemetry einfach ne sehr flexible Basis, wo man einfach
die Collection komplett Open Source Vendor nutral hat und
dann so n Central Data Hub hat, wo man auch Open Source
Komponenten oder Vendor Back Komponenten einfach anschließen
kann. Und ja Standard ist ne Community
die das macht seit ja 78 Jahren mittlerweile ursprünglich auch
von von Google mitgegründet und wir hatten ja über viel über
Distibuted Tracing gesprochen. Der Innovator von Distubuted
Tracing ist der Ben Siegelmann. Der war damals bei Google, der
hat dann diese Firma Light Step gegründet und der hat auch Open
Telemetry mit quasi gefounded und hat dann quasi das ist quasi
das Go to Technologie, gerade um auch dieses Distubuted Tracing
zu machen, aber alle Telemetrie Typen sind sind supported, also
heute moderne Telemetrie Stack ist eigentlich über um Open
Telemetrie rum gebaut ja voll gut voll.
Aktuell voll relevant auch für uns.
Hatte ich so auch noch nicht auf dem Zettel, guck ich mir an,
muss man glaub ich mal schauen, packen wir in die Shownotes
skirit. Was gibt es jetzt noch?
Was wir noch zu observability Distributed Tracing Metriken
logs sagen müssen, was vielleicht noch gesagt werden
muss, es gibt schon mal ganz viel, aber vielleicht haben wir
noch irgendwas nicht gecovert, was du gerne covern wolltest.
Ja, ich würd vielleicht zum. Abschluss einfach sagen.
Es ist so dieses Curiosity Thema was mich bei Observability auch
hält ist wirklich diese Kernfrage, was macht mein
Rechner eigentlich? Was wie kann ich das rausfinden?
Und da haben wir natürlich in verschiedenen Kontexten
verschiedensten Tools, die uns das quasi näherbringen oder die
uns das erlauben, aber es ist einfach n relevantes und
spannendes Problem und da gibt es total für die Historie auch
noch damals hörtest du diesen Raumschiff Enterprise Rekorder
Analogie Solaris damals hatte so Technologien mit denen man da
noch viel besser reingucken konnte in die Prozesse die wir
auf Linux vielleicht jetzt so langsam auch bekommen.
Aber ich rechne damit, dass wir so in Richtung Continuous
Profiling, Dynamic Instrumentation noch ne Menge
sehen und das hat man ja in allen Kontexten, ja, sei es
irgendwie Web, sei es embedded, sei es Enterprise, sei es
privat, sei es homelab, man läuft immer in diese Probleme
rein und ich freue mich auf so n Linux MCP, wo ich nachher JTBT
einfach fragen kann, hey, was macht mein Rechner einfach, ja.
Und das für mich ist da noch ne Menge drin was Observability
angeht, dass wir einfach nicht nur gut werden in unseren
Rechnern, sagen was sie tun sollen, sondern auch gut werden
in verstehen was macht das Ding eigentlich und was was sieht das
ja cool. OK dann sag ich.
Mal vielen dank, du hast den Bogen jetzt noch mal geschlossen
zum zum Eingang. Ja, hast du auch gesagt, es geht
drum zu verstehen was macht der Rechner ja nicht, wir sagen dem
Rechner was zu tun ist, sondern wir wollen wissen was er
eigentlich tut und warum. Und ja, von meiner Seite vielen
herzlichen Dank. War richtig cool, Spaß gemacht,
viel gelernt und hoffentlich bis bald noch mal.
Danke dir. Ja vielen Dank.
Für die Einladung sehr gerne ja, von meiner.
Seite vielen dank Herrn, ich hab viel gelernt.
Die Folge war super spannend, Deep Teig diesmal n bisschen
schnack gut alles klar Tschüss aus Hamburg ciao ciao.
Einfach komplex. Wird produziert und präsentiert
von Heisenware. Heisenware ist deine Low Code
Plattform zur Erstellung und zum Betrieb interaktiver Apps rund
um den Shopfloor. Starte noch heute deinen Free
Trial unterheisenware.com einfach minus komplex.