Alarma de datos de base de datos liviana y no intrusiva basada en SpringBoot

"Por la noche, te sientas bajo los aleros, observas cómo el cielo se oscurece lentamente, te sientes solo y desolado, sientes que te han privado de la vida. Yo era un hombre joven en ese momento, pero Tenía miedo de vivir así. Continuar y envejecer. En mi opinión, esto es más aterrador que la muerte --------Wang Xiaobo"

Necesito escribir un dispositivo de alarma para los datos de la base de datos. monitoreo, requisitos:

En general, la lógica es muy simple y no hay dificultades técnicas. Es una reinvención repetitiva de la rueda considerando la necesidad de analizar archivos de configuración, múltiples configuraciones de fuentes de datos, tareas programadas. etc., se utiliza SpringBoot y se utiliza su configuración automatizada. Tipo Con las ventajas de los atributos de configuración seguros y la programación de tareas simple integrada, puede configurar fácilmente diferentes fuentes de datos, inyectar datos de archivos de configuración complejos en beans y configurar dinámicamente planes de tiempo. /p>

Acerca de la configuración de fuentes de datos múltiples y los atributos de configuración de tipo seguro no son el tema central de este artículo, por lo que no entraré en detalles aquí.

La construcción de la clase de alarma consta de dos partes: inicialización y generación de reglas de alarma. La inicialización es responsable de cargar, analizar y verificar el archivo de configuración de alarma, y ​​la generación de reglas de alarma es responsable del establecimiento de la misma. proceso de alarma.

Aquí puede utilizar las reglas de inicialización predeterminadas y los procedimientos de análisis de alarmas, o puede utilizar reglas personalizadas. La codificación general se basa en el patrón de diseño del constructor, que es similar a la construcción de los objetos de configuración de Spring Security

Puede utilizar el proceso de análisis de alarmas predeterminado y el método de llamada

o

también El proceso de análisis de alarmas se puede personalizar aquí. Aquí se adopta la idea de programación funcional, y el proceso de análisis de alarmas se puede escribir dinámicamente mediante parametrización de comportamiento.

Con respecto al proceso de alarma, aquí combinamos el método de configuración de alarma de monitoreo de zabbix para abstraer activadores, acciones, medios de alarma, plantillas de mensajes de alarma, inserción de tablas SQL y otros comportamientos. Todo el comportamiento del proceso de alarma se configura a través de. archivo de configuración. La generación de reglas de alarma y la generación de reglas de alarma en la construcción del dispositivo de alarma anterior están integradas en un proceso completo.

Veamos varios escenarios específicos a través de archivos de configuración.

Escenarios de monitoreo de actividad: aplicables a datos para algunas tareas de procesamiento por lotes. Utilice la condición Where para determinar si hay datos que no cumplen. el estado esperado. Luego obtenga el identificador único de esta parte de los datos y genere un mensaje de alarma para enviar.

Escenario de verificación de tabla vacía: aplicable a algunas tablas de períodos de cuentas, los datos saldrán de la tabla en determinados momentos. Utilice la condición donde para determinar si existen datos. Si no, seleccione 'Los datos de la tabla XXX están vacíos. ' como código Método para construir un mensaje de alarma, se produce un mensaje de alarma

Escenario de monitoreo de tablas grandes: aplicable a algunas tablas grandes Cuando el volumen de datos alcanza un cierto pico, afectará el rendimiento del sistema, el tiempo de espera de SQL e incluso. Pérdida parcial de datos persistente. Es necesario realizar una copia de seguridad y limpieza de los datos redundantes. Se requiere alerta temprana.

Con respecto al problema de las alarmas repetidas, se ha integrado H2, pero actualmente la cantidad de datos de alarma es pequeña, por lo que no se usa para alarmas repetidas, se usa WeakHashMap para construir. Implementación de clase de herramienta de caché de clave débil.

Después de que se activa la primera alarma, se almacena en la memoria caché. El mensaje de alarma no se enviará dentro de las 2 horas posteriores a que se active la alarma. Se enviará una vez cada 2 horas.

La configuración dinámica se implementa a través de la clase de configuración SchedulingConfigurer. El archivo de configuración obtiene una expresión cron

DynamicCronSchedule.java