Custom Metric Attributes #22
Conversation
If applied, plugins can use the LabelExtractor to get the Labeler from the context and use the returned Labeler to add custom metric labels to the server and client metrics generated.
1. removed unused variable 2. refactoring test method to reduce complexity
| semconv.HTTPRequestMethodKey.String(r.Method), | ||
| semconv.HTTPResponseStatusCode(t.responseStatus), | ||
| append( | ||
| otelhttp.CustomMetricAttributes(r), |
There was a problem hiding this comment.
One of the problem of having the custom attributes in the contexts is that you cannot select to what layer you want them to be applied.
So, if you set one key=val at the http.server.* global layer, that attribute will be set in each other layer, in to the backend. Or the other way around, since you report the metric once the request is alredy served, if you set an attribute with a plugin at the http.client.* backend layer, it would be set up to the http.sever.* .
Also, you could set the var in a plugin that is executed only in one of the backends, when some other request is already made, so one backend would have the attribute, and another one not.
I am not sure, if we want a way to "extend the labels", we should go with this approach.
If applied, plugins can use the LabelExtractor to get the Labeler from the context and use the returned Labeler to add custom metric labels to the server and client metrics generated.
With this in place, a server plugin could easily add custom metrics to the standard ones to customize the metrics. We could for example write a simple plugin that decodes a JWT Bearer Token and adds a claim value to the server and client metrics.
The auth validator could then with some small adjustments allow for this to be configured since it already reads the JWT and the claims.