syslog-ng 4 improves Python support
It’s been a while since I personally acted as the release manager for a syslog-ng release, the last such release was 3.3.1 back in October 2011. v3.3 was an important milestone, as that was the version that introduced threaded mode and came with a completely revamped core architecture to scale up properly on computers that had multiple CPUs or cores. I released syslog-ng 4.0.1 a couple of weeks ago which brings with it the support for runtime typing, which is a significant conceptual improvement.
Apart from typing, which I have discussed at length already, the release sports important additions and improvements in syslog-ng’s support for Python, which I would like to zoom into a bit in this post.
In case you are not aware, syslog-ng has allowed you to write source and destination drivers, parsers and template functions in Python for a while now. See this post on writing a source in general and this one for writing an HTTP source.
There was one caveat in using Python though: while it was easy to extend an existing configuration and relatively easy to deploy these in a specific environment, syslog-ng lacked the infrastructure to merge such components into syslog-ng itself and expose this functionality as if it was implemented natively. For instance, to use the Python based HTTP source described in the blog post I mentioned above, you needed to write something like this to use the Python based http source:
source s_http {
python(
class("httpsource_v2.HTTPSource")
options("port", "8081")
);
};
As you can see, this syntax is pretty foreign, at least if you compare this to a native driver that would look like this:
source s_http {
http(port(8081));
};
A lot simpler, right? Apart from configuration syntax, there was another shortcoming though: Python code usually relies on 3rd party libraries, usually distributed using PyPI and installed using pip. Up to 4.0.0, one needed to take care about these dependencies manually. The http source example above needs you to install the “python3-twisted” package using dnf/apt-get or pip manually and only then would you be able to use it.
These short-comings are all addressed in the 4.0.0 release, so that:
- 3rd party libraries are automatically managed once you install syslog-ng.
- you can use native configuration syntax,
- we can ship Python code as a part of syslog-ng,
Let’s break these down one-by-one.
Managing 3rd party Python dependencies
From now on, syslog-ng automatically creates and populates a Python virtualenv to host such 3rd party dependencies. This virtualenv is located in ${localstatedir}/venv, which expands to /var/lib/syslog-ng/venv normally. The virtualenv is created by a script named syslog-ng-update-virtualenv, which is automatically run at package installation time.
The list of packages that syslog-ng will install into this virtualenv is described by /usr/lib/syslog-ng/python/requirements.txt.
If you want to make further libraries available (for instance because your local configuration needs it), you can simply use pip to install them:
$ /var/lib/syslog-ng/python-venv/bin/pip install <pypi package>
syslog-ng will automatically activate this virtualenv at startup, no need to explicitly activate it before launching syslog-ng.
Using this mechanism, system installed Python packages will not interfere with packages that you need because of a syslog-ng related functionality.
Native configuration syntax for Python based plugins using blocks.
There are two ways of hiding the implementation complexities of a Python based component, in your configuration file:
- using blocks to wrap the python() low level syntax, described just below
- using Python based config generators, described in the next section
Blocks have been around for a while, they basically allow you to take a relatively complex configuration snippet and turn it into a more abstract component that can easily be reused. For instance, to allow using this syntax:
source s_http {
http(port(8081));
};
and turn it into a python() based source driver, you just need the following block:
block source http(port(8081)) {
python(class("httpsource_v2.HTTPSource")
options("port", "`port`") );
}
The content of the block will be substituted into the configuration, whenever the name of the block is encountered. Parameters in the form of param(value) will be substituted using backticks.
In simple cases, using blocks provides just enough flexibility to hide an implementation detail (e.g. that we used Python as the implementation language) and also hides redundant configuration code.
Blocks are very similar to macros as used in other languages. This term was unfortunately already taken in the syslog-ng context, that’s why it has been named differently.
Blocks are defined in syslog-ng include files, these include files you can store as an “scl” subdirectory of the Python module.
Native configuration syntax for Python based plugins using configuration generators.
Sometimes, blocks are insufficient to properly wrap our desired functionality. Sometimes you need conditionals, in other cases you want to use a more complex mechanism or a template language to generate part of the configuration. That you can do using configuration generators.
Configuration generators have also been around for a while, but until now they were only available using external shell scripts (using the confgen module), or restricted to be used from C, syslog-ng’s base language. The changes in 4.0 allow you to write generators in Python.
Here’s an example:
@version: 4.0
python {
from syslogng import register_config_generator
def generate_foobar(args):
print(args)
return "tcp(port(2000))"
#
# this registers a plugin in the "source" context named "foobar"
# which would invoke the generate_foobar() function when a foobar() source
# reference is encountered.
#
register_config_generator("source", "foobar", generate_foobar)
};
log {
# we are actually calling the generate_foobar() function in this
# source, passing all parameters as values in the "args" dictionary
source { foobar(this(is) a(value)); };
destination { file("logfile"); };
};
syslog-ng will automatically invoke your generate_foobar() function whenever it finds a “foobar” source driver and then takes the return value for that function and substitutes back to where it was found. Parameters are passed around in the args parameter.
Shipping Python code with syslog-ng
Until now, Python was more of an “extended” configuration language, but with the features described above, it can actually become a language to write native-looking and native-behaving plugins for syslog-ng, therefore it becomes important for us to ship these.
To submit a Python implemented functionality to syslog-ng, just open a PR that places the new Python code into the modules/python-modules/syslogng/modules subdirectory. This will get installed as a part of our syslog-ng-python package. If you have 3rd party dependencies, just include them in the setup.py and requirements.txt files.
If you need an example how to use the new Python based facilities, just look at the implementation of our kubernetes() source.
Recent Comments