The bill has doubled and the traffic has not. This is the most common unpleasant surprise in infrastructure monitoring, and it is almost never caused by growth.
Find out what actually grew
Before changing anything, establish which stream is responsible. Almost every product can break its own consumption down by metric name, by log source, by service or by host, and the answer is nearly always concentrated: one name, one service, one recently changed component.
The date matters as much as the name. If the curve turned at a deployment rather than at a traffic increase, the cause is a code change, and the article on cardinality describes the usual one. If it turned at a retention change, somebody extended a window. If it climbs smoothly with no event, it is genuine growth and the conversation is different.
The four levers, in order of how much they cost you
Drop what nobody queries. Every mature setup carries metrics and log streams that no dashboard displays and no alert references. They are pure cost. Finding them takes an afternoon of cross-referencing queries against ingested names, and it is the only lever with no downside at all.
Reduce dimensions rather than volume. Removing one high-cardinality label frequently removes more cost than dropping a whole service, because of the multiplication described in the cardinality article.
Shorten retention where the questions are recent. Incident material is consulted within days. Trend material needs a long span at low resolution. Separate policies cost configuration and save substantially, and the article on retention explains what each purpose actually requires.
Sample, carefully. The article on sampling sets out the trap: keep errors preferentially without carrying the weight, and every rate computed afterwards is wrong.
Growth that is real still deserves a decision
Sometimes the curve is honest: more traffic, more services, more people asking questions. That is not a problem to be fixed, and treating it as one produces a setup that saves money by being unable to answer anything.
The question then is whether the marginal telemetry is worth its marginal price, and it is answerable per stream rather than in aggregate. A log source consulted during every incident earns its cost. A metric emitted by an application nobody has deployed to since March does not, and the two are usually on the same invoice line.
What makes this tractable is knowing which is which, which is why the first section of this article is about attribution rather than about reduction.
Reduce at the collection point
- Best forAny setup where the application cannot be changed quickly
- PricingFree; the cost is configuration in whatever forwards your data
- StandoutWorks without touching application code, and takes effect immediately
- Watch out forIt is a filter added between you and the truth, so anything dropped is invisible later
Fix the labels in the application
- Best forCardinality problems with a clear owner
- PricingFree, and a code change plus a deployment
- StandoutRemoves the cost at source rather than paying to discard it
- Watch out forRequires the team that owns the code to prioritise it, which is the actual obstacle
Separate retention per stream
- Best forSetups where one policy governs everything
- PricingUsually a setting; sometimes a tier boundary in commercial products
- StandoutLarge savings for a small amount of thought about what is asked when
- Watch out forGetting it wrong deletes the thing somebody needed, which is discovered months later
Move bulk to cheap storage and keep a queryable slice
- Best forHigh-volume logs that are kept for obligation rather than for use
- PricingCheaper per unit and slower to retrieve
- StandoutKeeps the obligation satisfied without paying to index material nobody searches
- Watch out forIt becomes a two-system arrangement, and nobody remembers which one is authoritative
Renegotiate, or change supplier
- Best forContracts approaching renewal with usage well above the original estimate
- PricingNothing to try; considerable if you move
- StandoutThe largest single reduction available, and the only one that requires no engineering
- Watch out forMigration means re-instrumenting unless the telemetry is vendor-neutral, which is the argument for that from the start
Set the alarm on your own consumption
The reason this becomes a crisis rather than a task is that nobody learns about it until an invoice arrives, by which point a month has been paid for. An alert on ingest volume or series count, owned by the team that generates it, converts a quarterly shock into a Tuesday.
It is also the one alert in this article that everybody agrees should exist and almost nobody has.
What we cannot verify
Pricing structures differ by vendor and change; we reproduce none, and no product is named or ranked here. The concentration pattern described above is consistent practitioner experience rather than a measured distribution. Your own breakdown by stream is available today from the product you are already paying, and it is the only account that matters.
The short version
- Establish which stream grew, and whether the curve turned at a deployment or at traffic.
- Dropping what nobody queries is the only lever with no downside.
- Removing one dimension often saves more than removing a whole service.
- Retention wants separate policies because the purposes ask for different spans.
- Sampling without carrying the weight makes every later rate wrong.
- Alert on your own consumption, so an invoice is never the first notification.