The Azure SDK for Java uses SLF4J as its logging facade (com.azure:azure-core ships azure-core-slf4j-stub as a no-op default). To see log output you need a concrete SLF4J binding on the classpath and then control the log level either via the AZURE_LOG_LEVEL environment variable or your logging framework's own configuration.

Set via environment variable:

export AZURE_LOG_LEVEL=1   # VERBOSE — all SDK log output
export AZURE_LOG_LEVEL=3   # WARN — recommended for production

Or at runtime before the first client is constructed:

System.setProperty("AZURE_LOG_LEVEL", "1");

<dependency>
  <groupId>ch.qos.logback</groupId>
  <artifactId>logback-classic</artifactId>
  <version>1.4.14</version>
</dependency>

Minimal src/main/resources/logback.xml:

<configuration>
  <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
    <encoder>
      <pattern>%d{HH:mm:ss} %-5level %logger{36} - %msg%n</pattern>
    </encoder>
  </appender>

  <!-- Restrict Azure SDK to WARN in production; set to DEBUG for diagnostics -->
  <logger name="com.azure" level="WARN"/>

  <root level="INFO">
    <appender-ref ref="STDOUT"/>
  </root>
</configuration>

<dependency>
  <groupId>org.apache.logging.log4j</groupId>
  <artifactId>log4j-slf4j2-impl</artifactId>
  <version>2.23.1</version>
</dependency>

Minimal src/main/resources/log4j2.xml:

<Configuration>
  <Appenders>
    <Console name="Console" target="SYSTEM_OUT">
      <PatternLayout pattern="%d{HH:mm:ss} %-5level %logger{36} - %msg%n"/>
    </Console>
  </Appenders>
  <Loggers>
    <Logger name="com.azure" level="warn"/>
    <Root level="info"><AppenderRef ref="Console"/></Root>
  </Loggers>
</Configuration>

Enable HTTP payload logging via HttpLogOptions on any client builder:

SecretClient client = new SecretClientBuilder()
    .vaultUrl("https://my-vault.vault.azure.net")
    .credential(new DefaultAzureCredentialBuilder().build())
    .httpLogOptions(new HttpLogOptions()
        .setLogLevel(HttpLogDetailLevel.BODY_AND_HEADERS))
    .buildClient();

Available HttpLogDetailLevel values:

Warning: BODY_AND_HEADERS can log secrets and PII. Never enable it in production without sanitization in place.

By default the SDK redacts Authorization, x-ms-encryption-key, and a handful of other sensitive headers. Add custom headers or query parameters to redact:

HttpLogOptions logOptions = new HttpLogOptions()
    .setLogLevel(HttpLogDetailLevel.HEADERS)
    .addAllowedHeaderName("x-custom-request-id")         // allow-list to log
    .addAllowedQueryParamName("api-version");             // allow-list to log

Any header or query parameter not in the allow-list is redacted as REDACTED.

Management-plane clients (azure-resourcemanager-*) configure HTTP logging via the fluent builder:

AzureResourceManager azure = AzureResourceManager
    .configure()
    .withLogLevel(HttpLogDetailLevel.BODY_AND_HEADERS)
    .authenticate(credential, profile)
    .withDefaultSubscription();

To see only logs from a specific service, scope the logger name in your SLF4J configuration:

<!-- Logback: only Key Vault logs at DEBUG, everything else at WARN -->
<logger name="com.azure.security.keyvault" level="DEBUG"/>
<logger name="com.azure" level="WARN"/>

Common logger namespaces:

Verbose logging has a measurable throughput cost. For production workloads:

• Set AZURE_LOG_LEVEL=3 (WARN) or 4 (ERROR).
• Avoid HttpLogDetailLevel.BODY_AND_HEADERS — body serialization is expensive.
• If using Logback, enable asyncAppender to move I/O off the request thread.

See Performance Tuning for benchmarking guidance.

• Configuration — AZURE_LOG_LEVEL and other environment variables
• Azure Identity Examples — credential diagnostics
• FAQ — common logging gotchas
• Azure V2 — Logging Best Practices — ClientLogger usage for SDK contributors