-
Notifications
You must be signed in to change notification settings - Fork 183
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
base: main
Are you sure you want to change the base?
Add CICD metrics #1681
Conversation
docs/attributes-registry/cicd.md
Outdated
| <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) | |
There was a problem hiding this comment.
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
?
There was a problem hiding this comment.
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
|
||
--- | ||
|
||
`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. |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
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 |
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 For CICD span conventions we should definitely keep this in mind. For example https://github.com/jenkinsci/opentelemetry-plugin emits span with an attribute 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. |
Fixes #1600
Changes
This PR adds metrics for CICD systems and related attributes.
Merge requirement checklist
[chore]