Logging in the Newired Docker image

This article explains where the Newired Docker image writes its logs and how to set up log levels and log rotation with Docker Compose.

How logging works in the image

Application logs go to the console. When the SPRING_PROFILES_ACTIVE=console environment variable is set, all application logs are written to the container's standard output. Docker then handles storage.

If the variable is not set, the application writes log files inside the container (/opt/Newired/tomcat/logs). We do not recommend this. The files are not on a volume, are hard to inspect and clean up, and are lost when the container is recreated.

Tomcat access logs are turned off. Newired is usually deployed behind a reverse proxy or load balancer (nginx, Traefik, HAProxy, a cloud load balancer, …), which already logs every HTTP request. To avoid duplicate logs and unnecessary disk usage, the image does not write access logs. If you need them, enable them on your proxy.

The logging profiles are available from Newired 26.0.0.

Available profiles

Configuring logging with Docker Compose

1. Enable console logging and log rotation

Add the environment variables and a logging section to the portal service in your docker-compose.yml:

services:
  portal:
    image: newired-portal:<version>
    environment:
      # ... your existing variables ...
      - SPRING_PROFILES_ACTIVE=console
      - LOGGING_LEVEL_ROOT=ERROR
    logging:
      driver: json-file
      options:
        max-size: "50m"   # size of one log file
        max-file: "5"     # number of rotated files kept

json-file is Docker's built-in default logging driver, so no installation is needed. By default, however, Docker does not rotate container logs, so the logging section is important. With the values above, the portal container uses at most 5 × 50 MB = 250 MB of disk for logs.

We recommend adding the same logging section to the db and object-storage services.

2. Set the log level

The log level is set with environment variables:

Allowed values are ERROR, WARN, INFO, DEBUG and TRACE. For normal operation, use ERROR or WARN. Use INFO or DEBUG only temporarily, for example when our support team asks you to, because these levels produce much larger logs.

3. Apply the changes

Logging settings are applied only when a container is created. A plain restart is not enough:

docker compose up -d --force-recreate

Recreating a container also deletes its old Docker log. If you want to keep it, copy it before running the command.

4. Check the result

View the latest logs:

docker compose logs --tail 100 portal

Follow the logs live, or show only recent entries:

docker compose logs -f --since 30m portal

Check that rotation is active:

docker inspect --format '{{json .HostConfig.LogConfig.Config}}' $(docker compose ps -q portal)

The output should be {"max-file":"5","max-size":"50m"}.

Optional settings

Sending logs to a central logging system

Docker can forward logs directly to systems such as syslog, Fluentd, Graylog (GELF), Splunk or AWS CloudWatch. Change the logging.driver accordingly. See the Docker documentation on logging drivers for details.

Writing log files to the host

If your policy requires log files, use the file or hybrid profile and map the log directory to the host:

services:
  portal:
    environment:
      - SPRING_PROFILES_ACTIVE=hybrid
    volumes:
      - ./logs:/opt/Newired/tomcat/logs

Create the ./logs directory before starting the container. The files are rotated daily and kept for 30 days, up to 100 MB in total.