ObservKit / Capacity Planning / Grafana Loki Sizing Calculator
Observability utility
Grafana Loki Sizing Calculator
Object storage, ingester WAL disk and a published compute reference for Loki — data capacity and compute shown separately, every assumption sourced.
Capacity inputs
Planning assumptions Expert
Data capacity
Object storage to plan for · chunks + index, one copy · planning estimate—
Received over retention —
Stored (× factor, before growth) —
Growth buffer —
Estimated cluster-wide WAL · low-confidence rough planning estimate—Includes the replication factor (intake = daily ingest × replication factor), spread across all ingesters. Derived from the only point Grafana publishes (one ingester, ~5 MB/s, ~5,000 series, ~10–15 GB of WAL) and scaled linearly: not a required disk size. Split evenly, about — per ingester would keep the high estimate under the 90% disk-full threshold. Local disk, separate from object storage.
Show math
Replication is not applied to object storage: the distributor writes every stream to replication_factor ingesters, but identical chunks hash to the same object, so the object store holds one copy. The object store provides its own durability.
Grafana reference profile Not calculated for your ingest
—
CPU requests, all components—
Memory requests, all components—
Components in this profile
| Component | CPU request | Memory request | Replicas |
|---|
Assumptions & sources
| Assumption | Source | Limitation | Confidence |
|---|---|---|---|
| Daily ingest is the uncompressed bytes the distributors receive. | Loki observability metrics (v2.9): loki_distributor_bytes_received_total. | Measure over a full week; counts per tenant. | High |
| Stored ÷ received factor: conservative planning assumption of 1.0× (editable); Grafana does not recommend this value. | Storage: chunks are compressed in object storage; no ratio is published. Configuration reference: chunk_encoding defaults to gzip. | Real ratio depends on log content and encoding. Measure loki_ingester_chunk_stored_bytes_total ÷ received bytes (v2.9 metric names). | Low |
| Object storage keeps one copy of each chunk. | Components: identical chunks hash to the same object, so replicas do not write duplicates. | Flushing from the WAL after a restart can reduce deduplication (WAL). The object store's own redundancy is the provider's. | Medium |
| Replication factor 3. | Components: generally 3; configuration reference: default 3. | Sets ingester intake and write quorum, not stored size. | High |
| Estimated cluster-wide WAL ≈ 2,000–3,000 seconds of ingester intake (ingest × replication factor). | WAL: one test, an ingester with 5,000 series ingesting ~5 MB/s and a 5-minute checkpoint, kept ~10–15 GB of WAL disk. | Single data point scaled linearly. Series count, checkpoint interval and flush behavior change it. Low-confidence rough planning estimate, not a required disk size. | Low |
| WAL volume kept under 90%. | WAL: the ingester rejects writes at 90% of the filesystem holding the WAL by default. | The threshold measures the whole filesystem, so give the WAL its own volume. | High |
| Compute is the Grafana reference profile for the ingestion tier (a rough guide). | Size the Loki cluster: CPU, memory and replicas per component, p90 utilization, microservices mode. | Not scaled to your ingest; other deployment modes are not covered; queries can need up to 10× querier resources. | Medium |
| Retention is enforced by the compactor and is off by default. | Retention and configuration reference: retention_enabled false, retention_period 0s. | Object-store lifecycle rules must be longer than the retention period. | High |
| Growth buffer 25% on object storage. | ObservKit planning assumption. | Set it from your own growth forecast. | n/a |
Not modeled: index size separately from chunks, cache memory (memcached), compactor working directory, query workload, per-tenant limits and other deployment modes.
Planning estimates only. Real Loki capacity depends on log content, label cardinality, query load, cache configuration and deployment mode.
Worked example: 250 GB/day for 90 days
Reference scenario the calculator's defaults: 250 GB/day received, 90 days retention, stored ÷ received 1.0, ingester replication factor 3, 6 ingesters and 25% growth. Open this scenario.
| Step | Formula | Result |
|---|---|---|
| Received over retention | 250 GB/day × 90 days | 22.5 TB |
| Stored (chunks + index) | × stored ÷ received 1.0 | 22.5 TB |
| Growth buffer | × 25% | 5.63 TB |
| Object storage to plan for | stored + growth, one copy | 28.1 TB |
| Ingest rate | 250 GB/day ÷ 86,400 s | 2.9 MB/s |
| Ingester intake | rate × replication factor 3 | 8.7 MB/s |
| WAL, all ingesters | intake × 2,000–3,000 s (scaled from Grafana's test) | 17.4 GB–26 GB |
| WAL volume per ingester | high WAL ÷ 6 ingesters ÷ 0.9 | 4.82 GB |
| Compute reference tier | Grafana profile for the tier of this ingest | Less than 100 TB/month (3 TB/day): 38 CPU requests, 59 Gi memory requests |
Data capacity and compute are different quantities and are never added: terabytes of object storage, gigabytes of WAL disk, and CPU and memory requests from a published profile.
Reference scenarios
Reference scenario comparison points, not recommended sizes. Stored ÷ received 1.0, replication factor 3, 6 ingesters, 25% growth.
| Scenario | Inputs | Object storage | WAL, all ingesters | Compute reference tier | Link |
|---|---|---|---|---|---|
| Small | 50 GB/day · 30 days | 1.88 TB | 3.47 GB–5.21 GB | Less than 100 TB/month (3 TB/day) | Open this scenario |
| Medium | 250 GB/day · 90 days | 28.1 TB | 17.4 GB–26 GB | Less than 100 TB/month (3 TB/day) | Open this scenario |
| Large | 3 TB/day · 90 days | 337.5 TB | 208.3 GB–312.5 GB | 100 TB to 1 PB/month (3–30 TB/day) | Open this scenario |
Object storage grows linearly with volume and retention; the WAL follows ingest rate only. At 3 TB/day the compute reference moves to Grafana's 3–30 TB/day profile (431 CPU requests, 857 Gi memory requests), which is a published tier, not a scaled figure.
Common mistakes
- Multiplying object storage by the replication factor. Replication factor 3 writes each stream to three ingesters, but chunks are stored once. Applying it to the 250 GB/day scenario gives 84.4 TB instead of 28.1 TB.
- Assuming a compression ratio you have not measured. The default factor of 1.0× is a conservative planning assumption, not a measurement. Hypothetical example if a week of measurements gave stored ÷ received of 0.25, the 250 GB/day scenario would need 7.03 TB. Open this scenario.
- Sizing the WAL from retention. The WAL holds recent, unflushed data, not retained data: about 26 GB at most for the 250 GB/day scenario, not a share of 28.1 TB. Seven days of retention changes object storage to 2.19 TB and leaves the WAL at 26 GB.
- Provisioning the WAL volume at its expected size. The ingester rejects writes when the filesystem reaches 90%. Dividing by 0.9 takes the per-ingester volume from 4.34 GB to 4.82 GB, and the volume should hold only the WAL because the threshold counts the whole filesystem.
- Scaling the compute reference by your ingest. Grafana's profile is published per ingestion tier. Below 3 TB/day the profile above is not proportional: 38 CPU requests is the profile for the tier, not a function of 50 GB/day. Use it as a ceiling to compare against, then measure.
- Assuming retention happens by itself. Retention runs in the compactor and is off by default (
retention_enabledfalse,retention_period0s), so logs live forever until you enable it. Object storage then grows without a bound that this calculator cannot show. - Fewer ingesters than the replication factor. Each stream is written to that many ingesters, so 3 ingesters at replication factor 3 is the minimum the calculator accepts: 9.65 GB of WAL volume per ingester instead of 4.82 GB with six.
How Loki sizing is calculated
received = daily ingest × retention days
object storage = daily ingest × stored÷received × retention × (1 + growth) one copy
ingest rate = daily ingest ÷ 86,400 s
WAL (all) = ingest rate × replication factor × 2,000–3,000 s
WAL volume = WAL (high) ÷ ingesters ÷ 0.9
compute = Grafana reference profile for the ingestion tier (not computed)- All volumes use decimal units (1,000 GB = 1 TB).
- The 2,000–3,000 s constants are 10–15 GB ÷ 5 MB/s from Grafana's single WAL data point.
- Compute tiers: under 3 TB/day, 3–30 TB/day, and 30 TB/day or more (about 1 PB/month). The boundaries are ObservKit's reading of the published tiers.
- Not modeled: index size apart from chunks, memcached sizing, the compactor working directory, query workload and other deployment modes.
The common capacity model behind every calculator is in the methodology.
Sources
- Size the Loki cluster — Grafana Loki documentation (latest). Reference CPU, memory and replicas per component and ingestion tier.
- Loki components — Grafana Loki documentation (latest). Ingester WAL, distributor replication and quorum, chunks and index in object storage, compactor.
- Storage — Grafana Loki documentation (latest). Chunks and TSDB index in object stores, retention through the compactor.
- Write ahead log — Grafana Loki documentation (latest). The ~5 MB/s test, 90% disk-full threshold, replay behavior.
- Configuration reference — Grafana Loki documentation (latest). Defaults for
replication_factor,chunk_encoding,retention_enabledandretention_period. - Log retention — Grafana Loki documentation (latest). Compactor retention, lifecycle-rule warning.
- Observability metrics — Grafana Loki documentation, v2.9. Metric names for measuring the stored ÷ received factor.
Last reviewed: · Related: Grafana Loki sizing guide · Capacity Planning · Methodology