CloudEvent Tracing Compliance

[travis-minke-sap]

The Knative Channel Specification specifies the expected behavior of handling W3C Tracecontext headers. The current implementation does NOT meet these requirements in that the traceparent and tracestate headers are lost in transmission. A completely new traceparent value is instead sent to the subscriber.

Currently, the Knative In-Memory Channel reference implementation DOES adhere to the specification, but the eventing-contrib/kafka implementation does not. Similar to this implementation the latter has the intermediate step of persisting to/from a Kafka Topic. There is currently confusion and a debate around the best way to handle this persistence, how it relates to the potential use of ce-traceparent and ce-tracestate, and where in the Knative / CloudEvent stack to handle this. Further, it is unclear whether the CloudEvents DTE Extension is useful or not.

See the following Github Issues/PRs for the history...

• Knative / CloudEvents
  • HTTP Transport Should Clear the CE Traceparent Extension knative/eventing#2918 & Clarification in Distributed Tracing Extension cloudevents/spec#603 & Reworked Distributed Tracing Extension cloudevents/spec#607
• eventing/in-memory
  • Tracing through InMemoryChannel knative/eventing#1757
• eventing-contrib/kafka
  • Implement tracing for KafkaChannel knative/eventing-contrib#1139 & KafkaChannel Tracing knative/eventing-contrib#1155
  • Tracing through KafkaChannel knative/eventing-contrib#563
• Previous Knative Implementation Removal
  • Remove Traceparent Extension Handling knative/eventing#2873

Therefore, we are going to wait until this is resolved before attempting to implement a solution that complies with the expected specification.

There are also larger tracing issue to be dealt with within the Knative Eventing ecosystem such as how to integrate Istio B3 Header usage with the current OpenTelemetry Headers. See knative/eventing#2581.

W3C Tracecontext Notes

• The traceparent field is composed of the following values...

  <version> - <traceid> - <parentid> - <flags>

...where the <version> (usually 00) specifies the format of the following data fields, and the <traceid> is the end-to-end ID of the entire trace through a distributed system. The <parentid> is also referred to as the <spanid>, and can/should change with each new HTTP Client Request being made. Therefore the expectation is that when the Channel receives an HTTP request with a traceparent header, that it is forwarded to the Subscriber with the same traceparent header, albeit with a new <parentid>.

[pbochynski]

Closing all issues as project is going to be archived. If it is still valid create a new issue in https://github.com/knative-sandbox/eventing-kafka