-
Notifications
You must be signed in to change notification settings - Fork 1.6k
[pdata/common] Marshal Value
to JSON bytes using the OTLP/JSON format
#12826
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
Comments
Pinging code owners:
See Adding Labels via Comments if you do not have permissions to add labels yourself. |
We should be following the spec on this one, see https://github.com/open-telemetry/opentelemetry-proto/blob/main/docs/specification.md#json-protobuf-encoding. If we are not, feel free to point the bug and we will fix it. If you think the spec does not have the right behavior, this is something we should discuss over at https://github.com/open-telemetry/opentelemetry-proto |
Value
Value
to JSON bytes using the OTLP/JSON format.
Value
to JSON bytes using the OTLP/JSON format.Value
to JSON bytes using the OTLP/JSON format
@mx-psi Thanks for your reply! There is no bug or wrong behavior here. I am just looking for some functions called opentelemetry-collector/pdata/ptrace/json.go Lines 21 to 43 in 568c3ce
|
+1 to support MarshalValue / UnmarshalValue (but via marshaler structs, not as global methods). The support for complex types in attributes has always been contentious in the spec, with the common suggestion for the backends which can't support those natively to store data as JSON, but there are no methods in pdata to produce OTLP/JSON representation of individual |
We can provide a PR if maintainers indicate acceptance. |
Thanks for the context, I support this, but would like to confirm thart @bogdandrutu and @dmitryax are okay with this before moving ahead |
Component(s)
pdata
Describe the issue you're reporting
Background
We aim to store the complex types (
map
,slice
) ofvalue
withinattributes
as JSON safely. Currently, serializing them to JSON strings usingvalue.AsString()
leads to the risk of losing type information during deserialization. Specifically:int64
or afloat64
.map
andslice
structures is particularly problematic due to their dynamic and unpredictable nesting levels.Solution
This issue can be resolved with a minor modification. Instead of directly serializing and deserializing the high-level
Value
type, we will operate on the underlyingotlpcommon.AnyValue
type it holds.AnyValue
is a Go struct generated from Protobuf definitions, which allows for a more precise representation of different data types.Here is the code implementing this functionality:
The text was updated successfully, but these errors were encountered: