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

Pulsar: use span links when receive telemetry is enabled #10650

Merged
merged 8 commits into from
Apr 10, 2024

Conversation

laurit
Copy link
Contributor

@laurit laurit commented Feb 23, 2024

Resolves #8859
Supersedes #8909
This PR alters spans produced by pulsar instrumentation to behave similarly to kafka instrumentation. If receive-telemetry is enabled place producer and consumer spans in different traces that are connected via span links. If receive-telemetry is not enabled place producer and consumer in the same trace and don't create receive span if the trace contains a process span.

@laurit laurit requested a review from a team February 23, 2024 07:47
@@ -87,24 +99,28 @@ private static Instrumenter<PulsarBatchRequest, Void> createConsumerBatchReceive
createMessagingAttributesExtractor(getter, MessageOperation.RECEIVE))
.addAttributesExtractor(
ServerAttributesExtractor.create(new PulsarNetClientAttributesGetter()))
.setEnabled(ExperimentalConfig.get().messagingReceiveInstrumentationEnabled())
Copy link
Contributor Author

Choose a reason for hiding this comment

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

spring kafka instrumentation also produces telemetry with span links for the batch receive scenario that can't be modeled with just parent child relationships

span ->
span.hasName(topic + " receive")
.hasKind(SpanKind.CONSUMER)
.hasParent(trace.getSpan(1))
.hasNoParent()
.hasLinks(LinkData.create(producerSpan.get().getSpanContext()))
Copy link
Contributor Author

Choose a reason for hiding this comment

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

I think this deviates a bit from kafka, here we place the span link on both receive and process spans but kafka places it only on the process span.

Copy link
Contributor

@breedx-splk breedx-splk left a comment

Choose a reason for hiding this comment

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

This looks good to me. I had a couple of questions and a few small things I think could help improve readability....but otherwise seems nice a solid change.

List<AttributeAssertion> assertions =
new ArrayList<>(
Arrays.asList(
equalTo(SemanticAttributes.MESSAGING_SYSTEM, "pulsar"),
Copy link
Contributor

Choose a reason for hiding this comment

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

Static imports for improved readability.

.hasParent(trace.getSpan(1))));
}

static List<AttributeAssertion> sendAttributes(
Copy link
Contributor

Choose a reason for hiding this comment

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

The method name doesn't match the behavior. Maybe something more like makeSendAttributeAssertions() or even sendAttrAssertions() or something.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The same pattern is used in kafka tests. In my opinion it is fine, these methods are only used in tests and attributes vs attribute assertions isn't a big difference.

return receiveAttributes(destination, messageId, testHeaders, false);
}

static List<AttributeAssertion> receiveAttributes(
Copy link
Contributor

Choose a reason for hiding this comment

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

Same comment about the name. Maybe makeReceiveAttrAssertions().

Comment on lines +181 to +187
consumer =
client
.newConsumer(Schema.STRING)
.subscriptionName("test_sub")
.topic(topic)
.subscriptionInitialPosition(SubscriptionInitialPosition.Earliest)
.subscribe();
Copy link
Contributor

Choose a reason for hiding this comment

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

Wait, where does the "receive with timeout" part factor into this test? I'm not seeing it. If it's there, perhaps a comment can help to clarify, because a reader doesn't immediately see how the receive-with-timeout is wired up.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I presume it is consumer.receive(1, TimeUnit.MINUTES);

@laurit laurit merged commit 3b7c225 into open-telemetry:main Apr 10, 2024
49 checks passed
@laurit laurit deleted the pulsar-span-links branch April 10, 2024 08:05
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.

Flag for Span Links not working for Pulsar
3 participants