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
The container empties the logs directory at each start, so the log files inside it do not survive a restart. Do not mount a volume over the logs directory.
To keep the server log or send it to a log platform, use the container's standard output, which carries the same content. Docker sends it where its logging driver points - to a file on the host by default, or to a log platform such as Fluentd, Splunk, Amazon CloudWatch or a syslog server:
docker run \
--log-driver=fluentd \
--log-opt fluentd-address=logs.example.com:24224 \
zatosource/zato-4.1
From there any collector can pick the log up - Loki, Elasticsearch, Splunk, Datadog, whatever you already run.
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.