News

The rsyslog 2025 Year in Review

Evolving Proven Infrastructure for a New Era

The year 2025 was a defining year for rsyslog. Not because of a single feature or release, but because several long-running threads finally converged: AI-assisted workflows, even fuller multi-core scalability, and native integration with modern observability stacks.

rsyslog 2025 Review: AI First (Human-Controlled), Core Engineering scaling, and Cloud-Native Data Flows.

Rather than chasing trends, rsyslog focused on evolving what it already does best: reliable, high-performance log and data processing for real-world infrastructure.

At the same time, the project continued a shift that has been underway for years. For quite some time now, rsyslog has been more than a syslog daemon. It is increasingly used as a flexible, programmable data and information pipeline that happens to excel at logs.

Continue reading “The rsyslog 2025 Year in Review”

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.

Festive room with a Christmas tree wrapped in glowing data streams, a train labeled “rsyslog express,” and figures symbolizing community and data flow.

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”

rsyslog 8.2512.0: network namespaces, omhttp enhancements and much more

We have released rsyslog 8.2512.0, the December 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 contains three major highlights:

  1. Completion of the foundational Network Namespace implementation, developed by Billie Alsup.
  2. A major omhttp refactoring and feature upgrade, contributed by Adrien GANDARIAS, with substantial integration work on the PR.
  3. The newest contribution: significant mmsnareparse enhancements by André Lorbach (Adiscon), expanding and refining modern SNARE and Windows event parsing capabilities.
rsyslog

Documentation improvements continue across the tree. As always, rsyslog.com/doc documents the current codebase.

Continue reading “rsyslog 8.2512.0: network namespaces, omhttp enhancements and much more”

Keeping rsyslog Accessible Worldwide

The rsyslog project continues to evolve — not only in performance and functionality, but also in how it ensures reliable global access for developers and users. In a time of increasing network fragmentation, rsyslog’s infrastructure is designed to remain reachable, maintainable, and open, regardless of regional conditions.

A long tradition of openness

Since its early days on SourceForge and CVS, rsyslog has steadily adapted to modern platforms while avoiding vendor or platform lock-in. The project migrated from CVS to git, then from self-hosted systems to GitHub, and now extends its reach through a set of regional mirrors. Each transition has followed one guiding principle: technology should remain open and accessible to all.

The rsyslog team has consistently favored diversity in infrastructure — multiple CI systems, different hosting providers, and redundant build and test paths. Even though GitHub currently serves as the canonical repository, rsyslog’s CI ecosystem includes additional components such as Buildbot instances and Gitea-based mirrors, ensuring that no single platform is essential for the project’s operation.

Global mirrors for accessibility

To further strengthen accessibility, rsyslog now provides regional mirrors for easier source code access:

These mirrors are intended purely for accessibility and resilience. They are not regional forks — all contributions and CI processes remain integrated through GitHub, where automated testing and code review take place. For developers affected by access restrictions, the team offers to forward contributions manually, ensuring that valuable work is never lost due to technical or political boundaries.

Built for resilience

This step builds upon rsyslog’s long-standing philosophy of redundant and distributed operations. During the COVID-19 pandemic and the European energy crisis, rsyslog maintained hot-standby mirrors of critical infrastructure — including its websites and CI components — in multiple data centers across regions. At peak uncertainty, DNS round-robin configurations and database replication allowed instant failover between European and U.S. nodes.

DigitalOcean continues to power parts of this network as an open-source sponsor, alongside additional providers that ensure geographic and operational diversity. At one point, when energy availability in Germany became a concern, a key system was temporarily relocated to Norway — demonstrating the flexibility and readiness of rsyslog’s infrastructure. The result is a system designed to survive global disruptions while keeping the project available to everyone who depends on it.

Philosophy and next steps

The addition of regional mirrors is part of a broader commitment to openness, reliability, and technological neutrality. rsyslog remains apolitical but proactive in maintaining accessibility — even as the world becomes more fragmented. The guiding idea is simple and enduring:

Open source should have no borders.

(FR) Le code ouvert ne devrait pas avoir de frontières
(ZH) 开源应该没有边界
(JA) オープンソースに国境はない
(ES) El código abierto no debe tener fronteras
(HI) ओपन सोर्स की कोई सीमाएँ नहीं होनी चाहिए
(AR) المصدر المفتوح يجب ألا يكون له حدود

Future improvements may include additional mirrors or CI redundancy on alternative platforms. For now, users and contributors can find the latest information — including all mirror links — in the main repository README.

Adiscon joins connect.IT Heilbronn-Franken — why this matters to rsyslog

Adiscon, the main sponsor of rsyslog, has joined connect.IT Heilbronn-Franken, a regional non-profit network linking companies, startups, universities, and public institutions across AI, data, cloud, and cybersecurity. We highlight connect.IT because it is a strong regional hub, and we are here to learn.

Expert networks underpin success in today’s complex IT landscape. We team up with peers to learn from real-world challenges and to share what proves to work. (Symbol Image: Rainer Gerhards via AI)
Continue reading “Adiscon joins connect.IT Heilbronn-Franken — why this matters to rsyslog”

rsyslog 8.2510.0 (2025.10) released

We have today released the 8.25100 rsyslog scheduled stable release. This release delivers three main themes: better Windows Security event ingestion, more flexible JSON handling end to end, and pragmatic compatibility fixes across popular outputs and platforms. It also includes steady documentation improvements and CI hardening.

Continue reading “rsyslog 8.2510.0 (2025.10) released”

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.

Symbol Picture for Status Update postings. (Image: Rainer Gerhards via AI)
Continue reading “Modern Snare-Format Parsing Arrives: Introducing the mmsnareparse Module”
Scroll to top