Logging is what lets you see what your application is doing when you’re not there to watch it. In production, your code is running on a server, possibly in the middle of the night. When something goes wrong, a well-crafted log file is often your only witness to the event. It tells the story of what happened. My goal here is to share practical ways to make that story clear, useful, and efficient, without slowing your application down.

A good starting point is to not lock yourself into a single logging library. You might start a project with one library, but requirements change. A better library might emerge. Using a facade, or an abstraction layer, means your application code talks to a consistent interface. The actual logging work is done by a library behind the scenes, which you can swap out. This is the core idea.

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

public class OrderService {
    private static final Logger logger = LoggerFactory.getLogger(OrderService.class);

    public void placeOrder(String orderId, String customerId) {
        // Your business logic here
        logger.info("Attempting to place order {} for customer {}", orderId, customerId);
    }
}

In this code, Logger and LoggerFactory come from SLF4J. They don’t do the logging themselves. They delegate to whatever library you’ve configured, like Logback or Log4j 2. Your OrderService class doesn’t need to know which one. If you decide to switch, you only change your project’s dependencies and configuration files. Your service class remains untouched. This separation saves a lot of future headaches.

When you write log messages, it’s tempting to build the string directly. This seems fine, but it has a hidden cost. Java will construct that string immediately, even if the log level you’re using is turned off in production. Doing this thousands of times per second wastes memory and processing power for messages no one will ever see.

Instead, you can pass the variables as separate parameters. The logging framework will check if the level is active first. Only if it is, will it combine the message and the parameters. This small change can improve performance.

// Less efficient: String is always built
logger.debug("Order " + orderId + " has a total of " + calculateTotal() + " items.");

// More efficient: String is only built if DEBUG is enabled
logger.debug("Order {} has a total of {} items.", orderId, calculateTotal());

Notice the {} placeholders. The framework replaces them with the values of orderId and the result of calculateTotal(). If the debug level is disabled, the calculateTotal() method isn’t even called, which is another significant saving.

The traditional log is a line of text. It’s great for humans to read in a console, but it’s difficult for machines to parse. Modern systems handle thousands of logs per second. We need a format that tools can understand automatically. This is where structured logging comes in. Instead of a sentence, you output a block of data, typically in JSON format.

A line like “User 12345 logged in from 192.168.1.1” becomes a structured entry.

{
  "@timestamp": "2023-10-27T10:15:30.123Z",
  "level": "INFO",
  "logger": "AuthService",
  "message": "User login successful",
  "userId": "12345",
  "ipAddress": "192.168.1.1",
  "thread": "main"
}

Now, a monitoring system like Elasticsearch can ingest this. You can then search for all logs where userId is “12345”, or create an alert when level is “ERROR”. You can build dashboards showing login attempts per hour. The data is immediately actionable.

Configuring this usually happens in your logging framework’s configuration file, not your Java code. Here’s a simplified Logback setup that outputs JSON.

<configuration>
    <appender name="JSON" class="ch.qos.logback.core.ConsoleAppender">
        <encoder class="net.logstash.logback.encoder.LogstashEncoder"/>
    </appender>

    <root level="info">
        <appender-ref ref="JSON" />
    </root>
</configuration>

This encoder automatically adds common fields like timestamp and thread name. You can add custom fields globally or through your code.

A single user action in a web application can trigger code across many classes and services. If each log message just says “Processing request” or “Database query executed”, it becomes impossible to tell which messages belong to the same user’s request. You need a way to stamp all related logs with a common identifier. This is often called a request ID or correlation ID.

You can use a Mapped Diagnostic Context for this. Think of it as a per-thread storage box. You put a piece of information, like a request ID, into this box at the start of processing. For the rest of that thread’s execution, every log message automatically includes that piece of information.

import org.slf4j.MDC;

public void handleRequest(HttpServletRequest request) {
    // Generate or extract a unique ID for this request
    String requestId = UUID.randomUUID().toString();
    MDC.put("requestId", requestId);

    try {
        logger.info("Starting request processing.");
        // ... call other methods and services ...
        logger.info("Request processing completed.");
    } finally {
        // Always clear the MDC at the end to prevent memory leaks
        MDC.clear();
    }
}

If your logging is configured for JSON, the requestId automatically appears in every log from this thread. If another class, deep in your stack, logs an error, you’ll see the same requestId. This allows you to filter logs in your central system and see the complete journey of that single request, from the web layer down to the database and back.

In production, you typically run with log levels like INFO or WARN to avoid being overwhelmed by noise. But what if a specific component starts behaving oddly? You need to see its detailed DEBUG logs to understand why. Restarting the entire application with a new configuration is risky and disruptive.

Many modern logging frameworks allow you to change log levels at runtime. You can use tools like JMX, or they may provide an HTTP endpoint. This means you can connect to your running application and tell it, “Just for the com.myapp.payments package, set the log level to DEBUG for the next 10 minutes.”

Here is a conceptual example of how you might do this programmatically with Log4j 2.

import org.apache.logging.log4j.Level;
import org.apache.logging.log4j.LogManager;
import org.apache.logging.log4j.core.LoggerContext;
import org.apache.logging.log4j.core.config.Configuration;
import org.apache.logging.log4j.core.config.LoggerConfig;

public class LogLevelManager {
    public void setDebugForPackage(String packageName) {
        LoggerContext ctx = (LoggerContext) LogManager.getContext(false);
        Configuration config = ctx.getConfiguration();
        LoggerConfig loggerConfig = config.getLoggerConfig(packageName);

        // Set the new level
        loggerConfig.setLevel(Level.DEBUG);

        // This tells Log4j 2 to apply the new configuration
        ctx.updateLoggers(config);
    }
}

In practice, you’d wrap this in a secure admin API. This ability is a powerful tool for live debugging.

Writing a log to a file is an I/O operation. It can be slow. If your application thread has to wait for the log to be written to disk before it can continue, it adds latency to your user’s request. This is where asynchronous logging helps.

With asynchronous logging, your application thread doesn’t write the log directly. It puts the log event into a queue and immediately goes back to work. A separate, background thread reads from this queue and performs the actual file writing. The user gets a faster response, and the logs still get written.

Configuration is key. Here’s a snippet for Log4j 2 that sets up an asynchronous logger.

<?xml version="1.0" encoding="UTF-8"?>
<Configuration status="WARN">
    <Appenders>
        <File name="FileAppender" fileName="logs/app.log">
            <PatternLayout pattern="%d %p %c{1.} [%t] %m%n"/>
        </File>
    </Appenders>

    <Loggers>
        <!-- This is the async logger. The main thread won't block on its I/O. -->
        <AsyncLogger name="com.myapp" level="info" additivity="false">
            <AppenderRef ref="FileAppender"/>
        </AsyncLogger>

        <Root level="error">
            <AppenderRef ref="FileAppender"/>
        </Root>
    </Loggers>
</Configuration>

You need to be aware that if the application crashes, any log events still in the in-memory queue could be lost. For most business applications, the performance gain outweighs this small risk. For critical audit logs, you might still use synchronous logging.

This is a critical safeguard. You must ensure that passwords, credit card numbers, social security numbers, or API keys never get written to log files. It’s surprisingly easy to do accidentally by logging a full request or response object.

The best defense is to never log such objects directly. Be selective. However, as an additional safety net, you can implement masking in your logging configuration. This scans log messages for patterns that look like sensitive data and replaces them before they are written.

You can create a custom converter for Logback. This one looks for 16-digit numbers (a simple credit card pattern) and masks them.

package com.myapp.logging;

import ch.qos.logback.classic.pattern.ClassicConverter;
import ch.qos.logback.classic.spi.ILoggingEvent;

public class MaskingConverter extends ClassicConverter {
    @Override
    public String convert(ILoggingEvent event) {
        String message = event.getFormattedMessage();
        if (message == null) {
            return null;
        }
        // A very basic pattern - you would use a more robust one
        return message.replaceAll("\\b(\\d{4}[ -]?){3}\\d{4}\\b", "[CREDIT_CARD_MASKED]");
    }
}

You then register this converter in your logback.xml file and apply it to your appender’s pattern. This acts as a final filter, scrubbing data before it hits the disk. Remember, this is a last line of defense, not a primary strategy.

When you have more than one server, logging to local files is not enough. You need to bring all those logs together into one place where you can search and analyze them. This is log aggregation. Instead of just writing to a file, your application also sends each log event to a central service over the network.

A common setup uses the ELK Stack: Elasticsearch for storage and search, Logstash for processing, and Kibana for visualization. Your Java app needs an appender that can send logs to Logstash.

For Logback, you can use the logstash-logback-encoder library. Your configuration would look something like this.

<configuration>
    <appender name="LOGSTASH" class="net.logstash.logback.appender.LogstashTcpSocketAppender">
        <!-- Destination is your Logstash server -->
        <destination>logstash.production.mycompany.com:5000</destination>
        <encoder class="net.logstash.logback.encoder.LogstashEncoder">
            <customFields>{"appname":"order-service","environment":"production"}</customFields>
        </encoder>
        <keepAliveDuration>5 minutes</keepAliveDuration>
    </appender>

    <root level="info">
        <appender-ref ref="LOGSTASH" />
    </root>
</configuration>

Now, logs from all instances of your service flow into a single system. You can see errors spiking on specific servers, trace a request across multiple services, and get a unified view of your application’s health.

Logs aren’t just for errors. They are a source of data about how your application performs. By consistently logging the duration of key operations, you can extract metrics. For example, you can log every database query time. Your aggregation system can then calculate the average, 95th percentile, and 99th percentile latency.

long startTime = System.currentTimeMillis();
// ... execute database query ...
long duration = System.currentTimeMillis() - startTime;

logger.info("Database query [{}] completed in {} ms", queryName, duration);
// In JSON, this becomes: {"queryName":"findUser", "duration_ms": 45, ...}

In Elasticsearch/Kibana, you can create a visualization charting the average duration_ms over time. You can set an alert to trigger if the 99th percentile goes above 500ms. This turns your passive logs into an active monitoring tool.

Finally, logs live on disk. If you don’t manage them, a single log file can grow to fill the entire disk, crashing your server. You need rules to control this. Log rotation creates a new file when certain conditions are met, and retention policies delete old files.

A common strategy is to rotate logs daily and keep them for 30 days. Here is a Logback configuration that does exactly that.

<configuration>
    <appender name="ROLLING_FILE" class="ch.qos.logback.core.rolling.RollingFileAppender">
        <file>logs/application.log</file>
        <encoder>
            <pattern>%d %p %c{1.} [%t] %m%n</pattern>
        </encoder>

        <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
            <!-- New file every day, and compress old ones -->
            <fileNamePattern>logs/application-%d{yyyy-MM-dd}.log.gz</fileNamePattern>
            <!-- Keep 30 days of history -->
            <maxHistory>30</maxHistory>
            <!-- Optional: Limit total size of archive -->
            <totalSizeCap>3GB</totalSizeCap>
        </rollingPolicy>
    </appender>

    <root level="info">
        <appender-ref ref="ROLLING_FILE" />
    </root>
</configuration>

Every day at midnight, application.log will be renamed to application-2023-10-27.log.gz and a fresh application.log will be created. After 30 days, the oldest compressed file is deleted. This keeps your logging sustainable.

Putting it all together, a robust logging strategy is built in layers. You start with a facade for flexibility. You use parameterized logging for performance and structured logs for machine readability. You add context to trace requests and ensure you can change log levels on the fly. You make logging asynchronous to protect performance, and you aggressively mask sensitive data. You forward logs to a central system where they become a source for both debugging and performance metrics. And you always manage the files on disk with sensible rotation and retention policies.

Each technique addresses a specific challenge you will face in production. Implementing them from the start saves immense time and frustration later. When that critical error occurs at 3 a.m., you’ll be grateful you took the time to build a logging system that can tell you exactly what went wrong.