Uploaded image for project: 'Debezium'
  1. Debezium
  2. DBZ-559

Add support for distributed tracing

XMLWordPrintable

    • Icon: Enhancement Enhancement
    • Resolution: Done
    • Icon: Major Major
    • 1.4.0.Beta1
    • None
    • core-library
    • None

      Larger MSA application deployments usually need a support of distributed tracing for monitoring and troubleshooting.

      We should provide a support for distributed tracing via OpenTracing API and verify that it works with Jaeger.

      We should implement this functionality in extensible way so if a customer wants to use Zipkin instead of OpenTracing the he would be able to inject its own class to implement it.

            [DBZ-559] Add support for distributed tracing

            Debezium Builder added a comment -

            Released

            Debezium Builder added a comment - Released

            Gunnar Morling added a comment -

            jpechane, resolving it in preparation of the release. Still need doc update though for the outbox routing SMT, the outbox Quarkus extension and the new SMT.

            Gunnar Morling added a comment - jpechane , resolving it in preparation of the release. Still need doc update though for the outbox routing SMT, the outbox Quarkus extension and the new SMT.

            Gunnar Morling added a comment -

            IMHO we need to include in the context the metadata from transaction

            jpechane, good point. I think this becomes more realistically doable now with our Quarkus outbox extension. I've logged DBZ-1818 for that.

            Gunnar Morling added a comment - IMHO we need to include in the context the metadata from transaction jpechane , good point. I think this becomes more realistically doable now with our Quarkus outbox extension. I've logged DBZ-1818 for that.

            Jiri Pechanec added a comment - - edited

            Yes and no - IMHO we need to include in the context the metadata from transaction - ideally txid. So if KC support will allow us to provide data for the context then yes, it is completed. If not then we should manage the tracing on our own.

            Also this article is using Zipkin. We should move towards OpenTracing. But this is a a great intro to the problem at hand.

            Jiri Pechanec added a comment - - edited Yes and no - IMHO we need to include in the context the metadata from transaction - ideally txid. So if KC support will allow us to provide data for the context then yes, it is completed. If not then we should manage the tracing on our own. Also this article is using Zipkin. We should move towards OpenTracing. But this is a a great intro to the problem at hand.

            Gunnar Morling added a comment -

            Didn't read the article yet, but it seems we might just be able to benefit from tracing support built into KC itself?

            Gunnar Morling added a comment - Didn't read the article yet, but it seems we might just be able to benefit from tracing support built into KC itself?

            Jiri Pechanec added a comment -

            A case for tracing - https://www.confluent.io/blog/importance-of-distributed-tracing-for-apache-kafka-based-applications

            Jiri Pechanec added a comment - A case for tracing - https://www.confluent.io/blog/importance-of-distributed-tracing-for-apache-kafka-based-applications

              Unassigned Unassigned
              jpechane Jiri Pechanec
              Votes:
              1 Vote for this issue
              Watchers:
              4 Start watching this issue

                Created:
                Updated:
                Resolved: