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 Copy linkLink copied to clipboard!
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) Copy linkLink copied to clipboard!
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
5.1.2. How log volume affects sizing Copy linkLink copied to clipboard!
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 Copy linkLink copied to clipboard!
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 Copy linkLink copied to clipboard!
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.smallsize. This provides capacity for 500 GB/day and allows headroom for log volume spikes. - Development, test, or low-traffic clusters
-
Start with
1x.extra-smallsize. This handles 100 GB/day and can be resized up after monitoring actual usage. - Single-node OpenShift (SNO) or edge deployments
-
Start with
1x.picosize. This is the minimum viable deployment (50 GB/day) for resource-constrained environments.
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 Copy linkLink copied to clipboard!
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.
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.
It is not possible to change the number 1x for the deployment size.
| 1x.demo | 1x.pico (6.1 and later) | 1x.extra-small | 1x.small | 1x.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 |