This monitor reports resource consumption across a whole SAP BTP global account.
It reads the monthlyUsage API of the SAP Usage Data Management service and reports, for every
subaccount, service, plan and measure, how much of that resource has been consumed in the
current month.
It covers usage only, in the units the platform meters, and works whatever commercial model
the global account is licensed under.

Note: usage is reported cumulatively for the month, not consumed since the last run. A series therefore rises through the month and restarts on the 1st. The figures are not real time and lag actual consumption by some hours, which is why the default schedule is hourly.

• An instance of the Usage Data Management service on plan reporting-ga-admin, with a service key. The plan reports on the whole global account regardless of which subaccount or Cloud Foundry space hosts the instance, so no parameters are needed at creation time.
• A Web Service connector configured against that service key, see below.

Note: this is not the same connector as the one used by the BTP Application Stats and BTP Application Events monitors. Those authenticate against the Cloud Foundry API with a user name and password. This monitor authenticates against the reporting API with OAuth2 client credentials, and the two cannot share a connector.

All values come from the service key of the reporting-ga-admin instance.

Note: the /oauth/token path has to be typed on the end of the authentication server yourself. The client credentials flow posts to the address exactly as entered and appends nothing. Without the path the connector check fails on a response that is not a token.

Note: the client ID contains a | character and the client secret usually contains a $ and a trailing =. All of them are part of the value and must be copied whole.

Note: the availability end point cannot be left empty. The reporting API serves nothing at its root, so a check against the base URL alone always fails. The date range above is deliberately an old month: the call returns an empty result quickly, which is all the availability check needs. Any valid month works.

• Use the surveillance table to adjust the monitoring settings:
  • Thresholds
  • Filters

• A single call per run returns every subaccount, service, plan and measure of the global account. The surveillance table then decides what is reported and what raises an alarm. Adding a line costs no additional call to SAP.

• Defines how many months before the current one are collected.
• Default is 0, which collects the current month only.
• It widens the metadata export only. Metrics and alarms always use the most recent month present in the response.
• Set it to 1 to keep re-reading the previous month for a few days after month end, while SAP is still settling the final figures.

Note: alarms and metrics deliberately ignore the earlier months. An alarm on a closed month cannot be acted on, and publishing several months at the same moment would write several values into a single metric series at one point in time.

• If enabled, this parameter will send the collected usage records as metadata to the configured plugins/integrations
• It can usually be retrieved as logs or tabular data within the corresponding integrations
• All collected usage records are sent, not only those matching a surveillance rule
• Each record carries every field the API returns, including the space, data centre, environment instance and the identifiers behind the display names

Note: a record is only sent when its usage value has changed since the previous run. The same figures are collected on every cycle, so without this the monitor would send several hundred identical records per day for a global account whose numbers barely move. A record whose value is stable is collected, is published as a metric, but is not exported again.

Note: always set a single Measure on a line that carries a threshold. Measures do not share a unit: an API call count, a number of gigabytes and a number of hours are all reported as plain numbers. A threshold on a line matching every measure compares values that have nothing in common, and will alarm on whichever measure happens to have the largest numbers.

Note: each grade of the threshold is switched off independently by a value of 0. G2W:0 W2M:500 is therefore a valid line that only raises a major alarm, and the default G2W:0 W2M:0 raises nothing at all. This lets a line be used purely for metrics.

Note: a usage record matched by several lines is published once as a metric, but raises an alarm for each line that matches it and is over its own threshold. Overlapping lines are intentional: a broad rule over a whole subaccount and a narrow rule on one service can both be useful, and both should be able to alarm.

• The alarm message contains the usage value and its unit, the service, plan and measure concerned, the threshold that was breached, the subaccount and the reporting period.
• The alarm is stable across runs: the same measure on the same subaccount updates the existing alarm rather than raising a new one, and clears when usage falls back under the threshold if Auto clear is set.

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

Effect: Sends a WARNING alarm for each subaccount whose Destination service has passed 20000 API calls this month, and a MAJOR alarm once it passes 30000. The alarm clears on its own at the start of the next month, when the counter restarts.

Effect: Sends a MAJOR alarm when the audit log volume stored for the production subaccount exceeds 5 GB in the month. The warning grade is disabled, so only the major threshold is used.

Note: the measure is part of the metric name, as promonitor.btp.usage.<measure>. Measures do not share a unit, so a single name covering all of them would mix gigabytes, hours and plain counts into one series that no dashboard can plot.

Note: the unit is taken from the API response, not from a fixed list, because the set of measures depends on which services a global account subscribes to.

Note: the value is a cumulative month to date figure and must be read as a gauge. A dashboard that aggregates the series as a sum will multiply it by the number of runs in the month. A per run difference is deliberately not published: SAP restates earlier figures as usage settles, so a difference can legitimately come out negative.

Note: metrics are sent from the first run even when no threshold is configured. This is intentional, so the normal range of an account can be observed before choosing thresholds.

Note: the reporting period is carried as a target so a published sample is never ambiguous about which month it measures.