Scribe Syslog-ng syslog.d filter help

[CaptnDanLKW]

I'm trying to add the "bsd:" kernel and program sources to the same wlceventd log but cannot figure out the syntax.

I used the working filter and added line
I'm trying to add the "bsd:" kernel and program sources to the same wlceventd log but cannot figure out the syntax, though I think I'm following an example from a different sample filter that does work.

I used the working wlceventd filter and added the bolded lines below.

Soon as I restart Scribe, the entries that should be captured by f_wlceventd revert back to the messages log.

I used an example from another sample filter that makes use of two filter sources for the same log... seems like this should work.

Any help would be appreciated! Thanks!

__________


# put bsd and wlceventd Assoc/ReAssoc/Disassoc messages into /opt/var/log /wlceventd.log

destination d_wlceventd {
file("/opt/ var/log/wlceventd.log");
};

filter f_wlceventd {
( ( program("WLCEVENTD") or
program("wlceventd") ) and
( message("ssoc") or
message("uth") ) ) or
( program("syslog") and
message("wlceventd") );
};

filter f_bsd {
program("bsd") and
message("bsd") ;
};

log {
source(src);
filter(f_wlceventd);
filter(f_bsd);
destination(d_wlceventd);
flags(final);
};

#eof

 

[elorimer]

I'm trying to add the "bsd:" kernel and program sources to the same wlceventd log but cannot figure out the syntax.

I used the working filter and added line
I'm trying to add the "bsd:" kernel and program sources to the same wlceventd log but cannot figure out the syntax, though I think I'm following an example from a different sample filter that does work.

I used the working wlceventd filter and added the bolded lines below.

Soon as I restart Scribe, the entries that should be captured by f_wlceventd revert back to the messages log.

I used an example from another sample filter that makes use of two filter sources for the same log... seems like this should work.

Any help would be appreciated! Thanks!

__________


# put bsd and wlceventd Assoc/ReAssoc/Disassoc messages into /opt/var/log /wlceventd.log

destination d_wlceventd {
file("/opt/ var/log/wlceventd.log");
};

filter f_wlceventd {
( ( program("WLCEVENTD") or
program("wlceventd") ) and
( message("ssoc") or
message("uth") ) ) or
( program("syslog") and
message("wlceventd") );
};

filter f_bsd {
program("bsd") and
message("bsd") ;
};

log {
source(src);
filter(f_wlceventd);
filter(f_bsd);
destination(d_wlceventd);
flags(final);
};

#eof

The "ands" and the "ors" make my hair hurt
The log statement sends a message to the destination if all the filters are true. Break it up into two log statements so the message is sent to the destination if either filter is met.

 

[CaptnDanLKW]

The "ands" and the "ors" make my hair hurt
The log statement sends a message to the destination if all the filters are true. Break it up into two log statements so the message is sent to the destination if either filter is met.

@elorimer Thanks, so like this below? Would each statement also get the flags(final) ? or just the last one.

log {
source(src);
filter(f_wlceventd);
destination(d_wlceventd);
flags(final);
};

log {
source(src);
filter(f_bsd);
destination(d_wlceventd);
flags(final);
};

#eof

 

[elorimer]

Yes, I think just like that. If a message meets the first filter, it is sent to the destination and isn't processed further. If it doesn't meet the first filter, it goes on to be run through the second logging statement.

You could also break your configuration into two separate files, or combine them all into one gigantic one. The one cardinal rule is not to define a source, destination or filter more than once. That's why I think you are right to combine these two ways of going to one destination into one configuration file.

As an aside, very much OT, complicated or/and filters take a lot more processing time/memory and can benefit from being broken out into separate filters and logging statements. The number of messages generated in this SOHO use case, even when you are using it as a concentrator for nodes and routers, doesn't seem to trigger any issues. I've found this wlceventd filter to be problematic because I see messages that I think should have been redirected dropping into messages. But that is due to the limited processing power between my ears.

 

[CaptnDanLKW]

@elorimer
I think the structure is working; the wlceventd entries are back in the correct log. It's harder to create bsd: events but I did switch around the f_filter and log statements so that the bsd structures were first, and it still logged the wlceverntd ones, so I think it's good now.

Your right about 'needs'; organizing logs is truly art vs. science and form over function. I used to look at logs more often in the past and at that time weeding though the noise was difficult. I basically started with scribe and the wlceventd filter just to make the main log a little more readable. Since then, I've added and tweaked filters, so that 'messages' is mostly quiet - so when something is written, it actually means something.

Thanks again for the guidance. Hope this help someone else too...

I also have a remote AIMesh node dumping its logs into its own file. (no granular separation for it)