Logging
Where server.log is, how to keep it outside a container and how to change log levels.
This is what Zato log lines look like:
2026-07-09 10:28:42,955 - INFO - 54728:MainThread - zato.server.base.parallel:21 - Starting Zato 4.1+rev.907497b5
2026-07-09 10:28:50,378 - INFO - 54728:Dummy-7 - customer.cache - 20260709-082850-3727-a1bbe9814a16cac8a - customer.cache:21 - Refreshed the customer cache, entries: 128
Where the log is
In a container, the server log is here:
The same content goes to the container's standard output, so docker logs shows it as well.
Keeping the log outside the container
Logs are not persistent. A recreated container starts with an empty logs directory, so if you need persistence, mount the logs directory as a volume, such as below using Docker Compose.
From there any collector can pick the file up - Loki, Elasticsearch, Splunk, Datadog, whatever you already run - or you can read the container's output directly instead.
Changing the log level
Dashboard has a System → Logging screen with one logger=LEVEL pair per line. Change a level, save, and it applies while the environment runs.

The levels are the standard ones - DEBUG, INFO, WARN, ERROR and CRITICAL.
The audit log export in the server log
When the audit log is exported with OpenTelemetry, an outage of the collector writes exactly three lines here, each once, and nothing in between:
2026-09-14 10:28:42,955 - WARNING - 54728:Dummy-9 - zato.common.audit_log.export.queue:21 - Audit export to http://otel-collector:4318 paused - HTTP 503 Service Unavailable
2026-09-14 10:31:07,102 - WARNING - 54728:Dummy-9 - zato.common.audit_log.export.queue:21 - Audit export queue full at 20,000 events, dropping the oldest
2026-09-14 10:34:51,388 - WARNING - 54728:Dummy-9 - zato.common.audit_log.export.queue:21 - Audit export to http://otel-collector:4318 resumed, 1,234 events dropped, ids 5,001 to 6,234
The first line names the reason the collector gave, the second appears only if the queue filled up before the collector was back, and the third says which events were dropped, if any - they are still in the audit database. Header values such as a bearer token never appear in these lines.