Make Your Logs Work for You
The days of logging in to servers and manually viewing log files are over. SolarWinds® Papertrail™ aggregates logs from applications, devices, and platforms to a central location.View Technology Info
Troubleshoot Fast and Enjoy It
SolarWinds® Papertrail™ provides cloud-based log management that seamlessly aggregates logs from applications, servers, network devices, services, platforms, and much more.View Capabilities Info
Aggregate and Search Any Log
SolarWinds® Papertrail™ provides lightning-fast search, live tail, flexible system groups, team-wide access, and integration with popular communications platforms like PagerDuty and Slack to help you quickly track down customer problems, debug app requests, or troubleshoot slow database queries.View Languages Info
Meet the Event Viewer
It's the heart of Papertrail.Start Tour
TAKE A TOUR
TBD - APM Integration Title
TBD - APM Integration DescriptionTBD Link
APM Integration Feature List
TBD - Built for Collaboration Title
TBD - Built for Collaboration DescriptionTBD Link
Built for Collaboration Feature List
Join SolarWinds Day October 19 to see the next evolution in observability. Register now.
Collect Logs: Apps & Services
Collect Logs: Hosting Services
Collect Logs: Integrations
Send Logs for Analytics
SolarWinds Users & Orgs
Support and Security
Papertrail supports a few ways to map senders to groups (like “Production”, “Staging”, “us-west-1”, and “Web apps”), depending on how descriptive the senders’ names are, how many senders exist, how frequently they change, and how you prefer to manage configuration information.
While we love automation, with a small number of senders (2-10) that rarely change, it’s probably overkill. Consider spending 5 minutes to create groups and add the systems manually. Revisit or automate when the number of systems increases or dynamic provisioning is involved.
When senders’ names are descriptive enough to indicate group membership, like
www32.prod, use Papertrail’s dynamic group membership. Create groups and provide name wildcard(s), like
www*. See How are senders named? for more on how systems get their names.
While most loggers default to using the system hostname as a log identifier, and Papertrail honors that, you can easily define a name that is different than the system hostname.
If your provisioning process knows more than the hostname, consider having the provisioning process generate log configs, or even system hostnames, with more informative names. Regardless of how you use Papertrail, this is often useful to do on its own.
If that’s not feasible, there are several convenient options for managing group membership that don’t require a meaningful hostname.
Create a Papertrail log destination per group. On the Destination Settings page, select the target group (like “Production” or “Staging”) under Add new systems to a group?. Have the senders for that group log to that log destination.
When new senders are provisioned, have them run the
papertrail-join-group command-line app.
This works great with automated deployment processes like Chef, Puppet, and VM instance bootstrap scripts. It also means that senders can easily join multiple groups, and that group information is kept in the same place as your other configuration/deployment information.
Related: Amazon EC2
Many of the techniques mentioned here can be used together. For example, log destinations might map to groups, but the destinations could still be configured using an automated deployment system like puppet.