The
information provided applies to the Informix Server Version 11.70.xC2
and later.
Following up on the last blog entry with the description of how to configure the syslogd implementation often used on Red Hat Linux distribution, here is a description for the syslog-ng implementation ("-ng" for "new generation"), widely used on SUSE Linux distributions. The examples have been tested on SUSE Linux Enterprise Server 11 using version 2.0.9 of syslog-ng.
Naturally, the concept of system logging is the same for both implementations and the Informix Warehouse Accelerator always uses the system logging facility named 'local6'. From the perspective of the accelerator and its messages the difference is in the method of configuring the system logging.
The configuration file for syslog-ng is located in directory /etc/syslog-ng/ and is named syslog-ng.conf. This file must be edited as user 'root' to apply the needed changes. syslog-ng has the notion of defining in the configuration file not only the destinations, but also the source of log messages, along with optional filters. These definitions are then tied together to define individual logging actions, making syslog-ng much more flexible. However, in the example I will keep things rather simple, just to achieve the same objective as with the examples for syslogd in the last blog entry: to redirect all messages of the accelerator to a separate file named /var/log/iwalog.
First a new filter for the Informix Warehouse Accelerator is defined. It is named 'f_iwa' and should select all messages going to facility 'local6'. Therefore the filter does not specify a level, but only the facility. The following line is added to the section containing all the filter definitions in file syslog-ng.conf:
filter f_iwa { facility(local6); };
Next a new destination for the messages from the accelerator is defined. The destination is the file /var/log/iwalog and the name of this new destination is 'd_iwa'. Usually the destinations in syslog-ng.conf are not grouped together (like the filter definitions), instead they are placed with the log action definition where the destination is used. Therefore a new place, convenient for the admin, is to be chosen for the following line to be added to the configuration file:
destination d_iwa { file("/var/log/iwalog"); };
Right after the destination definition, the log action is to be defined, again with a new line to be added to the file. Here, the previously defined filter 'f_iwa' and the destination 'd_iwa' are used. The generic source definition named 'src', already existing, is sufficient. It is not necessary to define a new source for this purpose. The line defining the log action is:
log { source(src); filter(f_iwa); destination(d_iwa); };
With this the definition for directing all messages from the acclereator to file /var/log/iwalog is complete. However, the same messages can be sent to different destinations concurrently, in effect duplicating the messages to each of these destinations. As usually there exist already some definitions that cause the accelerator's messages to be sent to other destinations, it may be desirable to turn this off in order to have the accelerator's messages collected only in the one (new) place, the file /var/log/iwalog. To do this, the other definitions applying to (some of) the accelerator's messages need to be found in the configuration file and changed accordingly. Typically these definitions are:
filter f_local { facility(local0, local1, local2, local3,
local4, local5, local6, local7); };
filter f_messages { not facility(news, mail) and not filter(f_iptables); };
filter f_warn { level(warn, err, crit) and not filter(f_iptables); };
These filter definitions apply to (some) messages of the accelerator and the later use of these filters in the configuration file causes these messages being sent to three different files: /var/log/localmessages, /var/log/messages and /var/log/warn. To stop these messages from being sent to these three destinations, the above filter definitions need to be changed to exclude the accelerator's messages. This is best done by using the filter 'f_iwa' that we have already defined. That way, if later a change is applied to filer 'f_iwa', it will automatically be effective throughout the configuration file without having to revisit and adjust the above three filter definitions. With the suggested changes applied, the lines will look like the following:
filter f_local { facility(local0, local1, local2, local3,
local4, local5, local6, local7)
and not filter(f_iwa); };
filter f_messages { not facility(news, mail) and not filter(f_iptables)
and not filter(f_iwa); };
filter f_warn { level(warn, err, crit) and not filter(f_iptables)
and not filter(f_iwa); };
After all necessary changes have been applied to the file syslog-ng.conf, the remaining task is to make the new configuration effective. The running syslog-ng daemon needs to read the changed configuration file. This is accomplished by sending the syslog-ng process the hang up signal. Sending the signal needs to be done as user 'root' and the easiest way is to use the kill system utility. Before using kill, the pocess ID of the running syslog-ng needs to be determined using the ps system utility, filtering the output with grep:
% ps -ef | egrep -v grep | egrep syslog-ng
root 2853 1 0 Oct18 ? 00:00:00 /sbin/syslog-ng
%
The hang up signal is sent to the process with the ID 2853:
% kill -SIGHUP 2853
To verify that syslog-ng really has read the new configuration, a quick look at /var/log/messages can be done:
% tail -5 /var/log/messages
...
Oct 20 15:20:59 node1 syslog-ng[2853]: Configuration reload request
received, reloading configuration;
Oct 20 15:20:59 node1 syslog-ng[2853]: New configuration initialized;
%
Given the extensive flexibility of syslog-ng it may well be possible to not only send messages to a different host, but also to insert the messages into a database system running on that host. However, figuring out how this can be done and what configuration is needed ... is left to the adventurous reader - for the time being at least.