Typical GCE instances can log to Papertrail the same way any other Linux or Windows host would, but Docker containers on Google Container Engine and apps on Google App Engine require different approaches.
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.
Papertrail can receive logs from Docker containers running on GKE 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).
Pods offer rudimentary control of which containers should run together. It was designed to address multi-container concerns such as log forwarding. Either:
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.
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:
Google Compute Engine has an idle timeout of 10 minutes.