Smart Talk Episode 7:Navigieren in Kardinalität, Kontrolle und Kosten bei der Beobachtbarkeit

Wir haben in dieser Serie bereits mehrfach die Beobachtbarkeit und den komplementären Raum von AIOps besprochen, aber dieses Mal gehen wir pragmatischer auf das Thema ein, um die Mentalität des Käufers zu verstehen. Worauf sollte ein CIO eines Unternehmens achten, wenn es auf der Suche nach einer Observability-Lösung ist? Seien Sie in dieser Folge dabei, wenn Dinesh Chandrasekhar, Chefanalyst und Gründer von Stratola, mit Krishna Yadappanavar, CEO von Kloudfuse, spricht. Krishna erklärt Beobachtbarkeit durch die Linse von drei Faktoren – Kardinalität, Kontrolle und Kosten.
Diese 3 Cs sind der Schlüssel zum Verständnis und zur Verwaltung der ständig wachsenden Observability-Daten. Diese Faktoren sind nicht nur für die Datenverwaltung wichtig, sondern auch für die Nutzung der Daten und Metadaten für zusätzliche Analysen.
Eine neue Entwicklung im Bereich der Beobachtbarkeit ist die Modellbeobachtbarkeit, insbesondere die LLMs, die generative KI vorantreiben. Die 3 Cs gelten auch für diesen neuen Anwendungsfall.

Einige der in dieser Folge von Smart Talk behandelten Themen sind:

• Das Potenzial von Beobachtbarkeitsdaten
• Vermehrung von Werkzeugen
• Überwindung isolierter Observability-Daten
• Unter Berücksichtigung der Metadaten
• Einblick in die Kosten

Gast
Krishna Yadappanavar, CEO, Kloudfuse
Krishna Yadappanavar ist Mitbegründer und CEO von Kloudfuse, einer einheitlichen Observability-Plattform. Zuvor war er Mitbegründer von SpringPath, sicherte sich eine Finanzierung in Höhe von 94 Millionen US-Dollar und führte das Unternehmen zu einer 320-Millionen-Dollar-Übernahme durch Cisco. Mit über 20 Patenten hat Krishna die Daten-, Virtualisierungs- und Speichertechnologien bei Veritas, Commvault, EMC, VMware und Cisco maßgeblich beeinflusst. Er war Mitautor des VMFS von VMware und entwarf wichtige Komponenten des Speichervirtualisierungsstapels für ESX Server. Darüber hinaus berät und investiert Krishna aufstrebende Start-ups in den Bereichen Daten, Virtualisierung, Cloud, Sicherheit und KI/ML und trägt so zu Vision, Produktstrategie, Technik und Markteinführungsbemühungen bei.

Gastgeber:  Dinesh Chandrasekhar ist ein Technologie-Evangelist, ein Vordenker und ein erfahrener IT-Branchenanalyst. Mit fast 30 Jahren Erfahrung hat Dinesh an B2B-Unternehmenssoftware sowie SaaS-Produkten gearbeitet und anspruchsvolle Lösungen für Kunden mit komplexen Architekturen bereitgestellt und vermarktet. Er hat außerdem äußerst erfolgreiche GTM-Strategien definiert und umgesetzt, um mehrere wachstumsstarke Produkte bei verschiedenen Unternehmen wie LogicMonitor, Cloudera, Hortonworks, CA Technologies, Software AG, IBM usw. auf den Markt zu bringen. Er ist ein produktiver Redner, Blogger und Wochenendprogrammierer. Dinesh hat einen MBA-Abschluss der Santa Clara University und einen Master-Abschluss in Computeranwendungen der University of Madras. Derzeit leitet Dinesh sein eigenes Unternehmen, Stratola, ein kundenorientiertes Unternehmen für Geschäftsstrategieberatung und Full-Stack-Marketingdienstleistungen.

Ressourcen
Smart Talk Folge 6:AIOps und die Zukunft der IT-Überwachung
Smart Talk Episode 5:Disaggregation des Observability Stack
Smart Talk Episode 4:Echtzeitdaten und Vektordatenbanken
Smart Talk Folge 3:Moderne Datenpipelines und LLMs
Smart Talk Episode 2:Der Aufstieg von GenAI-Anwendungen mit Data-in-Motion
Smart Talk Episode 1:Die Data-in-Motion-Ökosystemlandschaft
Sehen Sie sich hier die Karte des Data-in-Motion-Ökosystems an
Erfahren Sie hier mehr über Data-in-Motion auf RTInsights

Transkript
Dinesh Chandrasekhar

Hallo und willkommen zu dieser Folge von Smart Talk, einer Data in Motion-Führungsserie. Und in dieser Folge haben wir einen besonderen Gast, Krishna Yadappanavar. Er ist der CEO von Cloud Fuse. Er ist kein Unbekannter im Startup-Ökosystem. Er ist ein Serienunternehmer. Er hat bereits einige Unternehmen aufgebaut, und deshalb heißen wir Krishna herzlich willkommen, dieses Gespräch über Beobachtbarkeit zu führen, was wiederum ein Lieblingsthema dieser Serie ist. 

Krishna Yadappanavar

Vielen Dank.

Dinesh Chandrasekhar

Also, Krishna, um dich vorzustellen:Warum erzählst du uns nicht etwas über Kloudfuse und deinen Antrieb, das Unternehmen zu gründen?

Krishna Yadappanavar (01:01):

Okay, absolut. Danke, Dinesh. Danke für die herzliche Einführung. Hallo Leute, mein Name ist Krishna. Ja, ich lebe seit fast zwei Jahrzehnten im Valley und habe mit einer Reihe von Startups und großen Unternehmen zusammengearbeitet. Der Name des Unternehmens erinnert an VMware, als es noch ein frühes Startup war. Ich bin beigetreten und habe dann miterlebt, wie es von buchstäblich fast einer Million ERR zu einem 64-Milliarden-Unternehmen heranwuchs und ich war mit verschiedenen datenbezogenen Technologien verbunden, sei es das Schreiben von Dateisystemen, verteilten Systemen, Datenbanken oder OLAP oder OLTP. Okay, während dieser Reise ist mir aufgefallen, dass Daten das Geheimnis aller Erkenntnisse sind, sei es auf der Seite der Produktanalyse oder bei der Bereitstellung einer Lösung wie Virtualisierung oder der Bereitstellung einer Lösung wie Backup oder Disaster Recovery. Nachdem ich mein Startup Springpath gegründet hatte, das sich in der Hyperkonvergenz befand, versuchte ich, die Konvergenz von Speicher, Netzwerk und Sicherheit in einer Box zu vereinen, die ich an Cisco verkaufte.

Und nachdem ich einige Zeit bei Cisco verbracht hatte, fragte ich mich:Was sind die nächsten großen Trends, die kommen werden? Das ist Anfang 2020. Ich bin auf ein paar Trends gestoßen, zum Beispiel auf einige Trends, die sich darauf beziehen, wie die Daten in Bezug auf DevOps oder SecOps eines Entwicklers exponentiell wachsen. Wie werden die neuen Trends bei den KI- und LLM-Modellen für maschinelles Lernen, als sich die LLM-Modelle noch in der Anfangsphase befanden, den Markt stören? Und wenn das menschliche Gehirn dann anfängt, über bestimmte Ereignisse nachzudenken und darauf zu reagieren, möchten Sie, dass die Maschinen auf ähnliche Weise handeln. Dies waren einige der Probleme, auf die wir gestoßen sind, und im Schnittpunkt aller drei habe ich herausgefunden, dass die Lösung des Problems nicht nur der Beobachtbarkeit, sondern der Beobachtbarkeit plus Analyse und Automatisierung zusätzlich zu den Daten, die sich auf die Entwickler und DevOps konzentrieren, sehr wichtig ist. Das führte zum Beginn der Kloudfuse – eins führte zum anderen und dann sind wir jetzt ein Team von über 40 Leuten.

Dinesh Chandrasekhar (03:16):

Herzlichen Glückwunsch, das ist ein toller Anfang. Ich wünsche Ihnen viel Glück auf dieser Reise. Apropos Beobachtbarkeit:Das ist nicht erst gestern passiert. Ich habe auch ziemlich lange in diesem Bereich gearbeitet und das Konzept der Beobachtbarkeit hat sich im Laufe der Jahre weiterentwickelt. Ursprünglich, vor 10 oder 12 Jahren, gab es große Begeisterung darüber, über Infrastrukturüberwachung, Netzwerküberwachung und all das zu sprechen, und dann führte langsam eins zum anderen, und dann kamen Cloud- und Container-Überwachungsfunktionen hinzu, die hinzugefügt wurden. Und dann haben wir heute diesen Begriff der Beobachtbarkeit, der sehr beliebt ist. Die meisten Unternehmen, die früher für Überwachung geworben haben, sind heute Observability-Unternehmen. Und ich weiß, dass Sie im Bereich der Beobachtbarkeit neu angefangen haben und etwas bewirken wollten. Wie würden Sie diese Entwicklung beschreiben? Was war früher im Vergleich zu dem, was wir heute haben? Wie haben Sie diese Entwicklung gesehen?

Krishna Yadappanavar (04:09):

Ja, tolle Frage. Dinesh. Ich habe das gesehen, ich meine, als ich selbst Entwickler bin und eine monolithische Anwendung geschrieben habe, die auf physischen Maschinen ausgeführt wird. Dann sah ich das Aufkommen der Virtualisierung, sei es VMware oder Hyper-V oder die Open-Source-Virtualisierungstechnologien, und die Containerisierung kam ins Spiel. Wenn man sich also die Kernprobleme ansieht, wenn es um die Daten für die Beobachtbarkeit geht, haben sich diese Auswertungen weiterentwickelt, so dass wir gesehen haben, dass die mit den Daten verbundenen Attribute immer weiter zunehmen, und wenn man das kartesische Produkt dieser Attribute nimmt, dann wird es wirklich groß in der Größenordnung von mehreren Millionen bis Milliarden. Was sie als die mit dieser Kardinalität verbundene Kardinalität bezeichnen, ist das Datenvolumen. Da das Datenvolumen zunimmt, möchten die Menschen Daten A für bessere Analysen in Daten B umwandeln. Sie möchten bestimmte Arbeitsabläufe basierend auf den Daten automatisieren.

Sie möchten die Daten aufschlüsseln, damit Sie bessere Einblicke erhalten. Kurz gesagt, da das Datenvolumen auf traditionelle Weise zunimmt, hey, habe ich die sogenannte Überwachung durchgeführt, da die bekannten Bekannten verschwinden, was die traditionelle Überwachung ist. Dann betrachten Sie die bekannten Unbekannten, das ist der Beginn der Beobachtbarkeit, und es gibt die völlig unbekannten Unbekannten, bei denen Sie nichts wissen und mit Daten im Wert von mehreren Terabytes bis Petabytes konfrontiert werden. Sie müssen diese Daten analysieren und zu dem Mangel an besseren Worten gelangen, wo genau das Problem liegt, wie es mit dem Vorfall korreliert, was die Ursachenanalyse ist, was die Auswirkungsanalyse ist. Solange die Entwickler also Code schreiben, werden diese Komplexität und immer mehr Dienste kommen. Diese Komplexität wird immer höher und daher bleibt dies ein sich entwickelnder Raum, in dem neue Herausforderungen entstehen.

Dinesh Chandrasekhar (06:14):

Fantastisch. Offensichtlich ist die Beobachtbarkeit also definitiv ein schwer zu lösendes Problem. Ich würde gerne herausfinden, warum das so ist. Aber ich denke, Sie haben es gerade auch ein wenig angesprochen, aber es ist auch so, dass wir einen überfüllten Markt mit einem Dutzend Anbietern haben, die sagen:„Wir lösen diesen Teil der Beobachtbarkeit und diese Art von Beobachtbarkeit und so weiter“, aber es gibt immer noch eine Suche nach der idealen Lösung. Daher ist jeder CIO, mit dem ich spreche, immer auf der Suche nach diesem einen Wundermittel, das seine Probleme irgendwie löst. Warum ist das so? Gibt es eine andere Linse, durch die man es betrachten muss, um zu verstehen, warum es einen anderen Drang gibt, diese ideale Lösung zu finden?

Krishna Yadappanavar (07:04):

Lassen Sie mich also, wie ich bereits angedeutet habe, etwas zurücktreten, oder? Wonach sucht der Kunde, wenn er über eine ideale Beobachtungslösung nachdenkt? Beginnen wir mit dem Problem. Ich klassifiziere dieses Problem in die drei Cs – die Kardinalität, die Kontrolle und die Kosten. Lassen Sie mich auf die nächste Detailebene eingehen. Was bedeuten diese drei Cs? Bei der Kardinalität geht es darum, wie wir über bestimmte Daten verfügen, ob es sich nun um einen heiklen metrischen Punkt oder eine Logline oder ein Ereignis oder eine Spur oder eine Spanne handelt, die aus der Nachverfolgung Ihres Vertriebspartners oder dem Profil eines kontinuierlichen Profils stammt. Sie werden, mangels eines besseren Wortes, mit zusätzlichen Etiketten oder Tags versehen. Wenn Sie das kartesische Produkt der potenziellen Werte nehmen, die diese Etiketten annehmen können, wird es sehr, sehr hoch werden. Jetzt muss jeder Datenpunkt mit seinen Tags verknüpft werden.

Nennen wir also Tags die Metadaten. Und dann gibt es noch Daten. Unterschiedliche Schemata haben unterschiedliche Probleme. Einige sind metadatenlastig. Wenn Sie zur Matrix-Site gehen, wenn Sie zu den Protokollen und Spannen wie der verteilten Ablaufverfolgung kommen, sind sie wie datenintensiv, aber in Wirklichkeit ist es die enorme Zunahme des Volumens der Beobachtbarkeitsdaten aufgrund der Kardinalität. Heutzutage beobachte ich den umgekehrten Trend. Ich meine, damals dachten die Leute:„Hey, lass mich meine Daten an ein SaaS-Portal senden, und dann würde der SaaS-Anbieter alle diese Daten verwalten.“ Aber wenn ich mit dem CTO oder einem CIO oder einem technischen Leiter oder den Entwicklern oder den Architekten und sogar dem CFO spreche, denken sie:Lasst mich die Kontrolle über meine Daten haben. Was meinen sie damit? Es gibt einen umgekehrten Trend, dass ich aus verschiedenen Gründen über so viele Daten verfüge, sei es wegen der ausgehenden Risikokosten, wegen der Sicherheitsaspekte oder wegen der Menge der Daten selbst.

Sie möchten diese Daten nicht außerhalb ihrer VPC senden, und das hat noch einen anderen Aspekt. Sie möchten alle möglichen Schnittstellen einbinden, die ihnen einfallen, sei es für eine traditionelle Observatoriumsschnittstelle wie die Erstellung von Dashboards, Warnungen, SLOs oder anderen Analysefunktionen, die in herkömmlichem SQL oder GraphQL geschrieben werden könnten, oder für fortgeschrittene wie Spark-Jobs, um einige Analysen auf der Grundlage der Beobachtbarkeitsdaten auszuführen, da Beobachtbarkeit zu dieser grundlegenden Säule geworden ist. Das bedeutet, dass sie Eigentümer der Daten sein müssen. Die Daten sollten die VPC nicht verlassen. Wenn ich von den Daten spreche, sind es die Daten, die aufgenommen werden, die Daten, die abgefragt werden, und die Daten, die analysiert werden, und nicht zuletzt sind es die Kosten. Wenn Sie sich an einen beliebigen Anbieter wenden, sei es ein traditioneller kommerzieller SaaS-Anbieter oder eine Open-Source-Komponente, dann gibt es viele Open-Source-Lösungen. Die Infrastrukturkosten, die Kosten des Anbieters, sind direkt proportional zum Datenvolumen, direkt proportional zur Anzahl der Abfragen und direkt proportional zur Anzahl der Benutzer. Diese drei Dinge sind die Probleme, nach denen eine traditionelle Organisation sucht, die nach einer idealen Lösung, einer idealen Observability-Lösung sucht

Dinesh Chandrasekhar (10:24):

Kardinalität, Kontrolle und Kosten. Ich glaube, ich liebe das. Die drei Cs sind eine großartige Möglichkeit, den Observability-Bereich zu betrachten und daraus abzuleiten, was für die tatsächlichen Benutzer usw. wichtig ist. Apropos Kosten:Da wir es bereits angesprochen haben, möchte ich Ihnen auch diese Frage stellen. Wenn ich mit Kunden spreche, die nach einer Observability-Lösung suchen, beschweren sie sich meiner persönlichen Erfahrung nach oft so:„Hey, ich habe in jeder Abteilung, die ich habe, mindestens acht bis zehn verschiedene Tools.“ Ich schaue mir heute vielleicht 30 bis 40 Tools im gesamten Unternehmen an. Ich habe bereits Jahr für Jahr hohe Kosten für die Bezahlung dieser Lizenzen. „Warum möchte ich eine weitere Observability-Lösung?“ ist ein Rückstoß, den ich früher bekam, oder? Deshalb werde ich Ihnen jetzt, da Sie den Kostenaspekt angesprochen haben, dieselbe Frage stellen. Wie gehen Sie mit einem CIO an diese Frage heran und überzeugen ihn oder sagen ihm, warum dies besser ist, als 30 oder 40 verschiedene Tools zu haben?

Krishna Yadappanavar (11:23):

Okay, tolle Frage. Um diese Frage zu beantworten, beginnen wir mit der Frage, warum es zu einer starken Verbreitung von Werkzeugen kommt. Wenn Sie sich also das gesamte Ökosystem ansehen, waren traditionell einige Anbieter, wenn ich die kommerziellen Anbieter nehme, in bestimmten Streams ziemlich gut. Wenn Sie zu Protokollen gehen, können Sie an Splunk denken. Wenn Sie an Metriken denken, denken Sie an Datadog. Dann innerhalb von Google und allen FANGs der Welt. Diese ganze Open-Source-Bewegung begann, insbesondere mit dem Aufkommen von Kubernetes, dann kamen Dinge wie Prometheus, OpenTelemetry und so weiter.

Und es gibt diesen ganzen Wandel hin zur Open-Source-basierten Lösung. Was bedeutet es? Das bedeutet, dass die Entwickler, die Architekten und die DevOps-Leute ihre Observability-Daten in einem offenen Format aufnehmen möchten. Das heißt, selbst wenn ich eine Instrumentierung zur Instrumentierung meines Codes auswähle oder einen Agenten zum Sammeln meiner Daten einsetze, sollte diese hundertprozentig Open-Source-kompatibel sein. Deshalb wollten die kommerziellen Anbieter, als sie auch begannen, ihre Agenten in Open Source zu integrieren, auf der Abfrageseite, dass die gesamte Visualisierung, das Dashboard, die Warnungen – all diese Funktionen durch die Open-Source-Abfragesprachen gesteuert werden. Aus diesem Grund probieren sie mit dem Aufkommen von PromQL, LockQL, TraceQL und OpenTelemetry jetzt eine andere Open-Source-Abfragesprache aus.

 Jetzt sind Sie also in dieser Welt, in der Sie viele Möglichkeiten haben. Die Kunden haben sich bereits für bestimmte Streams und bestimmte Anbieter entschieden.

Dann gibt es eine Open-Source-Bewegung und dann nutzen verschiedene Teams unterschiedliche Infrastrukturen. Einige basieren auf Kubernetes, einige basieren auf Serverless, einige basieren auf ECS, Fargate und so weiter. Das fügt also eine weitere Dimension hinzu und um die Geschwindigkeit und Agilität der gesamten Produktbereitstellung zu erreichen, hat sich CI/CD an dieser Schnittstelle weiterentwickelt, um die Probleme sehr schnell zu lösen. Sie versuchen, nach der pointierten Lösung zu suchen und entscheiden sich am Ende für die sehr pointierte Lösung. Wenn wir als ideale Observability-Lösung meinen Observability-Stack für mein Unternehmen starten würden, würde ich einen Schritt zurücktreten und sehen:Wenn ich meine MTTR und MTTD reduzieren möchte, muss ich alle Endströme der Observability-Daten sammeln. Gehe ich zu n ? verschiedene Anbieter und wählen Sie n aus verschiedene Streams, oder gehe ich zu einem Observability Data Lake, wo ich alle Streams zusammenfügen kann, damit die Korrelation und die erweiterten Funktionen wie Ausreißererkennung, Anomalien und Kausalität relativ einfacher werden? Das wäre eine ideale Lösung, bei der Sie alles in einem Data Lake konsolidieren und Ihre Daten in Ihren Räumlichkeiten aufbewahren können.

Dinesh Chandrasekhar (14:18):

Fantastisch. Und ich möchte auch hinzufügen, dass ich den Kosten für die Verbreitung von Tools weitgehend zustimme, weil Entwickler ihr eigenes Ding bauen wollen und sie auch viele Open-Source-Tools in den Mix aufgenommen haben, aber es handelt sich auch um Käufe auf Abteilungsebene. Eine IT-Abteilung hat also das Gefühl, dass ich dieses Problem lösen kann, weil ich eine Pflasterlösung bekommen, dieses Tool von der Stange kaufen und verwenden kann. Und dann wurde ihnen im Laufe der Zeit klar, dass sie dem Arsenal ein weiteres Werkzeug hinzugefügt hatten, ohne zu merken, dass sie nicht vor lauter Bäumen im Wald suchen. Daher sind die CIO-Gespräche immer interessant und es geht darum, wie Sie die Anzahl der Tools, die Sie im gesamten Unternehmen haben, komprimieren oder reduzieren und eine einzige Observability-Plattform haben können, die alle Abteilungen, Anwendungen, Infrastrukturcontainer und so weiter abdeckt. 

Krishna Yadappanavar (15:08):

Absolut. Ich möchte also hinzufügen, dass jetzt auch verschiedene Personen im Unternehmen dieselben Daten betrachten. Wie DevOps-Entwickler achten auch Architekten auf die Observability-Daten im Hinblick auf Infrastruktur, Containerisierungsanwendungen und so weiter. Verwendung der gleichen Protokolle. Die SecOps-Leute versuchen, die Daten zu analysieren, um nach Sicherheitsaspekten und Bedrohungen zu suchen. Betrachten Sie ähnliche Daten aus den Protokollen oder Traces. Sogar die DataOps-Leute fragen sich:„Hey, wie gut sind meine Datenoperationen?“ Und jetzt, mit dem Aufkommen von LLM, schauen sich sogar die LLM-Ops-Leute ähnliche Daten an, um ihre Art von Analysen durchzuführen. Es muss also eine weitere Konsolidierung stattfinden. Darauf würde ich bei einer idealen Observability-Lösung achten. Wie binde ich alle verschiedenen Personas in einer Organisation ein, damit sie die Daten aus demselben sogenannten Data Lake nutzen können?

Dinesh Chandrasekhar (16:05):

Wirklich die sprichwörtliche Single-Pane-of-Glass-Sache, nach der wir alle gestrebt haben. Es ist also eine gute Sache. Ich möchte also auf eine andere Sache eingehen, die Sie kurz erwähnt haben, als Sie die vorherige Antwort erklärt haben, nämlich die Reduzierung der MTTR, nicht wahr? Als primärer Kernpunkt der Beobachtbarkeit geht es also nicht nur um die Fehlerbehebung, sondern auch um die Reduzierung der MTTR, die Reduzierung des Alarmrauschens und dieser Art von Metriken. Es erspart SREs und IT-Abteilungen also auf jeden Fall die Frage, wo das Problem liegt und was eine Grundvoraussetzung für die Lösung dieses Problems ist. Sie benötigen Zugriff auf Ereignisse in Echtzeit, während sie stattfinden. Wenn in einer bestimmten Anwendung oder auf einem bestimmten Server ein Protokoll über eine böswillige Aktivität oder ähnliches eingegeben wurde, benötigen Sie sofort Zugriff auf dieses Ereignis, damit Sie nachvollziehen können, wo diese Anomalie liegt, was in Ihrer Infrastruktur passiert, warum diese bestimmte Spitze in einem bestimmten Speicherthread auftritt oder was auch immer.

Sie müssen das also herausfinden, und damit dies geschieht, müssen Sie die Möglichkeit haben, all dies auch in Echtzeit aufzunehmen. Datenunmittelbarkeit ist einer meiner Lieblingsbegriffe im letzten Jahr, in dem ich darüber gesprochen habe, und die Aktualität der Daten ist hier irgendwie von größter Bedeutung. Hier geht es darum, wie aktuell die Daten sind, wie schnell Sie dieses bestimmte Problem lösen oder vielleicht sogar etwas abwenden können, das in diesem speziellen Kontext der Beobachtbarkeit passieren wird, insbesondere wenn es sich um Hunderte und Tausende von Servern handelt, die Sie überwachen, und all das, oder wo genau sagen Sie, hier liegt das Problem darin, die Daten so aktuell wie möglich zu machen oder nicht. Hängt es weitgehend von den Aufnahmemechanismen ab? Weil Sie über TEL und andere Arten von Instrumentierungstechniken und all das gesprochen haben. Wie würden Sie sonst darüber nachdenken oder es aus der Perspektive betrachten, wie schnell ich Zugriff auf Echtzeitdaten erhalten kann?

Krishna Yadappanavar (18:03):

Okay, ein weiterer toller Aspekt des Beobachtungsteams, du hast absolut Recht, Danesh. Die entscheidende Dimension, in der die Beobachtungsdaten verbraucht werden, ist also, wie schnell ich auf die Daten zugreifen kann, sobald die Daten die Datenquelle verlassen haben, unabhängig davon, ob es sich um Ihre Anwendung oder Ihre Infrastrukturkomponenten oder Ihre Plattform wie Open-Source-Komponenten und ähnliches handelt. Wenn man sich also ansieht, wie sich die Branche in den letzten fünf bis zehn Jahren entwickelt hat, sind die Echtzeit-Streaming-Dienste und Echtzeit-Datenbanken hinzugekommen. Wenn man sich die herkömmlichen Observ-Lösungen anschaut, meine ich, dass sie diese Funktionalität nicht nutzen konnten, weil die Technologie relativ älter war. Mit der Einführung des Echtzeit-Streamings und der Echtzeit-Datenbanken können Sie also so schnell wie möglich auf die Daten zugreifen. Das ist also das Maß für die sogenannte Aktualität der Daten von dem Moment, in dem sie die Anwendung verlassen, bis zu ihrer einfachen Abfrage, das ist alles, worauf es ankommt.

Dann ist da noch dieser Aspekt:„Hey, ich habe alle Daten.“ Wie unterteile ich diese Daten? Wie finde ich die relevanten Muster, die ich benötige, um zur Grundursache zu gelangen? Das ist die nächste Gruppe von Problemen. Das bedeutet also, dass ich in der Lage sein sollte, Daten von einem Datentyp in den anderen Datentyp umzuwandeln. Hey, ich erhalte eine Reihe von Protokollen. Kann ich mir schnell eine Metrik aus den Protokollen ansehen? Ich bekomme eine Reihe von Spannen. Kann ich mir ein Attribut innerhalb dieser Spanne oder einen Trace ansehen, um diese Daten zu analysieren? Da diese Attribute normalerweise korrelieren und das Debuggen auf diese Weise erfolgt. Das ist also die nächste Dimension. Und dann ist die dritte Dimension die erweiterte Analyse. Kann ich zusätzlich zu diesen Daten einige interessante statistische oder große Sprachmodelle verwenden, um die Daten zu analysieren und die sogenannten Ausreißer in meinem System zu finden?

Kann ich die Anomalien in meinem System finden? Okay, kann ich mir den Saisonalitätsaspekt meiner Daten ansehen? Kann ich meine Daten basierend auf dem, was ich aus der Vergangenheit gesehen habe, vorhersagen? Der saisonale Aspekt der Daten? All dies bezeichne ich als das Paket der erweiterten Analyse. Wenn Sie also über die Gesamtlösung nachdenken, nachdem die Aktualität der Daten gelöst wurde, müssen Sie die Daten als Einheit eines Bausteins betrachten und dann darüber nachdenken, wie jeder Baustein angepasst werden kann, und dann eine Reihe von Analysefunktionen festlegen. Und dann müssen wir uns ganz natürlich fragen:„Hey, ich habe das einmal analysiert. Kann ich das automatisieren?“ Das wird zur natürlichen Erweiterung des Ganzen. Deshalb haben wir gesehen, dass Kunden neben dem Drei-C-Problem auch gefragt haben, wie ich meine Beobachtungsdaten beobachten, analysieren und automatisieren kann.

Dinesh Chandrasekhar (20:57):

Sehr cool. Sehr cool. Und dann haben Sie in Ihrer Antwort auch das Zauberwort LLMs, große Sprachmodelle, erwähnt. Ich meine, heutzutage kann man kein Gespräch mehr führen, ohne über GenAI-LLMs zu sprechen. Deshalb freue ich mich, dass Sie es erwähnt haben, denn ich könnte Sie auf jeden Fall danach fragen, nämlich die LLM-Beobachtbarkeit. Es sieht so aus, als wäre das plötzlich ein aufstrebender Bereich, wenn man bedenkt, dass es überall eine Vielzahl von LLMs gibt und die Leute Schwierigkeiten haben, zu verstehen, wie sie abschneiden und so weiter. Erzählen Sie uns davon. Es sieht so aus, als ob Kloufuse auch an dieser Front etwas aufbaut, oder? Erzählen Sie uns also mehr darüber.

Krishna Yadappanavar (21:32):

Ich meine, ja. Ich meine, im Grunde genommen werden die LLM-Modelle in verschiedenen Anwendungsfällen eingesetzt, oder? Was den Mangel an besseren Worten betrifft. Die Dynamik der Daten ändert sich, insbesondere in der Observability-Welt sind die Daten sehr dynamisch. Es ist immer schwierig, das richtige LLM-Modell für bestimmte Vorgänge zu entwickeln. Daher haben wir das Problem auf zwei Arten betrachtet. Wie kann ich bestimmte LLM-Modelle zusätzlich zu den vorhandenen Observability-Daten nutzen, die von all den verschiedenen Personen, über die ich gesprochen habe, genutzt werden, egal ob es sich um DevOps oder SecOps oder DataOps-Leute oder die LLMOps-Leute handelt? Das ist der eine Aspekt davon. Und da ist noch der andere Aspekt:​​Hey, ich entwickle eine Anwendung, bei der das LLM eine sehr, sehr wichtige Komponente ist. Wie betrachte ich die vollständige Beobachtbarkeit einer Anwendung, die die Daten erzeugt, die in das LLM eingespeist werden, und dann gibt es viele Verbraucher, die diese Daten aus diesen LLM-Modellen verbrauchen?

Wir denken also darüber nach, und ich kann sagen, dass wir die Ersten sind, die umfassend darüber nachdenken, was die wahre Beobachtbarkeit für alle Anwendungen ist, die mit den LLM-Modellen entwickelt werden. Weil ich auf viele Lösungen gestoßen bin, die sich nur mit der Beobachtbarkeit des Modells beschäftigt haben, wie z. B. Drift und ähnliches. Aber wir schauen von Ende zu Ende. Das ist ein sehr interessanter Aspekt, da ein Großteil der Beobachtbarkeit von Infrastrukturanwendungen mit der Beobachtbarkeit von Modellen und anderen Dingen einhergeht. Und zu guter Letzt:Wenn Sie einen CIO oder CFO fragen, sind die Kosten für das LLM, wie auch für die aktuellen Lösungen, eine weitere wichtige Dimension. Ein weiterer Aspekt ist die Frage, wie Sie diese Kosten einhalten oder sogar Analysen zu den Kostenmetriken der LLM-Modelle selbst bereitstellen können. Man muss sich also alles ansehen:Leistung, fehlendes, nennen wir es APM für LLM-Anwendungen, und dann die Kosten. Das sind also die typischen Abmessungen, die Sie sehen würden.

Dinesh Chandrasekhar

Sehr cooler, aufregender Bereich und ich bin auf jeden Fall gespannt darauf, zu erfahren, was in den kommenden Monaten in diesem Bereich auf mich zukommt. Vielen Dank, Krishna. Das war ein sehr, sehr wunderbares Gespräch. Ich habe es genossen, Sie in unserer Show zu haben. Ich liebe es, über Beobachtbarkeit zu sprechen. Ich werde mich an Ihre drei Cs erinnern:Kardinalität, Kontrolle und Kosten. Ich denke, es ist eine großartige Möglichkeit, ein großartiges Mantra, die Beobachtbarkeit zu betrachten. Vielen Dank also für all die Einblicke. Ich freue mich, dass Sie hier sind. Vielen Dank.

Krishna Yadappanavar

Vielen Dank, Dinesh. Vielen Dank, dass ich in Ihrem Webchat dabei sein durfte.