* 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

added in open-telemetry#17

added in open-telemetry#17

* 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.

…s#28)

…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]>

…teps#46)

…/oteps#48)

* 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

…lemetry/oteps#52)

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

…/oteps#72)

* Update with calling conventions

* Typos

* Typos

* Formatting

* Add further motivation for Observer instruments, fix unbound variable in code samples

* Feedback for Bogdan's comments

* More depth re: c24t's feedback

* Remove bound instruments

* Show that the label set can be cached

* minor fixes in the sampling RFC

* address review comments

Co-authored-by: Bogdan Drutu <[email protected]>

…s#66)

* Proposal to separate context propagation from observability

* cleanup description for Extract

* commas

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

* Update text/0000-separate-context-propagation.md

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

* RFC proposal: A layered approach to data formats

* whitespace

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

* Capitalization

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

* whitespace

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

* CleanBaggage -> ClearBaggage

* move function descriptions to new line

* Add Optional subheader

* cleanup rough edits

* clean up advice on pre-existing context implementations

* Better context descriptions

* remove data format file

* remove git diff message

* improved code sytnax

* stop stuttering

* Update text/0000-separate-context-propagation.md

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

* spacing

* Refine propagation

* Remove registry concept
* Add explicit chaining

* Add RFC ID number from PR

* remove RFC status line

* slight calrification for GetHTTPExtractor

* add global propagators

* Clean up motivation

* Clean up explanbation intro

* Clarify context types

* Fix ChainHTTPInjector and ChainHTTPExtractor

* typo

* Reference Trace-Context, not just traceparent

* Bagge context cleanup

* stronger language around context access

* Update text/0042-separate-context-propagation.md

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

* clean up tradeoffs

* v2.0 of this OTEP

* Update OTEP number for new submission

* remove image file for unused diagram

* Update text/0066-separate-context-propagation.md

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

* Link to Erlang prototype

* whitespace

* ToC

* Update text/0066-separate-context-propagation.md

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

* more context examples

* typo

* Update text/0066-separate-context-propagation.md

Co-Authored-By: Yusuke Tsutsumi <[email protected]>

* Apply suggestions from code review

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

* Renamed aspects to "cross-cutting concerns"

* injectors are a list instead of chained

* clean up API representation

* cleanup examples

* typo

* remove correlations from proposal

* Update text/0066-separate-context-propagation.md

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

* remove the term "chaining"

* remove the terms  upstream and downstream

* improved architecturural explanation

* whitespace

* update link to Go prototype

* Removed the Baggage API; replaced it with Correlations.

* Fix the intro paragraph for Correlations

* git merges ate my homework
* some sentences were out of order

* Clarify that correltions must be propagated

* Clarify risks

* removed extra header

* Clarify definition of aspect-oriented programming

* Fix RemoveCorrelation

* Spelling

* Update text/0066-separate-context-propagation.md

Co-Authored-By: Sergey Kanzhelev <[email protected]>

* Clarifying details

* Update python prototype

* Update text/0066-separate-context-propagation.md

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

* Update text/0066-separate-context-propagation.md

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

* Update text/0066-separate-context-propagation.md

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

* Clarify that the APIs and example code are not meant as final.  Add C# prototype

* Inject returns headers, not context

* Update text/0066-separate-context-propagation.md

Co-Authored-By: Mauricio Vásquez <[email protected]>

* spelling

* remove spurious go comment

Co-authored-by: Christian Neumüller <[email protected]>
Co-authored-by: Reiley Yang <[email protected]>
Co-authored-by: alrex <[email protected]>
Co-authored-by: Tristan Sloughter <[email protected]>
Co-authored-by: Yusuke Tsutsumi <[email protected]>
Co-authored-by: Yuri Shkuro <[email protected]>
Co-authored-by: Sergey Kanzhelev <[email protected]>
Co-authored-by: Tyler Yahn <[email protected]>
Co-authored-by: Mauricio Vásquez <[email protected]>

* Remove SamplingHint from the Sampling otep

Signed-off-by: Bogdan Drutu <[email protected]>

* Update text/0006-sampling.md

Co-Authored-By: John Watson <[email protected]>

* Update text/0006-sampling.md

Co-Authored-By: John Watson <[email protected]>

Co-authored-by: John Watson <[email protected]>

open-telemetry/oteps#80)

* Remove the Metric Gauge instrument, recommend exclusive use of Observer instrument

* Typos

* More text

Co-authored-by: Bogdan Drutu <[email protected]>

Signed-off-by: Bogdan Cristian Drutu <[email protected]>

Signed-off-by: Bogdan Cristian Drutu <[email protected]>

…Meter (open-telemetry/oteps#84)

* Add InstrumentationLibrary to describe telemetry from a named Tracer/Meter

Signed-off-by: Bogdan Cristian Drutu <[email protected]>

* Update text/0083-component.md

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

* Update text/0083-component.md

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

* Update text/0083-component.md

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

* Update text/0083-component.md

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

* Update text/0083-component.md

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

Co-authored-by: Christian Neumüller <[email protected]>

…pen-telemetry/oteps#65)

OTLP proposal originally used a separate ResultCode enumeration for server
to tell the client whether the failed request can be retried or no.

After discussion here open-telemetry/opentelemetry-proto#47 (comment)
it became clear that the goal can be achieved using gRPC status codes without
a need for custom enumeration.

This change removes the ResultCode and explains how to use gRPC status codes.

Co-authored-by: Yuri Shkuro <[email protected]>

* Add Logs to OpenTelemetry vocabulary

This commit proposes the initial vocabulary for logs and event to be used across
OpenTelemetry project.

This is an initial proposal and we can extend / clarify the vocabulary as we go.

* Address PR comments

* Propose OpenTelemetry Logs Vision

This change proposes high-level items that define our long-term vision for
Logs support in OpenTelemetry project, what we aspire to achieve.

This is a starting point for discussion. I believe it is important for us
to collectively come up with such vision.

Comments, thoughts and opinions are highly welcome!
Propose OpenTelemetry Logs Vision

This change proposes igh-level items that define our long-term vision for
Logs support in OpenTelemetry project, what we aspire to achieve.

This a vision document that reflects our current desires. It is not a commitment
to implement everything precisely as listed. The primary purpose of this
document is to ensure all contributors work in alignment. As our vision changes
over time maintainers reserve the right to add, modify, and remove items from
this document.

* Address PR comments

)

This sentence was added temporarily to encourage participation
in PR discussion. It is no longer relevant since the PR is merged.

…ps#88)

* Work on new ontology

* More

* Typos

* Rewording and typos

* Updates

* More table

* Typo

* Add an example

* Add detail and translation guidance

* About monotonicity

* More on Last Value relationship

* Clarify _aggregation_

* For Bogdan

* Note about OTEP 93 and OTEP 96

* Formatting

Co-authored-by: Bogdan Drutu <[email protected]>

* OTLP/HTTP: HTTP Transport Extension for OTLP

OTLP can be currently communicated only via one transport: gRPC. While using
gRPC has certain benefits there are also drawbacks:

- Some users have infrastructure limitations that make gRPC-based protocol
  usage impossible. For example AWS ALB does not support gRPC connections.

- gRPC is a relatively big dependency, which some clients are not willing to
  take. Plain HTTP is a smaller dependency and is built in the standard
  libraries of many programming languages.

This proposal keeps the existing specification of OTLP over gRPC transport
(OTLP/gRPC for short) and defines an additional way to use OTLP protocol over
HTTP transport (OTLP/HTTP for short). OTLP/HTTP uses the same ProtoBuf payload
that is used by OTLP/gRPC and defines how this payload is communicated over HTTP
transport.

* Address PR comments

* Add response body description

Co-authored-by: Bogdan Drutu <[email protected]>

…n-telemetry/oteps#103)

* Enforce lint, link checks, fix errors. Remove status.

Signed-off-by: Bogdan Drutu <[email protected]>

* Update text/0002-remove-spandata.md

Co-authored-by: Armin Ruech <[email protected]>

* Update text/0006-sampling.md

Co-authored-by: Armin Ruech <[email protected]>

* Update text/0016-named-tracers.md

Co-authored-by: Armin Ruech <[email protected]>

* Update text/0016-named-tracers.md

Co-authored-by: Armin Ruech <[email protected]>

* Update text/0092-logs-vision.md

Co-authored-by: Armin Ruech <[email protected]>

* Allow ? in the headers

Signed-off-by: Bogdan Drutu <[email protected]>

* Disable enforce link because of DDOS protection on github.com

Signed-off-by: Bogdan Drutu <[email protected]>

Co-authored-by: Armin Ruech <[email protected]>

…s#104)

Signed-off-by: Bogdan Drutu <[email protected]>

* Nine instruments

* WIP: More explanation, starting on details section

* Introduction

* Typo fix

* Table fmt

* Rewrite without async delta instruments

* More examples

* Draft is ready

* More names considered

* More examples from review feedback

* From comments

* Typos

* Address question about MMSC

* About ValueObserver temporal quality

* More on temporal quality terminology

* 88 links to otep 88

* Swap temporal quality and default aggregation columns

* Move link ref

* Add 'Input' to the temporal quality header

* Add detail

* Rename into ./metrics

* Lint

* Lint

Signed-off-by: Bogdan Drutu <[email protected]>

Signed-off-by: Bogdan Drutu <[email protected]>

Co-authored-by: Carlos Alberto Cortez <[email protected]>

* Define Log Data model

This is a proposal of a data model and semantic conventions that allow to
represent logs from various sources: application log files, machine
generated events, system logs, etc.

Existing log formats can be unambiguously mapped to this data model.
Reverse mapping from this data model is also possible to the extent that
the target log format has equivalent capabilities.

The purpose of the data model is to have a common understanding of what a
log record is, what data needs to be recorded, transferred, stored and
interpreted by a logging system.

* Move content from Google Doc to markdown here

* Address PR comments

* Add Google Cloud Logging mapping

* Address PR comments

* Resolve Open Questions

* Add ECS mapping

* Address PR comments

Contributes to open-telemetry#622

This aligns the naming to what is already used for Embedded Logs (Span.Event).
There is no change of semantics.

* zPages proposal

* renamed file to the PR number

* linter issues

* linter issues

* added some principles for zPages development

* fixes after Reiley review

…eps#116)

This places it in the right directory according to new
structure for this repo.

* Add HTTP+JSON support for OTLP

* update protocol detail desc

* Rename title, handle line-breaking

Co-authored-by: Bogdan Drutu <[email protected]>

* Exemplar OTEP

* Wording fixes

Co-authored-by: Tyler Yahn <[email protected]>

* stats updates, specify parameters/output format

* aggregation -> aggregator, other small changes

* gauge -> lastvalue

* Update text/metrics/0113-exemplars.md

Co-authored-by: Chris Kleinknecht <[email protected]>

Co-authored-by: Tyler Yahn <[email protected]>
Co-authored-by: Chris Kleinknecht <[email protected]>
Co-authored-by: Bogdan Drutu <[email protected]>

* Added auto resource detection proposal

* Removed resource provider concept as per review comments

* Changed the proposal back to separating resource detection from the tracer/meter providers, clarified default resource detection in more detail, and added more points to the trade-offs & mitigations section

* Wrap lines

Co-authored-by: Sergey Kanzhelev <[email protected]>

* Proposal for metric naming conventions

* Add Node example metrics

* Node.js instead of Node

* Rename file, add Prometheus quote

* Second round of revisions

* Working group feedback

* More feedback changes

* Minor clarifications

* Word choice

* Whitespace to check CLA status

* Update text/metrics/0108-naming-conventions.md

Co-authored-by: Tyler Yahn <[email protected]>

* Update text/metrics/0108-naming-conventions.md

Co-authored-by: Tyler Yahn <[email protected]>

* Update text/metrics/0108-naming-conventions.md

Co-authored-by: Tyler Yahn <[email protected]>

* Update text/metrics/0108-naming-conventions.md

Co-authored-by: Tyler Yahn <[email protected]>

* Update text/metrics/0108-naming-conventions.md

Co-authored-by: Tyler Yahn <[email protected]>

* Update text/metrics/0108-naming-conventions.md

Co-authored-by: Tyler Yahn <[email protected]>

* Update text/metrics/0108-naming-conventions.md

Co-authored-by: Tyler Yahn <[email protected]>

* Code review feedback, remove discussion section

* Remove some discussion topics, and fix an example

* Rename OTEP 108 to metric naming _guidelines_

Co-authored-by: Tyler Yahn <[email protected]>
Co-authored-by: Bogdan Drutu <[email protected]>
Co-authored-by: jfoote <[email protected]>
Co-authored-by: Yuri Shkuro <[email protected]>

* Otep for dynamic configuration

* Revisions

* Further explanation

* Fix link

* Revise proposal

Co-authored-by: Sergey Kanzhelev <[email protected]>

* Revisions

* Make experimental

* Slight revisions

* Revisions

* Phase 1

* Revisions

* Change filename

* Fix lint errors

* Update text/0121-config-service.md

Co-authored-by: Chris Kleinknecht <[email protected]>

* Revisions

* Fix lint errors

* Add metadata explanation

* Update text/0121-config-service.md

Co-authored-by: Yuri Shkuro <[email protected]>

* Update text/0121-config-service.md

Co-authored-by: Yuri Shkuro <[email protected]>

* Update text/0121-config-service.md

Co-authored-by: Yuri Shkuro <[email protected]>

* Update text/0121-config-service.md

Co-authored-by: Yuri Shkuro <[email protected]>

* Change period from enum to int

* Specified service for metrics, removed tracing

* Switch to MetricConfig

* Clarify period description

* Remove metadata field

* Move to experimental folder

Co-authored-by: Sergey Kanzhelev <[email protected]>
Co-authored-by: Chris Kleinknecht <[email protected]>
Co-authored-by: Yuri Shkuro <[email protected]>
Co-authored-by: Bogdan Drutu <[email protected]>

…s#119)

* standard system and runtime metric names

* added more conventions and tables

* formatting

* cleanup writing/grammar

* Made tables shorter, cleaned up, added runtime overview

* more small fixes

* Tweaks and moved "Open Questions" to the end

* added PR number to filename

* lint

* Update tables, add runtime examples, from review

* More edits addressing review comments

- Clarify these are metric instrument names (not "metrics")
- Remove discussion points I left inline
- Add unresolved comments from review to open questions

* add open question on versioning

* removed open question about versioning

* unabbreviate "net" and "ops"

Co-authored-by: Bogdan Drutu <[email protected]>

Per my conversation with @tigrannajaryan, we have determined that event dimensions are
more appropriate as attributes since a single logical Resource could emit events with
disparate dimension sets.  Also, we need to be able to unambiguously reverse a LogRecord to
a SignalFx Event, so properties are nested in a specially keyed map inside Attributes.

open-telemetry/oteps#126)

* Add a proposal for SDK configurations for metric aggregation.

* rename file to match the PR #

* fix markdown lint issues

* clarify that this applies to the default SDK, and fill out the open questions

* update the java example to fix the naming changes

* Add another open question to the list.

* Update text/0126-Configurable-Metric-Aggregations.md

Co-authored-by: Chris Kleinknecht <[email protected]>

* Update to use the 'view' terminology

* another configuration/view replacement

* Add a few more open questions, and a note that they will be resolved in the spec.

* Update text/0126-Configurable-Metric-Aggregations.md

Co-authored-by: Tyler Yahn <[email protected]>

Co-authored-by: Chris Kleinknecht <[email protected]>
Co-authored-by: Tyler Yahn <[email protected]>
Co-authored-by: Bogdan Drutu <[email protected]>

…0126-Configurable-Metric-Aggregations.md (open-telemetry/oteps#132)

…en-telemetry/oteps#131)

* add otlp export otep

* Make SDK OTLP exporters support configurable export behavior

Based on discussions from the Metrics SIG meeting, configurable export behavior from the OTLP exporter is desired to support different mertic backends

* Make SDK OTLP exporters support configurable export behavior

Based on discussions from the Metrics SIG meeting, configurable export behavior from the OTLP exporter is desired to support different mertic backends

* fix format to pass markdownlint

* add sentence to highlight cumulative -> delta is also needed

Co-authored-by: Bogdan Drutu <[email protected]>

…rics 1.0 GA) (open-telemetry/oteps#130)

* Define what's in scope for OpenTelemetry Logs 1.0 GA

Clearly defined scope is important to align all logs contributors and to make
sure we know what target we are working towards. Note that some of the listed
items are already fully or partially implemented but are still listed for
completeness.

* Address PR comments

Co-authored-by: Bogdan Drutu <[email protected]>

This link was broken on a repo restructuring. The name of the spec was also changed from Correlation-Context to Baggage (see w3c/baggage#27)

…eps#143)

Link to readable version: https://github.com/tedsuo/rfcs/blob/versioning/text/0143-versioning-and-stability.md

Versioning is a high priority as we still hope to get some kind of release or announcement out by end of year. This proposal explains the versioning protocol and stability guarantees for OpenTelemetry implementations in every language. 

 It would be a helpful exercise to have maintainers review this proposal, and write out their language specific-expectations.

**Request for Maintainers:** Please create a language-specific document which describes how versioning and support works for your language, based on this OTEP, and post a link to it in the [tracking issue here](open-telemetry#1267). We want to ensure that versioning and support as been thought through before it is added to the spec.

Cheers,
-T

* metrics prototype scenario

* rename

* fix typo

* Update text/metrics/0146-metrics-prototype-scenarios.md

Co-authored-by: Cijo Thomas <[email protected]>

* Update text/metrics/0146-metrics-prototype-scenarios.md

Co-authored-by: Cijo Thomas <[email protected]>

* Update text/metrics/0146-metrics-prototype-scenarios.md

Co-authored-by: Cijo Thomas <[email protected]>

* Update text/metrics/0146-metrics-prototype-scenarios.md

Co-authored-by: Cijo Thomas <[email protected]>

* clarify GA/stable

* add example to exemplar

* adjust the proposed timeline considering most folks will be on vacation in Dec.

* fix nits

* adjust the ToC

* fix nits

* Update text/metrics/0146-metrics-prototype-scenarios.md

Co-authored-by: Leighton Chen <[email protected]>

* Update text/metrics/0146-metrics-prototype-scenarios.md

Co-authored-by: Leighton Chen <[email protected]>

* adjust wording

* fix typo

* address review comment

* address comments

* Update text/metrics/0146-metrics-prototype-scenarios.md

Co-authored-by: Cijo Thomas <[email protected]>

Co-authored-by: Cijo Thomas <[email protected]>
Co-authored-by: Leighton Chen <[email protected]>

…#150)

This is a draft proposal for OpenTelemetry Logging Library SDK specification.
The purpose of his proposal is to lay out the initial understanding of
what Logging Library SDKs will look like.

We would like to create prototypes based on this proposal in a few languages.
The learnings from prototypes will then allow us to refine this proposal and
eventually make the proposed approach part of the OpenTelemetry specification.

The approach proposed in this OTEP is not intended to be merged into the
OpenTelemetry specification after the OTEP itself is approved. We want to have
successful prototypes first. This OTEP is first and foremost a specification and
guidelines on how to create the prototypes.

The specification defines how the OpenTelemetry Logging Library SDK exposes its
functionality to authors of extensions to language-specific 3rd party logging
libraries and to end users that want to produce logs in
[OpenTelemetry manner](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/logs/overview.md).

The specification defines SDK elements that to some extent mirror the
OpenTelemetry
[Trace SDK](https://github.com/open-telemetry/opentelemetry-specification/tree/main/specification/trace).
This ensures uniformity and consistency of the OpenTelemetry specification and
of the implementations across traces and logs. For additional clarity the
definitions in this document refer to the Trace analogs where appropriate.

The descriptions of interfaces and methods in this document are intentionally
very brief. Detailed and precise descriptions will be borrowed from Trace
specification when this OTEP is submitted as a Log specification PR. I kept the
descriptions as short as possible in this document to make reviewing it easy and
fast.

…n-telemetry/oteps#151)

Resolves open-telemetry#1324

I believe changes to semantic conventions and the shape of emitted telemetry
are likely to occur during the lifetime of an instrumentation library.
I do not think we should aim to lock the telemetry schema and disallow changes to it.
Such locking would place a huge limitation on how instrumentation can evolve and
would make it nearly impossible to fix mistakes in the semantic conventions, in the
schema or  in the implementation of the instrumentation (which will inevitably happen
sooner or later).

This OTEP introduces the concept of telemetry schemas that allows semantic conventions
and instrumentations to evolve over time without breaking consumers of telemetry.

Merging as Admin as this is simply a typo.

Add a note about temperature recordings being potentially negative.

Co-authored-by: Joshua MacDonald <[email protected]>

…#149)

* add text/0000-exponential-histogram.md

* rename to match PR#

* fix lint complaint

* more lint fix

* remove statement on inclusive vs. exclusive bounds

Co-authored-by: Joshua MacDonald <[email protected]>

…ry/oteps#170)

* draft from OTEP 148

* renumber

* typo in header

* typos

* formatting

* clean TOC

* TOC edit

* Clarify the counting algorithm

* typos

* grammar

* grammar

* two paragraphs

* Summarize from the prototype

* Remove exported count from proposed spec language

* statement about not dropping sampler attributes

* from Thursday's SIG, limit proposal to head sampling probability

* log_head_adjusted_count

* Use 6 bits

* update the proto text

* add detail on SamplerResult

* remove metrics examples, add to span-to-metrics examples

* whitespace

* lint

…pen-telemetry/oteps#177)

…elemetry/oteps#168)

Fixes open-telemetry#1989

OTEP 0152 predates renaming of labels to attributes in the spec. Unfortunately
the schema file format still uses the term "label" in the metrics section this way:
```yaml
    metrics:
      changes:
        - rename_labels:
            label_map:
              # map of key/values. The keys are the old label name used
              # in the previous version, the values are the new label name
              # starting from this version.

            apply_to_metrics:
              # Optional. If it is missing the transformation is applied
              # to all metrics. If it is present the transformation is applied
              # only to the metrics with the name that is found in the sequence
              # specified below.
```

We don't want the word `label` in the schema files, instead we want the word
`attribute` to be used instead.

Discussed in spec meeting, decided:
- OTEPs which are not part of the spec repo are not considered to be final,
  or be an actual part of stable spec (OTEPs are not labeled "stable" in any way).
- Modify the OTEP, rename `label` to `attribute` (this commit).
- Merge the OTEP with the spec.

The OTEP text correctly says:
>In addition it is also possible to optionally specify spans and events that the transformation should apply to.

However, the block after that text is missing the apply_to_spans
that the text alludes to. I wrote the text correctly but made a
mistake when copy/pasting the yaml from my experimental codebase.

I consider this to be a non-breaking change. It is a bug fix since
the tag in yaml is supposed to be there according to the text.

… tracing (open-telemetry/oteps#173)

[Semantic conventions for messaging systems for tracing](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/trace/semantic_conventions/messaging.md) are available, but are in an experimental state. A [workgroup focusing on messaging semantic conventions](open-telemetry/community#819) will work on bringing the existing semantic conventions for messaging to a stable state. The workgroup meets on **Thursdays at 8AM PST**.

This documents proposes a scope for an initial stable version of messaging semantic conventions, as well as a roadmap.  It should serve as a starting point for initial discussions in the workgroup and, once agreed on, define the further agenda of the workgroup.

…pen-telemetry/oteps#183)

The discussion while implementing the Java SDK revealed that the LogRecord
data type may not be necessary. See here open-telemetry/opentelemetry-java#3759 (comment)

However, in some other languages LogRecord fits nicely (see the comment about
Python implementation in the same comment thread).

This changes allows implementators of the OTEP to choose the most idiomatic
approach for their language.

… for tracing to an initial stable state (open-telemetry/oteps#174)

…ps#178)

The mapping is necessary to correctly implement Logging Library SDKs such that
values mapped are unambiguous, consistent across languages and implementations.

* Introduce Scope Attributes

There are a few reasons why adding Scope attributes is a good idea:
- There are 2 known use cases where Scope attributes can solve specific problems:
  - Add support for [Meter "short_name"](open-telemetry#2422),
    represented as an attribute of Meter's Scope.
  - Add support for differentiating the type of data emitted from the scopes that belong
    to different data domains, e.g. profiling data emitted as log records or client-side
    data emitted as log records needs to be differentiated so that it can be easily
    routed and processed differently in the backends. We don't have a good way to handle
    this today. The type of the data can be recorded as an attribute Logger's Scope.
- It makes Scope consistent with the other primary data types: Resource, Span, Metric,
  LogRecord.

See additional [discussion here](open-telemetry#2450).