Chapter 3. Loki log store
Loki is an optional component of OpenShift Logging that provides local log storage for short-term troubleshooting. Loki is a horizontally scalable, highly available log aggregation system that uses labels to organize and query logs.
3.1. What Loki is Copy linkLink copied to clipboard!
Loki is a log aggregation system inspired by Prometheus. Unlike traditional logging systems that index the full contents of every log line, Loki indexes only a small set of labels extracted from the log payload, called stream labels. The actual log content is compressed and stored in object storage such as Amazon S3, Google Cloud Storage, or Azure Blob Storage.
This label-based indexing approach makes Loki:
- Cost-effective: Loki indexes stream labels rather than the full log content, reducing indexing overhead and index storage requirements. At query time, Loki retrieves the selected chunks and filters or parses their contents as required, so broad searches can still consume substantial resources.
- Horizontally scalable: Add more ingesters or queriers as log volume grows
- Kubernetes-native: Uses Kubernetes labels you already have for pod, namespace, and container selection
3.2. How Loki uses Kubernetes labels Copy linkLink copied to clipboard!
Loki organizes logs into streams, where each stream is identified by a unique set of labels. When Vector sends logs to Loki, it automatically extracts labels from Kubernetes metadata:
- kubernetes_namespace_name: The namespace where the pod runs
- kubernetes_pod_name: The name of the pod
- kubernetes_container_name: The container within the pod
- kubernetes_host: The node where the pod runs
- log_type: Whether the log is application, infrastructure, or audit
For infrastructure logs from systemd, Loki also extracts:
-
systemd_unit: The systemd unit that generated the log (for example,
kubelet.service)
These Kubernetes labels enable you to select and filter logs exactly as you would select pods with kubectl. For example, you can query:
- All logs from a specific namespace
- Logs from a particular pod
- All application logs across all namespaces
- Infrastructure logs from the kubelet service on specific nodes
3.3. Streams and labels Copy linkLink copied to clipboard!
Loki stores logs as streams. Each unique combination of labels creates a separate stream. For example:
-
One stream for application logs from
pod-1innamespace-a -
A different stream for application logs from
pod-2innamespace-a -
Another stream for infrastructure logs from
kubelet.serviceonnode-1
When you query Loki by using LogQL (Loki’s query language), you first select streams by their labels, then filter the log content within those streams. This two-step process mirrors how Kubernetes works: select resources by labels, then examine their content.
3.4. How Loki works Copy linkLink copied to clipboard!
The Loki data flow:
- Collection: Vector collects logs and extracts Kubernetes labels
- Ingestion: Loki’s distributor receives logs and forwards them to ingesters
- Temporary storage: Ingesters hold logs in memory temporarily
- Compression and storage: Ingesters compress logs into chunks and store them in object storage
- Indexing: Only the labels (metadata) are indexed, not the log content
- Querying: When you query, Loki uses the index to find relevant streams, then decompresses chunks to return matching log lines
3.5. Short-term storage design Copy linkLink copied to clipboard!
The OpenShift Logging configuration of Loki is designed for short-term log storage and fast troubleshooting, not long-term archival.
Key characteristics:
- Tested and supported retention up to 30 days: OpenShift Logging LokiStack sizing is tested and supported for retention periods up to 30 days. Logs are not automatically expired; configure retention explicitly to ensure that logs are deleted.
- Optimized for recent queries: Performance is best when querying recent logs (last few hours or days)
- Short-term troubleshooting: Ideal for debugging current issues, not historical analysis
For long-term storage, compliance archives, or queries spanning more than 30 days, forward logs to an external log management platform in addition to or instead of using Loki.
3.6. Loki components Copy linkLink copied to clipboard!
When you deploy Loki in OpenShift using the LokiStack custom resource, you deploy several components:
- Distributor
- Receives logs from Vector and forwards them to ingesters
- Ingester
- Temporarily holds logs in memory, then compresses and stores them as chunks in object storage
- Querier
- Fetches data from the index and object storage to answer queries
- Query Frontend
- Processes and optimizes queries before sending them to queriers
- Ruler (optional)
- Evaluates alerting and recording rules on log data
The Loki Operator manages these components and their scaling based on your LokiStack configuration.
3.7. Querying Loki with LogQL Copy linkLink copied to clipboard!
Loki uses LogQL, a query language inspired by PromQL (Prometheus Query Language). LogQL queries have two parts:
- Label selection: Use Kubernetes labels to select streams
- Content filtering: Filter log lines by content within selected streams
Example queries:
Select all application logs from namespace
my-app:{log_type="application", kubernetes_namespace_name="my-app"}Find errors in a specific pod:
{kubernetes_namespace_name="my-app", kubernetes_pod_name="web-1"} |= "error"Query infrastructure logs from kubelet:
{log_type="infrastructure", systemd_unit="kubelet.service"}
You can query Loki through the OpenShift web console (if you have the Cluster Observability Operator installed), Grafana, or the Loki API directly.