Tech Enthusiast. Nature Lover. Computer Geek. rsyslog lead developer.
After 24 months of focused evaluation and careful experimentation, we’re excited to announce a major shift in the evolution of rsyslog: we’re going AI First.
This marks the beginning of a strategic transformation in how we design, develop, and support rsyslog and its ecosystem. While today’s post is just a short announcement, it lays the groundwork for a series of updates to follow — including deep dives into what we’re doing, why, and how it benefits you.
As you probably have noticed, we have made some considerable progress on the presentation of the documentation on the rsyslog site. Also, the site itself received some upgrades.
The current state of rsyslog documentation and its representation on our official website has been a subject of concern within the professional community. We are initiating a comprehensive project aimed at systematically addressing these issues. Over the coming weeks, stakeholders can expect a series of methodical changes, some of which may be significantly transformative.
Trying to debug rsyslog.conf issues? This can be hard. Learn here why, and how you can avoid problems. Did you know? Upon startup, rsyslog reads its config file, usually located in /etc/rsyslog.conf. While doing so, it can include config snippets usually located in /etc/rsyslog.d. But no matter if given directly inside the rsyslog.conf, or inside a snippet, the overall config is just a single text document made up of the main config file and the snippets. This is important to note when debugging rsyslog problems.
Yesterday, we held the first open meeting for the (r)syslog community. It was announced on very short notice, but we still had more than 10 participants. Even more important, we had some great discussions. So I call the concept a “success” and plan for more to come.
For everyone who could not attend, here is the meeting recording:
Please accept YouTube cookies to play this video. By accepting you will be accessing content from YouTube, a service provided by an external third party.
If you accept this notice, your choice will be saved and the page will refresh.
I am thinking quite a while about doing online seminars or meetings for folks interested in rsyslog. After some prep work, I decided to do an experiment and invite all of you to the rsyslog community’s first open online meeting. It will be held at 2020-09-29 at 3p UTC (5p CEST, 11a EDT, 8a PDT). The meeting URL is https://meet.rainer-gerhards.de/syslogOpenMeeting. Meeting language is English.
This is more than a community experiment. I have worked on setting up a decent self-hosted Jitsi Meet server (some background info in German). The meeting is also meant as one of the first test runs for this system. So it definitely helps if you are a bit adventurous when you attend.
Continue reading “Experiment: an open online meeting for rsyslog folks”While we have released rsyslog 8.2008 today, binary packages are not yet updated. They will follow follow “a bit” later.
The rsyslog project usually publishes binary packages for many distributions alongside the regular (source) scheduled stable releases. So far, this was a mostly manual process. In the past couple of week, we have worked on a CI system for package build as well as additional automation. We have not yet fully reached our goals, but things look pretty well.
Continue reading “rsyslog 8.2008 released – packages delayed”Did you search for “rsyslog template variables”? And landed here? Many folks do, so let me explain where you actually find them. TLDR: find them in the property doc.
This tutorial tells how to integrate data from Windows event log into our rsyslog configuration. We will do this integration via the UDP syslog protocol so that we finally can show this in a real case. No advanced topics are covered. We use CentOS 7 and Windows Server 2012 (because it still is in more widespread use). This is part of a rsyslog tutorial series.
Continue reading “rsyslog: integrating Windows Event Log (via UDP)”
This tutorials tells how rsyslog is configured to accept syslog messages over the network via UDP. No advanced topics are covered. We use CentOS 7. This is part of a rsyslog tutorial series.
We will configure LC to only relay messages received via UDP but not store them locally. Locally-generated messages will still be stored inside local log files. They, too, will be forwarded to LR. This is a very common use case. We still do not configure any sender to connect to LC.
To do all of this, we need to modify only LC local configuration. As such, our base lab scenario will remain in the following configuration:
Note that we still do not configure any system to actually send data to LC. This will be done the next tutorial. Note that if you did not complete the last tutorial, it may be wise to have a look at it. We will work with the configuration it generated. Continue reading “rsyslog: relay messages only (no local storage)”