Why Regular Logs Are Not Enough and How to Save Prod with Logbook

Today I want to talk about how to make an application more understandable and more controllable for developers. Personally, I’m a big fan of logs. I like detailed and meaningful logs that don’t just state “we started executing this method” and “we finished executing this method,” but also provide information on who triggered it, with what input data, what exactly the method did, where it went next, and so on.

With such logs, a developer dealing with bug fixing in production, working with user requests, and responding to stakeholder questions finds it much easier not only to do their job, but also to actually enjoy working in IT.

The Logbook Library

Recently, I discovered the Java library Logbook (by Zalando), which is used for logging. Its uniqueness lies in the fact that it intercepts every HTTP request and HTTP response and logs their contents, including headers and bodies.

Thus, in addition to the usual logs of your application, you also get complete information about incoming requests and outgoing responses.

When It’s Especially Useful

• Microservices with poor logging. For example, when logs don’t provide any insight into where a request to a particular microservice came from, or when all microservices log into a single file without specifying the source. In case of production issues, reconstructing behavior from such logs takes much longer.

• Third-party APIs. Especially when these APIs have poor logging themselves. For example, the API only logs: “A new client was added to your system” — but it doesn’t log the client’s characteristics, ID, who added them, etc.

• User complaints. My favorite use case: end users report “this feature doesn’t work” and provide no other details. Logs seem fine, but the complaint is real. Without information about the user’s operating system, browser, how many attempts they made, and so on, debugging becomes guesswork. Anyone who has dealt with end-user complaints knows what I mean.

What Information Logbook Provides

Logbook helps solve these issues by providing details such as:

• Host name

• HTTP method

• Mime type

• Language used on the client

• Connection characteristics

• Cookies

• Client operating system

• CORS details

• User-agent

• Request body

• …and much more.

Having these details makes it much easier to reproduce behavior, especially in production.

Configuring Logbook

Another major advantage is how easy it is to configure. For example, in a Spring Boot application, you just impliment the dependency and update the configuration file.

Here’s an example configuration using application.yml:

logbook:
  # Enable/disable logging
  enabled: true

  # Header filtering
  obfuscate:
    headers:
      - Authorization
      - Proxy-Authorization
      - Set-Cookie
      - Cookie
    parameters:
      - password
      - secret
      - token
      - api_key
      - session_id

  # Body masking (regex)
  body-filters:
    # Example: replace values of email and password
    - "regex: \"(\\\"password\\\":\\\").*?(\")\" -> \"\\1***\\2\""
    - "regex: \"(\\\"email\\\":\\\").*?(\")\" -> \"\\1***@***\\2\""

  # Logging restrictions
  exclude:
    # Do not log static resources
    paths:
      - /actuator/**
      - /swagger-ui/**
      - /css/**
      - /js/**
    # Exclude specific media types from logs
    content-types:
      - "image/*"
      - "video/*"

  # Buffering (so large bodies are fully logged)
  buffer-size: 10240 # in bytes (10 KB)

  # Limit the size of the body in logs (0 = no limit)
  max-body-size: 0

  # Log format
  format:
    style: http # http, json, splunk, curl
    json:
      pretty: true # pretty-print JSON
      replace-control-chars: true

  # Enable color formatting (ANSI)
  include:
    - request
    - response
    - headers
    - body
    - uri
    - method
    - duration

  # Body decompression (e.g., gzip)
  decompress:
    enabled: true

  # Asynchronous logging (for high load)
  write:
    async: true

  # Writer settings
  writer:
    strategy: default # or json, splunk, curl
    level: info
    category: http.wire-logbook

  # CorrelationId settings (to link request/response)
  correlation-id:
    enabled: true
    generator: uuid # custom bean can be defined
    header-name: X-Correlation-ID

That’s it — you’re ready to go.

Special Log Formats

There are cases when you need logs in a specific structured format. For example, when a third-party API adds a new entity to your system and sends all its fields in the request body, separated by /. If there are more than 10 fields, and logs are stored in Kibana, they become unreadable for humans.

In such cases, you can connect a sink that creates centralized structured logging (for example, Logstash, JsonSink, or others). However, this setup usually requires more effort.

Conclusion

Logbook makes your application more transparent to developers and speeds up problem resolution. If you’re working with microservices, third-party APIs, or end users, give it a try — it provides maximum value with minimal effort for integration and configuration.