You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, any label added via addLabels() is treated as a "global" label. Global labels are part of the aggregation key of (service) transaction metrics, meaning that the user risks creating a high amount of metric groups that will result in APM Server pushing data into an overflow bucket. This can happen if user-specific labels or metrics are added via the addLabels() API. For 8.7.1 we are removing global labels from the aggregation key for the RUM agent (elastic/apm-server#10532). Beyond that, we need a better fix that gives the user the option to aggregate on service-specific labels. I'm not sure what exactly, but perhaps we can add a new addGlobalLabels() API, not sure if that is the best option though.
Discussed with @felixbarny and will work on this in the future when we plan in a bigger scoped breaking change in the RUM agent. The APM Server work around will continue to be the mitigation for the time being.
Currently, any label added via addLabels() is treated as a "global" label. Global labels are part of the aggregation key of (service) transaction metrics, meaning that the user risks creating a high amount of metric groups that will result in APM Server pushing data into an overflow bucket. This can happen if user-specific labels or metrics are added via the addLabels() API. For 8.7.1 we are removing global labels from the aggregation key for the RUM agent (elastic/apm-server#10532). Beyond that, we need a better fix that gives the user the option to aggregate on service-specific labels. I'm not sure what exactly, but perhaps we can add a new
addGlobalLabels()
API, not sure if that is the best option though.--
Additional context: https://elastic.slack.com/archives/C5L79P420/p1679555445014589
The text was updated successfully, but these errors were encountered: