Some additional comments on the config


These action queue configs probably don't do what you intend them to do

the first thing is that they only affect the next action, which is authpriv.* to /var/log/secure and you configure 2000 threads to write these logs out. That will create a HUGE amount of contention for the queue lock and under load you should see it maxing out quite quickly

what is it that you are attempting to do here?



# Performance Tuning #
$ActionQueueWorkerThreads 2000
$ActionQueueWorkerThreadMinimumMessages 1000
$ActionQueueSize 1000000
$ActionQueueDiscardMark 800000
$ActionQueueHighWaterMark 600000

#### RULES ####
# Log all kernel messages to the console.
# Logging much else clutters up the screen.
#kern.*                                                 /dev/console

# Log anything (except mail authpriv, cron)
# Dont log private authentication messages!
#*.*;mail.none;authpriv.none;cron.none                   ?RemoteIP

# The authpriv file has restricted access.
authpriv.*                                              /var/log/secure


since the queue only applied to the next action with this config, everything below this is operating from the main queue again as if there was no action queue configuration




# Log all the mail messages in one place.
mail.*                                                  -/var/log/maillog

# Log cron stuff
cron.*                                                  /var/log/cron

# Everybody gets emergency messages
*.emerg                                                 :omusrmsg:*

# Save news errors of level crit and higher in a special file.
uucp,news.crit                                          /var/log/spooler

# Save boot messages also to boot.log
# local7.*                                              /var/syslog/boot.log



ereregex is a fairly expensive filter to apply, it's much better to figure out a non-regex approach to filtering these. Can you post some examples of what you are trying to filter? mmnormalize to parse the logs and then make decisions on the parsed results id probably much faster.


/etc/rsyslog.d/security-config-omsagent.conf
# [Firewall Log Filtering] #
:msg, ereregex, "(1.1.[0-9]+.[0-9]+)" stop
:msg, ereregex, "(1.2.[0-9]+.[0-9]+)" stop
:msg, ereregex, "(1.3.[0-9]+.[0-9]+)" stop
:msg, ereregex, "(1.4.[0-9]+.[0-9]+)" stop
:msg, ereregex, "(1.5.[0-9]+.[0-9]+)" stop
:msg, ereregex, "(1.6.1[6-9].[0-9]+)" stop
:msg, ereregex, "(1.7.2[0-3].[0-9]+)" stop
:msg, ereregex, "(1.8.68.[0-9]+)" stop
:msg, ereregex, "(1.9.69.[0-9]+)" stop
:msg, ereregex, "(1.10.82.[0-9]+)" stop
:msg, ereregex, "(IP multicast routing failed)" stop
:msg, ereregex, "(TCP_7680)" stop


check the messages to see where CEF: and ASA- are in the message, can you filter on something smaller than rawmsg? (say syslogtag), and can you use 'startswith' instead of 'contains'?, again mmnormalize may be much faster

if $rawmsg contains "CEF:" or $rawmsg contains "ASA-" then @@127.0.0.1:25226
& stop
if $rawmsg contains "infobloxgridmstr" then @127.0.0.1:25224
& stop


combining multiple filters into one action, or having the filters call a ruleset can be far more efficient than all of them writing things out independently.

the if..then filter structure lets you easily combine filters

local0.info @127.0.0.1:25224
& stop
local1.info @127.0.0.1:25224
& stop
local2.info @127.0.0.1:25224
& stop
local3.info @127.0.0.1:25224
& stop
local4.info @127.0.0.1:25224
& stop
local5.info @127.0.0.1:25224
& stop
local6.info @127.0.0.1:25224
& stop
local7.info @127.0.0.1:25224
& stop
auth.* @127.0.0.1:25224
& stop
authpriv.* @127.0.0.1:25224
& stop
daemon.info @127.0.0.1:25224
& stop
syslog.* @127.0.0.1:25224
& stop
ftp.*<ftp://ftp.*> @127.0.0.1:25224
& stop
user.* @127.0.0.1:25224
& stop
_______________________________________________
rsyslog mailing list
https://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of 
sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE 
THAT.

Reply via email to