Ingo: Ja, ich bin jetzt hier auf der CubeCon 2024, bei mir ist Andreas Gramner und
Ingo: er ist CNCF-Ambassador und Captain-Maintainer.
Ingo: Du bist seit 16 Jahren bei Dynatrace und da für Observability zuständig oder
Ingo: mit zuständig. Hallo Andreas.
Andreas: Servus, ja, freut mich, dass wir die Zeit finden hier in Paris.
Ingo: Und ich habe tatsächlich überhaupt gar keine Ahnung, was Captain ist,
Ingo: aber das ist so eins der Sachen, die du als Maintener da häufig mit am meisten
Ingo: gerade machst. Vielleicht kannst du uns mal erklären, was bedeutet Captain?
Ingo: Man klingt schon so, als hätte es irgendwas mit Kubernetes zu tun. Ja, aber so richtig.
Ingo: Genau, was ist das? Wofür brauche ich das?
Andreas: Ich erkläre dir mal das Problem, was wir damit lösen wollen.
Andreas: Und zwar das Problem bei Kubernetes.
Andreas: Einige der Hörer werden hoffentlich wissen, was Kubernetes ist und wie Kubernetes funktioniert.
Andreas: Aber um es simpel zu sagen, wenn man eine Anwendung auf Kubernetes deployt,
Andreas: dann deployt man ja einen oder mehreren sogenannten Workloads,
Andreas: zum Beispiel ein Frontend, ein Backend, eine Datenbank. Die deployt man,
Andreas: indem man Manifeste schreibt, indem man definiert, was man da deployed haben will.
Andreas: Dann macht man entweder ein kubectl apply oder man verwendet Tools wie Argo
Andreas: oder Flux dafür und dann hofft man, dass einfach alles am Schluss gut läuft.
Andreas: Und Kubernetes selbst ist ein bisschen wie ein Blackbox. Da gibt es einen Kubernetes
Andreas: Pod Scheduler, der nimmt diese Anfragen und sagt, okay, ich brauche hier drei Pods.
Andreas: Dann sucht der Kubernetes Pod Scheduler den richtigen Platz und deployed es
Andreas: dann und hoffentlich alles ist grün.
Andreas: Das Problem ist aber, was ist, wenn das nicht so funktioniert?
Andreas: Was ist, wenn man wartet eine halbe Minute, eine Minute, zwei Minuten,
Andreas: fünf Minuten und irgendwie wird das Deployment nie fertig.
Andreas: Wieso ist das so? Natürlich kann man dann Troubleshooting machen.
Andreas: Man kann dann reingehen, wenn man sich auskennt mit Kubernetes,
Andreas: Logs gucken, Describen vom Deployment und alles mögliche.
Andreas: Jetzt ist aber so, dass natürlich nicht jeder so versiert ist mit Kubernetes
Andreas: und außerdem willst du in einer Organisation nicht jedem das Ganze lernen.
Andreas: Was Captain jetzt macht, Captain bietet Observability in das Deployment selbst
Andreas: das heißt, wie auch immer du jetzt deployst auf Kubernetes, sei es mit kubectl
Andreas: apply, mit Argo, mit Flux, mit Jenkins, wie auch immer.
Andreas: Erzeugt Captain einen sogenannten Distributed Trace, verwendet OpenTelemetry
Andreas: OpenTelemetry ist auch ein großes, prominentes Projekt Das heißt,
Andreas: wir erzeugen einen Trace, der genau zeigt,
Andreas: von Anfang, wo du den Request absetzt auf Kubernetes, um einen oder mehreren
Andreas: Workloads zu deployen, bis zum Schluss erzeugen wir einen Trace,
Andreas: der genau zeigt, wann Kubernetes,
Andreas: welchen Pod, wohin deployed hat, wie lange es gedauert hat, wo was gut gegangen
Andreas: ist, wo was schlecht gegangen ist.
Andreas: Das heißt, wir verwenden Distributed Tracing, nicht im traditionellen Sinn vom
Andreas: Tracen eines Requests in einer End-User-Anwendung vom End-User bis zur Datenbank,
Andreas: sondern vom ersten bis zum letzten Bot.
Andreas: Und das Zweite, was dann Captain auch noch macht, Traces sind gut für Aero-Analyse,
Andreas: wenn ein Deployment nicht gut läuft.
Andreas: Wir erzeugen aber auch Metriken. Metriken zum Beispiel, wie oft wird ein Deployed,
Andreas: wie lange dauert das Deployment, wie viele gehen gut, wie viele gehen schlecht von den Deployments.
Andreas: Und das sind so Teile dieser DORA-Metrics, dieser DevOps-Metriken,
Andreas: die viele Organisationen eigentlich verwenden, um zu messen,
Andreas: wie gut die Entwicklungsumgebung eigentlich
Andreas: ist oder wie gut die Entwicklungsmannschaft, wie oft deployed wird.
Andreas: Und das heißt, Captain bietet das einfach an, indem man Captain installiert
Andreas: und ihn pro Namespace aktiviert und man bekommt dann automatisch Prometheus-Metriken
Andreas: und Open-Telemetry-Adresses.
Ingo: Und diese Sachen muss ich mir ja noch irgendwie anzeigen, damit ich ein Grafana führe oder...
Andreas: Genau, was auch immer. Das heißt, im Endeffekt, wir erzeugen ja quasi was ich
Andreas: OpenTelemetry Traces und Prometheus Metricen, wenn du jetzt dort die Daten kannst,
Andreas: jetzt auf Jäger schicken, um einen Jäger Tracer anzusehen.
Andreas: Du kannst das irgendwo in ein Backend schicken und dann zum Beispiel mit Grafana visualisieren.
Andreas: Du kannst es natürlich auch an irgendeinen der EPM oder Observability Vendoren
Andreas: schicken, weil die meisten verstehen mittlerweile OpenTelemetry und Prometheus.
Andreas: Das heißt, die Visualisierung überlassen wir dem End-User, weil der End-User
Andreas: hat ja schon irgendwie sich festgelegt, wie er Observability Daten visualisiert.
Ingo: Ja, die meisten haben natürlich eine Lösung dafür.
Ingo: Das heißt, ich muss aber jetzt keine CI-CD-Pipeline haben, um Captain zu benutzen? Nein, klar nicht.
Andreas: Es ist im Endeffekt nur ein Tool, das ich quasi in meiner Plattform habe.
Andreas: Wir sprechen sehr viel mit Plattform-Ingenieurs, die jetzt gerade auf Kubernetes
Andreas: aufbauend gewisse Tools einsetzen, um eben diese Developer-Experience einfacher zu machen.
Andreas: Das heißt, da wird Argo oder Flux verwendet für GitOps-Deployments.
Andreas: Dann, wie gesagt, Captain spielt da glaube ich sehr gut rein und Captain wird
Andreas: dann im Endeffekt nur mehr auf Namespace-Ebene enabled über eine Annotation.
Andreas: Das heißt, das kann man auch wieder dann pro Namespace aktivieren oder eben
Andreas: nicht aktivieren und die Traces werden dann automatisch an das Observability-Backend geschickt.
Ingo: Das heißt, Captain arbeitet auch mit vielen verschiedenen Tools an der Stelle zusammen.
Ingo: Also ich bin da jetzt nicht festgelegt, wenn ich jetzt sage,
Ingo: oder wenn jetzt jemand denkt, okay, ich setze Captain ein, dann heißt es nicht,
Ingo: ich muss unbedingt Argo CD nehmen, ich muss unbedingt das und jenes nehmen.
Ingo: Also die sind austauschbar.
Andreas: Ganz genau, weil wir, Captain hängt sich quasi in den Kubernetes Pod Schedule rein.
Andreas: Der Pod Schedule ist die zentrale Komponente in Kubernetes, die,
Andreas: wenn eine Anfrage reinkommt, über ich möchte gerne dieses Diplomate machen,
Andreas: der Pod Schedule nimmt diese Anfrage und versucht sie dann quasi zu erfüllen.
Andreas: Indem er sagt, okay, welchen Pod habe ich hier?
Andreas: Okay, der braucht so viele Microcores, so viel Memory.
Andreas: Wo wird denn der hindeployed? Und wir haben da quasi eine Möglichkeit über Webhooks in Kubernetes,
Andreas: um uns dort reinzuhängen Und somit können wir unabhängig, welches Tool jetzt
Andreas: deployed oder welches Tool die Anfrage an Kubernetes stellt,
Andreas: etwas zu deployen, können wir diese Adresses erzeugen. Und das ist das Schöne daran.
Andreas: Ich verwende jetzt nicht mehr Argo und Flux als Beispiel, weil es ja sehr prominente
Andreas: Tools sind in diesem Umfeld.
Ingo: Aber ihr könnt auch das mit GitLab einfach so machen oder mit GitLab Runner
Ingo: oder darauf verzichten, wie wir auch.
Andreas: Oder darauf verzichten, genau.
Ingo: Okay, und das per Hand sozusagen machen. Okay, und Captain, muss ich das als
Ingo: Developer mir überlegen, dass ich das verwenden will?
Ingo: Oder frage ich da meinen Infrastruktur-Team und sage, ich hätte gerne diese
Ingo: Observability-Daten schon und dann überlegt sich das Infrastruktur-Team,
Ingo: okay, dann machen wir es mit Captain.
Andreas: Ja, grundsätzlich glaube ich, sind es immer die Teams, die auch das Delivery
Andreas: reinbringen in eine Kubernetes-Umgebung.
Andreas: Also die gleichen Teams, die
Andreas: GitLab oder Jenkins oder Argo und Flux reinbringen in eine Organisation,
Andreas: sagen dann, hey, wir sehen, dass oft Pipelines schieflaufen,
Andreas: wie können wir bessere Diagnose bringen und da gibt es Captain als Tool, das heißt, das Team,
Andreas: ich sage jetzt mal Plattform Engineering sehen wir halt sehr oft oder DevOps
Andreas: Team oder Infrastructure, wer auch immer verantwortlich ist,
Andreas: um diese Tools auf Kubernetes zu bringen, die würden dann auch Captain reinbringen.
Andreas: Aber der Entwickler hat dann pro Namespace die Option, über eine Annotation
Andreas: zu sagen, ich möchte jetzt auf meinem Namespace, wo ich meine App deploye,
Andreas: wirklich auch Captain aktivieren.
Ingo: Okay, also es ist selbst keine Pflicht. Nein, keine Pflicht.
Ingo: Es heißt auch nicht, dass ein Team dann, oder wenn Infrastruktur festgelegt
Ingo: hat, okay, wir würden Captain verwenden, aber jemand sagt, brauche ich nicht.
Ingo: Ich will jetzt diese, weil keine Ahnung, wie viel Potts das Ding dann jetzt
Ingo: noch mit aufmacht. Kannst du vielleicht nochmal erklären?
Andreas: Genau, es ist einfach nur ein Operator. Das heißt, der Operator hängt sich dann
Andreas: über einen Webhook in Kubernetes rein und wir haben selbst sonst keinen Overhead
Andreas: mehr. Das ist das Schöne daran.
Andreas: Wir haben jetzt eigentlich sehr low Overhead, weil wir hängen uns eine zentrale
Andreas: Komponente in Kubernetes rein über einen Webhook.
Andreas: Aber wir sind nur aktiv, wenn dann Kubernetes uns sagt, hey,
Andreas: da gibt es jetzt ein Deployment in diesem Namespace und wir sehen dann noch,
Andreas: ist dieser Namespace annotiert, ob Captain aktiv sein soll, ja oder nein.
Andreas: Wenn nicht, macht man gar nichts. Wenn ja, erzeugen wir einen Trace.
Ingo: Apropos Hooks, ich habe auch gelesen, dass ihr so Pre-Hooks oder Post-Hooks
Ingo: irgendwie haben könnt, dass man davor und danach ein Deployment...
Andreas: Danke, dass du das aufbringst, weil das ist der zweite große Use Case.
Andreas: Also der erste ist quasi die Observability.
Andreas: Wie oft wird deployed? Was passiert beim Deployment? Wie lange dauert es? Wo läuft es schief?
Andreas: Das Zweite ist, was wir auch gelernt haben, nur wenn man jetzt deployed und
Andreas: am Schluss vom Deployment sind alle Pods laufen und healthy,
Andreas: heißt das nicht, dass die Anwendung läuft.
Andreas: Da gibt es viele Sachen. Entweder man hat eine Anwendung deployed,
Andreas: aber die pending der Datenbank ist eigentlich auch falsche und im Endeffekt,
Andreas: gehe ich jetzt auf ein falsches externes System oder ich deploye,
Andreas: habe aber meinen Ingress falsch konfiguriert. Deswegen kommen jetzt keine User drauf.
Andreas: Es gibt zwei Sachen, die schieflaufen. Ich sage immer pod healthy does not mean
Andreas: application healthy and accessible.
Andreas: Jetzt bietet Captain zwei Möglichkeiten an. Pre- und Post-Deployment,
Andreas: das heißt, bevor dann Kubernetes, Pods, Kettle, wirklich anfangen zum Deployen,
Andreas: können wir Tasks und Evaluations ausführen.
Andreas: Das heißt, wir haben im Captain die Möglichkeit zu sagen, bitte führ diesen Task aus.
Andreas: Ein Task ist, ähnlich wie bei GitHub Actions, einfach ein Container,
Andreas: beziehungsweise wir bieten auch an, über TypeScript Script Functions zu schreiben,
Andreas: die wir in einem Container ausführen, die zum Beispiel sagen,
Andreas: ist das die pending environment da?
Andreas: Sind auf dem Git-Commit alle Requirements drauf? Also ich kann einfach Pre-Checks machen.
Andreas: Ich kann aber auch Checks machen gegen Observability-Daten. Zum Beispiel habe
Andreas: ich genug Ressourcen zur Verfügung?
Andreas: Ich kann auf Prometheus gehen oder auf andere Observability-Vendoren und sagen,
Andreas: ist das Environment überhaupt ready?
Andreas: Wenn das Environment nicht ready ist und diese Checks fehlen,
Andreas: dann geben wir an dem Pod Schedule auch weiter.
Andreas: Zurzeit können wir nicht deployen, weil die Pre-Checks nicht successful sind.
Ingo: Das würde dann auch anhalten an der Stelle?
Andreas: Das würde dann anhalten, genau. Das würde im Endeffekt das Gleiche bewirken,
Andreas: als wenn du auf deinem Kubernetes-Cluster nicht genug CPU oder Memory hast.
Andreas: Dann würde im Endeffekt auch der Pod-Scheduler sagen, du, es tut mir leid,
Andreas: ich habe nichts gefunden.
Andreas: Ja, genau. Und in dem Fall sagt dann der Pod-Scheduler, du, es tut mir leid,
Andreas: aber der Captain sagt, es geht zurzeit nicht.
Andreas: Und das Gleiche, was wir Pre-Check machen, Pre-Deployment Checks,
Andreas: machen wir auch Post-Deployment. Das heißt, als Post-Deployment-Check kannst
Andreas: du auch wieder sagen, hey, jetzt möchte ich wirklich sicherstellen,
Andreas: dass meine Anwendung auch von außen zugreifbar ist.
Andreas: Jetzt setze ich meinen Curl-Request auf den Endpoint. Oder ich frage jetzt mein
Andreas: Observability-Tool, ob meine SLOs nachher vor alle grün sind.
Andreas: Das heißt, vorm Deployment verhindern oder zumindest validieren,
Andreas: ob das Environment überhaupt ready ist und nach dem Deployment verifizieren,
Andreas: dass nicht nur die Pods laufen, sondern auch wirklich die Anwendung zugreifen. verliebt wird, genau.
Ingo: Funktioniert, okay.
Andreas: Genau.
Ingo: Und weil du jetzt gesagt hast, ich kann ein Curl-Request oder sowas absetzen,
Ingo: wie programmiere ich das?
Ingo: Muss ich mich da an irgendeine beschützte Programmiersprache halten oder kann
Ingo: ich einfach jedes Skript aufrufen oder wie funktioniert das?
Andreas: Es gibt grundsätzlich die Möglichkeit, einfach einen Container zu definieren.
Andreas: Das heißt, wir starten dann einfach den Container via GitHub Action.
Andreas: Du kannst jeden ledigen Container einfach.
Andreas: Dieser Container bekommt natürlich dann Kontext mit von uns.
Andreas: Das heißt, in welchem Kontext wird ausgeführt?
Andreas: Pre- oder Post-Deployment-Check. Für welche Anwendung? Das heißt,
Andreas: das wird alles mitgegeben.
Andreas: Wir bieten auch an, eine TypeScript-basierte Sprache, also auch in TypeScript
Andreas: kannst du schreiben und das packen wir dann in eine Dino-Runtime.
Andreas: Das heißt, für schnelle Checks kannst du einfach in TypeScript programmieren
Andreas: und einfach ein schnelles Curl-Request absetzen.
Andreas: Aber die einfachste Variante ist vermutlich einfach einen Container zu nehmen, wo alles schon drin ist.
Ingo: Wenn man vielleicht sowieso hat, weil man das vorher ja auch schon irgendwie
Ingo: mal gemacht hat, geguckt hat, ob es an der Anwendung läuft oder solche Sachen.
Andreas: Genau, und diese Metric-Checks oder wir nennen es Objectives-Checks oder SLO-Checks,
Andreas: Service Level Objectives-Checks, da braucht man selbst nicht Coden,
Andreas: sondern da kann man einfach nur definieren, ich möchte von Prometheus diese
Andreas: Query absetzen oder ich möchte, ich arbeite bei DeinAdress, bei DeinAdress gibt
Andreas: es auch eine Integration,
Andreas: ich möchte von DeinAdress diese und diese Metric haben und ich möchte gerne
Andreas: validieren, vorm oder nach dem Deployment, dass diese Metric in einem gewissen Wertebereich steckt.
Andreas: Wir nennen diese Komponente den sogenannten Captain-Matrix-Server.
Andreas: Das heißt, der Captain-Matrix-Server selbst holt sich Metriken von,
Andreas: Datensourcen, Prometheus, Dynatrace, Datadog, New Relic,
Andreas: Splunk, was auch immer, holt sich diese Metriken rein,
Andreas: zurück in Kubernetes und wir verwenden sie dann für diese Checks,
Andreas: wo dann der Entwickler dann sagen kann, ich möchte gern nach dem Deployment,
Andreas: dass meine Availability basierend auf meinem Monitoring-Tool immer noch 100%
Andreas: ist oder dass ich eine gewisse Response-Time habe.
Ingo: Und wenn so ein Post-Check dann fehlt, was mache ich dann?
Ingo: Also beim Pre-Check, okay, da höre ich auf. Beim Post-Check baue ich jetzt alles
Ingo: wieder ab und sage Hilfe.
Andreas: Beim Post-Check können wir das Rollback natürlich nicht direkt machen,
Andreas: aber beim Post-Check wäre es dann so, dann würde das im Endeffekt als Status aufscheinen.
Andreas: Zum Beispiel in Algo oder man würde dann zum Beispiel einen Workflow triggern,
Andreas: der dann das Rollback macht und man würde Leute notifizieren.
Andreas: Wir haben dort leider von der Kubernetes-Architektur nicht mehr die Möglichkeit,
Andreas: das Kubernetes selbst zu sagen, Rollback.
Andreas: Aber da würde man zum Beispiel zum Thema Progressive Delivery,
Andreas: da gibt es ja viele Tools wie zum Beispiel Argo Rollouts. Man könnte doch Argo
Andreas: Rollouts steuern damit.
Andreas: Und dann würde Argo Rollouts, also ein Higher Level Tool, eigentlich das Rollback dann vornehmen.
Ingo: Wäre natürlich auch wichtig, gerade wenn es irgendeine produktive Anwendung
Ingo: ist, zu sagen, ja okay, mein Deployment hat nicht richtig funktioniert,
Ingo: ich muss schnell wieder zurück, um auf den Stand zu kommen, der bis vor ein
Ingo: paar Sekunden eben noch richtig funktioniert hat.
Ingo: Das will ich natürlich schon haben. Das heißt, ich kann auf jeden Fall eine
Ingo: Message, egal ob das E-Mail oder Slack oder irgendwas, rausschicken und dann
Ingo: meine Entwickler sagen, halt hier.
Andreas: Genau, es geht wieder über diese Tasks. Das heißt, diese Tasks werden ausgeführt,
Andreas: nachdem die Evaluations ausgeführt werden. Das heißt, der Task bekommt dann auch mit.
Andreas: Post-Deployment ist jetzt der Post-Deployment-Evaluation-Task,
Andreas: also die SLOs, diese Metriken sind die grün oder rot.
Andreas: Und aufgrund von dem kannst du dann auch reagieren und sagen,
Andreas: hey, alles ist grün, super, ich schicke nur eine Info-Message oder rot,
Andreas: jetzt mache ich ein Jira-Ticket auf.
Ingo: Was ist denn jetzt gerade neu bei Captain? Was habt ihr denn in letzter Zeit
Ingo: zusätzlich entwickelt oder wo seid ihr gerade dran vielleicht auch?
Andreas: Ja, vielleicht muss man es historisch, muss man es eben ja arbeiten,
Andreas: seit sechs Jahren an Captain. Und vor sechs Jahren hat die Welt anders ausgesehen in Kubernetes.
Andreas: Und wir haben auch, glaube ich, damals versucht, zu viele Probleme zu lösen.
Andreas: Wir haben dort unsere eigene UI gehabt, um eben diese Daten zu visualisieren.
Andreas: Wir haben auch eigene Workflows drinnen gehabt. Und fünf Jahre später,
Andreas: also jetzt, haben wir gesehen, unsere Community hat uns gesagt,
Andreas: hey, es ist zwar super, dass ihr eine eigene UI habt, aber eigentlich generiert
Andreas: sie Open-Telemetry-Daten in Prometheus und wir wollen diese Daten in unseren Observability-Tool.
Ingo: Also das heißt, ganz genau.
Andreas: Super Feedback. Ein paar haben
Andreas: natürlich die UI geliebt, aber der Großteil sagt, brauchen wir nicht.
Andreas: Das heißt, wir haben uns erstens einmal geschiftet auf, wir erzeugen wirklich
Andreas: Open-Telemetry in Prometheus und somit haben wir alles da abgehandelt. done.
Andreas: Wir haben eine eigene, wir haben es Sequences genannt, ähnlich wie ein Workflow.
Andreas: Wir brauchen keine Workflow-Engine mehr, weil es gibt Algo-Workflows und es
Andreas: gibt viele andere Workflow-Tools in Kubernetes.
Andreas: Das heißt, wir haben uns wirklich gesagt, wir fokussieren uns auf das,
Andreas: wo wirklich die Probleme, wo die Leute noch die Probleme haben.
Andreas: Das ist Deployment Observability, was wird deployed, was ist langsam,
Andreas: was schlagt fail und diese Pre- und Post-Deployment-Checks und Tasks.
Andreas: Und auf das haben wir uns jetzt fokussiert und heuer, also diese Woche,
Andreas: haben wir auch offiziell die Version 2.0 released.
Andreas: Das, was wir vor sechs Jahren gestartet haben, hat jetzt lange Version 1.0 geheißen.
Andreas: Dann haben wir in der Transition-Phase, das hat jetzt ungefähr eineinhalb Jahre
Andreas: gedauert, haben wir Captain Lifecycle Toolkit genannt, weil es ist um den Lifecycle
Andreas: von einem Deployment gegangen.
Andreas: Und dies haben wir jetzt offiziell auf Captain 2.0 benannt. Das heißt,
Andreas: Captain 2.0, die aktuelle Version, ist genau das, was ich jetzt erklärt habe.
Andreas: Und wir haben einen langen Weg gehabt bis dahin, aber wir haben uns jetzt wirklich
Andreas: den Sweet Spot gefunden. und wir bekommen auch das Feedback von der Community,
Andreas: speziell jetzt von der GitOps-Community, Argo Flux, dass wir hier wirklich ein Problem lösen.
Ingo: Okay, dass die Leute da wirklich happy sind, dass ihr das die Probleme angeht,
Ingo: die da auch wirklich drängend sind und nicht euch verkünstelt sozusagen.
Andreas: Ganz genau, ja.
Ingo: Okay, also ihr habt sogar rebranded, weil ich mich nämlich auch gefragt habe,
Ingo: was ist denn dieses Toolkit jetzt noch? Ist es nochmal ein anderes Produkt?
Ingo: Oder, nee, Captain 2.0 ist Ist Captain, genau.
Andreas: Ja.
Ingo: Ist genau das. Jetzt hast du ganz oft Open Telemetry gesagt.
Ingo: Was ist denn genau das? Was macht das besonders?
Andreas: Also Open Telemetry ist ja quasi ein Standard, wie Telemetry-Daten,
Andreas: Traces, Logs und Metriken eigentlich in einer Anwendung gecaptured werden.
Andreas: For a lack of better terms. Oft verlerne ich leider die deutschen Wörter schon.
Ingo: Ja, geht uns zu allen so, glaube ich. Genau.
Andreas: Vielleicht muss man ein bisschen zurückgehen in der Geschichte.
Andreas: Ich bin ja seit 16 Jahren bei der Dynatrace und die Dynatrace gibt es schon
Andreas: länger und davor hat es auch schon Observability-Tools gegeben.
Andreas: Nur die haben halt damals Monitoring-Tools geheißen, jetzt heißen sie Observability-Tools.
Andreas: Das heißt, viele dieser Tools, genauso wie bei der Dynatrace,
Andreas: wir haben Agenten geschrieben, also quasi Software-Komponenten,
Andreas: einen Software- Agenten, den man installiert hat und dieser Agent hat dann versucht,
Andreas: aus Anwendungen aus Java, .NET und so weiter Daten zu extrahieren.
Andreas: Metriken, Logs und Traces. es. Und jeder hat sein eigenes Süppchen irgendwie gekocht.
Andreas: Mit OpenTelemetry gibt es einen Standard. Da gibt es Standard Libraries für.
Andreas: Anwendungsentwickler, um zu sagen, wie kann ich jetzt meine Anwendung so erweitern,
Andreas: damit meine Anwendung Metriken generiert, Traces generiert oder sogenannte Spans generiert und Logs so,
Andreas: dass sie über OpenTelemetry, über diesen Standard dann nach außen gegeben werden
Andreas: und von jedem Observability Tool, von jedem Backend aufgegriffen werden können,
Andreas: egal ob das jetzt Jäger ist, Grafana, Elastic,
Andreas: Datadog, Dynatrace, New Relic.
Andreas: Es gibt quasi einen Standard auf der, wie werden die Daten generiert und das
Andreas: Protokoll, quasi die Daten, die da rauskommen.
Andreas: Und dann gibt es unterschiedliche Backend-Provider, sowohl Open-Source als auch
Andreas: kommerzielle, die dann diese Daten verstehen.
Andreas: Ja, und das ist auch der Grund, wieso wir bei Captain OpenTelemetry einsetzen,
Andreas: weil wir erzeugen sogenannte Traces und wir erzeugen Metriken und deswegen steigen
Andreas: wir natürlich auch auf einen Standard auf,
Andreas: weil wenn wir Standarddaten erzeugen, gibt es unterschiedliche Tools,
Andreas: die dann der End-User verwenden kann, um diese Standarddaten anzuzeigen und zu analysieren.
Ingo: Ja, und das eine Tool hat vielleicht den einen Vorteil und das andere Tool … Ganz genau, ja, genau.
Andreas: Genau.
Ingo: Ich muss aber als Entwickler jetzt wirklich aufpassen, dass meine Applikation
Ingo: diese Daten irgendwie erzeugen kann.
Ingo: Oder muss ich einfach nur eine Library einhängen und dann funktioniert das automatisch?
Andreas: Genau, also bei OpenTelemetry, wir sprechen jetzt über OpenTelemetry und nicht
Andreas: mehr über Captain, bei OpenTelemetry gibt es mittlerweile auch sehr viele Auto-Instrumentoren.
Andreas: Auto-Instrumentatoren. Ich hoffe, das ist ein richtiges deutsches Wort.
Andreas: Quasi angefangen hat es natürlich, es gibt ein SDK für die unterschiedlichen
Andreas: Sprachen und als Entwickler muss ich meinen Code ändern, um eben diesen Daten zu erzeugen.
Andreas: Mittlerweile gibt es für die meisten Sprachen schon Agenten,
Andreas: auch wieder Agenten, die halt automatische Instrumentierung machen und automatisch
Andreas: schon Traces und Metriken erzeugen.
Andreas: Das gibt es natürlich bei unterschiedlichen Runtimes. Ich bringe jetzt Java
Andreas: und .NET zum Beispiel, weil die kenne ich am besten.
Andreas: Dort gibt es Möglichkeiten, wie man sich in diese Runtime reinhängt und dann
Andreas: dynamisch bei der Ausführung vom Code sich in gewisse Hooks reinhängt und somit
Andreas: im Endeffekt für für kritische Methoden, die aufgerufen werden,
Andreas: automatisch Traces erzeugt.
Andreas: Das heißt, als Entwickler brauche ich bei vielen Sachen eigentlich nichts mehr
Andreas: machen, sondern ich bekomme eigentlich diese Traces und Metriken.
Andreas: Nur jeder Agent, jeder Auto-Instrumentor kann nicht wissen, welche Daten wirklich
Andreas: komplett relevant sind für jeden Entwickler.
Andreas: Weil ich kenne die Anwendung im Vorhinein nicht, wenn ich so einen Agenten schreibe.
Andreas: Und deswegen hat der Entwickler immer noch die Möglichkeit, seine spezielle
Andreas: Methode, die er haben will, Wenn er sagt, diese Methode ist wichtig für mich, ich möchte wissen,
Andreas: wann sie ausgeführt wird, wie oft und ich möchte auch noch diese und diese Methoden-Argumente
Andreas: capturen, dann kann der Entwickler das noch sagen, indem er einen Aufruf macht
Andreas: auf die OpenTelemetry Library.
Andreas: Und dann wird das, was er emittet, was er da erzeugt mit diesem Aufruf,
Andreas: quasi gemerged mit allem Restlichen, was OpenTelemetry so erzeugt.
Ingo: Okay, dann muss ich natürlich wieder auf der anderen Seite gucken,
Ingo: dass ich diese Daten mir entsprechend anzeige und dann daraus irgendwas mache oder eben noch nicht.
Ingo: Ich muss natürlich wissen, okay, wenn ich jetzt so eine Funktion habe,
Ingo: vielleicht, weiß ich nicht, hängt das Programm gerade in der dann öfter mal
Ingo: auf oder ich brauche einfach zu lange oder es ist eine Funktion,
Ingo: die irgendwo Daten irgendwo her beziehen soll und die Datenquelle ist gerade
Ingo: nicht da oder wie auch immer, dass ich da so etwas benutze.
Andreas: Und was auch schön ist, also ich bin in dieser Industrie schon relativ lange
Andreas: jetzt, seit 16 Jahren bei der Dynatrace, aber das coole an der Open Telemetry
Andreas: ist, dass sich hier wirklich alle Vendoren eigentlich jetzt zusammengegeben
Andreas: haben und gesagt haben, wir kontributen,
Andreas: weil im Endeffekt ist es ein Benefit auch für die ganzen kommerziellen Hersteller,
Andreas: weil das schwierigste oder eine sehr schwierige Komponente für Observability-Vendoren ist,
Andreas: diese Agenten zu entwickeln und zu maintainen.
Ingo: Und wenn man das für jede Sprache machen soll.
Andreas: Dann… für jede Sprache immer up-to-date und eigentlich ist es viel einfacher,
Andreas: wenn man sich auf einen Standard fokussiert und im Endeffekt dann die Entwickler
Andreas: von Runtimes, von Libraries, ich spreche jetzt mal Hibernate zum Beispiel,
Andreas: das ist nach wie vor eine sehr prominente Library oder andere Libraries,
Andreas: die Entwickler von diesen Libraries, die verwendet werden in vielen Anwendungen,
Andreas: die wissen am besten, was eigentlich wichtig ist, wenn deren Libraries aufgerufen werden.
Andreas: Das heißt, es ist viel besser, wenn die ihre Library schon vorinstrumentieren mit OpenTelemetry,
Andreas: sodass jeder Entwickler, der dann die Library verwendet, sicher sein kann,
Andreas: dass die Traces, die dann rauskommen, die richtigen Daten enthalten.
Andreas: Und das hilft auch den Vendoren, weil wir brauchen uns dann nicht mehr hunderte
Andreas: Entwickler halten, die ständig die Agenten updaten müssen.
Ingo: Ja, die immer nur hinterher programmieren. Das heißt, das ist auch der Grund,
Ingo: warum Dynatrace da hinterher ist und sagt, okay, wir committen uns da jetzt
Ingo: OpenTelemetry zu machen.
Andreas: Genau, plus wir haben auch Engineers, die wirklich aktiv an OpenTelemetry mitarbeiten,
Andreas: weil es ist ja nicht so, dass einfach, ja, ihr Community macht einfach mal,
Andreas: ja, natürlich, also sehr viele von den Observability-Herstellern haben auch
Andreas: Engineering-Ressources wirklich committed auf OpenTelemetry als Open-Source-Projekt,
Andreas: genauso wie wir, wir haben einige Engineers,
Andreas: die aktiv 100% nur an OpenTelemetry arbeiten, Wir haben unseren Code für gewisse
Andreas: Instrumentierungen von gewissen Sprachen zurück-contributed an OpenTelemetry
Andreas: und jetzt, wie gesagt, arbeiten wir aktiv daran, das weiterzuentwickeln.
Ingo: Das heißt, OpenTelemetry ist jetzt sozusagen der Standard da an der Stelle.
Ingo: Es ist auch mittlerweile eines der größten CNCF-Projekte, wenn ich das richtig gelesen habe. Genau.
Ingo: Und wie entwickelt ihr da mit anderen Firmen zusammen?
Ingo: Also habt ihr da irgendwie, ist das alles in der CNCF?
Ingo: Alles in der CNCF. Dass ihr da, weiß ich nicht, trefft ihr euch dann ab und
Ingo: zu mal und besprecht irgendwas?
Ingo: Oder ist es, weil es ein Community-Projekt ist, ist es sowieso aus jeder Firma sind da Leute dabei?
Andreas: Naja, es ist so, also wie jedes CNCF-Projekt und wie die meisten Open-Source-Projekte
Andreas: gibt es halt dort regelmäßige Meetings.
Andreas: Da wird im Endeffekt besprochen, was wird als nächstes angegangen.
Andreas: Und im Endeffekt sind wir halt dann einer dieser Firmen, die halt dort,
Andreas: oder Community-Members,
Andreas: die dort mitwirken und sich aktiv einbringen, also wie jedes andere Community-Projekt
Andreas: genauso und dort versuchen wir gemeinsam,
Andreas: auch mit unserer offiziellen Konkurrenz dort das Projekt weiterzutreiben.
Ingo: Weißt du, was als nächstes bei OpenTelemetry ansteht oder bist du da ein bisschen rauf?
Andreas: Ja, ich glaube, mit Traces hat es ja angefangen, Logs, Events, Metriken.
Andreas: Es geht einfach darum, die alle Signale von Observability abzudecken.
Andreas: Profiling ist, glaube ich, gerade announced worden. Sie wollen jetzt auch Richtung Profiling gehen.
Andreas: Das heißt, es geht darum, dass man Open Telemetry noch erweitert,
Andreas: um eben diese weiteren Signale von Observability, weil wenn ich jetzt wieder
Andreas: historisch zurückgehe, was wir als Venturen gemacht haben in den letzten Jahren,
Andreas: wir haben ja Dynatrace mit Tracing angefangen, auch im Namen Dynatrace und wir
Andreas: haben es dann erweitert auf Logs, Metriken, Events,
Andreas: End-User-Daten, Profiling und so weiter.
Andreas: Wenn ich mir andere ansehe, wie zum Beispiel das Blank, das Blank kommt ja traditionell
Andreas: aus dem Logging, hat natürlich sehr viel in Logs angefangen und hat sich dann
Andreas: in andere Signale weiterentwickelt.
Andreas: Und das ist das gleiche jetzt mit OpenTelemetry.
Andreas: OpenTelemetry hat mit Traces angefangen und versucht hat jetzt alle anderen Signale abzudecken,
Andreas: indem zuerst einmal quasi Basis-Support eingebaut wird, dann Refined,
Andreas: bis man im Endeffekt dann eine Version hat von OpenTelemetry,
Andreas: wo man sagt, das ist jetzt GA Version 1.0.
Andreas: Die Spezifikationen sind alle da und dann können auch Vendoren wie wir sagen,
Andreas: okay wenn jetzt eine Anwendung instrumentiert ist mit OpenTelemetry und da kommen
Andreas: Logs raus dann wissen wir, die kommen in diesen Format und das können wir auch so verarbeiten.
Ingo: Und ihr habt dann als Standard Trace irgendwie eine schöne Web-Oberfläche und natürlich.
Andreas: Ja genau. Und natürlich auch eine AI, weil jeder eine AI hat aber wir haben
Andreas: die AI schon relativ lange, aber anscheinend waren wir ein bisschen zu früh
Andreas: dran mit dem ganzen. Tja.
Andreas: Ja, wir haben die AI, die die heißt Davis bei uns, die im Endeffekt alle Daten
Andreas: natürlich analysiert und der man auch Fragen stellen kann und alles mögliche.
Ingo: Okay, und dann bastle ich mir irgendwelche Sachen zusammen und kriege dann auch
Ingo: irgendwelche Alerts oder so, wenn irgendwas nicht stimmt.
Andreas: Genau, die Idee ist eigentlich, ich will jetzt nicht zu viel Commercial machen
Andreas: für dein Adresse, ich glaube, das ist nicht der Sinn und Zweck von dem Podcast,
Andreas: aber viele Observability-Vendoren, die schon lange im Geschäft sind,
Andreas: wir haben natürlich sehr viel Erfahrung mit der Analyse von sehr vielen Datenmengen
Andreas: Datenmengen und nicht nur von Daten, die unabhängig voneinander gesehen werden, sondern in Kontext.
Andreas: Das heißt, wenn wir zum Beispiel sehen, eine Response Time von einer Anwendung,
Andreas: die auf Java läuft und gleichzeitig auf Java High Garbage Collection,
Andreas: weil einfach zu wenig Memory da ist, dann liefern wir nicht unterschiedliche
Andreas: Alerts, wir sagen dann nicht Response Time High und Garbage Collection hat ein
Andreas: Problem und du bist auf 100% CPU, sondern da erzeugen wir ein Problem und sagen,
Andreas: Ein Problem ist, du hast eine hohe Responsezeit, der Root Cause ist Garbage
Andreas: Collection und die Aktion, um das zu lösen, wäre, im Endeffekt es zu skalieren
Andreas: oder andere Memory Settings zu machen.
Andreas: Das heißt, das ist dann der Mehrwert von einer kommerziellen Analytics Solution.
Andreas: Nicht nur dir jetzt Daten zu geben, die du dann auf ein großes Dashboard gibst
Andreas: und selbst die Schlüsse ziehst, sondern die Schlüsse werden für dich automatisch
Andreas: schon gezogen, zumindest ein Großteil.
Ingo: Okay, wenn ich selber hoste, mir selber die Daten angucke oder darstelle,
Ingo: müsste ich mir solche Regeln eben selber bauen.
Andreas: Genau.
Ingo: Oder ich weiß nicht, gibt es irgendwelche Community-Projekte dazu, weißt du, oder was?
Andreas: Das weiß ich jetzt leider nicht, nachdem es so viel gibt.
Ingo: Ja, aber dann müsste ich mich selber hinsetzen und sagen, okay,
Ingo: ich sehe die ganzen Daten sozusagen, ich habe eine Ahnung, wie meine Applikationen
Ingo: funktionieren sollen, aber um dann,
Ingo: aus den Daten irgendwas Sinnvolles zu machen, müsste ich mir halt eigene Regeln
Ingo: bauen und dann meinen Entwicklern Bescheid geben und sagen, hier,
Ingo: guck dir mal das Problem da ein bisschen genauer an, da stimmt irgendwas nicht.
Andreas: Genau, und eben diese Regeln, da gibt es natürlich sehr viele unterschiedliche
Andreas: Ansätze, wir machen sehr viel an Anomalie-Detection mit unterschiedlichen Algorithmen,
Andreas: um herauszufinden, gibt es ein abnormales Verhalten,
Andreas: ist jetzt die Response-Time abnormal oder normal, basierend auf Baselines,
Andreas: das heißt, es ist Montag in der Früh,
Andreas: ist jetzt Montag in der Früh die Response-Time immer so, oder ist es heute Leute
Andreas: anders, läuft irgendwas anders am System, was einen Impact darauf hat.
Andreas: Das heißt, das ist auch der Vorteil, wieso man dann vielleicht kommerzielle
Andreas: Venturen verwendet, um eben die Daten zu analysieren. Man kann alles selbst machen.
Andreas: Die Frage ist, wie viele Leute muss man investieren und wie viel Expertise hat
Andreas: man selbst im Haus, um die Schlüsse dann zu ziehen oder sagt man,
Andreas: man investiert dann doch das Geld und schickt die Daten an eine Lösung,
Andreas: die halt dann schon sehr vieles automatisch kann.
Ingo: Trotzdem sollte man sich ja ein bisschen mit Open Telemetry auskennen,
Ingo: weil da bringt es nichts, wenn ich eine größere Lösung kaufe und dann keine
Ingo: Ahnung habe, wie ich es einsetze.
Andreas: Genau, wobei, da muss man nochmal ganz kurz sagen, Open Telemetry fokussiert
Andreas: sich darauf, wie wir die Daten bekommen.
Andreas: Open Telemetry sagt nichts aus, wie die Daten analysiert werden.
Ingo: Deswegen hast du vorhin auch zum Beispiel Jäger nochmal erwähnt.
Ingo: Also mir war am Anfang auch nicht klar, ich hatte das irgendwie so in dieselbe Ecke gesteckt.
Ingo: Ich habe mir gedacht, die machen quasi dasselbe. Aber nee, das eine ist die
Ingo: API, die mir die Sachen anzeigt und dann brauche ich ein anderes Produkt,
Ingo: was diese Daten dann nimmt und daraus irgendwas auch macht.
Andreas: Genau, also OpenTelemetry sagt, welche Daten wollen wir haben von den Anwendungen,
Andreas: welche Traces, welche Logs, welche Metriken sind interessant.
Andreas: Diese Daten müssen dann irgendwo hingeschickt werden an ein Backend und wenn
Andreas: es ein Backend ist, können sie visualisiert werden oder analysiert.
Andreas: Jaeger ist ein Tool, um Traces zu analysieren.
Andreas: Visualisiert. Ich kann mir einen Trace ansehen. Ich kann mir auch 100 Traces
Andreas: ansehen und Jäger bietet mir dann eine UI an, um zu sagen, ich möchte jetzt
Andreas: nur die Traces sehen, die länger als 5 Sekunden dauern. Genau.
Ingo: Das ist dann so wie in der Webkonsole hier bei Browsern oder sowas,
Ingo: wo ich einfach sagen kann, okay, zeig mir das mal und ich sehe,
Ingo: okay, die eine Abfrage nach dem Bild hat so und so lange gedauert oder hat es nicht gefunden.
Ingo: So nach dem Motto würde ich das dann in Jäger oder anderen sehen.
Andreas: Genau. ganz genau.
Ingo: Gut, gibt es noch einen Grund, Captain einzusetzen? Gibt es noch einen Grund,
Ingo: sich wirklich mit Open Telemetry auseinanderzusetzen?
Ingo: Oder sagst du, nee, ist eigentlich, muss man machen heutzutage.
Andreas: Ich sage mal so, wenn du dich in ein Flugzeug setzen möchtest und du weißt,
Andreas: der Pilot hat keine einzigen Instrumente, weiß nicht, wie schnell er fliegt
Andreas: und wie viel Sprit noch im Tank ist, dann brauchst du nicht auf Open Telemetry
Andreas: zu sein und nicht auf Captain.
Andreas: Wenn du aber gerne willst, dass du weißt, was passiert...
Andreas: Dann würde ich sagen, schaut euch OpenTelemetry an oder generell Observability.
Andreas: Und Captain bietet, wie gesagt, die Observability in die Deployments.
Ingo: Schon integriert.
Andreas: Genau, deswegen hoffe ich, dass die Leute sich das ein bisschen ansehen.
Ingo: Klingt auf jeden Fall nach einem coolen, interessanten Projekt,
Ingo: was man sich mal angucken kann.
Ingo: Vielen Dank, Andreas, dass du uns mal diese beiden Projekte vorgestellt hast
Ingo: und dass du mal ein bisschen auseinanderklamüsert hast. weil,
Ingo: genau, also auch mir waren da so ein paar Sachen unklar und ich hoffe,
Ingo: das hat man jetzt ein bisschen besser verstanden.
Andreas: Ich hoffe auch, ja, und es ist natürlich nicht leicht, up-to-date zu bleiben
Andreas: bei allem, was sich im Kubernetes-Umfeld, in der CNCF tut.
Andreas: Es gibt ja mittlerweile 170, 180 unterschiedliche Projekte und das alles zu
Andreas: verstehen, ist natürlich sehr schwer.
Andreas: Und mittlerweile aktuell ist ja zumindest diese Woche natürlich alle,
Andreas: der ganze Fokus ist auf AI und alles mögliche, dagegen vielleicht andere wichtigere
Andreas: Sachen auch runter, aber es gibt Gott sei Dank genug Informationen und Videos
Andreas: um sich dort ein bisschen einzulesen.
Ingo: Genau, kannst du vielleicht nochmal sagen, was ist eure Webseite von Captain,
Ingo: wo kann man sich vielleicht noch ein paar Informationen holen?
Andreas: Ja, www.captain.sh ist die Webseite.
Ingo: Wir sind zwar Captain mit E, ich habe auch gesehen, es gibt auch ein bisschen A.
Andreas: Ja, genau, Captain KEPTN. Und am besten aber im CNCF Slack.
Andreas: So CNCF hat ja einen eigenen Slack-Workspace und dort haben wir mit Captain
Andreas: KEPTN auch unseren Channel, wo man dann die Community und die Maintainers und alle findet.
Ingo: Verlaufen sich da manchmal ein paar Leute? Also wie gesagt, ich habe Captain
Ingo: mal gesucht und habe gedacht, okay, da gibt es eins mit A, eins mit E.
Ingo: Das ist ja interessant natürlich.
Andreas: Der Name kommt ja quasi von der Käpt'n, der eigentlich am Steuerrad sitzt,
Andreas: der den Container richtig in den Hafen bringt.
Andreas: Und das ist die deutsche phonetische Variante von einem Käpt'n.
Andreas: Deswegen haben wir K-E-P-T-N.
Andreas: Und ich glaube, es hat interessanterweise, es gibt irgendeine Firma in Norddeutschland
Andreas: sogar, die auch einen ähnlichen Namen hat, aber machen komplett was anderes.
Andreas: Ist auch eine ähnliche Variante von Käpt'n. ja, es kann schon sein,
Andreas: dass sich Leute verlaufen, aber ich hoffe, sie finden dann trotzdem irgendwie
Andreas: zu uns, weil sie Podcasts wie deinen hören und jetzt wissen,
Andreas: wie man Captain richtig buchstabiert.
Ingo: Richtig buchstabiert. Genau, vielen Dank. Dann hoffe ich mal,
Ingo: vielleicht schlagen ein paar neue Leute bei euch auf, lesen sich die Dokumentationen
Ingo: durch oder kommen sogar in den Slack-Channel.
Ingo: Ich nehme an, da sind auch Entwickler, die einem dann ein bisschen helfen können,
Ingo: wenn man dann mal auf irgendwelche Fragen stößt oder...
Ingo: Okay, wunderbar. Vielen Dank, Andreas.
Andreas: Dankeschön.