Chapter 5. Size your LokiStack deployment


This topic provides guidance for both pre-installation and post-installation sizing:

  • Before installation, choose an initial deployment size using the baseline recommendations. You cannot accurately predict log volume before installation.
  • After installation, measure actual log volume using Prometheus metrics and the LokiStack dashboards, and then adjust the deployment size as needed.

Starting with an appropriate initial size ensures a smooth deployment and minimizes the need for resizing.

If your deployment exceeds the capacity of the chosen size, you can either increase the LokiStack size or scale individual components.

5.1. Understand Loki deployment sizing

Understanding how to size your Loki deployment helps you avoid performance issues and ensure logs are reliably collected and queryable.

5.1.1. What is QPS (Queries Per Second)

QPS (Queries Per Second) measures the rate of log queries against your LokiStack. Common sources of queries include:

  • User queries from the OpenShift web console
  • Dashboard auto-refresh intervals (for example, Grafana dashboards refreshing every 30 seconds)
  • Alert rule evaluations running continuously
  • API queries from monitoring and observability tools

A single user running multiple dashboards can generate 10-20 QPS. The LokiStack sizing table shows average QPS at 200ms query latency.

After you install the LokiStack, you can view actual QPS metrics on the LokiStack Reads and LokiStack Writes dashboards. In the OpenShift Container Platform web console, navigate to Observe Dashboards. The LokiStack Writes dashboard is particularly important for scaling decisions, as it shows the write load on LokiStack components receiving logs from the collector.

5.1.2. How log volume affects sizing

Log volume directly impacts the resources required for Loki components:

Ingestion rate (GB per day)
Drives ingester CPU and memory requirements. Higher log volume requires more ingesters to handle the write load.
Retention period
Drives object storage capacity. Loki compresses logs using the Snappy algorithm with a typical compression factor of 5-7x. Calculate storage as: daily log volume ÷ 6 × retention days (for example, 100 GB per day ÷ 6 × 30 days = 500 GB storage). Actual compression varies based on log content.
Query time range
Affects querier resource requirements. Queries across longer time ranges require more memory and CPU to process results.

5.1.3. Ruler component CPU requirements

The ruler component evaluates alerting rules and retention policies continuously. Enabling the ruler significantly increases CPU requirements:

  • Processes alerting rules against incoming log streams
  • Evaluates retention policies for log deletion
  • Scales based on: number of tenants × number of rules × log data volume

For example, the 1x.medium size requires:

  • Without ruler: 34 vCPUs
  • With ruler: 42 vCPUs (+8 vCPUs for ruler evaluation)

5.1.4. Determining initial deployment size

You cannot accurately estimate log volume before installation because log production depends on application verbosity, infrastructure events, and audit configuration, not cluster size. Start with a conservative initial size and adjust after measuring actual log volume.

Use these baseline recommendations for initial deployment:

Production clusters with typical workloads
Start with 1x.small size. This provides capacity for 500 GB/day and allows headroom for log volume spikes.
Development, test, or low-traffic clusters
Start with 1x.extra-small size. This handles 100 GB/day and can be resized up after monitoring actual usage.
Single-node OpenShift (SNO) or edge deployments
Start with 1x.pico size. This is the minimum viable deployment (50 GB/day) for resource-constrained environments.
Important

Factors that make pre-installation log volume estimation impossible:

  • A single verbose application pod can produce 100 GB per day of logs
  • Log volume varies dramatically based on application log levels (DEBUG vs ERROR)
  • Infrastructure logs (systemd-journald) and audit logs are not produced by containers
  • Cluster activity (pod creation/deletion/restart) generates variable log volume
  • Storage backend performance affects ingestion rate and query performance

After installation, measure actual log volume and adjust the size using observed metrics.

5.2. LokiStack deployment size specifications

Loki sizing follows the 1x.<size> format to specify deployment capacity and performance.

Sizing for Loki follows the format of 1x.<size> where the value 1x is number of instances and <size> specifies performance capabilities.

Note

Starting in logging 6.6, the 1x.extra-small and 1x.small deployment sizes use 3 Loki ingesters instead of 2. This increases the total disk requests for these sizes compared to earlier versions.

The 1x.pico configuration defines a single Loki deployment with minimal resource and limit requirements, offering high availability (HA) support for all Loki components. This configuration is suited for deployments that do not require a single replication factor or auto-compaction.

Disk requests are similar across size configurations, allowing customers to test different sizes to determine the best fit for their deployment needs.

Important

It is not possible to change the number 1x for the deployment size.

Table 5.1. Loki sizing
 1x.demo1x.pico (6.1 and later)1x.extra-small1x.small1x.medium

Data transfer

Demo use only

50GB/day

100GB/day

500GB/day

2TB/day

Queries per second (QPS)

Demo use only

1-25 QPS at 200ms

1-25 QPS at 200ms

25-50 QPS at 200ms

25-75 QPS at 200ms

Replication factor

None

2

2

2

2

Total CPU requests

None

7 vCPUs

14 vCPUs

34 vCPUs

54 vCPUs

Total CPU requests if using the ruler

None

8 vCPUs

16 vCPUs

42 vCPUs

70 vCPUs

Total memory requests

None

17Gi

31Gi

67Gi

139Gi

Total memory requests if using the ruler

None

18Gi

35Gi

83Gi

171Gi

Total disk requests

40Gi

590Gi

590Gi

590Gi

590Gi

Total disk requests if using the ruler

60Gi

910Gi

910Gi

910Gi

910Gi

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