Creación de reglas y acciones de alerta

Actualizado: 2012-02-03

Esta sección describe conceptos básicos sobre alertas en tiempo real y ofrece una serie de estrategias y directrices para implementar reglas de alerta en EdgeSight. Para obtener instrucciones detalladas sobre cómo crear alertas y acciones en tiempo real, consulte los temas “Reglas de alerta” y “Acciones de alerta” de la ayuda en pantalla.

Las alertas en tiempo real permiten supervisar aplicaciones y dispositivos importantes de la empresa y notificar a personas designadas dentro de la misma cuando se producen problemas. De manera predeterminada, el agente recopila datos y estadísticas de alertas en cada escritorio y los carga en el servidor diariamente. Cuando se configura explícitamente una alerta mediante una regla de alerta, se solicita el envío de una notificación en tiempo real cada vez que se produce una condición de alerta específica.

El propósito de las alertas en tiempo real es notificar oportunamente los sucesos importantes que requieran atención inmediata. Por ejemplo, las reglas de alerta garantizan que los datos estén disponibles para su consulta en el Monitor de comunidad. El Monitor de comunidad permite examinar una comunidad XenApp y mostrar las alertas en tiempo real y el contexto de sistema de uno o varios dispositivos. Cuando desarrolle una estrategia de alertas en tiempo real, asegúrese de crearlas sólo para sucesos que tengan una resolución asociada. Las alertas en tiempo real no van dirigidas a la recopilación de datos; los agentes recopilan los datos correspondientes tanto si la regla de alerta existe como si no, y los informes históricos disponibles son el medio más efectivo para consultar datos de disponibilidad y rendimiento.

Una configuración de alertas correcta es muy importante para obtener una notificación de alerta efectiva en tiempo real acerca del estado de las aplicaciones y los dispositivos distribuidos. Le permite identificar rápidamente qué problemas son verdaderamente importantes y requieren atención inmediata, y qué problemas pueden esperar. Para obtener una configuración de alertas efectiva es necesario implementar una estrategia de alertas. Cuando diseñe su estrategia, haga lo siguiente:

Una vez establecida una estrategia de alertas, puede configurar las alertas en tiempo real usando la página Reglas de alerta en la consola EdgeSight Server Console (Configuración de la empresa > Alertas > Reglas).

Funciones de las alertas

Hay una serie de funciones que mejoran la configuración de reglas de alertas para una condición susceptible de ser objeto de alerta y reducir el número de alertas superfluas que genera el agente. Estas reglas de alerta deben dar como resultado una respuesta de acción en caso de que la alerta llegue a generarse. A continuación se presenta una lista de algunos escenarios mejorados:

  • Las reglas de alerta de rendimiento se pueden especificar basándose en parámetros complejos. Por ejemplo, se puede enviar una alerta de Rendimiento del sistema si el uso de CPU supera x% y hay menos de x de memoria libre en el equipo.
  • Se pueden definir reglas de alertas de aplicaciones para especificar el nombre de empresa del proceso desde el cual se generan las reglas de alerta. Por ejemplo, si un proceso escrito por la empresa especificada falla, se envía una alerta de Fallo de proceso al equipo de asistencia técnica interno de la empresa.
  • Se pueden especificar reglas de alertas de registro de eventos Windows para incluir la aplicación y el evento que hace la entrada en el registro de eventos. Por ejemplo, si se produce una infracción de directiva de grupo, se envía una alerta al equipo de seguridad.
  • Se puede usar negación lógica (con la casilla No es como) para definir ciertas reglas de alerta. Por ejemplo, para enviar una notificación de alerta de aplicación terminada sólo si el proceso terminado no fue escrito por el equipo interno de programación de herramientas.

Tipos y categorías de alerta

Las alertas en tiempo real se pueden subdividir en dos categorías: basadas en eventos y de sondeo. Las alertas basadas en eventos se generan cuando se produce el evento asociado en el sistema; las alertas de sondeo se basan en consultas hechas a la base de datos del agente en forma periódica. En general, las alertas de sondeo se usan como notificaciones de problemas de rendimiento en una aplicación, sistema o red. Para obtener información sobre cómo funcionan las alertas de sondeo, consulte Parámetros de muestra, sondeo y nueva alerta, más adelante.

Cuando se configuran reglas de alerta mediante el asistente correspondiente, las alertas se agrupan en los tipos siguientes según el tipo de evento o condición a la que se asocian:

  • Alertas de la aplicación
  • Alertas del sistema
  • Alertas de red
  • Alertas de rendimiento de XenApp
  • Alertas de error de XenApp
  • Alertas de rendimiento de sesiones
  • Alertas de error de XenDesktop

Para garantizar que los datos de alerta en tiempo real de los servidores XenApp estén disponibles, las siguientes alertas están preconfiguradas y asignadas al subdepartamento de comunidades XenApp:

  • Base de datos de registro de configuración no disponible
  • Error de conexión al almacén de datos de la comunidad
  • Error de la acción de supervisión de estado y recuperación
  • Error de la prueba de supervisión de estado y recuperación
  • El servicio IMA no responde
  • Fallos de conexión con el servidor de licencias
  • El número de servidores en una zona es demasiado alto
  • Límite de uso simultáneo de la aplicación publicada
  • Sesión en estado apagado
  • Error de conexión al cliente de Terminal Server
  • Error de detección del servidor de licencias de Terminal Server
  • Elección de recopilador de datos de zona desencadenada
  • Elecciones de zona demasiado frecuentes

Los parámetros para estas alertas se pueden modificar. En el asistente de creación de reglas de alerta se puede ver la descripción de cada regla de alerta y su conjunto de parámetros.

Alertas de Active Application Monitoring

EdgeSight Server Console muestra las alertas en tiempo real recibidas desde el software Citrix Active Application Monitoring (AAM). Con este software se pueden grabar y crear scripts de usuarios virtuales y definir pruebas. Cuando se ejecutan las pruebas, se generan sesiones ICA de usuarios virtuales en los servidores XenApp de destino. Los resultados de las pruebas proporcionan información sobre la respuesta y disponibilidad de las aplicaciones.

Importante: Para generar alertas de Active Application Monitoring es necesario tener el Agente de EdgeSight para XenApp 5.0 o posterior ejecutándose en modo Avanzado.

Las reglas de alertas de Active Application Monitoring son las siguientes:

  • La alerta de Fallo de respuesta de aplicación se genera cuando falla una transacción supervisada.
  • La alerta de Tiempo de respuesta de aplicación se genera cuando el tiempo que tarda en ejecutarse la transacción supervisada supera el umbral especificado.

Estas alertas se agrupan bajo las alertas de rendimiento de XenApp. Para obtener más información sobre la instalación de software, consulte Instalación y configuración. Para obtener más información sobre cómo crear e iniciar pruebas, consulte la ayuda en pantalla que acompaña al software Active Application Monitoring.

Notas sobre alertas específicas

La información siguiente sobre ciertas alertas le ayudará a comprender en qué condiciones se generan estos tipos de alerta.

  • Alerta de nuevo proceso: Sólo se genera para procesos que se utilizan por primera vez una vez transcurrido el período de gracia de nuevo proceso. El período de gracia se configura en las propiedades del agente (para más información, consulte Configuración de propiedades del agente). Por ejemplo, el período de gracia predeterminado en los agentes de XenApp es de 7 días. Si instala un agente y luego inicia un proceso, el agente lo registra como proceso pero no como nuevo proceso porque la base de datos del agente tiene menos de 7 días. Una vez que la base de datos tiene más de 7 días, cualquier nuevo proceso (es decir un proceso que no está en la base de datos del agente) que se ejecute desencadenará una alerta. Esto evita recibir una gran cantidad de alertas en el momento en que se instala el agente. Tenga en cuenta que el período de gracia es relativo a la edad de la base de datos del agente, no a la fecha de instalación inicial del mismo. Si por alguna razón es necesario volver a crear la base de datos del agente, el período de gracia se restablece.
  • Alerta de proceso bloqueado: Corresponde a las alertas de "No responde" que aparecen en los informes. El software de EdgeSight usa la API de Windows (invocación de IsHangAppWindowl) para determinar si una aplicación ya no responde. Se considera que una aplicación ya no responde cuando ha dejado de esperar entradas, no está en el proceso inicial y no ha invocado la función PeekMessage dentro del período de espera interno de 5000 milésimas de segundo (5 segundos).
  • Alertas de fallo de proceso e instantánea de proceso: Estos tipos de alerta pueden generar informes de errores si las condiciones del equipo afectado permiten capturar datos del error. En algunos casos, el sistema no puede permitir la recopilación de datos. En el caso de las alertas de fallos de proceso y los informes generados respectivamente, existen varios factores que se deben considerar:
    • Si el archivo de errores no se puede generar, se crea un registro del mensaje correspondiente en el archivo de registro zcrash_loader. Vaya a Estado del servidor > Host de scripts del servidor, localice es_zcrash_loader, haga clic en el icono de menú y seleccione Ver registro.
    • ¿Cuándo se creó el informe de errores? La optimización del informe de errores es diferente a la optimización de la base de datos, y el tiempo de retención de los informes de errores está controlado por el parámetro Máx. de días de conservación. Vaya a Configuración del servidor > Configuración y seleccione la ficha Procesamiento de errores.
    • ¿Cuál es el límite para el número máximo de registros recopilados y cuánto espacio se asigna a los informes de errores? (Consulte Configuración del servidor > Configuración). Si se excede el número máximo de registros de errores o el límite de consumo máximo de disco, el procesamiento de errores de la aplicación se desactivará hasta que se aumente el límite. No existe una operación de restablecimiento que se pueda utilizar para eliminar las cargas existentes.
  • Error de uso individual de la aplicación publicada y Límite de uso simultáneo de la aplicación publicada: Cuando se habilite el registro de eventos de control de conexión en el servidor XenApp, el parámetro Registrar los rechazos por superación de límites debe estar habilitado para permitir la generación de estas alertas basadas en SMA. (Para los sistemas XenApp 6, use la directiva Registro de sucesos de límites de inicios de sesión). Para obtener más información sobre cómo configurar sucesos de control de conexiones, consulte la documentación de XenDesktop.

Parámetros de muestra, sondeo y nueva alerta

La muestra es la recopilación periódica de datos del sistema que se está supervisando. El sondeo es cuando un agente ejecuta una consulta en la base de datos para comparar los parámetros de la regla de alerta con los datos recopilados.

Cada regla de una alerta por sondeo incluye los siguientes parámetros:

  • Porcentaje de muestras necesarias
  • Intervalo de sondeo
  • Nueva alerta

La mayoría de la reglas de alerta por sondeo también incluyen un parámetro Ventana de muestra de datos que no se puede modificar y que normalmente se establece en Intervalo de sondeo más un minuto.

Estos parámetros permiten optimizar la frecuencia con la que se pueden desencadenar las alertas de un tipo específico. La muestra se realiza cada 5 segundos, según el tipo de alerta. Durante la muestra, se recopilan los datos necesarios del tipo de alerta. Cuando se produce un sondeo, los datos recopilados se comparan con las condiciones especificadas en la regla de alerta. El valor del intervalo de sondeo determina la frecuencia con la que se realiza el sondeo. El porcentaje de muestras necesarias determina el porcentaje de muestras recopiladas que deben estar dentro del umbral (superior o inferior, según el tipo de alerta) antes de que se desencadene una alerta. Si la alerta definida por la regla de alerta ya se ha desencadenado durante el período de nueva alerta, no se generará otra alerta hasta que caduque el período y se vuelva a producir la condición de alerta. La ventana de muestra de datos indica desde cuándo se incluyen las muestras en el sondeo.

Nota: El intervalo de sondeo predeterminado está diseñado para proporcionar una generación oportuna de alertas minimizando el impacto de las consultas a la base de datos. La disminución del intervalo de sondeo (aumento de la frecuencia con la que se ejecutan las consultas) puede tener un efecto negativo en el rendimiento del sistema y se debe realizar con precaución.

Ejemplo de alerta de sondeo

Esta ilustración muestra una regla de alerta para detectar ralentizaciones del sistema debidas a un uso intensivo de CPU.



La alerta funciona de este modo:

  • El software del agente de EdgeSight toma muestras del porcentaje de tiempo de CPU utilizado. En este ejemplo usamos una frecuencia de muestreo de 5 segundos.
  • Cada 90 segundos, el software sondea las muestras recopiladas para ver si el porcentaje de tiempo de CPU supera el 40 por ciento en, al menos, un 10 por ciento del número total de muestras. La ventana de muestra de datos está definida como el intervalo de sondeo (90 segundos) más un minuto (60 segundos), por lo que se incluyen todas las muestras recopiladas en los últimos 150 segundos. Esto significa que se habrán recopilado 30 muestras. Si hay 3 muestras o más (del total de 30) que arrojan un porcentaje de tiempo de CPU superior al 40 por ciento, se generará una alerta.
  • El parámetro de nueva alerta se define como Cada intervalo de sondeo, de modo que si el porcentaje de tiempo de CPU también supera el umbral en los datos incluidos en el siguiente sondeo, se generará otra alerta.

Cuándo se debe configurar una regla de alerta en tiempo real

EdgeSight no necesita que se configuren ciertos tipos de alerta para que el agente de EdgeSight recopile datos en las condiciones que generarían la alerta. Si está configurando una regla de alerta, debe hacerlo sólo si está en posición de responder a ella en cuestión de horas. Si no hay una respuesta apropiada a tal condición de alerta en un plazo de varias horas desde que se genera, es mejor usar un informe histórico para determinar si se ha producido algún problema significativo. Si se crean demasiadas reglas de alerta se puede reducir la efectividad de las herramientas de supervisión, como el monitor de comunidad, ya que se recibirían multitud de alertas y ello haría más difícil la identificación de los eventos realmente importantes.

Impacto de las alertas en tiempo real en el rendimiento

Independientemente del tipo de alerta de regla, existirá un determinado consumo de recursos de procesamiento para cada regla configurada para un agente. Como mínimo, el agente tiene que determinar si la alerta debe ser generada y, si es así, debe enviar la alerta al servidor. En algunos casos, el agente debe ejecutar una consulta SQL en la base de datos para determinar si se ha producido una condición de alerta y, si las condiciones abarcan varios factores, el agente tiene que procesar grandes cantidades de datos para generar alertas y después enviarlos al servidor.

Cada regla de alerta configurada para un agente concreto lleva asociado un consumo de recursos para procesamiento, y dicho procesamiento puede ocurrir cuando el usuario final está intentando realizar alguna tarea importante, por lo que es necesario tener cuidado y configurar únicamente las reglas de alerta necesarias, con un destino y una acción asociados. Si el impacto general del agente en un sistema es un problema, y se han definido un número significativo de reglas de alerta para ese agente, tiene la opción de volver a evaluar las reglas definidas para determinar si un informe historial es más apropiado que las alertas en tiempo real. La lista siguiente ofrece instrucciones generales para determinar cuándo un conjunto de reglas de alerta puede afectar negativamente al usuario final.

  • Si se han definido 3 ó 4 alertas de rendimiento de red o de aplicación.
  • Si se han definido alertas de rendimiento de proceso o de red para condiciones frecuentes, por ejemplo, un uso de CPU por encima del 5%.
  • Si se han definido alertas de rendimiento de proceso o de red para condiciones muy complejas (por ejemplo, llenar un valor para más de 2 ó 3 umbrales de rendimiento). En estos casos, las consultas SQL ejecutadas por el agente para determinar si existe una condición de alerta, pueden consumir un número elevado de ciclos de base de datos significativo.
  • Si se definen alertas de rendimiento de proceso o de red con “No es como”.
  • Si se definen alertas de rendimiento de proceso o de red con varias operaciones textuales de “Como” o “No es como”.
  • Si se definen reglas de alerta de rendimiento que nunca se generarán (por ejemplo, una alerta de rendimiento de proceso para una aplicación cuya ejecución está bloqueada por una directiva de grupo).

¿Cuándo mostrará el servidor una alerta en tiempo real?

Las alertas en tiempo real no se generan hasta que se cumplen las condiciones siguientes:

  • Las reglas de alerta se crean y asignan a un departamento.
  • Los dispositivos han ejecutado el proceso de trabajo inicial o el proceso de trabajo de comprobación de la configuración.
  • Ha tenido lugar la condición o el evento especificado en la regla de alerta
Nota: Algunas reglas de alerta de XenApp están preconfiguradas y asignadas al departamento de Comunidades XenApp, según se describe en “Tipos y categorías de alertas” en esta sección.

No se envían alertas de ningún tipo al servidor hasta que el agente ha completado su secuencia de inicio, lo que puede tardar varios minutos. Los procesos de trabajo de inicio y de comprobación de configuración se ejecutan una vez completada la secuencia de inicio, y la ejecución de los procesos de trabajo tarda varios minutos. Una vez generada la alerta, ésta se almacena en un lote para enviarla al servidor. Las alertas se guardan en lotes durante un máximo de un minuto, y si la conexión de red funciona, se envían al servidor. Si no existe una conexión de red, o si el agente se detiene antes de poder enviar las alertas, el servidor no recibirá las alertas en cola, y no se volverán a enviar. (No se garantiza que el servidor reciba las alertas en tiempo real). No obstante, dado que el agente no requiere que se configuren alertas de tiempo real para la recopilación de datos, la condición de alerta aún se captura y se puede ver en los historiales después de cargar los datos, incluso si no se han enviado al servidor como alertas en tiempo real. Las alertas no enviadas también se muestran en los informes de alerta en tiempo real que muestran datos directamente desde la base de datos del agente.

Administración de acciones de alerta

La página Acciones de alertas (Configuración de la empresa > Alertas > Acciones) permite configurar la generación de una acción de alerta cuando ocurre una condición de alerta específica. Las acciones de alertas se pueden usar para:

Es posible asociar una única acción con varias reglas de alerta. Por ejemplo, hay varios casos en que un jefe de TI debe recibir notificación de una condición de alerta, por lo tanto se puede asociar una acción de envío de mensaje de correo electrónico a dicho jefe con cada regla de alerta aplicable.

Nota: Si bien con la acción de alerta “Iniciar proceso ejecutable externo” sólo se puede iniciar un archivo EXE, es posible ejecutar cmd.exe y usar argumentos de línea de comandos para invocar un archivo con otra extensión (por ejemplo, BAT o VBS).

Para obtener información sobre cómo crear acciones de alerta, consulte el tema “Acciones de alerta” de la ayuda en pantalla.

Administración de supresiones de alertas

La página Supresiones de alerta (Configuración de la empresa > Alertas > Supresiones) muestra las alertas que se han suprimido. Los administradores pueden modificar o borrar supresiones de alertas.

Cualquier usuario puede crear una supresión de alerta desde la Lista de alertas ubicada en la ficha Supervisión. Las supresiones sirven para evitar que EdgeSight Server Console muestre un tipo de alerta específico basándose en su origen, dispositivo o usuario, o una combinación de estos criterios. Las supresiones sólo tienen efecto para el usuario que las creó; los demás usuarios pueden seguir viendo las alertas. Para obtener más información sobre las supresiones de alertas, consulte los temas “Lista de alertas” y “Supresiones de alerta” de la ayuda en pantalla.

Contact Careers Terms of Use Privacy Governance Follow Us
© Citrix Systems, Inc. All rights reserved.