# rsyslog: a syslog daemon whose headline speed number dates to 2013

> rsyslog is the C log routing engine most Linux distributions ship already, with loadable modules, external Python and Perl outputs, and repository topics naming elasticsearch, kafka and mongodb as destinations. Its throughput figure was measured on version 7 in December 2013, which is the first thing to check before you adopt it.

**rsyslog/rsyslog** — High-performance log ingestion and ETL engine

- Repository: https://github.com/rsyslog/rsyslog
- Website: http://www.rsyslog.com
- Stars: 2,340 · Forks: 739
- Language: C
- License: LGPL-3.0
- Published: 2026-10-14 · Updated: 2026-10-14 · Language: en
- Canonical page: https://hysenlabs.com/projects/rsyslog-rsyslog

## One million messages per second, measured on version 7

The headline number sits in the opening paragraph: over one million messages per second to local destinations under minimal processing, with `(based on v7, Dec 2013)` attached to it. The recent tags all carry an 8.x version, so that figure describes code more than a decade older than the branch you would clone today. The sentence right after it promises that performance stays excellent even with complex routing and remote forwarding, and it names no hardware, no message size and no date of a rerun.

Read it closely, because the architecture around the claim has moved too. rsyslog began as a plain syslogd replacement and grew into a pipeline that ingests from many sources, transforms them and outputs to many destinations. Nobody adopts it for a line rate alone; the reason to run it is the rule set deciding which facility lands in which file, database or queue.

## Loadable modules, a grammar directory and three languages at the root

The repository root describes the shape better than any feature list. `Makefile.am`, `configure.ac`, `autogen.sh` and `grammar/` belong to an autotools build of C, while `plugins/`, `runtime/` and `compat/` carry the module machinery and the transports. Output plugins written in Python or Perl live outside the C core and are documented separately in `plugins/external/README.md`, which is how a destination gets added without recompiling the daemon.

Three more top-level entries explain why a C daemon reaches past its own language: a Maven `pom.xml` for the Java side, `setup.cfg` for the Python side, and `README.AIX`, `README.AIX.IBM` plus a `solaris/` directory for AIX and Solaris. Licence terms are LGPL-3.0, and the root carries `COPYING`, `COPYING.LESSER` and `COPYING.ASL20` beside them.

## Branch guidance names master while the default branch is main

A repository fact and an instruction in the README disagree. The default branch is `main`, while the branch guidance states that the `master` branch tracks active development and that production users should prefer the newest tag instead. Anything scripted against this project, a mirror job or a CI checkout, has to choose a name deliberately rather than following the written advice.

Documentation carries the same shape problem. The README sends documentation contributions to the `doc/` directory, and the root also holds a separate `docs/` directory, so the two are not interchangeable in a checkout. Per-OS build requirements for CentOS, Ubuntu, Debian and SUSE are not listed either; the file points readers to the online build instructions and to a fuller version of itself.

## Distribution packages first, official builds when the repository lags

The shortest route is your distribution package. rsyslog is available in most Linux distribution repositories and is often pre-installed, so nothing needs downloading before it runs. The problem the project names is lag, since distributions may trail behind in packaging the newest versions, and for hosts that need a current build it maintains its own RPM-based packages, an Ubuntu repository and a Debian repository, plus official container definitions.

A source build needs three support libraries, given as the build environment requirements:

```bash
pkg-config
libestr
liblogging
```

The last one is the stdlog component used by the testbench. Anyone working on the latest git master is told to build the support libraries from source rather than reach for the packaged copies.

## Four installation routes, four upgrade paths, no named alternative

No competing daemon is named anywhere in the README, so the comparison that matters happens inside rsyslog. There are four ways to reach a running instance, and each one hands you a different upgrade path.

A distribution package is old but rides the distribution's own update process. The project RPM, Ubuntu and Debian packages are current and sit outside that process, so update timing follows the project instead. Official containers put the daemon and its configuration into an image, with the definitions kept in the repository. A source build is current and lands entirely on you, together with the support libraries. Teams pick differently depending on whether they trust the distribution's cadence or the project's, and the README does not document a rollback procedure for any of the four routes.

## Development containers absorbed the old rsyslog-docker repository

Container work moved into the main tree. Ready-to-use build environments live in `packaging/docker/dev_env`, and those images were previously built in a separate rsyslog-docker repository before being maintained here, with runtime container definitions under `packaging/docker/rsyslog` and the details in `packaging/docker/README.md`.

The single executable line the README offers belongs to that workflow, and it is a testbench run with four parallel jobs:

```bash
make check -j4
```

What it does not tell you is what a pass looks like. No expected output, no duration and no subset selector appear beside it, so a new contributor learns the result by running it. The root `KNOWN_ISSUES` file records what is still broken, and `diag.sh` appears in the tree with no explanation in the README.

## An experimental assistant that admits it can emit wrong configs

Two AI features sit inside the project and both carry warnings. The rsyslog Assistant at rsyslog.ai answers configuration and troubleshooting questions, covers both the Linux daemon and the Windows Agent, and is version-aware, but it is marked experimental and may occasionally generate incorrect config examples, which is why the instruction is to review anything it produces before applying it. Pull request review runs Google Gemini over new PRs, and those comments are informational only, with every contribution still reviewed by human experts.

The root shows how far that tooling reaches. `AGENTS.md` covers contributors working with AI coding agents such as GitHub Copilot and OpenAI Codex, and the tree holds `.agent/`, `.codex/`, `.gemini/` and `jules.yaml` at the top, plus a top level ai directory of its own. For commit messages there is a separate assistant at rsyslog.com/tool_rsyslog-commit-assistant, with the rule that the substance goes into the message itself rather than into the pull request body.

## Adiscon funds it, consensus steers it, a mirror keeps it reachable

Money and decisions are deliberately separated. The project is sponsored primarily by Adiscon while technical decisions are made independently via consensus, and there is no formal membership beyond participation. The founder and maintainer, Rainer Gerhards, publishes technical commentary on rainer-gerhards.net alongside the official site rsyslog.com, its RSS feed, a Telegram channel and a WhatsApp channel.

Reachability gets a section of its own, which few project files do. GitHub is the canonical home, and a European mirror hosted on DigitalOcean at github-mirror.rs serves regions where GitHub access is limited; contributors there are asked to contact the project so a patch can be routed for review. Help otherwise runs through GitHub Discussions, GitHub Issues and a mailing list at lists.adiscon.net/mailman/listinfo/rsyslog.

Momentum shows up in the dates: the recent tags 8.2608.0 and 8.2604.0 carry 2026-08-18 and 2026-04-21, and the last push landed on 2026-09-28. The same file's table of contents also promises a Sponsors section and a Legal Notice (GDPR) section, so read that notice before a deployment instead of expecting the repository files to answer data handling questions.

## Conclusion

Adopt rsyslog where hosts already speak syslog and routing has to be decided in configuration rather than in a separate pipeline service. Stay away if your buying criterion is a searchable log store, because this project moves and reshapes messages rather than keeping them. Verify two things before rollout: time your own message rate against your own disk, since the only published throughput figure names version 7 and December 2013 with no hardware, and check which branch your clone actually fetches.

## FAQ

### How do I install rsyslog on a Linux system?

It is available in most Linux distribution repositories and is often pre-installed already. When a distribution lags behind, the project maintains its own builds for RPM-based systems, Ubuntu and Debian, plus official container definitions.

### What does it take to build rsyslog from source?

The build environment requirements list `pkg-config`, `libestr` and `liblogging`, the last being the stdlog component used by the testbench. Anyone working on the latest git master is told to build the support libraries from source rather than use packaged copies.

### How do I run the rsyslog test suite?

Run `make check -j4` inside the development container. Ready-made build environments live in `packaging/docker/dev_env`, and the runtime container definitions live in `packaging/docker/rsyslog`.

### Can AI tools help me write rsyslog configuration?

The project runs an experimental assistant at rsyslog.ai for configuration and troubleshooting, and it warns that the assistant may occasionally generate incorrect config examples, so review before applying. Pull request review also uses Google Gemini, but those comments are informational only and every contribution is still reviewed by human experts.

### Who maintains rsyslog and how do I report a problem?

Sponsorship comes primarily from Adiscon, while technical decisions are made independently via consensus with no formal membership beyond participation. Problems go to GitHub Issues and GitHub Discussions, and there is a mailing list at lists.adiscon.net/mailman/listinfo/rsyslog.

## Sources

- [License: LGPL-3.0](https://github.com/rsyslog/rsyslog/blob/main/LICENSE)
- [Project website](http://www.rsyslog.com)
- [README](https://github.com/rsyslog/rsyslog/blob/main/README.md)
- [Releases](https://github.com/rsyslog/rsyslog/releases)
- [rsyslog/rsyslog on GitHub](https://github.com/rsyslog/rsyslog)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/rsyslog-rsyslog