Reduce Dynatrace ingest cost
Dynatrace meters logs three times over — once to ingest and process, again for every GiB-day you retain, and in the usage-based model again for every GiB a query scans. Decide what is worth all three at the OpenTelemetry Collector, before the data reaches your tenant. Self-hosted, and priced per collector.
25 Collectors free after a no-card registration · 5 without one How the free tier works
Dynatrace’s value is real. What surprises people is that volume is not charged once: it is charged on the way in, every day it is kept, and in the usage-based model again each time somebody asks a question of it.
Log — Ingest & Process is billed once, when the data enters your tenant. Log — Retain is billed per GiB-day, so the same gigabyte is charged again for every day it is held. A gigabyte kept for ninety days is not one charge; it is ninety.
Readiness probes, polling chatter, retry storms, and duplicated fields make up a large share of most log pipelines — ingested, retained, and rarely read.
A backend’s own agent ships what it’s pointed at. Meaningful reduction means transforming telemetry upstream at the collector, not at Dynatrace.
Sensitive fields slip into logs and get indexed in Dynatrace, where they’re retained and queryable long after they should have been dropped.
Security-relevant logs and low-value debug output go to the same expensive index, because there’s no layer deciding what belongs where.
Nobody drops data in production without a way to see exactly what a filter removes first. So the volume — and the bill — keeps growing.
Most reduction projects that end with an unchanged invoice picked the wrong line. Dynatrace meters several things separately, and only some of them respond to sending less.
Charged once, on the volume entering your tenant. This is the meter most people picture when they think about telemetry cost, and on Dynatrace it is only the first of three.
What moves it: Filter and aggregate at the collector. What never reaches the tenant is never ingested, and is also absent from the two meters below.
Charged per GiB-day: the same gigabyte is billed again for every day you hold it. A gigabyte kept for ninety days is ninety charges, not one.
What moves it: Two independent levers here, and most teams only pull the first. Reduce the volume, and separately review the retention period — keeping less for longer can cost more than keeping more for a short window.
In the usage-based model, Retain and Query are billed separately and, in Dynatrace’s own words, you pay for each query — charged on the volume a query scans. A broad dashboard over a wide window has a price attached, which is not true of most backends.
What moves it: Data never ingested is never scanned, so edge-side filtering reduces this too. The alternative is the Retain with Included Queries model, where a query allowance is bundled with retention — worth checking which of the two your contract is on before optimising anything.
Full-Stack and Infrastructure Monitoring are billed on the hosts you monitor, not on what those hosts send.
What moves it: Nothing you do to telemetry moves this line. If most of your Dynatrace spend sits here, filtering is the wrong project.
Mechanics as Dynatrace documents them, not as we would like them to be — check them against your own contract, which may differ. Dynatrace Log Analytics licensing documentation Telemetry reaches Dynatrace through the collector's otlphttp exporter, so every change below happens before that exporter runs.
The reduction happens in the collector’s processor chain, before anything reaches your tenant: filter what is not worth ingesting, and aggregate what only needs to be counted. Because retention is billed per GiB-day, a gigabyte removed at the edge is removed from every day it would otherwise have been held. LinkMesh authors those processors once and rolls them out to a group of collectors; your telemetry never passes through LinkMesh.
This calculator models the ingest side of a Dynatrace bill. Retention multiplies that figure by the days you keep the data, and in the usage-based model querying is charged on top, so treat the result as the floor rather than the total. Every figure is an estimate for planning — LinkMesh does not set or represent Dynatrace pricing.
Estimated annual impact
Estimates only, for planning. Actual savings depend on your data, contract, and how aggressively you filter. LinkMesh does not set or represent Dynatrace pricing.
01
Problem
Health checks, readiness probes, and polling noise are ingested and indexed at full price, then almost never queried.
LinkMesh
Write filter rules that read plainly — drop where service.name = "health-check" — and apply them at the Collector, before anything reaches Dynatrace. LinkMesh renders the rule to OTTL and pushes it across the fleet.
The noise never reaches a billed index. Same signals, a fraction of the volume.
How-to: drop noisy logs →
02
Problem
Debug output and high-cardinality, high-volume events multiply your ingest without a matching increase in value.
LinkMesh
Keep debug locally or route it to cheap storage; statistically sample repetitive events; trim duplicated and unused attributes that inflate every record. All at the source, as managed processors on the collector.
Send Dynatrace the events worth indexing — not every retry and every field.
How processors transform telemetry →
03
Problem
When one pipeline sends everything to Dynatrace, low-value telemetry pays the same premium as your security-critical logs.
LinkMesh
Define routes by label, source, or environment: send security-relevant logs to Dynatrace and fan the rest to object storage, a cheaper backend, or an OTLP destination — from the same collector, with a different processing chain per route.
Dynatrace keeps the data that belongs there; everything else stops paying Dynatrace prices.
How routes fan telemetry to backends →
04
Problem
Credit cards, emails, tokens, and IDs slip into logs and get indexed in Dynatrace, where they’re retained and queryable by people who shouldn’t see them.
LinkMesh
Apply masking processors on the host, before telemetry leaves your network. Built-in templates for common patterns plus custom OTTL rules for your fields — so sensitive values never reach the index.
Sensitive data is gone before egress — not something to scrub from Dynatrace later.
How-to: mask PII before egress →05
Problem
Nobody drops data in production on faith. Without a way to see what a rule removes, the safe choice is to ingest everything — and keep paying.
LinkMesh
LinkMesh previews each processor against real captured records: input on one side, the rule and generated OTTL in the middle, the output on the other. You see exactly what a filter keeps and drops before it reaches a single collector.
Cut with confidence, because you saw what the rule does before it ran.
How-to: filter records on a route →06
Problem
A cost project shouldn’t become a rip-and-replace migration — and coupling every collector directly to Dynatrace makes any future change a fleet-wide rewrite.
LinkMesh
LinkMesh sits in front of Dynatrace as a vendor-neutral collection and processing layer built on standard OpenTelemetry Collectors and Grafana Alloy. Dynatrace stays your backend; LinkMesh manages what reaches it — and the same layer can route elsewhere the day you want to.
Lower the bill now without locking yourself to any one backend later.
How-to: route to another backend →Reduce cost for another backend
The product
Left alone, none of this gets cheaper: the volume grows on its own, the data that already left cannot be recalled, and each agent added is one more to remove later.
By filtering, dropping, sampling, and routing telemetry at the OpenTelemetry Collector layer — before the data reaches Dynatrace. Dynatrace bills by volume, so removing low-value data at the source directly reduces what you pay to ingest, retain, and query.
No. LinkMesh sits in front of Dynatrace as a collection and processing layer. Dynatrace stays your backend; LinkMesh manages the collectors and controls what telemetry reaches it. The same layer can also route telemetry to other backends if you choose.
You decide what is dropped. Every filter is previewed against real records — input, rule, and output side by side — before it reaches a collector, so you see exactly what is kept and removed. You can route lower-value data to cheaper storage instead of dropping it.
No. LinkMesh is self-hosted and carries only configuration and health. Filtering runs in your own collectors, and your telemetry flows straight from them to Dynatrace or your other backends — it never transits LinkMesh.
Not answerable without seeing your rate card and, unusually for this category, your query habits. What is knowable is the shape: cutting a gigabyte at the edge removes it from ingest once, from retention for every day you would have kept it, and from every future query that would have scanned it. That compounding is why retention length is worth reviewing alongside volume. Model the ingest floor with the calculator on this page. LinkMesh does not set or represent Dynatrace pricing.
By managed collector, never by data volume. The first 25 collectors are free after a no-card registration in the OpenSight Customer Portal (5 without one); beyond that it is a flat USD 12.50 · CHF 12.00 · EUR 12.50 per collector per month, billed annually, and the bill stops growing at 200 collectors. Your savings scale with volume; your LinkMesh cost does not.
Self-hosted, vendor-neutral, priced per collector. Stand LinkMesh up, preview your filters against real records, and cut ingest with confidence. The first 25 Collectors are free after a no-card registration in the OpenSight Customer Portal (5 without one).
Install the control plane on any Linux VM — 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, and the full walkthrough: Install guide →
Use these maintained guides to move from product evaluation to a working configuration.
Check versions and limitations first