此内容没有您所选择的语言版本。

Chapter 11. Distributed tracing

This chapter outlines the support for distributed tracing in AMQ Streams, using Jaeger.

How you configure distributed tracing varies by AMQ Streams client and component.

You instrument Kafka Producer, Consumer, and Streams API applications for distributed tracing using an OpenTracing client library. This involves adding instrumentation code to these clients, which monitors the execution of individual transactions in order to generate trace data.
Distributed tracing support is built in to the Kafka Connect, MirrorMaker, and Kafka Bridge components of AMQ Streams. To configure these components for distributed tracing, you configure and update the relevant custom resources.

Before configuring distributed tracing in AMQ Streams clients and components, you must first initialize and configure a Jaeger tracer in the Kafka cluster, as described in Initializing a Jaeger tracer for Kafka clients.

Note

Distributed tracing is not supported for Kafka brokers.

11.1. Overview of distributed tracing in AMQ Streams

Distributed tracing allows developers and system administrators to track the progress of transactions between applications (and services in a microservice architecture) in a distributed system. This information is useful for monitoring application performance and investigating issues with target systems and end-user applications.

In AMQ Streams and data streaming platforms in general, distributed tracing facilitates the end-to-end tracking of messages: from source systems to the Kafka cluster and then to target systems and applications.

As an aspect of system observability, distributed tracing complements the metrics that are available to view in Grafana dashboards and the available loggers for each component.

OpenTracing overview

Distributed tracing in AMQ Streams is implemented using the open source OpenTracing and Jaeger projects.

The OpenTracing specification defines APIs that developers can use to instrument applications for distributed tracing. It is independent from the tracing system.

When instrumented, applications generate traces for individual transactions. Traces are composed of spans, which define specific units of work.

To simplify the instrumentation of the Kafka Bridge and Kafka Producer, Consumer, and Streams API applications, AMQ Streams includes the OpenTracing Apache Kafka Client Instrumentation library.

Note

The OpenTracing project is merging with the OpenCensus project. The new, combined project is named OpenTelemetry. OpenTelemetry will provide compatibility for applications that are instrumented using the OpenTracing APIs.

Jaeger overview

Jaeger, a tracing system, is an implementation of the OpenTracing APIs used for monitoring and troubleshooting microservices-based distributed systems. It consists of four main components and provides client libraries for instrumenting applications. You can use the Jaeger user interface to visualize, query, filter, and analyze trace data.

An example of a query in the Jaeger user interface

Simple Jaeger query

11.1.1. Distributed tracing support in AMQ Streams

In AMQ Streams, distributed tracing is supported in:

Kafka Connect (including Kafka Connect with Source2Image support)
MirrorMaker
The AMQ Streams Kafka Bridge

You enable and configure distributed tracing for these components by setting template configuration properties in the relevant custom resource (for example, KafkaConnect and KafkaBridge).

To enable distributed tracing in Kafka Producer, Consumer, and Streams API applications, you can instrument application code using the OpenTracing Apache Kafka Client Instrumentation library. When instrumented, these clients generate traces for messages (for example, when producing messages or writing offsets to the log).

Traces are sampled according to a sampling strategy and then visualized in the Jaeger user interface. This trace data is useful for monitoring the performance of your Kafka cluster and debugging issues with target systems and applications.

Outline of procedures

To set up distributed tracing for AMQ Streams, follow these procedures:

This chapter covers setting up distributed tracing for AMQ Streams clients and components only. Setting up distributed tracing for applications and systems beyond AMQ Streams is outside the scope of this chapter. To learn more about this subject, see the OpenTracing documentation and search for "inject and extract".

Before you start

Before you set up distributed tracing for AMQ Streams, it is helpful to understand:

The basics of OpenTracing, including key concepts such as traces, spans, and tracers. Refer to the OpenTracing documentation.
The components of the Jaeger architecure.

Prerequisites

The Jaeger backend components are deployed to your OpenShift cluster. For deployment instructions, see the Jaeger deployment documentation.

11.2. Setting up tracing for Kafka clients

This section describes how to initialize a Jaeger tracer to allow you to instrument your client applications for distributed tracing.

11.2.1. Initializing a Jaeger tracer for Kafka clients

Configure and initialize a Jaeger tracer using a set of tracing environment variables.

Procedure

Perform the following steps for each client application.

Add Maven dependencies for Jaeger to the pom.xml file for the client application:

<dependency>
    <groupId>io.jaegertracing</groupId>
    <artifactId>jaeger-client</artifactId>
    <version>1.1.0.redhat-00002</version>
</dependency>

Define the configuration of the Jaeger tracer using the tracing environment variables.
Create the Jaeger tracer from the environment variables that you defined in step two:
```
Tracer tracer = Configuration.fromEnv().getTracer();
```
Note
For alternative ways to initialize a Jaeger tracer, see the Java OpenTracing library documentation.
Register the Jaeger tracer as a global tracer:
```
GlobalTracer.register(tracer);
```

A Jaeger tracer is now initialized for the client application to use.

11.2.2. Tracing environment variables

Use these environment variables when configuring a Jaeger tracer for Kafka clients.

Note

The tracing environment variables are part of the Jaeger project and are subject to change. For the latest environment variables, see the Jaeger documentation.

Property	Required	Description
`JAEGER_SERVICE_NAME`	Yes	The name of the Jaeger tracer service.
`JAEGER_AGENT_HOST`	No	The hostname for communicating with the `jaeger-agent` through the User Datagram Protocol (UDP).
`JAEGER_AGENT_PORT`	No	The port used for communicating with the `jaeger-agent` through UDP.
`JAEGER_ENDPOINT`	No	The traces endpoint. Only define this variable if the client application will bypass the `jaeger-agent` and connect directly to the `jaeger-collector`.
`JAEGER_AUTH_TOKEN`	No	The authentication token to send to the endpoint as a bearer token.
`JAEGER_USER`	No	The username to send to the endpoint if using basic authentication.
`JAEGER_PASSWORD`	No	The password to send to the endpoint if using basic authentication.
`JAEGER_PROPAGATION`	No	A comma-separated list of formats to use for propagating the trace context. Defaults to the standard Jaeger format. Valid values are `jaeger` and `b3`.
`JAEGER_REPORTER_LOG_SPANS`	No	Indicates whether the reporter should also log the spans.
`JAEGER_REPORTER_MAX_QUEUE_SIZE`	No	The reporter’s maximum queue size.
`JAEGER_REPORTER_FLUSH_INTERVAL`	No	The reporter’s flush interval, in ms. Defines how frequently the Jaeger reporter flushes span batches.
`JAEGER_SAMPLER_TYPE`	No	The sampling strategy to use for client traces: Constant, Probabilistic, Rate Limiting, or Remote (the default type). To sample all traces, use the Constant sampling strategy with a parameter of 1. For more information, see the Jaeger documentation.
`JAEGER_SAMPLER_PARAM`	No	The sampler parameter (number).
`JAEGER_SAMPLER_MANAGER_HOST_PORT`	No	The hostname and port to use if a Remote sampling strategy is selected.
`JAEGER_TAGS`	No	A comma-separated list of tracer-level tags that are added to all reported spans. The value can also refer to an environment variable using the format `${envVarName:default}`. `:default` is optional and identifies a value to use if the environment variable cannot be found.

Additional resources

Section 11.2.1, “Initializing a Jaeger tracer for Kafka clients”

11.3. Instrumenting Kafka clients with tracers

This section describes how to instrument Kafka Producer, Consumer, and Streams API applications for distributed tracing.

11.3.1. Instrumenting Kafka Producers and Consumers for tracing

Use a Decorator pattern or Interceptors to instrument your Java Producer and Consumer application code for distributed tracing.

Procedure

Perform these steps in the application code of each Kafka Producer and Consumer application.

Add the Maven dependency for OpenTracing to the Producer or Consumer’s pom.xml file.

<dependency>
    <groupId>io.opentracing.contrib</groupId>
    <artifactId>opentracing-kafka-client</artifactId>
    <version>0.1.12.redhat-00001</version>
</dependency>

Instrument your client application code using either a Decorator pattern or Interceptors.

If you prefer to use a Decorator pattern, use following example:

// Create an instance of the KafkaProducer:
KafkaProducer<Integer, String> producer = new KafkaProducer<>(senderProps);

// Create an instance of the TracingKafkaProducer:
TracingKafkaProducer<Integer, String> tracingProducer = new TracingKafkaProducer<>(producer,
        tracer);

// Send:
tracingProducer.send(...);

// Create an instance of the KafkaConsumer:
KafkaConsumer<Integer, String> consumer = new KafkaConsumer<>(consumerProps);

// Create an instance of the TracingKafkaConsumer:
TracingKafkaConsumer<Integer, String> tracingConsumer = new TracingKafkaConsumer<>(consumer,
        tracer);

// Subscribe:
tracingConsumer.subscribe(Collections.singletonList("messages"));

// Get messages:
ConsumerRecords<Integer, String> records = tracingConsumer.poll(1000);

// Retrieve SpanContext from polled record (consumer side):
ConsumerRecord<Integer, String> record = ...
SpanContext spanContext = TracingKafkaUtils.extractSpanContext(record.headers(), tracer);

If you prefer to use Interceptors, use the following example:

// Register the tracer with GlobalTracer:
GlobalTracer.register(tracer);

// Add the TracingProducerInterceptor to the sender properties:
senderProps.put(ProducerConfig.INTERCEPTOR_CLASSES_CONFIG,
          TracingProducerInterceptor.class.getName());

// Create an instance of the KafkaProducer:
KafkaProducer<Integer, String> producer = new KafkaProducer<>(senderProps);

// Send:
producer.send(...);

// Add the TracingConsumerInterceptor to the consumer properties:
consumerProps.put(ConsumerConfig.INTERCEPTOR_CLASSES_CONFIG,
          TracingConsumerInterceptor.class.getName());

// Create an instance of the KafkaConsumer:
KafkaConsumer<Integer, String> consumer = new KafkaConsumer<>(consumerProps);

// Subscribe:
consumer.subscribe(Collections.singletonList("messages"));

// Get messages:
ConsumerRecords<Integer, String> records = consumer.poll(1000);

// Retrieve the SpanContext from a polled message (consumer side):
ConsumerRecord<Integer, String> record = ...
SpanContext spanContext = TracingKafkaUtils.extractSpanContext(record.headers(), tracer);

11.3.1.1. Custom span names in a Decorator pattern

A span is a logical unit of work in Jaeger, with an operation name, start time, and duration.

If you use a Decorator pattern to instrument your Kafka Producer and Consumer applications, you can define custom span names by passing a BiFunction object as an additional argument when creating the TracingKafkaProducer and TracingKafkaConsumer objects. The OpenTracing Apache Kafka Client Instrumentation library includes several built-in span names, which are described below.

Example: Using custom span names to instrument client application code in a Decorator pattern

// Create a BiFunction for the KafkaProducer that operates on (String operationName, ProducerRecord consumerRecord) and returns a String to be used as the name:

BiFunction<String, ProducerRecord, String> producerSpanNameProvider =
    (operationName, producerRecord) -> "CUSTOM_PRODUCER_NAME";

// Create an instance of the KafkaProducer:
KafkaProducer<Integer, String> producer = new KafkaProducer<>(senderProps);

// Create an instance of the TracingKafkaProducer
TracingKafkaProducer<Integer, String> tracingProducer = new TracingKafkaProducer<>(producer,
        tracer,
        producerSpanNameProvider);

// Spans created by the tracingProducer will now have "CUSTOM_PRODUCER_NAME" as the span name.

// Create a BiFunction for the KafkaConsumer that operates on (String operationName, ConsumerRecord consumerRecord) and returns a String to be used as the name:

BiFunction<String, ConsumerRecord, String> consumerSpanNameProvider =
    (operationName, consumerRecord) -> operationName.toUpperCase();

// Create an instance of the KafkaConsumer:
KafkaConsumer<Integer, String> consumer = new KafkaConsumer<>(consumerProps);

// Create an instance of the TracingKafkaConsumer, passing in the consumerSpanNameProvider BiFunction:

TracingKafkaConsumer<Integer, String> tracingConsumer = new TracingKafkaConsumer<>(consumer,
        tracer,
        consumerSpanNameProvider);

// Spans created by the tracingConsumer will have the operation name as the span name, in upper-case.
// "receive" -> "RECEIVE"

11.3.1.2. Built-in span names

When defining custom span names, you can use the following BiFunctions in the ClientSpanNameProvider class. If no spanNameProvider is specified, CONSUMER_OPERATION_NAME and PRODUCER_OPERATION_NAME are used.

BiFunction	Description
`CONSUMER_OPERATION_NAME, PRODUCER_OPERATION_NAME`	Returns the `operationName` as the span name: "receive" for Consumers and "send" for Producers.
`CONSUMER_PREFIXED_OPERATION_NAME(String prefix), PRODUCER_PREFIXED_OPERATION_NAME(String prefix)`	Returns a String concatenation of `prefix` and `operationName`.
`CONSUMER_TOPIC, PRODUCER_TOPIC`	Returns the name of the topic that the message was sent to or retrieved from in the format `(record.topic())`.
`PREFIXED_CONSUMER_TOPIC(String prefix), PREFIXED_PRODUCER_TOPIC(String prefix)`	Returns a String concatenation of `prefix` and the topic name in the format `(record.topic())`.
`CONSUMER_OPERATION_NAME_TOPIC, PRODUCER_OPERATION_NAME_TOPIC`	Returns the operation name and the topic name: `"operationName - record.topic()"`.
`CONSUMER_PREFIXED_OPERATION_NAME_TOPIC(String prefix), PRODUCER_PREFIXED_OPERATION_NAME_TOPIC(String prefix)`	Returns a String concatenation of `prefix` and `"operationName - record.topic()"`.

11.3.2. Instrumenting Kafka Streams applications for tracing

This section describes how to instrument Kafka Streams API applications for distributed tracing.

Procedure

Perform the following steps for each Kafka Streams API application.

Add the opentracing-kafka-streams dependency to the pom.xml file for your Kafka Streams API application:

<dependency>
    <groupId>io.opentracing.contrib</groupId>
    <artifactId>opentracing-kafka-streams</artifactId>
    <version>0.1.12.redhat-00001</version>
</dependency>

Create an instance of the TracingKafkaClientSupplier supplier interface:

KafkaClientSupplier supplier = new TracingKafkaClientSupplier(tracer);

Provide the supplier interface to KafkaStreams:

KafkaStreams streams = new KafkaStreams(builder.build(), new StreamsConfig(config), supplier);
streams.start();

11.4. Setting up tracing for MirrorMaker, Kafka Connect, and the Kafka Bridge

Distributed tracing is supported for MirrorMaker, Kafka Connect (including Kafka Connect with Source2Image support), and the AMQ Streams Kafka Bridge.

Tracing in MirrorMaker

For MirrorMaker, messages are traced from the source cluster to the target cluster; the trace data records messages entering and leaving the MirrorMaker component.

Tracing in Kafka Connect

Only messages produced and consumed by Kafka Connect itself are traced. To trace messages sent between Kafka Connect and external systems, you must configure tracing in the connectors for those systems. For more information, see Section 3.2, “Kafka Connect cluster configuration”.

Tracing in the Kafka Bridge

Messages produced and consumed by the Kafka Bridge are traced. Incoming HTTP requests from client applications to send and receive messages through the Kafka Bridge are also traced. In order to have end-to-end tracing, you must configure tracing in your HTTP clients.

11.4.1. Enabling tracing in MirrorMaker, Kafka Connect, and Kafka Bridge resources

Update the configuration of KafkaMirrorMaker, KafkaConnect, KafkaConnectS2I, and KafkaBridge custom resources to specify and configure a Jaeger tracer service for each resource. Updating a tracing-enabled resource in your OpenShift cluster triggers two events:

Interceptor classes are updated in the integrated consumers and producers in MirrorMaker, Kafka Connect, or the AMQ Streams Kafka Bridge.
For MirrorMaker and Kafka Connect, the tracing agent initializes a Jaeger tracer based on the tracing configuration defined in the resource.
For the Kafka Bridge, a Jaeger tracer based on the tracing configuration defined in the resource is initialized by the Kafka Bridge itself.

Procedure

Perform these steps for each KafkaMirrorMaker, KafkaConnect, KafkaConnectS2I, and KafkaBridge resource.

In the spec.template property, configure the Jaeger tracer service. For example:

Jaeger tracer configuration for Kafka Connect

apiVersion: kafka.strimzi.io/v1beta1
kind: KafkaConnect
metadata:
  name: my-connect-cluster
spec:
  #...
  template:
    connectContainer: 1
      env:
        - name: JAEGER_SERVICE_NAME
          value: my-jaeger-service
        - name: JAEGER_AGENT_HOST
          value: jaeger-agent-name
        - name: JAEGER_AGENT_PORT
          value: "6831"
  tracing: 2
    type: jaeger
  #...

Jaeger tracer configuration for MirrorMaker

apiVersion: kafka.strimzi.io/v1beta1
kind: KafkaMirrorMaker
metadata:
  name: my-mirror-maker
spec:
  #...
  template:
    mirrorMakerContainer:
      env:
        - name: JAEGER_SERVICE_NAME
          value: my-jaeger-service
        - name: JAEGER_AGENT_HOST
          value: jaeger-agent-name
        - name: JAEGER_AGENT_PORT
          value: "6831"
  tracing:
    type: jaeger
#...

Jaeger tracer configuration for the Kafka Bridge

apiVersion: kafka.strimzi.io/v1beta1
kind: KafkaBridge
metadata:
  name: my-bridge
spec:
  #...
  template:
    bridgeContainer:
      env:
        - name: JAEGER_SERVICE_NAME
          value: my-jaeger-service
        - name: JAEGER_AGENT_HOST
          value: jaeger-agent-name
        - name: JAEGER_AGENT_PORT
          value: "6831"
  tracing:
    type: jaeger
#...

1: Use the tracing environment variables as template configuration properties.
2: Set the spec.tracing.type property to jaeger.

Create or update the resource:
```
oc apply -f your-file
```

Additional resources

此内容没有您所选择的语言版本。

Chapter 11. Distributed tracing

11.1. Overview of distributed tracing in AMQ Streams

11.1.1. Distributed tracing support in AMQ Streams

11.2. Setting up tracing for Kafka clients

11.2.1. Initializing a Jaeger tracer for Kafka clients

11.2.2. Tracing environment variables

11.3. Instrumenting Kafka clients with tracers

11.3.1. Instrumenting Kafka Producers and Consumers for tracing

11.3.1.1. Custom span names in a Decorator pattern

11.3.1.2. Built-in span names

11.3.2. Instrumenting Kafka Streams applications for tracing

11.4. Setting up tracing for MirrorMaker, Kafka Connect, and the Kafka Bridge

11.4.1. Enabling tracing in MirrorMaker, Kafka Connect, and Kafka Bridge resources

学习

尝试、购买和销售

社区

关于红帽文档

让开源更具包容性

關於紅帽

Red Hat legal and privacy links

Red Hat legal and privacy links