-
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
Managing Senders
Adding a sender
By default, Papertrail log destinations accept logs from new senders and create the new sender name automatically (see How are senders named?). Adding a sender is as simple as configuring logging for a new machine or app.
In some cases, this relatively open default policy might not be the best fit, so Papertrail also provides more controlled options. Choose the balance between security and flexibility that best fits your environment.
Require registration of new senders
For each log destination, disable auto-detection by unchecking Yes, recognize logs from new systems to make Papertrail silently drop messages sent from system names that don’t already exist.
To register new systems after auto-recognition is disabled, either enable auto-recognition long enough to send a single message, then disable auto-recognition again, or use papertrail-add-system (or the corresponding HTTP API call) to register the system(s).
Configure a random sender identifier
For environments where integrity is critical or where hostnames are publicly known, Papertrail can match messages against a value other than the sender’s hostname, such as an assigned random string.
For example, here’s how to tell Papertrail that the sender named www42 will send with this random string as the syslog hostname:
$ papertrail-add-system --hostname C9M-0t3NxZ2XlpBS-y8upepeS1zNurT -s www42Papertrail will show the system’s hostname, www42, but its messages must contain the C9M… string as the hostname. This string can be used with remote_syslog2 (example), rsyslog (example), and most other senders.
Typically, the combination of the system hostname and the account-specific log destination is unique enough that using a separate random string as an identifier isn’t required.
Use source IPs
Alternatively, on Add Systems, select My syslogd only uses the default port and then provide the IP of each sender.
Disable UDP
Optionally, you may also wish to ensure that every sender has gone through the TCP three-way handshake. To do so, disable UDP logging on the log destination.
How are senders named?
Log senders like rsyslog and remote_syslog2 typically set a sender identifier field in each syslog packet to the system hostname, though it can be set to other values (see Override the hostname sent by a logger).
Because Papertrail accepts inbound links that use the sender name, such as https://papertrailapp.com/systems/www42, the sender name must be unique. When Papertrail receives a log message from a new sender and:
- has been configured to accept messages from unrecognized senders (see Destinations), and
- the sender name in the log message is already in use by an existing sender
Papertrail will append a hyphen and sequence number (-1) to the default sender name shown in Papertrail. For example: www42-1
This display name in Papertrail can still be edited, but it ensures that administrators do not confuse the new sender with an existing sender.
Removing senders
Automatically removing senders
If Automatically remove idle senders? is checked for a log destination, idle senders will be removed two days after their most recent log message is no longer searchable, or one week after they’ve stopped sending, whichever is longer.
Manually removing a sender
If Automatically remove idle senders? (in Log Destination settings) is not checked for a given destination, you’ll need to manually remove any sender that’s no longer needed.
To remove a sender:
- Navigate to your Dashboard.
- Choose the All Systems group link.
- Find the system in the group list, and click the Settings button to the right.
- At the bottom right of the settings page, click Delete this system.
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.