Syslog Alert Rules

Versus can receive syslog directly from your devices and start a workflow the moment a message matches a rule — a disk-space warning launches a cleanup diagnostic, a failover message opens an incident, a certificate error kicks off a renewal check. Rules are the syslog counterpart of a cron schedule: instead of firing on when, they fire on what the device just said.

It lives under Workflows → Syslog Alert Rules (/syslog-alert-rules) and requires administrator access. The listener itself is switched on under Versus Platform → System → Settings → Syslog.

---

The built-in syslog listener

Versus runs its own syslog receiver inside the backend — no separate collector or relay is required.

Both listeners bind on all interfaces and set SO_REUSEPORT on Linux so every gunicorn worker can share the port. Settings are read once when the process starts.

Where it runs. The listener is an in-process background thread of any serving process (gunicorn, runserver, manage.py run_worker), never of a one-off management command. ENABLE_INPROC_SCHEDULERS=1 forces it on (the dedicated worker), DISABLE_INPROC_SCHEDULERS=1 forces it off (stateless web replicas), and PROCESS_ROLE=gateway disables it on a collector gateway — so on Kubernetes it lives on the single worker behind its own UDP 514 / TCP 1514 Service; see High Availability, DR, and Kubernetes.

HTTP push. A relay or shipper that can't reach the ports can POST lines to /api/syslog-ingest/ as {"lines": [...]} with an X-Versus-Token header matching the backend's SYSLOG_INGEST_TOKEN setting. Lines arriving this way are parsed, stored, and rule-matched identically.

Pointing devices at Versus

For an F5 BIG-IP, Versus configures the device for you. The Syslog card on the device's Base Settings tab shows whether Versus is already a remote syslog server on that box and offers Configure as syslog target, which adds a remote server named versus (UDP, using the Syslog Target Host and UDP Port from Settings) through the standard sys syslog remote-servers configuration; Remove takes it out again. The Add Device wizard has the same step as an on-by-default checkbox for F5 devices, applied best-effort so a missing target host never blocks onboarding.

For any other vendor, point its remote-syslog configuration at the Syslog Target Host and port by hand.

How a message is parsed and stored

Each line has its <PRI> header stripped and mapped to an RFC 3164 severity. Lines in F5's text format — Mon DD HH:MM:SS host severity process[pid]: message — also yield hostname, process, and message, with severity words normalised (err → error, warn → warning, emerg → emergency). Anything that fits neither shape is still stored as info with the raw text, so nothing silently disappears.

The hostname is matched against your inventory — exact hostname first, then a short-name match — to attach the entry to a Device. Browse stored entries on a device's Log tab (latest 500, auto-refreshing every 10 seconds) or query /api/syslog/ with device, hostname, search, and limit filters. An hourly job purges entries older than the retention window.

Rules

Click Add Rule. A rule has these fields:

Through the API a rule also carries a context_template — a JSON object merged into every run it launches. The list shows each rule's threshold, group, target workflow, pattern, cooldown, and when it last fired.

What happens on a match

Every stored line is checked against every enabled rule, in name order — severity → device group → pattern → cooldown — and every rule that passes fires; there is no first-match stop. A firing rule:

1. Creates a workflow run named [Syslog] <rule> — <hostname> — <time>, attributed to syslog-rule:<id> and scoped to the rule's device group (or the device's own group).
2. Passes the event in as run context — device_id, hostname, message, severity, facility, syslog_entry_id — on top of the rule's context_template, so a Python Script step can read exactly which device said what.
3. Starts the run immediately and stamps the rule's last triggered time, which the cooldown checks next time.

Launching a workflow is the only action. Notifications, Desk incidents, ServiceNow records, or remediation all come from the workflow you point the rule at — build it in the Workflow Builder. Rule evaluation is isolated from ingestion: a broken rule or failing workflow is logged and never stops messages from being stored.

Rules only evaluate against syslog messages that actually reach Versus. Enable the listener, set the Syslog Target Host, and configure devices to send logs here first — the page reminds you of this at the bottom.

Syslog rules vs. Observe alert rules

Syslog Alert Rules react to log lines from devices; Observe alert rules evaluate metrics from a datasource and route to contact points. Use a metric threshold for "CPU above 90% for five minutes" and a syslog rule for "the device just logged that tmm restarted".

---

Quick reference