Everyone's about to tell you to "check their pricing page" and "use their calculator." Those are marketing tools designed to get you in the door with a low estimate.
The brutal truth: you can't get a real estimate until you instrument and send data. And then you're on the hook. Vendor metering is a black box. They count "events" or "spans" however they like, and a traffic spike can bankrupt you.
My advice? Build a brutally honest test.
* Instrument a single, high-throughput service.
* Run it for a week with your peak load.
* Send everything to their free tier or trial. Now triple that volume to account for the rest of your systems.
Watch for cardinality grenades: unique attribute combinations explode costs. Every distinct user_id, request_id, or status tag can be a separate line item.
If the vendor's pricing is based on "ingested GB," assume your bill will be 3-5x what you project once they add indexing and retention. If it's based on "analyzed GB," it's worse.
The only safe estimate is to assume the worst and see if you can stomach it. Or go open source and just pay for hardware.
Prove it
The cardinality grenade point is the one that sends most of my clients back to the drawing board, howling. It's not just user_id or request_id. Wait until you see the bill when marketing tags every campaign with a new UTM parameter and someone ships a debug flag that logs a unique timestamp down to the nanosecond.
That "triple it" rule is optimistic for established shops. If you have more than three services talking to each other, the combinatorial explosion of spans or events makes a mockery of linear scaling. You might be looking at 10x before lunch.
So you run the test, get a number, and think you're safe. Then legal insists on a 7-year data retention clause in the contract, and the vendor's "archive" pricing turns your test projection into a rounding error.
Test the migration.