Groundcovers 100-Mio.-Dollar-Series-C verändert die Observability-Kaufentscheidung

Jeder VP Engineering, bei dem in den nächsten zwei Quartalen eine Datadog- oder New-Relic-Verlängerung ansteht, hat soeben ein neues Argument für das Gespräch mit dem CFO bekommen. Groundcover, ein Tel Aviver Observability-Anbieter auf Basis von eBPF und OpenTelemetry, schloss in der Woche vom 31. Juli eine Series-C-Runde über 100 Millionen Dollar ab. Die Runde ist weniger bedeutsam für das, was sie über Groundcover aussagt, als für das, was sie über die Struktur des Observability-Budgetpostens für 2027 bedeutet.

Was geschehen ist

Wie Network World berichtete, wurde die Series C von One Peak angeführt, mit Beteiligung von Morgan Stanley Expansion Capital, Zeev Ventures, Angular Ventures, Heavybit und Jibe. Damit beläuft sich die Gesamtfinanzierung für das 2021 gegründete Unternehmen auf 160 Millionen Dollar. Die Runde folgt auf eine Series B über 35 Millionen Dollar im April 2025 – das Tempo ist aggressiv: etwa fünfzehn Monate zwischen B und C, und der Betrag hat sich fast verdreifacht.

Das Pitch des Unternehmens lautet, in den Worten von CEO und Mitgründer Shahar Azulay, dass Observability einen Kategoriewandel durchläuft. „Ich finde, was gerade mit Observability passiert, ist faszinierend", sagte er gegenüber Network World. Die technische Wette besteht darin, dass eBPF – die Extended Berkeley Packet Filter Kernel-Technologie, die Code sicher innerhalb des Linux-Kernels ausführt, ohne ein eigenes Modul zu erfordern – Groundcover einen Blickwinkel verschafft, den SDK-basierte Instrumentierung nicht bieten kann. Die kommerzielle Wette lautet, dass Telemetrie aus agentischen KI-Workflows in Volumen und Sensitivität explodieren wird und Unternehmen diese nicht an ein gemeinsam genutztes Vendor-Backend schicken wollen.

Deshalb speichert Groundcover Telemetrie in der eigenen Cloud-Umgebung des Kunden. Das ist auch der Grund, warum das Unternehmen intensiv KI-nahe Produkte entwickelt: Agent Mode, ein eingebauter Assistent, mit dem Ingenieure Dashboards erstellen sowie Logs und Traces analysieren können, ohne manuell Abfragen zu schreiben, sowie eine Model Context Protocol-Integration, die Agent Mode mit Coding-Agents und Workflow-Tools wie Linear verbindet. Azulay sagte, die MCP-Adoption verlief schneller als erwartet.

Technische Architektur

Zwei architektonische Entscheidungen tragen hier die Hauptlast, und Platform Leads sollten beide verstehen, bevor sie dem Vendor-Pitch zustimmen.

Die erste ist eBPF als Erfassungsschicht. Traditionelle Observability erfordert, dass Entwickler Code instrumentieren, ein SDK einbinden und Telemetrie ausgeben, die der Anbieter versteht. Dieses Modell versagt in dem Moment, in dem Ingenieure LangChain-Agents, MCP-Server und Drittanbieter-Modelle einbinden, die niemand erfasst hat. „eBPF ist gewissermaßen das Sicherheitsnetz – selbst wenn du nicht instrumentiert hast, selbst wenn du nicht die volle Kontrolle hast, wirst du wissen, welche agentischen Workflows in der Produktion laufen, welche Modelle genutzt werden, welche Anbieter sie verwenden", sagte Azulay. Der Betrieb unterhalb der Anwendungsschicht bedeutet, dass das Observability-Tool Traffic und Syscalls sieht, unabhängig davon, ob das App-Team Tracing hinzugefügt hat. Für Teams, die KI-Features auf Kubernetes ausliefern, ist das der Unterschied zwischen dem Wissen über Token-Ausgaben und einer unangenehmen Überraschung am Quartalsende.

Die zweite ist Bring-your-own-Cloud-Speicher. Die meisten SaaS-Observability-Anbieter nehmen Kunden-Telemetrie in ein von ihnen betriebenes Multi-Tenant-Backend auf. Das funktioniert gut für HTTP-Request-Logs. Es funktioniert schlecht, wenn Traces – wie Azulay betonte – die tatsächliche Anfrage eines Kunden enthalten und nicht nur strukturierte Request-Daten. Prompts sind Nutzerinhalte. Je nach Jurisdiktion und Branche können sie auch regulierte Inhalte sein. Das Vorhalten von Telemetrie im Kunden-VPC verändert das Gespräch über Datenhaltung von einem Vendor-Fragebogen zu einem Architekturdiagramm.

Die dritte Verschiebung, die eigentlich eine Folge der ersten beiden ist, betrifft das, was Teams messen. Latenz und Fehlerrate sind weiterhin vorhanden. Jetzt stehen Token-Verbrauch und Halluzinierungsraten gleichberechtigt daneben. Distributed Tracing, das eine vorhersehbare Anzahl von Hops zwischen Services voraussetzte, muss nun eine einzelne Agent-Session berücksichtigen, die sich in Dutzende Tool-Aufrufe und interne Modell-Aufrufe ohne festes Muster auffächert. Azulay betont ausdrücklich, dass dies kein umgezeichnetes APM-Produkt ist. „Es wird nicht dasselbe Produkt sein. AI Observability ist nicht genau das Gleiche wie APM."

Wer unter Druck gerät

Die etablierten Anbieter. Wenn AI Observability wirklich eine andere Produktkategorie ist als ein ergänzendes Feature, dann befinden sich Datadog, New Relic, Splunk und Dynatrace in der Lage, in der sich On-Premises-Monitoring-Anbieter um 2015 befanden: Sie verkaufen noch das Alte, während um sie herum Neues finanziert wird. Das bedeutet nicht, dass sie verlieren. Es bedeutet, dass ihre Per-Host- und Per-GB-Preismodelle für Workloads falsch erscheinen, bei denen ein einziger Agent-Trace einen mehrseitigen Prompt-Payload enthalten kann.

Der CFO jedes Unternehmens ab Series B mit nennenswertem KI-Feature-Aufwand sollte dem VP Engineering diese Woche eine konkrete Frage stellen: Wie viel Prozent unserer Observability-Rechnung wird jetzt durch KI-Workload-Telemetrie verursacht, und wächst dieser Posten schneller als der zugrundeliegende Compute? Wenn ja, ist das Verlängerungsgespräch mit dem aktuellen Anbieter kein Verlängerungsgespräch mehr. Es ist ein Re-Architektur-Gespräch, und der Hebel liegt bei demjenigen, der das alternative Angebot mitbringt.

Engineering-Teams treffen es auch auf subtilere Weise. Wenn Ihr Platform-Team vor zwei Jahren auf SDK-basierte Instrumentierung standardisiert und interne Bibliotheken rund um den Vendor-Client geschrieben hat, lässt sich ein eBPF-basierter Ansatz nicht sauber integrieren. Entweder betreiben Sie beides parallel (doppelte Kosten, doppelte Verwirrung) oder Sie verpflichten sich zu einem Migrationsprojekt, das ein Quartal an Platform-Kapazität verschlingt. Keines davon ist kostenlos.

Auch der Stellenmarkt verschiebt sich. Observability-Ingenieure, die eBPF, Kernel-Level-Tracing und OpenTelemetry-Pipelines verstehen, waren schon immer selten und teuer. Mit MCP-Integrationserfahrung und Prompt-bewusstem Telemetrie-Design haben Sie einen kleinen Kandidatenpool, um den Groundcover, Chronosphere, Honeycomb und jedes KI-native Startup konkurrieren werden. Planen Sie entsprechend.

Handlungsempfehlungen für Engineering-Teams

Erstens: Prüfen Sie, was Ihr aktueller Observability-Anbieter tatsächlich von Ihren KI-Workloads erfasst. Lautet die Antwort „was unsere Entwickler manuell instrumentieren", haben Sie eine Sichtbarkeitslücke, die als Produktionsvorfall sichtbar wird, bevor sie als Budgetposten erscheint. Azulay verglich die aktuelle KI-Sichtbarkeitslücke mit der Prä-Observability-Ära vor etwa einem Jahrzehnt. Er liegt nicht falsch, und Teams, die diesen Wandel miterlebt haben, erinnern sich, wie viel des Schmerzes durch verzögerte Tooling-Entscheidungen selbst verursacht wurde.

Zweitens: Holen Sie Ihren General Counsel in das Observability-Gespräch. Wenn Traces jetzt Kunden-Prompts enthalten, müssen Ihre Datenverarbeitungsverträge mit Ihrem Observability-Anbieter das widerspiegeln. Ein gemeinsam genutztes Multi-Tenant-Backend, das Prompt-Inhalte speichert, hat eine andere regulatorische Ausgangslage als strukturierte Request-Metadaten. Bring-your-own-Cloud-Architekturen sind den operativen Aufwand wert, wenn sie ein Compliance-Gespräch vom Tisch nehmen.

Drittens: Behandeln Sie MCP-Integration als echtes Bewertungskriterium, nicht als Demo-Punkt. Das von Azulay beschriebene Muster – bei dem einige Kunden Observability über MCP abfragen statt über das Dashboard, während andere es nutzen, um direkt Korrekturen zu schreiben – wird innerhalb von achtzehn Monaten die tatsächliche Arbeitsweise im On-Call-Betrieb sein. Anbieter ohne glaubwürdige MCP-Story werden in Enterprise-RFPs bereits still deprioritisiert.

Viertens: Modellieren Sie die Unit Economics. Kosten pro Trace, Kosten pro gespeichertem GB, Kosten pro aktivem Agent. Wenn Ihre KI-Feature-Roadmap das Agent-Volumen im nächsten Jahr verdreifacht, rechnen Sie das gegen Ihren aktuellen Vertrag durch, bevor Sie etwas über zwölf Monate hinaus unterzeichnen.

Wichtigste Erkenntnisse

• Groundcovers 100-Mio.-Dollar-Series-C, angeführt von One Peak, bringt die Gesamtfinanzierung auf 160 Mio. Dollar und bestätigt AI Observability als eigenständige Kategorie jenseits von traditionellem APM.
• eBPF-basierte Erfassung entfernt den SDK-Instrumentierungsschritt – das wird wichtiger, je mehr Engineering-Teams den Überblick verlieren, welche agentischen Workflows und Modell-Anbieter in der Produktion laufen.
• Bring-your-own-Cloud-Telemetriespeicherung wird zur regulatorischen Anforderung, nicht zur Präferenz, sobald Traces rohe Kunden-Prompts enthalten.
• Token-Verbrauch und Halluzinierungsrate sind jetzt erstklassige Observability-Metriken neben Latenz und Fehlerrate. Vendor-Verträge, die vor dieser Verschiebung geschlossen wurden, haben falsche Preisstrukturen.
• Die Adoption von MCP-Integration übertrifft die Erwartungen der Anbieter. Teams, die in diesem Quartal Observability-Plattformen evaluieren, sollten fragen, wie der KI-Assistent des Anbieters Kontext an Coding-Agents weitergibt – nicht nur, ob er einen hat.