What an on-premise monitoring server actually stores (and how to size the disk)

#database #infrastructure #monitoring

Every on-premise monitoring pitch ends with the same question from IT: "fine, but how much disk?" The honest answer is a formula, not a number. Here is what actually lands on the server and how to estimate it.

What gets stored

A typical deployment writes five kinds of rows:

Table	One row per	Typical size
`sessions`	login / logout / idle transition	~200 bytes
`app_usage`	app or site, aggregated per interval	~150 bytes
`file_events`	copy, move, delete, print, USB write	~400 bytes + path
`screenshots`	one captured frame	150–400 KB
`audit_log`	who viewed which recording	~200 bytes

The first three are metadata. The fourth is the only thing that grows fast.

The sizing formula

disk ≈ endpoints × captures/day × avg_capture_size × retention_days
     + endpoints × metadata_per_endpoint_per_year × years

A concrete case — 200 endpoints, one capture every 10 minutes (≈48/day), 250 KB average, 30 days:

200 × 48 × 250 KB × 30 ≈ 72 GB

Metadata for the same fleet is a rounding error by comparison: tens of GB per year, not hundreds.

Video changes the order of magnitude

Screen recording, if you enable it, costs 20–60× the equivalent duration in screenshots depending on resolution and codec. Two consequences:

Enable recording per-group, not per-tenant. Most organisations need it for a handful of regulated roles.
Cap recording duration in the policy, not in the storage layer. Disk-full is a much worse failure than "recording stopped at the limit".

Retention must be enforced by the system

A retention policy in a PDF is not retention. The database needs a scheduled delete with three properties:

Per-table windows — screenshots expire faster than file events, which expire faster than payroll-relevant time records.
Legal hold override — one flag on a case that suspends deletion for exactly those records, with an owner and an end date.
A dry-run mode — so you can see what would be deleted before turning it on.

-- pseudocode for the nightly job
DELETE FROM screenshots
WHERE captured_at < now() - interval '30 days'
  AND thread_id NOT IN (SELECT id FROM legal_holds WHERE released_at IS NULL);

Run it with LIMIT batches during business hours, and log the count. The log is what proves the policy is real.

Backups are the hidden doubling

The estimate above is live data. Backups typically double it, and a second copy off-site doubles it again. If the number you quoted to management was 72 GB, the actual infrastructure number is closer to 150–200 GB once retention snapshots exist.

Network is rarely the bottleneck

Agents that only send metadata use almost nothing. Screenshots are compressed and sent on intervals. The real spike happens when an administrator opens a playback session — that is a burst of image reads, not sustained WAN traffic.

Two things worth deciding early

Where does the database live? On the same box as the screenshot store, you get one failure domain and one restore procedure. Separate them and you get scale, plus two things to back up.
What is the growth assumption? Sizing for today's endpoint count is the classic mistake; size for the fleet you expect when the licence renewal comes around.

This is the model iMonitor EAM ships with: server and database on your own hardware, keystroke counts rather than content, per-module retention, and a 15-day trial that is enough to measure your own capture rate before committing to disk. More at imonitorsoft.com.

DEV Community