Every replica in one log. Every change on record.
The Logs page follows what the services of the swarm write, interleaved by time, with the task and its node in front of every line. Events shows what the swarm reported, and keeps two weeks of it where a manager remembers only its last 256; next to it, an audit log of every change the app itself made.
What you can do
One page for all logs
Logs in the sidebar shows what the services of the swarm write, interleaved by time. Choose services per stack, or all of them; then a service that is added joins by itself.
Only the swarm
The swarm only passes on the logs of its own tasks, so standalone containers on the nodes stay out.
Search the way you think
Search with words, !word to leave lines out, "a phrase" or a /regular expression/.
Errors and warnings
Show only errors or warnings, recognised from ERROR, level=warn, "level":"error", [warn] and the like. Hide the timestamps, and mark what came from stderr.
Merged by time
The Logs tab of a service merges the logs of all its tasks by time, with the task and its node as the source, like web.3@node-2.
A whole stack
The Logs tab of a stack does the same for all its services.
Filter and follow
Show the last 100 to 5000 lines, filter them, and follow live like docker service logs -f, or pause.
When the log broker stalls
Service logs come through the log broker of the manager, which can stall on a long tail from another node. The app then waits 3 seconds and reads the logs of those tasks from their containers, through the Docker context of that node.
What the daemon says
Messages from the daemon itself, such as a node that cannot deliver its logs, appear above the lines.
What the swarm reported
Events in the sidebar, on the tab Swarm events, newest first: services created, changed and removed; nodes that go down or come back, change availability or role; secrets, configs and swarm networks. Standalone containers, images and volumes stay out.
What changed
A change says what it was, old next to new: a new image, another replica count, a rollout that starts, finishes, pauses or rolls back. A node that goes down or a rollout that pauses stands out.
Two weeks of events
A manager keeps only its last 256 events, its own containers included; with healthchecks those are gone within minutes. So the app keeps its own log while it runs, also from the notification area: two weeks, at most 2000 events per swarm.
Filter the events
Filter by kind, by period (last hour, today, last night) and by name or stack.
An audit log
The other tab of Events: every change this app makes in a swarm, from services, nodes and secrets to images, cleanup, restoring a backup and scheduled image updates. With the time, the context, the Windows user, the action, its target and detail, and whether it worked; attempts that failed are there too. Kept for 90 days, at most 5000 entries per swarm.
Never a secret
A secret appears only by name. Join tokens, the unlock key and the content of secrets are left out, also from the text of an error.
Search and export
Search by name, user or detail, filter by action and result, and export to CSV. What others change with the Docker CLI or another tool is not in it; the swarm events show that.
Events
A manager forgets after 256 events. The app does not.
With healthchecks running, the last 256 events of a manager are gone within minutes. The app writes down what the swarm reports while it runs and keeps two weeks of it, so a service that was scaled or a node that went down last night is still there in the morning.
Per service or stack
The same view on the page of a service or a stack.
The Logs tab of a service or a stack merges the logs of its tasks the same way, with the task and its node in front of each line. An API with six replicas on three nodes returns errors now and then? Type the request path in the filter, and the source shows which task on which node logged it.
All features