-
Notifications
You must be signed in to change notification settings - Fork 888
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Do we still need component
in semantic conventions?
#271
Comments
When going over the component attributes, it seems that the use of the component attribute is different for each convention:
So maybe it was put there just for consistency? BTW, in OTEP 16 (named tracers), you specify the name of the instrumenting library, not the instrumented library, so that's not really the use case. |
I think OTEP should use the name of the instrumented library not the name of the instrumentation. |
@bogdandrutu I think you are wrong (or I am misunderstanding your sentence):
-- https:/open-telemetry/oteps/blob/master/text/0016-named-tracers.md#explanation |
Much better to explicitly specify the component than try to guess based on other attributes. grpc is a good example, where it reuses the http attributes. I would go a far as to say traces ought to always have component, as a quick way of seeing the instrumented technology. |
This needs discussion in the next Spec SIG meeting. |
Discussed during the meeting to remove it. |
Is there a link to the recording or notes from the meeting? I am curious what factors were weighed in the decision. |
For example, in specification/data-semantic-conventions.md for HTTP
It's not clear what the value of this required attribute is given that the HTTP-nature of the span can be inferred from the other required attributes like
http.method
, so it only bloats the data size. Also, the OTEP 16 provides another mechanism for identifying the type of library/component.The text was updated successfully, but these errors were encountered: