-
Administrator Guide
-
Collect Logs
-
Collect Logs: Apps & Services
- ESXi
- Routers network hardware
- Apple iOS and macOS
- Unix and BSD system logs
- C# and .NET (NLog)
- C# and .NET (log4net)
- Java logback
- Android
- Kubernetes cluster logging with rKubelog
- haproxy
- Advanced Unix logging tips
- Perl
- Windows
- Kubernetes
- Erlang
- Node.js
- Java log4j
- JavaScript
- Unicorn
- PHP
- Docker
- systemd
- Ruby on Rails
- MySQL
- Unix and BSD text log files (remote_syslog2)
- Redis
- Go
- Python
- Elixir
- IIS
- Embedded devices or proprietary systems
-
Collect Logs: Hosting Services
-
Collect Logs: Integrations
-
Manage Logs
- Groups
- Log flood detection
- Web Hooks
- Log colorization
- Linking to logs
- JSON search syntax
- Settings API
- Log destinations
- Alerts
- Command-line client
- Log filtering
- HTTP API
- Automatic S3 archive export
- Managing Senders
- Permanent log archives
- Mapping senders to groups
- Search syntax
- Click-to-search
- Log search API
- Event Viewer
-
Send Logs for Analytics
-
SolarWinds Users & Orgs
-
Support and Security
-
What's New
Mapping senders to groups
Background
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.
Simpler environments
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.
More complex environments
Senders with descriptive names
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 *prod* or www*. See How are senders named? for more on how systems get their names.
Senders without descriptive names
Consider choosing descriptive sender 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.
I prefer simple
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.
I prefer full-featured
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
Let me control everything
Make calls to Papertrail’s HTTP API. While papertrail-cli wraps the API in command-line tools, you can invoke the API calls directly as well. See Manage Systems, especially Register and Join Group.
Combine these
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.