Skip to content

Kafka consumer client does not inherit service name #709

Closed

Description

@ffalexandererben

The Kafka consumer client instrumentation uses a hardcoded service name kafka and does not inherit the service name.
I think it should inherit the service name given via environment or vm property - maybe this behaviour should even be configurable.
It's possible to work around this issue by using dd.service.mapping, but that is only a workaround in my opinion.

Activity

  1. tylerbenson commented on Feb 15, 2019

    @tylerbenson
    Contributor

    In my opinion, it should probably be kafka for the producer but use the configured service name for the consumer. What do you think?

  2. ffalexandererben commented on Feb 15, 2019

    @ffalexandererben
    Author

    I agree, that makes sense.

    Just one thought on the consequences if the service name for Kafka consume traces is changed to the configured service name: The operation name kafka.consume might cause a problem for services that also have a HTTP interface, where the dominant trace operation name will be servlet.request or express.request or whatever framework is used. As fas as I'm aware, selecting operation names in the APM UI is still a beta feature, so the consume traces will not be shown in the UI for the service (or the other way around if the Kafka traces are more frequent).

    But this is a problem for the current state of the Kafka instrumentation as well: Produce traces and consume traces cannot show up at the same time in the UI without the operation selector available - the most active operation wins as it is the primary operation in terms of the statistics.

  3. matt-canty-dragon commented on Dec 19, 2019

    @matt-canty-dragon

    But this is a problem for the current state of the Kafka instrumentation as well: Produce traces and consume traces cannot show up at the same time in the UI without the operation selector available - the most active operation wins as it is the primary operation in terms of the statistics.

    @ffalexandererben I am curious as to what you would recommend at this time? I am in a position right now where I should choose a path:

    1. Do nothing, live with the issue until a resolution is released.
    2. Map service kafka to service-name
    3. Map service kafka to service-name-kafka (or service-name-kafka-client) current preference

    Rationale for number 3 is:

    1. We avoid the service-type contention between HTTP and Kafka interfaces.
    2. We get the additional information on the UI as to which service is consuming.

    The implications of implementing 2 or 3 will mean that once this is resolved there will inevitably be some cleanup too.

    Note that RabbitMQ consumer uses service name already.

  4. ffalexandererben commented on Dec 19, 2019

    @ffalexandererben
    Author

    We ended up using the second option as it best fits our needs. To do this, you do not have to implement anything and just use dd.service.mapping as stated above. Same goes for option three by the way. You can just try either option without much work involved.

  5. matt-canty-dragon commented on Dec 19, 2019

    @matt-canty-dragon

    Do your services also have HTTP endpoints? I think this is the clincher for 3 over 2 specifically.

  6. ffalexandererben commented on Dec 19, 2019

    @ffalexandererben
    Author

    They do, but we just use the span type selector in the UI. We got used to it, but it's far from ideal. But we have more than 120 services in production and almost every one of them uses Kafka. Having separate services for the Kafka integration would double the number of services to 240, which would be even more unwieldy.

  7. bobthearsonist commented on Apr 22, 2022

    @bobthearsonist

    just stumbled upon this still-open request. the dotnet tracers appear to already prpend with the service name ie servicename-kafka, is the java tracer ever going to be updated to do this by default?

  8. mcculls commented on Apr 22, 2022

    @mcculls
    Contributor

    If you set the following system property on both the producing and consuming sides:

    -Ddd.kafka.legacy.tracing.enabled=false
    

    then the consume span will now have the local servicename and a new span will be added between the producer and consumer to represent the "time-in-queue" for the message. This new "time-in-queue" span will have a service name of "kafka", and sits between the producing service name and consuming service name in the service map.

  9. samsaggace commented on Nov 8, 2022

    @samsaggace

    Thanks so much for this awesome feature, it's super powerful !

    Is there a documentation that lists of all the other "non-legacy" features that can be activated to improve the experience ?
    I'm so eager to test them all !!! 😄

    Thanks again

  10. bm1549 commented on Nov 17, 2023

    @bm1549
    Collaborator

    @samsaggace we don't have a comprehensive document, but they are searchable in the repository itself. Please be careful about using these as they may introduce breaking changes

    https://github.com/search?q=repo%3ADataDog%2Fdd-trace-java+isLegacyTracingEnabled%28true&type=code

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions