journald-backed logging

By default, modules started by this app log to a flat file under PYOBS_LOG_DIR (via pyobs --log-file). As an alternative, modules can instead log directly into the systemd journal (via pyobs --syslog, a flag pyobs-core already supports) – one switch changes both where modules are started to log and where the log viewer reads them back from, so the two can never drift out of sync with each other.

Choosing a backend

PYOBS_LOG_BACKEND = None       # None (default): auto-detect from pyobsd's own config
                                # "file" / "journald": explicit override

If unset, the effective backend is auto-detected from pyobsd’s own global config file (~/.config/pyobs.yaml, /etc/pyobs.yaml, or /opt/pyobs/storage/pyobs.yaml, first one found wins) – the same file pyobsd (pyobs-core’s daemon manager) reads to decide whether it starts modules with --syslog, so this app’s own choice can’t silently disagree with what pyobsd does for modules it manages itself. An explicit "file"/"journald" setting always wins over auto-detection.

This is a global, fleet-wide switch, not a per-module setting – consistent with PYOBS_LOG_DIR/PYOBS_LOG_LEVEL already being global. Switching backends is a clean cutover: a module’s log history written under the old backend becomes invisible to the log viewer once the switch flips. There’s no dual-read or merge-both-backends logic, and log retention/rotation is unmanaged by this app either way – logrotate for file logs, journald’s own retention settings (SystemMaxUse= etc.) for the journal.

What changes, and what doesn’t

Only the log-related pieces change: start_module() passes --syslog instead of --log-file, and the log viewer shells out to journalctl instead of tail``ing a file. Process management -- PID files, start/stop/restart, status checks, ``psutil-based resource stats – is entirely unaffected either way.

Journal entries are queried by SYSLOG_IDENTIFIER=pyobs (the same for every module) plus PYOBS_MODULE=<name> (the module-distinguishing field), and reconstructed into the exact same text shape the file backend already produces (timestamp, [LEVEL], module name, file:line, message) – so the level/timestamp parsing, filtering, and templates downstream need no per-backend branching at all.

Deployment note: reading the journal cross-user requires the account running pyobs-web-admin to have journal read access – typically satisfied by membership in the adm or systemd-journal group on Debian/Ubuntu-family systems. A dedicated, minimal-privilege service account may need to be added to one of those groups explicitly.