[ad_1]
Stern is an open source tool that makes it easy to stream real-time Kubernetes logs to your endpoint. You can use Stern to monitor logs from multiple containers simultaneously, giving you a combined view of activity within pods.
Why use stern?
Kubectl offers integrated log tracking using the kubectl logs domain. Although this may 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 multiple Pods or are working with detailed data.
Stern offers a Kubernetes logs experience with world-class support for multiple pods and containers. Each container in your registration flow has a unique color so you can quickly identify the lines scrolling in front of you. Stern allows you to select the Pods to include using complex queries built from regular expressions.
There are also built-in filtering capabilities to select logs based on timestamp, container state, and Kubernetes picker. In this article, we’ll show you how to use all of these features to speed up access to your Kubernetes logs.
Starting
Stern is distributed as precompiled 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 choose to install via Homebrew instead by running brew install stern.
Stern uses your existing Kubernetes configuration files to connect to your cluster. By default it will load .kube/config. Use the --kubeconfig mark or set KUEBCONFIG environment variable if you need to change this path.
Kubernetes contexts are also fully supported. Add the --context flag to specify a particular context within your currently loaded configuration file. You can also use the --namespace check to manually select a namespace in your cluster. Stern will only follow records for objects within the given context and namespace; the --all-namespaces The flag can be used to stream logs from across the cluster.
basic use
The basic Stern syntax only needs one argument:
stern api-server
Provide a pod name to stream logs originating from containers in that pod. However, this usage belies Stern’s true power; the Pod name is just an example of a pod query.
pod queries
Stern uses Pod queries to determine the log streams that emerge. The queries are regular expressions so he can assemble advanced pod selections using standard syntax.
the stern api-server example above will match any Pod that contains api-server on his behalf If you changed this to stern .*-serveryou would see logs originating from all your pods with names ending in -server. This allows you to quickly assemble register streams that add lines from multiple components onto your stack.
The queries only affect the pods that are selected. Stern automatically includes logs from all containers within those Pods. You can control this using the optional --container flag that accepts another regular expression that defines acceptable container names to include.
stern .*-server --container .*-0
Similarly, you can exclude specific containers using the --exclude-container flag and a regular expression:
stern .*-server --exclude-container .*-helper
Tag selectors are also supported. Select the --selector marks with a regular expression that defines tags to match the Pods against. This default is .*including all pods that match the original query.
stern .*-server --selector app-version=v1.*
Filtering based on container state
By default, Stern only shows logs for running containers. Use the --container-state flag to get lines registered by containers in a different state. it’s compatible running, waitingY terminated parameters:
# Show logs from stopped containers stern .*-server --container-state terminated
Filtering individual log lines
Once you’ve selected the correct set of pods and containers, you can move on to filtering the actual log data. Stern gives you a few options to reduce noise and help you focus on meaningful data:
--since– Get logs written within a relative human-readable time frame, since as5meither1h.--tail– Get lots of these log lines to get started. Default to-1(no limit), so your terminal is populated with all pre-existing records before the live-queued 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 getting a limited selection of recent significant records from a web service:
stern web-server --since 1h --tail 100 --exclude .*GET /robots.txt.*
Using output templates
Stern normally outputs log lines using the following format:
<namespace name> <pod name> <container name> <original log line>
This format is customizable using the --template flag. Go template syntax is supported for accessing the Namespace, PodName, ContainerNameY Message variables inside your formatter:
stern .*-server --template 'Namespace: {{.Namespace}} Pod: {{.PodName}} - {{.Message}}'
Sometimes you may want to read the log lines without any additional formatting. Wearing --output raw will display the raw messages as is, producing output similar to Kubectl.
An alternative option is --output json to get log data in a format that is more suitable for programmatic consumption. It will output a stream of JSON objects with message, namespace, podNameY 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 issued.
Finally, Stern supports a --color flag that can be used to force or disable the use of colored output. you accept auto, nevereither always as its value. The last option is useful if the program does not correctly detect your shell’s TTY.
Summary
Stern is a Kubernetes convenience tool that makes Pod logs more useful and accessible. You can easily control multiple Pods and Containers with its colored output, complex selectors, and customizable output formats.
Stern is designed for real-time log tracking as part of an active debugging or monitoring process. If you’re looking for aggregation, indexing, and long-term storage, it’s usually best to integrate a dedicated observability system with your cluster. Platforms like Prometheus and the Elastic Stack provide historical inspection capabilities to augment the live log streams displayed by Stern.
[ad_2]
