-
Administrator Guide
-
Collect Logs
-
Collect Logs: Apps & Services
- ESXi
- Routers network hardware
- Apple iOS and macOS
- Unix and BSD system logs
- C# and .NET (NLog)
- C# and .NET (log4net)
- Java logback
- Android
- Kubernetes cluster logging with rKubelog
- haproxy
- Advanced Unix logging tips
- Perl
- Windows
- Kubernetes
- Erlang
- Node.js
- Java log4j
- JavaScript
- Unicorn
- PHP
- Docker
- systemd
- Ruby on Rails
- MySQL
- Unix and BSD text log files (remote_syslog2)
- Redis
- Go
- Python
- Elixir
- IIS
- Embedded devices or proprietary systems
-
Collect Logs: Hosting Services
-
Collect Logs: Integrations
-
Manage Logs
- Groups
- Log flood detection
- Web Hooks
- Log colorization
- Linking to logs
- JSON search syntax
- Settings API
- Log destinations
- Alerts
- Command-line client
- Log filtering
- HTTP API
- Automatic S3 archive export
- Managing Senders
- Permanent log archives
- Mapping senders to groups
- Search syntax
- Click-to-search
- Log search API
- Event Viewer
-
Send Logs for Analytics
-
SolarWinds Users & Orgs
-
Support and Security
-
What's New
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:
- Java: Use the logback Syslog4jAppender
- Python: Use the standard Python SysLogHandler
- PHP: Send remote syslog from PHP
Idle timeout
Google Compute Engine has an idle timeout of 10 minutes.