How do indicators work?

Indicator components

An indicator consists of the following components:

• General parameters

• Filter & Counters

• Thresholds

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:

• unique name and optional description

• collection interval

  For NEs managed by MDM, this represents the interval for collecting the statistics (for example, every 30 s), while for NEs managed by the NFM-P, this value is ignored and statistics are collected according to the settings configured in the NFM-P.

• window duration

  Window duration is the size of the data bucket for telemetry calculation.

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.

• counters

  When a telemetry type is selected, the ADD COUNTERS button becomes available.

  For the sample indicator, selecting the /telemetry:base/interfaces/utilization telemetry type allows collection of the input-utilization counter.

• formula

  A formula applies arithmetic operators and aggregation functions to the counters. The following can be applied:

  • arithmetic operators: addition, subtraction, multiplication, division, absolute value

  • aggregation functions: minimum, maximum, sum, average

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:

• raise a threshold crossing alarm (TCA)

  The TCA is raised in Current Alarms.

• generate email

  An email can be generated for each threshold crossing event or aggregated by time period or number of events.

  Email server settings must be configured in NSP Settings by an administrator.

• output a message to a Kafka topic

  The Kafka topic must already be created. The default topic is nsp-act-action-event.

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:

• an increasing threshold for a value of 50

• an alarm action with major severity

• a falling threshold for a value of 5 with a Kafka message showing low utilization

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.

• Aggregate TCAs do not contain a Site ID or Site name, and are considered system level alarms. To view these alarms, the user must either have the Administrator role, or have both Access to all Equipment and Access to all Services enabled.

• If the user has access to certain NEs only, the user sees Indicator TCAs for those NEs, but no aggregate TCAs.

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?.