Skip to content
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

Merge OTEPs into the Specification #4288

Merged
merged 114 commits into from
Nov 8, 2024

Conversation

carlosalberto
Copy link
Contributor

Very latest attempt to merge the OTEPs repo into the Specification (previous attempt I clowned and did a squash-merge, which would erase the history we want to retain).

  • OTEPs will live under the oteps directory, next to specification one.
  • History has been kept.
  • Updated @codeboten email from his previous defunct value (preventing CLA check).

Additionally, additional lint fixes in order to merge this:

  • Removed dead links, e.g. links to now removed Lightstep documentation.
  • Updated links that point to the Specification (our current lint prefers local, rather than absolute addresses).
  • Updated links for components that have been moved around, e.g. semantic conventions and the protocol.

Follow-up items listed in #4284

iredelmeier and others added 30 commits July 30, 2019 20:43
* RFC: Remove SpanData

* formatting

* respond to comments, add related issues

* finishing touches

* rename file

* respond to comments

* edit withOption wording

* Update 0004-remove-spandata.md

Co-Authored-By: Yang Song <[email protected]>

* fix typo/github links

* Adds language for including span ID, removes it from open questions

* respond to comments

* Rename 0004-remove-spandata.md to text/0002-remove-spandata.md

* Change finish to end

* Clarify where the isOutOfBand option passed.
* Four metrics RFCs to eliminate raw statistics

* Create 4 RFC drafts on metrics

* Update 0001-metric-pre-defined-labels.md

Co-Authored-By: Isobel Redelmeier <[email protected]>

* Update 0001-metric-pre-defined-labels.md

Co-Authored-By: Isobel Redelmeier <[email protected]>

* Refinements

* Set status to proposed

* Assign numbers 3-4-5-6

* Renumber refs

* Update status styling

* Fix misspellings

* Combine the first three into one
* Document global initializion

* Global initializer requirements

* Minor revision

* Set status

* Rename 0010-global-init.md to text/0005-global-init.md

* OTr->OTel
* Propose sampling API changes

* Add details about SamplingHint, Sampler interface and default samplers.

* Add details about start span operation.

* Update spelling text/0006-sampling.md

Co-Authored-By: Yang Song <[email protected]>

* Update spelling text/0006-sampling.md

Co-Authored-By: Yang Song <[email protected]>

* Add span name to the Sampler interface. Clarify how the sampling flags are exposed.

* Use ascii for personas

* Add spankind to the sampler input.

* Remove delayed span creation proposal from this RFC

* Remove unspecified type from sampler hint.

* Update text/0006-sampling.md

Co-Authored-By: Tristan Sloughter <[email protected]>

* Add clarification that Sampler is always called.
…pen-telemetry/oteps#41)

* Propose Datadog's auto-instr as a starting point

* Address PR comments

* Review responses
…ation), RFC 0004 (configurable aggregation) deleted (open-telemetry/oteps#29)

* Updates to 0003 following work session 8/21/2019

* Update date

* Feedback applied

* Feedback applied

* Remove handle specification, will create another RFC

* More typing

* Add metrics handles RFC

* Rename 0000

* Remove 0004

* Add an open question from python PR87

* Add an open question about RecordBatch

* Clarify the open questions

* Name NonNegative and NonDescending options

* Clarify the Measurement unit for RecordBatch

* Add issues addressed

* Linkify

* Linkify

* Format

* Address option names and default settings

* Answer questions

* Spelling

* Use 0007

* Refer to 0008

* Take suggestion
…oteps#39)

* Metric observer spec

* Observers cannot call use Set. Suggest a constructor name.

* Typo fix

* Number 0007

* Use 0008
…n-telemetry/oteps#26)

* Propose: Remove support to report out-of-band telemetry from the API

* Clarify what the change means

* Update text/0007-no-out-of-band-reporting.md

Co-Authored-By: Yang Song <[email protected]>

* Update text/0007-no-out-of-band-reporting.md

Co-Authored-By: Yang Song <[email protected]>
* Rename Cumulative to Counter

* Reword that

* More explanation and caveats

* More explanation and caveats
* First draft: "named tracers"

* Implement feedback.

* Move named tracers proposal into text folder

* Apply suggestions from code review

Co-Authored-By: Armin Ruech <[email protected]>

* Apply suggestions from code review

Co-Authored-By: Armin Ruech <[email protected]>

* Add examples section.

* Update 0000-named-tracers.md

* Implement feedback from code review

* Remove the implementation details about enabling / disabling ... of
sensors and reduced the proposal the actual core of associating names
with tracers.:q

* Update text/0000-named-tracers.md

Co-Authored-By: Christian Neumüller <[email protected]>

* Update text/0000-named-tracers.md

Co-Authored-By: Christian Neumüller <[email protected]>

* Reworked this RFC based on feedback on GitHub.

* Implement latest review suggestions

* Removed formatting

* Re-introduce plain string factory and move Resource-based approach to alternatives

* Use ` to format the names in the examples.

* Fix typo and broken link

* Extended the OTEP to included Metrics as well.

* Update text/0000-named-tracers.md

Co-Authored-By: Christian Neumüller <[email protected]>

* Update text/0000-named-tracers.md

Co-Authored-By: Christian Neumüller <[email protected]>

* Implement latest feedback.

* Rename 0000-named-tracers.md to 0016-named-tracers.md
Since this OTEP  has been thoroughly discussed before entering the "proposed" stage, it should be ready for approval already.
* Clarify maintenance of auto-instr repos

* Make the implicit explicit per PR comment
* add resource version rfc

* fix typo

* update due to feedback

* Update text/0000-version-resource.md

Co-Authored-By: Yuri Shkuro <[email protected]>

* update number

* remove old version

* Rename 0038-version-resource.md to 0038-version-semantic-convention.md

* Rename 0038-version-semantic-convention.md to 0038-version-semantic-attribute.md
* Add OTLP Draft RFC

OpenTelemetry Protocol (OTLP) specification describes the encoding, transport and delivery mechanism of telemetry data between telemetry sources, intermediate nodes such as collectors and telemetry backends.

* PR fixes

* Make Unary gRPC the only recommended mode

Experiments have shown that Streaming implementation
results in significantly more complex code. The performance
benefits of Streaming mode were only visible in very
small batches and are not applicable to real life scenarios
when under high load we aim to have large batches.

In addition, one of the potential benefits that we could
get with Streaming - the ability to optimize and avoid
repetition of Resource does not seem to have much real
life usage.

As a result Streaming mode was removed from the RFC and
Unary mode is the only mode that is now part of the spec.

* Address review comments

* Change status to approved

* Address review comments
* Add OTLP Trace Data Format specification

This is a continuation of OTLP RFC proposal open-telemetry/oteps#35

This change defines the data format used by Span and Resource messages.

The data format is a result of research of prior art (primarily OpenCensus and Jaeger),
as well as experimentation and benchmarking done as part of OTLP RFC proposal.

Go benchmark source code is available at https://github.com/tigrannajaryan/exp-otelproto
(use `make benchmark-encoding` target). Benchmarking shows that depending on the payload
composition this data format is about 4x-5x faster in encoding and 2x-3x faster in
decoding equivalent data compared to OpenCensus data format (all benchmarks in Go).

Notable differences from OpenCensus:

- Attribute key/value pairs are represented as a list rather than as a map.
  This results in significant performance gains and at the same time changes
  the semantic of attributes because now it is possible to have multiple attributes
  with the same key. This is also in-line with Jaeger's tags representation.

- Removed unnecessary wrappers such as google.protobuf.Timestamp which resulted in
  significant performance improvements for certain payload compositions (e.g. lots of
  TimedEvents).

- Resource labels use the same data type as Span attributes which now allows
  to have labels with other data types (OpenCensus only allowed strings).

* Address review comments

* Add protobuf type qualifier to pre-formatted blocks

* Add a note about future goals for the protocol

* Address review comments

* Make sure all field comments start with field name

* Change status to approved

* Clarify start and end time expectations.

* Address Sergey's comments

* Remove string length requirement

* Add StatusCode enum
…en-telemetry/oteps#49)

* Draft LabelSet spec

* Typos

* Add notes on performance expectations

* Typo

* Updates to use Monotonic/NonMonotonic, and NonNegtive/Signed

* Revert

* PR number 49

* Major revision to match the already-merged specification on LabelSet

* Update text/0049-metric-label-set.md

Co-Authored-By: dyladan <[email protected]>

* Update text/0049-metric-label-set.md

Co-Authored-By: dyladan <[email protected]>

* Update text/0049-metric-label-set.md

Co-Authored-By: dyladan <[email protected]>

* Accept suggested phrasing

* Revert mod changes eh?

* Update text/0049-metric-label-set.md

Co-Authored-By: Tyler Yahn <[email protected]>

* Update text/0049-metric-label-set.md

Co-Authored-By: Isobel Redelmeier <[email protected]>

* Remove explicit meter argument where not necessary
…/oteps#61)

* Propose approval / start round 3 of discussion

* Use Monotonic

* Updates to use Monotonic/NonMonotonic, and NonNegtive/Signed

* Update 0003

* Minor

* Revert

* Revert
AlexanderWert and others added 21 commits March 18, 2023 11:17
* Configuration proposal

This OTEP is the result of the Configuration working group. See
open-telemetry#2920 for
additional details.
This OTEP aims at defining consistent conventions about what spans to create for messaging scenarios, and at defining how those spans relate to each other. Instrumentors should be able to rely on a consistent set of conventions, as opposed to deducing conventions from a set of examples.

This was split from OTEP open-telemetry#192, which became too comprehensive.
…en-telemetry/oteps#232)

On 08 Mar 2023, the OpenTelemetry GC and TC held an OpenTelemetry Leadership summit, discussing various topics. One of the themes we discussed was establishing standard rules for describing the maturity of the OpenTelemetry project. This OTEP summarizes what was discussed there and is intended to have the wider community provide feedback.

This OTEP builds on what was previously communicated by the project, especially on the following page: https://opentelemetry.io/docs/reference/specification/versioning-and-stability.

The Collector’s [stability levels](https://github.com/open-telemetry/opentelemetry-collector#stability-levels) inspired the maturity levels.

Signed-off-by: Juraci Paixão Kröhling <[email protected]>
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 <[email protected]>
Co-authored-by: Spencer Wilson <[email protected]>
Co-authored-by: Otmar Ertl <[email protected]>
Co-authored-by: Armin Ruech <[email protected]>
…d Roadmap (open-telemetry/oteps#243)

[Easy to read version with images:
[https://github.com/lquerel/oteps/blob/app-telemetry-schema-vision-roadmap/text/0243-app-telemetry-schema-vision-roadmap.md](https://github.com/lquerel/oteps/blob/app-telemetry-schema-vision-roadmap/text/0243-app-telemetry-schema-vision-roadmap.md)]

Unlike the traditional data ecosystem (OLTP and OLAP), the world of
telemetry generally does not rely on the concept of a schema.
Instrumentation is deeply embedded in the code of applications and
libraries, making it difficult to discover all the possible telemetry
signals an application can emit. This gap prevents or limits the
development of CI/CD tools for checking, reporting, documenting, and
generating artifacts from telemetry signals specific to an application.
This document presents a long-term vision aimed at enabling the
OpenTelemetry project to address this issue and extend its impact to a
broader ecosystem. It proposes extending the initiatives of Telemetry
Schema and Semantic Conventions to include concepts of Application
Telemetry Schema and Resolved Telemetry Schema. A series of OTEPs and
Tools will be proposed in this overarching document to detail each
aspect of this vision.

Similar (but proprietary) initiative from Facebook: [Positional Paper:
Schema-First Application
Telemetry](https://research.facebook.com/publications/positional-paper-schema-first-application-telemetry/)

**EDIT 1: The OTel Weaver project (a PoC implementation of this OTEP and
some of the others mentioned in the roadmap) is now available
[here](https://github.com/f5/otel-weaver).**

**EDIT 2: The Slack channel
[#otel-weaver](https://cloud-native.slack.com/archives/C0697EXNTL3) is
dedicated to this OTEP and the associated OTel Weaver project.**

---------

Co-authored-by: Yuri Shkuro <[email protected]>
Co-authored-by: Reiley Yang <[email protected]>
Co-authored-by: Tigran Najaryan <[email protected]>
This is second version of the Profiling Data Model OTEP. After [we've
gotten feedback from the greater OTel
community](open-telemetry/oteps#237) we went
back to the drawing board and came up with a new version of the data
model. The main difference between the two versions is that the new
version is more similar to the original pprof format, which makes it
easier to understand and implement. It also has better performance
characteristics. We've also incorporated a lot of the feedback we've
gotten on the first PR into this OTEP.

Some minor details about the data model are still being discussed and
will be flushed out in the future OTEPs. We intend to finalize these
details after doing experiments with early versions of working client +
collector + backend implementations and getting feedback from the
community. The goal of this OTEP is to provide a solid foundation for
these experiments.

So far we've done a number of things to validate it:
* we've written a new profiles proto described in this OTEP
* we've documented decisions made along the way in a [decision
log](https://github.com/open-telemetry/opentelemetry-proto-profile/blob/main/opentelemetry/proto/profiles/v1/decision-log.md)
* we've done benchmarking to refine the data representation (see
Benchmarking section in a [collector
PR](petethepig/opentelemetry-collector#1))

* diff between original pprof and the new proto:
[link](open-telemetry/opentelemetry-proto-profile@2cf711b...petethepig:opentelemetry-proto:pprof-experiments#diff-9cb689ea05ecfd2edffc39869eca3282a3f2f45a8e1aa21624b452fa5362d1d2)

We're seeking feedback and hoping to get this approved. 

---

For (a lot) more details, see:
* [OTel Profiling SIG Meeting
Notes](https://docs.google.com/document/d/19UqPPPlGE83N37MhS93uRlxsP1_wGxQ33Qv6CDHaEp0/edit)

---------

Co-authored-by: Juraci Paixão Kröhling <[email protected]>
Co-authored-by: Christos Kalkanis <[email protected]>
Co-authored-by: Felix Geisendörfer <[email protected]>
Co-authored-by: Reiley Yang <[email protected]>
This is a proposal of a data model to represent entities. The purpose of
the data model is to have a common understanding of what an entity is,
what data needs to be recorded, transferred, stored and interpreted by
an entity observability system.

This data model sets the foundation for adding entities to
OpenTelemetry. The data model is largely borrowed from
[the initial
proposal](https://docs.google.com/document/d/1VUdBRInLEhO_0ABAoiLEssB1CQO_IcD5zDnaMEha42w/edit)
that was accepted for entities SIG formation.

This OTEP is step 1 in introducing the entities data model. Follow up
OTEPs will add further data model definitions, including the linking of
Resource information to entities.
For `abc;def` the `locations_start_index` should be `4` as `2` points to
`baz`.

Follow up of
open-telemetry/oteps#239 (comment)
This is a proposal to address Resource and Entity data model
interactions, including a path forward to address immediate friction and
issues in the current resource specification.


The proposal includes all links and context needed to justify it, but
duplicating a snapshot here:

## Motivation

This proposal attempts to focus on the following problems within
OpenTelemetry to unblock multiple working groups:

- Allowing mutating attributes to participate in Resource ([OTEP
208](open-telemetry/oteps#208)).
- Allow Resource to handle entities whose lifetimes don't match the
SDK's lifetime ([OTEP
208](open-telemetry/oteps#208)).
- Provide support for async resource lookup
([spec#952](open-telemetry#952)).
- Fix current Resource merge rules in the specification, which most
implementations violate
([oteps#208](open-telemetry/oteps#208),
[spec#3382](open-telemetry#3382),
[spec#3710](open-telemetry#3710)).
- Allow semantic convention resource modeling to progress
([spec#605](open-telemetry#605),
[spec#559](open-telemetry#559),
etc).

---------

Co-authored-by: Tigran Najaryan <[email protected]>
Co-authored-by: jack-berg <[email protected]>
Co-authored-by: Arve Knudsen <[email protected]>
Co-authored-by: David Ashpole <[email protected]>
…ion (open-telemetry/oteps#258)

Based on conversations last week in the Specification and Semantic
Conventions SIGs, I'm opening this duplicate pull request which was
originally set as a
[Draft](https://github.com/open-telemetry/oteps/pull/241/files) and
hasn't had movement since last November.

There are real use cases that are coming to fruiting, namely in the
CI/CD working group, that will benefit from this being accepted. Once
accepted we can work on getting the specification added for both general
context propagation and baggage.

On the note of baggage; baggage is a form of context propagation and was
not originally mentioned directly by name in this OTEP. It is however,
absolutely essential. I've had the pleasure of prototyping out tracing
within an OpenTofu controller system where context on available in
parent/child at the very start of the trace was available. Baggage was
the means of transferring this critical context to subsequent siblings
that would've not had it otherwise.

Thanks for all the hard work to the original author (@deejgregor) and
opening the draft open-telemetry#241

CC. TC sponsors @jsuereth @carlosalberto

---------

Co-authored-by: Robert Pająk <[email protected]>
Co-authored-by: Liudmila Molkova <[email protected]>
…#4273)

In the 10/22/24 spec SIG, we discussed that the prototyping requirement
for newly proposed features with development maturity level has a
"chicken and the egg" problem.

This resolves by clarifying what counts as a prototype for these cases.
@carlosalberto carlosalberto requested review from a team as code owners November 8, 2024 14:20
Copy link
Member

@reyang reyang left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

:shipit:

@carlosalberto carlosalberto merged commit 6b82113 into open-telemetry:main Nov 8, 2024
6 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.