Excessive INFO logging from ConfigurationUpdater after latest deployment

[TheMorganHub]

Tracer Version(s)

1.53.0

Java Version(s)

21.0.8

JVM Vendor

Amazon Corretto

Bug Report

Title: Excessive INFO logging from ConfigurationUpdater after latest deployment

Description
After our latest deployment, we’ve observed an excessive amount of INFO logs coming from com.datadog.debugger.agent.ConfigurationUpdater. These logs appear to contain what should likely be DEBUG-level information.

Example logs:

[dd.trace 2025-09-10 13:40:36:595 +0000] [dd-task-scheduler] INFO com.datadog.debugger.agent.ConfigurationUpdater - Re-transforming class: ar.com.glamit.spring.configurations.config.ConfigurationCreatorConfig

[dd.trace 2025-09-10 13:40:36:730 +0000] [dd-task-scheduler] INFO com.datadog.debugger.agent.ConfigurationUpdater - Applying new probe configuration, changes: ConfigurationComparer{addedDefinitions=1, removedDefinitions=0, filteredListChanged=false, changedBlockedTypes=0}

Impact
These INFO logs are displayed as ERROR in the Datadog Web UI, creating noise and confusion for users monitoring logs.

Suspected cause
Upon reviewing the agent code, the logging level seems incorrectly set to INFO instead of DEBUG:

private void retransformClasses(List<Class<?>> classesToBeTransformed) {
  for (Class<?> clazz : classesToBeTransformed) {
    try {
      LOGGER.info("Re-transforming class: {}", clazz.getTypeName());
      instrumentation.retransformClasses(clazz);
    } catch (Exception ex) {
      ExceptionHelper.logException(LOGGER, ex, "Re-transform error:");
    } catch (Throwable ex) {
      ExceptionHelper.logException(LOGGER, ex, "Re-transform throwable:");
    }
  }
}

Expected behavior
These messages should likely be logged at the DEBUG level (or possibly TRACE), as they represent internal instrumentation details rather than actionable operational events.

Expected Behavior

Please confirm whether this logging level is intentional, and if not, consider adjusting it to reduce noise in production environments.

Reproduction Code

No response

[jpbempel]

Hey! @TheMorganHub
Which version did you upgrade from?
There is no obvious change recently around this log, and having a ton of this log is maybe a bad sign that you are re-transforming a lot. which considering the heavy operation it is not a good sign a definitily more worrisome than having more logs.
Can you share more information about your case?

[TheMorganHub]

Hi @jpbempel,
We're always on latest, so it's probably the previous or even the same version. Is transformation done automatically by the tracer? This is the first time we see this log.

What triggers a retransformation?

[jpbempel]

Those tranformations are triggered by Dynamic Instrumentation/Live Debugger or Exception Replay.
Those features are opt-in so it's either in Java property or Env vars that those features are enabled

[TheMorganHub]

@jpbempel
This is our Dockerfile definition:

FROM amazoncorretto:21-alpine-jdk
# hadolint ignore=DL3018
RUN apk add --no-cache fontconfig ttf-dejavu && \
    ln -s /usr/lib/libfontconfig.so.1 /usr/lib/libfontconfig.so && \
    ln -s /lib/libuuid.so.1 /usr/lib/libuuid.so.1 && \
    ln -s /lib/libc.musl-x86_64.so.1 /usr/lib/libc.musl-x86_64.so.1
ENV LD_LIBRARY_PATH=/usr/lib
ENV DD_CODE_ORIGIN_FOR_SPANS_ENABLED="true"
ARG VERSION=0.0.1
ARG DD_GIT_REPOSITORY_URL
ARG DD_GIT_COMMIT_SHA
ARG DD_GIT_REPOSITORY_URL
ARG DD_GIT_COMMIT_SHA
ENV DD_GIT_REPOSITORY_URL=$DD_GIT_REPOSITORY_URL
ENV DD_GIT_COMMIT_SHA=$DD_GIT_COMMIT_SHA
WORKDIR /usr/app
COPY ./target/test-$VERSION.jar .
ADD https://dtdg.co/latest-java-tracer dd-java-agent.jar
RUN sh -c "touch dd-java-agent.jar" && \
    sh -c "touch test-$VERSION.jar" && \
    echo "#!/bin/sh" > entrypoint.sh && \
    echo "if [ \"\$SPRING_PROFILES_ACTIVE\" = 'prod' ]; then" >> entrypoint.sh && \
    echo "  java -Xmx2g -javaagent:dd-java-agent.jar -Ddd.service=TEST -Ddd.version=$VERSION -Ddd.profiling.enabled=true -Ddd.logs.injection=true -jar test-$VERSION.jar" >> entrypoint.sh && \
    echo "else" >> entrypoint.sh && \
    echo "  java -Xmx2g -jar tests-$VERSION.jar" >> entrypoint.sh && \
    echo "fi" >> entrypoint.sh && \
    chmod +x entrypoint.sh
EXPOSE 8080 8443
ENTRYPOINT ["/usr/app/entrypoint.sh"]

Which flag is the one that enables retransformation? What is the use case for retransformation?

[jpbempel]

Which flag is the one that enables retransformation?

ENV DD_CODE_ORIGIN_FOR_SPANS_ENABLED="true"

What is the use case for retransformation?

for Code Origin for spans, when a server/entry span is created we will also tag the span with Code Origin information with source file and line number. this requires to instrument the user code where the span is created.
So basically every endpoint should be instrumented. but it should not be a lot of re-transformation.

can you count the number of logs Re-transforming class: that are emitted please?

[TheMorganHub]

Sure. From 2025-09-10 10:30:00 to 2025-09-10 11:20:00 when we finally decided to disable logging with DD_LOG_LEVEL="OFF", we can see a total of 594 logs emitted. Most are repetitions too.
For example:

[dd.trace 2025-09-10 13:42:00:149 +0000] [dd-task-scheduler] INFO com.datadog.debugger.agent.ConfigurationUpdater - Re-transforming class: ar.com.glamit.glamitoms.services.store.StoreService

This same service gets re-transformed 15 times in that period of time.

[jpbempel]

Sounds fishy here.
Could you re-run the service with this additional property: -Ddatadog.slf4j.simpleLogger.log.com.datadog.debugger=debug
this will enable DEBUG logs just for the debugger part that trigger the re-transformation and send me those logs, please?

Thanks

[TheMorganHub]

Here are the debug logs you asked:

extract-2025-09-12T20_19_35.500Z.csv

[jpbempel]

Thanks for the debug logs. I now understand why you have so many re-transformation. spring-data spans are also decorated right now which generate slightly more re-transformation.
will fix this and probably move the transformation log to debug.
Thanks