Forward the audit log to a SIEM

Gardience can send a copy of every audit log entry, with its chain hash, to your SIEM (security information and event management system, such as Splunk, Microsoft Sentinel, Elastic or QRadar) over syslog. Entries are sent as they are written.

A copy kept off the Gardience server is what keeps the audit trail trustworthy even against someone with root access to that server. It is also your record of anything that happened after your last backup.

Turn on forwarding#

You need the admin role.

1. Open Settings in the console.

2. Under Audit forwarding (syslog / SIEM), enter the destination in the form PROTOCOL://HOST:PORT, for example:

   • tls://siem.example.com:6514
   • tcp://siem.example.com:514
   • udp://192.0.2.5:514
3. Click Save.

The change is recorded in the audit log (settings.changed). Forwarding starts shortly after you save, and the first entry the new destination receives is a siem.started entry that names the previous destination, if any.

To stop forwarding, clear the field and click Save.

Choose a protocol#

TCP and TLS messages use octet counting framing (RFC 6587): each message is preceded by its length and a space.

Message format#

Each entry is one syslog message:

<110>1 2026-10-16T14:03:22Z gardience gardience - audit - {"ts": "...", "user": "alice", "fun": "...", "tgt": "...", "args": [...], "minions": [...], "prev": "...", "hash": "..."}

• Priority 110 is facility 13 (log audit) at severity 6 (informational).
• The host name and app name are both gardience, and the message ID is audit.
• The body is the audit entry as JSON. hash is the entry's chain hash and prev is the hash of the entry before it.

Size cap#

A message is kept to 8,000 bytes, so it fits any syslog receiver and a single UDP datagram. An entry for a fleet-wide job can list thousands of nodes, so a larger entry is shortened before it is sent:

1. The minions and args lists are cut to their first 20 items. Next to each, Gardience adds a count (minions_count, args_count) and a SHA-256 of the full list (minions_sha256, args_sha256).
2. The entry is marked "truncated": true.
3. If it is still too large, only the identifying fields are sent: ts, user, fun, jid, hash, prev, the node count and hash, and the first 200 characters of tgt.

The full entry always stays in the audit log on the server, and its chain hash is unchanged.

How delivery resumes#

Gardience does not keep a separate queue. It reads the audit log itself and remembers, for each destination, the hash of the last entry that destination accepted. This position is called the cursor, and it is saved in siem_cursor.json in the data volume.

What this means in practice:

• The SIEM is down. Gardience reports a problem (shown on the console banner, by gardience doctor and in the gardience_errors metric) and retries, waiting 2 seconds at first and up to 10 seconds between tries. When the SIEM is back, every entry since the cursor is sent, in order.
• Gardience restarts. Delivery picks up from the cursor.
• You change destination. Gardience first gives the old destination everything up to the change, so it is left with no gap. A destination never used before starts from the moment you switched. A destination used before starts again where it stopped and catches up on everything since.
• The cursor file is unreadable. Gardience reports it and resends from the start of the current audit log segment. Some entries may arrive twice; none are skipped.
• The audit log was restored from an older backup. The cursor no longer exists in the log. Gardience reports it and carries on from the current end of the restored log.

Delivery is "at least once": after a crash an entry can arrive twice, but over TCP or TLS it is never skipped. Syslog has no delivery receipt, so a loss inside the SIEM itself cannot be detected. The full log and its verification stay on the server.

Related#

• Monitoring
• Backup and restore
• Security model
• Troubleshooting