RELP lets security teams modernise Syslog without replacing collectors

At a glance

What this is: This is an analysis of how RELP can preserve existing rsyslog-based log collection while moving processing into a security data pipeline.

Why it matters: It matters because IAM, NHI, and SOC teams depend on reliable event delivery and consistent identity telemetry, and transport design can determine whether logs are preserved, enriched, and routed safely across trust zones.

👉 Read TENZIR's analysis of RELP-backed Syslog delivery into a security data pipeline

Context

Security logging pipelines often grow around existing collectors, not around a clean-sheet architecture. When rsyslog already spans sites, trust zones, and application estates, the governance challenge is to improve downstream processing without breaking the delivery layer that operators already trust. That is especially relevant where log data supports identity investigation, privilege review, and NHI visibility.

RELP changes the operational boundary by adding application-level acknowledgement to Syslog delivery, while leaving the collector estate intact. For identity and security teams, the practical question is not whether to replace the logging edge, but how to preserve reliable event transport while normalising and routing data for SIEM, hunting, and audit use cases.

Key questions

Q: How should security teams modernise Syslog logging without rebuilding their collectors?

A: Keep the existing collection layer and move transformation into the pipeline. Use RELP or an equivalent reliable transport to preserve delivery, then normalise and route events downstream so you can improve analytics without disturbing the edge estate.

Q: Why does transport reliability matter in identity and security log pipelines?

A: Because identity investigations depend on complete, ordered evidence. If the transport layer drops, reorders, or obscures events, access reviews, incident response, and NHI tracing lose the context needed to reconstruct what happened.

Q: What breaks when schema normalization is pushed into every downstream security tool?

A: You get inconsistent parsing, duplicated rules, and brittle integrations. Each consumer interprets producer-specific syntax differently, which makes correlation harder and increases the chance that identity or privilege events are handled inconsistently.

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.

Technical breakdown

How RELP changes the Syslog delivery boundary

RELP adds reliable delivery semantics on top of Syslog by requiring the receiver to acknowledge each transaction. Until that acknowledgement arrives, rsyslog retains the event and retries on failure, so the sender controls durability before handoff. This matters because it separates transport reliability from downstream processing. The receiving pipeline can batch acknowledgements and ingest events into memory without promising that every later destination has committed the data. That makes RELP a boundary protocol rather than a storage guarantee.

Practical implication: treat RELP as the cutover point from collector durability to pipeline processing, not as end-to-end persistence.

Why parse_syslog and TQL matter after ingestion

Once RELP preserves delivery, the next problem is message structure. Native Syslog and application logs arrive in producer-specific syntax, so the pipeline must parse, normalise, and enrich before routing. Tenzir’s model keeps transport context alongside payload data, including the RELP transaction ID and peer address, which helps with traceability and diagnostics. The important design choice is that parsing happens once in the pipeline rather than being duplicated across every downstream consumer.

Practical implication: centralise parsing and enrichment in the pipeline so log consumers receive a consistent schema and traceable event context.

Why schema-driven routing reduces integration risk

When events share one schema, routing becomes a policy decision instead of a collector redesign. Security teams can fork failed logins to the SIEM, retain the full stream for hunting, and send selected data to open storage or analytics destinations. That architecture keeps collection stable while allowing different destinations to evolve. The operational advantage is that changes to one destination do not cascade back into rsyslog servers, queues, or certificates across the estate.

Practical implication: use schema-based routing to separate collection stability from downstream destination changes.

NHI Mgmt Group analysis

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.

Log pipelines are becoming identity evidence pipelines. As security teams use event streams for access review, incident response, and service-account investigation, the logging architecture starts to influence identity governance. If transport breaks or schemas drift, the evidence trail for human and non-human identity activity becomes fragmented. The practical conclusion is that logging design now belongs in the same governance conversation as IAM and PAM.

Programmable routing is a better fit for distributed estates than collector replacement. Many organisations already have years of operational logic embedded in rsyslog collectors, queues, and certificates. Replacing that estate creates migration risk that is rarely justified when the real need is downstream transformation. The named concept here is collector-to-pipeline decoupling: keep the edge stable, then make the processing layer programmable. Teams should modernise the processing plane before they disturb the collection plane.

RELP makes backpressure visible, but teams still need policy around retention and duplication. Tenzir’s acknowledgement model creates a clean handoff, yet the article is explicit that downstream destinations can still lag or fail independently. That means operational resilience depends on understanding where the reliability boundary ends and on designing for at-least-once delivery. Practitioners should define how duplicates, retries, and storage commitments are handled across the pipeline.

The strongest identity angle here is operational, not theoretical. Identity, NHI, and audit teams rely on log completeness to reconstruct who or what acted, when, and from where. A transport layer that preserves message boundaries and context improves that evidence quality, but only if the downstream pipeline keeps the schema intact. The practical conclusion is to align logging architecture with identity investigation requirements, not just with ingestion throughput.

What this signals

Collector-to-pipeline decoupling: organisations that already operate mature rsyslog estates should view transport modernisation as a way to protect operational continuity while improving downstream detection and audit quality. The design lesson is that change belongs where transformation happens, not where collection already works.

Identity and NHI programmes will increasingly depend on log pipelines that preserve context, because the evidence required for access review and incident reconstruction is only as good as the event boundary and schema integrity. Teams that cannot maintain those properties will struggle to support investigations across distributed estates.

For practitioners

• 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. That reduces migration risk and lets you modernise the processing layer without disturbing the edge.
• Define the RELP reliability boundary clearly Document that acknowledgement means the event entered the receiving handoff, not that every destination has stored it. Make this explicit for SIEM, data lake, and hunting workflows so operators understand where retries and duplicates can appear.
• Centralise parsing and normalisation once Use the pipeline to parse Syslog, retain transport context, and map source-specific formats into a shared schema. That avoids duplicating logic across downstream tools and keeps identity-related events easier to search and correlate.
• Separate high-value log streams by routing policy Fork critical events such as failed logins into the SIEM while preserving the full stream in long-term storage for hunting and audit. This keeps operational detection separate from forensic retention.

Key takeaways

• Reliable transport is only one part of the logging problem, because security value depends on where acknowledgement ends and downstream processing begins.
• Keeping rsyslog at the edge can reduce migration risk while still allowing normalisation, enrichment, and routing in a programmable pipeline.
• Identity and NHI investigations benefit when log architecture preserves schema and context across trust zones, not just when it delivers messages successfully.

Key terms

• RELP: The Reliable Event Logging Protocol is a Syslog transport that adds application-level acknowledgement for event delivery. It lets a sender keep retrying until the receiver confirms acceptance, which reduces silent loss at the handoff boundary while still leaving downstream storage and processing to other systems.
• Collector-to-pipeline decoupling: A design pattern where the log collection layer stays stable while parsing, normalisation, enrichment, and routing move into a downstream processing pipeline. It reduces migration risk in mature estates and makes transformation logic easier to govern centrally.
• At-Least-Once Delivery: At-least-once delivery means a message is confirmed as delivered, but it may be processed more than once. This is a common and practical guarantee in telemetry systems because it is easier to preserve than exact-once delivery, especially when retries, crashes, and batching are part of the design.

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

👉 TENZIR's full article covers the rsyslog configuration and TQL pipeline examples behind the handoff model

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, IAM, and secrets management. It is suitable for practitioners who need to connect identity controls to broader security operations and auditability.