Instrumentation for spring integration about spring-cloud-sleuth HOT 2 CLOSED

The security context interceptor is a good building block: it keeps the thread context up to date when Spring Integration hands off between threads. Missing are:

• "the identification problem". Creating the span on an incoming message (question: how to identify incoming messages, as opposed to any old message that is in flight and not being sampled?)
• "the headers problem" Ensuring that the span headers are propagated through all external middleware. Problem here is that they are all different, e.g. JMS has headers and by default copies all headers, AMQP has headers and doesn't, Redis and Kafka do not have headers.
• "the sampling problem". How to signal to a downstream service that the message is not being sampled (and that the decision was already made)?
• "the common data model problem". How to align with the "common data model" that Pivotal is pushing. With HTTP we know a lot about the transport when we first set up a trace. In a messaging app we may know less or nothing (e.g. did it come from Rabbit, Redis, etc? What was the broker address?).

from spring-cloud-sleuth.

This one is closeable (all problems addressed in some way). The "common data model" is an ongoing effort so additional issues can be raised against that as necessary.

from spring-cloud-sleuth.