Additional information on OpenTelemetry spans
- Dominant language
- Go
- Stars
- 1.1k
- Forks
- 378
- Avg merge
- 2d 6h
- Merged PRs (30d)
- 74
Description
**Is your feature request related to a problem? Please describe.**
I was very excited to try out the OpenTelemetry backend to get some insight into our CI performance. It is so close but I am missing a few pieces of information on spans that would really make the difference for me. I saw a comment on an older issue that seemed to imply adding more information to spans was not desired (https://github.com/buildkite/agent/issues/869#issuecomment-447684086) but it would make a big differenct.
We dynamically generate all but one of our build steps. That results in unstable job uuids for each job. The labels of the job are stable over time, though. That makes the OpenTelemetry span data collected almost useless to track job performance over time (which is my ultimate goal). It would be much nicer to see the value of `BUILDKITE_LABEL` instead of `BUILDKITE_JOB_ID`.
**Describe the solution you'd like**
In fact it might be nice to do one of the following:
* Expose all reasonable environment variables to the spans as contextual information, much like you might see in a debugger's local variables inspection.
* Make the contextual information available configurable by the user. I like the way `sudo --preserve-env` works as an example.
**Describe alternatives you've considered**
I suppose you could make graphql calls for each span to get more detail about the label but that seems wasteful. Perhaps there are other options I have not considered.
Contributor guide
Research direction
Start by locating the agent's OpenTelemetry span instrumentation and reviewing the linked discussion in issue 869. Compare the existing BUILDKITE_JOB_ID context with the requested BUILDKITE_LABEL value, then determine whether configurable contextual environment variables are in scope. Done should include an agreed attribute or configuration design and tests covering the resulting span data.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- observability
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100