-
Notifications
You must be signed in to change notification settings - Fork 2.3k
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
[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 <[email protected]>
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: