Make Your Logs Work for You

The days of logging in to servers and manually viewing log files are over. SolarWinds® Papertrail™ aggregates logs from applications, devices, and platforms to a central location.

View Technology Info

FEATURED TECHNOLOGY

Troubleshoot Fast and Enjoy It

SolarWinds® Papertrail™ provides cloud-based log management that seamlessly aggregates logs from applications, servers, network devices, services, platforms, and much more.

View Capabilities Info

FEATURED CAPABILITIES

Aggregate and Search Any Log

SolarWinds® Papertrail™ provides lightning-fast search, live tail, flexible system groups, team-wide access, and integration with popular communications platforms like PagerDuty and Slack to help you quickly track down customer problems, debug app requests, or troubleshoot slow database queries.

View Languages Info

FEATURED LANGUAGES

TBD - APM Integration Title

TBD - APM Integration Description

TBD Link

APM Integration Feature List

TBD - Built for Collaboration Title

TBD - Built for Collaboration Description

TBD Link

Built for Collaboration Feature List

Collect Logs: Hosting Services > Google Cloud Platform

Google Cloud Platform

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.

Typical GCE instance

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.

Docker containers on Google Container Engine

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).

With GKE “pods”

For deployments using GKE pods, where multiple containers can be grouped together, see Papertrail’s logspout instructions, or for more pod-level options, check out Kubernetes.

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

  • include a per-pod logspout container in the pod, or
  • use a shared mount (like a persistent volume) to expose log files from many containers to a forwarder container. The forwarder container can run any syslog sender, such as rsyslog or remote_syslog2.

Without GKE 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.