Proposal: Service/Component Version Labels #235
Assignees
Milestone
Comments
|
Should this go into an RFC? |
|
Probably. I'll write one up and reference it in here. |
|
See open-telemetry/oteps#38 for the RFC. |
|
@austinlparker can you please move the OTEP's description to the spec, please. |
tigrannajaryan
pushed a commit
to tigrannajaryan/opentelemetry-specification
that referenced
this issue
Nov 22, 2019
Some exporting protocols have built-in fields for this information (e.g. OpenCensus), some other protocols don't (e.g. Jaeger). Our approach so far has been that this sort of information is best to be standardized via semantic conventions and conveyed as generic attributes. This change adds the appropriate semantic conventions. A companion change in https://github.com/open-telemetry/opentelemetry-proto/ will be made to remove no longer needed messages that describe the Library. Resolves open-telemetry#235
SergeyKanzhelev
pushed a commit
that referenced
this issue
Nov 25, 2019
) Some exporting protocols have built-in fields for this information (e.g. OpenCensus), some other protocols don't (e.g. Jaeger). Our approach so far has been that this sort of information is best to be standardized via semantic conventions and conveyed as generic attributes. This change adds the appropriate semantic conventions. A companion change in https://github.com/open-telemetry/opentelemetry-proto/ will be made to remove no longer needed messages that describe the Library. Resolves #235
SergeyKanzhelev
pushed a commit
to SergeyKanzhelev/opentelemetry-specification
that referenced
this issue
Feb 18, 2020
…pen-telemetry#363) Some exporting protocols have built-in fields for this information (e.g. OpenCensus), some other protocols don't (e.g. Jaeger). Our approach so far has been that this sort of information is best to be standardized via semantic conventions and conveyed as generic attributes. This change adds the appropriate semantic conventions. A companion change in https://github.com/open-telemetry/opentelemetry-proto/ will be made to remove no longer needed messages that describe the Library. Resolves open-telemetry#235
TuckTuckFloof
pushed a commit
to TuckTuckFloof/opentelemetry-specification
that referenced
this issue
Oct 15, 2020
carlosalberto
pushed a commit
to carlosalberto/opentelemetry-specification
that referenced
this issue
Oct 21, 2024
This is intended to capture the proposal developed by [the Sampling SIG](https://docs.google.com/document/d/1gASMhmxNt9qCa8czEMheGlUW2xpORiYoD7dBD7aNtbQ/edit#heading=h.mngoctm0c84w). --------- Co-authored-by: Joshua MacDonald <jmacd@users.noreply.github.com> Co-authored-by: Spencer Wilson <5624115+spencerwilson@users.noreply.github.com> Co-authored-by: Otmar Ertl <otmar.ertl@gmail.com> Co-authored-by: Armin Ruech <7052238+arminru@users.noreply.github.com>
carlosalberto
pushed a commit
to carlosalberto/opentelemetry-specification
that referenced
this issue
Oct 23, 2024
This is intended to capture the proposal developed by [the Sampling SIG](https://docs.google.com/document/d/1gASMhmxNt9qCa8czEMheGlUW2xpORiYoD7dBD7aNtbQ/edit#heading=h.mngoctm0c84w). --------- Co-authored-by: Joshua MacDonald <jmacd@users.noreply.github.com> Co-authored-by: Spencer Wilson <5624115+spencerwilson@users.noreply.github.com> Co-authored-by: Otmar Ertl <otmar.ertl@gmail.com> Co-authored-by: Armin Ruech <7052238+arminru@users.noreply.github.com>
carlosalberto
pushed a commit
to carlosalberto/opentelemetry-specification
that referenced
this issue
Oct 31, 2024
This is intended to capture the proposal developed by [the Sampling SIG](https://docs.google.com/document/d/1gASMhmxNt9qCa8czEMheGlUW2xpORiYoD7dBD7aNtbQ/edit#heading=h.mngoctm0c84w). --------- Co-authored-by: Joshua MacDonald <jmacd@users.noreply.github.com> Co-authored-by: Spencer Wilson <5624115+spencerwilson@users.noreply.github.com> Co-authored-by: Otmar Ertl <otmar.ertl@gmail.com> Co-authored-by: Armin Ruech <7052238+arminru@users.noreply.github.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Currently in the OpenTelemetry design, there's no convention for specifying the version of a service or component. This is a pretty basic piece of information that is very useful for consumers of telemetry data (to understand, specifically, what version of a given component/service produced a given iota of telemetry data) that we should support as a first-class citizen.
Would it make the most sense to add these to the Standard Resources once that's updated, and treat them as semantic versions (thus,
service.semver,component.semver, etc.) and allow for other resources to attach the.semverfield? Alternately, we could create aVersionsemantic resource that had different types of versions that would be useful for different resource types (for example, client OS versions, hardware revisions, etc.)The text was updated successfully, but these errors were encountered: