Strimzi 0.32 adds OpenTelemetry at Kafka integration boundaries

A trace through a streaming system needs instrumentation at the boundaries where records enter and leave. Enabling an operator setting cannot describe every external connector or HTTP client by itself. Strimzi 0.32 adds OpenTelemetry support for Kafka Connect, MirrorMaker and the Kafka Bridge. The November 3 release makes that instrumentation available alongside Kafka 3.3.1 support.

The useful question is what each component actually traces. Strimzi's versioned tracing procedure gives separate answers. Those boundaries determine which parts of a data path become visible and which require instrumentation elsewhere.

I value Kafka's ability to let independent systems consume retained history. That independence also means the broker is only one part of an application's execution path. Tracing is useful when it names the instrumented interaction instead of implying that one configuration makes the whole distributed workflow observable.

Components initialize tracing in different places

The procedure says enabling tracing updates interceptor classes in the component's integrated producers and consumers. For MirrorMaker and Connect, a tracing agent initializes the tracer from the resource configuration. Bridge initializes its own tracer.

For MirrorMaker and MirrorMaker 2, traces record messages entering and leaving the replication component between source and target clusters. This identifies the component's part in the record path. It does not by itself instrument every application that produced the original record or later consumed its copy.

Connect traces messages that it produces and consumes through Kafka. The documentation explicitly requires tracing in the relevant connectors to observe traffic between Connect and external systems. A source connector reading another database and a sink connector writing elsewhere therefore need their own instrumentation for that external interaction.

Bridge traces its Kafka traffic and incoming HTTP requests from client applications. End-to-end HTTP visibility still requires the HTTP clients to participate. The boundary differs from Connect's, so using the same tracing type does not imply identical spans from every component.

The resource selects the tracing implementation

OpenTelemetry is selected through spec.tracing.type: opentelemetry. The component's container template supplies environment variables identifying the service and exporter endpoint. The following partial Connect configuration follows the versioned procedure.

spec:
  tracing:
    type: opentelemetry
  template:
    connectContainer:
      env:
        - name: OTEL_SERVICE_NAME
          value: example-connect
        - name: OTEL_EXPORTER_JAEGER_ENDPOINT
          value: http://jaeger-host:14250
        - name: OTEL_TRACES_EXPORTER
          value: jaeger

This fragment belongs inside an otherwise configured Connect resource. It does not deploy a tracing backend or define the connector workload. Its purpose is to separate the instrumentation selection from the destination to which spans are exported.

The 0.32 changelog says the new integration uses the Jaeger exporter by default for compatibility. The alternative-exporter procedure describes adding the necessary artifacts to the Kafka image and selecting the exporter through OTEL_TRACES_EXPORTER. Selecting another exporter can therefore involve image contents as well as an environment variable.

My preference is to keep those two requirements together in deployment documentation. A property naming an exporter does not establish that the required implementation exists in the image that runs the component.

Connector readiness becomes more informative

The release also changes KafkaConnector status. If the connector or any task reports a failed state, Strimzi adds a NotReady condition. Previously the resource could report Ready despite that failure. This corrects the relationship between the declarative resource's status and the workload it manages.

Tracing and readiness answer different operational questions. A trace describes activity through an instrumented path. A readiness condition summarizes whether the managed connector and its tasks have failed. The latter can identify a problem even when no useful traffic reaches the point that would generate a trace.

Operator permissions are split by responsibility

The changelog also splits the previous namespaced ClusterRole into two roles. Its new watched role contains permissions to watch and manage Strimzi custom resources. The namespaced role retains permissions for resources created from those definitions. A cluster-wide operator must receive the watched role at cluster level, while the other role can be granted in the namespaces where custom resources exist.

This gives an administrator a more specific permission arrangement to deploy. Updating the operator image without updating its role bindings would leave out part of the release's installation model. The scope of the watched resources and the scope of the generated workloads are related but distinct permission requirements.

Automation and supported versions change alongside tracing

Strimzi adds automatic approval when a KafkaRebalance optimization proposal is ready. That changes where the workflow can proceed without a separate approval action. The proposal and its readiness still exist as distinct steps in the documented capability.

The release requires Kubernetes 1.19 or later and removes Kafka 3.1.0, 3.1.1 and 3.1.2 support while adding 3.3.1. Those supported-version boundaries apply independently of enabling tracing. Within that environment, the OpenTelemetry addition provides explicit instrumentation at the integration components, with external connector and client traffic remaining separate instrumentation responsibilities.