Sizing methodology

Principles

• Formulas are visible. Every calculator shows its math for the current inputs and a static description of the model.
• Assumptions are explicit. Defaults such as Splunk's 15% / 35% ratios or the 85% planning utilization target are named, sourced and editable.
• Vendor documentation comes first. Where Splunk or Elastic document a behavior, the model follows it and links the page and version. ObservKit's own assumptions are labelled as such, for example the 10% frozen cache.
• A planning estimate is not a guarantee. Results size storage; they do not replace workload testing, vendor sizing or validated architectures.
• Local-first. Calculations run in the browser; inputs are not sent to a server.
• Models change when evidence changes. Corrections are recorded in the changelog below with their impact.

Common model

1. Ingest
2. Retention
3. On-disk factor
4. Copies / replicas
5. Growth / headroom
6. Provisioned capacity

dataset     = daily ingest × retention days
on disk     = dataset × on-disk factor           (compression, index structures, mappings)
copies      = on disk × copies                    (replication, search factor, replicas)
usable      = copies × (1 + growth)
provisioned = usable ÷ utilization target          (where the platform needs free disk)

The generic Log Storage model uses an on-disk factor of 1.0 and no utilization target. The platform models replace each factor with the platform's documented behavior. The Capacity Planning hub walks 250 GB/day through all three models side by side.

Vendor-specific models

Splunk

Rawdata about 15% of pre-indexed volume on every copy (× RF), index files about 35% on searchable copies only (× SF). SmartStore replaces retention-sized local disk with a cache window plus replicated hot buckets, and stores one remote copy of warm buckets. Details: how Splunk sizing is calculated, SmartStore guide.

Elasticsearch

Raw volume × index/raw factor per tier; replicas on regular indices only; fully mounted searchable snapshots keep one local copy and frozen keeps a cache, with the dataset in the snapshot repository; provisioned disk = usable ÷ 85% planning utilization (÷ 90% shared-cache share on frozen). Details: how Elastic sizing is calculated, data tiers guide.

Grafana Loki

Object storage holds one copy of compressed chunks and index. Grafana publishes no compression ratio, so the stored ÷ received factor is a conservative ObservKit planning assumption of 1.0× (editable, not a Grafana recommendation); measure loki_ingester_chunk_stored_bytes_total ÷ loki_distributor_bytes_received_total. The cluster-wide WAL is a low-confidence rough planning estimate scaled linearly from the single point Grafana publishes (one ingester, about 5 MB/s, about 5,000 series, about 10–15 GB of WAL), with replication applied to intake; it is not a required disk size. Compute is shown as the Grafana reference profile for the matching ingestion tier, not computed for your workload; query workloads can need much more. Confidence: medium for object storage, low for the WAL scaling.

OpenSearch

Amazon OpenSearch Service follows the AWS storage-sizing formula with a 1.1 index factor, 5% Linux reserved space and 20% service overhead (capped at 20 GiB per instance, so without node sizing the result can overestimate). Self-managed OpenSearch is hot-only and uses an aggregate planning utilization target based on the default 85% low watermark. Shard guidance is 10–50 GB per shard (AWS: 10–30 GiB for search, 30–50 GiB for log analytics). The per-node shard limit is 1,000 by default for self-managed OpenSearch (configurable) and, on Amazon OpenSearch Service, 1,000 up to 2.15 and heap-based from 2.17 (1,000 per 16 GiB of heap, max 4,000); without engine version and heap, no data-node estimate is shown. Not modeled: node counts from capacity, instance types, IOPS.

Events per second

EPS × average event bytes × 86,400 seconds = bytes per day, shown as decimal GB/day (1 GB = 10⁹ bytes). Average event size must be measured on your real events.

Verification

• Documentation. Each sourced assumption links to the vendor page and documentation version it was checked against. Pages show the month they were last reviewed; the date changes only when the content is reviewed again.
• Formulas. Automated tests reproduce documented examples — Splunk's 100 GB at RF3/SF2 gives 45 GB rawdata + 70 GB index files = 115 GB — and lock invariants such as SF never exceeding RF, no replicas on searchable snapshots and frozen data never counted as a full local copy.
• Examples. Every figure in worked examples, reference scenarios and guides is generated by the calculation engines and re-computed by tests. If a formula changes, the tests fail until the published content is updated.

What ObservKit does not claim

ObservKit is an independent project. It is not affiliated with, endorsed by or certified by Splunk LLC, Elasticsearch B.V., the Cloud Native Computing Foundation or any other vendor, and its results are not official vendor sizing. Infrastructure counts, such as the Splunk indexer estimate, are planning heuristics. Search concurrency, node sizing, hardware profiles and premium apps are outside the models.

Changelog

1. October 2026 — Platform comparison and EPS helper

   New platform comparison: one daily ingest, retention and growth through the Splunk, Elasticsearch, Grafana Loki and OpenSearch models, each with exactly the defaults its own calculator applies to an imported scenario, so opening a card shows the same figure. An optional monthly cost multiplies each headline quantity by a price per GB-month that you enter; ObservKit ships no prices. The four platform calculators can now convert events per second to GB/day in place with the same formula as Log Storage. No sizing formula changed.

2. October 2026 — Grafana Loki and OpenSearch models, EPS input

   Two calculators were added. Grafana Loki: object storage = daily ingest × stored ÷ received × retention, one copy, plus growth; the replication factor affects ingesters and the WAL only; the WAL is scaled linearly from one documented Grafana test; compute is Grafana’s published reference profile per ingestion tier and is never added to storage. OpenSearch: Amazon OpenSearch Service uses source × (1 + replicas) × index factor ÷ 0.95 ÷ 0.80, with UltraWarm and cold storage as primary-only data in S3; self-managed OpenSearch divides stored size by a planning disk utilization target (default 85%). Log Storage gained an events-per-second input (EPS × average event bytes × 86,400 = bytes/day) and can continue into four platforms, transferring only daily ingest, retention and growth. Elasticsearch and OpenSearch gained a shared shard planner (10–50 GB rule of thumb; 1,000 shards per data node default for Elasticsearch). Existing models are unchanged.

3. October 2026 — Reference content and guides

   Splunk, Elasticsearch and Log Storage pages gained worked examples, reference scenarios, sizing decisions, common mistakes and visible sources. Three guides and this methodology page were added. Every figure on these pages is generated by the calculation engines and verified by tests.

4. October 2026 — Capacity Planning hub and Log Storage hand-off

   Log Storage can continue into Splunk or Elasticsearch, transferring only daily ingest, retention and growth. Replication is not transferred because Splunk uses RF/SF and Elasticsearch uses replicas per tier. Imported Elasticsearch retention starts as 7 hot, 23 warm and the rest cold, as a starting point to review.

5. October 2026 — Splunk storage model corrected

   Before: indexed = pre-indexed volume × 0.5, then × RF for every copy. After: rawdata = P × 0.15 × RF plus index files = P × 0.35 × SF, following Splunk's indexer-cluster documentation: non-searchable copies hold rawdata only. Impact at RF3/SF2: 1.15× instead of 1.50× the pre-indexed volume. The corrected result is 23.3% lower than the previous one; put the other way, the previous model was 30.4% higher than the corrected one. At RF = SF both models give the same result. SmartStore mode was added at the same time (local cache + replicated hot buckets; one remote copy of warm buckets).

6. October 2026 — Elasticsearch tier model corrected

   Before: every tier, including frozen, stored the full dataset × (1 + replicas), with no disk headroom. After: replicas apply to regular indices only; fully mounted cold keeps one local copy; frozen keeps a cache locally and the full dataset in the snapshot repository; an index/raw factor input was added; provisioned disk divides usable data by a planning utilization target.

7. October 2026 — Planning utilization wording

   The input previously called a disk watermark was renamed "Planning disk utilization target" (85%), because it is an aggregate planning assumption and not the per-node watermark allocator, which also applies a 200 GB max-headroom cap.

8. September 2026 — Splunk and Elasticsearch calculators published

   First versions of the Splunk Sizing & Storage Calculator and the Elasticsearch Sizing Calculator.

Last reviewed: October 2026