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”New: production-ready observability stack integrated into rsyslog
Rsyslog now includes an officially maintained, production-oriented observability stack for centralized logging and monitoring. The stack is designed as a practical reference deployment that can be used directly or adapted to local requirements.
This addition was merged into the rsyslog main branch last Friday via pull request #6325.
The stack is called ROSI, short for Rsyslog Operations Stack Initiative. Its first deliverable, the ROSI Collector, focuses on the central log collection side.
What is included
The ROSI Collector is shipped as a Docker Compose deployment located under:
deploy/docker-compose/rosi-collector/It combines the following components into a coherent setup:
- rsyslog as a centralized log receiver
- Grafana Loki for log storage and querying
- Prometheus for metrics collection
- Grafana with preconfigured dashboards
- Traefik as a reverse proxy with automatic TLS via Let’s Encrypt
The stack is intended to be directly usable while remaining fully transparent and modifiable.
Core properties
- Reference deployment, not a demo
The configuration reflects operational practice and recommended integration patterns rather than a minimal showcase. - Secure transport
Syslog reception over TLS (RFC 5425) is supported, including mTLS. Certificate generation helpers are included. - Immediate observability
Predefined Grafana dashboards provide visibility into log flow, system state, and basic operational metrics without additional wiring. - Operational helpers
Scripts are included for certificate handling, stack status checks, and Prometheus target management. - Integrated documentation
Documentation is part of the main rsyslog documentation.
Why this exists
Many users want a complete and coherent logging and observability setup instead of assembling individual components themselves. The ROSI Collector provides a known-good baseline that can be deployed as-is or adjusted incrementally.
For the rsyslog project, ROSI establishes an explicit operational reference. This improves consistency across documentation, support, and future observability-related work, without changing rsyslog’s role as a flexible and modular logging engine.
Scope and future direction
The current ROSI Collector targets VM-based and single-host Docker environments. These setups are common and often favor solutions that are understandable, inspectable, and low in operational complexity.
ROSI is expected to evolve. Kubernetes support is a targeted extension, but intentionally not part of the initial merge. Establishing a solid and well-understood baseline takes priority over covering all deployment models at once.
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.
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.
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”LibLogging 1.0.8 released
liblogging 1.0.8 [download]
We have released liblogging 1.0.8.
This is a bugfixing release to make the build compatible with newer compilers again.
sha256sum: 6449b7bb75dc282ec6bf1b98a753c950746ea5b190ec9aee097881e4dc5c4bf1
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 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:
- Completion of the foundational Network Namespace implementation, developed by Billie Alsup.
- A major omhttp refactoring and feature upgrade, contributed by Adrien GANDARIAS, with substantial integration work on the PR.
- The newest contribution: significant mmsnareparse enhancements by André Lorbach (Adiscon), expanding and refining modern SNARE and Windows event parsing capabilities.
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”New Liblognorm 2.0.8 stability release
We are pleased to announce the release of liblognorm 2.0.8, the fast lognormalization library.
This is a pure maintenance release aimed at addressing specific border cases to improve overall stability. While liblognorm is the engine behind rsyslog’s log normalization capabilities (specifically mmnormalize), it is as a stand-alone library which is also used by other projects. This update is recommended for all users.
Designing Cost-Efficient and Sustainable Log Pipelines With Rsyslog
For readers who prefer a compact Computer Science style model of the concepts discussed, you will find a concise CS summary at the end of this article.
Modern logging pipelines generate far more data than most platforms can process cost-effectively. Commercial SIEMs, cloud logging services, and large-scale analytics backends typically use pricing models tied to events per second (EPS) or ingest volume. Every unnecessary log message therefore increases cost, CPU load, network traffic, and energy consumption.
Rsyslog provides a flexible architecture that helps control these effects long before data reaches expensive systems. This article explains how rsyslog can be used to build leaner, cheaper, and more sustainable log pipelines without losing the visibility required for operations or compliance.
