Posts tagged syslog

Papertrail supports the remote syslog protocol, so it accepts Web server access logs from rsyslog, syslog-ng, the tiny remote_syslog log file to remote syslog daemon, and other senders.

In that “other senders” category, here’s an elegant hack to have Apache transmit access logs directly to a remote syslog server, using a one-line httpd.conf change.

To transmit with the hostname “www1” and the program name “apache”, add this line:

CustomLog "|nc -u logs.papertrailapp.com 1111" "<134>%{%b %d %X}t www1 apache %h %l %u %t \"%r\"%>s %b \"%{Referer}i\" \"%{User-agent}i\""

This combines netcat, Apache’s CustomLog configuration directive, and Apache’s piped logs feature (which will even restart nc if it crashes). Apache outputs a syslog-framed message to a pipe and nc does the rest. The <134> is the syslog’s priority identifier for facility local0, severity info. That’s followed by the syslog timestamp, system name, and program name.

Everything after “apache” is format specifiers to generate the standard combined log format. The format can be customized. The CustomLog directive works globally and can be used in VirtualHost stanzas.

The reference example is:

CustomLog "|nc -u <destination hostname> <destination port>" "<134>%{%b %d %X}t <system hostname> <program name> %h %l %u %t \"%r\"%>s %b \"%{Referer}i\" \"%{aUser-agent}i\""

This would work for any daemons which can output to a pipe, don’t block on the output (or automatically restart the pipe program, as Apache does), and support a user-supplied template for message formatting. It’s also possible to CustomLog to pipe to the “logger” program (instead of netcat), like this:

CustomLog "|logger -t httpd -p local1.info"

.. and then use your existing syslog daemon to transmit those to Papertrail.

One of our more popular features just got better. If you’ve used Papertrail’s “Cloud Log Destinations,” you know that Papertrail can automatically detect when new systems come online and start generating logs.

When a system starts logging to your cloud destination, Papertrail detects its new hostname and adds it for you. It’s ideal for environments with lots of systems or with short-lived systems or VM instances.

Frequent users may have noticed 2 recent changes:

• These cloud destinations are now the default rather than an alternative. If you’re new to Papertrail, you’ll automatically be using one (and you won’t see the term “cloud destinations,” only “log destinations”). Per-system configuration on Papertrail is rarely required.
• When a given environment has reached a stable set of systems, flip a switch to make Papertrail ignore new hostnames instead of auto-adding them. In the Log Destinations tab within Account, each destination has:

We’re always interested in how this can be better or easier. Enjoy!

Keeping the theme of today’s Apple WWDC iCloud, MobileMe, and iTunes news, here’s how to send logs from your phone, over the Internet, to Papertrail.

Use iOS syslog to troubleshoot an iOS app you’re writing, learn more about your phone’s operations, or make it easy for app testers to send you their phone’s debug logs.

Looks like this (thanks to Mike Beasley):

Here’s how to setup syslogd on your phone: instructions. Note: this depends on a jailbroken iOS device.

Log in to Papertrail and click Add System. Give your phone’s log destination a name (like “bobs-iphone-4g”) and check the “Has dynamic IP or multiple IPs” box since it roams.

Then follow Papertrail’s instructions for OS X (BSD syslog), which you’ll see on the next page. Your phone will be able to log to Papertrail from anywhere with Internet access.

To collect logs from a tester’s phone, register another system and send them the log destination that Papertrail provides.