Rsyslog currently offers only very rough support for plug-ins: only the MySQL plugin is available as a plugin. Even the output plug-in structure is not yet finished. So it looks like plug-is are quite unimportant to rsyslog. Right?
Wrong! Totally wrong! If there is a single feature that is absolutely critical to rsyslog, it is plug-in support. Plug-ins offer a way to provide dynamically loadable extensions of the core functionality. Provided the plug-in interface (API) is clean and well-designed, that can come without any performance hit.
Now don’t just think about plug-ins for exotic features. What if almost everything is a plug-in? Well, in that case the code loaded in memory (the footprint) can be exacty tailored to what is needed. This is most benefitial for small, embedded system with limited resources available. On the other hand, this doesn’t limit a highly capable system of offering a very rich functionality. It just loads different plug-ins.
Remember that almost all functionality can be implemented as a plugin. Inputs (E.g. UDP syslog or local domain sockets) and outputs (e.g. database output or message forwarding) make somewhat natural plugins. But plugins can also be used in filtering. For example, the (expensive) regexp functionality could be provided by a plugin. As could be different message parsers.
This is exactly the way rsyslog is heading: we will try to provide an ultry-slim framework which offers just the basic things needed to orchestrate the plug-ins. Most of the functionality will indeed be available via plug-ins, dynamically loaded as needed.
I am not yet sure when we will reach his goal. But the object model design and the overall design direction heads into this area. With that design philosophy, we can make rsyslog really universally available, even on low-powered devices (loading just a few plug-ins). At the high end, systems with a lot of plug-ins loaded will be able to handle the most demanding tasks.
And, of course, plug-ins will hopefully not only be provided by the rsyslog project itself. It is our sincere hope that others will also begin to contribute functionality in the form of plug-ins. To facilitate that, we strive to create very simple plug-in interfaces. For example, all threading details will be handled by the core engine itself and plug-ins will be able to think they are running on a single thread. The core engine will handle the proper sync operations. Of course, plug-ins in need to use themselves a sophisticated threading model can do so – but it is not a requirement. Hopefully, that’ll make it very easy to create plug-ins and thus be very easy to contribute extended functionality for rsyslog. That, we hope, will help create a lively community and thus a breakthrough syslog project.