Portal aggregation and grouping

Overview

The Portal aggregates metric data along two dimensions: the defined hierarchy and time. To aggregate the data, the Portal also takes into account the group by and aggregate by options that you set when you create the metric in the Finder (depending on the kind of metric, not all options are available). Learn here how the possible combinations of aggregation and grouping options, as well as the hierarchy node and period selection, produce different results in the dashboards of the Portal.

The example hierarchy

For demonstration purposes, let us suppose that we have defined a very simple hierarchy based on locations that consists of two levels only:

Country (top level)
City (entity level)

Our imaginary organization has offices in two countries: Switzerland (CH) and Spain (ES). For each country, offices are located in two cities: Geneva (GVA) and Zurich (ZRH), in the case of Switzerland; Madrid (MAD) and Barcelona (BCN), in the case of Spain.

Finally, for simplicity, let us suppose that there are just two devices per city, whose names are composed by the initial letter of the city, followed by either the number 1 or the number 2. That makes a total of eight devices:

Hierarchy

Count metrics

Depending on the type of object, count metrics may take into account, for a particular day, only those objects that were active during that day or all the objects regardless of their activity. For some types of objects, you can only count active instances. For packages, you always count all of them. For users and devices, the user may choose whether to count all of them or only those that were active. See the table below as reference:

Only active

Only all objects

User choice

Except in the case of packages, you are usually interested in counting only those objects which were active during the day. However, in cases such as transformation projects, it is important to know which objects already fulfil the transformation condition, no matter whether they were active during a particular day or not. For instance, if you have a migration project from Windows 8 to Windows 10, you probably want to count every day the devices which have already installed Windows 10, even when they were not active during the measurement day. In this way, when observing the results of the metric in the Portal, you get a non-decreasing value, which may not be the case if you measure only active devices instead. For instance, in a typical company, the number of active devices decreases dramatically during the weekend, increasing again during weed days.

The value of a metric that counts all objects is thus valid for the particular day when it is computed and cannot be aggregated through time. Therefore, the Portal does not show widgets associated to these metrics when selecting time periods different from one day. In addition, note that the computation of these metrics requires to look through all the history available in the Engine for counting in all possible objects. The conditions that you can specify for these metrics are consequently the same as for full period investigations, namely they cannot depend on activities or events.

When counting active objects only, an extra condition (count devices that meet conditions on ... in period) influences how the Portal displays the results of the metrics for periods longer than one day. Use this extra condition to count objects, either:

The last day that the objects were active within the selected period (for inventory purposes), or
At least one day during the selected period (for detecting occurrences).

Grouping by properties

As a first example, let us consider a metric that counts the number of devices and groups them both by type and OS (in the COMPUTE DAILY section, select Group by device type and OS version and architecture).

Since this metric is intended to make an inventory of devices and inventories are usually based on the latest state of the catalogued objects, select the extra condition of count metrics to last active day (in the MATCHING section, select Count devices that meet conditions on last active day in period). Leave the rest of the options for creating the metric to their defaults.

The devices in our example are of the following types and have the following operating systems installed:

If the devices and their operating system do not change, the Portal consistently displays the same global results for the metric, regardless of the period selected. For instance, when you display the count metric in a table widget, arranging the rows by operating system and the columns by device type, you always get the following global results:

Now let us consider the case that B1 (the only Mac OS device in the list) gets its OS upgraded from version Yosemite to El Capitan. After this upgrade, the choice of the extra condition of count metrics influences the results displayed in the Portal. Differences appear only when viewing periods are longer than one day in the Portal; therefore, let us see the results of our widget when selecting a period of one week (the week when the device got its OS upgraded). If you chose last active day as extra condition, you get:

That is, you get the same results as before, except for the last row in the list, where OS X Yosemite 10.10.5 (64 bits) is replaced by OS X El Capitan 10.11.4 (64 bits). That implies that the last day when the Mac device was active during the selected week, it already had the El Capitan version installed. However, if the metric was defined with the extra condition option set to at least one day instead of the last active day, the widget displays the following results:

That is, during the week of the upgrade, the Mac computer was seen some days with the Yosemite version installed and some other days with the El Capitan version. Thus, it appears twice in the table widget. For that reason, the option at least one day is not well-adapted to inventorying, which was the original purpose of the metric.

On the other hand, the option at least one day is useful to detect occurrences of particular situations. For example, imagine that you want to know whether any device had the antivirus real-time protection turned off any day during the selected period. To that end, create a metric that counts devices and performs any of the following two functions:

Group the devices by the status of their antivirus real-time protection
Set a condition to get only those devices with the protection turned off.

Choose at least one day as the extra condition of the metric to count those devices that had the protection turned off at any day and not necessarily the last day that they were active.

Note that the Portal verifies the state of the antivirus real-time protection of the devices when it computes the value for the metric. If you switch the antivirus real-time protection of a device off and on in the same day before Portal computation, the situation will go undetected for the previously defined metric. In general, this applies to all metrics that set conditions on the state of objects. On the other hand, metrics with conditions based on events keep a history of occurrences. For instance, if a metric counts the number of devices executing high threat binaries, the Portal will see these executions during the computation of the metric in any case.

Coming back to our inventory example, let us consider now the result of counting all devices instead of counting the active devices only. Since the migration from Yosemite to El Capitan looks like a transformation project, counting all objects is probably more suitable than counting just the active objects. Indeed, imagine that the Mac laptop in the example is turned off for a whole day after being upgraded to El Capitan. While a metric that counts all objects would include the Mac laptop in the results of that day, a metric counting only active devices would leave it out of its results. Think carefully about the choice of counting only active objects or all objects when you create a count metric for devices or users.

Grouping by foreign category

Count metrics let you group results not only by the properties of the counted objects themselves, but also by categories of related objects (foreign categories). Let us illustrate this kind of grouping by creating a metric that counts the number of users. The metric groups the users by a foreign category called Ownership. We define Ownership as a category of devices that has two keywords:

Corporate, which indicates that a device belongs to the company.
BYOD, which indicates that a device personally belongs to the user.

From the example hierarchy, let us focus on the CH node, that is, the devices in Switzerland, and imagine that we had the following usage pattern during the last day:

User 1: an employee used a personal computer G1 in Geneva and then travelled to Zurich and used a corporate computer Z1.
User 2: used a personal computer G2 in Geneva.
User 3: used a corporate computer Z2 in Zurich.

When retrieving the data during the nightly computation, the Portal stores the following data internally:

Note that the Portal is unable to deduce from this table whether the Corporate device of User 1 is located in Geneva or Zurich (same for the employee’s BYOD device). To be on the safe side, the convention followed by the Portal is to count the user in for all possible combinations, although that may lead to situations where the actual combination did not occur. In our example for User 1, only the combinations GVA-BYOD (because of the use of G1) and ZRH-Corporate (because of the use of Z1) actually occur. However, the Portal counts as well User 1 for the combinations GVA-Corporate and ZRH-BYOD.

Thus, displaying the metric in a table widget, with the rows organized by hierarchy and the columns by Device-Ownership, yields the following results for the last day (when CH is selected as the Country of the hierarchy):

Note that because of User 1 using computers in both Geneva and Zurich, and because of the additional combinations added by convention, none of the partial results add up to the overall values. The values over all the hierarchies are shown in the Table widget after ticking the option Display overall value in the configuration of the widget for dividing by hierarchy.

Considerations on ratios and thresholds

When creating a count metric that includes a ratio computation and thresholds based on the ratio, threshold violations occur more frequently when exploring the lower levels of the hierarchy. The reason is that ratios tend to get more extreme when there are less objects to count. To avoid triggering threshold violations with only a few objects involved, tick the checkbox Ignore unless at least x objects are impacted in a hierarchy node and specify the minimum number of objects that must be impacted in order to consider a threshold violation effective.

On the other hand, if you base the thresholds on absolute values instead of ratios, threshold violations occur more frequently in higher levels of the hierarchy, because they involve more objects.

Quantity metrics

There are two types of quantity metrics: those that measure a countable number of actions (such as the number of executions, the number of printed pages, etc.) and those that measure a continuous quantity related to the activity of a device (the memory usage, the boot or logon duration, etc.). In both types of quantity metrics, the measured quantity changes over time. It is therefore necessary to aggregate all the collected values to display a final result in the Portal for each available time frame. For quantity metrics, there are four ways of aggregating the results:

sum over all devices and the whole timeframe
average value per device per day
maximum value per device per day
minimum value per device per day

Not all of the aggregation strategies are available for all quantity metrics. Only the options that make sense for a particular metric can be selected. Typically, the computation of the average and the maximum values per device per day are available to any quantity metric, whereas the sum or the minimum values only make sense for some kinds of quantity metrics.

Let us examine the different aggregation options for quantity metrics through some examples. For instance, consider a metric that counts the number of executions of the Finder -your favorite real-time analysis application from Nexthink- on each device; that is, a quantity metric that computes the number of executions with a condition on the executable name nxfinder.exe. Suppose that, for the current week, the devices of our original example located in Spain have the following usage pattern:

Consider first the results of the metric for the different aggregation strategies when looking at the last day:

Maximum value per device per day: 2

The device that executed the Finder the most on Tuesday is M1, which did it twice.

Sum over all devices and the whole timeframe: 4

Results from adding all the executions on Tuesday 2 (M1) + 1 (M2) + 1 (B1) = 4.

Average value per device per day: 1.3

Results from dividing the sum of all executions (the previous value calculated) by the number of devices that participate in the metric 4 / 3 = 1.3. Note that B2 is not counted in for computing the average on Tuesday because it does not satisfy the condition of executing nxfinder.exe.

Now let us consider the results when selecting the last week. Since the week is not over, the Portal has data only for Monday and Tuesday:

Maximum value per device per day: 4

Device M1 executed the Finder four times on Monday. That is the maximum for any device during the week.

Sum over all devices the whole timeframe: 10

That adds up for the four executions on Tuesday plus six on Monday.

Average value per device per day: 1.7

Results from dividing the sum of all executions over the whole week by the sum of devices participating in the metric each day. That is 10 / 6 = 1.7. Note again that neither B1 not counted in on Monday nor B2 is counted in on Tuesday because they do not satisfy the condition of executing nxfinder.exe, so we only have three devices each day, making a total of 6 devices for computing the average.

We have just seen an example of a quantity metric that counts individual occurrences. Let us now consider a metric based on continuous value; for instance, a metric that computes the average memory usage per execution of the Finder (as in the previous example, we use a condition on the executable nxfinder.exe). As you probably know, the memory used by the Finder increases with the number of tabs that are simultaneously open, so we can expect significant differences between the memory used by any two distinct executions of the Finder. Again, for the devices in Spain, suppose that we have the following usage pattern for the current week:

The metric yields the following results for Tuesday, according to the chosen aggregation strategy:

Maximum value per device per day: 500 MB

Device B1 had the highest memory usage on Tuesday. Note that this is not the absolute maximum value of memory used by the Finder in the device, since the metric is actually measuring the average along the day.

Minimum value per device per day: 100 MB

Device M1 had the lowest memory usage on Tuesday. Again, note that this is an average along the day, so it is not the absolute minimum amount of memory that the Finder used.

Average value per device per day: 300 MB

Adding the values for all devices makes a total of 100 (M1) + 200 (M2) + 500 (B1) + 400 (B2) = 1200 MB, dividing by four devices gives 300 MB in average.

If you select to see the last week results in the Portal, you get the following results:

Maximum value per device per day: 500 MB

No device used more memory for the Finder than B1 on Tuesday, so 500 MB is again the maximum for the week.

Minimum value per device per day: 100 MB

The same for the minimum usage of memory, which corresponds to M1 on Tuesday. Note that the memory usage of M2 on Monday is not counted as 0 because it does not meet the condition of executing the Finder. Thus, the metric does not take M2 into account.

Average value per device per day: 300 MB

We have 1200 MB from Tuesday plus a total of 200 (M1) + 300 (B1) + 400 (B2) = 900 MB on Monday, making a grand total of 2100 MB for the week. Dividing by three active devices on Monday (M2 had no executions) plus four devices on Tuesday, that is, a total of seven devices, gives 2100 / 7 = 300 MB in average.

In quantity metrics, as in count metrics, you can group the results by up to two criteria. Since quantity metrics are related to devices only, the criteria for grouping results can be based either on the attributes or on categories of devices (no foreign categories are available in this case). Setting group by options lets you break down the results of the metric when they are displayed in a table widget within a dashboard, in the same way as shown for count metrics.

Top metrics

Top metrics return a list of objects ordered by their contribution to a particular activity. When defining a top metric, you choose:

The type of object to show in the list.
The total number of objects in the list (from the top 10 to the top 100).
An activity that is linked to that type of object.
The criterion for including the objects in the list: include those with either the highest or the lowest contribution to the activity.
The aggregate by option for the activity, which determines how to compute the contribution of each object.

The available aggregation options are similar to those available in quantity metrics. The difference is that they are not necessarily based on devices, so they can cross device boundaries. For instance, a metric that computes the top 10 users with the highest number of executions aggregates into a single value the number of executions carried out by a same user in different devices. Thus, these are the Aggregate by options of top metrics:

sum over the whole timeframe
average value per day
maximum value per day
minimum value per day

As in the case of quantity metrics, not all the aggregation possibilities are available for all top metrics, but only those that make sense.

Grouping by hierarchy

In addition to the group by options that you specify for count and quantity metrics, the Portal always aggregates the results of all metrics (including top metrics) by hierarchy.

When selecting one group by option in the definition of a count or quantity metric, it is always possible to break down the results by hierarchy and by grouping option, arranging them as the rows and columns (or columns and rows) of a Table widget. If you define two group by options and you select one of them to break down the results by rows or columns in a Table widget, you must select the other option for the columns or rows, respectively. In this case, the option to break down by hierarchy is not available. Nevertheless, choosing to display the total value of the metric or metrics added to the widget (i.e. the Metrics option), instead one of the group by criteria, lets you again choose the hierarchical criterion to arrange the results.

In top metrics, however, there is no group by option and it is not possible to arrange the hierarchy in a Table widget. You can still add display fields to the definition of a top metric to see them arranged in a Table widget.

Hierarchy navigation in the Portal

For those widgets that do not explicitly break down the results of a metric by hierarchy (KPI, Line charts, and those Table widgets not arranged by hierarchy), use the hierarchy navigation tool of the Portal that is located in the top blue ribbon to explore the results at different levels in the hierarchy. All the widgets in the dashboard adapt their results to the node selected in the hierarchy navigation tool.

The Table widgets that do break down the results by hierarchy divide in fact their results by the nodes placed at the immediately lower level of the node selected in the hierarchy navigation tool (that is, its child nodes).

For instance, consider a dashboard built around the hierarchy of our original example. While viewing the dashboard in the Portal, if you switch from the Global view to the node CH in the hierarchy navigation tool, all the widgets in the dashboard will display the results limited to the values that they got for Switzerland. In addition, Table widgets arranged by hierarchy will divide their results by the nodes GVA and ZRH, which are the children of the CH node.

Considerations on aggregation along time

As time passes by, the Portal accumulates data day by day. Every night, the Portal collects and computes the values of the past day and aggregates the results to the current week, month, and quarter.

However, when switching from a view of the current week to the current month in the Portal, a counterintuitive situation may occur: the amount of data available for the current month might be less than the amount of data for the current week. This situation may occur when a month boundary has recently been crossed, because a week can overlap over two different months.

Let us explain it with one of our previous examples on quantity metrics. Consider again the metric that counts the number of executions of the Finder and suppose that we chose to aggregate by the sum over all devices and the whole timeframe. If you look at the values that we obtained, we had 6 executions of the Finder on Monday and 4 executions on Tuesday. Assume now that Monday was April 30, Tuesday was May 1, and it is May 2. Therefore, a month boundary was crossed yesterday.

If we navigate to the most recent date available in the Portal, the result depends on the period selected:

Day: 4 executions, corresponding to Tuesday, May 1.
Week: 10 executions, corresponding to the 6 on Monday plus the 4 on Tuesday.
Month: 4 executions, corresponding to Tuesday, May 1.

That is, the week started before the new month and it is still ongoing, so there are more days available for the current week than for the current month. The value for the week may therefore be bigger than the value for the month.

RELATED TASK

Creating a metric

Last updated 2 months ago