Observability mit Dr. Heinrich Hartmann von Zalando #91

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.