The Problem Many Developers Faced
When monitoring Java apps in Middleware APM, each microservice should appear with its own unique name. That makes it easy to trace requests, debug latency, and understand which service is causing issues.
But many developers noticed something odd:
- Their services showed up in the APM screen,
- Yet the service name wasn’t reflecting correctly.
By default, the metadata injector does not set the “OTEL_SERVICE_NAME”.
Earlier, Middleware relied on a custom flag (MW_SERVICE_NAME) for Java apps.
That meant extra configuration steps — and confusion — for developers using OpenTelemetry.
What’s New in v1.8.0
We listened to your feedback and simplified the flow.
In the latest Java APM Agent (v1.8.0):
- “OTEL_SERVICE_NAME” is now the preferred flag (takes priority over “MW_SERVICE_NAME”).
- This brings Middleware APM closer to the OpenTelemetry standard.
- Service names now auto-reflect in APM traces once you upgrade.
How to Upgrade
If You’re Using Kubernetes Auto-Instrumentation, run this helm upgrade to pull in the new agent version:
helm upgrade mw-agent middleware-labs/mw-kube-agent-v3 \
--reuse-values \
--set "mw-autoinstrumentation.opentelemetry-operator.manager.autoInstrumentationImage.java.tag=1.8.0" \
-n mw-agent-ns
Then restart your Java services:
kubectl rollout restart deployment <your-service-name> -n <namespace>
If You’re Running Java APM via the JAR Method
- Download the latest release: middleware-javaagent-1.8.0.jar
- Start your app like this:
MW_API_KEY=<your-api-key> \
OTEL_SERVICE_NAME=<your-service-name> \
java -javaagent:/path/to/middleware-javaagent-1.8.0.jar -jar your-app.jar
Still not seeing your service names? Double-check:
- That you’re running v1.8.0 or above.
- The OTEL_SERVICE_NAME variable is set at deployment or pod level.
- Check logs for old MW_SERVICE_NAME conflicts