Dynatrace-Ingest-Kosten senken
Dynatrace misst Logs dreifach — einmal beim Ingest, erneut für jeden GiB-Tag der Aufbewahrung und im nutzungsbasierten Modell nochmals für jedes GiB, das eine Abfrage durchsucht. Entscheiden Sie am OpenTelemetry Collector, was alle drei wert ist, bevor die Daten Ihren Tenant erreichen. Selbst gehostet, Preis pro Collector.
25 Collectors nach kostenloser Registrierung · 5 ohne Registrierung Wie die kostenlose Stufe funktioniert
Dynatrace bietet echten Mehrwert. Überraschend ist meist, dass Volumen nicht einmal abgerechnet wird: beim Eintreffen, an jedem Tag der Aufbewahrung und im nutzungsbasierten Modell erneut, sobald jemand eine Frage daran stellt.
Log — Ingest & Process wird einmal berechnet, wenn die Daten in den Tenant gelangen. Log — Retain wird pro GiB-Tag berechnet, dasselbe Gigabyte also für jeden Tag erneut. Ein Gigabyte über neunzig Tage ist nicht eine Abrechnung, sondern neunzig.
Readiness-Probes, Polling-Verkehr, Retry-Stürme und doppelte Felder machen einen grossen Teil der meisten Log-Pipelines aus — ingestiert, aufbewahrt und selten gelesen.
Der Agent eines Backends verschickt, worauf er angesetzt ist. Eine spürbare Reduktion bedeutet, Telemetrie vorgelagert am Collector umzuwandeln, nicht erst bei Dynatrace.
Sensible Felder rutschen in Logs und werden in Dynatrace indexiert, wo sie noch lange aufbewahrt und abfragbar sind, nachdem sie längst hätten verworfen werden sollen.
Sicherheitsrelevante Logs und wenig nützliche Debug-Ausgaben landen im selben teuren Index, weil keine Ebene entscheidet, was wohin gehört.
Niemand verwirft in Produktion Daten, ohne vorher genau zu sehen, was ein Filter entfernt. Also wächst das Volumen — und die Rechnung — weiter.
Die meisten Reduktionsprojekte, die mit einer unveränderten Rechnung enden, haben die falsche Position gewählt. Dynatrace misst mehrere Dinge getrennt, und nur ein Teil davon reagiert darauf, dass Sie weniger senden.
Wird einmal berechnet, auf das Volumen, das in Ihren Tenant gelangt. Das ist die Position, an die die meisten denken, wenn sie von Telemetriekosten sprechen — bei Dynatrace ist sie nur die erste von dreien.
Was es bewegt: Am Collector filtern und aggregieren. Was den Tenant nie erreicht, wird nie ingestiert — und fehlt auch in den beiden folgenden Positionen.
Wird pro GiB-Tag berechnet: Dasselbe Gigabyte wird für jeden Tag erneut abgerechnet, den Sie es aufbewahren. Ein Gigabyte über neunzig Tage sind neunzig Abrechnungen, nicht eine.
Was es bewegt: Hier gibt es zwei unabhängige Hebel, und die meisten Teams ziehen nur den ersten. Senken Sie das Volumen — und prüfen Sie getrennt davon die Aufbewahrungsdauer. Wenig sehr lange aufzubewahren kann teurer sein als viel für ein kurzes Fenster.
Im nutzungsbasierten Modell werden Retain und Query getrennt abgerechnet — in Dynatrace’ eigenen Worten zahlen Sie für jede Abfrage, berechnet auf das Volumen, das eine Abfrage durchsucht. Ein breites Dashboard über ein weites Zeitfenster hat damit einen Preis, was bei den meisten Backends nicht der Fall ist.
Was es bewegt: Daten, die nie ingestiert wurden, werden auch nie durchsucht — Filtern am Rand senkt also auch diese Position. Die Alternative ist das Modell „Retain with Included Queries“, bei dem ein Abfragekontingent in der Aufbewahrung enthalten ist. Prüfen Sie zuerst, auf welchem der beiden Modelle Ihr Vertrag liegt.
Full-Stack und Infrastructure Monitoring werden nach den überwachten Hosts abgerechnet, nicht danach, was diese Hosts senden.
Was es bewegt: Keine Änderung an der Telemetrie bewegt diese Position. Liegt dort der Großteil Ihrer Dynatrace-Ausgaben, ist Filtern das falsche Projekt.
Die Mechanik so, wie Dynatrace sie dokumentiert — nicht, wie wir sie gern hätten. Prüfen Sie sie gegen Ihren eigenen Vertrag, der abweichen kann. Dynatrace-Lizenzdokumentation zu Log Analytics (Englisch) Telemetrie erreicht Dynatrace über den otlphttp-Exporter des Collectors — jede Änderung geschieht also, bevor dieser Exporter läuft.
Die Reduktion geschieht in der Processor-Kette des Collectors, bevor etwas den Tenant erreicht: filtern, was den Ingest nicht wert ist, und aggregieren, was ohnehin nur gezählt wird. Da die Aufbewahrung pro GiB-Tag abgerechnet wird, fehlt ein am Rand entferntes Gigabyte an jedem Tag, an dem es sonst gelegen hätte. LinkMesh schreibt diese Processors einmal und rollt sie auf eine Gruppe von Collectors aus; Ihre Telemetrie läuft nie über LinkMesh.
Dieser Rechner bildet die Ingest-Seite einer Dynatrace-Rechnung ab. Die Aufbewahrung multipliziert diesen Wert mit den Tagen, die Sie die Daten halten, und im nutzungsbasierten Modell kommen Abfragen obendrauf — betrachten Sie das Ergebnis daher als Untergrenze, nicht als Gesamtsumme. Jede Zahl ist eine Schätzung für die Planung; LinkMesh legt keine Dynatrace-Preise fest und vertritt sie nicht.
Geschätzte jährliche Wirkung
Nur Schätzungen für die Planung. Die tatsächlichen Einsparungen hängen von Ihren Daten, Ihrem Vertrag und davon ab, wie konsequent Sie filtern. LinkMesh legt keine Dynatrace-Preise fest und vertritt sie nicht.
01
Problem
Health-Checks, Readiness-Probes und Polling-Rauschen werden zum vollen Preis ingestiert und indexiert und danach fast nie abgefragt.
LinkMesh
Schreiben Sie Filterregeln, die sich lesen lassen — drop where service.name = "health-check" — und wenden Sie sie am Collector an, bevor irgendetwas Dynatrace erreicht. LinkMesh übersetzt die Regel in OTTL und verteilt sie auf die ganze Flotte.
Das Rauschen erreicht nie einen kostenpflichtigen Index. Dieselben Signale, ein Bruchteil des Volumens.
Anleitung: laute Logs verwerfen (Englisch) →
02
Problem
Debug-Ausgaben und Events mit hoher Kardinalität und hohem Volumen vervielfachen Ihre Ingestion, ohne dass der Nutzen im gleichen Mass steigt.
LinkMesh
Behalten Sie Debug-Daten lokal oder routen Sie sie in günstigen Speicher; samplen Sie sich wiederholende Events statistisch; entfernen Sie doppelte und ungenutzte Attribute, die jeden Datensatz aufblähen. Alles an der Quelle, als verwaltete Processors auf dem Collector.
Schicken Sie Dynatrace die Events, die eine Indexierung wert sind — nicht jeden Retry und jedes Feld.
Wie Processors Telemetrie umwandeln (Englisch) →
03
Problem
Wenn eine einzige Pipeline alles an Dynatrace schickt, zahlt wenig nützliche Telemetrie denselben Aufpreis wie Ihre sicherheitskritischen Logs.
LinkMesh
Definieren Sie Routen nach Label, Quelle oder Umgebung: sicherheitsrelevante Logs an Dynatrace, den Rest an Object Storage, ein günstigeres Backend oder ein OTLP-Ziel — vom selben Collector aus, mit einer eigenen Verarbeitungskette pro Route.
Dynatrace behält die Daten, die dort hingehören; alles andere zahlt keine Dynatrace-Preise mehr.
Wie Routen Telemetrie an Backends verteilen (Englisch) →
04
Problem
Kreditkartennummern, E-Mail-Adressen, Tokens und IDs rutschen in Logs und werden in Dynatrace indexiert, wo sie aufbewahrt werden und für Personen abfragbar sind, die sie nicht sehen sollten.
LinkMesh
Wenden Sie Maskierungs-Processors auf dem Host an, bevor Telemetrie Ihr Netzwerk verlässt. Integrierte Vorlagen für gängige Muster plus eigene OTTL-Regeln für Ihre Felder — damit sensible Werte nie den Index erreichen.
Sensible Daten sind vor dem Verlassen des Netzwerks entfernt — nicht etwas, das Sie später aus Dynatrace bereinigen müssen.
Anleitung: PII vor dem Export maskieren (Englisch) →05
Problem
Niemand verwirft in Produktion Daten auf gut Glück. Ohne zu sehen, was eine Regel entfernt, ist es die sichere Wahl, alles zu ingestieren — und weiter zu bezahlen.
LinkMesh
LinkMesh zeigt für jeden Processor eine Vorschau mit echten erfassten Datensätzen: auf der einen Seite die Eingabe, in der Mitte die Regel und das erzeugte OTTL, auf der anderen die Ausgabe. Sie sehen genau, was ein Filter behält und verwirft, bevor er einen einzigen Collector erreicht.
Mit Sicherheit kürzen, weil Sie gesehen haben, was die Regel tut, bevor sie lief.
Anleitung: Datensätze auf einer Route filtern (Englisch) →06
Problem
Ein Kostenprojekt sollte keine komplette Ablösung werden — und wer jeden Collector direkt an Dynatrace koppelt, macht aus jeder künftigen Änderung eine Neuschreibung der ganzen Flotte.
LinkMesh
LinkMesh sitzt vor Dynatrace als herstellerneutrale Erfassungs- und Verarbeitungsebene auf Basis standardmässiger OpenTelemetry Collectors und Grafana Alloy. Dynatrace bleibt Ihr Backend; LinkMesh steuert, was dort ankommt — und dieselbe Ebene kann an dem Tag, an dem Sie es wollen, auch anderswohin routen.
Die Rechnung jetzt senken, ohne sich später an ein einzelnes Backend zu binden.
Anleitung: an ein anderes Backend routen (Englisch) →Kosten für ein anderes Backend senken
Das Produkt
Von allein wird nichts davon günstiger: Das Volumen wächst weiter, bereits versendete Daten lassen sich nicht zurückholen, und jeder zusätzliche Agent ist einer mehr, den Sie später wieder entfernen.
Indem Telemetrie auf der Ebene der OpenTelemetry Collectors gefiltert, verworfen, gesampelt und geroutet wird — bevor die Daten Dynatrace erreichen. Dynatrace rechnet nach Volumen ab; wer wenig nützliche Daten an der Quelle entfernt, senkt direkt die Kosten für Ingestion, Aufbewahrung und Abfrage.
Nein. LinkMesh sitzt als Erfassungs- und Verarbeitungsebene vor Dynatrace. Dynatrace bleibt Ihr Backend; LinkMesh verwaltet die Collectors und steuert, welche Telemetrie dort ankommt. Dieselbe Ebene kann Telemetrie auf Wunsch auch an andere Backends routen.
Sie entscheiden, was verworfen wird. Jeder Filter wird mit echten Datensätzen geprüft — Eingabe, Regel und Ausgabe nebeneinander —, bevor er einen Collector erreicht, sodass Sie genau sehen, was behalten und was entfernt wird. Weniger nützliche Daten können Sie auch in günstigeren Speicher routen, statt sie zu verwerfen.
Nein. LinkMesh ist selbst gehostet und überträgt nur Konfiguration und Zustand. Das Filtern läuft in Ihren eigenen Collectors, und Ihre Telemetrie fliesst direkt von dort zu Dynatrace oder Ihren anderen Backends — sie läuft nie über LinkMesh.
Ohne Ihre Rate Card — und, untypisch für dieses Feld, ohne Ihre Abfragegewohnheiten — nicht beantwortbar. Bekannt ist die Form: Ein am Rand entferntes Gigabyte fehlt einmal im Ingest, an jedem Tag der geplanten Aufbewahrung und in jeder künftigen Abfrage, die es durchsucht hätte. Wegen dieser Multiplikation lohnt es sich, die Aufbewahrungsdauer gemeinsam mit dem Volumen zu prüfen. Die Ingest-Untergrenze schätzen Sie mit dem Rechner auf dieser Seite. LinkMesh legt keine Dynatrace-Preise fest und vertritt sie nicht.
Pro verwaltetem Collector, nie nach Datenvolumen. Die ersten 25 Collectors sind nach einer kostenlosen Registrierung ohne Kreditkarte im OpenSight Customer Portal gratis (5 ohne Registrierung); darüber gilt ein fester Preis von USD 12.50 · CHF 12.00 · EUR 12.50 pro Collector und Monat, jährlich abgerechnet, und ab 200 Collectors steigt die Rechnung nicht weiter. Ihre Einsparungen wachsen mit dem Volumen; Ihre LinkMesh-Kosten nicht.
Selbst gehostet, herstellerneutral, pro Collector abgerechnet. Nehmen Sie LinkMesh in Betrieb, prüfen Sie Ihre Filter mit echten Datensätzen und reduzieren Sie die Ingestion mit Sicherheit. Die ersten 25 Collectors sind nach einer kostenlosen Registrierung ohne Kreditkarte im OpenSight Customer Portal gratis (5 ohne Registrierung).
Control Plane auf jeder Linux-VM installieren — Ubuntu / Debian
curl -fsSL https://artifacts.saas.opensight.ch/binaries/linkmesh-server/latest/linkmesh-server_latest_amd64.deb -o linkmesh-server.deb && sudo apt install -y ./linkmesh-server.debRHEL / Rocky / AlmaLinux, Collector-Enrollment und die vollständige Anleitung: Installationsanleitung →
Diese gepflegten Anleitungen führen von der Produktbewertung zur konkreten Konfiguration. Dokumentation auf Englisch.
Versionen und Grenzen vorab prüfen