Papertrail can filter incoming log messages that match one or more strings or regular expressions (regex) of your choosing. Here’s how.
Log filtering is included with all Papertrail accounts and filtered messages don’t consume log data transfer. Filters are specific to a destination, which means that different environments, systems, or apps can have their own settings.
Papertrail’s log filter is an additional tool. The sending client or app can still filter logs, like with the remote_syslog
exclude_patterns option or by changing an app’s log settings. These filters are independent of any Papertrail filter.
Trying to find a log message in Papertrail’s log viewer? This page covers how to drop log messages, not how to search for them. Visit Search syntax instead.
Log Destinations. Users accessing Papertrail via an app hosting service should see a section titled
Log Filteringon the main
Here are a few common uses. Read on for complete docs.
This will drop all messages containing any of the 3 strings. All matches are case-sensitive.
Imagine you have one program generating log messages that you don’t want.
Filter all messages from the program
mongod on the system
db-server-42 using the regex:
^ indicates that the match must happen from the start of a log message. The sender name (in this example,
db-server-42) is the name as shown on the Dashboard.
Regexes automatically match substrings (unless other parts of the regex constrain them further). That is, these three expressions are identical:
cron .*cron.* cron.*
They will all match any string containing
cron, with or without any leading or following characters. Including
.* before or after a typical filter rule is unnecessary and should be omitted.
Imagine you have two sending systems which are temporarily generating an undesirable torrent of log messages that you don’t want. Filter all messages from the senders
Or filter only messages from
noisy-file.log on these two senders:
Visit Events and browse the full log stream with all log message. Decide which messages you want to filter.
Copy and paste a string or construct a regex that matches each of the messages which Papertrail should filter.
For example, to filter all log messages containing
debug, simply use
debug as the filter and choose String.
When constructing a regex to filter messages, we recommend using Rubular with Ruby version 2.0.0 selected for testing. This isn’t exactly the same regex engine that Papertrail uses, but it’s a close approximation.
Paste the filter expression created above, then copy a sample log message of each message type which should be matched. We test against everything shown in the Papertrail viewer except for the timestamp, so include the sender name, program name, a colon, and then the message (as shown in the ‘Your test string’ input box below).
Since this regex matches the log message shown, Papertrail would silently discard the message.
Finally, paste a log message which should not match. Confirm that the filter is not too permissive.
Note that certain characters have special meaning when using a regex and need to be escaped by placing a
\ before them.
These are special characters:
To match log messages containing
GET a.b.c type=json, use a filter string that escapes each special character:
GET a\.b\.c type=json
Log filtering is configured from the
Settings menu in Papertrail.
Most users will see a
Log Destinations menu option in the left hand menu. Users accessing Papertrail via an app hosting service may see a
Log Filtering form field on the main
Settings page itself.
Paste the regex and click
A more complex example would match multiple messages or only messages from certain senders or apps. For example, suppose that these two messages serve no operational purpose:
www42 httpd: 127.0.0.1 - "GET / HTTP/1.0" 200 3
util2 kernel: nf_conntrack: automatic helper assignment is deprecated and it will be removed soon. Use the iptables CT target to attach helpers instead.
Find the portion of the log that occurs in all such messages.
Here we’ll use
127.0.0.1 - "GET / HTTP/1.0" 200 (a successful HTTP request from the Web server itself) and
nf_conntrack: automatic helper assignment is deprecated (a warning which could be repeated).
The following would filter all successful web requests (any HTTP status 200-299) and the warning:
Papertrail matches your regular expression against the complete log message as it is formatted in the viewer. This allows you to include the name of the sender and/or program (or a substring of them) as part of the filter.
Using the examples above, to filter each message from only the system shown in the example, use a filter like:
^ indicates that the match must be at the very start of the log. The sender name is the same display name shown on the Papertrail dashboard.
Note: if you use the sender name in a filter and then edit the sender name, the filter will need to be updated as well.
Papertrail’s default policy is to process messages it receives, which means that the filter string is deciding which messages are ignored. While there’s currently no support for an inverse filter (default behavior of ignoring log messages), these two workarounds often accomplish the same behavior:
Pick the top few message types and have papertrail filter them. Often this can get close to the same result. Here’s an example. In most cases this is simply:
string from one|string from the other|repeat for more messages
If you have a filtering requirement which Papertrail can’t serve well, please tell us.