It may not be obvious what they mean so this documentation is to help understand what they represent.

There are some key ideas to keep in mind.  The first is what the “#” symbol means in this context.  You can read it as “Number of”.

• “for each granularity Size” means if it’s daily then it’s per day, Monthly is per month, Weekly is Per week

• Some of the measures use each other to calculate their values.  This is mostly true for the Normalized ones

• Viewing any Measure with the word ‘Normalized' will be incorrect unless you also change the Category to Normalized Machine Series

Measures

• # Asset Hours

  • This counts the number of Hours that assets ran.  We used the consumed quantity line to count this value

• # Assets

  • This means the Number of Unique assets.  We consider assets unique by their instance ID.  For each Unique Instance ID we see we will count it as 1 even if the Asset was only active for 1 hour

• # Assets by Usage

  • This counts machines based on their usage.  If a machine was used for each granularity Size it counts as 1.  If it was used for 12 hours it would count as 0.5

• # Reservations

  • This is similar to # Assets but only counts Reservation line items.  All other line items are reported as having a count of 0.  This also counts reservations uniquely and reports each one as a count of 1 regardless of how much was used.  Keep in mind a reservation needs to have some usage for us to see it.  A 0% utilized reservation will not get counted since it does not appear in the bill.

• # Utilized Reservations

  • This counts Reservations based on their usage hours.  For each granularity Size we report the number 1.  So if a reservation was used for 12 hours on a day it would count as 0.5 Reservations.

• # VM Hours

  • This counts the number of VM Hours we see in the bill.  If the VM is reserved by a reservation then we scale it based on it’s NF Factor

• # VMs

  • Counts Unique VMs by name for each granularity Size.  If a machine only runs for half the period then it will still count as 1

• # VMs by Usage

  • This Counts VMs based usage for each granularity Size.  In Daily for example if a VM ran for 12 hours we would report it as 0.5.  If it runs all Day then it would count as 1

• Applications Cost

  • The cost of line items that match the Application Criteria.  Such as MySQL, Windows License etc.

• Compute Cost

  • The Cost of the line item when it is considered ‘Compute’ Pretty much anything with Microsoft.Compute.  Reserved VMs will have a cost of 0.0

• Compute Cost before RI

  • Similar to Compute Cost but takes any reserved VMs and calculated what their cost would have been if it was On Demand.  This can be thought of as ‘Money we avoided Spending’

  • This uses the EA Price sheet for EA Quota Machines. Otherwise it uses the “Hourly Cost” Value linked to the VM

• Network Cost

  • Cost that matches the Network Criteria.  Such as IP Addresses or Data Transfer

• Normalized Reservation Surplus

  • This treats the Normalized VMs Number as Negative and the Normalized Reservations as positive.  When viewed in the report they sum together.  So the value we see is any Excess Reservation amount. It will be Negative if there is more VM usage than Reserved

• Normalized Reservations

  • This uses the # Reservations and multiplies it by the NF Ratio of the Reservation

• Normalized Underutilized Reservations

  • This takes the Normalized Reservations and the Normalized Utilized Reservations and subtracts them.

• Normalized Utilized Reservations

  • This takes the Resource Quantity value of a reserved Line item and multiplies it by the NF Ratio

• Normalized VMs

  • Uses the # VMs by Usage value and multiplies it by the NF Ratio of the machine.

• Total Cost ($)

  • The total Cost

Detailed Explanation of Compute Cost vs Compute Cost Before RI’s:

ALGORITHM FOR THE MEASURES:

• Compute Cost: The above vm_compute_line_items.csv file has all the line items pertaining to a Virtual machine that is a Compute Cost.  Note that the above file was generated from the raw EA bill collected from Microsoft for CloudHealth.  The way we determine whats a compute cost is by looking at the consumed_service column (sometimes also shows up as ConsumedService for different types of bills).  We look for values for all line items in this column and the value must be equal to Microsoft.Compute.  After this we just look at extended cost column and just display whatever the cost Microsoft reported in the bill.  As mentioned above, Reserved VM’s have a cost of zero reported by Microsoft.  Reserved Vm’s are determined by looking at the additional_info column in the bill and the additional_info column must have reservationId and reservationOrderedId in it so as to be able for us to say that a reservation was applied to the VM.  CloudHealth does not do any manipulations here.  This is the pattern that Microsoft follows for all their bills.
  
  

• Compute Cost Before RI’s: The input for this measure is the same as the above file.  The compute cost before RI’s for non reserved VM’s are calculated the same way as the above measure.  The only distinction here is that we do calculation for Reserved VM’s since they show up as zero cost in the bill.  This is done so as to show the customer as to how much money they would have spent if they did not purchase a reservation for those VM’s or in the azure world we call this as Pay-As-You-Go or in the aws world we call this as On-Demand Pricing.  To calculate this pricing, we first find the VM name by looking at the component column in the digest (In different raw bills, this column name is different.  The names are as follows for different bill types EA bills: InstanceID, MCA Bill: ResourceId, PC Bills: ResourceUri).  From the VMname, we figure out the subscription associated with it.  If we couldn’t find a subscription with the associated VM name we set the price to be 0. If there is a valid subscription, we then try to figure out what quota type the subscription has.  If the subscription is of quota type EnterpriseAgreement then we calculate the the hourly_cost of the vm from EA Price sheets collected from this API here Azure Billing Enterprise APIs - PriceSheet.  If we couldn’t find the price from here or if the quota type was something other than EA(Usually this is the Pay-as-you-go case), we basically calculate the hourly cost of the VM by looking at the cost column in the bill and divide it by resource_quantity column and then map the VM to the meter_guid column value of the line item and then apply the same hourly cost to the line items with the same meter_guid values.