How to Use the Command 'stern' (with examples)

Stern is a powerful command-line tool designed to simplify the process of monitoring logs in a Kubernetes cluster. It allows developers and system administrators to tail the logs of multiple pods and containers simultaneously, facilitating quick diagnosis and debugging. With stern, you can filter logs by various criteria such as namespace, pod status, or pod name regex patterns, making it an invaluable tool for managing complex Kubernetes environments.

Use case 1: Tail All Pods Within a Current Namespace

Code:

stern .

Motivation: When you are working within a specific namespace and you need a holistic view of all the activities happening within the pods, tailing all pod logs can help in real-time debugging, monitoring performance, or detecting any anomalies in your applications.

Explanation:

• The stern command is executed with a dot . indicating that the command should consider all pods within the current namespace. This simplification is particularly useful when you do not need to specify a particular namespace or regex, and you want a broad overview of everything happening in the current context.

Example Output:

+ pod-a › container-1
pod-a log line 1
pod-a log line 2
+ pod-b › container-2
pod-b log line 1
pod-b log line 2

This output demonstrates live log streaming from pods ‘pod-a’ and ‘pod-b’ in the current namespace.

Use case 2: Tail All Pods with a Specific Status

Code:

stern . --container-state running

Motivation: Filtering logs based on pod or container status is crucial when you want to focus only on active containers (running), diagnose issues with stuck containers (waiting), or analyze logs from recently finished containers (terminated).

Explanation:

• The --container-state argument specifies the state of the container to consider. The given state running ensures that only logs from currently executing containers are displayed. Other states like waiting or terminated can be specified alternatively to investigate specific issues related to those states.

Example Output:

+ pod-c › container-a
pod-c log line 1
pod-c log line 2

This shows logs from running containers within the current namespace.

Use case 3: Tail All Pods That Match a Given Regular Expression

Code:

stern pod_query

Motivation: When dealing with a large number of pods, it’s often necessary to focus on a subset of them that pertain to a particular application or service. Regular expressions enable flexible and powerful matching to filter relevant pods.

Explanation:

• pod_query is the regex pattern used to match the desired pods’ names. By specifying a regular expression, stern will only tail logs from pods whose names fit the provided pattern, allowing targeted log monitoring.

Example Output:

+ pod-xy123 › container-main
pod-xy123 log line 1
pod-xy123 log line 2

Here, stern is filtering logs using the regular expression pod_query, targeting pods matching that naming pattern.

Use case 4: Tail Matched Pods from All Namespaces

Code:

stern pod_query --all-namespaces

Motivation: In scenarios where you need insights from pods located across different namespaces, such as when tracking a multi-namespace application, this approach provides a consolidated view of logs from across the entire cluster.

Explanation:

• pod_query remains the regex for matching pod names.
• The --all-namespaces flag tells stern to disregard namespace boundaries. By using this, the command retrieves logs from all namespaces in your Kubernetes cluster, making it ideal for a comprehensive cluster-wide log monitoring solution.

Example Output:

+ namespace-1 › pod-xy123 › container-2
pod-xy123 line 1
+ namespace-2 › pod-xy456 › container-3
pod-xy456 line 1

This output represents logs from matched pods in multiple namespaces.

Use case 5: Tail Matched Pods from 15 Minutes Ago

Code:

stern pod_query --since 15m

Motivation: Checking logs from a specific historical window is useful for retrospectives, incident investigations, or verifying the impacts of recent changes in your system that occurred within a defined timeframe, like the last 15 minutes.

Explanation:

• The --since argument followed by 15m specifies that the logs should be fetched from the past 15 minutes. This helps to focus log monitoring on a recent time frame that might correspond to a suspected incident or event, providing a snapshot view of past activities.

Example Output:

+ pod-xy123 › container-4
[15m ago] pod-xy123 log line 1
[15m ago] pod-xy123 log line 2

The logs captured are from the past 15 minutes, providing retrospective insights.

Use case 6: Tail Matched Pods with a Specific Label

Code:

stern pod_query --selector release=canary

Motivation: Labels are a key component in orchestrating and managing Kubernetes resources. By filtering logs based on specific labels, such as release=canary, you can focus on a particular deployment environment or phase (e.g., canary, production, testing).

Explanation:

• pod_query represents the regex for pod matching, a standard practice across use cases.
• The --selector release=canary argument allows filtering pods where the label release matches canary. This label-based filtering is beneficial when monitoring or debugging specific deployment types.

Example Output:

+ pod-jkl › container-app
pod-jkl log line 1
pod-jkl log line 2

This shows logs from pods labeled as release=canary, helping isolate environments and ensuring targeted debugging efforts.

Conclusion:

Stern offers a robust and flexible solution for monitoring Kubernetes pod logs with ease. By utilizing its various options and filters, such as namespaces, states, regex matches, timeframes, and labels, IT professionals can efficiently manage and debug applications running on Kubernetes, tailoring log outputs to meet specific needs. Stern’s ability to provide real-time insights is crucial for maintaining optimal performance and reliability in dynamic and complex Kubernetes environments.