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”imfile inotify handling improved: safer systems, lower rsyslog impact
Large imfile deployments can put pressure on Linux inotify resources. In practice, running out of inotify watches is very uncommon, but when it does happen, the consequences used to be unpleasant and system-wide.
To address this properly, we completed a single improvement delivered in two steps: treat inotify usage as a bounded, shared system resource while keeping rsyslog itself as unaffected as possible.
Continue reading “imfile inotify handling improved: safer systems, lower rsyslog impact”Call for Experiments: Agentic Coding on rsyslog
We are inviting developers, junior engineers, and curious “vibe coders” to experiment with AI code agents on a real production code base: rsyslog.
This is not a sandbox or demo repository. This is mature infrastructure software with real users, strict quality requirements, and a long maintenance history.
If you want to see how far agentic coding really goes, this is a good place to try.
Continue reading “Call for Experiments: Agentic Coding on rsyslog”