Chapter 4. Loki deployment sizing
Before you install the Loki Operator, choose an initial LokiStack deployment size based on your cluster size. After installation, you measure actual log volume and adjust the deployment size as needed. Starting with an appropriate initial size ensures a smooth deployment and minimizes the need for resizing.
4.1. Understanding 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.
4.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 sizing table shows average QPS at 200ms query latency.
4.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/day)
- Drives ingester CPU and memory requirements. Higher log volume requires more ingesters to handle the write load.
- Retention period
- Drives object storage capacity. Retention multiplied by daily log volume determines total storage needed (for example, 100 GB/day × 30 days = 3 TB storage).
- Query time range
- Affects querier resource requirements. Queries across longer time ranges require more memory and CPU to process results.
4.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)
4.1.4. Determining initial deployment size Copy linkLink copied to clipboard!
Because log volume cannot be predicted before installation, use these baseline recommendations:
- Small clusters (≤10 nodes)
-
Start with
1x.extra-smallsize - Medium to large clusters (>10 nodes)
-
Start with
1x.mediumsize - Single-node OpenShift (SNO) or edge
-
Start with
1x.picosize (minimum viable deployment)
You cannot accurately estimate log volume before installation. Factors that make pre-installation sizing impossible:
- A single pod can produce 100 GB/day of logs
- Log volume varies dramatically based on application verbosity, not pod count
- Infrastructure logs (journald) and audit logs are not produced by containers
- Cluster activity (pod creation/deletion) affects log volume independently of workload size
Start with a baseline size and adjust after monitoring actual log production.
4.1.5. Calculating sizing after installation Copy linkLink copied to clipboard!
After the logging stack is running, calculate the correct size based on observed metrics:
Procedure
- Wait at least 24 hours after installation to capture representative log volume patterns.
Query the actual log ingestion rate using Prometheus:
sum by (component_name) (rate(vector_component_sent_bytes_total{component_type="loki", component_kind="sink"}[5m]))Convert the rate to GB/day and compare against the sizing table:
# Example: If query returns 5242880 bytes/second # = 5242880 * 86400 / 1073741824 = ~421 GB/day # → Requires 1x.small (500 GB/day capacity)Update the
LokiStackCR with the new size if needed:spec: size: 1x.small # Updated from initial 1x.extra-small- Monitor CPU and memory utilization to ensure the deployment is not resource-constrained.
Resizing a LokiStack triggers a rolling restart of components. Plan resizing during maintenance windows.
4.2. Loki deployment sizing 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.
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+ only] | 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 | 430Gi | 430Gi | 590Gi |
| Total disk requests if using the ruler | 60Gi | 910Gi | 750Gi | 750Gi | 910Gi |