rsyslog 8.2606.0: stream compression, Elastic Beats input, and ongoing defensive hardening
We have released rsyslog 8.2606.0, the June 2026 scheduled-stable version. Scheduled-stable releases are bi-monthly snapshots of the daily-stable branch, providing predictable update points with the same functional content as daily-stable at the time of the snapshot.
The main theme of this release is operational robustness under pressure: reducing forwarding bandwidth with experimental stream compression, adding Elastic Beats input support for selected pipeline use cases, and continuing the defensive hardening work across the code base.
The three changes that deserve the most attention are:
- Experimental TCP stream compression for
omfwdtoimtcp - New Elastic Beats / Lumberjack input module via
imbeats - Continued defensive hardening and reliability work
Rsyslog Windows Agent 8.4 Released
A new version of the rsyslog Windows Agent is now available. Version 8.4.0 brings native configuration import/export options, improved service stability, and multiple client bug fixes.
Core Service Engine Updates
In the core engine, a critical concurrency fix has been applied to both the Syslog and RELP forwarding actions. The update resolves shared disk-queue rewrite race conditions that previously occurred when multiple forwarding actions were configured to use the same queue directory simultaneously, ensuring greater data integrity during high-load forwarding scenarios.
Configuration Client Enhancements
Native YAML Support
The Configuration Client now natively supports importing and exporting YAML configuration files. This functionality is fully aligned with the service runtime loader, streamlining configuration backups and migrations across environments.
Reliability & Configuration Handling
Registry-based configuration loading has been hardened to handle fresh installations and incomplete registry data smoothly. Additionally, when encountering unknown configuration blocks—such as those introduced by newer service versions—the client now gracefully skips them with a clear warning rather than failing to load.
Service Management & Stability
Service control logic has been overhauled to handle edge cases such as orphan processes, access control issues, and transitional service states. Administrators now have access to optional process termination options and a direct shortcut to Windows Services.
Timeout messaging during start and stop operations has been clarified for cases where the client stops waiting before Windows completes the service transition. The status bar now explicitly tracks states like Stopping, Starting, and Paused (Reloading), and false stop-timeout errors—where the service had already reached a stopped state—have been eliminated.
Additionally, the Event Viewer now prepends new events following start, stop, restart, or reload actions rather than clearing the existing list, while background threading has been improved to recover cleanly from aborted operations. A client crash on shutdown involving open Event Viewer or Service Management panels has also been resolved.
Released versions
- Service: 8.4.0.239
- Client: 8.4.0.334
Rsyslog Windows Agent 8.3 Released
We have just released Rsyslog Windows Agent 8.3, bringing enhanced interoperability, modern configuration options, and deep operational visibility to our professional Windows-to-Linux logging bridge.
A major highlight of this release is the introduction of YAML configuration support. By adding file-based YAML support for service configuration files, rsyslog Windows Agent now allows administrators to utilize human-readable, industry-standard formatting for their configuration logic. This facilitates easier integration with DevOps toolchains and simplifies the management of complex forwarding rules across diverse Windows environments.
Operational transparency has also been significantly improved with the addition of Runtime Metrics. Administrators can now enable a dedicated HTTPS query endpoint to access real-time service metrics. This feature allows for the direct monitoring of event throughput and service health, making it simple to pull performance data into centralized monitoring systems.
Furthermore, rsyslog Windows Agent 8.3 is ready for the next generation of infrastructure with enhanced Windows Server 2025 support, including improved message fallback and custom-channel cleanup within the Event Monitor service.
Continue reading “Rsyslog Windows Agent 8.3 Released”rsyslog 8.2604.0: YAML configuration, Azure Monitor output, and stronger hardening
We have released rsyslog 8.2604.0, the April 2026 scheduled-stable version. Scheduled-stable releases are bi-monthly snapshots of the daily-stable branch, providing predictable update points with the same functional content as daily-stable at the time of the snapshot.
This release makes rsyslog easier to configure, easier to integrate with modern observability platforms, and more robust under failure conditions.
Four major highlights:
- YAML as an alternative configuration format
- Azure Monitor and HTTP ecosystem integration
- Reliability and security hardening
- Packaging, CI, and portability improvements
Rsyslog Windows Agent 8.2 Released
A new version of the rsyslog Windows Agent is now available, version 8.2. This update delivers targeted stability improvements, performance optimizations for high-throughput environments, and enhanced compatibility with modern Windows operating systems.
Core Service & Engine Enhancements
High-Load Connection & Performance Optimizations
This release significantly improves the agent’s resilience under heavy traffic. Incoming TCP connections now benefit from an increased listen backlog and more reliable handling during connection spikes. Furthermore, timestamp processing across log messages is more reliable, backed by faster parsing for common log timestamp formats. Rule search expression evaluation has also been optimized for greater speed, accompanied by updated documentation.
Stability & Message Handling
Filter rule evaluation has been stabilized to resolve edge-case issues during message processing. Output formatting logic has been refined to ensure predictable message content preparation prior to forwarding or storage. In addition, character set conversions are now clearer and more consistent across operations.
Operating System Compatibility & Diagnostics
Configuration validation has been tightened to ensure reliable loading of configuration version details. Windows Event Log handling has been updated to ensure event category names render correctly on modern operating systems, including Windows 11 and Windows Server 2025. Finally, diagnostic and debug error messages now display correctly across all supported languages and character encodings.
Download
The new release is available for immediate download through the official page:
rsyslog gains native Azure Monitor Logs Ingestion support
Cloud logging environments are rarely simple. Many organizations run mixed estates where on-prem systems, private infrastructure, and cloud services all need to feed into a central observability workflow. That is exactly where rsyslog is supposed to help: reliable, flexible log transport and processing without forcing a one-size-fits-all architecture.
We have now taken another step in that direction.
With the merge of PR #6615 on March 18, 2026, rsyslog now includes a new output module, omazuredce, for sending events directly to Azure Monitor Logs Ingestion. The merged change includes the module itself, documentation, configuration parameters, build integration, and tests.
The rsyslog Evolution: Bridging BSD Heritage with Adiscon Innovation
It is a well-documented fact in the open-source community that rsyslog traces its lineage back to the original 1980s BSD syslogd developed by Eric Allman, primarily through the sysklogd fork. This foundation provided the industry with a standardized way to communicate system events for decades.
However, even before the digital landscape evolved into the era of high-velocity data, the original single-threaded BSD design was known by us to face significant performance bottlenecks. As such, we were well aware of the need to support multithreading.
Continue reading “The rsyslog Evolution: Bridging BSD Heritage with Adiscon Innovation”Docs moved to new Domain
We have today moved the rsyslog official documentation to https://docs.rsyslog.com/doc instead of our long-standing location directly on www.rsyslog.com/doc. All existing links will be properly redirected. The goal is to keep the all-important doc set on its own resource, which helps with scaling and ensuring availability of the documentation.
This move was considered for quite a while and has its pros and cons. The ultimate reason we are doing it, and doing it now is a cyberattack against rsyslog.com which began four days ago. While we mitigated it quickly, it led to unavailability of the doc for around one hour. That made us finally make the decision to move doc to a dedicated system, which we can make more robust than the full featured site with it’s dynamic content.
Continue reading “Docs moved to new Domain”rsyslog 8.2602.0: ROSI Collector, rate-limit policies, stronger TLS, and telemetry integration
We have released rsyslog 8.2602.0, the February 2026 scheduled-stable version. Scheduled-stable releases are bi-monthly snapshots of the daily-stable branch, providing predictable update points with the same functional content as daily-stable at the time of the snapshot.
This release introduces a new production-ready deployment stack and continues significant runtime and security hardening.
Four major highlights:
- ROSI Collector: centralized log collection stack
- Named rate limit policies for imtcp and imptcp
- Security and TLS hardening
- Telemetry and ecosystem integration
What rsyslog is today: a high-performance log ingestion and ETL engine
The site title and GitHub project tagline now describe rsyslog as a high-performance log ingestion and ETL engine.
This is a small but visible change. It reflects how rsyslog is actually used today in modern infrastructures, and it aligns the project’s public description with long-standing technical reality. It is not a rebranding exercise, and it does not change what rsyslog is compatible with or where it comes from.
If you have followed the project for a long time, the wording may stand out. That is intentional. It acknowledges an evolution that has been underway for years and that many users already rely on in production.
Continue reading “What rsyslog is today: a high-performance log ingestion and ETL engine”