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

Automatic trace continuation #72

Open
cykl opened this issue Mar 16, 2020 · 2 comments
Open

Automatic trace continuation #72

cykl opened this issue Mar 16, 2020 · 2 comments

Comments

@cykl
Copy link

cykl commented Mar 16, 2020

Current TracingKafkaConsumer behaviour is to override Consumer#poll to:

  • create very short lived consumer spans before returning all the records to the caller.
  • inject span context into record headers to allow trace continuation.

Continuing a trace requires some boilerplate (see https://github.com/PacktPublishing/Mastering-Distributed-Tracing/tree/master/Chapter05 or #59) and seems a frequent use case.

I believe automatic trace continuation is possible and would provide a better developer experience. Basically, we could subclass ConsumerRecords to create a consumer span when client ask for the next record and finish it on subsequent hasNext invocation.

As trace continuation should be optional, we could set a tracing policy using TracingKafkaConsummerBuilder. Current behaviour could be kept as-is or reimplemented using the same mecanism. Spans would be finished immediately rather than waiting for the next invocation. Start times would differ but I don't know which is better.

Ideally, I had like to be able to decide whether producer span is a parent or only a reference/link to force a new sampling decision. However, it seems only possible with OpenTelemetry not OpenTracing.

I will likely give this idea a try. @malafeev @yurishkuro Any thoughts or experience to share?

@rquinio
Copy link

rquinio commented May 4, 2020

Hi, I'm trying to understand why consumer spans were designed this way (finished on creation).
From my naive perspective I'd expect the consumer span to be finished only when offset commit is acknowledged and so it would encompass any processing and there would be no need for automatic continuation...
Is this a limitation of Kafka APIs/threading model that #poll and #commit are executed in different threads, so it's no possible to keep track of span+offset status in a ThreadLocal ?

@malafeev
Copy link
Contributor

malafeev commented May 4, 2020

yes, one issue is that #poll and #commit are executed in different threads, another that #poll returns several messages and for each message new consumer span is created because each message can be from different producer.

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

No branches or pull requests

3 participants