Package brave.messaging

Class MessagingTracing

    • Method Detail

      • tracing

        public Tracing tracing()
        Since:
        5.9

      • producerSampler

        public SamplerFunction<MessagingRequest> producerSampler()
        Returns an overriding sampling decision for a new trace. Defaults to ignore the request and use the trace ID instead.

        This decision happens when a trace was not yet started in process. For example, you may be making an messaging request as a part of booting your application. You may want to opt-out of tracing producer requests that did not originate from a consumer request.

        Since:
        5.9
        See Also:
        SamplerFunctions, MessagingRuleSampler

      • consumerSampler

        public SamplerFunction<MessagingRequest> consumerSampler()
        Returns an overriding sampling decision for a new trace. Defaults to ignore the request and use the trace ID instead.

        This decision happens when trace IDs were not in headers, or a sampling decision has not yet been made. For example, if a trace is already in progress, this function is not called. You can implement this to skip channels that you never want to trace.

        Since:
        5.9
        See Also:
        SamplerFunctions, MessagingRuleSampler

      • propagation

        public Propagation<String> propagation()
        Returns the propagation component used by messaging instrumentation.

        Typically, this is the same as Tracing.propagation(). Overrides will apply to all messaging instrumentation in use. For example, Kafka and also AMQP. If only trying to change B3 related headers, use the more efficient B3Propagation.FactoryBuilder.injectFormat(Span.Kind, B3Propagation.Format) instead.

        Use caution when overriding

        If overriding this via MessagingTracing.Builder.propagation(Propagation), take care to also delegate to Tracing.propagation(). Otherwise, you can break features something else may have set, such as BaggagePropagation.

        Library-specific formats

        Messaging instrumentation can localize propagation changes by calling toBuilder(), then MessagingTracing.Builder.propagation(Propagation). This allows library-specific formats.

        Example 1: Apache Camel

        Apache Camel has multiple trace instrumentation. Instead of using a single header like "b3" to avoid JMS propagation problems, their OpenTracing implementation replaces hyphens with "_$dash$_".

        For example, this would cause "X-B3-TraceId" to become "X_$dash$_B3_$dash$_TraceId". When normal instrumentation is on the other side, it would not guess to use this convention, and fail to resume the opentracing created trace.

        A custom propagation component used only for camel could tolerantly read this replacement format and write down the safe and more efficient B3Propagation.Format.SINGLE_NO_PARENT instead. It could do this with configuration, such as "opentracing compatibility" and not add the same overhead to other libraries.

        Example 2: Spring Messaging

        Spring Messaging is used for both in-memory and remote channels. Transports such as STOMP may require speculatively duplicating propagation fields as Native Headers.

        You could make a custom Propagation.RemoteSetter that takes into consideration if a message has native support or not, and add "native headers" only when needed by the message in use instead of adding headers to all messaging libraries. 

        
 SimpMessageHeaderAccessor accessor =
     MessageHeaderAccessor.getAccessor(message, SimpMessageHeaderAccessor.class);

 if (accessor != null) {
   // Add native headers..
 }
        Since:
        5.13
        See Also:
        Tracing.propagation()

      • current

        @Nullable
public static MessagingTracing current()
        Returns the most recently created tracing component iff it hasn't been closed. null otherwise.

        This object should not be cached.

        Since:
        5.9