Oh, simple answer. The tools you use to inspect those traces just blow up with noise. Like a trace that shows 600+ of file reads that all take less than half a millisecond.
This is all noise when you are trying to debug more common issues than your FS being too slow.
+ also storage cost. Most vendors charge by Mb stored or span recorded.
That is why I mentioned post-filtering the recording as the alternative. Grab the full recording then filter to just the relevant results before inspection.
For that matter, why are a few hundred spans a problem? Are the visualizers that poor? I usually use function tracing where hundreds of millions to billions of spans per second are the norm and there is no difficulty managing or understanding those.
In most cases these traces are shipped over the wire to a vendor. Only that will cost $$. Then, not all vendors have tail sampling as a "free" feature. So, in many cases it's better to not record at all.
That sounds positively dystopian. Is it really that hard to dump to private/non-vendor storage for local analysis using your own tools?
I do not do cloud or web development, so this is just totally alien. I generate multi-gigabyte logs with billions of events for just seconds of execution and get to slice them however I want when doing performance analysis. The inability to even process your own logs seems crazy.
You can absolutely dump the traces somewhere and analyze them yourself. The problem is that this falls apart with scale. You are maybe serving thousands of requests per second. Your service has a ton of instances. Capturing all trace data for all requests from all services is just difficult. Where do you store all of it? How do you quickly find what you need? It gets very annoying very fast. When you pay a vendor, you pay them to deal with this.
This is all noise when you are trying to debug more common issues than your FS being too slow.
+ also storage cost. Most vendors charge by Mb stored or span recorded.