Notifications
Clear all
Topic starter
19/08/2026 3:25 pm
TL;DR: RELP can be used to keep existing rsyslog collectors in place while shifting parsing, normalisation, enrichment, and routing into a programmable security data pipeline, reducing the need to rebuild long-lived logging estates from scratch, according to TENZIR. The key issue is not transport alone but where reliability ends and downstream processing begins, which changes how teams think about log delivery and backpressure.
NHIMG editorial — based on content published by TENZIR: RELP integration for security data pipelines and Syslog estates
Questions worth separating out
Q: How should security teams modernise Syslog logging without rebuilding their collectors?
A: Keep the existing collection layer and move transformation into the pipeline.
Q: Why does transport reliability matter in identity and security log pipelines?
A: Because identity investigations depend on complete, ordered evidence.
Q: What breaks when schema normalization is pushed into every downstream security tool?
A: You get inconsistent parsing, duplicated rules, and brittle integrations.
Practitioner guidance
- Preserve the collector layer and change the destination plane Keep existing rsyslog collectors, queues, and certificates in place while shifting parsing and routing into the downstream pipeline.
- Define the RELP reliability boundary clearly Document that acknowledgement means the event entered the receiving handoff, not that every destination has stored it.
- Centralise parsing and normalisation once Use the pipeline to parse Syslog, retain transport context, and map source-specific formats into a shared schema.
What's in the full article
TENZIR's full article covers the operational detail this post intentionally leaves for the source:
- Exact rsyslog sender configuration for omrelp, including queue persistence and retry settings
- The matching TQL receive pipeline that preserves Syslog boundaries and transport metadata
- Examples of route-based delivery into SIEM and open storage destinations
- The integration guidance for plaintext, TLS, and mutual TLS in collector-to-pipeline handoff
👉 Read TENZIR's analysis of RELP-backed Syslog delivery into a security data pipeline →
RELP for Syslog estates: what it means for security data pipelines?
Explore further
19/08/2026 4:10 pm
RELP solves a reliability problem, not a governance problem. The transport layer can preserve delivery guarantees, but it does not decide whether the right logs are collected, normalised, retained, or routed to the right control owners. That distinction matters in identity-heavy environments where auditability, investigation, and NHI telemetry depend on more than simple message delivery. Practitioners should treat reliable transport as an enabling control, not the security outcome itself.
A question worth separating out:
Q: How do teams decide whether RELP should be used for security logs?
A: Use it when the edge collectors are already stable and the real need is reliable handoff into a programmable pipeline. It is most useful when you want durability at the collector boundary, schema control after ingestion, and flexible routing without replacing the estate.
👉 Read our full editorial: RELP lets security teams modernise Syslog without replacing collectors
