Add CICD metrics

[christophe-kamphaus-jemmic]

Fixes #1600

Changes

This PR adds metrics for CICD systems and related attributes.

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. → NA

[pablochacin]

In many complex CI/CDs the workers are categorized by other attributes, such as the platform they run (ubuntu, windows) the tooling they have installed (java, go) or other attributes.

I lean towards leaving this attribute open (without pre-defined values). Also consider class as an alternative name to reflect its intention to group the workers into categories.

[christophe-kamphaus-jemmic]

I have rename this attribute to cicd.worker.class in 26d3064.

[pablochacin]

Here we are introducing the concept of worker, but it seem disconnected from other elements of the domain.

For instance, pipelines are executed in workers. Shouldn't the metrics related to pipelines be somehow reference the workers? I'm not quite sure how this could be done. Just adding the worker type to the pipeline seems insufficient.

Maybe we should consider a worker id attribute. It seems useful to, for example, identify all errors in a pipeline comes from a faulty worker.

[christophe-kamphaus-jemmic]

For instance, pipelines are executed in workers. Shouldn't the metrics related to pipelines be somehow reference the workers? I'm not quite sure how this could be done. Just adding the worker type to the pipeline seems insufficient.

Maybe we should consider a worker id attribute. It seems useful to, for example, identify all errors in a pipeline comes from a faulty worker.

I did consider this, however we could easily run into cardinality issues if we add such an attribute to metrics (eg. if dynamic workers are used). If we add a cicd.worker.id attribute to metrics it will have to be opt-in and with a warning about the cardinatity.

For CICD span conventions we should definitely keep this in mind. For example https://github.com/jenkinsci/opentelemetry-plugin emits span with an attribute jenkins.computer.name.

Also at some point I would like to be able to link host or container metrics to a pipeline run despite any cardinality issues as an opt-in feature: #1184 For this it makes sense to use a cicd.worker.id attribute as well.

I think we should discuss this further on a separate Github issue.