trace high-radius tag usage #5125
|
We should avoid too many radius for metrics, likes we should not include customerId in the metrics, should we also avoid it in trace tags also? |
Replies: 1 comment
|
For metrics, high-cardinality data (like an arbitrary ID) is not recommended to be collected as attributes on a metric count towards its identity. For example The same consideration with respect to identity doesn't apply to traces as the identity for a span is its unique ID, so the number of attributes that a trace has doesn't affect its identity. Traces are often billed based on raw data storage costs, so what is logged isn't usually a factor - just how much. Separate to costs, whether any particular data is safe to be stored in your telemetry back-end is up to your individual requirements and policies with consideration for things such as PII/PCI/HPAA etc. |
For metrics, high-cardinality data (like an arbitrary ID) is not recommended to be collected as attributes on a metric count towards its identity. For example
foo.barwithuser=1is considered distinct fromfoo.barwithuser=2, so ifuseris an arbitrary 32-bit integer it can cause a cardinality explosion and could lead to a large number of active series in a metrics back-end. This in turn could have a significant impact on your telemetry costs. A finite set (e.g. HTTP methods, GET/POST etc.) wouldn't typically be of concern.The same consideration with respect to identity doesn't apply to traces as the identity for a span is its unique ID, so the number of attributes that a trace has doe…