-
Notifications
You must be signed in to change notification settings - Fork 176
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
Should metric namespaces be restricted from also being metric names? #50
Comments
If "Option C" is chosen in #51 (comment), I think that this reason not introducing the restriction will no longer be relevant:
because |
The TC voted and here is the result #51 (comment). |
@reyang this issue is about namespaces for instrument names as opposed to namespaces for attribute names, did the TC vote also on this? thx |
To me this looks like a mix-up. Re-opening. |
On second look, maybe the decision has been made(?), based on #50 (comment)
|
Or, more precisely, #51 (comment) effectively decides the underlying question that led to this issue (naming of |
just a note, I did find something in our current conventions which is both a metric and a metric name: |
I have a scenario in #330 that shows an example of how not introducing this restriction would lead to a clearer naming outcome. #330 is set to change the process schema by namespacing all attributes pursuant to the decision in #51 (this is partially just to get the change out of the way, but also to work around limitations of the semconv yaml tooling with regards to duplicates in the yaml spec). There were 2 attribute naming scenarios that would become problematic if the decision in this issue is to introduce the restriction (i.e. metric names cannot be namespaces). For example, two metrics that posed a problem were In the PR, I've named these attributes
If this restriction was put in place, making the
|
I believe this issue is only about metric namespaces and metric names (and not related to attribute namespaces or attribute names). |
@braydonk For those, the The problem I see in #330 that I think is related to this issue is: There's a metric My point being: if this issue gets solved with: metric names cannot be also namespaces, then #330 is invalid. |
I was unaware there was a distinction. So the decision in this issue wouldn't affect
That is what I'm trying to challenge. I think |
this has come up in open-telemetry/opentelemetry-java-instrumentation#11901 which is proposing metrics:
|
Summarizing reasons for not introducing this restriction:
.count
suffixes for more concise metric names, e.g.system.processes
instead ofsystem.processes.count
Summarizing reasons for introducing this restriction:
I will update these summaries based on any comments made below.
The text was updated successfully, but these errors were encountered: