Summary

The Strimzi image bundles OpenTelemetry 1.34.1 via kafka-thirdparty-libs, while the AutoMQ Kafka tarball ships OpenTelemetry 1.40.0. Both sets of jars end up in the flat /opt/kafka/libs/ directory, causing version conflicts at runtime.

Related Issues

• [BUG] Kafka broker fails to start when enabling OTLP HTTP metrics exporter #3111 — Original bug: AbstractMethodError in OkHttpHttpSenderProvider when OTLP HTTP exporter is enabled
• fix: add missing jdk http sender for otlp metrics exporter #3124 — Workaround: excluded sender-okhttp, added sender-jdk in AutoMQ
• [BUG] OTLP gRPC metrics exporter crashes on startup — GrpcSenderProvider missing from classpath #3217 — Regression: gRPC protocol crashes because GrpcSenderProvider was removed along with sender-okhttp
• fix: Prevent broker startup crash when using GRPC for metrics to prevent broker crash #3252 — Fix: re-introduces sender-okhttp in AutoMQ (correct for AutoMQ standalone, but doesn't address the Strimzi conflict)

Root Cause

The Strimzi image build (AutoMQ/strimzi-kafka-operator) copies all jars into /opt/kafka/libs/:

When two versions of the same OTel artifact coexist on the classpath, the JVM may load a class from one version and an interface from another. Specifically:

1. HttpExporterBuilder (1.40.0) calls HttpSenderProvider.createSender(...) with the 1.40.0 method signature
2. ServiceLoader may resolve OkHttpHttpSenderProvider from the 1.34.1 jar (or vice versa)
3. The method signature changed between 1.34.1 and 1.40.0 → AbstractMethodError

The find-classpath-collision.sh script in Strimzi catches class-level collisions but not same-artifact version mismatches, so this slips through the build.

Why previous fixes were incomplete

• fix: add missing jdk http sender for otlp metrics exporter #3124 excluded sender-okhttp and added sender-jdk in AutoMQ to avoid the AbstractMethodError. This worked for protocol=http but broke protocol=grpc because GrpcSenderProvider is only provided by sender-okhttp.
• fix: Prevent broker startup crash when using GRPC for metrics to prevent broker crash #3252 re-introduces sender-okhttp in AutoMQ, which is correct for standalone AutoMQ. But in the Strimzi environment, the version mismatch between AutoMQ's 1.40.0 jars and Strimzi's 1.34.1 jars remains the root cause.

The real fix needs to happen in AutoMQ/strimzi-kafka-operator's kafka-thirdparty-libs/pom.xml.

Proposed Fixes (in strimzi-kafka-operator)

Option A: Upgrade OTel version to match AutoMQ (minimal change)

Align kafka-thirdparty-libs/3.9.x/pom.xml and 4.0.x/pom.xml to 1.40.0:

<opentelemetry.version>1.40.0</opentelemetry.version>
<opentelemetry-alpha.version>1.40.0-alpha</opentelemetry-alpha.version>

• Pros: minimal diff, both sides use the same version, no behavioral change.
• Cons: still ships duplicate jars (one from AutoMQ tarball, one from thirdparty-libs). Needs to be re-aligned whenever AutoMQ upgrades OTel.

Option B: Remove duplicate OTel dependencies from thirdparty-libs (thorough)

Since the AutoMQ tarball already ships a complete set of OTel jars (sdk, exporters, senders), the thirdparty-libs pom.xml should stop declaring them. Only keep what AutoMQ does not provide (e.g., opentelemetry-kafka-clients-2.6 for Strimzi tracing, opentelemetry-sdk-extension-autoconfigure).

<!-- Remove these from pom.xml (already in AutoMQ tarball): -->
<!-- opentelemetry-exporter-otlp -->
<!-- opentelemetry-exporter-sender-jdk -->
<!-- opentelemetry-exporter-sender-grpc-managed-channel -->
<!-- grpc-netty-shaded -->

<!-- Keep these (Strimzi-specific, not in AutoMQ tarball): -->
<!-- opentelemetry-sdk-extension-autoconfigure -->
<!-- opentelemetry-kafka-clients-2.6 -->

• Pros: eliminates duplication at the source, no version drift risk.
• Cons: larger change, requires verifying exactly which OTel jars the AutoMQ tarball provides. Strimzi's tracing agent dependencies (autoconfigure, kafka-clients-2.6) may also need version alignment.

Environment

• AutoMQ OTel SDK version: 1.40.0 (gradle/dependencies.gradle)
• Strimzi thirdparty-libs OTel version: 1.34.1 (kafka-thirdparty-libs/3.9.x/pom.xml and 4.0.x/pom.xml)