syslog-ng copies messages out of the kernel buffer into its own queues, but if destinations are slow those queues eventually fill. At that point, backpressure slows reading from the UDP socket, and the kernel receive buffer begins to overflow. The practical result is message loss at the network ingress point, even though the application is still running normally.
Why slow destinations turn UDP logging into loss at the ingress boundary
syslog-ng can accept UDP traffic faster than downstream destinations can drain it, but only up to the point where its internal queues and the kernel receive buffer stop absorbing bursts. After that, the failure mode is not a graceful slowdown of the sender, it is dropped messages at the network edge. That means the operational question is not whether syslog-ng is running, but whether the end-to-end logging path is sized for peak arrival rates.
For practitioners, the important distinction is that UDP provides no delivery recovery. Once the kernel buffer overflows, the application cannot ask the sender to retransmit what was lost, so the loss becomes invisible unless you are measuring queue depth, socket drops, or downstream ingestion lag. If the bottleneck persists, you can have a healthy daemon and an incomplete audit trail at the same time.
- Kernel receive buffering buys time, not durability.
- Queue growth is a symptom of mismatch between ingress rate and destination throughput.
- Loss happens at the point where buffering is exhausted, not when syslog-ng exits.
What this means for reliability, observability, and forensic completeness
The practical impact is that log completeness depends on the worst-case combination of traffic volume, burstiness, and destination latency. A brief downstream slowdown can be harmless if the queue absorbs it, but sustained pressure causes ingress drops that selectively remove the very records you may need for troubleshooting or incident review. NHI Mgmt Group’s Ultimate Guide to Non-Human Identities is useful here because the same operational pattern often appears when logs are meant to capture machine, service, or automation activity at scale.
That is why syslog pipelines need capacity thinking, not just configuration correctness. If a collector sits behind a bursty UDP source, then queue sizing, destination health, and retention of dropped-message evidence all become part of the logging design. The goal is to detect when backpressure is turning into silent data loss before you lose the records needed to prove what happened.
For additional background on how queueing, buffering, and logging controls are typically handled in security operations, NIST Cybersecurity Framework 2.0 provides the broader govern, protect, detect, respond, recover context, while NIST SP 800-53 Rev 5 Security and Privacy Controls is the tighter control reference for logging, auditability, and configuration management.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | RS.IM-01 — Improvements are identified and implemented | Queue overflow exposes a logging reliability gap that should drive operational improvement. |
| DE.CM-08 — Telemetry is collected and analyzed | The answer depends on monitoring queue depth and socket drops to detect loss early. | |
| PR.PT-05 — Logs are determined, documented, implemented, and reviewed in accordance with policy | The subject is log transport reliability and the completeness of recorded events. | |
| Recommendation — Review dropped-message trends and improve logging capacity before loss becomes routine. Monitor ingestion lag and buffer exhaustion to catch silent log loss in time. Define log retention and transport requirements that account for burst traffic and downstream delay. | ||
| CIS Controls v8 | 8.2 — Collect Audit Logs | Reliable ingestion is required so audit logs are actually captured, not silently dropped. |
| 8.8 — Manage Audit Log Storage | Buffering and backlog handling are part of preserving log integrity under load. | |
| Recommendation — Tune log collection paths so audit events survive peak UDP bursts. Provision sufficient buffering and downstream storage to avoid loss during spikes. | ||
Practitioner Guidance
What to verify: Check whether the collector can sustain peak UDP ingest while every configured destination is intentionally slowed to its realistic worst case. If queue depth rises during normal peaks, you do not yet have a stable logging path.
What to measure: Track kernel socket drops, internal queue occupancy, and end-to-end log latency together. Any one metric alone can look acceptable while message loss is already beginning.
Common mistake: Treating UDP logging as acceptable because the daemon remains up. Availability of the process is not the same thing as delivery of every message.
Practitioner takeaway: Size and monitor the full logging chain for burst tolerance, because once the receive buffer overflows, the failure is silent data loss, not a recoverable backlog.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 17, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
