Informix Warehouse Accelerator

Matching: messages

Informix Warehouse Accelerator: Redirecting Messages (2)

martinfu Tags: accelerator messages syslog warehouse sles suse informix linux syslog-ng ‎ 4,663 Views

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.

Blog Content/Topics List

Informix Warehouse Accelerator: Redirecting Messages (1)

martinfu Tags: accelerator warehouse system_logging linux im syslog informix messages ‎ 4,885 Views

Blog Content/Topics List

Icon: IWA Logo Truck The information provided applies to the Informix Server Version 11.70.xC2 and later.

The processes of a running Informix Warehouse Administrator instance typically are producing various informational messages that are handled via the system logging mechanism. On a normally configured Linux system, these messages are directed to the file /var/log/messages. Traditionally, this is the place for system messages and therefore it may be convenient to redirect the messages of the accelerator to a different location. For one, this probably helps to unclutter the file /var/log/messages, but it can also avoid running out of disk space for the file system where this file resides.

Depending on the distribution and version of Linux in use, different implementations of system logging are available, each with its specific method of configuration. Therefore, in this blog entry I will describe the method for the most common and basic system logging implementation, the syslogd (see also the manpage for syslogd(8) ). The examples have been tested on Red Hat Enterprise Linux Server release 5.5 (Tikanga) with version 1.4.1 of syslogd. Red Hat Enterprise Linux Server release 6.0 (Santiago) uses the rsyslogd as preferred implementation for system logging. The configuration file for rsyslogd is /etc/rsyslog.conf, which is in its default structure almost identical to the configuration file of syslogd. Therefore the description below can also be applied to a standard configuration of the rsyslogd implementation.

The syslogd implementation of system logging offers several so called 'facilities'. Examples of such facilities are 'auth', 'cron', 'daemon', 'kern', 'mail', 'local0' through 'local7', to name a few. For each facility the system logging can be configured by several levels, e.g. 'debug', 'info', 'warning', 'err', etc. The configuration of the facilities with their levels includes also the destination for the messages, usually files like /var/log/messages. The configuration of syslogd is in file /etc/syslog.conf (see also the manpage syslog.conf(5) for more information). An application like the accelerator has to specify the facility and the level for any messages sent to the system logging.

The following actions normally require root access, so all things should best be done as user 'root'.

The Informix Warehouse Accelerator uses the facility 'local6' for all its messages sent to the system logging. In order to change the destination for all these messages, no matter what is their level, this 'local6' facility needs to be configured in file /etc/syslog.conf. If there is no configuration for the 'local6' facility listed in the configuration file, then the default message destination is /var/log/messages. To change this, two things need to be done in /etc/syslog.conf:

Entries that apply to all facilities are denoted by an asterisk wildcard before the dot. An example is the following line:
*.info;mail.none;cron.none /var/log/messages

This tells the system logging to put all messages of level 'info' coming from all facilities ( *.info ) into /var/log/messages, but not messages from facilities 'mail' and 'cron'.

In this line, the facility 'local6' now also must be specified to exclude its messages from going to /var/log/messages. The changed line will look like this:
*.info;local6.none;mail.none;cron.none /var/log/messages
Assuming that until now there is no configuration for facility 'local6', a new line has to be added to the file for this facility. Using the asterisk wildcard for the level, we configure for all messages of facility 'local6' that they be directed to the specified destination file. The file name has to be specified with the absolute path, and if it is not owned by user 'root' it must at least be writable for user 'root'. (This sometimes is not guaranteed for remote file systems, e.g. mounted via NFS.)
local6.* /var/log/iwalog

The above line will cause all messages for facility 'local6' to be sent to file /var/log/iwalog instead of the default /var/log/messages.

With this the simple configuration for facility 'local6' is complete. In case there are more configuration lines that apply to all facilities, i.e. with the asterisk wildcard before the dot, then they should also be changed as above by adding the ;local6.none specifier to them.

In order to make the new configuration effective, the syslog daemon has to read the new configuration file. This is achieved by restarting the syslog daemon process, named syslogd. Normally it is sufficient to send this syslogd process the hangup signal upon which it will do the required restart and thus read the new configuration file.

In order to send a signal to the syslogd process, the process ID of that process needs to be determined, e.g. using the ps system utility in the following way:
```
    % ps -ef | egrep -v grep | egrep syslogd
    root      2037     1  0 Jun29 ?        00:00:01 syslogd -m 0
    %
  
```
The ID of the syslogd process in the example is 2037.
To send the hang up signal to this process, the kill system utility is used, specifying the signal by its name SIGHUP:
```
    % kill -SIGHUP 2037
    %
  
```

To check that the system logging daemon really is restarted, a glance at /var/log/messages can be done:

  % tail /var/log/messages
  Oct 18 ...
  Oct 18 11:48:14 <hostname> syslogd 1.4.1: restart.
  %

With the above configuration now effective, all future messages from the Informix Warehouse Accelerator should be redirected to the file /var/log/iwalog.

In a following blog entry I will briefly describe the necessary steps when using the syslog-ng implementation ("-ng" for "new generation"), an implementation widely used on SUSE Linux Enterprise Server.

Blog Content/Topics List

Feed for Blog Entries

Blogs