Add k8s metrics for jobs and cronjobs

[ChrsMark]

Part of #1032

Changes

This PR adds metrics for k8s jobs and cronjobs that are already in use by the Opentelemetry Collector (k8scluster receiver).

• k8s.job.active_pods (collector)
• k8s.job.failed_pods (collector)
• k8s.job.successful_pods (collector)
• k8s.job.desired_successful_pods (collector)
• k8s.job.max_parallel_pods (collector)
• k8s.cronjob.active_jobs (collector)

Merge requirement checklist

• CONTRIBUTING.md guidelines followed.
• Change log entry added, according to the guidelines in When to add a changelog entry.
  • If your PR does not need a change log, start the PR title with [chore]
• schema-next.yaml updated with changes to existing conventions.

[dashpole]

It seems like these should all be UpDownCounters, rather than gauges.

[ChrsMark]

Good catch @dashpole! My only concern is about the k8s.job.desired_successful_pods and
k8s.job.max_parallel_pods. Should those be also UpDownCounters since they are set by users and are mostly desired-state values?

[dashpole]

The main question is how they should be aggregated. UpDownCounters aggregate by summing, gauges aggregate by averaging. If I was aggregating k8s.job.desired_successful_pods k8s.job.max_parallel_pods` across a cluster, I would probably want to see the sum of all desired_successful_pods or the sum of max_parallel_pods, rather than the average of either. So IMO those should both be UpDownCounters.

[jinja2]

This is a very interesting point. These metrics being additive makes sense to me. But the data point type from the receiver is gauge. I think most instrumentation libraries export UpDownCounter as non-monotonic sums but I am not sure if this a standard. Would this cause some confusion for users? Should there be a way to clarify export and instrument type in cases as this?

[dashpole]

I think most instrumentation libraries export UpDownCounter as non-monotonic sums but I am not sure if this a standard.

Yes, that is correct. It is a bit odd to specify an instrument type for metrics that are not recorded using an instrument, but that seems mostly editorial here.

IMO we should update the data point type in the receiver to be a non-monotonic sum.

[trask]

I think most instrumentation libraries export UpDownCounter as non-monotonic sums but I am not sure if this a standard.

I think this is the closest we have:

https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/metrics/sdk_exporters/otlp.md#additional-environment-variable-configuration

which specifies exporting UpDownCounter with Cumulative aggregation in all cases

[ChrsMark]

@dashpole @jinja2 @open-telemetry/semconv-k8s-approvers types are now switched to updowncounters. Anything else missing here?

[lmolkova]

Do @open-telemetry/semconv-system-approvers want to take a look?