Ingested volume
A price per gigabyte accepted, usually measured daily. This is the charge source-side filtering moves most directly: a record that never leaves the host is never ingested.
Reduce telemetry costs
Telemetry bills grow with volume, and the volume grows on its own. Start with the backend you pay for, then use LinkMesh to manage the collector configurations that filter, aggregate and route telemetry before it is exported — centrally, across the whole fleet.
Where the bill actually comes from
Most reduction projects that end in an unchanged invoice failed here rather than in the pipeline. Observability contracts usually meter several things at once, and only some of them respond to sending less.
Retention and storage
What it costs to keep the data once indexed, often tiered by age. Reducing what arrives reduces what accumulates, but the saving appears gradually as old data ages out rather than on the next invoice.
Hosts, agents or units
A price per monitored host, container or licensed unit. Volume reduction does not move this at all. If most of your spend sits here, filtering is the wrong project.
Per-product and per-feature charges
Separate lines for traces, synthetics, session replay, security analytics or premium queries. Each is metered on its own terms, and a change to log volume may leave every one of them untouched.
Find your charge on this list before you change a pipeline. If your spend is concentrated in per-host fees, filtering will not help you and no tool can make it help you.
Choose your backend
Splunk
Review which records reach Splunk, test filters before ingestion, and estimate the impact using your own contract assumptions.
View the Splunk cost-reduction guide →Datadog
Evaluate filtering and routing before export to Datadog. Check which billable products and signals your changes actually affect.
View the Datadog cost-reduction guide →Elastic
Evaluate which data needs to reach Elasticsearch and which can be reduced or routed elsewhere. Measure storage and processing alongside ingest volume.
View the Elastic cost-reduction guide →Dynatrace
Review the telemetry sent to Dynatrace and test source-side filtering. Preserve signals required by the features and investigations your team uses.
View the Dynatrace cost-reduction guide →Four ways to cut volume before it is billed
In the order to try them: least destructive first. Each one costs you something, and a guide that does not say what would be selling you a reduction rather than a decision.
Drop
Remove records nobody reads — debug output left on after an incident, health-check noise, duplicated fields. The largest and safest reduction is usually here, and it is the one most often skipped because nobody is sure what is safe to remove.
What it costs you: Irreversible. Once a record is dropped at the edge, no query can recover it.
Sample
Keep a representative fraction of high-volume, low-variance telemetry — successful requests, healthy polls — while keeping every error and every slow trace in full.
What it costs you: Rates and counts stay usable; individual-event forensics does not. Sample where you reason about aggregates, never where you reason about single events.
Aggregate
Convert many similar records into counts, sums or histograms at the collector, so the backend stores one series instead of a million lines that were only ever going to be counted.
What it costs you: You keep the shape of the data and lose its detail. The dimensions you aggregate away cannot be grouped by later.
Route
Send each signal to the destination that should hold it, rather than everything to the most expensive one. Audit logs to cheap object storage, operational telemetry to the tool your team actually opens.
What it costs you: Not a saving by itself — it moves the cost. Compare the whole pipeline, including egress and the storage you route into.
All four run in the OpenTelemetry Collector itself, on your hosts, before anything is exported. LinkMesh is where you author them once and roll them out to a group of collectors, with the change reviewable as a diff and revertible if it turns out to be wrong.
What you should not drop
Most advice in this category assumes a reader free to delete anything. If you are in a regulated environment, or on call, you are not. The reductions below are the ones that come back to hurt, and they are worth naming before you start.
- Anything an alert evaluates. A rule that silently stops firing is worse than the bill it saved.
- Records you are required to retain, and for the period you are required to retain them. A retention obligation is not a volume problem.
- Security and audit trails, including authentication events and configuration changes.
- Errors, exceptions and slow traces. They are usually a small share of volume and nearly all of the value.
- The fields your dashboards group by. Dropping a label is cheap until a panel goes blank.
Telemetry that must be kept but does not need to sit in an expensive index is a routing question, not a dropping one — see multi-destination routing. Telemetry that must be kept but must not carry personal data is a masking question — see filtering and redaction.
Measure the billable change
Lower telemetry volume does not automatically lower your invoice. Identify the charge you want to reduce, capture a representative baseline, and confirm that the proposed change affects that charge. A fixed commitment, host-based fee or unrelated product charge may stay the same.
Test a small group first. Compare useful signals, dropped records, alert inputs and troubleshooting coverage before rolling out a rule. Include the cost of running Collectors and LinkMesh in your evaluation.
More than one destination?
Routing lets you choose which data reaches each backend. Sending fewer records to one service can create storage or operational costs elsewhere, so compare the whole pipeline.
Common questions
Does reducing telemetry volume reduce my bill?
Only if volume is what you are billed for. Ingest-volume and retention charges respond to it; per-host, per-unit and per-product charges do not. Identify the line you want to move before changing anything, then confirm the change affects that line.
Where should telemetry be filtered — at the source or in the backend?
At the source, if the goal is cost. Filtering inside the backend happens after the data has been accepted, which means it has usually already been counted. A record dropped on the host is never ingested and never billed.
What can I safely drop?
Debug output left enabled after an incident, health-check and heartbeat noise, duplicated fields, and verbose logs from systems nobody queries. Keep anything an alert evaluates, anything under a retention obligation, security and audit trails, and your errors.
Does LinkMesh charge by telemetry volume?
No. LinkMesh is priced per managed collector, so the volume flowing through your pipelines never changes what LinkMesh costs. That is also why this page can be honest about when filtering will not help you.
How do I know a filter will not break something?
Test it against real telemetry before it is live. LinkMesh previews the effect of each processor on captured data, so you can see exactly which records a rule removes, and roll a change out to one group before the fleet.
If nothing changes
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.
Once it is running
- A per-collector bill that a volume spike does not move.
- Sensitive fields masked on the host, before anything leaves the network.
- Every config change a diff you can review and roll back.
- Backends you can swap, because nothing proprietary sits in the path.
Test with your own telemetry
25 Collectors free after a no-card registration · 5 without one — How the free tier works. LinkMesh licensing is based on managed collectors, not telemetry volume.
Test this in your own environment
Use these maintained guides to move from product evaluation to a working configuration.
Check versions and limitations first