Jeff Champagne, Field CTO at Cribl – Interview-Serie

Jeff Champagne, Field CTO at Cribl, bringt umfassende Erfahrung in den Bereichen Observability, Unternehmensdaten, Produktstrategie und technische Architektur mit. Bevor er zu Cribl kam, war er als Director of Product Management bei Databricks tätig und verbrachte mehr als sieben Jahre bei Splunk in leitenden Positionen im Bereich Field Product, Architektur und Global Systems Engineering. Sein Hintergrund umfasst auch Führungspositionen im Bereich Systems Architecture bei BNY ConvergEx, leitende Ingenieursarbeiten bei Premier Technology Solutions und frühe Ingenieursführungspositionen bei Assist-2-Sell, was ihm eine breite Perspektive darauf gibt, wie Unternehmen operativ Daten auf großem Maßstab sammeln, verwalten, analysieren und nutzen.

Cribl ist ein Unternehmen für Unternehmens-Telemetrie, das sich darauf konzentriert, IT-, Sicherheits-, SRE- und DevOps-Teams bei der Sammlung, Verarbeitung, Routenfindung, Speicherung und Analyse von Observability- und Sicherheitsdaten zu unterstützen, ohne an einen einzigen Anbieter gebunden zu sein. Das Unternehmen positioniert sich als “AI-Plattform für Telemetrie” mit Produkten wie Cribl Stream für Echtzeit-Telemetriesammlung, -reduzierung, -anreicherung und -routenfindung; Cribl Edge für anbieterunabhängige Endpunkte-Telemetriesammlung; Cribl Search für die Suche nach Daten vor Ort; und Cribl Lake für die Speicherung. Seine umfassendere Mission ist es, Unternehmen mehr Kontrolle, Flexibilität und Effizienz zu geben, wenn die Telemetrie-Volumina wachsen und AI-getriebene Betriebe sauberere, zugänglichere Daten erfordern.

Sie haben bei Splunk, Databricks und jetzt Cribl gearbeitet, was Ihnen eine seltene Perspektive auf Unternehmensdaten, Observability und Infrastruktur über mehrere Technologiezyklen hinweg gibt. Aus dieser Perspektive heraus: Was fühlt sich wirklich anders an bei der Observability-Herausforderung, die durch agente AI entsteht?

Bei der Anwendungs-Observability haben wir immer mit komplexen, verzweigten Ausführungspfaden zu tun, Anfragen durch Mikrodienste und Korrelation von Protokollen in verteilten Systemen. Bei Sicherheitsoperationen haben wir mit hohem Volumen, disparaten Datenquellen zu kämpfen, um Bedrohungen über Systeme hinweg zu erkennen, die zwar komplex sind, aber immer noch vorhersehbar verhalten. Agente AI erfindet keines von diesen Problemen neu; sie explodieren sie gleichzeitig.

Agenten ketten Entscheidungen, rufen externe Tools auf und spawnen dynamisch Sub-Agenten in Weisen, die nicht vorherbestimmt sind. Der Ausführungsgraph ist nicht nur komplex, sondern kann auch wild unterschiedlich sein, und das Volumen der Telemetrie, das erforderlich ist, um zu rekonstruieren, was tatsächlich passiert ist, wächst exponentiell mit jedem Hop. Die Sammlung aller erforderlichen Telemetrie, um agentische Systeme beobachtbar zu machen, muss sowohl einfach zu instrumentieren als auch kosteneffektiv zu betreiben sein. Andernfalls werden Unternehmen die gleiche Abwägung treffen, die sie immer getroffen haben, und die Sichtbarkeit reduzieren, um Kosten zu kontrollieren – genau zum falschen Zeitpunkt, um blind zu werden.

Wenn Unternehmen autonome Agenten in Workflows einbetten, wo sind die größten Sichtbarkeitslücken zwischen dem, was ein AI-Agent aufgefordert wird zu tun, und dem, was tatsächlich in den zugrunde liegenden Systemen passiert?

Agenten vervollständigen Workflows, die auf der Oberfläche erfolgreich aussehen, während sie stillschweigend schlechte Tool-Aufrufe machen, Parameter halluzinieren oder vom ursprünglichen Ziel abdriften. Die Konsequenzen treten oft Stunden später in einem anderen System auf.

Der Bruch beginnt in der Regel bei der Interpretation: leichte Mehrdeutigkeit in der ursprünglichen Anweisung wird je nachdem anders aufgelöst, was der Agent aus dem Speicher abruft, welche Tools zu diesem Zeitpunkt verfügbar sind oder wie ein vorheriger Schritt in der Kette seinen Kontext geprägt hat. Sie müssen auch die nachgelagerten Systeme instrumentieren, auf die der Agent angewiesen ist, da ein Agent einen perfekt geformten Datenbankaufruf machen und dennoch eine falsche Antwort zurückgeben kann, wenn die zugrunde liegende Tabelle nie aktualisiert wurde, weil ein ETL-Job stillschweigend im Voraus fehlgeschlagen ist.

Der Agent hat genau das getan, was er aufgefordert wurde; die Daten, denen er vertraute, waren einfach nur veraltet.

Warum sind traditionelle Observability-Tools oft unzureichend für die Überwachung von agentischen AI-Systemen?

Erstens wurden sie um starre, proprietäre Schemata und vorhersehbare Datenformen herum entwickelt. Agentische Spuren entsprechen nicht diesen Erwartungen – sie sind voluminös, hoch variabel in der Struktur und enthalten Datentypen wie vollständigen Prompt-Text, Modell-Reasoning-Ketten und Tool-Aufruf-Payloads, die Legacy-Tools nicht ohne erhebliche Transformationsarbeit verarbeiten können. Offene Standards wie OpenTelemetries GenAI-Semantik-Konventionen entstehen, um dies zu bewältigen, aber viele Legacy-Plattformen wurden nicht so konzipiert, dass sie davon profitieren können.

Zweitens bricht die Skala- und Kosten-Gleichung schnell zusammen. Ein einzelner Agent, der Produktions-Workloads bearbeitet, kann mehr Telemetrie in einer Stunde generieren als ein gesamter Anwendungsstapel an einem Tag produziert, und die meisten traditionellen Plattformen berechnen nach Volumen und Speicherung. Das schafft ein unmögliches Abwägungsspiel – entweder instrumentiert man alles und riskiert übermäßige Kosten oder reduziert man die Sichtbarkeit in den Systemen, in denen man sie am meisten benötigt.

Wenn ein AI-Agent ausfällt, wie können Organisationen bestimmen, ob die Ursache im Modell, in der Abrufschicht, in einer API-Abhängigkeit, in einem Berechtigungsproblem oder in einem nachgelagerten Infrastrukturproblem lag?

Die Isolierung der Ursache in einem agentischen Ausfall ist ein Prozess der Eliminierung über Schichten hinweg. Es funktioniert nur, wenn Ihre Telemetrie alle Schichten konsistent umfasst. Latenz- und Fehlersignale auf den Modell-Spuren deuten auf das LLM selbst hin. Abruf-Spuren sagen Ihnen, ob der Kontext, der zurückgegeben wurde, relevant oder veraltet war. Tool-Aufruf-Spuren legen nahe, ob es fehlgeschlagene API-Abhängigkeiten oder Berechtigungsfehler gab.

Wie bereits erwähnt, benötigen Sie auch Telemetrie aus den nachgelagerten Systemen, auf die der Agent angewiesen ist, da ein Agent einen perfekt geformten Aufruf machen und dennoch eine falsche Antwort produzieren kann, wenn die Daten, denen er vertraute, nie aktualisiert wurden. Kein einzelnes Signal erzählt die ganze Geschichte, und deshalb ist die Korrelation über alle Schichten hinweg an einem Ort das, was Teams, die agentische Ausfälle schnell debuggen können, von denen unterscheidet, die immer noch raten.

Welche Arten von Telemetrie-Daten werden am wichtigsten, wenn Unternehmen versuchen, das Verhalten von Agenten im großen Maßstab zu verstehen?

Die Grundlage ist immer noch MELT – Metriken, Ereignisse, Protokolle und Spuren – aber das Gewicht verschiebt sich erheblich, wenn man in agentische Systeme wechselt. Metriken sagen Ihnen, dass etwas falsch ist, und Protokolle geben Ihnen den rohen Nachweis dessen, was passiert ist, aber keines von beiden kann die Entscheidungskette rekonstruieren, der ein Agent zu einer falschen Antwort gefolgt ist. Dafür sind Spuren das kritischste Signal.

In einem traditionellen verteilten System zeigt eine Spur, wie eine Anfrage durch Dienste bewegt wurde. In einem agentischen System zeigt sie, wie ein Modell ein Problem durchdachte, welche Tools es aufrief, welchen Kontext es abrufte, wo es verzweigte und welche Entscheidung es bei jedem Schritt traf. Ohne diese Spur sehen Sie nur die Ausgabe mit keiner Möglichkeit, zu erklären, wie man dorthin gekommen ist.

Die anderen MELT-Signale verschwinden nicht; Metriken zu Token-Nutzung und Latenz sind wichtig für Kosten und Leistung, und Protokolle aus nachgelagerten Systemen bleiben unerlässlich. Aber Spuren sind das, was agentisches Verhalten lesbar macht.

Viele AI-Diskussionen konzentrieren sich immer noch stark auf Halluzinationen. Unterschätzen Unternehmen operationelle Ausfälle wie schlechte Abrufe, fehlerhafte Integrationen, Latenzspitzen oder fehlenden Kontext?

Die meisten Halluzinationen in der Produktion sind keine Modellfehler; sie sind operationelle Ausfälle in Verkleidung. Schlechte Abrufe liefern veralteten oder unvollständigen Kontext, und das Modell füllt die Lücke mit etwas Plausibel-Klingendem. Eine fehlerhafte Integration bedeutet, dass der Agent nie die Daten erhalten hat, die er benötigte, um richtig zu entscheiden. Fehlender Kontext aufgrund eines fehlgeschlagenen ETL-Jobs sieht aus wie eine Halluzination, ist aber in Wirklichkeit ein Infrastrukturproblem.

Wenn Teams den Unterschied nicht erkennen können, greifen sie auf das zurück, was sie kontrollieren können, was normalerweise das Modell selbst ist. Sie iterieren über System-Prompts, fügen Schutzmechanismen hinzu und verfeinern Bewertungsrahmen, und obwohl diese Techniken einen echten Wert haben, behandeln sie ein Symptom anstelle der Ursache. In meiner Erfahrung ist die höchste Hebelwirkung fast immer in der Datenqualität und Frische in der Abrufschicht zu finden. Ein gut begründeter Agent mit sauberen, aktuellen Daten wird immer einen stark prompt-engineereden Agenten überbieten, der mit veralteten oder unvollständigen Kontext arbeitet.

Wenn Agenten autonomer werden, was sollten Unternehmens-Teams protokollieren, verfolgen oder überwachen, um Rechenschaftspflicht zu wahren, ohne sich selbst mit Lärm zu überwältigen?

Die Grundlage ist immer noch MELT, aber Rechenschaftspflicht für agentische Systeme erfordert die Schichtung eines Bewertungsrahmens auf traditionelle Telemetrie. Metriken, Ereignisse und Protokolle legen Infrastrukturfehler und fehlerhafte Integrationen bloß, die agentisches Verhalten vor der Modellantwort verderben können; Spuren geben Ihnen die Entscheidungskette, um zu verstehen, warum es zu einer bestimmten Antwort kam. Aber keines von beiden sagt Ihnen, ob die Antwort tatsächlich korrekt war, und das ist der Punkt, an dem LLM-as-Judge-Bewertung die Lücke füllt. Die gleichen AI-Fähigkeiten, die Agenten antreiben, können verwendet werden, um sie zu bewerten, indem sie Ausgaben für Genauigkeit, Begründetheit und Aufgabenabschluss auf einer Skala bewerten, die kein menschlicher Überprüfungsprozess erreichen kann.

Bevor die Produktion beginnt, dient es als Qualitäts-Tor, um Rückschläge zu vermeiden, bevor sie Benutzern erreichen. In der Produktion wird es zu einem kontinuierlichen Monitor, der Live-Verkehr sampelt und Antworten kennzeichnet, die außerhalb akzeptabler Schwellen liegen. Der Schlüssel, um Lärm zu vermeiden, besteht darin, zu erkennen, dass nicht jeder Agent-Workflow das gleiche Risiko mit sich bringt, was bedeutet, dass man von einer einheitlichen Überwachung zu etwas übergeht, das die Branche als human-on-the-loop-Governance bezeichnet. Sie definieren Verhaltens-Baselines und Vertrauensschwellen im Voraus, lassen Agenten operieren und reservieren menschliche Interventionen für Ausnahmen.

Welche Rolle können Telemetrie-Pipelines spielen, um Sicherheits-, SRE-, Daten- und AI-Teams dabei zu helfen, aus einer gemeinsamen Sicht auf agentisches Verhalten zu arbeiten?

Sicherheitsteams, SREs, Daten-Ingenieure und AI-Teams schauen alle auf unterschiedliche Aspekte desselben Problems durch verschiedene Tools, und keines von ihnen hat das vollständige Bild. Der Grund, warum Telemetrie-Pipelines zu einem Standardbestandteil moderner Unternehmens-Daten-Architektur geworden sind, liegt darin, dass sie genau dieses Problem lösen: eine einzelne, gut regulierte Pipeline vor allen Tools stellt sicher, dass jedes Team von den gleichen normalisierten, angereicherten Daten arbeitet, ohne dass spezielle Agenten und Sammler für jedes Team eingesetzt werden müssen.

Die Flexibilität ist auf zwei Ebenen wichtig. Die erste Ebene ist die Datenebenen-Struktur. Eine gut konzipierte Telemetrie-Pipeline ermöglicht es Ihnen, Daten dem richtigen Speicher- und Analyse-Strategie zuzuordnen, sodass Sie nicht analytics-Ebene-Preise für Daten zahlen, die Sie nur für langfristige Compliance-Aufbewahrung benötigen. Die zweite Ebene ist Optionality, da die AI-Tool-Landschaft weiterhin schnell evolviert. Unternehmen, die ihre Observability-Strategie um das Ökosystem eines einzigen Anbieters herum aufbauen, werden teure Migrationsprojekte vor sich haben, sobald ein besseres Tool aufkommt.

Welche Fehler sehen Sie Unternehmen machen, wenn sie versuchen, bestehende Überwachungspraktiken auf agentische AI-Deployments umzustellen?

Der häufigste Fehler, den ich sehe, besteht darin, dass sie nach bestehenden Premium-Observability-Plattformen greifen, um agentische Spuren zu sammeln, ohne die Kostenauswirkungen zu berücksichtigen. Agentische Spuren sind groß, variabel und voluminös in einer Weise, die traditionelle Anwendungs-Telemetrie nicht ist, und die meisten Premium-Plattformen berechnen nach Einzug und Speicherung. Die Rechnung kann zu einem ernsthaften Problem werden, bevor Teams überhaupt realisieren, was passiert, und die typische Reaktion ist, das, was sie sammeln, zu reduzieren. Das Ergebnis ist das Schlimmste aus beiden Welten: hohe Kosten und unvollständige Sichtbarkeit.

Der zweite Fehler besteht darin, das falsche mentale Modell auf das anzuwendende Überwachung zu legen. Traditionelle Infrastruktur-Überwachung fragt “Ist das System hoch?” und löst Alarme aus, wenn es nicht ist. Diese Frage ist notwendig, aber bei Weitem nicht ausreichend für agentische Systeme, bei denen die Infrastruktur perfekt gesund sein kann, während der Agent stillschweigend schlechte Entscheidungen trifft, veraltete Daten abruft oder vom ursprünglichen Ziel abdriftet. Teams, die bestehende Dashboards und Alarm-Schwellen auf Agent-Workflows anwenden, überzeugen sich oft, dass sie Abdeckung haben, wenn sie tatsächlich nur die Wasserrohre beobachten.

Der dritte Fehler besteht darin, Instrumentierung als Nachgedanke zu behandeln. Unternehmen, die Agenten schnell pilotieren und in die Produktion überführen, ohne die Observability zu durchdenken, landen in teuren Sanierungszyklen, bei denen sie die Daten-Sammlungs-Architektur nach dem ersten bedeutenden Produktions-Ausfall neu aufbauen. Die Teams, die Agent-Deployments am erfolgreichsten skalieren, instrumentieren früh, etablieren Baselines, während der Verkehr niedrig und das Verhalten vorhersehbar ist, und bauen ihren Bewertungsrahmen auf, bevor sie ihn benötigen, anstatt danach, wenn etwas schief geht.

Blickt man in die Zukunft, wird Infrastruktur-Sichtbarkeit zu einer Voraussetzung für die Einführung von Unternehmens-AI werden, ähnlich wie Cloud-Observability für große Cloud-Migrationen unerlässlich wurde?

Der Vergleich zur Cloud ist extrem ähnlich. Das Wichtigste, was ich Kunden sage, wenn sie Infrastruktur in die Cloud verlagern, ist, dass sie nicht einfach verschieben und neu starten. Sie deployen eine ganz neue Architektur mit neuen Fähigkeiten. All dies muss auf eine Weise instrumentiert und überwacht werden, für die die vorherigen Tools wahrscheinlich nicht ausgelegt waren. Die Unternehmen, die diesen Schritt übersprangen, liefen in sich verschlechternde Ausfälle, die sie nicht diagnostizieren konnten, spiralförmige Kosten, die sie nicht erklären konnten, und Ausfälle, die sie nicht verhindern konnten. Observability wurde zur Grundlage des Vertrauens, das es der Cloud ermöglichte, im großen Maßstab zu skalieren, und das gleiche Muster wiederholt sich nun mit agentischer AI, schneller und mit höheren Einsätzen.

Der primäre Grund, warum Agenten diese Art von Aufsicht benötigen, liegt darin, dass sie per Design nicht deterministisch sind, ihr Verhalten zur Laufzeit entsteht und ihre effektive Fähigkeit jedes Mal wächst, wenn Sie ein neues Tool verbinden. Statische vorherige Zertifizierung kann ein System nicht abdecken, dessen Aktionsfläche sich mit jeder Integration ändert. Agenten werden innerhalb definierter Vertrauensgrenzen operieren, und diese Grenzen werden sich im Laufe der Zeit ausdehnen, wenn Observability-, Richtlinien- und Bewertungs-Infrastruktur heranreift. Die Grenzen selbst werden nie verschwinden, und das ist kein Versagen. So funktionieren bereits alle bedeutenden autonomen Systeme der Welt.

Vielen Dank für das großartige Interview. Leser, die mehr erfahren möchten, sollten Cribl besuchen.