This monitor reports the resource consumption of individual SAP BTP subaccounts as a time series, by day, week or month.
It reads the subaccountUsage API of the SAP Usage Data Management service and reports, for every
service, plan and measure of a subaccount, how much of that resource was consumed in each period.
It raises alarms when usage crosses a limit, when it rises sharply from one period to the next,
and when a service that used to report usage stops appearing.
It covers usage only, in the units the platform meters, and works whatever commercial model
the global account is licensed under.

Note: only whole periods that have already ended are reported and compared. The current period is still filling, and the figures of some services lag by a few days. See Periods and the aggregation caveat.

• 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 the BTP Global Usage monitor. If that monitor is already set up for the global account, nothing else needs to be provisioned. See the BTP Global Usage page for the connector configuration.

• Use the surveillance table to choose the subaccounts, the period and the thresholds.
• Use the Load subaccounts… button above the table to pick subaccounts by name. It fills in their IDs.
• Lines that share the same subaccount, period and periods back share a single call to SAP. Adding a filter or threshold line on an existing subaccount costs nothing extra.

• Set Subaccount ID to * to monitor every subaccount of the global account. This is the default.
• The subaccounts are listed from the usage reported last month and this month, then collected one call each.
• A subaccount that also has its own line with the same period and periods back is collected once, not twice.

Note: a subaccount that has reported no usage at all last month or this month is not listed, so it is not collected. There is nothing to report for it.

Note: partial patterns such as abc* are not supported. SAP identifies subaccounts by ID only. Such a line is skipped with a warning.

Note: each subaccount costs one call per period per run. The calls are sent five at a time, so a global account with many subaccounts is collected in a fraction of the time a sequential run would take.

Note: no further subaccount call is started once 80% of the job timeout has passed. The run then reports what it collected instead of being killed and losing everything, and writes the warning Made X of Y subaccount calls. If that warning appears on every run, raise the timeout of the monitor or split the subaccounts over two jobs.

• Day, Week (Monday to Sunday) or Month (calendar month).
• Periods back is the number of whole periods before the current one that are collected. Default is 7. The range is limited to 89 days, 12 weeks or 8 months.
• Metrics and the usage threshold use the last whole period of each service. The increase alarm compares the last two whole periods.

Note: SAP does not add up usage the same way for every measure. A rate such as memory_per_hour reads the same for a full day, week or month (for example 0.24), and lower for a partial period. A stored volume reads the value of its last day. Summing daily figures to obtain a month is therefore wrong for many measures, and the monitor never does it. Every figure is used exactly as SAP reports it for the chosen period.

Note: some services report with a delay. On the reference account, Cloud Foundry reported the current day while Audit Log stopped two days back and skipped up to five days at a time. Keep Periods back large enough for the slowest service to have two whole periods in the range.

Note: always set a single Measure on a line that carries a Usage threshold. Measures do not share a unit: API calls, gigabytes and hours are all plain numbers.

Note: no increase is computed when the previous period had no usage, since a percentage of zero has no meaning.

Note: the no data delay is measured against the most recent data SAP returned for the subaccount, not against today, so a service that is simply late does not raise an alarm. Keep it above a few days: Audit Log skips several days while running normally. The monitor remembers the last date each service reported, so the warning is still raised when the service has disappeared from the collected range altogether. A service silent for 90 days is forgotten and its alarm clears.

Note: when a subaccount returns no usage at all, or has dropped out of the list used by *, there is no recent data to measure against and its remembered services are compared with today instead. A subaccount that stops reporting as a whole therefore raises its warnings like a single service that stops. A call that fails, or a list that could not be read, is never taken for silence.

• Usage: the usage value and unit, the service, plan and measure, the breached threshold, the subaccount and the period.
• Increase: the increase in percent, the two values compared, the service, plan and measure, the subaccount and both periods.
• No data (WARNING): the service, plan and measure, the last date reported, the number of days of silence and the allowed delay.
• Alarms are stable across runs and include the period, so the same service alarming on its daily and on its monthly figures raises two separate alarms.
• When several lines match the same service, plan and measure of one subaccount, one alarm is raised, at the highest severity any of those lines asks for. A broad line and a narrow line on the same service are two grades of one condition, not two alarms.

Effect: Publishes the daily usage of every service of every subaccount as metrics, and raises no alarm. This is the line to start with.

Effect: Compares the audit log volume of the last two whole months of one subaccount. Sends a WARNING alarm when it has doubled and a MAJOR alarm when it has grown six times.

Effect: Sends a MAJOR alarm for any subaccount whose Cloud Foundry memory averaged 4 GB or more over the last whole day, and a WARNING when Cloud Foundry has reported nothing for more than 3 days.

Note: the measure is part of the metric name, as promonitor.btp.subaccount_usage.<measure>. It differs from the BTP Global Usage metrics on purpose: those carry a month to date figure, these a figure per day, week or month, and the two must not be mixed in one series.

Note: the value of a period is published again on every run until the next period completes, so the series moves in steps. Read it as a gauge, never as a sum.

Note: the date of the period is not a target. A new value every day would start a new series every day in most monitoring tools.