Merge OTEPs into the Specification #4288
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
* 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
…s#62) * Update 0008 and accept
…etry/oteps#70) * Add Bound Instruments OTEP * Add status
* Configuration proposal This OTEP is the result of the Configuration working group. See open-telemetry#2920 for additional details.
* Introduce remote-parent OTEP
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.
codeboten
approved these changes
Nov 8, 2024
tigrannajaryan
approved these changes
Nov 8, 2024
6 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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).
Additionally, additional lint fixes in order to merge this:
Follow-up items listed in #4284