- last edited on by
MaciejNeumann
Especially with DPS, it's important due to ATM, to have good efficiency in trace data being grabbed.
Looking at the "Full-Stack trace volume and Adaptive Traffic Management" dashboard, one interesting tile is related to the average size of full-stack spans. I see several values across different tenants:
In the notes, Dynatrace says that "While spans can vary widely, the average size is typically 1.5-2 KiB.". I'm getting values below that.
But I'm curious how this can be optimized further? I imagine the more Request Attributes, for example, the bigger the size.
But instead of wondering, I would like some real facts. I believe I can get there with traces DQL. Anybody have an idea?
Digging into the new Distributed Tracing app shows some of the data I'm looking for. It has several variables that we can filter & see. Particularly interesting seem to be "Ingest size" and "Retain size":
This is from the playground, but I have dived into other clients, and here are some of my initial findings:
- Exceptions are one of the factors that more contributes to big span/trace data. I have seen some with 35KB, and this was just the beginning.
- Most of the times, Code call stack is also a big contributor in data ingest size.
- Big SQL queries, along with the Code call stack, also are pretty heavy
But, if you want more detail, you can open a trace in Notebooks, and get an idea of the data:
Lot's more to discover in the near future, so I can optimize ATM 😁
Looking at it in the playground it seems like on average failed requests will generate larger spans due to the additional information captured. Interestingly, you can also see on average OTEL traces are smaller suggesting the OneAgent is capturing more by default. With OTEL you could absolutely attach as much information as you like making some fat spans if you really wanted.
Also, with the below, the largest spans (max column) came from not failed requests, with both OneAgent and OTEL captured successful spans beating out the max sized failed spans.
Again, this was from the playground environment so your actual results could easily change environment to environment.
With the above you could also make any field a dimension to see how different types of spans change in size due to data captured.
Featured Posts
