I’ve achieved a long-term goal for rsyslog today: I have finally managed to include the ability to automatically switch to backup actions (servers, databases, whatever ;)) when the primary fails. I have implemented it in a very high level inside the syslogd rule engine, and so it is quite powerful.
Just read this doc excerpt:
This directive allows to specify if actions should always be executed (“off,” the default) or only if the previous action is suspended (“on”). This directive works hand-in-hand with the multiple actions per selector feature. It can be used, for example, to create rules that automatically switch destination servers or databases to a (set of) backup(s), if the primary server fails. Note that this feature depends on proper implementation of the suspend feature in the output module.
The following is an example of what can be done with it (a config file excerpt):
This selector processes all messages it receives (*.*). It tries to forward every message to primary-syslog.example.com (via tcp). If it can not reach that server, it tries secondary-1-syslog.example.com, if that fails too, it tries secondary-2-syslog.example.com. If neither of these servers can be connected, the data is stored in /var/log/localbuffer. Please note that the secondaries and the local log buffer are only used if the one before them does not work. So ideally, /var/log/localbuffer will never receive a message. If one of the servers resumes operation, it automatically takes over processing again.
As is written in the doc, this ability depends on proper handling of the new suspend-interface in the output driver. So far, I have only updated the omfwd driver. I plan to do the mysql driver soon. I’ll possibly also look after the file driver, but suspension there seems like a foreign concept. The other drivers don’t support it (nothing can go wrong enough), so I don’t bother about them.
All in all, I am quite happy and I think this is a very useful feature. It will be part of 1.18.0, currently it is “just” in anon cvs. I hope to release 1.18.0 tomorrow – let’s see if that works.
I am also glad that this example shows the output interface (and a whole lot of the other new internal plumbing) works pretty well. I think we are in an excellent position for all the other new things to come ;)