Administrator Guide
- Documentation for Papertrail
Collect Logs
Collect Logs: Apps & Services
Collect Logs: Hosting Services
Collect Logs: Integrations
- Fluentd
- Librato
- Amazon CloudWatch
- StatHat
- Amazon SNS
- HostedGraphite
- Datadog
- Zapier
- VictorOps
- New Relic traces
- Slack
- Campfire
- PagerDuty
- New Relic Insights
- Pushover
- AppOptics
- Geckoboard
- OpsGenie
- Honeybadger
Manage Logs
Send Logs for Analytics
SolarWinds Users & Orgs
Support and Security
- Security and Compliance
- Support Policy
What's New
- Papertrail Release Notes

Log filtering

Introduction

Papertrail can filter incoming log messages that match one or more strings or regular expressions (regex) of your choosing.

Log filtering is included with all Papertrail accounts and filtered messages don’t consume log data transfer. Filters are specific to a destination, so 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_syslog2 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.

Search queries can’t be used directly as log filters, but they can usually be translated. Read on to learn how to translate a search query (e.g. host:abc AND program:123) to a regular expression (e.g. ^abc 123:).

Quick start

Log in to Papertrail and click Settings, then click Filter logs under the usage bar.
Select Log Filters for the desired destination. (This step isn’t necessary for Heroku add-on accounts.)
In the log filtering settings, enter the case-sensitive string that matches messages Papertrail should ignore. More.

Example uses

Ignore noise. “Noise” could be requests from monitoring agents, requests for static assets, requests that succeeded and did not modify a resource, or any other log messages which are unlikely to be useful.
Control log verbosity. Drop unnecessary messages from services that you do not have access or ability to change. For example, a closed-source app, a managed service, or a system with strict change control.
Environment-specific log configuration. For example, retain everything in staging and development but silence certain messages in production, or vice versa.
Team-wide control. Let anyone on a team see and change the filtering settings, without needing to understand and modify a config file.
Infrastructure-wide control. Create a single regular expression that reflects your own logging preferences, then apply it to log streams from many systems and apps at once.

Examples

Here are a few common uses. See Setup for complete docs.

Filtering all occurrences of 3 messages

This will drop all messages containing any of the 3 strings. All matches are case-sensitive.

Filtering one program or log file from one sender

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:

^db-server-42 mongod

The ^ 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.

Substrings

Regexes automatically match substrings (unless anchors in the regex specify position, as above). That is, these three expressions are identical:

cron
.*cron.*
cron.*

and 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.

Filtering (“disabling”) multiple senders

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 system-a and system-b:

^(system-a|system-b)

Or filter only messages from noisy-file.log on these two senders:

^(system-a|system-b) noisy-file.log

(If just one system is going crazy, consider temporarily muting it instead.)

Setup

Decide what to filter

Visit Events and browse the full log stream with all log messages. Decide which messages you want to filter.

Each line in the log stream is scanned individually, so multiline or related messages can’t be filtered with a single expression.

Create filter

Click Settings, then click Filter logs under the usage bar. Then, select a log destination’s Log Filters (not necessary for Heroku users). In one of the boxes in the Log Filters area, enter a string or construct a regex that matches each of the messages Papertrail should filter.

For example, to filter all log messages containing debug, enter debug as the filter and choose String. Use the Add and Save buttons to create more filters and save the changes.

Log filters can only be created on account-specific destinations. Logs from senders using a public IP to send to port 514 cannot be filtered.

Test regular expression

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 that should be matched. The expression matches 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).

For example:

Since this regex matches the log message shown, Papertrail would silently discard the message.

Finally, paste a log message that should not match. If it still matches, refine the regex.

The characters .|()[]{}\^$+?* have special meaning when using a regex and need to be escaped by placing a \ before them. 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

Papertrail doesn’t allow “lookaround” ((?!, (?=, (?<) regular expression elements because they have unpredictable performance. Try writing an alternative regex, altering the client’s log configuration, or adding identifiable content to the problem messages. Contact us for further help with advanced filtering.

Advanced

Filtering multiple messages

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

and

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:

Filtering colorized messages

If your logs contain hidden ANSI color codes, these can interfere with filtering. Suppose that your logs colorize the log level (DEBUG, INFO, WARN, ERROR) that occurs immediately after the program name:

and you want to filter out INFO and DEBUG messages from app1. To match an ANSI escape code, use the regex (\e[[0-9;]*m)?. For example, to filter the log lines above, use an expression such as:

app1: (\e\[[0-9;]*m)?(INFO|DEBUG)(\e\[[0-9;]*m)?

The regex

/app1: (INFO|DEBUG)/

would not match, even though it appears to align with the displayed character string.

Papertrail’s standard system and program colors are not applied using ANSI color codes, so don’t require any special filtering.

Filtering by sender

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:

The ^ 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.

Filter by default

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:

Filter them locally. All common loggers (rsyslog, syslog-ng, remote_syslog2) can filter by message contents.
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 that Papertrail can’t serve well, please tell us.

The scripts are not supported under any SolarWinds support program or service. The scripts are provided AS IS without warranty of any kind. SolarWinds further disclaims all warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The risk arising out of the use or performance of the scripts and documentation stays with you. In no event shall SolarWinds or anyone else involved in the creation, production, or delivery of the scripts be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the scripts or documentation.