rsyslog Windows Agent 26.10 Technical Release Notes
Release date: October 7, 2026
Service build: 26.10.0.354
Configuration Client build: 26.10.0.443
User Interface build: 26.10.0.1018
Upgrade assessment
Recommendation: Recommended update
Why update now: This release updates included OpenSSL libraries to 3.5.9 and corrects configuration editing and service diagnostics in the User Interface.
If you defer: Existing processing continues, but included OpenSSL libraries stay on the previous update, and the configuration-editing and diagnostic corrections in this release remain absent.
Who benefits most: Administrators who use TLS and anyone who edits configuration or follows service diagnostics in the User Interface.
Upgrade and verification: Update rsyslog Windows Agent using the normal supported upgrade path. Confirm that the installed service version is 26.10.0.354. Test the changed functions that are relevant to your deployment.
Important changes
OpenSSL 3.5.9
- Change: The included OpenSSL libraries are updated to 3.5.9.
- Operational impact: TLS-using actions and services run with the updated library.
- Applies to: All rsyslog Windows Agent installations.
- Verification: After upgrade, confirm the installed service build and exercise one TLS-using function you rely on.
Configuration interface and diagnostics
- Change: Workbench edits are validated before saving, and the previous document is restored when a save fails. Leaving the page, reloading, switching the configuration source, or restarting asks whether to save or discard unsaved changes. Move rule up moves the selected rule when two rule names differ only by punctuation. Failures from an older remote registry session are ignored, and service commands that would change a remote target are blocked. Empty optional allowed-peer and TLS rows no longer block other edits. Configuration-tree navigation is denser, selection feedback is clearer, and license file path handling is clearer. The empty Advanced page is removed. Debug-log follow stays with appended lines and a replaced log file.
- Operational impact: Configuration edits are less likely to be lost or applied to the wrong rule, and commands that would change a remote target are blocked.
- Applies to: rsyslog Windows Agent installations using the User Interface for configuration or service diagnostics.
- Verification: Save a valid edit and a failing edit, move two rules whose names differ only by punctuation, and follow a debug log while new lines are appended.
User Interface
- Workbench edits are validated before saving. If a save fails, the previous document is restored.
- Leaving the page, reloading, switching the configuration source, or restarting asks whether to save or discard unsaved changes.
- Move rule up moves the selected rule when two rule names differ only by punctuation.
- Failures from an older remote registry session are ignored, and service commands that would change a remote target are blocked.
- Empty optional allowed-peer and TLS rows no longer block other edits to the selected service.
- Configuration-tree navigation is denser, selection feedback is clearer, and license file path handling is clearer.
- The empty Advanced page is removed.
- Debug-log follow stays in view when lines are appended or the log file is replaced.
Partner deployment notes
Availability: Use the canonical rsyslog Windows Agent download and this Technical Release Notes page as the release reference; do not use temporary build links as the long-term reference.
Localization: The User Interface translation workflow is being prepared. Translation strings and contribution guidance will be published in the Adiscon community repository when available.
Partner verification: Confirm the installed service, Configuration Client, and User Interface builds. Save a configuration change in the User Interface and, where relevant, exercise one TLS-using function.
Related links
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.
Season’s Greetings from the rsyslog Project
As the year comes to a close, we would like to send our warm thanks to everyone who makes the rsyslog project what it is.
To our users, contributors, and community members around the world: thank you for your trust, feedback, bug reports, patches, documentation work, and thoughtful discussions throughout the year. Open source only works because of people who care, and rsyslog is no exception.
Continue reading “Season’s Greetings from the rsyslog Project”Native OpenTelemetry Export Arrives: Introducing the omotlp Output Module
With the latest merge into the rsyslog development branch, rsyslog now provides a native OpenTelemetry (OTLP/HTTP) log exporter. The new omotlp output module enables rsyslog to send logs directly to any OTLP-compliant collector without the need for sidecars or protocol translators.
This is Phase 1 of the OpenTelemetry integration. It focuses on the OTLP/HTTP JSON transport, including batching, retry semantics, TLS/mTLS, and proxy support. Additional transport variants (gRPC and HTTP/protobuf) may follow in future phases.
Continue reading “Native OpenTelemetry Export Arrives: Introducing the omotlp Output Module”rsyslog AI Assistant Update
We’ve applied a small knowledge base correction to the rsyslog AI Assistant (ChatGPT and DigitalOcean Gradient versions), both available at rsyslog.ai.
While minor, this update improves answer accuracy and consistency for configuration and troubleshooting topics.
New rsyslog AI Assistant — powered by DigitalOcean Gradient
We are excited to introduce a second rsyslog Assistant, now live at rsyslog.ai. It runs on the DigitalOcean Gradient platform and uses the Llama 3.3 Instruct (70B) open-source model — offering no-login, privacy-friendly, and open access to rsyslog expertise.
Modern Snare-Format Parsing Arrives: Introducing the mmsnareparse Module
Last September, Rainer Gerhards revisited a long-standing challenge: normalizing legacy Windows Snare logs for use in modern observability pipelines.
In his article Revisiting old style Windows Log Schema Mapping, he explored heuristic and AI-assisted methods to better handle these still-prevalent formats.
That effort has now resulted in production-ready code: the new mmsnareparse module — already part of the daily stable build and scheduled for inclusion in the 8.2510.0 stable release.
We’re looking for testers right now.
If your systems still forward Windows Security logs in Snare format, please deploy mmsnareparse and let us know how it performs in your environment.
Real-world feedback will directly shape future development.
DigitalOcean Renews Sponsorship – A Strong Foundation for rsyslog Innovation
We are pleased to announce that DigitalOcean has renewed its sponsorship of the rsyslog project. The partnership between rsyslog and DigitalOcean has been in place for many years and continues to be an essential part of our technical infrastructure.
CI extended: Debian 13, openEuler 24.03-LTS, Fedora 42, Debian sid
TL;DR: We added Debian 13, openEuler 24.03-LTS, Fedora 42, and Debian sid to rsyslog CI. We retired Ubuntu 18.04. CI runs use GitHub-hosted runners plus self-hosted workers, with infrastructure sponsored by GitHub, DigitalOcean, opencsv, and Adiscon.
Rsyslog project update: faster reviews, clearer process
Summary
We are tightening our contribution workflow to improve review speed and predictability. Expect reasonable turnaround times, not instant responses. This is rolling out now.
What changes now
- Initial PR look: Maintainer aims to glance at each new PR within 3 business days.
- AI review on PRs: Runs automatically on open. In our experience it is 90%+ correct and provides actionable items.
- Full review trigger: Deeper maintainer review typically follows when CI is green and AI items are fixed or clearly explained.
- Old issues policy: No mass closures. We are revisiting older items with AI assist and closing them for the right reasons, often by implementing what is needed.
- Labels and dashboards: We are formalizing labels (including good first issue) and lightweight dashboards to make navigation and triage easier. Details will follow in a separate post.
- Responsible AI First: We use AI to speed feedback, but only where it adds real value and the results make sense.