Overview of Filters

In addition to filtering log events by thresholds, using logger and appender configurations, the logging facility has filter classes to filter log events, based on character strings and thresholds:
Filter Class Name
Description
RepeatMatchFilter
filters repeated log messages.
StringMatchFilter
filters log messages based on a character string in the log message.
LevelRangeFilter
filters log messages based on a range of message thresholds.
LevelMatchFilter
filters log messages based on a single message threshold.
AndFilter
filters log messages based on the results of a list of other filters.
DenyAllFilter
denies log events that did not meet the criteria of previous filters in a filter policy.
By using filter classes to filter messages, you can choose whether to accept or deny a log event if a match occurs between a filter parameter and the string or threshold in the log event.
You configure filter classes by using the <filter> subelements within an appender configuration.
Filters are processed in the order in which they appear in the appender definition, creating a filtering policy for the appender.
The results of filtering depend on filter arguments. The AcceptOnMatch argument in the RepeatMatchFilter, StringMatchFilter, LevelMatchFilter, and LevelRangeFilter filters indicate whether to accept the log event if there is a match. The following lists describe the process of deciding whether a log event is accepted or denied:
  • RepeatMatchFilter
    • If the immediate previous message (%m) is the same as the message (%m) specified in the log event and if AcceptOnMatch is TRUE, then the appender processes the log event.
    • If the previous message (%m) is the same as the message (%m) specified in the log event and if AcceptOnMatch is FALSE, then the appender denies the log event.
  • StringMatchFilter and LevelMatchFilter
    • If there is a match between the filter string or the filter threshold (level) and the log event, and if AcceptOnMatch is TRUE, then the appender processes the log event.
    • If there is a match between the filter string or the filter threshold (level) and the log event, and if AcceptOnMatch is FALSE, then the appender denies the log event.
    • If there is no match between the filter and the log event, then the appender processes the next filter in the filtering policy. If the log event has not been denied and if there are no other filters in the filtering policy, then the appender processes the log event.
  • LevelRangeFilter
    • If there is a match between the minimum and maximum thresholds (inclusive) in the filter and the log event, and if AcceptOnMatch is TRUE, the appender processes the log event.
    • If there is no match, the appender denies the log event.
    • If there is a match between the minimum and maximum thresholds (inclusive) in the filter and the log event, and if AcceptOnMatch is FALSE, then the appender processes the next filter in the filtering policy. If the log event has not been denied and if there are no other filters in the filtering policy, the appender accepts and processes the log event.
  • AndFilter uses StringMatchFilter, LevelMatchFilter, and LevelRangeFilter as arguments. The results of these filters as arguments to the AndFilter class is the same as it is in the individual filters.
You can include DenyAllFilter as the last filter in the filtering policy to deny any log events that do not meet the filtering policy for the appender.
The following example is a simple filtering policy to log only performance messages for the ARM subsystem:
<filter class="StringMatchFilter">
   <param name="StringToMatch" value="Perf.ARM"/>
   <param name="AcceptOnMatch" value="true"/>
</filter>
<filter class="DenyAllFilter">
</filter>
Note: Filter definitions are not available in the logging facility language elements for SAS programs.