This message was deleted.

Hi @User

maximum number of spans that are supported within a trace

interesting...never came across limitations in number of spans that can be connected via a single traceId. Can you explain a bit about this? Or point me to an issue somewhere?

And also around the amount of custom data (size of a span)?

size of a span can vary depending on the amount of custom tags or events you add. I remember it being around 50bytes to 100 bytes when compressed to disk. I wonder what might be the issues that you are facing that let you to this? Will it be possible to share the rate at which you ingest spans and the disk usage you see in your system?

maximum number of spans that are supported within a trace

So, from a future perspective and considering addition of custom spans, the scale we are targeting is roughly 1000 spans/trace. If it goes beyond that, then we are fine with truncation. So wanted to understand if the current architecture would be able to support that or not.

And also around the amount of custom data (size of a span)?

This isn't a more pressing problem right now. Developing better instrumentation might push us to add much more custom tags to respective spans for enrichment, so that would help remediate issues quicker.

@User I don't think our architecture is limited by number of spans in a trace.

Even if we consider sampling at otel-collector, it would be at a trace level right? That would still have the scenario where a trace has considerably large number of spans.

right..sampling does not solve for large number of spans in a trace