I have the following rsyslog.conf:

$PreserveFQDN on
# rsyslog v5 configuration file

# For more information see /usr/share/doc/rsyslog-*/rsyslog_conf.html
# If you experience problems, see http://www.rsyslog.com/doc/troubleshoot.html

#### MODULES ####

$ModLoad imuxsock # provides support for local system logging (e.g. via logger command)
$ModLoad imklog   # provides kernel logging support (previously done by rklogd)
#$ModLoad immark  # provides --MARK-- message capability

# Provides UDP syslog reception
$ModLoad imudp
$UDPServerRun 514

# Provides TCP syslog reception
$ModLoad imtcp
$InputTCPServerRun 514


# Use default timestamp format
$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat

# File syncing capability is disabled by default. This feature is usually not required,
# not useful and an extreme performance hit
#$ActionFileEnableSync on

# Include all config files in /etc/rsyslog.d/
$IncludeConfig /etc/rsyslog.d/*.conf

#### RULES ####

#discard loadbalancer messages
:msg, contains, "default send string" ~

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

# Log anything (except mail) of level info or higher.
# Don't log private authentication messages!
*.info;mail.none;authpriv.none;cron.none                /var/log/messages

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

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

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

# Everybody gets emergency messages
*.emerg                                                 *

# 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/log/boot.log

# ### begin forwarding rule ###
# The statement between the begin ... end define a SINGLE forwarding
# rule. They belong together, do NOT split them. If you create multiple
# forwarding rules, duplicate the whole block!
# Remote Logging (we use TCP for reliable delivery)
# An on-disk queue is created for this action. If the remote host is
# down, messages are spooled to disk and sent when it is up again.
#$WorkDirectory /var/lib/rsyslog # where to place spool files
#$ActionQueueFileName fwdRule1 # unique name prefix for spool files
#$ActionQueueMaxDiskSpace 1g   # 1gb space limit (use as much as possible)
#$ActionQueueSaveOnShutdown on # save messages to disk on shutdown
#$ActionQueueType LinkedList   # run asynchronously
#$ActionResumeRetryCount -1    # infinite retries if host is down
# remote host is: name/ip:port, e.g., port optional
#*.* @@remote-host:514

*.* @localhost:5000
# ### end of the forwarding rule ###

Which contains the following rule for discarding a specific message:

#discard loadbalancer messages
:msg, contains, "default send string" ~

It does not seem to do what it is supposed to do, I can still see these messages in /var/log/messages:

[~] # tail -f /var/log/messages
Dec  3 02:51:38 default send string
Dec  3 02:51:42 default send string
Dec  3 02:51:43 default send string
Dec  3 02:51:47 default send string
Dec  3 02:51:48 default send string
Dec  3 02:51:52 default send string
Dec  3 02:51:53 default send string
Dec  3 02:51:57 default send string
Dec  3 02:51:58 default send string
Dec  3 02:52:02 default send string
Dec  3 02:52:03 default send string

Please note that this is a Logstash server which receives syslog messages from other servers to port 514 and forwards them to its own port 5000 in order for them to be processed by Logstash, that's why there is this line in the config file:

 *.* @localhost:5000

I was thinking the hostname is "default" and the :msg is "send string", but I couldn't get it to filter that way either. So, I did some more searching and found the following:

:rawmsg, isequal, "default send string" stop

That finally made the messages go away. For what its worth, they appear to be from our load balancer, probably a syslog/udp healthcheck.

Reference: http://lists.adiscon.net/pipermail/rsyslog/2012-September/030562.html

  • 1
    Yes, they are UDP healthcheck messages coming from F5 loadbalancer and the solution works. Awesome! Thanks a lot! – Iokanaan Iokan Mar 9 '16 at 8:29
  • Worth noting that this should go in any queue of rules. For instance, when using $RulesetCreateMainQueue, this must be included in any rule set. This message is sent as part of the udp probe, as @IokanaanIokan stated, by F5 local traffic managers. It is sent so that the F5 will react to ICMP messages returned by a host. – mbrownnyc Aug 13 '19 at 2:22

You need to make sure that your rule for discarding the message should be called before the one that writes it in a file.

By default, Rsyslog have a /etc/rsyslog.d/50-default.conf that writes messages as it is. Maybe putting your rule before:

$IncludeConfig /etc/rsyslog.d/*.conf

should work.

And Rsyslog warns to not use ~, you should use stop instead.

  • there is nothing in /etc/rsyslog.d/ folder. I have put the rule before it anyway, did not change anything. – Iokanaan Iokan Dec 8 '15 at 8:51
  • Hmm... I work with ubuntu server, maybe yours is different. Anyway, if there is no .conf in your /etc/rsyslog.d/ folder, the way you made it is correct, but for some reason it is not working. Try using this syntax: if ($msg contains "default send string") then { stop } You need to make sure that the message really is "default send string"... if this is not working, try "send string" or even "string" alone. A log itself contains some information that should not be confused with the message. – Luiz Guilherme Littig Berger Dec 8 '15 at 16:30
  • tried your suggestions, unfortunately, the same situation. I guess I'll give up and use logrotation to avoid /var getting full. – Iokanaan Iokan Dec 28 '15 at 14:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.