In previous sections of this guide, we examined logging architectures, node-level logging, cluster-level logging, and sidecar patterns. We also touched upon the benefits of centralized logging. In this section, we’ll expand on centralized logging to look at backend systems and how to use them.
Centralized logging helps access historical log data. With it, manually searching through the logs generated by different nodes or pods on a cluster becomes more manageable. Without a centralized logging system, the logs from a pod could be lost after terminating a pod. In part three of this logging guide, we’ll cover the numerous advantages of centralizing logs.
Understanding Logging in a Kubernetes Cluster
Given the complexity of Kubernetes, knowing where to look in your data for analytics or debugging purposes can be challenging. Capturing pod and system logs is critical for containerized workloads in Kubernetes. You can also collect various other log data types in Kubernetes, such as audit or ingress logs.
In a Kubernetes cluster, applications run as containers. The container runtime handles the generated output and redirects it to a containerized application’s stdout and stderr streams, usually written to log files in JSON format. You can fetch these container logs by running this command:
$ kubectl logs podname
Control plane components, such as etcd, kube-apiserver, and kube-scheduler, collect logs at the Kubernetes cluster level:
- etcd stores information about the desired and actual state of the system. It also contains metrics about disk write performance and gRPC metrics.
- kube-apiserver logs provide information about the API server responsible for serving the API requests. These logs can be found at
- kube-scheduler logs contain information about the cluster’s components responsible for scheduling decisions. These logs can be found at
Combined, these various sources of data provide insight into how Kubernetes performs as a system.
Another log-generating component is kubelet, which runs at the node level. Container runtimes using systemd will log to journald. To access these logs, you can run the
The network proxy, kube-proxy, runs on each node and writes logs to the
/var/log directory. In addition to these logs, we can collect Kubernetes events and auditing logs. If you’re having a cluster-level issue, these logs are a good starting point for troubleshooting.
Using a node logging agent is common as it allows the configuring of logging parameters. For example, you can configure the frequency, log levels, and logging format for the logging agent.
Logging frequency controls how often the logging agent collects and ships the logs to the centralized logging backend. For example, you can configure the logs to ship once every hour. This results in the logs being collected and persisted locally, before sending them to the logging backend every hour.
You can configure log levels to selectively log events only from the defined levels. For example, you can define a configuration to capture all logs of INFO severity or higher.
A centralized logging system is essential for viewing all these logs in one location. Before we dive into what to look for in a log management backend, consider the following differences between non-centralized and centralized logging.
Challenges of Non-centralized Logging
Various challenges arise when you don’t use centralized logging. As the number of logs grows, so does the complexity of the task of identifying or interpreting a problem in your system. For example, if your database is running slowly, you can analyze database slow query logs; however, this shouldn’t be the only place to look. Most systems are multitiered, with frontend, middleware, and database components. You’ll need to examine the logs generated by one or more of these tiers. Moreover, you might need to examine logs generated from other sources, such as underlying server, network, or storage subsystems.
Kubernetes is highly dynamic and distributed in nature, so you will work with multiple machines, each with various containers that can terminate at any time. The logs from the containers become lost once a container is evicted from the node.
All of this makes using a centralized logging backend solution critical. Centralized logging helps to keep track of containers with short lifespans.
Benefits of Centralized Logging
Some of the key benefits of centralizing logs include, but are not limited to:
- Handling different log formats
- Efficient central storage
- Improved querying
- Correlating events
Within Kubernetes, one application will run as one or more pods. Finding a particular log statement or an error message becomes difficult as your cluster grows. For example, if your Kubernetes cluster has multiple replicas of a pod, and any of the pods could serve a particular request, it would be difficult to search for the relevant logs manually.
Centralized logging helps you to avoid issues with short-lived container logs or the abrupt termination of a pod. With centralized logging, pod log data can persist beyond the lifecycle of a container or pod. In addition to helping with troubleshooting, having a centralized logging mechanism is extremely useful for identifying performance bottlenecks.
Looking at logs from different pods or nodes separately can also make it difficult to understand patterns or derive overall system metrics. With a centralized logging system, you can obtain an aggregated view of your system, deriving key metrics about the system’s health and performance. This approach to log analysis makes it easier to quickly catch security issues.
Aggregated logs are also required for security audits and for fulfilling compliance requirements.
Centralized Logging Backends
To make the extensive log data generated by your Kubernetes applications practical, you must collect and aggregate it in a well-structured format. Modern log management tools are designed to retrieve, correlate, and display Kubernetes log data in an interactive interface for additional analytical and technical usage. Let’s look at key features you would need from a centralized logging system for Kubernetes.
Easy Log Searching and Querying
Centralized logging solutions should support search and discovery tools for locating logs and events related to your applications and services. Several platforms support various logging query languages to make the search and discovery easier. For example, Kubernetes logs can differ based on their source, log levels, logging handlers, log format, or severity. A robust query language makes it easier to search these logs.
Scalable Data Ingestion
Centralized logging systems for Kubernetes should provide the capability to comfortably meet the data ingestion requirements as the system scales up or down. It should also offer the ability to use streaming data ingestion to gain immediate system-wide awareness and handle issues.
Complex Data Correlation
The ability to aggregate the data in a centralized logging backend solution allows you to correlate logs and derive useful metrics. Centralized log management unlocks the capability of collecting, storing, and analyzing log data from several sources in a unified platform. When the Kubernetes cluster runs a workload, it might interact with internal or external resources, which could also change its state. Therefore, the logging backend should be capable of correlating logs generated from different components for easy analysis.
Alerting and Analysis
Centralized logging systems for Kubernetes should provide the ability to set up alarms that integrate with third-party tools and manage complex searches. For example, teams might want to integrate with platforms such as PagerDuty or Slack for alert notifications.
Centralized logging systems should also provide insight into seemingly unrelated pieces of data using machine learning or data analysis algorithms.
Moving Toward Centralized Logging for Kubernetes
A centralized logging system for the Kubernetes cluster should provide all the capabilities discussed above. Centralized logging systems make it easier to identify issues, perform security audits, and help fulfill compliance requirements. These systems allow easy log querying, correlating complex data, and supporting scalable data ingestion. With the complexity of a distributed Kubernetes system, using a centralized logging system is essential. In the next section of this series, we’ll look at how to send logs from a Kubernetes cluster with pods running a microservice-backed application to CrowdStrike Falcon LogScale.