-
Notifications
You must be signed in to change notification settings - Fork 3
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
OTLP Zipkin Collector #5
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a couple of comments on the Armeria portion, didn't look in detail at other parts
try (ReadBuffer readBuffer = ReadBuffer.wrapUnsafe(nioBuffer)) { | ||
try { | ||
InputStream inputStream = readBuffer; | ||
if ("gzip".equalsIgnoreCase(req.headers().get("content-encoding"))) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should add DecodingService
in reconfigure
instead of handling content-encoding ourselves
It doesn't support base64
in it's default decoders list, but I've never seen that encoding before and don't see it mentioned in otlp docs (it just mentions gzip) so suspect the default is fine.
Tried to remember why we don't use DecodingService
in zipkin-server and couldn't (looked through openzipkin/zipkin#2348). It might be related to metrics there but I can't see any reason to avoid it here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great hint, I've updated the PR
} else if ("base64".equalsIgnoreCase(req.headers().get("content-encoding"))) { | ||
inputStream = Base64.getDecoder().wrap(content.toInputStream()); | ||
} | ||
ExportTraceServiceRequest request = ExportTraceServiceRequest.parseFrom(inputStream); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Without needing to decode input streams, you should be able to parse the ByteBuffer
directly with CodedInputStream.newInstance(nioBuffer)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How would that look like? I don't want to misuse the API 😬
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Assuming I didn't miss anything, I think it's just that
ExportTraceServiceRequest request = ExportTraceServiceRequest.parseFrom(CodedInputStream.newInstance(nioBuffer));
Don't need ReadBuffer
, it's a InputStream
so currently the parsing is going through protobuf's slow InputStream
parsing path
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually that's even simpler - ExportTraceServiceRequest request = ExportTraceServiceRequest.parseFrom(content.toInputStream());
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah yeah that's the least lines but I think CodedInputStream.newInstance(content.byteBuf().nioBuffer())
isn't too bad and avoids going through the InputStream
version of protobuf parsing. It's not terrible but since we've already aggregated, better to avoid it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, fixed that. Thank you
import java.util.Base64; | ||
import java.util.List; | ||
import java.util.concurrent.CompletableFuture; | ||
import java.util.zip.GZIPInputStream; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
BTW just randomly noticed it seems unused imports aren't hitting CI, not sure if it's intended or not
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can't make the build fail because of that locally either 🤔
marking this draft until it is mergable without conflict. helps me remember what's ready to review vs not. |
when polishing this later, consider @reta recent PR which had a nice description README updates etc. basically we want to get to a point where merging this won't cause work for others to go back and polish it, add docs, etc openzipkin/zipkin#3765 |
List<Span> spans = SpanTranslator.translate(request); | ||
collector.collector.accept(spans, result); | ||
} catch (IOException e) { | ||
throw new RuntimeException(e); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The method throws Lost track this is lambda, probably Exception
, do we need to wrap it into RuntimeException
?new UncheckedIOException(ex)
would be better here
module/pom.xml
Outdated
<dependency> | ||
<groupId>com.fasterxml.jackson.core</groupId> | ||
<artifactId>jackson-annotations</artifactId> | ||
<version>2.17.0</version> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
<version>2.17.0</version> | |
<version>2.17.1</version> |
pom.xml
Outdated
|
||
<assertj.version>3.25.3</assertj.version> | ||
<awaitility.version>4.2.1</awaitility.version> | ||
<junit-jupiter.version>5.10.2</junit-jupiter.version> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
<junit-jupiter.version>5.10.2</junit-jupiter.version> | |
<junit-jupiter.version>5.10.3</junit-jupiter.version> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ps marcin added a different PR for this stuff, so there's a conflict. If you prefer to do a re-bump pass PR, I'll review it as he needs to rebase this anyway
import java.util.Map; | ||
|
||
/** | ||
* LabelExtractor extracts the set of OTel Span labels equivalent to the annotations in a |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
* LabelExtractor extracts the set of OTel Span labels equivalent to the annotations in a | |
* AttributesExtractor extracts the set of OTel Span labels equivalent to the annotations in a |
import java.util.regex.Pattern; | ||
import java.util.stream.Collectors; | ||
|
||
class LinkUtils { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
class LinkUtils { | |
final class LinkUtils { |
OK, I've done everything that was requested of me, I've applied all the review suggestions. I think that there's no point in delaying the review of this any further. |
@marcingrzejszczak can you please close this pr as #13 has already been merged. |
Code + tests for OTLP encoding and collecting. Tests using OTel OTLP exporters against OTLP Zipkin Collector