Google Cloud Platform

Intro

A typical Google Compute Engine VM instance should log to Papertrail the same way as any other Linux or Windows host does. Expand the Configuration sidebar menu and choose your operating system or app framework.

For Docker containers on Google Container Engine or apps on Google App Engine, read on.

Docker containers on Google Container Engine

Papertrail can receive logs from Docker containers running on GCE and Kubernetes. These instructions augment logging from Docker.

At a high level, think of this as a decision whether logging should be an infrastructure-provided concern (conceptually, more similar to persistent storage) or a container-managed concern (more similar to SSH or app configs).

With GCE “pods”

For deployments using GCE pods, where multiple containers can be grouped together, see Papertrail’s logspout instructions.

Pods offer rudimentary control of which containers should run together. It was designed to address multi-container concerns such as log forwarding. Either:

Without GCE pods

Without pods, each container is by definition its own standalone entity, so logging is a container-managed concern. Run a syslog forwarder on each container, such as rsyslog or remote_syslog2. Both use very little resident memory.

remote_syslog2 supports wildcard paths, so a single static remote_syslog2 configuration could be used for many disparate container images. For example, all containers can write logs to a certain directory (or directories), then remote_syslog2 can automatically watch all files in those directories with no container- or log file-specific configuration.

Apps on Google App Engine

A typical App Engine app should log to Papertrail using a language- or app framework-specific sender. Expand the Configuration sidebar menu and choose your language app framework. Here are links to the best methods for App Engine:

Idle timeout

Google Compute Engine has an idle timeout of 10 minutes.