이 콘텐츠는 선택한 언어로 제공되지 않습니다.
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 링크 복사링크가 클립보드에 복사되었습니다!
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)? 링크 복사링크가 클립보드에 복사되었습니다!
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 링크 복사링크가 클립보드에 복사되었습니다!
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 링크 복사링크가 클립보드에 복사되었습니다!
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 링크 복사링크가 클립보드에 복사되었습니다!
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 링크 복사링크가 클립보드에 복사되었습니다!
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 링크 복사링크가 클립보드에 복사되었습니다!
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 |