Datadog Kosten: Was die Rechnung treibt und wie Sie sie steuern

Die Rechnung als getrennte Zähler lesen

Datadog berechnet nicht einen Preis für "Monitoring". Jedes Produkt hat eine eigene Einheit. Die Preisseite listet sie Produkt für Produkt auf.

Der erste Schritt ist daher eine Tabelle: Produkt, Abrechnungseinheit, aktuelle Nutzung und Verantwortlicher. Datadog dokumentiert getrennte Berechtigungen für Billing und Nutzung. Fordern Sie Usage Read an, um Nutzung und Usage Attribution einzusehen. Änderungen an der Zuordnung erfordern Usage Edit. Für Vertrags- und Zahlungsdetails benötigen Sie Billing Read. Fragen Sie einen Administrator nach zusätzlich benötigten Berechtigungen.

Was jeder Zähler zählt

Das sind die Einheiten, wie sie die Preisseite und die Billing-Dokumentation beschreiben. Prüfen Sie sie gegen Ihren eigenen Plan, denn Kontingente unterscheiden sich je nach Plan und Vertrag.

• Infrastructure Hosts: Abrechnung pro Host und Monat. Ein Host ist jede physische oder virtuelle OS-Instanz, die Sie überwachen. Hosts werden stündlich gemessen. Datadog lässt die obersten 1 Prozent der stündlichen Werte weg, sodass kurze Spitzen die Rechnung nicht bestimmen.
• Container: Der Pro-Plan enthält 5 Container pro Host, der Enterprise-Plan 10 (Preisseite). Weitere Container werden pro Container und Stunde berechnet.
• Custom Metrics: Eine Custom Metric ist ein Metrikname mit einer Kombination von Tag-Werten, einschließlich des Host-Tags. Datadog zählt die verschiedenen Custom Metrics jede Stunde und bildet daraus den Monatsdurchschnitt. Wie oft Sie Datenpunkte senden, ändert die Zahl nicht.
• Logs: zwei Zähler. Ingest wird pro GB berechnet, das aufgenommen oder gescannt wird. Index wird pro Million Log-Events berechnet, die durchsuchbar bleiben. Die Aufbewahrung wählen Sie pro Index.
• APM: Abrechnung pro APM-Host und Monat. Ingested Spans werden am Monatsende in GB berechnet. Indexed Spans werden pro Million berechnet. Jeder APM-Host enthält von beidem eine Menge (150 GB Ingest und 1 Million indexierte Spans pro Host, laut APM-Billing-Seite).

Welche Zähler mit der Größe wachsen

So funktioniert die Abrechnung. Es ist keine Rangliste. Host- und Container-Zahlen folgen Ihrer Infrastruktur. Die übrigen Zähler folgen Ihren Daten.

Die Zahl der Custom Metrics hängt von den tatsächlich gesendeten Kombinationen von Tag-Werten ab. Im Datadog-Beispiel ergeben vier beobachtete Kombinationen vier Count- oder Gauge-Metriken. Dieselben vier Kombinationen ergeben 20 Histogramm-Metriken mit den Standardaggregationen. Ein neuer Tag erhöht die Zahl nur, wenn zusätzliche Kombinationen entstehen.

Indexierte Logs wachsen mit der Zahl der Log-Events, die Sie durchsuchbar halten. Ein neuer Service, der bei jedem Request loggt, erhöht sie. Datadog berechnet die im Monat indexierten Events. Nutzung über Ihrer Vereinbarung wird als On-Demand berechnet.

Ingested und Indexed Spans wachsen mit dem Request-Volumen und damit, wie viele Traces Ihre Sampling-Regeln behalten. Indexed Spans berechnet Datadog nach den Retention Filtern, die Sie setzen.

Steuerung, die Datadog bietet

Arbeiten Sie vom größten Zähler nach unten. Für jeden gibt es in Datadog selbst eine Steuerung.

• Metrics without Limits: Laut Datadog trennt es die Ingest-Kosten von den Index-Kosten. Sie senden weiter alle Daten und wählen, welche Tags abfragbar bleiben. Im Beispiel der Dokumentation sinkt eine Metrik mit zwei behaltenen Tags von 4 auf 3 indexierte Custom Metrics, während Ingested bei 4 bleibt. Ingested-Volumen zählt nur für Metriken, die Sie konfiguriert haben.
• Exclusion Filter für Logs: Ausgeschlossene Logs werden aus den Indizes verworfen. Laut Dokumentation laufen sie weiter durch Live Tail und speisen weiter Log-based Metrics und Archive. Nutzen Sie sie für Logs mit hohem Volumen und geringem Wert. Klären Sie mit Datadog, wie ausgeschlossene Logs auf den Ingest-Zähler zählen.
• Tagesquoten für Logs: Eine Quote pro Index begrenzt, wie viele Events pro Tag indexiert werden. Nach dem Limit werden Logs nicht mehr indexiert, erreichen aber weiter Live Tail und Archive. Datadog empfiehlt einen Monitor, der bei 80 Prozent der Quote auslöst.
• Ingestion Controls für Traces: Die Seite Ingestion Control zeigt jeden Service und erlaubt Sampling-Regeln. Sortieren Sie nach Downstream Bytes/s, um die größten Quellen zu finden. Bei OpenTelemetry wirkt sich SDK-Sampling auch auf die APM-Trace-Metriken aus. Für Metriken über den gesamten Datenverkehr müssen alle Spans den span_metrics-Connector im Collector durchlaufen, bevor Sampling angewendet wird.
• Retention Filter: Sie bestimmen, welche Spans indexiert werden, und damit, welche Spans als Indexed Spans berechnet werden.
• Usage Attribution: schlüsselt die Nutzung nach bis zu drei Tag-Keys auf, mit CSV-Dateien und einer API. Mit Usage Read können Sie sie einsehen. Änderungen am Setup erfordern Usage Edit. Enthalten ist nur Nutzung, die sich bei der Instrumentierung taggen lässt.

Nutzung vor der Rechnung beobachten

Datadog veröffentlicht Metriken zur geschätzten Nutzung, zum Beispiel datadog.estimated_usage.apm.ingested_bytes und datadog.estimated_usage.apm.indexed_spans. Für Logs erfassen die Standard-Usage-Metriken aufgenommene Logs, aufgenommene Bytes und indexierte Logs. Datadog weist darauf hin, dass dies Schätzungen sind, die von den offiziellen Abrechnungszahlen abweichen können.

Legen Sie diese auf ein Dashboard und richten Sie pro Zähler einen Monitor ein. Taggen Sie vorher Services und Teams, damit Usage Attribution zeigen kann, wer welchen Teil verursacht.

Die Option behalten, das Tool zu wechseln

Datadog unterstützt OpenTelemetry. Wenn Ihre Anwendungen OpenTelemetry-Daten senden, ist die Instrumentierung nicht an einen Anbieter gebunden. Das Ziel der Daten kann sich ändern.

Die OpenTelemetry-Seite von Datadog nennt diese Wege für Traces, Metriken und Logs: den Datadog Agent mit dem DDOT Collector, einen OpenTelemetry Collector, den Datadog Agent als OTLP-Empfänger und direkte OTLP-Ingestion. Datadog empfiehlt den Agent mit dem DDOT Collector. Die direkte Ingestion beschreibt es als Option für Fälle, in denen ein Collector oder Agent nicht möglich ist.

Mit einem Collector ist das Ziel nur wenige Zeilen Konfiguration. Dieses Beispiel ist aus der Datadog-Dokumentation gekürzt. Die Dokumentation sagt, dass für Produktion ihre vollständige Konfiguration zu nutzen ist.

Dieses Weiterleitungsbeispiel erzeugt keine APM-Trace-Metriken und ergänzt keine Host- oder Cloud-Metadaten. Nutzen Sie dafür die vollständige Konfiguration von Datadog.

receivers:
  otlp:
    protocols:
      http:
        endpoint: 0.0.0.0:4318
exporters:
  otlp_http:
    endpoint: https://otlp.${env:DD_SITE}
    headers:
      dd-api-key: ${env:DD_API_KEY}
service:
  pipelines:
    traces:
      receivers: [otlp]
      exporters: [otlp_http]
    metrics:
      receivers: [otlp]
      exporters: [otlp_http]
    logs:
      receivers: [otlp]
      exporters: [otlp_http]

Reihenfolge der Arbeit

Eine kurze Reihenfolge, die für die meisten Teams passt:

• Besorgen Sie sich Usage-Read-Zugriff und notieren Sie jeden Zähler mit der aktuellen Nutzung.
• Legen Sie Tag-Keys für Usage Attribution fest (Team, Service, Umgebung). Dafür brauchen Sie Usage Edit.
• Nehmen Sie den größten Zähler zuerst und nutzen Sie seine Steuerung: Tags, Exclusion Filter, Quoten oder Sampling.
• Richten Sie Usage-Monitore ein, damit eine neue Log-Quelle oder ein neuer Tag Sie nicht überrascht.
• Nutzen Sie OpenTelemetry für neue Services und prüfen Sie in einer Testumgebung, dass Ihre Ansichten weiter funktionieren.