Yingrong.update protos 2 #2
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
This adds guarantees that are necessary for OTLP/JSON wire representation stability. This does not yet declare OTLP/JSON. It will be a separate PR once we are certain nothing else is needed.
…received (open-telemetry#444) This is considered an bug in the spec that was uncovered in the discussion here: open-telemetry#442 (comment) I did some spelunking and the "generate" recommendation comes from the very first commit: open-telemetry@b5bcfff#diff-ef5f80fbf835dd57e14cb9264944f03d80cf6b04cc7671b0e7fb33167c67efcc where they were copied from Java repo, to which they were copied from OpenCensus open-telemetry/opentelemetry-java#134 and in OpenCensus the wording first time appeared here census-instrumentation/opencensus-proto#160 (authored by @SergeyKanzhelev, merged by @bogdandrutu). We are deleting the requirement to generate a new trace id or span id if an invalid id is received. The receivers can decide how they want to treat the invalid id (just like upon receiving any other invalid id), e.g. they may drop it, log an error, accept the invalid data, etc. We are not going to prescribe a particular receiver behavior when invalid trace/span id is received.
…ields (open-telemetry#442) Resolves open-telemetry/opentelemetry-specification#3040 This is not a breaking change: - For Span it now defines more precisely the receiver behavior that was previously defined vaguely (e.g. it was unclear what "empty" means for bytes field). - For LogRecord it now defines the receiver behavior that was previously unspecified. This ensures that the wording are consistent with what we have for the Span.
…-telemetry#454) * Update breaking-change to check against last published version * Fetch tags
Co-authored-by: Reiley Yang <[email protected]> Co-authored-by: Armin Ruech <[email protected]>
This PR explicitly lists the additive changes allowed and adds a requirement that such additive changes must be accompanied by interoperability explanation when necessary. This is a subset of open-telemetry#432 that contains other guarantees that we did not yet agree to. I believe this particular subset is necessary regardless of what we decide about open-telemetry#432.
Signed-off-by: Bogdan Drutu <[email protected]>
* Add OTLP to the specification We previously had OTLP definition scattered in multiple OTEPs. This amalgamates the OTEPs and brings OTLP to the specification repo. * Address PR comments * Address PR comments
* Allow specifying a single configuration The following change describes that the OTLP exporter must support configuration for all signals via a single set of configuration options. There is also an example for configuring different signals with different endpoints via environment variables. * adding a third example * moving otlp exporter into protocol directory * add link to exporter from readme * apply review feedback
…g (#911) Resolves: open-telemetry/opentelemetry-specification#786 See discussion and motivation for the change in the issue linked above. Co-authored-by: Sergey Kanzhelev <[email protected]>
MUST is the correct requirement here. There is no situation when a different content type is a better choice.
* Change default OTLP port number Contributes to open-telemetry/opentelemetry-specification#1148 Note that a separate port is used for OTLP/HTTP for now. There is currently work in progress to confirm that we can use the same port. Once we have the confirmation I will update the spec again to use one port. * Address PR comments
* Remove support to allow_different_nesting, from markdownlint Signed-off-by: Bogdan Drutu <[email protected]> * Update specification/metrics/semantic_conventions/README.md Co-authored-by: Armin Ruech <[email protected]> * Run markdown-toc Signed-off-by: Bogdan Drutu <[email protected]> Co-authored-by: Armin Ruech <[email protected]>
## Changes It seems wired that the closing tag of `<details>` is missing. As a result, most of the content has been folded. Added a closing `</details>` tags to only fold the table of contents. Before the change:  After the change: 
* Versioning and support based on OTEP 143
Signed-off-by: Bogdan Drutu <[email protected]>
…(#1637) Resolves open-telemetry#268 This behavior is already the documented behavior for JSON Protobuf, see https://developers.google.com/protocol-buffers/docs/proto3#json: >JSON value will be a decimal string. Either numbers or strings are accepted.
* Mark sections of datamodel stable. * Generated ToC * Clean up MUST and SHOULD in the document. * adjust for bug in markdown-toc * Mark protocol as stable. Co-authored-by: Carlos Alberto Cortez <[email protected]>
The Log SIG discussed and made a decision to declare Log data model and Log part of OTLP Beta. (See SIG meeting notes here https://docs.google.com/document/d/1cX5fWXyWqVVzYHSFUymYUfWxUK5hT97gc23w595LmdM/edit#heading=h.28y76as82bvu)
Related to open-telemetry/opentelemetry-specification#1816 Fixes open-telemetry/opentelemetry-specification#1835 Some historical context: we wanted to make grpc and http use the same port and we had an open issue in the Collector to do so: open-telemetry/opentelemetry-collector#1256 The conclusion is that there are technical hurdles that make it unfeasible: open-telemetry/opentelemetry-collector#1256 (comment) Because of that we need to keep grpc and http ports separate. This means we need to change the spec to say that otlp/http uses port 4318. Once this PR is merged we will also need to submit for port 4318 registration with IANA like we did previously with port 4317: open-telemetry/opentelemetry-specification#1148 (comment)
Co-authored-by: Tigran Najaryan <[email protected]>
Co-authored-by: Joshua MacDonald <[email protected]>
Co-authored-by: Joshua MacDonald <[email protected]>
Co-authored-by: Joshua MacDonald <[email protected]>
Co-authored-by: Joshua MacDonald <[email protected]>
Co-authored-by: Joshua MacDonald <[email protected]>
Co-authored-by: Tigran Najaryan <[email protected]>
Co-authored-by: Tigran Najaryan <[email protected]>
Co-authored-by: Johannes Tax <[email protected]>
* Add bitshift to comment for reading span flags * Change >> to != 0
…en-telemetry#514) * add metric.attributes for supporting additional metadata on metrics
* Fix wrong spelling in README.md Fix wrong spelling in README.md * Polish document content
This is a follow up to [OTEP 239: Introduces Profiling Data Model v2](open-telemetry/oteps#239) The main motivation behind this PR is that this will allow us to start experimenting with the profiles proto in opentelemetry-collector. I marked the profiles part as `Experimental` to indicate that this is not a final version of the data model. I copied the proto from the OTEP, and moved `pprofextended.proto` from `profiles/v1/alternatives/pprofextended.proto` to just `profiles/v1/pprofextended.proto`. I did this because I figured we no longer have alternative representations and this will reduce confusion for people outside of Profiling SIG. The rest of the proto stayed the same. I tested this file with a collector fork and I it compiles properly.
…metry#342)" This reverts commit 8ba33cc.
VinozzZ
force-pushed
the
yingrong.update_protos_2
branch
from
d931dc6
to
d161664
Compare
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.
No description provided.