[syslog-ng] log failback groups

[Zoltán Pallagi]

Thank you for sharing your idea with me, but I'm afraid, it is a little 
bit more complicated to do it well. If I understand your idea correctly, 
it can handle only the performance problem of the output side but 
doesn't solve the high traffic problem on input side (in this case, the 
master process will be overloaded and the other processes will be 
starved). Also, there are other problems relation in multiple syslog-ng 
processes/threads as well (e.g.: handling if more processes want to 
write to the same destination or storing the correct state of every 
processes and so on).

Back to your performance problem:
Will you send me your configuration? Perhaps, it's possible to optimize 
it a bit.

Patrick H. wrote:
> 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 at balabit.hu>
> To: Syslog-ng users' and developers' mailing list 
> <syslog-ng at lists.balabit.hu>, syslogng at 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
>>   


-- 
pzolee

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.balabit.hu/pipermail/syslog-ng/attachments/20100319/1c42f07e/attachment.htm