SupportConsoleDevelopersStart a trialContact

Chapter 3. Optimize Loki queries

Configure labels and follow best practices to optimize Loki query performance.

3.1. Best practices for Loki query performance
Copy link

Improve the Loki query performance by using the latest operator version, v13 schema, and fast object storage.

You can take the following steps to improve Loki query performance:

  • Ensure that you are running the latest version of the Loki Operator.
  • Ensure that you have migrated LokiStack schema to the v13 version.

  • Ensure that you use reliable and fast object storage. Loki places significant demands on object storage. If you are not using an object store solution from a cloud provider, use solid-state drive (SSD) for your object storage. By using SSDs you can benefit from the high parallelization capabilities of Loki.

    To better understand the utilization of object storage by Loki, you can use the following query in the Metrics dashboard in the OpenShift Container Platform web console: 

    sum by(status, container, operation) (label_replace(rate(loki_s3_request_duration_seconds_count{namespace="openshift-logging"}[5m]), "status", "${1}xx", "status_code", "([0-9]).."))
  • Loki Operator enables automatic stream sharding by default. The default automatic stream sharding mechanism should be adequate in most cases and users should not need to configure perStream* attributes.
  • If you use the OpenTelemetry Protocol (OTLP) data model, you can configure additional stream labels in LokiStack.
  • Different types of queries have different performance characteristics. Use simple filter queries instead of regular expressions for better performance.

3.2. Best practices for Loki labels
Copy link

Optimize the Loki query performance by properly configuring labels for log sharding and indexing.

Labels in Loki are the keyspace on which Loki shards incoming data. They are also the index used for finding logs at query-time.

Consider the following criteria when creating labels:

  • Labels should describe infrastructure. This could include regions, clusters, servers, applications, namespaces, or environments.
  • Labels are long-lived. Label values should generate logs perpetually, or at least for several hours.
  • Labels are intuitive for querying.

Configure stream labels in the Loki Operator for ViaQ or OpenTelemetry Protocol (OTLP) data models.

Configuring which labels the Loki Operator will use as stream labels depends on the data model you are using: ViaQ or OpenTelemetry Protocol (OTLP). Both models come with a predefined set of stream labels.

ViaQ model

ViaQ does not support structured metadata. To configure stream labels for the ViaQ model, add the configuration in the ClusterLogForwarder resource. For example: 

apiVersion: observability.openshift.io/v1
kind: ClusterLogForwarder
metadata:
  name: instance
  namespace: openshift-logging
spec:
  serviceAccount:
    name: logging-collector
  outputs:
    - name: lokistack-out
      type: lokiStack
      lokiStack:
        target:
          name: logging-loki
          namespace: openshift-logging
        labelKeys:
          application:
            ignoreGlobal: <true_or_false>
            labelKeys: []
          audit:
            ignoreGlobal: <true_or_false>
            labelKeys: []
          infrastructure:
            ignoreGlobal: <true_or_false>
            labelKeys: []
          global: []

lokiStack.labelKeys field contains the configuration that maps log record keys to Loki labels used to identify streams.

OTLP model
In the OTLP model all labels that are not specified as stream labels are attached as structured metadata.

The following are the best practices for creating stream labels:

  • have a low cardinality with at most tens of values.
  • The values are long lived. For example, the first level of an HTTP path: /load, /save, and /update.
  • The labels can be used in queries to improve query performance.
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

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust. Explore our recent updates.

Legal Notice

Theme

© 2026 Red HatBack to top