KafkaChannel Tracing

[slinkydeveloper]

Fixes #1139

Proposed Changes

• 🎁 KafkaChannel now implements tracing

Release Note

KafkaChannel now correctly implements tracing using eventing-wise tracing configuration from config-tracing

[slinkydeveloper]

/assign @ian-mi

[slinkydeveloper]

Example of tracing from IMC:

KafkaChannel with this patch (same requests flow):

The obvious problem is that the span of inbound KafkaChannel ends when the message is inserted into the topic, and the dispatcher on the other side tries to rebuild the parent span using the ce attributes.

[ian-mi]

trace context propagation should probably happen regardless of whether events are recorded.

[slinkydeveloper]

I think what we do here is fine because it's similar to doing span.IsRecordingEvents(): if you're not recording the span, there is no need to do the hard lifting for writing the span and reading it from the other side.

[ian-mi]

Trace context is meant to be propagated regardless of sampling decision, otherwise there would be no need for a sampled flag. Here's zipkin's documentation on the reason for doing so: https://github.com/openzipkin/b3-propagation#why-send-trace-ids-with-a-reject-sampling-decision.

[matzew]

/lgtm

[slinkydeveloper]

During the CloudEvents WG meeting we just find out that this implementation is wrong, because it should not touch the ce-traceparent extension. We need to write this information in another cloudevent extension

[ian-mi]

During the CloudEvents WG meeting we just find out that this implementation is wrong, because it should not touch the ce-traceparent extension. We need to write this information in another cloudevent extension

I'm not sure what you mean by this, ce-traceparent is meant to be used for trace context propagation.

[slinkydeveloper]

I'm not sure what you mean by this, ce-traceparent is meant to be used for trace context propagation.

But the event creator should set it, middlewares should not touch it. I'll send you the link to the PR to the spec with the clarification discussed today during the meeting.

[slinkydeveloper]

I propose for now to unblock this PR adding a traceparent/tracestate header backed by us. When the spec clarifies the goals of DCE, we can go ahead and remove our code for traceparent/tracestate.

@ian-mi How do you propose to serialize/deserialize traceparent/tracestate without adding a new library? Should we revert the code we used to have in eventing? knative/eventing#2873

[slinkydeveloper]

Since now the spec is more specific, how do we want to proceed on this?

[slinkydeveloper]

/retest

[knative-metrics-robot]

The following is the coverage report on the affected files.
Say /test pull-knative-eventing-contrib-go-coverage to re-run this coverage report

File	Old Coverage	New Coverage	Delta
kafka/channel/pkg/dispatcher/dispatcher.go	62.6%	59.0%	-3.6
kafka/channel/pkg/dispatcher/tracing.go	Do not exist	91.7%

[matzew]

/lgtm
/approve

[knative-prow-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: matzew, slinkydeveloper

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [matzew,slinkydeveloper]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment