Strimzi removes OpenTracing and changes connector retries

An operator upgrade can change behavior without any corresponding edit to an application resource. Strimzi 0.37.0, released September 6, contains two examples. OpenTracing configuration is no longer supported, and enabled connector auto-restarts continue indefinitely unless a maximum is configured. Both changes affect the processes that move data around Kafka, where a healthy broker alone does not establish that downstream work is progressing.

The tracing removal applies to Kafka Connect, both MirrorMaker resource types, and the Kafka Bridge. Their tracing.type: jaeger setting is unsupported in this release. The supported setting is tracing.type: opentelemetry. Separately, auto-restart remains an opt-in capability. The new unlimited default applies when automatic restart is enabled, rather than enabling restarts for every connector automatically.

I value the ability to feed independent systems from retained Kafka history. Connector failures are therefore part of how I judge the usefulness of that history. A topic can remain available while a destination stops receiving records. Observability and recovery policy need to describe that distinction clearly enough that an operator can identify which part of the data flow has stopped.

The tracing implementation changes

The tagged changelog records the earlier transition. OpenTracing-based Jaeger support was deprecated in Strimzi 0.31, and OpenTelemetry support arrived in the following releases. The removal in 0.37 finishes that compatibility period. An old tracing setting is consequently an upgrade input that needs attention, even if the connector configuration and its Kafka topics remain unchanged.

This migration concerns the tracing implementation selected by Strimzi. The old configuration value included a backend's name, which can make the removal sound like a ban on that backend. Earlier changelog entries describe OpenTelemetry exporting through OTLP and note that a sufficiently recent Jaeger backend can accept OTLP. The implementation and the destination of trace data are separate decisions. An installation needs a compatible exporter endpoint as well as the supported resource setting.

The 0.37 deployment guide shows how those decisions appear in a Kafka Connect resource. This fragment belongs inside an otherwise complete KafkaConnect.spec configuration.

tracing:
  type: opentelemetry
template:
  connectContainer:
    env:
      - name: OTEL_SERVICE_NAME
        value: order-connect
      - name: OTEL_EXPORTER_OTLP_ENDPOINT
        value: "http://otel-collector:4317"

The endpoint in this example names the installation's OTLP receiver. Changing the enum value while retaining an endpoint intended for another exporter does not express a complete migration. The guide supplies equivalent container environment settings for the other supported resource types, with the template location appropriate to each process.

Application instrumentation remains another part of the trace. The guide describes instrumentation for producer and consumer applications, including wrappers and interceptors. Enabling tracing on a managed Connect process does not automatically instrument every independent application that writes or reads its topics. The configuration boundary matters when interpreting an incomplete trace through a streaming system.

Retries continue after the old stopping point

Before this release, enabled connector auto-restart stopped after seven restarts. Strimzi 0.37 removes that implicit maximum. A resource that previously relied on the default can therefore keep retrying a failed connector after it would formerly have required intervention. The release notes provide maxRestarts: 7 as the explicit way to retain the previous limit.

For an existing KafkaConnector, the relevant fragment under spec is small.

autoRestart:
  enabled: true
  maxRestarts: 7

Omitting maxRestarts while leaving enabled: true selects the new unlimited behavior. The configuration reference defines the setting for failed connectors and tasks. If the maximum is reached and the connector still fails, the user must restart it manually. For MirrorMaker 2, the setting belongs to the connector configuration within its mirrors, so it can describe the recovery policy of the relevant replication connector.

Unlimited attempts do not mean a tight loop. The reference describes an increasing delay calculated as n * n + n minutes, where n is the number of previous restarts. This interval caps at 60 minutes. An initial attempt is immediate, and later attempts become farther apart until they reach that cap. This preserves an opportunity to recover from a dependency that remains unavailable beyond the old stopping point.

The policy cannot determine whether the failure is transient. Retrying a connector with invalid credentials does not repair those credentials. It does change what happens after someone repairs them, because another automatic attempt can occur without a separate manual restart. A finite limit chooses a different operational arrangement, with explicit intervention after the configured attempts are exhausted.

I prefer to make that arrangement visible in the resource when a fixed stopping point matters. Kafka's replay model provides a reason to resume processing after a destination returns, but it does not decide how long an operator should keep attempting recovery. The new setting lets that decision be expressed directly instead of inherited from the previous default.

The reference also exposes restart status, including the attempt count and last restart timestamp. Those fields distinguish an operator that is still attempting recovery from one whose configured limit has been reached. Together with the supported tracing path, they provide evidence about the connector process around the log. The September upgrade changes how that evidence is produced and how long automatic recovery remains active for an unchanged enabled resource.