Observability cost optimisation
An observability bill grows with data volume, not with what anyone looks at: in most setups a large share of the logs and metrics being ingested is never queried. The work is to audit what is generated, cross it with what is actually used, and put an OpenTelemetry pipeline in front that filters, samples and routes before anything is sent. The deliverable is a report with the estimated saving against your own bill and an implementation plan, and it can stop there if the numbers do not justify the change.
Last updated:
Where the telemetry money goes
Who it is for
For teams whose observability bill is already a visible budget line, or who have started cutting retention and turning off traces to contain it. Also for anyone considering a vendor change who wants to know how much of the spend is the vendor and how much is how things are instrumented.
What it solves
You pay by volume ingested and decide by habit. Debug logs from a service nobody has debugged in eighteen months cost the same as the ones that matter; high-cardinality metric labels — request, user or container identifiers — multiply series nobody ever aggregates; and trace sampling, where it exists, is at the default. When the cut comes in a hurry, retention gets halved, which is exactly what you need on the day of the hard investigation.
What the goal is
To pay for the telemetry that gets looked at and keep what is needed to investigate an incident. What we aim for is lower volume sent without losing diagnostic capability, and the report says how much lower in your specific case. We do not publish saving percentages: they depend on how each system is instrumented, and an average figure would mean nothing about your bill.
The three parts of the work
Audit
What is generated, what is ingested, what is queried and what each piece costs. With the vendor bill next to the inventory of metrics, logs and traces.
OpenTelemetry pipeline
A collector in front that filters, aggregates, drops labels, samples traces and routes each kind of data where it belongs. The instrumentation code does not change.
An open stack, if it pays
Grafana, Prometheus, Loki and Tempo, run by us or by your team. It is one option in the report, not the obligatory conclusion.
What we hand over
The report
A telemetry inventory per service, with its associated cost and its real usage: which dashboards, alerts and queries touch each piece of data. For every line, what we propose doing — drop, aggregate, sample, reduce retention, move to cheaper storage — with the estimated saving against your bill and what you give up in exchange. That last column is the important one: a cut that leaves the team blind during the next incident is not a saving.
The plan
Implementation order by saving against risk, with the collector configuration written and reviewable, and a phase where old and new run side by side to confirm nothing is lost before cutting over.
When it is NOT worth it
If the bill is still small against the cost of changing it, if you are halfway through a platform migration, or if the real problem is missing instrumentation rather than excess, we say so in the report and that is the end of it. It happens, and it is cheaper to know than to build a pipeline nobody needed.
How we work
Access and collection
Read access to the observability platform and to the bill, and an inventory of what each service generates.
Cost against usage
Which data feeds real dashboards, alerts and queries, and which data appears nowhere at all.
Report and decision
Estimated saving per line, what you give up and the implementation order. You decide with this, and you can stop here.
Implementation and overlap
Collector configured, a period with old and new running together, and cutover once it is confirmed nothing is missing.
Frequently asked questions
Do we have to change observability vendor?
Not necessarily. A good share of the saving comes from not sending data nobody queries, and that works with the vendor you already have. Migrating to an open stack is an option that appears in the report with its own operating cost, not the default conclusion.
Do the applications have to be re-instrumented?
Generally no. The OpenTelemetry collector sits in front and works on what is already emitted. If instrumentation is missing from a service that matters, it appears in the report as a separate recommendation.
Do you guarantee a percentage saving?
No, and be wary of anyone who does without having seen your setup. The report gives an estimate calculated on your own bill and your own volume, with the working shown so you can check it.
Are we going to lose data we later need?
That is the real risk of this work, which is why every proposal in the report states what you would no longer be able to investigate. What gets touched first is what feeds no dashboard and no alert, and the cutover happens after a period of running both side by side.
Do we have to change cloud provider to start?
No. Reliability work happens on what you already have, whether that is AWS, Azure, Google Cloud, a European provider or your own hardware. Migration is a separate service and only makes sense if there is a reason for it.
How long before we notice anything?
The noise goes first: an alert review usually shows results within the first few weeks, because a good share of what fires is not actionable. SLOs take longer, because they need measuring, and they are worth nothing until there are a few weeks of data behind them.
Do you sign a non-disclosure agreement?
Yes, if you want one, and nothing we see is used as an example anywhere without written permission. Access is requested at the minimum needed and documented.
Ask for the observability audit
Tell us which platform you use and the order of magnitude of the bill. We reply within 24 working hours with the scope and the timescale.
or write to us at info@esdis.es