I opened a PR on the audit plugin and would love some feedback, and ideally a review from the XO team: https://github.com/vatesfr/xen-orchestra/pull/10460

The need

We need to send XO audit records to our central syslog server, like the rest of our infrastructure logs. Today the only way I found is to poll audit.getRecords from a cron job, which:

• adds a delay (up to the polling interval),
• needs to track which records were already exported, otherwise records are duplicated or missed,
• needs a long-lived token of a real admin user stored on the machine.

What the PR does

It adds a logRecords option to the audit plugin, disabled by default. When it is enabled, each new audit record is also written to the xo-server logs as a single JSON line (namespace xo:xo-server-audit:records, level info):

xo:xo-server-audit:records INFO {"data":{...},"event":"apiCall","previousId":"...","subject":{...},"time":...,"id":"..."}

The records then follow the existing log pipeline in real time, either stdout → journald → rsyslog or the built-in [logs.transport.syslog], with no extra credentials.

• The record is logged after it has been stored, so the log line is exactly the stored record, including id and previousId.
• Nothing changes when the option is disabled, and the hash chain is not affected.
• I tested it on a from-sources install with rsyslog forwarding to a remote server.

Related: #10461 (already merged) fixed actions made from XO 5 (/v5) being recorded with 127.0.0.1 / ::1 as the user IP. With both changes, the forwarded records contain the real client IP.

Questions

• Does this approach look acceptable to the XO team, or would you prefer something else (e.g. a dedicated syslog transport in the plugin)?
• Is anyone else exporting audit logs to a SIEM/syslog, and would this fit your use case?

Thanks!