Contribute additional semantic conventions to OpenTracing
With OpenTracing, span tags and loggings keys are completely free-form. Rather than try to set limitations, they have used conventions to try to standardize on names for common tags. OpenTracing has a few already defined here: https://github.com/opentracing/specification/blob/master/semantic_conventions.md
For example: db.instance
and db.statement
, so you know the host and query that was used.
These conventions are extremely helpful to us:
- Some of these conventions could be utilized to help us correlate data between Jaeger, Prometheus, and structured logs. For example a
host
field across all three, could be helpful in troubleshooting a problematic node. A commonsession_id
could help us map a users logs to their traces. - There are also some conventions that could relate to other areas of GitLab, like the
environment
in use or the particular line of code a span is representing. - We don't plan to write our own tracers, which means we cannot directly control this.
Because of their importance, we should contribute additional semantic conventions to do two things:
- Increase adoption of these tags being used
- Establish a convention so that everyone in the tracing community can benefit, and better interoperate
Suggested Additional Semantic Conventions
Tag Name | Type | Notes and examples |
---|---|---|
Environment | string | The name of the environment the span is originating from. For example, production or staging . Could also be used to differentiate between blue/green deploys. |
Version | string | The software version that is generating this span. This could be used to detect canaries versus GA versions. |
Source File / Line # | array | Trace back to where the span is being generated in the source code. filename.rb:232, filename2.rb:214
|
Commit SHA / Tag | string | If available, specify the version or SHA of the built code in order to find the proper line. |
Session ID | string | The ID of a particular session |
Edited by Joshua Lambert