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

OTLP Zipkin Collector #5

Closed
wants to merge 34 commits into from
Closed

OTLP Zipkin Collector #5

wants to merge 34 commits into from

Conversation

marcingrzejszczak
Copy link
Collaborator

Code + tests for OTLP encoding and collecting. Tests using OTel OTLP exporters against OTLP Zipkin Collector

Copy link

@anuraaga anuraaga left a 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"))) {

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

https://github.com/line/armeria/blob/main/core/src/main/java/com/linecorp/armeria/server/encoding/DecodingService.java#L49

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.

Copy link
Collaborator Author

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);

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)

Copy link
Collaborator Author

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 😬

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

Copy link
Collaborator Author

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());

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.

Copy link
Collaborator Author

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;

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

Copy link
Collaborator Author

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 🤔

@codefromthecrypt codefromthecrypt marked this pull request as draft June 28, 2024 00:07
@codefromthecrypt
Copy link
Contributor

marking this draft until it is mergable without conflict. helps me remember what's ready to review vs not.

@codefromthecrypt
Copy link
Contributor

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);
Copy link

@reta reta Jun 28, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The method throws Exception, do we need to wrap it into RuntimeException? Lost track this is lambda, probably 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>
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
<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>
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
<junit-jupiter.version>5.10.2</junit-jupiter.version>
<junit-jupiter.version>5.10.3</junit-jupiter.version>

Copy link
Contributor

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
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* 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 {
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
class LinkUtils {
final class LinkUtils {

@marcingrzejszczak marcingrzejszczak marked this pull request as ready for review June 28, 2024 09:17
@marcingrzejszczak
Copy link
Collaborator Author

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.

@making
Copy link
Contributor

making commented Sep 25, 2024

@marcingrzejszczak can you please close this pr as #13 has already been merged.

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

Successfully merging this pull request may close these issues.

5 participants