As of SAP Focused Run 3.0 FP02 the new Aggregation Framework for system- and self-monitoring metrics of the Monitoring & Alerting Infrastructure (MAI) is available. It replaces the old framework which is available in System Analysis Aggregation.
The Aggregation Framework offers you the following benefits:
As of SAP Focused Run 4.0 SP00 the following new features are available:
Within SAP Focused Run the new Aggregation Framework is used in the following apps:
The prerequisite for configuring the Aggregation Framework is that the user has the role SAP_FRN_AAD_MOAL_REP_ALL (see New, Changed, and Obsolete Roles with SAP Focused Run 3.0 SP02).
Before starting the configuration, make sure that all MAI jobs are scheduled with default variant. To do so, execute transaction MAI_TOOLS, activate the expert mode, and in tab Administration, click Schedule all MAI jobs with default variant.
The configuration of the Aggregation Framework is done within app System Monitoring - Individual Maintenance and Assignment in the page Aggregation Framework (last page in the navigation bar on the left-hand side).
It uses a variant concept. In each variant, you make the following settings:
Retention Time | Default period in months | Max. period in months |
---|---|---|
Very short* | 1 | 1 |
Short | 3 | 24 |
Medium | 12 | 24 |
Long | 24 | 24 |
Very long* | 75 | 75 |
The variant is immediately active after saving it. The aggregation is performed with a delay of 1-2 hours (e.g., when the aggregation job runs at 10.30 data from 8.00 to 9.00 of the same day will be aggregated).
For more information, see the in-app help of the Aggregation Framework.
In the Central Components of the Self-Monitoring Dashboard, two metrics are monitoring the status of the Aggregation Framework (the self-monitoring metrics are collected by job SAP_MAI_AGGR_SFM):
See the description of the metric if the rating is red. In case the aggregation fails, the next job run will perform the aggregation for missing time slots as well.
The following information is only relevant for you if you have used the app System Analysis – Configuration for retention time of metrics used by OCC Dashboard and System Analysis.
Note that there is currently no migration of configuration or aggregated metric data from the System Analysisframework to the new Aggregation Framework. Therefore, configure the variants for the new framework so that no less data is aggregated than before. Use the forecast option for a review when creating the variants to find out which metrics on which objects are being collected via the variant.
System Analysis and OCC Dashboard have a logic implemented to load the data from the correct source: all data which is older than the activation of the Aggregation Framework is coming from the System Analysisframework, and all data which is newer is coming from the Aggregation Framework.
After activating the Aggregation Framework, deactivate the System Analysisframework manually. This is done by deactivating all variants in the app System Analysis – Configuration.
For SAP Focused Run 3.0 FP02-FP03
The granularity for the aggregation is always on hourly level, there are no other options here. The maximum retention time in the Aggregation Framework is 24 months.
The aggregation is always done in UTC time. Since the granularity is always hourly, time zones with minute shifts compared to UTC are not supported. This is the case, for example, for the Indian time zone., which has a shift of 30 minutes. As a user in that time zone, you can use the aggregated data the applications, but single values are slightly incorrect. This is particularly relevant when displaying hourly aggregates. When displaying daily or weekly aggregates, the problem becomes significant less important. If data is required in such a time zone within a scope where raw data is available, this data will be used. That means correctness of the data is more important than performance. Therefore, the issue occurs only for data that is older than 28 days.
For SAP Focused Run 4.0 SP00
Regarding daily aggregation, it is only supported to define one time zone which is globally used for all variants, and which cannot be changed later. Furthermore, there is no support for daylight saving time. For example, if you choose German time, the data will always be aggregated in German wintertime.
As described already above, the read access to daily aggregates is not yet possible. But nevertheless, it might already make sense to define variants on the daily aggregation to use the data (much) later as this data can be stored up to 75 months.