Use remote_syslog2 to aggregate logs from any text file, like app log files, in Unix and BSD.
Papertrail reads log messages from applications and server daemons which do not support - or even know about - syslog.
To send log files from those applications to Papertrail, run Papertrail’s tiny standalone remote_syslog2 daemon. It tracks one or more log files and sends new entries to Papertrail in realtime.
remote_syslog2 works for any text log files, has no impact to the daemon or its logging configuration, and is easy to setup. It forwards logs directly to Papertrail, without relying on the system syslog daemon. No adjustments to
syslog-ng.conf are required.
Note: Some apps, such as MySQL, Apache, and Tomcat (log4j), have internal support for logging directly to syslog. For apps like these, you may use its internal syslog support or use remote_syslog2 as described below.
Download the current release. To extract it and copy the binary into a system path, run:
$ tar xzf ./remote_syslog*.tar.gz $ cd remote_syslog $ sudo cp ./remote_syslog /usr/local/bin
RPM and Debian packages also available.
Paths to log file(s) can be specified on the command-line, or save log_files.yml.example as
/etc/log_files.yml. Edit it to define:
portprovided under log destinations. If no destination port was provided, set
logs.papertrailapp.comand remove the
portconfig line to use the default (514).
Start the daemon:
Logs should appear in Papertrail within a few seconds of being written to the on-disk log file. Problem? See Troubleshooting.
remote_syslog requires read permission on the log files it is monitoring.
remote_syslog2 is daemonized as
remote_syslog. When you’re looking for the process, look for
Install an init file.
First, please feel free to drop a mail into firstname.lastname@example.org, either instead of following these instructions or while trying them. We enjoy helping, and these steps are only here if they let you save time by troubleshooting independently.
Second, there’s a few reasons
remote_syslog might not be sending logs. In order:
Is it running? Check with
ps auxww | grep [r]emote_syslog. Exactly 1 process should be shown, like this:
root 24501 0.0 0.4 13952 8864 ? S Mar01 2:45 remote_syslog
In the example above, the process is running as user
root. If a user other than
root is shown, does that user running
remote_syslog have permission to write to
/var/run/ is the default location for PID files (background)?
remote_syslog isn’t already running as root, try running it as root to test (such as with
sudo), or specify an alternate location for the PID file (such as with
If you can start
remote_syslog but it subsequently stops running, try leaving it attached to the terminal (rather than daemonizing):
Was it working for a day or a week, then stopped overnight (perhaps across many systems at the same time)? This could be a firewall policy change or log rotation. However,
remote_syslog plays well with all common log rotation systems (with no changes to the configuration of either), so we’d like to hear about this problem.
remote_syslog monitoring log files that are stored on an NFS share? If so, enable polling via the
The next step is to see what
remote_syslog is actually doing. Typically that’s with strace, such as:
strace -tt -s 500 -fp 12345
12345 is the process ID of
remote_syslog, obtained from the second column of
ps auxww. This will output every call that it makes. We suggest sending the strace output to a file:
strace -tt -s 500 -fp 12345 -o strace.log
Feel free to send the
strace.log file to us via email@example.com. We’ll look for a few things. Did the OS notify
remote_syslog of writes to the log files? Did
sendto() (UDP) or
send() (TCP) to try sending the message? What happened?
See other options with:
See also Troubleshooting reachability
Can we help? Just ask.