Uso de eventos correlacionados para activar una política de eventos

Además de configurar una política de eventos para desencadenarse en un solo evento, también puede configurar una política de eventos que correlacione dos o más eventos. Si los eventos se producen según lo especificado, la política de eventos ejecuta las acciones configuradas. Por ejemplo, es posible que desee emitir ciertos comandos de modo operativo cuando se genere un evento de UI_CONFIGURATION_ERROR dentro de los cinco minutos posteriores a un evento de UI_COMMIT_PROGRESS. Como otro ejemplo, es posible que desee cargar un archivo determinado si un evento DCD_INTERFACE_DOWN se genera dos veces en un intervalo de 60 segundos.

Para correlacionar eventos en una política de eventos, incluya las siguientes instrucciones en el nivel de [edit event-options] jerarquía:

En la events instrucción, puede enumerar varios eventos desencadenantes. Para obtener información sobre cómo definir eventos en directivas de eventos, consulte Información general sobre directivas de eventos y notificaciones de eventos. Para correlacionar esos eventos con otros eventos, configure las within instrucciones y/o.attributes-match

La within instrucción define los eventos correlacionados que deben (o no) ocurrir dentro de un intervalo de tiempo especificado antes de un evento desencadenante. La attributes-match instrucción permite al sistema tener en cuenta los atributos de un evento. La attributes-match instrucción puede correlacionar el atributo de un evento con el atributo de otro evento o con una expresión regular. La política de eventos ejecuta las acciones configuradas en la then instrucción solo si se cumplen las condiciones especificadas. En las secciones siguientes se describe cómo usar las instrucciones.

• Correlación de eventos por intervalo de tiempo
• Correlación de eventos según atributos de eventos

En argumentos de script de eventos e instrucciones de política de eventos admitidas, como la execute-commands instrucción, puede usar variables de política de eventos para diferenciar entre un evento desencadenante y un evento correlacionado. Los eventos desencadenantes y los eventos correlacionados se configuran en las siguientes instrucciones en el nivel de [edit event-options policy policy-name] jerarquía:

• Evento desencadenante: configurado en la events instrucción
• Evento de correlación: configurado en la within seconds events instrucción

Puede utilizar variables de política de eventos de los siguientes formularios para representar eventos desencadenantes y correlacionados:

• {$$.attribute-name}: la notación de doble signo de dólar ($$) representa el evento que activa la política. Cuando se combina con un nombre de atributo, la variable se resuelve en el valor del atributo asociado con el evento desencadenante. Por ejemplo, {$$.interface-name} se resuelve en el nombre de interfaz asociado con el evento desencadenante.

• {$event.attribute-name}—El signo de dólar único con la notación de nombre de evento ($event) representa el evento más reciente que coincide con event. Cuando se combina con un nombre de atributo, la variable se resuelve en el valor del atributo asociado con ese evento. Por ejemplo, cuando una política emite el show interfaces {$COSD_CHAS_SCHED_MAP_INVALID.interface-name} comando, la {$COSD_CHAS_SCHED_MAP_INVALID.interface-name} variable se resuelve en el nombre de interfaz asociado con el evento más reciente COSD_CHAS_SCHED_MAP_INVALID almacenado en caché por el proceso de eventos.

• {$*.attribute-name}—El signo de dólar con la notación de asterisco ($*) representa el evento más reciente que coincida con cualquiera de los eventos correlacionados. La variable se resuelve en el valor del atributo asociado con el evento más reciente que coincide con cualquiera de los eventos correlacionados especificados en la configuración de la política.

En las políticas de eventos, puede hacer referencia a eventos específicos mediante variables de política de eventos. Tenga en cuenta la siguiente política de eventos:

En el show interfaces {$$.interface-name} comando, el valor del interface-name atributo de evento e1, e2, o e3 se sustituye por la {$$.interface-name} variable.

En el show interfaces {$e4.interface-name} comando, el valor del interface-name atributo del evento más reciente e4 se sustituye por la {$e4.interface-name} variable.

En el show interfaces {$*.interface-name} comando, el valor del interface-name atributo del , o e6 evento más reciente e5e4se sustituye por la {$*.interface-name} variable. Si uno de , e2, o e3 se produce dentro de e1los 60 segundos posteriores a e4, e5, o e6, el valor del interface-name atributo para ese evento correlacionado (e4, e5, o e6) se sustituye por la {$*.interface-name} variable. Si el evento de correlación no tiene un interface-name atributo, el software no ejecuta el show interfaces {$*.interface-name} comando.

Si e1 ocurre dentro de los 60 segundos de ambos e4 y e5, la {$*.interface-name} variable usa el valor del interface-name atributo para e4. La política se utiliza e4 porque el proceso de eventos (eventd) busca eventos correlacionados en orden secuencial según lo configurado en la within instrucción. En este caso, la orden es e4 > e5 > e6.

La siguiente política de eventos emite un conjunto de comandos y carga el archivo de salida resultante en un sitio de archivado. El sistema ejecuta la política de eventos si uno de los eventos desencadenantes, event3, , event4o event5, se produce dentro de los 60 segundos posteriores a que ocurra uno de los eventos correlacionados, event1 o , event2. El pseudocódigo de la política es el siguiente:

El destino de la política de eventos define dos sitios de archivado. El dispositivo intenta transferirse al primer sitio de archivo de la lista y se mueve al siguiente sitio solo si se produce un error en la transferencia. La configuración de la política de eventos es:

En la siguiente política de eventos, los dos eventos se correlacionan si sus valores de atributo de evento coinciden. Hacer coincidir los atributos de ambos eventos garantiza que los dos eventos estén relacionados. En este caso, las direcciones de interfaz deben coincidir y los nombres de interfaz física (ifd) deben coincidir.

El RPD_KRT_IFDCHANGE error se produce cuando el proceso de protocolo de enrutamiento (rpd) envía una solicitud al kernel para cambiar el estado de una interfaz y se produce un error en la solicitud. El RPD_RDISC_NOMULTI error se produce cuando una interfaz está configurada para la detección de enrutadores, pero la interfaz no admite operaciones de multidifusión IP según sea necesario.

En el siguiente ejemplo, una organización desea registrar todas las configuraciones con errores que provocaron una pérdida de conectividad con la red de administración. La organización usa una configuración de prueba de monitoreo de desempeño en tiempo real (RPM) que verifica la accesibilidad de la red de administración cada minuto. Los operadores siempre confirman los cambios mediante el comando de la commit confirmed CLI. El commit confirmed comando permite que la configuración se revierta automáticamente si los cambios en la configuración afectan a la conectividad.

La política de eventos ejecuta un script de eventos, save-rollback.slax, para copiar la configuración con errores anulada por la reversión automática a una ubicación específica. El script de eventos copia el archivo de reversión /config/juniper.conf.1.gz en el directorio /var/tmp para su almacenamiento y posterior examen.

El evento desencadenante de la política de eventos es el evento UI_COMMIT_NOT_CONFIRMED. Este evento se produce cuando el dispositivo revierte automáticamente la confirmación confirmada. Cuando el sistema activa una reversión confirmada de confirmación, el evento UI_COMMIT_NOT_CONFIRMED se produce dos veces. El primer mensaje de evento indica que la reversión está en curso y el segundo mensaje de evento indica que la reversión se ha completado. Por lo tanto, la política de eventos debe correlacionar los dos eventos UI_COMMIT_NOT_CONFIRMED para que el sistema no active la política de eventos dos veces. En este ejemplo, el segundo evento UI_COMMIT_NOT_CONFIRMED debe producirse dentro de los 50 segundos posteriores al primer evento.

Para determinar si la configuración resultó en una pérdida de conectividad con la red de administración, la política de eventos también correlaciona el evento UI_COMMIT_NOT_CONFIRMED con el evento PING_TEST_FAILED del sondeo RPM. Un evento PING_TEST_FAILED ocurre cuando falla la prueba de RPM en la red de administración. En este ejemplo, el evento UI_COMMIT_NOT_CONFIRMED debe producirse dentro de los 60 segundos posteriores al evento PING_TEST_FAILED. Para especificar la prueba de sondeo RPM que generó el evento, la política de eventos incluye la attributes-match instrucción y solo se activa cuando el atributo del test-owner evento coincide Connectivity y el atributo del test-name evento coincide Management.

La política de eventos configura instrucciones independientes within para el evento PING_TEST_FAILED y el primer evento UI_COMMIT_NOT_CONFIRMED. Mediante within varias instrucciones, deben darse ambas condiciones para que se desencadene la política de eventos. Cada within instrucción requiere un intervalo de tiempo diferente. Del mismo modo, ambas attributes-match condiciones deben cumplirse para que se active la política.

La configuración de la política de eventos es la siguiente:

El save-rollback.slax script del evento es el siguiente:

Cuando el dispositivo que ejecuta Junos OS activa la política de eventos, el dispositivo guarda el archivo de configuración de reversión en el directorio /var/tmp con un nuevo nombre de archivo que incluye la marca de hora.