Parascope Docs

How cost is calculated

How Parascope turns asset prices, rate cards and bills into per-CI cost, and what the Cost Explorer totals mean

Parascope prices your infrastructure from the cost sources you connect, then moves that cost along the dependency graph to the workloads that use it. A hypervisor's purchase price ends up shared by the VMs running on it; a licence on one VM stays with that VM. This page explains how that works, what the Cost Explorer's two totals mean, and what happens when a source has no exchange rate or stops reporting.

A worked example

Hypervisor H costs 1,000 a month (a rate card). VMs A and B run on H and use 60% and 40% of it. A also carries a licence at 50 a month (another rate card).

CISeededInheritedLoadedDistributedRetained
H1,00001,0001,0000
A506006500650
B04004000400
Total1,0502,050 (do not add)1,050

The estate costs 1,050 a month, and both the seeded and the retained columns add up to that. The loaded column does not: H's 1,000 appears once on H and again inside A and B, so adding loaded cost across CIs counts the hypervisor twice.

The terms

  • Seed: money entering the model at one CI from an outside source, such as a Snipe-IT purchase price, a rate card or a bill. A CI's seeded cost is the sum of its own seeds.
  • Pool: a CI that passes cost on to the CIs that consume it, such as a hypervisor, a Kubernetes node or a Ceph cluster. Inherited cost is what a CI receives from the pools it runs on.
  • Loaded cost is seeded plus inherited: what a CI costs with its share of the platform underneath it. Each CI's Cost tab shows it.
  • Distributed cost is what a pool passes on to its consumers. Retained cost is loaded minus distributed: the cost that stops at that CI.
  • Idle capacity is the part of a pool its consumers do not use. Parascope passes idle cost on to the consumers in proportion to what they use, so it does not pile up unseen at the pool.
  • Stranded cost sits at a pool that has no consumers, so the pool retains it. The Quality tab lists stranded cost, which is a quick way to find hardware nobody is using.

Each unit of cost is retained by exactly one CI. That is the conservation rule: total seeded equals total retained, which equals attributed plus stranded. Each recalculation checks it and records the result on the Quality tab.

Spend at source and Consumed by

The measure is which per-CI amount a total adds up: seeded or retained. The Cost Explorer offers both. A toggle above the treemap, table and trends switches between them, and the metrics sidebar follows the explorer's measure. On the Trends tab, grouping the chart by Cost Origin locks the toggle to Spend at source, and the headline and sidebar then read Spend at source too.

  • Spend at source adds up seeded cost. Each amount counts where it enters: at the asset, rate card or bill that priced it. In the example, H shows 1,000 and A shows 50.
  • Consumed by adds up retained cost. Each amount counts where it stops after flowing down to the workloads. In the example, A shows 650 and B shows 400. It includes stranded cost, so capacity nobody consumes still shows up, at the pool that holds it.

With no filters, and for a user whose access covers the whole estate, both give the same total. In your base currency it matches the Seeded figure on the Quality tab. Filters make the two differ, and that difference is the useful part. Filtered to the virtual tier, the example shows 50 under Spend at source (A's licence) and 1,050 under Consumed by (what the VMs consume, hypervisor included).

Each grouping has a default:

GroupingDefault
Cost OriginSpend at source (the only option)
LocationSpend at source
Infrastructure (Source on the Trends tab), Tier, CI Type, and no groupingConsumed by

A grouping uses its default until you pick a measure with the toggle. After that, your choice carries over when you change the grouping. Cost Origin is the exception: it always shows Spend at source, and your choice comes back when you move to another grouping. Drilling into a treemap tile keeps the measure the tile was summed under, which can differ from the level below it. Going back up, or choosing another grouping, returns the measure to what it was before the drill.

Cost Origin splits spend at source into Capex (Snipe-IT purchases and capital rate cards) and Opex (recurring rate cards, OpenStack prices and bills, and AWS spend). A CI with both a capital and a recurring seed contributes to both. Retained cost has already mixed sources together on its way down the graph, so it has no origin to split by, and the toggle is disabled for this grouping.

Loaded cost is not offered as a total, for the reason in the example. The Cost Explorer's CSV export, which needs the cost:export permission, carries seeded, loaded and retained cost for each CI if you want to do your own arithmetic. Its Seeded Cost, Loaded Cost and Retained Cost columns sit between Tier and Allocated Cost, so a script that reads the export by column position needs updating. Allocated Cost is the earlier name for loaded cost and is deprecated.

Where seeds come from

SourceComponentNotes
Snipe-IT hardware purchase costCapitalAmortised monthly, see Amortisation
Capital rate cardCapitalAmount divided by its amortisation months
Recurring rate cardRecurringMonthly, or a yearly amount divided by 12
OpenStack list priceRecurringThe price table the OpenStack collector uses when no billing data exists
OpenStack billing (Distil)BilledBilled spend per instance
AWS Cost ExplorerBilledEC2 instance spend, see AWS cost enrichment

The component says what kind of cost a seed is: capital is buying the asset, recurring is running it, and billed is observed spend, which covers both.

When several sources price the same thing

Precedence is decided per component, on which seeds are present:

  1. A bill beats estimates. When a CI has billed spend, its override rate cards and its OpenStack list price stop counting, and so does a Snipe-IT purchase placed on that CI.
  2. Snipe-IT beats a capital rate card. When a machine has a Snipe-IT purchase cost, capital override cards on any record of that machine stop counting (see Identity groups).
  3. A recurring rate card beats the OpenStack list price.
  4. Capital and recurring stack. A server's purchase price and its colocation fee both count.
  5. The most specific rate card wins. When several override cards of the same kind match one CI, the card with the highest specificity applies: a card that selects the CI by ID beats one that selects by tag, which beats one that selects by CI type. Ties go to the card with more selector conditions, then the later start date, then the card created more recently. Editing a card's name or description does not change which card wins.
  6. Additive cards stack. A card set to add on top counts in addition to whatever else applies in its component, billed spend included. Use it for cost that sits on top of the asset, such as a platform subscription. To make a card additive, turn on Add on top of other sources under Stacking in the rate card dialog; cards are override cards by default.

A seed that loses is superseded. It does not disappear quietly: the Quality tab lists each supersession, grouped by rule, with a count and sample CIs. When you save an override card that matches some of the same CIs as other cards of its kind, the rate card dialog lists those cards and how many CIs each shares, and the Quality tab lists the overlap after the next recalculation.

A winning seed that cannot be used is not replaced by the next one down. If the winning card has no exchange rate, or the winning AWS figure is stale, that component counts 0 for the CI and the totals carry a warning. The number stays honest and the warning explains the gap.

Identity groups

One physical machine often appears several times: as a Snipe-IT asset, a NetBox device, a Proxmox node and a Ceph host. Parascope links these records through correlation and treats the linked hardware records as one identity group, so a purchase price is counted once per machine.

Identity groups are bounded to hardware records: NetBox devices, Proxmox nodes, Ceph hosts, VMware hosts, OpenStack hypervisors and bare-metal (Ironic) nodes, and Snipe-IT hardware. A group does not pass through VMs, operating systems, applications or databases, so a correlation made on a shared IP address cannot chain unrelated machines together.

  • Placement. A Snipe-IT asset's amortised cost lands on one CI: a pool in its group when there is one (for example the Proxmox node, so the cost reaches the VMs running on it), otherwise the most physical record. It can also land on a CI correlated directly with the asset, such as a bare-metal Kubernetes node. A CI holds at most one priced asset. An asset with no free CI is reported as unplaced: its cost is left out of the totals, and the Quality tab shows the amount left out.
  • Large or ambiguous groups. A group larger than the configured limit (8 records by default), or one holding more than one priced Snipe-IT asset, is not used as a group. Each asset then considers only the records correlated directly with it, and the Quality tab says why.
  • Rate cards across a group. Recurring override cards on different records of one machine each count, and the Quality tab flags the overlap so you can remove the duplicate.

Amortisation

  • Snipe-IT: the purchase cost divided by the asset's depreciation months, charged from the purchase date for that many calendar months. Assets without a depreciation schedule use the default depreciation period, 36 months unless your deployment sets another. After that the asset charges 0, but it still counts as present, so a capital rate card on the same machine stays superseded. An asset with a purchase cost but no usable purchase date is amortised with no end date and flagged on the Quality tab.
  • Capital rate card: the amount divided by its amortisation months, charged from the card's start date until the amortisation runs out or the card's end date arrives, whichever comes first.

Rate card dates

A rate card applies from its start date, which is included, up to its end date, which is not. A card that ends on 1 July applies through 30 June. Date boundaries take effect at the first recalculation after midnight UTC.

When a card selects CIs by ID, paste one CI UUID per line. Parascope rewrites each ID in the standard lower-case form it matches on, so an ID copied with capitals, braces or without hyphens still matches; a line that is not a UUID is refused when you save.

Currencies

Your tenant keeps its cost ledger in one base currency, shown with the totals on the Quality tab. Seeds in other currencies are converted at the European Central Bank reference rate, which Parascope fetches once a day. A rate more than 7 days older than the recalculation is not used.

A seed with no usable rate is unpriced: it is left out of the totals rather than added in the wrong currency. The Quality tab lists unpriced seeds, and the Cost Explorer shows a badge such as "Some costs are unpriced: missing EUR rate" that opens the Quality tab. The seed counts again at the first recalculation after a rate arrives.

Snipe-IT does not record which currency a purchase cost is in, so Parascope treats Snipe-IT costs as already being in your base currency. If your Snipe-IT records use another currency, convert them there, or price that hardware with capital rate cards instead.

Changing the base currency rewrites the cost ledger, so it is an operator action: contact support if you need it.

External cost data

AWS Cost Explorer spend is fetched once a day and kept apart from Parascope's own calculations. It expires by evidence:

  • An instance that no longer appears in a finished fetch for its credential drops out at the next recalculation.
  • If no fetch with a credential has succeeded for 72 hours, Parascope stops counting the AWS spend fetched with it and marks the totals as source incomplete. The Quality tab names the credential (role ARN or access key ID) and the reason, and the Cost Explorer shows an "AWS cost data unavailable" badge that opens it.

See AWS cost enrichment for setup and the services covered.

The Quality tab

The Cost Explorer's Quality tab shows the conservation check from the latest recalculation (seeded, attributed and stranded totals, in your base currency) and lists what the totals leave out or had to choose between:

  • Unpriced seeds, with the source, component and monthly amount of each. A recalculation records up to 500 of them.
  • AWS cost data incomplete: each AWS credential whose spend is excluded, and why.
  • Stranded cost, by pool.
  • Seed precedence and overlaps: superseded seeds grouped by rule, largest group first. The tab shows up to 50 groups, and when there are more it gives the total number of groups.

A user whose data scope covers part of the estate sees a reduced tab: the unpriced seeds and stranded cost of the CIs within that scope. The conservation totals, the AWS section and the precedence groups describe the whole estate, so that user does not see them. When the totals carry a warning that may come from CIs outside the scope, the tab says "Some affected costs may be outside your access."

Who can see cost

Cost is gated on the cost:read permission. Without it, the Cost Explorer cannot load cost data, cost fields on a CI read blank, and the CI's Cost tab is hidden. Cost columns elsewhere need the same permission:

  • a ParaQL query or natural-language question that names a cost column is refused;
  • a filter on cost in the CI list is refused, and a sort on cost falls back to the default order;
  • a change-history filter on cost is refused;
  • a new or changed tagging-rule condition that names a cost column cannot be saved.

The Cost Explorer's CSV export needs cost:export, which includes cost:read. The CI list's CSV export has no cost columns. Attribute-value discovery does not list cost columns for anyone.

A tagging rule whose condition names a cost column records who saved that condition, its condition author, and runs only while the author holds cost:read. If the author loses the permission, or the rule was saved with a personal token that has since expired, each run of the rule fails. Rules saved before Parascope recorded condition authors have no author, so their cost conditions fail the same way. After three failed runs in a row, Parascope turns the rule off and marks it Failed in the rules list, with the error on hover. The tags it already applied stay in place.

To bring the rule back, someone who holds cost:read opens it in the rule editor and chooses Save Changes, which makes them the condition author, then turns the rule back on. Saving the rule without cost:read leaves the author as it was.

A correlation rule whose match or booster path names a cost column also records an author: whoever last saved its conditions while holding cost:read. It runs only while that author holds cost:read. If the author loses the permission, the rule was saved with a personal token that has since expired, or the rule was saved before Parascope recorded authors, each run of the rule, dry runs included, is skipped with the reason shown and matches nothing. The rule stays on and is never marked Failed. To bring it back, someone who holds cost:read opens it in the rule editor and chooses Update Rule, which makes them the author. Saving the rule without cost:read leaves the author as it was.

A signed-in user who can read configuration items can also read cost. For API keys and how permissions are granted, see Access Control and Authentication and RBAC Administration.

How often cost is recalculated

Parascope recalculates cost a few minutes after a rate card, a class split or the exchange rates change, and at least once per UTC day otherwise. New CIs and relationships are therefore priced within about a day. Trend snapshots are taken daily.

Trend history

Trend snapshots recorded before Parascope started keeping seeded and retained cost have no value for either measure. The Trends chart leaves those points blank and places a "Methodology changed" marker at the first point on or after the change.

Other terms

  • Seed family: where a seed comes from, one row of the table in Where seeds come from.
  • Solver edge and flow: Parascope moves cost along links derived from your relationships, from each pool to the CIs consuming it. One amount moving along one link is a flow.
  • Class split: a pool's cost divided by resource class (compute, storage, network) before it flows, so a VM that uses storage but little compute pays for what it uses. Configure class splits on the Cost Configuration settings page.
  • Rate-incomplete and source-incomplete: the two warnings a total can carry, for unpriced seeds and for stale or unavailable AWS data.
  • Scope and scope watermark: an AWS credential (role ARN or access key), and the time of its last successful fetch. A scope with no success for 72 hours is stale.
  • Epoch: the date the cost method changed in your trend history.

Known limits

  • A CI with billed spend still receives cost from the pools it runs on. An OpenStack instance billed through Distil that also runs on a hypervisor you price with a rate card carries both its bill and a share of the hypervisor. Price that capacity one way.
  • Snipe-IT costs are assumed to be in your base currency (see Currencies).
  • AWS cost covers EC2 instances. Spend on other AWS services is not collected.