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

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

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

Loki stores logs as streams. Each unique combination of labels creates a separate stream. For example:

  • One stream for application logs from pod-1 in namespace-a
  • A different stream for application logs from pod-2 in namespace-a
  • Another stream for infrastructure logs from kubelet.service on node-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

The Loki data flow:

  1. Collection: Vector collects logs and extracts Kubernetes labels
  2. Ingestion: Loki’s distributor receives logs and forwards them to ingesters
  3. Temporary storage: Ingesters hold logs in memory temporarily
  4. Compression and storage: Ingesters compress logs into chunks and store them in object storage
  5. Indexing: Only the labels (metadata) are indexed, not the log content
  6. 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

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
Important

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

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

Loki uses LogQL, a query language inspired by PromQL (Prometheus Query Language). LogQL queries have two parts:

  1. Label selection: Use Kubernetes labels to select streams
  2. 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.

Red Hat logoGithubRedditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat Documentation

Legal Notice

Theme

© 2026 Red Hat
Back to top