The set of interesting log messages changes depending on the context. Log messages which are…
Papertrail can now filter log messages on behalf of your apps and systems.
Constantly logging a noisy system error that you’re well aware of? Don’t care about requests from monitoring probes? Give us a regular expression and we’ll ignore them. No need to touch your app or system config.
Keep reading or dive right in the docs.
Why is this important?
Usefulness is in the eye of the beholder. It’s not our job to tell you what log messages might be useful, and we’d prefer that it isn’t left to your application or system’s default configuration, either. The logs that the author chose to generate may not have any relationship to the ones you care about.
Our job is to expose intelligently-chosen control and configurability. More succinctly: the knobs that matter. This is one of them.
Logging configs are harder to change than they could be, especially with multiple senders and deployment environments. Papertrail’s log filtering transfers that control from the daemon or framework author to you.
That’s true for managed services too, where a hosting provider may not be able to modify their logging policies to suit a single customer.
Also, Papertrail is in a unique position to provide infrastructure-wide logging control. In addition to message content, Papertrail can filter by sender, program, or log destination, which means there’s a single place to silence almost any unnecessary logs.
We hope this saves time which might otherwise be spent fighting with app configs.
Am I charged for filtered messages?
No. Log filtering is included with all Papertrail accounts and filtered messages don’t consume log data transfer.
Let’s see it in action
A standard Ruby on Rails app generates these messages for every page fragment (“partial”) used in a page:
Although we have easy ways to make Rails less verbose, assume I’m mostly happy with the stock logging except these messages. Knowing the list of page elements that were rendered usually serves no purpose in production, so they’re basically noise. And changing the log output either means omitting other messages (by decreasing verbosity) or monkey-patching Rails.
So, let’s have Papertrail ignore them. Use the filter:
In your log destination configuration (Account), it looks like this:
Users of Papertrail via hosting services may see a slightly different presentation for clarity.
Next, let’s just ignore these messages from senders that begin with “www” (like www1 and www2), not all senders. Also, we don’t care about static asset requests (like images and CSS files), either, so let’s also ignore messages from those senders that contain “/assets”. Use the filter:
wwwd+ W: (Rendered|/assets)
See it in Rubular. The filter is a regular expression. This regex matches any sender name with “www” followed by one or more digits, then any app name from those senders, then either of the messages we want to filter.
Use Papertrail’s log filtering to customize where an app should be verbose and where it should be quiet. No need to be limited by the sending service’s default settings or the implementor’s preferences. Just decide what you don’t want and create a regular expression to match it.