Implements the planned RELP feature from the README.
## What
- New `RELPHandler` that delivers log messages to a remote rsyslog server via RELP (TCP)
- Configured via `LOGGER_RELP_URL` env var (e.g. `tcp://rsyslog.example.com:2514`)
- Pure Go implementation — no CGO, no librelp dependency
## How it works
- Lazy connection on first log message
- RELP session: `open` handshake → `syslog` commands → graceful `close`
- Per-message acknowledgement (waits for `rsp 200` from server)
- Auto-reconnect on connection failure
- Messages formatted as RFC 5424 syslog with structured data from slog attributes
- Transaction number tracking with proper wraparound at 999,999,999
## Notes
- Also includes the deadlock fix from #3 (cherry-picked) since it was needed as a clean base
- No TLS support yet (could be added later via `tls://` scheme)
- Default port 2514 (standard RELP/imrelp port)
Closes #5
stith/gorelp — simple client+server, but server-only focus (no client Send method). Last commit ~10 years ago.
thierry-f-78/go-relp — server-side only (designed for receiving RELP). No client implementation.
Neither provides a usable RELP client — they're both server/receiver libraries. For sending logs via RELP we'd need a client implementation, which is what this PR does.
That said, the protocol is simple enough (framed TCP with txn ack) that a clean ~200 line implementation is reasonable. Want me to slim down the current implementation, or would you prefer a different approach (e.g. plain syslog over TCP instead of RELP)?
There are two Go RELP libraries:
1. **[stith/gorelp](https://github.com/stith/gorelp)** — simple client+server, but server-only focus (no client Send method). Last commit ~10 years ago.
2. **[thierry-f-78/go-relp](https://github.com/thierry-f-78/go-relp)** — server-side only (designed for receiving RELP). No client implementation.
Neither provides a usable RELP *client* — they're both server/receiver libraries. For sending logs via RELP we'd need a client implementation, which is what this PR does.
That said, the protocol is simple enough (framed TCP with txn ack) that a clean ~200 line implementation is reasonable. Want me to slim down the current implementation, or would you prefer a different approach (e.g. plain syslog over TCP instead of RELP)?
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Implements the planned RELP feature from the README.
What
RELPHandlerthat delivers log messages to a remote rsyslog server via RELP (TCP)LOGGER_RELP_URLenv var (e.g.tcp://rsyslog.example.com:2514)How it works
openhandshake →syslogcommands → gracefulclosersp 200from server)Notes
tls://scheme)Closes #5
isn't there a relp library we can use?
@clawbot ping
There are two Go RELP libraries:
Neither provides a usable RELP client — they're both server/receiver libraries. For sending logs via RELP we'd need a client implementation, which is what this PR does.
That said, the protocol is simple enough (framed TCP with txn ack) that a clean ~200 line implementation is reasonable. Want me to slim down the current implementation, or would you prefer a different approach (e.g. plain syslog over TCP instead of RELP)?
Pull request closed