Skip to content
RiverCore
Zurück zu ArtikelnENGINEERING
Datadog bricht sein SaaS-Only-Modell mit BYOC und Federated Logs auf
Datadog BYOCfederated logsobservabilityDatadog federated logs Snowflake DatabricksBYOC cloud observability platform

Datadog bricht sein SaaS-Only-Modell mit BYOC und Federated Logs auf

12 Jun 20267 Min. LesezeitSarah Chen

Datadog hat mehr als ein Jahrzehnt damit verbracht, Observability als reine SaaS-Kategorie zu definieren. Diese Woche auf der DASH-Konferenz endete diese Haltung. Der Anbieter begann, die Analyse von Metriken, Logs und Traces zu unterstützen, die in kundenkontrollierter Cloud-Infrastruktur gespeichert sind, führte eine Federated-Logs-Suche gegen externe Speicher ein und integrierte eine neue KI-Agent-Konsole, um Token-Ausgaben für sein eigenes Bits AI sowie für Agenten von Drittanbietern wie Anthropic und OpenAI zu verfolgen.

Was passiert ist

Die Schlagzahl ist keine Dollarsumme, sondern ein Kategorienwechsel: von null auf drei. Datadog wechselte in einem einzigen Keynote-Zyklus von null kundenkontrollierten Speicheroptionen zu drei eigenständigen Lösungen (BYOC, Federated Logs und ein gehosteter MCP-Server, über den externe Agenten seine Erkennungen abfragen können). Wie TechTarget berichtete, war Datadog zuvor streng SaaS-orientiert, wobei alle Telemetriedaten in der eigenen Cloud landeten. Zara Boddula, Produktmanagerin bei Datadog, begründete den Wandel mit Telemetrievolumen im Petabyte-Bereich, die durch KI-Workloads und grenzüberschreitenden Compliance-Druck entstehen.

Die Federated-Logs-Suche erweitert den Log Explorer, um Databricks, ClickHouse und Snowflake abzufragen, ohne diese Daten zuvor in Datadog zu importieren. Carlos Casanova von Forrester stellte fest, dass Cisco/Splunk denselben Federated-Weg einschlägt, und dass dieses Muster bei korrekter Umsetzung Ingest-, Speicher- und Rechenkosten reduziert, ohne an Genauigkeit zu verlieren. Das ist das Versprechen.

Auf der KI-Seite führte Datadog eine Agent-Konsole ein, die Nutzung und Kosten für Bits-AI-Agenten sowie Drittanbieter-Agenten von Anthropic und OpenAI überwacht. AI Guard, ein agentisches Sicherheitstool, wurde in einer eingeschränkten Vorschau veröffentlicht. Ein neuer gehosteter MCP-Server umfasst sowohl Observability als auch Sicherheit. Datadog zeigte außerdem eine Vorschau einer Runtime-Priorisierungs-Engine, die automatisch „Kronjuwelen"-Systeme anhand von Telemetriedaten statt über Benutzer-Tags erkennt, und entkoppelte seinen Bits Security Analyst vom eigenen SIEM, sodass er nun auch mit Splunk und Microsoft Sentinel funktioniert. Die Quelle gibt keine Preise für BYOC oder Federated Logs bekannt, was relevant ist, da der gesamte Geschäftsfall für den Wechsel weg von SaaS-Speicher auf Kosten basiert.

Technische Analyse

BYOC und Federated Search sind zwei unterschiedliche Architekturen, die als eine einzige Ankündigung präsentiert werden – Engineering-Teams müssen sie getrennt betrachten.

BYOC hält die Datenebene im Cloud-Account des Kunden. Die Steuerungsebene (Abfragen, Dashboards, Alerting) verbleibt in Datadogs SaaS. Das ist das Standardmuster, das Snowflake-native und ClickHouse-native Observability-Startups seit zwei Jahren einsetzen. Der Kompromiss ist bekannt: Man zahlt dem Hyperscaler für Speicher und Rechenleistung bei der Telemetrie-Aufbewahrung statt Datadogs GB-Ingest-Tarif, und nimmt dafür Abfragelatenz in Kauf, die vom eigenen Objektspeicher und der eigenen Rechenkapazität abhängt. Die Quelle gibt nicht an, welche Clouds beim GA unterstützt werden, noch ob BYOC alle drei Telemetrietypen (Metriken, Logs, Traces) gleichwertig abdeckt. Die realistische Einschätzung: Wenn BYOC AWS-first mit Logs-only beim Launch erscheint, ist es ein defensives Produkt. Wenn es von Tag eins an Metriken und Traces über AWS, GCP und Azure abdeckt, ist es ein echter architektonischer Wandel.

Federated Logs ist eine andere Angelegenheit. Anstatt Daten zu verschieben, stellt der Log Explorer Abfragen direkt gegen Databricks, ClickHouse und Snowflake aus. Das ist das Muster, das Carlos Casanova als dasselbe identifizierte, das Cisco/Splunk verfolgt. Die technische Frage ist das Query-Pushdown: Wie viel der Filter-, Aggregations- und Join-Arbeit wird im externen Warehouse ausgeführt, und wie viel wird in Datadogs Abfrageebene gezogen? Wenn das Pushdown flach ist, wird „Federated" zu einem höflichen Begriff für „wir leiten Ihre Warehouse-Daten ab und berechnen Ihnen die Bandbreite zweimal."

Dann gibt es noch den Lock-in-Rückstand. Torsten Volk von Omdia war direkt: Datadog erfordert weiterhin seinen proprietären Agenten (oder seine eigene OpenTelemetry-Distribution) für Datenbanküberwachung, Data Observability und Cloud-Netzwerküberwachung. Der Upstream-OpenTelemetry-Collector bietet nur Basisfunktionalität. Volk stellte dies Elastic gegenüber, das Vanilla-OTel-Collector über alle seine Observability-Dienste hinweg unterstützt. BYOC verschiebt also die Speichergrenze, nicht aber die Erfassungsgrenze. Prüfbar, aber unbekannt: Wie viel Prozent des typischen Datadog-Telemetrievolumens eines Kunden erfordern den proprietären Agenten? Liegt die Antwort über 50 Prozent, ist BYOC kosmetisch.

Wer betroffen ist

Die erste betroffene Gruppe sind BYOC-native Startups. Anbieter, die ihr gesamtes Angebot auf „Ihre Daten, Ihre Cloud" gegen Datadogs SaaS-Lock-in aufgebaut haben, haben soeben ihr stärkstes Differenzierungsmerkmal verloren. Sie haben noch ein Argument (kein proprietärer Agent, echte OTel-native Ingest, einfachere Preisgestaltung), aber die Marketing-Folie mit dem Satz „Im Gegensatz zu Datadog verlassen Ihre Daten niemals Ihren Account" ist hinfällig.

Die zweite Gruppe sind Enterprise-Plattformteams, die bereits mehrjährige Datadog-Verträge auf Basis reiner SaaS-Annahmen abgeschlossen haben. Sie müssen jetzt entscheiden, ob sie nachverhandeln. Wenn BYOC-Preise deutlich günstiger sind als SaaS-Ingest, wird die Finanzabteilung fragen warum. Wenn nicht, ist die Ankündigung Theater. Eric Swanson, leitender SRE beim Denver-basierten MagicSchool AI, fasste die Skepsis beim Keynote zusammen: Er verlor den Überblick über die „mit Stolz ankündigenden" Features, stellte fest, dass viele davon KI-basiert sind mit nutzungsabhängigen Token-Kosten – und das noch bevor man zur bestehenden Komplexität von APM, Logs, Traces, RUM und Profiles kommt, die alle separat und workload-abhängig abgerechnet werden.

Die dritte Gruppe sind SIEM-Platzhirsche. Datadogs Entkopplung des Bits Security Analyst vom eigenen SIEM und die Ausrichtung auf Splunk und Microsoft Sentinel ist ein direkter Angriff auf Accounts, bei denen Datadog die Observability hat, aber den Security-Data-Lake verloren hat. Es ist damit zu rechnen, dass Splunk- und Sentinel-Vertriebsteams innerhalb von 90 Tagen in Verlängerungsgesprächen den Satz hören werden: „Wir nutzen einfach Datadogs Analyst auf Ihrer Plattform."

Die offene Frage für alle drei Gruppen: Skalieren Datadogs Preise für KI-Features linear mit dem Token-Verbrauch, oder gibt es gebündelte Stufen? Die Quelle bestätigt, dass die Agent-Konsole Kosten ausweist, legt das eigene Abrechnungsmodell jedoch nicht offen. Bis das geklärt ist, wird die Einführung von KI-Features in kostensensitiven Engineering-Organisationen vorsichtig bleiben.

Handlungsempfehlungen für Engineering-Teams

Wer Datadog im großen Maßstab betreibt, sollte in diesem Quartal drei konkrete Schritte unternehmen.

Erstens: Prüfen Sie Ihren Agent-Bestand. Stellen Sie fest, welche Features in Ihrem aktuellen Vertrag den proprietären Datadog-Agenten erfordern und welche auf dem Upstream-OpenTelemetry-Collector laufen. Dieses Verhältnis ist Ihr tatsächlicher Lock-in-Koeffizient. Volks Konzept der „Lock-in-Grade" ist das richtige Denkmodell: BYOC reduziert den Speicher-Lock-in, ändert aber nichts am Erfassungs-Lock-in. Wenn Datenbanküberwachung und Cloud-Netzwerküberwachung tragende Säulen Ihres Stacks sind, befinden Sie sich nach wie vor fest im geschlossenen System.

Zweitens: Modellieren Sie Federated Logs gegen Ihre aktuelle Ingest-Rechnung, bevor Sie migrieren. Wählen Sie eine hochvolumige Log-Quelle (Anwendungslogs sind meist der günstigste Test), leiten Sie sie nach Snowflake oder ClickHouse weiter und vergleichen Sie die Abfragelatenz im Log Explorer mit Ihrer bestehenden SaaS-Ingest-Baseline. Yanbing Lis Muster „erst kleines Modell, dann Frontier-LLM" für AI Guard ist hier übertragbar: Leiten Sie günstige, hochvolumige Abfragen an den Federated-Speicher weiter und behalten Sie latenzempfindliche Incident-Response-Pfade im heißen SaaS-Speicher. Die Architekturempfehlungen von Google Cloud zur gestaffelten Datenhaltung lassen sich sauber auf diese Aufteilung anwenden.

Drittens: Setzen Sie ein hartes Budget für KI-Agenten-Ausgaben, bevor Sie etwas aktivieren. Die Agent-Konsole gibt Ihnen Sichtbarkeit, keine Kontrolle. Definieren Sie Token-Budgets pro Team, verknüpfen Sie diese mit der Reporting-Funktion der Konsole und behandeln Sie Überschreitungen als Paging-Ereignisse. Katie Norton von IDC hatte recht, dass die Runtime-Priorisierungs-Engine das bedeutendste Update für Anwendungssicherheit in dieser Ankündigung ist, weil Tags veralten und Eigenverantwortung unzugeordnet bleibt. Dieselbe Logik gilt für die KI-Kostenzuständigkeit. Ohne einen zugewiesenen Verantwortlichen pro Agent wird die Agent-Konsole zu einem Bericht, den niemand liest.

Wichtigste Erkenntnisse

  • Datadog beendete seine strikte SaaS-Haltung mit BYOC und Federated-Logs-Suche gegen Databricks, ClickHouse und Snowflake – und folgt damit der Cisco/Splunk-Richtung in Sachen Federation.
  • Die Anforderung des proprietären Agenten für Datenbanküberwachung, Data Observability und Cloud-Netzwerküberwachung hält eine bedeutende Lock-in-Fläche aufrecht. Elastic bleibt die sauberere OTel-native Alternative.
  • Die Agent-Konsole meldet KI-Ausgaben für Bits AI, Anthropic und OpenAI, aber die Quelle legt Datadogs eigenes Abrechnungsmodell für KI-Features nicht offen – das ist die eigentliche Variable, die über die Akzeptanz entscheidet.
  • Der nun eigenständige Bits Security Analyst gegen Splunk und Microsoft Sentinel ist ein direkter Wettbewerbszug gegenüber SIEM-Platzhirschen. Innerhalb von 90 Tagen ist mit Verlängerungsdruck zu rechnen.
  • Prüfbare Vorhersage: Wenn BYOC-Preise beim GA mehr als 30 Prozent unter dem entsprechenden SaaS-Ingest liegen, ist bis Q4 2026 mit mindestens einer öffentlich angekündigten Enterprise-Migration weg von reinem SaaS-Datadog zu rechnen. Ist der Abstand kleiner, bleibt die BYOC-Akzeptanz einstellig und die Ankündigung war defensiv.

Häufig gestellte Fragen

F: Was ist Datadog BYOC und wie unterscheidet es sich vom bisherigen SaaS-Modell?

BYOC (Bring-your-own-cloud) ermöglicht es Datadog, Metriken, Logs und Traces zu analysieren, die im eigenen Cloud-Account des Kunden gespeichert sind, anstatt im SaaS-Backend von Datadog. Bisher war Datadog strikt SaaS-orientiert, was bedeutete, dass alle Telemetriedaten in Datadog-kontrollierte Infrastruktur importiert werden mussten. Die Steuerungsebene (Abfragen, Dashboards) läuft weiterhin in Datadogs Cloud.

F: Beseitigt die Federated-Logs-Suche den Vendor-Lock-in bei Datadog?

Nein. Die Federated-Logs-Suche ermöglicht es dem Log Explorer, Databricks, ClickHouse und Snowflake direkt abzufragen, aber Datadog erfordert weiterhin seinen proprietären Agenten oder seine eigene OpenTelemetry-Distribution für erweiterte Features wie Datenbanküberwachung, Data Observability und Cloud-Netzwerküberwachung. Der Upstream-OpenTelemetry-Collector bietet lediglich Basisfunktionalität.

F: Wie geht die Datadog Agent-Konsole mit KI-Token-Kosten um?

Die Agent-Konsole überwacht Nutzung und Kosten für Datadogs eigene Bits-AI-Agenten sowie für Drittanbieter-Agenten von Anthropic und OpenAI. Sie bietet Einblick in den Token-Verbrauch pro Agent, legt jedoch Datadogs eigenes Abrechnungsmodell für KI-Features nicht offen – APM, Logs, Traces, RUM und Profiles werden weiterhin separat und workload-abhängig abgerechnet.

SC
Sarah Chen
RiverCore Analyst · Dublin, Ireland
TEILEN
// RELATED ARTICLES
StartseiteLösungenProjekteÜber unsKontakt
News06
Dublin, Irland · EUGMT+1
LinkedIn
🇩🇪DE