Skip to content
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

Add CICD metrics #1681

Open
wants to merge 20 commits into
base: main
Choose a base branch
from

Conversation

christophe-kamphaus-jemmic
Copy link
Contributor

Fixes #1600

Changes

This PR adds metrics for CICD systems and related attributes.

Merge requirement checklist

| <a id="cicd-pipeline-run-id" href="#cicd-pipeline-run-id">`cicd.pipeline.run.id`</a> | string | The unique identifier of a pipeline run within a CI/CD system. | `120912` | ![Experimental](https://img.shields.io/badge/-experimental-blue) |
| <a id="cicd-pipeline-task-name" href="#cicd-pipeline-task-name">`cicd.pipeline.task.name`</a> | string | The human readable name of a task within a pipeline. Task here most closely aligns with a [computing process](https://wikipedia.org/wiki/Pipeline_(computing)) in a pipeline. Other terms for tasks include commands, steps, and procedures. | `Run GoLang Linter`; `Go Build`; `go-test`; `deploy_binary` | ![Experimental](https://img.shields.io/badge/-experimental-blue) |
| <a id="cicd-pipeline-task-run-id" href="#cicd-pipeline-task-run-id">`cicd.pipeline.task.run.id`</a> | string | The unique identifier of a task run within a pipeline. | `12097` | ![Experimental](https://img.shields.io/badge/-experimental-blue) |
| <a id="cicd-pipeline-task-run-url-full" href="#cicd-pipeline-task-run-url-full">`cicd.pipeline.task.run.url.full`</a> | string | The [URL](https://wikipedia.org/wiki/URL) of the pipeline run providing the complete address in order to locate and identify the pipeline run. | `https://github.com/open-telemetry/semantic-conventions/actions/runs/9753949763/job/26920038674?pr=1075` | ![Experimental](https://img.shields.io/badge/-experimental-blue) |
| <a id="cicd-pipeline-task-type" href="#cicd-pipeline-task-type">`cicd.pipeline.task.type`</a> | string | The type of the task within a pipeline. | `build`; `test`; `deploy` | ![Experimental](https://img.shields.io/badge/-experimental-blue) |
| <a id="cicd-worker-state" href="#cicd-worker-state">`cicd.worker.state`</a> | string | The state of a CICD worker / agent. | `idle`; `busy` | ![Experimental](https://img.shields.io/badge/-experimental-blue) |
| <a id="cicd-worker-type" href="#cicd-worker-type">`cicd.worker.type`</a> | string | The type of worker / agent used by the CICD system. | `vm`; `pod` | ![Experimental](https://img.shields.io/badge/-experimental-blue) |

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It defines how you provision the worker/agent, instead of type, could we use provider or provisioner?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The worker might not be provisioned by the CICD system. It could just be connected to it as a static worker.

Here we should cover both dynamic provisioned as well as statically connected workers.
As suggested in #1681 (comment) we should also leave the possibility open for CICD systems to to further subdivide workers.
I have rename this attribute to cicd.worker.class in 26d3064.

docs/attributes-registry/cicd.md Outdated Show resolved Hide resolved
docs/cicd/cicd-metrics.md Outdated Show resolved Hide resolved

---

`cicd.worker.type` has the following list of well-known values. If one of them applies, then the respective value MUST be used; otherwise, a custom value MAY be used.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@pablochacin
Copy link

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
Copy link
Contributor Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Development

Successfully merging this pull request may close these issues.

Add metrics for CICD job queues
4 participants