I thought I provide a quick “happy camper” status update. Even though this was only a side-activity, I had an exceptionally good day working with Digital Ocean Gradient and open source models. I am working on support Agents for the rsyslog ecosystem.
Adiscon (rsyslog’s main sponsor) has joined connect.IT Heilbronn-Franken. Short version: I want more first-hand input from real deployments in AI, logging, and security. Local practitioners have plenty of it. Turning those lessons into clear guidance helps the global rsyslog community. Simple.
I recently had a discussion about data lakes. It made me realize that people often picture them as the starting point of data collection — as if all information somehow appears in the lake. In reality, no lake exists without rivers. And in the world of IT systems, rsyslog is part of that river system.
Windows logs provide a wealth of information that must be made usable for Observability. As you may know, I work on normalizing these logs for quite some while, I even created liblognorm for that purpose. Ingesting them properly is important for schema mapping, e.g. to Elastic Cloud.
I am glad to tell that I finally managed to solve an issue that caused confusion for years. Someone had cloned and published the rsyslog documentation at readthedocs. Unfortunately, it was not maintained afterwards and also looked like an official rsyslog doc. That added a lot to the “rsyslog’s doc is bad and inconsistent” feel inside the community. This could now be resolved, and current, official doc is now available at readthedocs. I am very happy and glad for readthedocs staff members who helped us to finally resolve the issue.
In the past days I noticed PR patterns that do not look right. This is a smell, not a verdict. The upside is real: rsyslog is interesting enough to attract attention. That is actually great news. Now we have the problem ourselves, and that is the moment to engineer the right guardrails without losing our welcoming tone. You need to be a target in order to gain sufficient experience to tackle that hard problem.
I chased a rare crash in highly-threaded code. It popped up now and then; earlier fixes didn’t stick. I suspected an advanced concurrency issue. I also asked Gemini, Copilot/Codex, and Claude for help. They agreed with me: surely something subtle—epoll, re-queueing, ownership flags…
My AI use on images as inferior, as you can see here. I hope you like that fact ;-)
We were all wrong—and, importantly, I was wrong in the same way the AIs were. Their analyses reinforced my initial hypothesis. The fact that the static analyzer reported nothing reinforced it even more—after all, that’s “proven non-AI tech.” In hindsight, if I had thought earlier about the limits of these tools (AI and non-AI), I might have changed direction sooner—but I was also primed by experience: in this part of the codebase, bugs are almost always complex.
I’ve been using AI to help with commit messages for a while now. Yesterday, in a discussion with co-workers, it became clear that this may not just be a convenience feature — it’s turning into a real time saver.
That was the background for creating the new rsyslog Commit AI Assistant. It directly addresses a problem we ourselves face in daily development. True to dogfooding, we now use it internally whenever we craft a commit message — myself included.
The “rsyslog commit assistant” in action. You can even see my typos ;-) (Screenshot: Rainer Gerhards, actual session)
rainer.gerhards.net uses cookies to ensure that we give you the best experience on our website. If you continue to use this site, you confirm and accept the use of Cookies on our site. You will find more informations in our Data Privacy Policy.OkRead more