This monitor reports what a SAP BTP global account is charged, for every subaccount, service,
plan and measure.
It reads the monthlySubaccountsCost API of the SAP Usage Data Management service and reports
the total cost together with the two sources it is made of, pay as you go and cloud credits.
It raises alarms when a cost crosses a budget, when it rises sharply from one month to the next,
and when something that was being charged stops appearing.

Note: this API only serves global accounts on the CPEA or BTPEA consumption based commercial model. A subscription based account receives an empty result, not an error. Confirm the commercial model of the client before deploying this monitor. See Commercial model.

• An instance of the Usage Data Management service on plan reporting-ga-admin, with a service key.
• A Web Service connector configured against that service key.

Note: this is the same connector as BTP Global Usage and BTP Subaccount Usage. If one of those monitors is already set up for the global account, nothing else needs to be provisioned. See the BTP Global Usage page for the connector configuration.

Note: it is not the connector of BTP Directory Usage. A directory service key answers 403 on this API.

• On a CPEA or BTPEA global account the API returns one row per subaccount, service, plan and measure, with the cost of each.
• On a subscription global account it returns an empty result with no error.

Note: an empty result is reported as information and the run finishes successfully. It is not an error, because for a subscription client it is the correct and permanent answer.

Note: this is the trap to avoid. Deployed against a subscription client the monitor reports no cost for ever, which looks like “nothing is being spent” rather than “this monitor cannot work here”. If no cost is ever reported, check the commercial model of the global account before looking for a fault.

• A single call per run returns every subaccount, service, plan and measure of the global account. Adding a line to the surveillance table costs no additional call.
• A budget is set per line, so a line narrowed to one subaccount and one service sets the budget of that service alone, not of the whole account.

• Defines how many months before the current one are collected. Default is 2.
• Keep it at 2 or more. The increase alarm compares the last two months that have ended, and with 0 there are none.

Note: the current month is never compared. It is still filling, and SAP restates its figures until the month is billed.

• A month that SAP has not billed yet is provisional. Its rows carry the estimated tag set to true, and the cost alarm says “not billed yet”.
• The figures of such a month change from one run to the next, upwards as the month fills and sometimes downwards when SAP corrects them.

Note: once a month is billed, its rows switch to estimated false. In a monitoring tool this starts a new series for that month, because the tag is part of the series identity. This is intended: a billed figure and a provisional one are not the same measurement.

Note: the cost threshold is a budget in the account's currency, not a percentage. Set it per service rather than on a line matching everything, otherwise the largest service decides when the alarm fires.

Note: no increase is computed when the previous month cost nothing, since a percentage of zero has no meaning. A service charged for the first time therefore raises no increase alarm, only a cost alarm if it passes its budget.

Note: when several lines match the same subaccount, service, plan and measure, one alarm is raised, at the highest severity any of those lines asks for.

Note: the monitor remembers the last month each subaccount and service was charged, so the no data warning is still raised once something has disappeared from the collected range. A series silent for 12 months is forgotten and its alarm clears. An empty result never raises these warnings.

• Cost: the amount and currency, the service, plan and measure, the breached budget, the subaccount and the month. The message ends with “not billed yet” while the month is still provisional.
• Increase: the increase in percent, the two amounts compared, the service, plan and measure, the subaccount and both months.
• No data (WARNING): the service, plan and measure, the last month charged, the number of months of silence and the allowed delay.
• Alarms are stable across runs: the same series updates its alarm rather than raising a new one.

Effect: Publishes the cost of every subaccount, service, plan and measure as metrics, and raises no alarm. This is the line to start with, so the normal spend of an account can be observed before choosing any budget.

Effect: Sends a WARNING when any single service of the production subaccount passes 500 in the account's currency this month, and a MAJOR past 1000.

Effect: Watches for cost that runs away rather than for a fixed budget. Sends a WARNING when a service costs half as much again as the previous month, a MAJOR when it triples, and a WARNING when a service that was being charged stops appearing for more than two months.

Note: three metrics are sent for each one, as promonitor.btp.cost.<measure>, promonitor.btp.cost_payg.<measure> and promonitor.btp.cost_credits.<measure>. The first is the total, the other two are the parts paid from pay as you go and from cloud credits.

Note: the total is the sum of the two others. They are three separate metrics rather than one metric with a source target precisely so that a dashboard cannot add them together and count the same spend twice.

Note: the value is a cumulative month to date figure and must be read as a gauge, like the usage metrics. A dashboard that aggregates the series as a sum multiplies it by the number of runs in the month.