Some time ago @paullatzelsperger suggested a workaround in order to be able to use the proprietary Azure OpenTelemetry Distro instead of the provided one. The background is, that, to my knowledge, the usage of the proprietary distro is the recommended approach on Azure.
The suggested workaround, basically consisting of a Docker multistage build, simply overwriting the opentelemetry-javaagent.jar with the applicationsinsights-agent.jar to match "-javaagent:/app/opentelemetry-javaagent.jar" without the need to overwrite the Docker entrypoint, worked fine until Microsoft released 3.5.x-version of their OpenTelemetry Distro.
The problem now is that I get a java.lang.NoClassDefFoundError: io/prometheus/metrics/model/registry/MultiCollector. I can only guess that Microsoft doesn't provide the Prometheus dependencies anymore, as they're using their own exporter, or that they now started to heed the system property "-Dotel.metrics.exporter=prometheus" from now on, which is part of the Docker entrypoint command line, or whatever.
My question:
Is there a reason that the Docker files specify these values as system properties, fixing OTEL to Prometheus?
The problem with that is that the system properties take precedence, so I'm not able to change that part without overwriting the Dockerfile entrypoint, which I would like to avoid in order to avoid checking the official Dockerfiles for each release if something changed.
If these are passed via environment variables, I would be able to overwrite these configuration values.
Some time ago @paullatzelsperger suggested a workaround in order to be able to use the proprietary Azure OpenTelemetry Distro instead of the provided one. The background is, that, to my knowledge, the usage of the proprietary distro is the recommended approach on Azure.
The suggested workaround, basically consisting of a Docker multistage build, simply overwriting the opentelemetry-javaagent.jar with the applicationsinsights-agent.jar to match "-javaagent:/app/opentelemetry-javaagent.jar" without the need to overwrite the Docker entrypoint, worked fine until Microsoft released 3.5.x-version of their OpenTelemetry Distro.
The problem now is that I get a java.lang.NoClassDefFoundError: io/prometheus/metrics/model/registry/MultiCollector. I can only guess that Microsoft doesn't provide the Prometheus dependencies anymore, as they're using their own exporter, or that they now started to heed the system property "-Dotel.metrics.exporter=prometheus" from now on, which is part of the Docker entrypoint command line, or whatever.
My question: Is there a reason that the Docker files specify these values as system properties, fixing OTEL to Prometheus?
The problem with that is that the system properties take precedence, so I'm not able to change that part without overwriting the Dockerfile entrypoint, which I would like to avoid in order to avoid checking the official Dockerfiles for each release if something changed. If these are passed via environment variables, I would be able to overwrite these configuration values.