Notifications
Clear all
Topic starter
18/08/2026 2:28 pm
TL;DR: AxoSyslog shipped 17 releases in one year, compared with five for syslog-ng, while adding new parsing, formatting, and performance features that change how teams manage log transport and transformation, according to Axoflow. The pattern shows that logging pipelines are becoming more programmable, more operationally demanding, and harder to manage with static configurations.
NHIMG editorial — based on content published by Axoflow: AxoSyslog Year 2, a comparison with syslog-ng
By the numbers:
- AxoSyslog shipped 17 releases in one year, compared with 5 releases for syslog-ng over the same period.
- AxoSyslog changed 2,742 files, while syslog-ng changed 995 files in the same year.
Questions worth separating out
Q: How should security teams manage frequent changes to log collection pipelines?
A: Treat log collection as a governed security control, not a background utility.
Q: Why do logging pipeline changes affect IAM and NHI visibility?
A: Identity telemetry only works when events arrive intact and in the right structure.
Q: What do teams get wrong about log pipeline performance tuning?
A: They often optimise for steady-state throughput and miss burst conditions.
Practitioner guidance
- Inventory log-path dependencies Map every collector, parser, destination, and buffering layer that feeds SIEM, SOAR, and audit use cases, then rank them by security criticality.
- Build pipeline regression tests Create test suites for representative event types, including identity, cloud, endpoint, and application logs, and confirm that upgrades preserve field names, timestamps, routing rules, and drop behaviour.
- Govern transformation logic as code Version control filters, parsers, and enrichment rules alongside infrastructure code, with approval gates for any change that can alter evidence quality or event disposition.
What's in the full article
Axoflow's full analysis covers the release-by-release detail this post intentionally leaves out:
- Specific feature comparisons between AxoSyslog and syslog-ng across filtering, formatting, and transport options
- Release-by-release notes on performance, buffering, and scaling changes that matter in production
- Code-level development metrics and per-feature summaries that help operators plan upgrade testing
- Practical context on how each change affects log routing, transformation, and troubleshooting
👉 Read Axoflow’s year-over-year comparison of AxoSyslog and syslog-ng →
AxoSyslog’s faster release cadence: what it means for log pipeline teams?
Explore further
18/08/2026 3:16 pm
Log pipeline change velocity is now a governance problem, not just an engineering one. When a telemetry platform ships frequently, the organisation must continuously re-validate parsing rules, transport settings, and downstream assumptions. That is especially true where logs feed IAM, PAM, and NHI monitoring, because a missed field or altered format can break detection and audit chains. The practical conclusion is that release management for logging should sit within security governance, not outside it.
A question worth separating out:
Q: How can organisations tell whether telemetry changes are safe to deploy?
A: A change is safe only when it preserves event completeness, ordering, and downstream usability. Teams should confirm that SIEM queries still match expected records, that high-value identity events are still retained, and that rollback procedures work if a new parser or destination introduces loss or latency.
👉 Read our full editorial: AxoSyslog’s release cadence shows how log pipelines are evolving
