Reports and the monthly summary¶

New in the next release

This is on the dev and qa builds now, and in the next release.

In the inventory reports¶

Each inventory keeps capacity planning as it was that day, so a report from any day shows the forecast then, never today's. An old report is a record of what was known when.

The downloads (Excel, CSV and HTML) get these sheets:

Sheet	One row per	Columns
Capacity	Resource of each cluster, host, datastore, pool, backup store or volume	Source, Kind, Name, Parent, Resource, Unit, Used, Usable, Capacity, Use %, Threshold %, Forecast (status), Reaches on, Earliest, Latest, Days, Trend % a month, History days, From inventory days, Note
Reclaim	Suggestion	Suggestion, Source, VM, VM ID, Cluster, Days, vCPU back, Memory GiB back, Disk GiB back, Suggested size, Why, Datastore, File
Storage growth	Datastore	Source, Datastore, Days, Grew GiB, From existing VMs GiB, From new VMs GiB, Grew most, Snapshots, Oldest snapshot days
Orphaned disks	Disk file no VM uses	Source, Datastore, File, Size GiB, Last written, Why, VM, VM ID
Host NICs	Host port	Source, Host, NIC, Kind, MAC, Speed Mb/s, Link, Driver, Members, Address

The Capacity, Reclaim and Storage growth sheets aren't compared between inventories: a forecast moves every day, and a Changes sheet full of it would hide what someone changed. Orphaned disks and Host NICs are compared, so a new orphan or a NIC that changed speed shows on Changes.

Units: amounts are cores for CPU rows and GiB for the rest; percentages are 0–100.

In the reporting database¶

With the reporting database, each sheet is a table of the same name, led by run_id and taken, with a latest_ view for the newest inventory:

Table	View
`capacity`	`latest_capacity`
`reclaim`	`latest_reclaim`
`storage_growth`	`latest_storage_growth`
`orphaned_disks`	`latest_orphaned_disks`
`host_nics`	`latest_host_nics`

A Grafana panel of runway over time:

SELECT taken AS time, name, days
FROM ferrule.capacity
WHERE resource = 'disk' AND forecast = 'ok'
ORDER BY taken;

Columns added in a later release are added to existing tables automatically. The database is optional: the Capacity tab, the downloads and the summary all work without it.

The monthly summary¶

One page for a manager or a client, covering a month:

Shortest runways: what fills first, when, and in how many days.
What to buy: for each cluster within six months of its threshold, how many hosts (up to four) it takes to get past six months, and the new date. It plans in hosts like the cluster's largest, or in the host you describe on Settings. A cluster that four such hosts can't carry past six months says so.
What could be reclaimed: the top suggestions, and what they give back.
Where storage grew: each datastore's growth, and what drove it.
Runway alerts this month: what warned or went critical, and when.

A month that has ended is told from the inventory taken nearest its last day, so it shows capacity as it was then. The month in progress uses the live figures. Each page says which.

It's a single, self-contained HTML page: no scripts, no images to fetch, so it opens in any browser and survives being forwarded. Every value on it is escaped.

Getting it¶

How
This month so far	On the Capacity tab, opens in a new tab
Last month	The same, for the month just ended
Download	Saves last month's as `ferrule-capacity-YYYY-MM.html`
Email, on the 1st	Automatically, from 07:00 local time, covering the month just ended
Email last month's now	Settings → Capacity planning → Monthly summary (admins)

Email¶

It goes to its own address list, not the alert email list (SMTP_TO): set it on Settings, or CAPACITY_SUMMARY_TO.
It goes through the same mail server alert email uses: SMTP_HOST, SMTP_FROM, and SMTP_PORT, SMTP_TLS, SMTP_USERNAME, SMTP_PASSWORD as needed. See Alerts.
It's sent as HTML with a plain-text part, for mail clients that won't show HTML.
It carries a Prepared by name if you set one (CAPACITY_SUMMARY_BY).
It's sent once a month. Ferrule remembers which month it last sent, across restarts, and retries hourly through the 1st until it gets through.
The Capacity tab says whether it's emailed, to whom, when it was last sent, and, if not, why: no mail server, no address, or the last attempt's error.

The summary is paid, like the rest of capacity planning, and needs no database.

For an MSP, one summary per client site comes with the hub (remote collectors). Until then, each install sends its own.