이 콘텐츠는 선택한 언어로 제공되지 않습니다.

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-small size
Medium to large clusters (>10 nodes)
Start with 1x.medium size
Single-node OpenShift (SNO) or edge
Start with 1x.pico size (minimum viable deployment)
Important

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

  1. Wait at least 24 hours after installation to capture representative log volume patterns.
  2. 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]))
  3. 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)
  4. Update the LokiStack CR with the new size if needed:

    spec:
      size: 1x.small  # Updated from initial 1x.extra-small
  5. Monitor CPU and memory utilization to ensure the deployment is not resource-constrained.
Note

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.

Important

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

Expand
Table 4.1. Loki sizing
 1x.demo1x.pico [6.1+ only]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

430Gi

430Gi

590Gi

Total disk requests if using the ruler

60Gi

910Gi

750Gi

750Gi

910Gi

Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 문서 정보

Legal Notice

Theme

© 2026 Red Hat
맨 위로 이동