Skip to content
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

Optimize Encoding by Grouping Multiple Spans into OTEL TraceData #11

Open
making opened this issue Aug 20, 2024 · 1 comment
Open

Optimize Encoding by Grouping Multiple Spans into OTEL TraceData #11

making opened this issue Aug 20, 2024 · 1 comment
Labels
enhancement New feature or request

Comments

@making
Copy link
Collaborator

making commented Aug 20, 2024

Feature

Optimize Encoding by Grouping Multiple Spans into OTEL TraceData

Rationale

The current implementation of the encoder converts each Zipkin Span into a OTEL TraceData object. As a result, TraceData with only a single Span is sent each time. In OTEL, multiple Spans are typically grouped within ResourceSpans, and multiple ResourceSpans can be wrapped within a single TraceData. This makes the current implementation appear inefficient.

By converting MutableSpan to io.opentelemetry.proto.trace.v1.Span within the encoder, and then aggregating multiple Spans into a single TraceData on the zipkin2.reporter.Encoding or zipkin2.reporter.internal.AsyncReporter side, the efficiency of the encoding process could be significantly improved.

Example Scenario

In the current setup, each individual Zipkin Span results in a separate TraceData object being sent, even though OTEL is designed to handle multiple Spans together within ResourceSpans. By adjusting the implementation to aggregate multiple Spans into a single TraceData object, it would reduce overhead and improve processing efficiency, especially in environments where a large volume of Spans is being reported.

@making making added the enhancement New feature or request label Aug 20, 2024
@making making mentioned this issue Aug 20, 2024
@codefromthecrypt
Copy link
Contributor

this is an interesting feature idea. in brave, there is a localRootId which was made for aggregating by trace ID, just not span ID. I'm not sure if there is something in otel side to aggregate once already converted to otel. Mainly, the challenge on this is to ensure you release/timeout what you are collecting.

here are some breadcrumbs
https://github.com/openzipkin/brave/blob/69003dfc811418f0dbc42e9e17ff880ebe1f4b02/brave/src/test/java/brave/features/handler/SkeletalSpansTest.java
https://github.com/openzipkin/brave/blob/69003dfc811418f0dbc42e9e17ff880ebe1f4b02/brave/src/test/java/brave/features/handler/CountingChildrenTest.java
https://github.com/openzipkin-contrib/zipkin-storage-kafka/blob/master/storage/src/main/java/zipkin2/storage/kafka/streams/SpanAggregationTopology.java

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants