I took a look at how tracing is implemented in

Otel-collector Github receiver: trace_event_handling.go
- When the workflow events are received a resource is created for the given workflow with as attributes the appropriate vcs and cicd attributes.
- The root span (for the workflow) and all child spans (for the steps in the workflow) are associated with that resource.
- Child spans only have attributes if they are specific to that unique span (eg. for cicd.pipeline.task.name).
- This is very efficient.
Jenkins opentelemetry-plugin: MonitoringRunListener.java
- Spans are sent with attributes set.
- Attributes like the pipeline URL are only set on the root span, while other spans have only specific attributes (eg. for the step name)
  - This can actually be an issue on some storage backends (eg. to calculate average stage durations per pipeline) and I contributed a feature to work around this issue by setting some attributes on all child spans of a build: Added step withSpanAttributes to set the attributes also on child spans, added setSpanAttributes for setting the attribute only on the target jenkinsci/opentelemetry-plugin#827
argo-workflows (WIP): workflow/tracing/workflow.go
- Separate Tracers are used with distinguishing service name for different workflows (different resources)
- Individual spans have attributes set with some attributes: eg. node, workflow, phase

Going forward we should base the semantic conventions for tracing on the Github receiver and we should define both a resource for a Workflow and traces for workflow and task under a workflow.

Add CICD conventions for spans #1713

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions