Notifications
Clear all
Topic starter
19/08/2026 3:47 pm
TL;DR: Syslog pipelines that were designed for small environments can become bottlenecks under bursty, high-volume telemetry, and Axoflow argues that throughput, buffering, transport choice, and backpressure all shape whether logs arrive intact. The operational lesson is that reliability, not raw ingestion capacity, determines whether security and identity evidence remains usable during incidents and audits.
NHIMG editorial — based on content published by Axoflow: Syslog Scaling and Performance Considerations
By the numbers:
- 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
- Only 5.7% of organisations have full visibility into their service accounts.
Questions worth separating out
Q: How should security teams design logging pipelines for bursty incident traffic?
A: They should size collectors, relays, and queues for peak event surges rather than average throughput, then test those assumptions under simulated incident conditions.
Q: Why do logs become unreliable when syslog pipelines scale poorly?
A: Because the same pipeline that handles routine traffic can collapse under burst load, complex parsing, or downstream throttling.
Q: What signals show that logging infrastructure is no longer keeping up?
A: Watch queue depth, processing latency, CPU pressure, disk I/O, and any increase in throttled or dropped messages.
Practitioner guidance
- Design for peak telemetry bursts Model collector and relay capacity against incident-time surges, not average daily message rates.
- Separate evidence-grade logs from low-value streams Shards pipelines so security, identity, and compliance events follow a durable path, while debug and verbose operational logs can be routed elsewhere.
- Use acknowledged transports where loss is unacceptable Keep UDP only for telemetry that can tolerate loss, and move sensitive or forensic logging to TCP, TLS, or OTLP/gRPC where flow control, retries, and acknowledgments preserve delivery.
What's in the full article
Axoflow's full article covers the operational detail this post intentionally leaves for the source:
- Protocol-by-protocol throughput and reliability trade-offs for UDP, TCP/TLS, and OTLP/gRPC
- Queue sizing and buffering patterns for resilient relay and collector design
- Pipeline sharding approaches that separate security logs from debug and operational noise
- Monitoring guidance for ingest rate, latency, throttling, and dropped-message detection
👉 Read Axoflow's analysis of syslog scaling and performance trade-offs →
Syslog scaling and reliability: what SOC and IAM teams miss?
Explore further
19/08/2026 4:24 pm
Syslog reliability is an identity evidence problem as much as a logging problem. Security teams often treat telemetry as an infrastructure feed, but the operational value of logs is inseparable from whether they preserve access history, authentication events, and privileged actions. When service account activity or token misuse happens during a burst, missing messages create an evidentiary gap that weakens both incident response and auditability. Practitioners should treat log durability as part of identity governance, not a separate engineering concern.
A question worth separating out:
Q: How do compliance and incident response change when telemetry loss is possible?
A: Teams need stronger controls around durability, retention, and routing for security and identity logs, because missing records can undermine audit conclusions and post-incident reconstruction. The practical response is to classify logs by evidentiary value and give the critical path better buffering, monitoring, and transport guarantees than routine operational data.
👉 Read our full editorial: Syslog scaling bottlenecks expose reliability gaps in security telemetry
