Logging in Spring Boot

Notebook Summary

Copy this into a notebook. Every line is derivable from the detailed notes below.

Detailed Study Notes

A customer clicks Place order. The screen says nothing is wrong. But the order never reaches the kitchen, never charges the card, never appears in the database. There is no red error box, no stack trace on their screen — the request just evaporated somewhere between the controller, the service, the repository, and the payment gateway. You have one question and no way to answer it: what actually happened? That silence is the problem logging exists to solve.

2.1What logging is, and why it exists

Logging is the practice of writing down what your program did while it ran. Each log line is a small note the code leaves behind — what came in, what went out, and how it ended. Concretely, you keep track of three things:

• Data input — e.g. which username arrived in the request parameter.
• Data output — e.g. what a called API returned.
• Final result — e.g. SUCCESS, FAILURE, or an exception.

Beyond bare debugging, logs let you monitor the same application across environments — Dev, QA, Stage, Prod — each of which may misbehave differently. A well-logged program also records its execution flow, the state of important objects, exceptions, the class and thread that ran, and the time each event occurred. Together those notes are a documented history of what the system did.

The order-processing failure from the hook is hard precisely because the flow crosses several components. You log at each one so the trail is unbroken:

2.2The three ways to log — and why two of them fail

Before frameworks, developers reached for two crude approaches. Understanding why they break down is the whole motivation for Log4j.

A logging framework is a library that does all of this correctly for you. It manages the file or database connection, enforces one format, adds severity levels, and can persist your logs — solving every problem above at once. That library is what the rest of this lesson is about.

2.3Log4j and its three moving parts

Log4j is a fast, highly configurable logging framework for Java. Three properties make it the classic choice: it's designed for speed and minimal overhead (safe in high-traffic apps), it's configured from external XML/properties files so you change logging behaviour without touching code, and it uses a hierarchical model that categorises and filters messages by package or class name.

Every log message flows through the same three components. Learn these three words and Log4j stops being mysterious:

2.4Loggers: one per class, born from a factory

A Logger is the object that turns Log4j on inside a single Java class. You create exactly one, as a static field named after the class, and you call its methods instead of System.out.println. Because it's static, all instances of the class share the one logger, and it carries the class name so every line it emits is automatically attributed.

public class YourClassName {
    // named after the class → messages are auto-tagged with the class name
    static Logger log = Logger.getLogger(YourClassName.class.getName());

    public static void main(String[] args) {
        // your logic goes here, using log.info(...) etc.
    }
}

The Logger exposes one method per severity. Choosing the right one is what makes logs filterable later:

[!] fatal() exists in Log4j but not in the SLF4J API you'll actually use in Spring Boot — see §2.5 and §2.8.

2.5Appenders: where the message goes

An Appender is the component that writes a log message to an external destination. Appender is an interface, which is why Log4j can offer many interchangeable implementations — you pick the destination by picking the appender, without changing your logging calls.

2.6Layouts: how the message is formatted

A Layout specifies the format in which the appender writes each log statement. Same message, different dress: a Layout decides whether a line is bare text or a rich, parseable record.

%d{yyyy-MM-dd HH:mm:ss} [%t] %-5p %c{1} - %m%n

%d date/time   %t thread   %-5p level (left-padded to 5)
%c{1} logger (last segment)   %m message   %n newline

2.7Logging levels: the volume knob

A level is a severity rank that decides whether a message is actually emitted. Each logger is configured with a threshold, and Log4j applies one rule:

So if a logger is set to INFO, then INFO, WARN, ERROR (and FATAL) print, while DEBUG and TRACE are ignored. Raise the threshold in production to cut noise; lower it to DEBUG when hunting a bug.

2.8SLF4J: the facade Spring Boot actually uses

SLF4J (Simple Logging Facade for Java) is an abstraction that sits in front of a real logging engine. You write your code against SLF4J's interface; at runtime an actual implementation — Logback, Log4j, or java.util.logging — does the work. Spring Boot bundles logging in by default: the SLF4J API with Logback as the engine.

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

@RestController
public class LogController {
    // SLF4J factory — note the org.slf4j import, not org.apache.log4j
    private static final Logger log = LoggerFactory.getLogger(LogController.class);

    @GetMapping("/logs")
    public String logs() {
        log.trace("trace — hidden at default level");
        log.debug("debug — hidden at default level");
        log.info("info — visible");
        log.warn("warn — visible");
        log.error("error — visible");
        return "check your console";
    }
}

2.9Configuration in application.properties

The point of a framework is that you tune behaviour without editing code. In Spring Boot that happens in application.properties. Two everyday needs: reveal debug logs, and make logs survive a terminal restart.

# raise verbosity for your own package only
logging.level.com.crio=DEBUG

# keep the rest of the world quiet
logging.level.root=INFO

# persist logs to a file (console alone is not durable) [+]
logging.file.name=logs/app.log

• Color-coded console logs are on by default in Spring Boot — levels are tinted so errors jump out.
• Console logs do not persist. Kill the terminal and they're gone. To make logs sustain over time you must write them to a file or database — which is exactly what logging.file.name turns on.

2.10Spring Boot Actuator: the live dashboard

Logs tell you what happened. But when orders in production suddenly turn slow, you also want to know what's happening right now — memory, CPU, database health — without attaching a debugger. Spring Boot Actuator adds production-ready endpoints that report your app's health and metrics on demand.

Add the actuator dependency at start.spring.io, then a controller like the one taught in the session:

@RestController
public class HelloWorldController {

    @GetMapping("/helloworld")
    public String getMethodName() {
        return new String("Hello World!");
    }
}

management.endpoints.web.exposure.include=*

Exposing everything is fine locally; in real production you expose a curated subset, not *. [+]

2.11Interview & practice Q&A

2.12Key takeaways

• Logs are the record you read after something breaks — without them, a prod failure is a black box.
• Frameworks beat SOPL and manual file-writing because they add levels, uniform format, and persistence.
• Log4j = Logger (who) → Appender (where) → Layout (how).
• A message prints only when its level ≥ the logger's threshold; Spring's default is INFO.
• Spring Boot gives you SLF4J + Logback free; tune it from application.properties, no code changes.
• Actuator is the live dashboard — but only /health is exposed until you say otherwise.

Microexercises

Reading proves you recognise these ideas. These two drills prove you can use them — one to build, one to diagnose. Attempt each before opening the walkthrough.

3.1Build it — a logging controller + config

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.web.bind.annotation.*;

@RestController
public class StatusController {
    private static final Logger log = LoggerFactory.getLogger(StatusController.class);

    @GetMapping("/status")
    public String status() {
        log.debug("debug: computing status");
        log.info("info: status requested");
        log.error("error: sample error line");
        return "ok";
    }
}

logging.level.root=INFO
logging.level.com.crio=DEBUG
logging.file.name=logs/app.log

3.2Diagnose it — the code that won't behave

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

@RestController
public class OrderController {
    private static final Logger log = LoggerFactory.getLogger(OrderController.class);

    @GetMapping("/order")
    public String order() {
        log.debug("validating order");   // (a)
        log.info("order accepted");      // (b)
        log.fatal("payment gateway down"); // (c)
        return "done";
    }
}

logging.level.root=INFO

    @GetMapping("/order")
    public String order() {
    log.debug("validating order");    // hidden until level lowered
    log.info("order accepted");       // prints at INFO
    log.error("payment gateway down"); // was fatal() — use error()
    return "done";
    }

# reveal the debug line when you need it
logging.level.com.crio=DEBUG