We turned on
syslog-ng for our production environment today and ran into a problem
which I think the solution might also solve this one.
The problem I ran into is that with full production logging on,
syslog-ng is using up about 50% of the CPU, and thats writing
everything out to /dev/null (a few hundred machines). With a single
regex turned on, it was using 90% CPU. So what I'm going to end up
doing is running multiple syslog-ng processes so they can run in
parallel on separate CPU cores. This way they can process data
simultaneously. There will be a master process which basically sends
everthing with the mail facility to two other syslog-ng processes, one
of which will be parsing out data to insert into a database, and
another will be parsing out data to write to files (different regexes
for each).
Now, the way this might also solve the failover issue is to make
multi-process capability part of syslog-ng. So one might end up with a
config like:
@version: 3.0
options {
use_dns(no);
log_iw_size(10000);
};
source s_sys {
unix-stream('/dev/log');
};
source s_net {
tcp(ip(0.0.0.0) port(514) max-connections(1000));
udp(ip(0.0.0.0) port(514));
};
filter f_mail {
facility(mail); };
process p_msgid {
filter f_msgid {
message('MsgID: (?<MESSAGEID>\S+)', type('pcre')
flags('nobackref','store-matches'));
};
destination d_oracle { sql(...); };
destination d_oracle_fallback { sql(...); };
log { filter(f_msgid); destination(d_oracle); };
log { filter(f_msgid); destination(d_oracle_fallback);
flags(fallback); };
};
process p_foobar {
options {
flush_timeout(1000);
}
filter f_foobar { ... };
destination d_foobar { ... };
destination d_foobar_fallback { ... };
log { filter(f_foobar); destination(d_foobar); };
log { filter(f_foobar); destination(d_foobar_fallback);
flags(fallback); };
};
log { source(s_sys); source(s_net); filter(f_mail);
destination(p_msgid); destination(p_foobar); };
This will launch 3 processes, a master control process that does very
basic filtering and uses some sort of IPC to send the data to 2 other
processes which inherit the global options section and accept every
config statement the master process does except sources. This way each
process can run in parallel on the different CPU cores, and can have
fallback destinations that wont interfere with the other processes.
Sent: Wednesday, March 17, 2010 7:54:42 AM
From: Zoltán Pallagi
<pzolee@balabit.hu>
To: Syslog-ng users' and developers' mailing list
<syslog-ng@lists.balabit.hu>,
syslogng@feystorm.net
Subject: Re: [syslog-ng] log failback groups
Hi Patrick,
As far as I know, we would like to solve the failover/failback problem
in syslog-ng PE v3.2 (and perhaps in OSE v3.2), but we are still
working on it.
However, we are planning to support it only in case of tcp/syslog
destinations.
Patrick H. wrote:
How
do you do groups of failbacks? For example
log { filter(f_filter1); destination(d_file1); };
log { filter(f_filter1); destination(d_file2); }; <-- log here only
if the above fails
log { filter(f_filter2); destination(d_sql1); }; <-- may include
messages from the above 2 lines
log { filter(f_filter2); destination(d_sql2); }; <-- log here only
if d_sql1 fails
So, say lines 1 and 3 both fail, lines 2 and 3 should both start
working. If I put a fallback flag on d_file2 and d_sql2, and d_sql1
fails, d_sql2 wont kick in on matches that d_file1 is still taking.
It seems like there should be a way to do "log { destination(...) or destination(...); };", or "log {...} or log {...};".
______________________________________________________________________________
Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng
Documentation: http://www.balabit.com/support/documentation/?product=syslog-ng
FAQ: http://www.campin.net/syslog-ng/faq.html
--
pzolee