skip to content

What are logger groups in Spring Boot, and how do they interact with the loggers endpoint?

level: middleimportance: nice to knowfreq 18%

answer

  1. logging.group.<name>=pkg1,pkg2 defines a group
  2. predefined groups: web and sql
  3. POST /actuator/loggers/<group> sets all members at once
  4. GET shows groups section + members list
  5. LoggerGroups injected into LoggersEndpoint

basics

~20 s

A logger group is a named alias for several loggers, defined with logging.group.<name>=pkg1,pkg2. You can then POST a level to that group name via the loggers endpoint and it changes all members at once. Spring predefines web and sql groups.

solid answer

~40 s

Logger groups let you treat multiple related loggers as one unit. You declare a group in config, e.g. `logging.group.payments=com.myapp.payments,com.myapp.billing`. Spring Boot ships two predefined groups: `web` (Spring web/HTTP loggers) and `sql` (Hibernate SQL, JDBC). The loggers endpoint is group-aware: `GET /actuator/loggers` includes a `groups` section, `GET /actuator/loggers/payments` shows the group's members and configuredLevel, and `POST /actuator/loggers/payments {"configuredLevel":"DEBUG"}` applies the level to every member in one call — far more convenient than posting to each package. This is ideal for operational runbooks: define a group around a feature's packages, then flip the whole feature's verbosity with a single request and reset it with a single `null` POST.

code

java · 17 lines
java
// application.properties
// logging.group.payments=com.myapp.payments,com.myapp.billing

// Inspect the group:
//   GET /actuator/loggers/payments
//   { "configuredLevel": null,
//     "members": ["com.myapp.payments", "com.myapp.billing"] }

// Turn on DEBUG for the WHOLE group in one call:
//   POST /actuator/loggers/payments   { "configuredLevel": "DEBUG" }

// Predefined groups also work out of the box:
//   POST /actuator/loggers/web   { "configuredLevel": "DEBUG" }
//   POST /actuator/loggers/sql   { "configuredLevel": "DEBUG" }

// Reset the group back to inheriting:
//   POST /actuator/loggers/payments   { "configuredLevel": null }

go deeper

for a junior

Know a group bundles several loggers under one name and can be set together.

for a middle

Define groups, name the predefined web/sql, and use the endpoint to set all members at once.

for a senior

Relate groups to LoggerGroups in LoggersEndpoint and use them to build clean debugging runbooks.

for a principal

Standardize per-feature groups across services so live-verbosity operations are consistent and low-risk.

## What a logger group is A **logger group** is a **named alias that maps to a set of logger names**, so you can configure or control them together. Without groups you'd repeat the same level for `com.myapp.a`, `com.myapp.b`, `com.myapp.c`; with a group you address them all by one name. ### Defining a group In `application.yml`/properties: ``` logging.group.payments=com.myapp.payments,com.myapp.billing,com.stripe ``` This creates a group named `payments` with three member loggers. ### Predefined groups Spring Boot ships two out of the box: - **`web`** — a bundle of Spring web/HTTP-related loggers (e.g. `org.springframework.core.codec`, `org.springframework.http`, `org.springframework.web`, plus Tomcat/HTTP internals) so you can turn on request tracing quickly. - **`sql`** — SQL-related loggers (e.g. `org.springframework.jdbc.core`, Hibernate SQL, `org.hibernate.SQL`) so you can see database statements. ## Interaction with the loggers endpoint The endpoint is **group-aware** through the `LoggerGroups` object injected alongside `LoggingSystem` into `LoggersEndpoint`: - `GET /actuator/loggers` returns a top-level `groups` map in addition to `levels` and `loggers`. - `GET /actuator/loggers/{groupName}` returns the group's `configuredLevel` and its `members` list. - `POST /actuator/loggers/{groupName}` with `{"configuredLevel":"DEBUG"}` sets the level on **every member logger** in a single request. Posting `{"configuredLevel":null}` resets all members. ## Static config uses groups too Groups aren't only for the endpoint — you can set a group's level statically: `logging.level.payments=DEBUG` applies DEBUG to all members at startup. (That static usage lives with the Logging subcategory; here the focus is the endpoint interaction.) ## Gotchas - A group's reported `configuredLevel` reflects the level set on the group as a whole; individual members could still be overridden. - If member packages overlap or nest, changing the group sets each named member explicitly, which then acts as a configured node for inheritance. - Group names live in the same namespace as logger names for the POST path — pick names that won't collide with real package names. - Predefined `web`/`sql` groups exist even if you define none of your own. ## When to use Groups shine for **operational convenience**: bundle the loggers for a feature or subsystem, then raise/lower verbosity for the whole thing with one endpoint call — a clean building block for production debugging runbooks.

  • Which logger groups does Spring Boot define by default?
    Two: `web` (Spring web/HTTP loggers) and `sql` (SQL/Hibernate loggers). You can POST a level to either via the loggers endpoint to quickly enable request or SQL tracing.
  • What is the advantage of POSTing to a group instead of individual loggers?
    One request changes the level for every member logger atomically, instead of issuing a separate POST per package — simpler and less error-prone for operational runbooks.

saying these in an interview costs you the question

  • Thinking you must POST each package separately even when a group exists
  • Not knowing web and sql are predefined groups
  • Assuming groups only work in static config and not via the endpoint
  • Confusing a group name with a single real logger

context

resolving links…