Replies: 2 comments 5 replies
-
Instrumenter API's main goals I think are
I think only 1) and 2) are in scope for this issue In particular they seem to be about 2) Do the DB semantic conventions not capture information about the response that they should? DB is very much request-response heavy in nature so intuitively it does seem off that we always ignore the response. Also do the HTTP common conventions just have too much? If many methods of the common conventions can't be implemented, it seems the conventions may not reflect reality. We should propose removing conventions - alternatively perhaps we can limit instrumentation API to only "required" attributes but I guess those aren't really well defined in practice. I think instrumentation API should target "normal" attributes - required as currently specd is probably too small, but full spec might be too big. But then we have nothing to target. |
Beta Was this translation helpful? Give feedback.
-
One more piece of feedback: it is unfortunate that subclassing of Instrumenters is practically impossible. I think we pass around too much |
Beta Was this translation helpful? Give feedback.
-
I would like to start a discussion and collect feedback and ideas for Instrumenter API improvements before declaring it stable.
So far I have some specific feedback.
Void
as response type seems artificial.HttpCommonAttributesExtractor
have around 5 empty methods. Seems untidy.Beta Was this translation helpful? Give feedback.
All reactions