feat: Syslog backend

[ruslandoga]

Continues from #2067

---

TODOs

• Enable payload encryption with user-uploaded cipher keys
• Format log messages according to syslog protocol RFC5424
• Deliver over TCP as described in RFC6587 (implemented with octet counting)
• TLS support based on RFC5425
• Move telegraf usage to a docker-compose workflow with write-to-file assertions
• CI workflow should also be updated
• Create TCP backend via /backends liveview form
• clean up tests
• add Syslog Structured Data to config
• support connection URI in config
• more tests
• try it out irl with some hosted syslog sink service

---

Questions

• How should LogEvent data be mapped to the Syslog hostname, app-name, procid, and msgid fields?
• How should Syslog Structured Data be handled, should it be populated from LogEvent? Some platforms like Better Stack rely on SD for authentication. Maybe SD can be provided via config.
• Should this backend expose the Broadway topology parameters in the backend / application configuration?
• Instead of requiring separate host, port, and tls fields, could it be a connection URI (e.g., tcp://host:port, or ssl://host:port or tls://host:port)? It might even contain cipher keys/certs/... like in psql-style urls.

[ruslandoga]

I wonder if we need to add handle_failed and retry there. We can keep something like :attempt in the ack metadata to stop retrying after attempt > 3 or something like that.

[Ziinc]

lets default to 1 retry which is what all backends are standardizing to

[Ziinc]

How should Syslog Structured Data be handled, should it be populated from LogEvent? Some platforms like Better Stack rely on SD for authentication. Maybe SD can be provided via config.

Yes lets use a config for it since it is not widely supported

Should this backend expose the Broadway topology parameters in the backend / application configuration?

no don't expose those. we should manage them automatically under the hood.

Instead of requiring separate host, port, and tls fields, could it be a connection URI (e.g., tcp://host:port, or ssl://host:port or tls://host:port)? It might even contain cipher keys/certs/... like in psql-style urls.

Yes, we can do that, should be an either/or validation.