How do indicators work?

Indicator components

An indicator consists of the following components:

The components appear in the Create and Edit forms.

Sample indicator

An example indicator tracks average utilization for a three-node ring, sampling from four ports and a LAG in the ring. Alarms are generated if average utilization is increasing above 50% or decreasing below 5%.

General

The general parameters include the following:

Note: For simple indicators, that is, indicators with only one counter and no formula, there is no data bucket. The window duration is ignored; KPI values are calculated at the collection interval.

Counters&Formula

The Counters & Formula parameters declare the telemetry values to be collected and the operations and aggregation functions to apply. An object filter ensures that the data is collected on the resources of interest.

For the sample indicator, the formula is configured to provide an average of the counter value data.

See How do indicator formulas work? for details.

Object filter

Configure an object filter as needed to filter the available resources; see How do object filters work?.

When at least one counter has been selected, the VERIFY RESOURCES button becomes available. Check the contents of the resource list to ensure that your object filter is retrieving the correct objects.

For the sample indicator, the object filter determines the ports and LAGs to collect information from.

Thresholds

Thresholds define the preferred range of data values for the indicator. Thresholds are optional: you can create zero, one, or multiple thresholds, for increasing or decreasing values.

When the indicator is plotted in Visualizations, thresholds appear on the plot and threshold crossing events are indicated.

Each threshold can be configured to trigger one or more actions:

Note: Indicator alarms may still be raised shortly after a resource (for example, an NE) is unmanaged in NSP if statistics messages are already in the system waiting to be processed.

For the sample indicator, you can configure an example threshold, with:

This configuration allows for high and low utilization to be handled differently according to differing levels of urgency. If needed, another increasing threshold could be set at 40, for example, with warning severity, to tell operators that the ring may need attention.

Threshold crossing alarms

Indicator TCAs appear in Current Alarms as alarms with Source System “fdn:app:nsp-indicator” and Alarmed Object Type “nsp-indicator:rta-indicator-rules/rule”. The Alarmed Object ID contains the indicator rule name and the Additional Text contains the threshold violation details.

The Object Full Name field contains the indicator name and the specific object instance. For aggregate TCAs, where the aggregation functions such as avg() or sum() are used, the threshold violation may be based on statistics from multiple objects, and therefore cannot be attributed to a single object instance. In this case, the Object Full Name field contains the name of the indicator rule.

Visibility of TCAs depends on user access control settings.

Simple and complex indicators

Simple indicators use a single counter and no formula. A simple indicator is evaluated every collection interval, for every resource returned by the object filter.

Complex indicators use one or more counters and a formula. A complex indicator uses counter statistics received during each window duration to aggregate each incoming counter from each resource into a counter function. This output is then, depending on the formula, used in arithmetic or aggregation operations, or both, to calculate the KPI.

Indicator data storage

Indicator data is stored in Postgres unless there is an auxiliary database enabled, in which case all collected data is stored in the auxiliary database.

By default, data is stored in Postgres for 35 days, and in the auxiliary database for 90 days. These values can be changed using the RESTCONF API or by updating the age-out policy; see How do I edit an age-out policy?.