Funcionamiento de alertas Proactive

1 Comportamiento esperado del umbral sostenido (sustained threshold)
2 Atenuación (dampening)
3 Retardo entre la superación del umbral y el evento
4 Parámetros configurables
- 4.1 Personalización
- 4.2 Lógica de búsqueda del período
5 Ejemplo práctico
- 5.1 ¿Cómo NMIS evalúa el umbral sostenido?
- 5.2 Generación del evento
- 5.3 Cierre del evento
- 5.4 Tabla de resumen

En las alertas Proactive generadas por NMIS, existen varios aspectos a considerar antes de que se genere o no una alerta, los cuales se describen a continuación:

Comportamiento esperado del umbral sostenido (sustained threshold)

El sistema no genera una alerta inmediatamente cuando un valor supera un umbral en una sola medición (collect). En su lugar, NMIS promedia los valores durante un período de tiempo (threshold_period).

Solo si el promedio durante ese período excede el nivel configurado, entonces se genera el evento.
Esto evita falsos positivos provocados por picos momentáneos. (Por ejemplo: un pico de CPU de un minuto no dispara una alerta si después baja rápido).

Atenuación (dampening)

Además, NMIS aplica un mecanismo de amortiguación o “dampening”. Esto evita que si el valor está justo en el límite del umbral, el evento se dispare y cierre repetidamente.

El sistema usa configuraciones como:

$C->{'threshold_falling_reset_dampening'}: controla el retardo o amortiguación cuando el valor vuelve a bajar del umbral.
$C->{'threshold_rising_reset_dampening'}: controla el retardo o amortiguación cuando el valor sube y cruza el umbral.

Esto hace que las alertas sean más estables y no se repitan por fluctuaciones pequeñas.

Retardo entre la superación del umbral y el evento

Puede haber un retraso entre cuando el valor supera el umbral y cuando se genera el evento. Ese retraso es esperado, no necesariamente un error de configuración.

Sucede porque el valor tiene que mantenerse alto el tiempo suficiente (sustain) para cumplir el promedio configurado.
Si el valor solo estuvo alto por poco tiempo, no se generará evento.

Parámetros configurables

Existen parámetros que controlan este comportamiento.

threshold_period-section: define cuánto tiempo hacia atrás NMIS promedia los datos para calcular si el umbral está sostenido.

Este valor depende de la sección del modelo (por ejemplo: health, interface, pkts, etc.).
Si no se define un período específico para esa sección, se usa el valor por defecto de 15 minutos.

La configuración por defecto del archivo /usr/local/nmis9/conf/Config.nmis es la siguiente:

'threshold_period-default' => '-15 minutes',
'threshold_period-health' => '-4 hours',
'threshold_period-interface' => '-15 minutes',
'threshold_period-pkts' => '-15 minutes',
'threshold_period-pkts_hc' => '-15 minutes',

Esto significa:

Si la métrica pertenece a la sección health, promedia las últimas 4 horas.
Si pertenece a interface, pkts, etc., promedia los últimos 15 minutos.

Personalización

Actualmente, no se puede personalizar threshold_period por nodo individual, solo por modelo. Pero sí se puede hacer por sección dentro del modelo, usando nombres únicos.

En este caso, se realiza el análisis de CPU Load, que está contenido en el archivo /usr/local/nmis9/models-custom/Common-Windows-wmi_v1.nmis. Lo siguiente se agrega en la sección 'threshold':

'threshold_period-CPULoad' => '-10 minutes'

Esto hará que NMIS solo considere los últimos 10 minutos de datos para calcular si se supera el umbral de CPU.

Lógica de búsqueda del período

Alrededor de la línea 163 en el archivo /usr/local/nmis9/lib/NMISNG.pm, existe la sección que indica cómo NMIS decide qué threshold_period usar:

for my $maybe ( $args{subconcept}, "default" )
{
return $self->config->{"threshold_period-$maybe"} if ( $self->config->{"threshold_period-$maybe"} );
}
return "-15 minutes";

Traducción lógica:

Busca si existe un threshold_period específico para la subsección del modelo (por ejemplo, CPULoad, health, etc.).
Si no lo encuentra, usa el threshold_period-default.
Si tampoco existe, por seguridad usa 15 minutos.

Ejemplo práctico

En el archivo /usr/local/nmis9/models-custom/Common-Windows-wmi_v1.nmis se tiene la siguiente configuración de umbrales para el evento ‘Proactive Windows CPU’:

  'WindowsCPU' => {
    'event' => 'Proactive Windows CPU',
    'item' => 'LoadPercentage',
    'select' => {
      '5' => {
        'control' => '$node eq "BNOPINTRAAP13-A"',
        'value' => {
          'critical' => '65',
          'fatal' => '70',
          'major' => '60',
          'minor' => '55',
          'warning' => '50'
        }
      },
      '10' => {
        'control' => '$node eq "bnodtestw2k16"',
        'value' => {
          'critical' => '65',
          'fatal' => '70',
          'major' => '60',
          'minor' => '55',
          'warning' => '50'
        }
      },
      'default' => {
        'value' => {
          'critical' => '90',
          'fatal' => '95',
          'major' => '85',
          'minor' => '80',
          'warning' => '70'
        }
      }
    },
    'title' => 'CPU Utilisation',
    'unit' => '%'
  },

El comportamiento del CPU1 mostrado en opCharts para el equipo 'bnodtestw2k16', es el siguiente:

El collect para este dispositivo se encuentra configurado cada 2 minutos, por lo tanto 15 minutos equivalen a unos 7 u 8 polls.

¿Cómo NMIS evalúa el umbral sostenido?

NMIS no evalúa solo el último valor. Calcula el promedio de los últimos valores dentro del threshold_period (por defecto 15 min).
Solo cuando ese promedio sostenido supera el umbral, se genera el evento. Si los valores bajan rápido antes de que el promedio se mantenga alto lo suficiente, no se genera nada.
Además, el dampening impide que si el valor está cerca del límite (por ejemplo, 64–66%), el evento se abra y cierre constantemente.

Generación del evento

Hora	CPU (%)	Supera umbral crítico (65%)	Promedio sostenido (últimos ~15 min)	Resultado

Hora	CPU (%)	Supera umbral crítico (65%)	Promedio sostenido (últimos ~15 min)	Resultado
10:30	4	❌	Promedio ≈ 4%	Nada
10:32	1	❌	Promedio ≈ 2.5%	Nada
10:34	75	✅	Promedio ≈ (4+1+75)/3 = 26.6%	Nada (promedio bajo)
10:36	100	✅	Promedio ≈ (4+1+75+100)/4 = 45%	Nada
10:38	97	✅	Promedio ≈ 55%	Nada aún (por debajo de 65%)
10:40	41	❌	Promedio baja ≈ 53%	Nada
10:42	20	❌	Promedio baja ≈ 48%	Nada
10:44	63	❌ (menor que 65)	Promedio ≈ 50%	Nada
10:46	63	❌	Promedio ≈ 52%	Nada
10:48	63	❌	Promedio ≈ 53–55%	🔥 Aquí se genera el evento

Explicación:

Para las 10:48 AM, el promedio de los últimos 15 min (aproximadamente 7 muestras: 10:34–10:48) ya supera 65% debido a que varios valores fueron altos (75%, 100%, 97%, 63%, 63%, 63%).
El sistema detecta que la condición se ha sostenido el tiempo suficiente y finalmente genera el evento crítico.

Cierre del evento

Hora	CPU (%)	Estado

Hora	CPU (%)	Estado
10:50	47	❌ baja
10:52	68	✅
10:54	68	✅
10:56	99	✅
10:58	26	❌
11:00	0	❌
11:02	0	❌ → evento cerrado

Explicación:

Cuando el promedio sostenido de los últimos 15 min cae por debajo del umbral, el evento se cierra automáticamente.
Por eso no se cierra justo cuando baja el valor, sino después de unos cuantos polls más.

Tabla de resumen

Concepto	Explicación

Concepto	Explicación
La alerta no se genera a las 10:34 AM	Porque el promedio de los últimos 15 min no superaba 65% aún.
La alerta se genera a las 10:48 AM	Porque el valor sostenido durante varios collects ya superó el umbral.
La alerta se cierra a las 11:02 AM	Porque el promedio sostenido volvió a bajar por debajo del umbral.
Parámetro clave	`threshold_period` controla cuánto tiempo de datos se promedia para decidir.