How to discard unwanted syslog messages in rsyslog

Repetitive application logs can bury failures and consume storage long after their messages have stopped helping an operator. A narrow discard rule in rsyslog suppresses unwanted syslog messages while allowing other events from the same application to reach their usual destinations.

Rsyslog evaluates rules in order. The stop action discards a matching message before any later file or forwarding action can receive it, so a filter placed after a destination cannot prevent the copy already written there.

Local logging must already work before a missing message can prove that a filter matched. On a systemd-based Linux host, the journal may retain its own copy even when rsyslog discards the message; existing log entries also remain untouched.

1. Inspect the input and destination rules in the active rsyslog configuration.

   $ sudo cat /etc/rsyslog.conf /etc/rsyslog.d/*.conf
   ##### snipped #####
   $IncludeConfig /etc/rsyslog.d/*.conf
   ##### snipped #####
   *.*;auth,authpriv.none		-/var/log/syslog
   ##### snipped #####

   On Ubuntu and Debian, the master configuration includes /etc/rsyslog.d/*.conf, and 50-default.conf normally writes local messages to /var/log/syslog. Included files run in filename order. A destination above the include runs earlier regardless of the drop-in filename. An input bound to a custom ruleset needs its filter inside that ruleset.

   Related: How to inspect the effective rsyslog configuration

2. Open 10-discard-unwanted.conf in /etc/rsyslog.d/ with your text editor.

   $ sudoedit /etc/rsyslog.d/10-discard-unwanted.conf

   The file can be new. Its 10- prefix places it before 50-default.conf; an earlier custom destination needs the filter before that action instead.

3. Add a discard rule for the unwanted program and message at the top of the file.

   Matched messages will be lost from every subsequent rsyslog destination, including remote forwarding. A broad match such as just "error" can hide real failures. The two conditions limit the discard to one program and one message fragment.

   if ($programname == "noisyapp" and $msg contains "health check passed") 
   then {
       stop
   }

   Here noisyapp is the program name parsed from the syslog tag, and health check passed is the case-sensitive message fragment. For another application, those two values and the matching test messages need to reflect its actual logs. Other contents of an existing file stay in place.

4. Save the configuration file.
5. Validate the complete rsyslog configuration.

   $ sudo rsyslogd -N1
   rsyslogd: version 8.2312.0, config validation run (level 1), master config /etc/rsyslog.conf
   rsyslogd: End of config validation run. Bye.

   The version varies by installation. Validation must finish without configuration errors before the restart.

   Related: How to test rsyslog configuration syntax

6. Restart rsyslog to activate the filter.

   The restart briefly interrupts rsyslog processing. If wanted messages disappear, recovery is to remove only the added rule, validate with sudo rsyslogd -N1, and restart again. This restores future logging but cannot recover discarded messages.

   $ sudo systemctl restart rsyslog

   Related: How to manage the syslog service

7. Send a message that matches both discard conditions.

   $ logger --tag noisyapp "health check passed [discard-check-1]"

   The [discard-check-1] marker distinguishes this test from normal traffic. On a repeat test, a new marker in all three messages and the final search prevents older entries from confusing the result.

   Related: How to send a test syslog message

8. Send a different message from the same program.

   $ logger --tag noisyapp "connection failed [discard-check-1]"

9. Send the unwanted message fragment from another program.

   $ logger --tag otherapp "health check passed [discard-check-1]"

10. Check the destination log for the three test messages.

    $ sudo grep -F '[discard-check-1]' /var/log/syslog
    2026-11-09T10:36:09.863392+00:00 host noisyapp: connection failed [discard-check-1]
    2026-11-09T10:36:09.919087+00:00 host otherapp: health check passed [discard-check-1]

    Only the two nonmatching messages appear. The noisyapp heartbeat is absent, while its error and the otherapp heartbeat still arrive. No output means the logging path has not been demonstrated; three lines mean the filter did not discard the matching message. For a different destination, the same check belongs in that file or on the receiving collector.

    Related: How to troubleshoot missing syslog messages