Supervisión y alerta en IBM Software Hub

Puede utilizar el IBM Software Hub marco de supervisión y alertas para supervisar el estado de la plataforma. Puede configurar eventos para que le avisen cuando sea necesario realizar alguna acción, basándose en los umbrales que usted defina.

De forma predeterminada, IBM Software Hub se inicializa con un monitor que se ejecuta cada diez minutos. El monitor de diagnóstico registra el estado de las implementaciones y las solicitudes de StatefulSetsvolumen persistente. También realiza un seguimiento del uso del sistema de procesadores virtuales (vCPU) y la memoria. Los datos que se recopilan se pueden utilizar para el análisis y para alertar a los clientes en un entorno de producción, en función de las reglas de alerta establecidas.

Marco de alerta

Glosario

Para empezar, debe comprender los siguientes términos:

Suceso
Un suceso es el informe del estado de una entidad como, por ejemplo, un pod, una reclamación de volumen persistente (PVC) u otro recurso.
severity
La gravedad del suceso indica si el suceso es crítico. La gravedad de un suceso puede ser: Crítico, Aviso o Información. Cada tipo de suceso incluye metadatos para el suceso, incluyendo una descripción y pasos para resolver el suceso.
crítico
Los recursos supervisados son inestables. Es esencial generar una alerta si este estado persiste.
aviso
Los recursos supervisados han alcanzado un umbral de alerta. Es posible que no sean necesarias alertas inmediatas.
info
Los recursos supervisados se comportan según lo esperado. Solo mensajes informativos.
alerta
Una alerta es un suceso que indica un problema o un problema potencial. Las alertas se pueden enviar utilizando condiciones de excepción (SNMP) o correo electrónico (SMTP). Cada tipo de alerta se puede asociar con diferentes reglas de alertas. Por ejemplo, un tipo de alerta puede alertar inmediatamente, o esperar a que se produzca un suceso antes de que el emisor de alertas envíe una alerta.
Cuota
Una cuota para un recurso como, por ejemplo, vCPU y memoria, es un destino que determina la gravedad de una alerta. Si el uso de recursos excede una cuota, el suceso se considera crítico. Si el uso de recursos excede el porcentaje de la cuota que define el umbral de alerta, el suceso se considera un aviso.
Supervisor
Un supervisor es un script cuya finalidad es comprobar periódicamente el estado de una entidad y generar sucesos. Un único supervisor puede registrar sucesos con diferentes fines. Por ejemplo, el monitor de plataforma que viene con IBM Software Hub genera eventos para comprobar el estado de las reclamaciones de volumen persistente, StatefulSets, y las implementaciones.
gestor de alertas de vigilancia
Un WAM (Watchdog Alert Manager) supervisa todos los supervisores para asegurarse de que se ejecutan en una planificación. WAM también expone una API que escucha los sucesos que generan los supervisores. Estos sucesos persisten en Metastore para generar alertas cuando se cumplen las reglas de alerta. También se pueden utilizar los sucesos persistentes también para estudiar patrones históricos. Para obtener más información, consulte las API de alerta.
Perfil de alertas
Un perfil de alerta define la configuración de la alerta. El perfil predeterminado habilita SMTP y SNMP.
reenviador de alertas
Un reenviador de alertas es el servicio responsable del envío de alertas y condiciones de excepción. Después de que el gestor de alertas de watchdog identifique una posible alerta, invoca el reenviador de alertas para que se envíen al entorno del cliente.

¿Cómo funciona?

Diagrama de flujo del marco de alerta
  1. El trabajo cron del gestor de alertas watchdog se repite por las extensiones para el tipo de extensión zen_alert_monitor y crea trabajos cron para los supervisores con los metadatos proporcionados. Utiliza métricas del producto como políticas de entrada y actualizaciones en Metastore.
  2. La tarea programada supervisa los eventos mediante la v1/monitoring/events API.
  3. El suceso se almacena en la base de datos Metastore. Por ejemplo:
    Monitor_type Event_type Reference Alerted_time Metadatos Gravedad Historial
    diagnósticos check-pvc-status zen-metastore-edb-1 NOT_ALERTED {Metadata about the resource} info 
    {
“time”:”critical/warning/info”,
}
    diagnósticos check-quota-status IBM Knowledge Catalog 08-23-2020:05:03:00 {Metadata about the resource} crítico 
    {
“time”:”critical/warning/info”,
}

    Si los mismos monitor, event_type y reference informan de otro suceso, el registro se actualiza con los últimos metadatos y en la columna de historial se anota la gravedad del suceso y la hora.

  4. El monitor de la plataforma se ejecuta cada 10 minutos y comprueba el estado de los PVC y los pods.
  5. El trabajo cron de alerta se ejecuta cada 10 minutos, comprobando si hay alertas posibles utilizando cuotas y umbrales para determinar la gravedad de la alerta. El trabajo cron de supervisión de watchdog pasa comprueba todos los sucesos de la base de datos Metastore para ver si hay sucesos con una gravedad crítica o de aviso. Dependiendo del número necesario para cumplir con una condición de alerta, que se define mediante las reglas establecidas para alert_type y la gravedad correspondiente, las alertas se envían o se posponen hasta que se cumplan las condiciones.
  6. El administrador puede cambiar las cuotas, los umbrales y el nivel de flexibilidad que desea para el sistema cuando se alcanzan las cuotas. Estos cambios se notifican de forma inmediata a la infraestructura de alertas. Para obtener más información, consulte Supervisión de la plataforma.

Más información