-
Notifications
You must be signed in to change notification settings - Fork 165
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
Proposal: don't pluralize metric namespaces #212
Comments
I think a year ago we decided to move this direction. See the updated pluralization rules in the spec: https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/metrics/semantic_conventions/README.md#use-count-instead-of-pluralization We should just clean up the specification of ambiguity of this topic. |
Can you please list all impacted metric names? Or maybe if it is easier just prepare a draft PR with all name changes. I think seeing all names would help better understand the impact. |
@tigrannajaryan I've closed the initial PR which expanded the scope to both metric namespaces and metric names, and opened a fresh PR that limits the scope to this issue only, which applies only to metric namespaces (and not metric names). this issue affects the following metric namespaces:
|
Renaming I'd also suggest bringing metrics currently emitted by Collector receivers but not defined in the semantic conventions. There must be plenty of them with pluralized namespaces. Maybe they can influence this decision. I can do that exercise if it makes sense |
@dmitryax yes, I think that would be great! |
I checked the collector receivers. Most of the exposed metrics don't have pluralized namespaces. But there are still a few of them with pluralized namespaces. I'll put all of them here with their description for the full context:
I believe most of them can be easily renamed to avoid pluralized namespaces. However, if we just remove the cc @djaglowski FYI |
Another scenario to consider: open-telemetry/opentelemetry-collector-contrib#24905 (comment). We'd like to add new metrics to the kubeletstatsreceiver that include in the name a section clarifying which conceptual "limit", either |
There are two reasons behind this proposal:
system.process.status
(vssystem.processes.status
)jvm.thread.state
(vsjvm.threads.state
)This would affect these metrics names:
system.processes.count
->system.process.count
system.processes.created
->system.process.created
db.client.connections.*
->db.client.connection.*
jvm.threads.count
->jvm.thread.count
jvm.classes.count
->jvm.class.count
It may also affect these metrics if we decide to add
.count
(or.usage
) to them:process.threads
->process.thread.count
process.open_file_descriptors
->process.open_file_descriptor.count
The text was updated successfully, but these errors were encountered: