Description of problem:

On Thursday 15 December 2005 03:31, Tony Griffiths <tonyg> wrote:
...
[we have] a centralised logger that captures information from all computers and 
applications that have the appropriate logging levels enabled.  Various 
utilities to examine this log information in both realtime and via batch 
trolling have been written.

But what about system daemons, et al?

This has been problematic since there are numerous system daemons and 
subsystems that affect the performance of the computing cluster and 
applications but their logging information typically gets lost in the 
syslog message file(s).  It would be possible to troll these files later 
but merging that information into the other log in proper time sequence 
would be difficult.  Even a 'live' tail -f on the /var/log/messages file 
would probably not provide good enough timing to keep log entries in 
strict monotonicly increasing time order!  To solve this problem, I've 
created a patch to the redirection code in syslogd that allows UDP 
messages to be sent to a port OTHER-THAN syslog (514).  This patch tries 
not to break the circular redirection logic but does allow redirection 
to a "local" IP address as long as the destination port# is not the one 
that syslogd itself is listening on.  With this patch, we can setup 
rules in /etc/syslog.conf to capture *important* system information and 
have it sent to our logger daemon for incorporation into the application 
logfile(s) in proper time order.  Of course if our daemon is not up or 
is unreachable, the UDP packets simply drop in the bit-bucket as they 
should.  The format allowed by the patch is-

# redirect some msgs to a remote host
facility.priority               @remote-host:port

with the absence of the ":port" indicating that the variable LogPort 
(defaults to 514 but can be overridden by -p switch) is used.  This is 
traditional syslog redirection!  I've attached the patch files.  The 
remote-port patch to syslogd.c assumes that the three prior patch files 
have been applied.

Hopefully you can incorporate this patch into the standard RedHat SRPM 
for sysklog!