[Feature]: Define v2 storage API that operates on OTLP batches #5079
Labels
Comments
24 tasks
yurishkuro
added a commit
that referenced
this issue
Jan 15, 2024
## Which problem is this PR solving? - Part of #5079 - Avoid triple marshaling due to our use of internally generated OTLP proto types, which prevents us from directly using the output of jaeger->otlp conversion from collector contrib. ## Description of the changes - 🛑 breaking: the JSON format is changed to match [OTLP-JSON][otlp-json], specifically - the trace & span IDs are returned as hex-encoded strings, not base64 as required by Proto-JSON - enums are returned as integers, not strings - Use Proposal 1 from open-telemetry/opentelemetry-collector#9233 (comment) - API-V3 proto is already declared to use official OTLP types; remove the overrides to our internally generated OTLP proto types - Replace `SpansResponseChunk` with official `otlp.TracesData`, but override it internally to use a custom type - Depends on jaegertracing/jaeger-idl#103 ## How was this change tested? - Unit tests [otlp-json]: https://github.com/open-telemetry/opentelemetry-proto/blob/main/docs/specification.md#json-protobuf-encoding --------- Signed-off-by: Yuri Shkuro <github@ysh.us>
|
Can I take this issue ? |
|
you can try - this is a design issue |
4 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Requirement
In OTEL-based Jaeger-v2 we don't want to force OTLP trace data to go through unnecessary transformation into Jaeger's current data model. We want to define a V2 version of the storage API so that the OTLP data can be passed through the receiver-exporter pipeline without additional conversions, for better efficiency.
Problem
More discussion in the doc https://docs.google.com/document/d/1s4_6VgAS7qAVp6iEm5KYvpiGw3h2Ja5T5HpKo29iv00/edit#heading=h.hlhu8pegwdcj
to be continued
Open questions
No response
The text was updated successfully, but these errors were encountered: