Log¶
control.audit.log
Who sees the journal¶
The Audit log section is visible to two roles:
- security — the supervising role: the audit log and its own account (login, changing its own password, logout). Settings, streams and observed state are closed to it entirely, reading included.
- superadmin — as with everything else in the console.
The admin and viewer roles have no access: supervision of the operators does not belong to the operators themselves, and to a viewer the journal would reveal administrator logins and the addresses they log in from. The ban is enforced by the server, not by the menu: a role without access is refused on a direct link as well.
Roles are assigned in the Accounts section. The person who watches what the operators do gets an account of their own with the security role, rather than a superadmin.
What goes into the journal¶
A record is left by a change that actually happened and by a login:
- settings edits — of a stream, a machine, a template, a schedule source, access, the control installation itself;
- work with the cluster's machines — registration, revocation, removal, opening and closing the join window;
- work with accounts — creation, edit, removal, password change;
- migration of settings from Flussonic v3 — both building the plan and applying it;
- a manual placement run;
- an administrator's login and a failed login attempt;
- work with the customer registry — creating, editing and deleting a customer, linking and unlinking an account.
A bulk operation leaves a record per affected object, not one per call: migrating three hundred streams shows up as three hundred records, and a search by name finds any of them.
Revealing a live join token stands apart: it is a read, but revealing a secret amounts to handing it out, so the record stays. The token value itself never enters it.
The feed and its columns¶
Records run newest first. Load more fetches the next page — the feed does not end at the first fifty records.
The table has five columns:
- Time — when the action happened.
- Actor — who acted. Either an administrator's login, or one of the service kinds: static key (a login with the break-glass credentials from
/etc/mcaster/secrets.env, shared by everyone, hence no name behind them) and node (the registration of a cluster machine, where the actor is its identifier). - Action — what was done, as a machine name of the form
<resource>.<verb>:stream_config.put,node_config.patch,admin.create,auth.login. The names are stable, which makes them convenient to search and filter by. - Resource — what it was done to: type and name, for instance
stream/program-a. - Outcome — success for an action that happened and failure for a failed login.
The arrow to the left of a row expands the record's details: the address the request came from, the administrator's role, the document version after the edit, the list of edited fields and — if the request arrived with a tracing header — its identifier, which matches the record against the logs.
Searching the journal¶
Five fields sit above the feed and work together:
- Resource type and Resource name — "everything done to this stream".
- Actor — "everything this person did".
- From and To — a time window in RFC 3339, for instance
2026-08-14T14:00:00Z.
Apply re-reads the feed from the top. An empty field means "do not filter".
An incident is usually taken apart in two queries: first by resource — what happened to this stream, then by the actor from the record you found — what else that same person did that day.