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.
At a glance
What this is: This is a RELP integration analysis showing how existing rsyslog collectors can stay in place while Tenzir takes over downstream parsing, normalisation, enrichment and routing.
Why it matters: It matters because logging estates often carry operational history, trust boundaries and retry logic that teams cannot casually replace, and identity-aware security data pipelines still need reliable transport before any governance or detection value emerges.
Context
Syslog estates are usually the product of years of operational accumulation, not design from first principles. They often span collectors, disk queues, certificates, retry logic and local routing rules across sites and trust zones, which means the transport layer is already part of the security control surface.
RELP changes the delivery contract by adding application-level acknowledgement to Syslog without forcing collectors to be retired. For teams modernising security data pipelines, the relevant question is where reliable handoff ends and downstream processing begins, because that boundary determines backpressure, loss tolerance and where parsing and enrichment should live.
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 RELP improve reliability without making log delivery end-to-end durable?
A: RELP confirms that the receiving pipeline accepted a transaction, but it does not guarantee that every downstream destination stored it. That separation avoids coupling edge collectors to the slowest sink, while still allowing sender-side retry and at-least-once delivery.
Q: What breaks when Syslog collectors are replaced too early?
A: Teams lose mature local controls such as routing rules, queues, certificate handling and retry behaviour that have already been tuned for the environment. The result is usually more migration risk, not better telemetry governance, because the edge layer becomes a redesign project instead of a stable handoff point.
Q: What should security teams do when a log pipeline crosses trust zones?
A: Use authenticated transport, preserve source metadata, and separate the acknowledgement of receipt from the downstream storage guarantee. That keeps the transport boundary clear while still letting security data flow across sites, business units or customer environments with controlled retry behaviour.
Technical breakdown
How RELP changes Syslog delivery guarantees
RELP, or Reliable Event Logging Protocol, adds acknowledgement to Syslog delivery at the application layer. The sender retains each transaction until the receiver confirms acceptance, and it retries if the connection fails before acknowledgement arrives. That creates an at-least-once delivery model, which prevents silent loss but can produce duplicates at the failure boundary. The important architectural distinction is that RELP protects the handoff, not the entire downstream pipeline.
Practical implication: Treat RELP as a reliable ingress control, then design deduplication and downstream durability separately.
Why keeping rsyslog at the edge reduces migration risk
Existing rsyslog collectors often contain years of operational knowledge, including inputs, filters, routing rules, disk queues and certificate handling. Replacing that layer to adopt a security data pipeline creates unnecessary change at the most distributed part of the estate. By keeping rsyslog at the edge and pointing omrelp at a downstream pipeline, teams preserve trusted collection behaviour while shifting transformation work into a programmable layer.
Practical implication: Keep the collection estate stable and move transformation only after the transport boundary is explicit.
Why message boundary preservation matters for security data
RELP preserves the full message boundary, including embedded newlines, and keeps peer address and transaction ID alongside the payload. That matters because security telemetry is only useful when the context that proves where a message came from survives parsing and routing. Once the event is normalised, the pipeline can map raw Syslog into structured fields and route it to different tools without reworking the collectors that produced it.
Practical implication: Retain source context through parsing so routing, diagnostics and investigations do not lose provenance.
NHI Mgmt Group analysis
Transport reliability is now part of security governance, not just plumbing. In logging estates, the control question is no longer whether messages leave the box, but what reliability contract the collector actually provides to downstream security systems. If that contract is vague, teams either over-couple edge collectors to every destination or accept avoidable blind spots. Practitioners should define the acknowledgement boundary before they redesign the pipeline.
Modernising security telemetry does not require collector replacement. The article reflects a broader pattern in security operations: legacy edge systems often hold the most operational maturity, while value shifts into downstream normalisation and routing. For identity and detection teams, that means governance should focus on handoff semantics, queue durability and message provenance rather than ripping out stable collectors. The practical conclusion is to modernise the pipeline without destabilising the edge.
Programmable security data pipelines shift control from destination-specific integrations to schema and routing policy. Once messages are normalised, routing becomes a governance problem rather than an engineering one, because the same event can feed SIEM, data lake and hunting workflows differently. That creates a named control gap we can call the reliability boundary gap: organisations assume a transport acknowledgement means end-to-end durability, when it only means the pipeline received the event. Practitioners should align controls to the real boundary.
Identity context still matters in infrastructure telemetry. Even though this is not an IAM article, the pipeline’s ability to preserve peer address, transaction ID and source shape affects how teams investigate account abuse, failed logons and privileged access paths. Security data pipelines that discard source context weaken later identity-centric detection and forensics. The practitioner takeaway is to preserve transport metadata long enough for downstream correlation.
Long-lived log estates are governance assets, not technical debt by default. The collectors, queues and certificates already operating at the edge encode trust decisions that a new pipeline must respect. Replacing them prematurely can create more risk than it removes, especially across segmented environments and customer-facing trust zones. The correct approach is to evolve the estate in place and move policy to the programmable layer.
What this signals
Reliability boundary gap: teams often assume a transport acknowledgement means the event is safe everywhere, but security pipelines need a separate durability model after handoff. That distinction will matter more as organisations route the same event into multiple tools with different storage and latency characteristics.
Modern log pipelines should be designed around source context preservation, not just message delivery. If peer identity, transaction identity and native message shape disappear too early, downstream correlation becomes weaker even when transport reliability looks healthy.
For practitioners
- Preserve the collector layer Keep rsyslog at the edge and point omrelp to a downstream receiving node instead of rebuilding the estate around the new pipeline.
- Define the acknowledgement boundary Document that RELP confirms handoff into the receiving pipeline, not end-to-end persistence across every downstream destination.
- Retain queue durability on the sender Use disk-assisted queues, queue filenames and shutdown persistence so brief outages do not erase events before retransmission.
- Require mutual TLS across trust zones Use TLS and mutual TLS when collectors send across sites, business units or customer environments so the transport path is authenticated.
- Normalize before routing Parse Syslog into structured events in the pipeline, then fork output to SIEM and open storage based on schema fields such as status and class_uid.
Key takeaways
- RELP shifts the logging problem from raw delivery to where handoff ends and downstream processing begins, which is a governance decision as much as a technical one.
- Existing rsyslog collectors can remain valuable because they already encode queues, retry rules and trust boundaries that are expensive to recreate.
- The practical control is to modernise the pipeline without destabilising the edge, then preserve transport metadata long enough for normalisation and investigation.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0, CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.DS-01 — Data-at-rest | Log queues and delivery assurance affect how security data is protected in transit and at rest. |
| PR.AA-05 — Access Permissions, Entitlements and Authorizations | Mutual TLS and trust-zone boundaries govern which collectors can send to the pipeline. | |
| Recommendation — Protect telemetry queues and handoff paths so log data remains available through temporary outages. Restrict collector-to-pipeline access with authenticated transport and explicit trust boundaries. | ||
| CIS Controls v8 | CIS-5 — Account Management | The article relies on durable collector-side identities, certificates and controlled retry behaviour. |
| Recommendation — Inventory and manage collector identities, certificates and access paths as part of logging operations. | ||
| MITRE ATT&CK | TA0007;TA0009 — Discovery; Collection | Reliable telemetry and source context support detection and investigation of adversary activity. |
| Recommendation — Map log sources to discovery and collection coverage so investigator workflows retain provenance. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Record Review, Analysis, and Reporting | The pipeline exists to normalise, enrich and route audit data for analysis. |
| Recommendation — Centralise audit analysis after normalisation so investigation and reporting use consistent telemetry. | ||
Key terms
- Reliable Event Logging Protocol: RELP is a Syslog transport protocol that adds application-level acknowledgement to event delivery. It lets a sender retain a transaction until the receiver confirms acceptance, which improves reliability for logging pipelines but does not guarantee downstream storage or processing.
- 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.
- Message boundary preservation: Message boundary preservation means the full original event shape survives transport and parsing, including details such as embedded newlines and transaction metadata. It matters in security operations because provenance and source context often determine whether telemetry remains useful for hunting and investigation.
- Security data pipeline: A security data pipeline is the chain that ingests, filters, enriches, normalises, and routes telemetry before it reaches storage or analytics. In practice, it determines which evidence survives into detection, investigation, and compliance workflows, so it is part of the control environment, not just infrastructure plumbing.
Deepen your knowledge
NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. Explore nhimg.org for resources that connect identity governance to the broader security disciplines your programme depends on.
Published by the NHIMG editorial team on August 19, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org