opentelemetry-collector-contrib: [k8sclusterreceiver] Some metric units don't follow Otel semantic conventions

Describe the bug Some metrics don’t follow Otel semantic conventions

Steps to reproduce Nothing to reproduce. The problem lies in the specification of the receiver itself.

What did you expect to see? Metrics that count objects should use units with brackets {} and not 1

Example:

  • k8s.container.restarts ==> Unit: "{restarts}"
  • k8s.cronjob.active_jobs ==> Unit: "{jobs}"
  • k8s.job.active_pods ==> Unit: "{pods}"
  • etc.

What did you see instead? Many metrics specify unit 1 to report a count of objects:

  • k8s.container.restarts
  • k8s.cronjob.active_jobs
  • k8s.job.active_pods
  • etc.

Unit 1 must be used only for fractions and ratios.

What version did you use? Main branch

What config did you use? N/A

Environment N/A

Additional context N/A

About this issue

  • Original URL
  • State: closed
  • Created 2 years ago
  • Comments: 24 (24 by maintainers)

Commits related to this issue

Most upvoted comments

I’ve looked thru some mores docs and Otel Metrics API says that Instrument units are optional:

An optional unit of measure … A unit of measure.

Users can provide a unit, but it is up to their discretion. Therefore, this API needs to be structured to accept a unit, but > MUST NOT obligate a user to provide one.

So I think we should allow empty units.

I opened PR which allows to set units: "", but still fails validation if “unit” field is not set -> https://github.com/open-telemetry/opentelemetry-collector-contrib/pull/27090

I believe this can be closed.

Updated to use {resource} as unit. Will be released in next version.

I believe we are done with this task, all metrics seems to follow Otel semantic conventions.

@bertysentry feel free to validate and let me know if something isn’t right.

@povilasv You could use either {resources} or empty unit.

I’ve looked thru some mores docs and Otel Metrics API says that Instrument units are optional:

An optional unit of measure … A unit of measure. Users can provide a unit, but it is up to their discretion. Therefore, this API needs to be structured to accept a unit, but > MUST NOT obligate a user to provide one.

So I think we should allow empty units.

Thanks for looking this up. Taking a quick look at opentelemetry-go it seems like the unit is left empty if not specified by the user so I agree we can leave this empty.

Considering these 2 points, I strongly recommend we don’t specify a unit where it’s not required by UCUM. If we put 1 for state sets and enumerations, we’ll break the Otel-to-Prometheus conversion, which is a large part of our ecosystem.

This makes sense to me.

Potentially we can tweek the mdatagen to explicitly require unit field while allowing it to be ""