-
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
Please guide how to properly extend attributes for not-yet-documented protocols #1601
Comments
Good point, that should probably be formatted as an (open) enum. It would be intended to be used for such a case.
Most "enum"-like attributes explicitly allow using "a custom value", and rpc.system is IMHO supposed to be one of them. |
For adding new attributes, I would use a custom prefix. E.g. for your example I would use |
Thanks!
Can you please point where it is in the specification? I've seen only explicitly closed "enums" like Next thing i was going to ask: is a PR welcome. I am going to contribute JSON RPC then :) |
Discussed during the issue triage, the namespace approach (use company/product/project/etc. names) seems to be the safe way to go. |
I'll think how to put this into docs. However,currently i'm waiting (indefinetly) for my company to allow signing CLA for another PR... |
For example |
What are you trying to achieve?
I am implementing tracing library for Json Rpc 2.0. It would be convenient to have some additional attributes as GRPC does:
rpc.grpc.status_code
. However, it is not clear to me how to extend attributes properly. I can think of two approaches:rpc.system = jsonrpc
. Question: is this attribute intended to be used for any sort of RPC? Since i can't find closed list of allowed values...rpc.jsonrpc.something_protocol_related = "blah"
because GRPC does the samecom.my_organization.jsonrpc.something_protocol_related
since Json Rpc is not standartized here (yet) to avoid collisions in futureI followed docs about semantic conventions and naming and i see the pattern how attributes extend for specific protocols. However i'm not sure if extensibility by nesting is intended for developers outside of opentelemetry project. Question here is: should we treat attributes mentioned in these docs as read-only allowed things or can we extend them?
The text was updated successfully, but these errors were encountered: