Infrastructure estimates
How much space do 30 days of logs need?
Tools to use
A log volume is filling up and you need a thirty-day estimate. 'Each line is short' ignores growth in event count, while using only uncompressed volume can overstate some storage needs. Separate event count, bytes per event, retention days, compressed-size ratio, and total stored copies.
Start with 100,000 events per day at 500 bytes each
events per day: 100000
bytes per event: 500
days: 30
compression ratio: 1
stored copies: 1These conditions produce 1,500,000,000 bytes: 50,000,000 per day for thirty days. That is 1.5 GB or about 1.397 GiB. Read the result's unit rather than treating a GiB figure as GB.
In this published configuration, 'events per interval' is evaluated per day. Convert a measurement of 100 events per second to 8,640,000 per day first. Entering only 100 would estimate one hundred events a day. Align measurement and input intervals before adjusting other factors.
A ratio of 0.5 assumes half the original size
Change the ratio to 0.5 for 750,000,000 bytes, or 0.25 for 375,000,000. This is compressed size divided by original size, not a percentage field where you enter 50. One means no reduction. A 25% reduction leaves a ratio of 0.75, not 0.25.
Compression depends on content and method. Repetitive records and records containing already compressed or encrypted data need not share a ratio. Without representative measurements, compare assumptions such as 1 and 0.5 rather than calling 0.5 measured. The tool does not upload logs to measure compression.
Use the total number of stored copies
At ratio 0.5, two total copies require 1,500,000,000 bytes. One primary plus one additional replica means two in this calculation. If a service's 'replicas=1' counts only the additional replica, copying that number directly would undercount total storage.
Decide whether the estimate includes backups or other regions. This multiplier assumes identical copies; destinations with different retention or compression are clearer as separate estimates. More copies alone do not prove a recoverable backup exists.
What does the 500-byte event include?
Include timestamps, levels, request IDs, JSON keys, and delimiters if they are stored. Visible characters are not UTF-8 bytes, especially with Japanese text or emoji. A short representative example in the character/byte counter helps reveal the difference.
One line is not always one event: stack traces span lines, and collectors may combine them. Match the event-count unit to the average-size unit. Dividing a sample's total bytes by its corresponding event count makes the averaging basis explicit.
Ninety days is triple only under the same daily model
At 100,000 events/day, 500 bytes/event, no compression, and one copy, ninety days requires 4,500,000,000 bytes. Tripling retention triples this steady model. If event volume grows, revisit the daily assumption; new features or logging levels can change event size too.
An incident-driven burst can make a long-term average inadequate for peak capacity. Compare normal and elevated scenarios, then check actual storage usage. The tool neither predicts peaks nor ingests historical logs for trend analysis.
Payload volume is not the whole search-system footprint
Indexes, metadata, working space, and filesystem headroom are not automatically included in this basic payload estimate. Products differ, so an invented universal multiplier is not a measurement. Use product documentation and representative measurements to estimate additions separately.
Retention expiry and physical reclamation need not happen simultaneously in every product. This steady-state model does not simulate deletion delays or transition spikes. Do not size a disk exactly to the result without identifying what the estimate includes and excludes.
Separate a daily average from an incident scenario
A hundred thousand events per day differs enormously from per second. Convert a rate to this screen's daily count: 100 per second sustained for 86,400 seconds is 8.64 million per day. Extending one peak second across the day assumes a sustained peak. Label average, busy-day and incident scenarios separately; the calculator does not turn an assumption into a measurement.
Incidents can change event size as well as frequency: a stack trace is larger than a short access entry. Doubling counts and doubling average bytes produces four times the data, unlike doubling counts alone. Record which assumptions changed. The screen does not persist a scenario history; retain the conditions deliberately if you need a comparison.
Retention should reflect what investigations need. Dropping essential fields may prevent reconstruction, while spare capacity does not justify retaining unnecessary secrets or bodies. The tool exposes the size consequences of chosen counts, bytes and days; it does not choose collection policy, access rights or retention obligations.