How to Keep track of Kubernetes Pod Logs In True-Time With Stern

Stern is an open up-supply device that will make it less complicated to stream actual-time Kubernetes logs to your terminal. You can use Stern to observe logs from numerous containers simultaneously, offering you a blended look at of action inside of Pods.

Why Use Stern?

Kubectl provides built-in log tailing employing the kubectl logs command. Whilst this can do the job perfectly in basic conditions, it lacks support for aggregating logs from several resources with even further filtering of the final results. This can make it cumbersome to use when you require to monitor quite a few Pods or you are operating with verbose data.

image of the Kubernetes log viewer tool, Stern

Stern presents a Kubernetes logs expertise with 1st-class help for several Pods and containers. Each individual container in your log stream is uniquely colorized so you can promptly determine the strains scrolling in front of you. Stern allows you pick the Pods to include things like using complicated queries created from typical expressions.

There is also integrated filtering capabilities to select logs centered on timestamp, container position, and Kubernetes selector. In this write-up, we’ll clearly show how to use all these capabilities to accelerate accessibility to your Kubernetes logs.

Finding Started off

Stern’s dispersed as pre-compiled binaries for Windows, macOS, and Linux on the project’s GitHub releases page. Find the ideal download for your process and increase the binary to your Path. macOS customers can choose to set up by way of Homebrew in its place by functioning brew put in stern.

Stern employs your present Kubernetes config files to join to your cluster. It’ll default to loading .kube/config. Use the --kubeconfig flag or established the KUEBCONFIG natural environment variable if you need to modify this path.

Kubernetes contexts are seamlessly supported also. Include the --context flag to specify a individual context within your presently loaded config file. You can also use the --namespace flag to manually decide on a namespace in your cluster. Stern will only tail logs from objects in just the indicated context and namespace the --all-namespaces flag can be utilized to stream logs from the overall cluster.

Fundamental Use

Stern’s fundamental syntax desires only 1 argument:

stern api-server

Supply a Pod name to stream logs originating from containers in that Pod. This use belies Stern’s real power while the Pod identify is only a single illustration of a pod question.

Pod Queries

Stern takes advantage of Pod queries to identify the log streams to area. Queries are regular expressions so you can assemble superior alternatives of Pods utilizing typical syntax.

The stern api-server instance previously mentioned will match any Pod made up of api-server in its identify. If you modified this to stern .*-server, you’d see logs originating from all your Pods with names that finish in -server. This lets you promptly assemble log streams that mixture lines from multiple components in your stack.

Queries only have an affect on the Pods that are chosen. Stern instantly involves logs from all the containers within people Pods. You can control this working with the optional --container flag which accepts a further regex defining satisfactory container names to contain.

stern .*-server --container .*-

In the same way, you can exclude precise containers employing the --exclude-container flag and a regex:

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

Label selectors are supported way too. Set the --selector flag with a regex defining labels to match Pods versus. This defaults to .*, together with all Pods matching the unique query.

stern .*-server --selector application-model=v1.*

Filtering Primarily based on Container Point out

Stern defaults to only showing logs from managing containers. Use the --container-point out flag to get traces logged by containers in a distinctive condition. It supports operating, waiting around, and terminated parameters:

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

Filtering Individual Log Traces

At the time you have selected the right established of Pods and containers, you can move on to filtering the true log info. Stern offers you a number of possibilities to lower the noise and assist you concentration on significant knowledge:

  • --because – Get logs penned within just a human-readable relative timeframe, due to the fact as 5m or 1h.
  • --tail – Get many this log strains to start with. Defaults to -1 (no restrict), so your terminal is filled with all pre-present logs ahead of the dwell tailed output starts.
  • --exclude – Exclude log traces that match this typical expression. You can use this flag various periods the conditions will be blended as a logical “and” clause.

Here’s an illustration of fetching a restricted selection of recent significant logs from a internet provider:

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

Using Output Templates

Stern usually provides log traces employing the adhering to format:


This structure is customizable working with the --template flag. Go templating syntax is supported to accessibility the Namespace, PodName, ContainerName, and Concept variables within your formatter:

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

Sometimes you might want to read log lines without the need of any more formatting. Employing --output raw will show the simple messages as-is, developing very similar output to Kubectl.

An option possibility is --output json to get log knowledge in a format that’s more suited for programmatic use. It’ll emit a stream of JSON objects with concept, namespace, podName, and containerName properties.

Stern can instantly prepend timestamps to every single log line if you involve the --timestamps flag. This is off by default as quite a few well-liked servers incorporate this information on their own, before a message is emitted.

At last, Stern supports a --shade flag that can be made use of to power or disable the use of colorized output. It accepts car, by no means, or usually as its price. The latter option is beneficial if the program does not thoroughly detect your shell’s TTY.


Stern is a Kubernetes ease resource that would make Pod logs a lot more useful and accessible. You can conveniently hold tabs on numerous Pods and containers with its colorized output, elaborate selectors, and customizable output formats.

Stern’s developed for real-time log tailing as portion of an lively debugging or monitoring procedure. If you’re hunting for long-phrase aggregation, indexing, and storage, it’s commonly best to combine a devoted observability program with your cluster. Platforms like Prometheus and Elastic Stack supply historical inspection abilities to increase the live log streams shown by Stern.

Share this post

Similar Posts

Leave a Reply

Your email address will not be published.