Add experimental api for adding operation attributes #14590
Conversation
| * Add an {@link AttributesExtractor} to the given {@link InstrumenterBuilder} that provides | ||
| * attributes that are passed to the {@link OperationListener}s. This can be used to add | ||
| * attributes to the metrics without adding them to the span. To add attributes to the span use | ||
| * {@link InstrumenterBuilder#addAttributesExtractor(AttributesExtractor)}. |
There was a problem hiding this comment.
I think we can wait with this. Firstly need to decide whether we want to add something like this at all.
|
It's been an intentional decision in semantic conventions that the attributes on metrics should be a subset of the attributes on spans (where they both measure the same thing). Have you seen other cases where this would be helpful? |
I wasn't aware that metrics attributes should be a subset of span attributes. Since the intention is that instrumentation api can be used outside of this project we also need to consider whether this could be useful for others. |
| * attributes to the metrics without adding them to the span. To add attributes to the span use | ||
| * {@link InstrumenterBuilder#addAttributesExtractor(AttributesExtractor)}. | ||
| */ | ||
| public static <REQUEST, RESPONSE> void addOperationAttributesExtractor( |
There was a problem hiding this comment.
based on the general name (operation), I think I'd expect these attributes to be stamped onto both spans and metrics?
maybe OperationListenerMetrics? to be clear that these are only passed to OperationListeners
(if I read it right)
laurit
force-pushed
the
operation-attibutes
branch
from
6639c2c to
1651163
Compare
3 participants
#14342 requires adding attributes to metrics that are not added to the span. While this could be overcome by modifying the spec to add these attributes to the span too in my opinion it really is a shortcoming of our current api.