Stern is an open-source tool that makes it easier to stream real-time Kubernetes logs to your terminal. You can use Stern to monitor logs from multiple containers simultaneously, giving you a combined view of activity inside Pods.

Why Use Stern?

Kubectl offers built-in log tailing using the kubectl logs command. Although this can work well in simple cases, it lacks support for aggregating logs from multiple sources with further filtering of the results. This can make it cumbersome to use when you need to monitor several Pods or you’re working with verbose data.

Stern offers a Kubernetes logs experience with first-class support for multiple Pods and containers. Each container in your log stream is uniquely colorized so you can quickly identify the lines scrolling in front of you. Stern lets you select the Pods to include using complex queries built from regular expressions.

There’s also integrated filtering capabilities to select logs based on timestamp, container status, and Kubernetes selector. In this article, we’ll show how to use all these features to accelerate access to your Kubernetes logs.

Getting Started

Stern’s distributed as pre-compiled binaries for Windows, macOS, and Linux on the project’s GitHub releases page. Select the appropriate download for your system and add the binary to your PATH. macOS users can opt to install via Homebrew instead by running brew install stern.

Stern uses your existing Kubernetes config files to connect to your cluster. It’ll default to loading .kube/config. Use the --kubeconfig flag or set the KUEBCONFIG environment variable if you need to change this path.

Kubernetes contexts are seamlessly supported too. Add the --context flag to specify a particular context within your currently loaded config file. You can also use the --namespace flag to manually select a namespace in your cluster. Stern will only tail logs from objects within the indicated context and namespace; the --all-namespaces flag can be used to stream logs from the entire cluster.

Basic Usage

Stern’s basic syntax needs only one argument:

stern api-server

Supply a Pod name to stream logs originating from containers in that Pod. This usage belies Stern’s true power though; the Pod name is only one example of a pod query.

Pod Queries

Stern uses Pod queries to determine the log streams to surface. Queries are regular expressions so you can assemble advanced selections of Pods using standard syntax.

The stern api-server example above will match any Pod containing api-server in its name. If you changed this to stern .*-server, you’d see logs originating from all your Pods with names that end in -server. This lets you rapidly assemble log streams that aggregate lines from multiple components in your stack.

Queries only affect the Pods that are selected. Stern automatically includes logs from all the containers within those Pods. You can control this using the optional --container flag which accepts another regex defining acceptable container names to include.

stern .*-server --container .*-0

Similarly, you can exclude specific containers using the --exclude-container flag and a regex:

stern .*-server --exclude-container .*-helper

Label selectors are supported too. Set the --selector flag with a regex defining labels to match Pods against. This defaults to .*, including all Pods matching the original query.

stern .*-server --selector app-version=v1.*

Filtering Based on Container State

Stern defaults to only showing logs from running containers. Use the --container-state flag to get lines logged by containers in a different state. It supports running, waiting, and terminated parameters:

# Show logs from stopped containers
stern .*-server --container-state terminated

Filtering Individual Log Lines

Once you’ve selected the right set of Pods and containers, you can move onto filtering the actual log data. Stern gives you a few options to reduce the noise and help you focus on meaningful data:

• --since – Get logs written within a human-readable relative timeframe, since as 5m or 1h.
• --tail – Get many this log lines to begin with. Defaults to -1 (no limit), so your terminal is filled with all pre-existing logs before the live tailed output begins.
• --exclude – Exclude log lines that match this regular expression. You can use this flag multiple times; the conditions will be combined as a logical “and” clause.

Here’s an example of fetching a limited selection of recent meaningful logs from a web service:

stern web-server --since 1h --tail 100 --exclude .*GET /robots.txt.*

Using Output Templates

Stern normally presents log lines using the following format:

<namespace name> <pod name> <container name> <original log line>

This format is customizable using the --template flag. Go templating syntax is supported to access the Namespace, PodName, ContainerName, and Message variables inside your formatter:

stern .*-server --template 'Namespace: {{.Namespace}} Pod: {{.PodName}} - {{.Message}}'

Sometimes you might want to read log lines without any extra formatting. Using --output raw will show the plain messages as-is, producing similar output to Kubectl.

An alternative option is --output json to get log data in a format that’s more suitable for programmatic consumption. It’ll emit a stream of JSON objects with message, namespace, podName, and containerName properties.

Stern can automatically prepend timestamps to each log line if you include the --timestamps flag. This is off by default as many popular servers add this information themselves, before a message is emitted.

Finally, Stern supports a --color flag that can be used to force or disable the use of colorized output. It accepts auto, never, or always as its value. The latter option is useful if the program doesn’t properly detect your shell’s TTY.

Summary

Stern is a Kubernetes convenience tool that makes Pod logs more useful and accessible. You can easily keep tabs on multiple Pods and containers with its colorized output, complex selectors, and customizable output formats.

Stern’s designed for real-time log tailing as part of an active debugging or monitoring process. If you’re looking for long-term aggregation, indexing, and storage, it’s usually best to integrate a dedicated observability system with your cluster. Platforms like Prometheus and Elastic Stack provide historical inspection capabilities to augment the live log streams shown by Stern.