Docs: Remote log forwarding doc: fix RFC5424 template and expand guidance

[dzarzycki]

Summary

The Configuring Remote Log Forwarding doc has a template example that fails with strict RFC5424 collectors (Promtail/Loki, Fluent Bit, modern Graylog), and several common topics are missing.

Bugs

1. %PROTOCOL-VERSION% renders as 0 but RFC5424 requires 1

The documented template:

GRAYLOGRFC5424,"<%PRI%>%PROTOCOL-VERSION% %TIMESTAMP:::date-rfc3339% ..."

renders messages as <30>0 2026-04-15T... on the wire. RFC5424 parsers reject version 0 with errors like expecting a version value in the range 1-999 [col 4].

Fix: replace %PROTOCOL-VERSION% with literal 1:

<%PRI%>1 %TIMESTAMP:::date-rfc3339% ...

2. Template name GRAYLOGRFC5424 is misleading

This is standard RFC5424 — not Graylog-specific. The name confuses users sending to Loki, Splunk, or other collectors. Suggest renaming the example to RFC5424 or VERGESYSLOG.

Content gaps

3. Multi-cluster hostname handling

%HOSTNAME% resolves to just node1, node2 — ambiguous when monitoring multiple VergeOS clouds. Document the common patterns:

• %HOSTNAME% — single-cluster only
• mycluster-%HOSTNAME% — cluster-prefixed (recommended for multi-cluster)
• %HOSTNAME%.mycluster.example.com — FQDN style

4. TCP vs UDP trade-off

Currently the doc shows both @@host:514 (TCP) and @host:514 (UDP) but doesn't explain the choice. Add a brief note:

• TCP (@@) — guaranteed delivery, recommended for audit/compliance
• UDP (@) — fire-and-forget, lower overhead, can drop packets under load

5. Port 514 assumes root privileges

Most modern collectors run unprivileged (Docker containers, Loki/Promtail) and listen on port 1514 instead. Mention this as a common alternative.

6. Verification guidance is vague

Add concrete troubleshooting steps:

• tcpdump -i any -A port 1514 on the collector host to confirm packets are arriving
• Inspect the wire format to catch version-number issues (<PRI>1 for RFC5424, <PRI> alone for RFC3164)

7. Tested collectors section

Add a brief table of known-working targets with config notes:

• Graylog
• Loki (via Promtail)
• Splunk
• Elasticsearch (via Logstash)
• Plain rsyslog relay

Recommended canonical template

RFC5424,"<%PRI%>1 %TIMESTAMP:::date-rfc3339% %HOSTNAME% %APP-NAME% %PROCID% %MSGID% %STRUCTURED-DATA% %msg%\n"

With a second multi-cluster example showing the hostname prefix pattern.

Context

Encountered while setting up Promtail/Loki for a demo VergeOS cloud. Spent time debugging the version-0 parse errors before capturing the wire format with tcpdump and tracing it back to the documented template.

[dzarzycki]

Additional context: RFC3164 vs RFC5424

Clarifying the two format options since both come up in VergeOS deployments.

RFC3164 (BSD Syslog, formalized 2001, originally 1980s)

The original Unix syslog format. Informational RFC, not a real standards-track document.

Wire format:

<30>Apr 15 11:27:54 node1 appserver[3499]: User logged in

Example VergeOS template:

VERGEFMT,"<%PRI%>%timegenerated% vergesystemname-%HOSTNAME% %syslogtag%%msg%\n"

Pros

• Universally supported by every syslog daemon and collector
• Simple, compact, human-readable
• Works out of the box with most tools, no config tuning

Cons

• No year in timestamp (Apr 15 11:27:54 — year inferred from when received)
• No timezone — assumes local time, creates chaos across TZ boundaries
• No sub-second precision
• Hostname is free-form — no standard for FQDN or cluster prefix
• PID embedded in tag (tag[pid]:) — parsers have to split it out
• No structured data — everything is free-text in %msg%
• 1024-byte message limit (often exceeded in practice, inconsistent handling)

RFC5424 (2009, actual standards-track RFC)

Modern replacement designed to fix RFC3164's problems.

Wire format:

<30>1 2026-04-15T11:27:54.123456-04:00 node1 appserver 3499 LOGIN [auth@32473 user="dz"] User logged in

Example VergeOS template:

VERGESYSLOG,"<%PRI%>1 %TIMESTAMP:::date-rfc3339% vergesystemname-%HOSTNAME% %APP-NAME% %PROCID% %MSGID% %STRUCTURED-DATA% %msg%\n"

Pros

• Full ISO 8601 timestamps with timezone and microsecond precision
• Separate fields for hostname, app name, PID, MSGID — parsers don't have to guess
• Structured data ([auth@32473 user="dz" ip="1.2.3.4"]) — machine-parseable without regex
• 65KB message limit — room for stack traces, JSON payloads
• Explicit version field — lets format evolve without breaking parsers
• Unicode/UTF-8 support
• Official IETF standard — vendors align to it for long-term compat

Cons

• Older collectors may not parse it (legacy SIEM appliances, embedded devices)
• Slightly more verbose
• Some tools require explicit config to enable RFC5424 mode
• Less human-readable at a glance when tailing raw

When to pick which

Situation	Pick
Modern stack (Loki, Splunk, Elastic, recent Graylog)	RFC5424
Multi-timezone deployment	RFC5424 (timezone matters)
High-volume logging with parsing downstream	RFC5424 (structured data saves CPU)
Legacy appliance / older SIEM	RFC3164 (often forced)
Unknown collector, want broadest compat	RFC3164
New deployment where you control the collector	RFC5424

Recommendation for the docs

Offer both templates — RFC5424 as the recommended default for new deployments, RFC3164 as the compatibility option. Label them clearly so users can pick based on their collector. Include a one-liner on the trade-off rather than making readers research it themselves.