This isn't mentioned in https://github.com/open-telemetry/semantic-conventions/blob/main/docs/general/naming.md#naming-rules-for-counters-and-updowncounters, but the convention has been followed pretty closely to only use .count suffix on UpDownCounter metrics (and not to use it on Counter metrics).
I'm not thinking of reasons right now, maybe related to the ambiguity of Counters being commonly exported as both delta and cumulative, and maybe related to the Prometheus exporter converting these to _count_total(?)
There are just a few metrics that violate this convention:
otel.sdk.span.ended.count
otel.sdk.processor.span.processed.count
otel.sdk.exporter.span.exported.count
dotnet.thread_pool.work_item.count - this one is stable, can't rename it
One option for the otel.sdk.* metric names could be:
otel.sdk.ended_spans
otel.sdk.processor.processed_spans
otel.sdk.exporter.exported_spans
cc @JonasKunz
This isn't mentioned in https://github.com/open-telemetry/semantic-conventions/blob/main/docs/general/naming.md#naming-rules-for-counters-and-updowncounters, but the convention has been followed pretty closely to only use
.countsuffix on UpDownCounter metrics (and not to use it on Counter metrics).I'm not thinking of reasons right now, maybe related to the ambiguity of Counters being commonly exported as both delta and cumulative, and maybe related to the Prometheus exporter converting these to
_count_total(?)There are just a few metrics that violate this convention:
otel.sdk.span.ended.countotel.sdk.processor.span.processed.countotel.sdk.exporter.span.exported.countdotnet.thread_pool.work_item.count- this one is stable, can't rename itOne option for the
otel.sdk.*metric names could be:otel.sdk.ended_spansotel.sdk.processor.processed_spansotel.sdk.exporter.exported_spanscc @JonasKunz