Add bytes (binary) as a data type to AnyValue#297
Merged
tigrannajaryan merged 1 commit intoopen-telemetry:mainfrom May 5, 2021
Merged
Add bytes (binary) as a data type to AnyValue#297tigrannajaryan merged 1 commit intoopen-telemetry:mainfrom
tigrannajaryan merged 1 commit intoopen-telemetry:mainfrom
Conversation
Contributes to: open-telemetry/opentelemetry-specification#780 open-telemetry/opentelemetry-collector-contrib#3267 Issue open-telemetry/opentelemetry-specification#780 nicely describes why the data type is needed. There are several use cases for binary data, both for trace and log attributes and for log record Body. This is a backward compatible addition. After this change is merged no senders will initially exist that emit binary data. Nevertheless, if such data is received by the Collector it will correctly pass such data intact through the pipeline when receiving/sending OTLP (no Collector code changes are needed for this). We do not yet have binary data type in the OpenTelemetry API, so no existing sources can emit it yet. The receivers that do not understand the binary data type should also continue functioning normally. Collector's current implementation treats any unknown data type as NULL (and this would apply to binary data type until we teach the Collector to understand binary specifically). I checked the Collector source code and this should not result in crashes or overly surprising behavior (NULL is either ignored or treated as an "unknown" branch in the code which does not care about it). We will add full support for binary data to the Collector, particularly to support translating it correctly to other formats (e.g. Jaeger, which supports binary type natively). Note: the addition of this data type to the protocol is not an obligation to expose the data type in the Attributes API. OTLP has always been a superset of what is possible to express via the API. The addition of the data type in the Attributes API should be discussed separately in the specification repo.
jsuereth
approved these changes
Apr 29, 2021
zenmoto
approved these changes
Apr 30, 2021
djaglowski
approved these changes
May 3, 2021
Member
Author
|
@open-telemetry/specs-approvers it would be good to have a few more eyes on this before I merge it. |
jmacd
approved these changes
May 5, 2021
Oberon00
approved these changes
May 5, 2021
3 tasks
This file contains hidden or 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
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.
Contributes to:
open-telemetry/opentelemetry-specification#780
open-telemetry/opentelemetry-collector-contrib#3267
Issue open-telemetry/opentelemetry-specification#780
nicely describes why the data type is needed. There are several use cases
for binary data, both for trace and log attributes and for log record Body.
This is a backward compatible addition. After this change is merged no senders
will initially exist that emit binary data. Nevertheless, if such data is received
by the Collector it will correctly pass such data intact through the pipeline
when receiving/sending OTLP (no Collector code changes are needed for this).
We do not yet have binary data type in the OpenTelemetry API, so no existing
sources can emit it yet.
The receivers that do not understand the binary data type should also continue
functioning normally. Collector's current implementation treats any unknown
data type as NULL (and this would apply to binary data type until we teach
the Collector to understand binary specifically). I checked the Collector source
code and this should not result in crashes or overly surprising behavior
(NULL is either ignored or treated as an "unknown" branch in the code which
does not care about it).
We will add full support for binary data to the Collector, particularly to
support translating it correctly to other formats (e.g. Jaeger, which supports
binary type natively).
Note: the addition of this data type to the protocol is not an obligation to
expose the data type in the Attributes API. OTLP has always been a superset of
what is possible to express via the API. The addition of the data type in the
Attributes API should be discussed separately in the specification repo.