Hello, I am using OtlpTraceJsonExporter to export trace data as JSON and I am running in to an issue where the trace and span IDs are base64-encoded strings instead of being hex-encoded strings which is causing our collector endpoint to reject the payloads (e.g. OWUyYTNkYzA2MDc0YjE3NTQwZDU0ZGU0ZTUxZTczNWY= instead of 9e2a3dc06074b17540d54de4e51e735f).
According to this spec, the values should be hex-encoded.
The traceId and spanId byte arrays are represented as case-insensitive hex-encoded strings; they are not base64-encoded as is defined in the standard Protobuf JSON Mapping. Hex encoding is used for traceId and spanId fields in all OTLP Protobuf messages, e.g., the Span, Link, LogRecord, etc. messages. For example, the traceId field in a Span can be represented like this: { “traceId”: “5B8EFFF798038103D269B633813FC60C”, … }
Is this a known issue? The only workaround I'm able to find is decoding the JSON output of Message.jsonUTF8Data, decoding the base64 values, and re-encoding the JSON payload with the decoded trace/span IDs.
Hello, I am using
OtlpTraceJsonExporterto export trace data as JSON and I am running in to an issue where the trace and span IDs are base64-encoded strings instead of being hex-encoded strings which is causing our collector endpoint to reject the payloads (e.g.OWUyYTNkYzA2MDc0YjE3NTQwZDU0ZGU0ZTUxZTczNWY=instead of9e2a3dc06074b17540d54de4e51e735f).According to this spec, the values should be hex-encoded.
Is this a known issue? The only workaround I'm able to find is decoding the JSON output of
Message.jsonUTF8Data, decoding the base64 values, and re-encoding the JSON payload with the decoded trace/span IDs.