El desarrollo industrial de sistemas de software requiere gran atención a la tolerancia a fallas del producto final, así como una respuesta rápida a las fallas y fallas si ocurren. El seguimiento, por supuesto, ayuda a responder a fallos y fallos de forma más eficiente y rápida, pero no lo suficiente. En primer lugar, es muy difícil realizar un seguimiento de una gran cantidad de servidores: se necesita una gran cantidad de personas. En segundo lugar, es necesario comprender bien cómo funciona la aplicación para poder predecir su estado. Por lo tanto, necesitamos mucha gente que comprenda bien los sistemas que estamos desarrollando, su rendimiento y sus características. Supongamos que incluso si encuentra suficientes personas dispuestas a hacer esto, todavía lleva mucho tiempo capacitarlos.
¿Qué hacer? Aquí es donde la inteligencia artificial viene en nuestra ayuda. El artículo hablará sobre (mantenimiento predictivo). Este enfoque está ganando popularidad activamente. Se han escrito una gran cantidad de artículos, incluso sobre Habré. Las grandes empresas aprovechan al máximo este enfoque para mantener el rendimiento de sus servidores. Después de estudiar una gran cantidad de artículos, decidimos probar este enfoque. ¿Qué resultó de esto?
introducción
El sistema de software desarrollado tarde o temprano entra en funcionamiento. Es importante para el usuario que el sistema funcione sin fallos. Si ocurre una emergencia, debe resolverse con la mínima demora.
Para simplificar el soporte técnico de un sistema de software, especialmente si hay muchos servidores, generalmente se utilizan programas de monitoreo que toman métricas de un sistema de software en ejecución, permiten diagnosticar su condición y ayudan a determinar qué causó exactamente la falla. Este proceso se llama monitoreo del sistema de software.
Figura 1. Interfaz de monitoreo de Grafana
Las métricas son varios indicadores de un sistema de software, su entorno de ejecución o la computadora física bajo la cual se ejecuta el sistema con una marca de tiempo del momento en que se recibieron las métricas. En el análisis estático, estas métricas se denominan series de tiempo. Para monitorear el estado del sistema de software, las métricas se muestran en forma de gráficos: el tiempo está en el eje X y los valores a lo largo del eje Y (Figura 1). Se pueden tomar varios miles de métricas de un sistema de software en ejecución (de cada nodo). Forman un espacio de métricas (series de tiempo multidimensionales).
Dado que se recopila una gran cantidad de métricas para sistemas de software complejos, el monitoreo manual se convierte en una tarea difícil. Para reducir la cantidad de datos analizados por el administrador, las herramientas de monitoreo contienen herramientas para identificar automáticamente posibles problemas. Por ejemplo, puede configurar un activador para que se active cuando el espacio libre en el disco caiga por debajo de un umbral específico. También puede diagnosticar automáticamente un apagado del servidor o una desaceleración crítica en la velocidad del servicio. En la práctica, las herramientas de monitoreo hacen un buen trabajo al detectar fallas que ya han ocurrido o identificar síntomas simples de fallas futuras, pero en general, predecir una posible falla sigue siendo un hueso duro de roer para ellos. La predicción mediante análisis manual de métricas requiere la participación de especialistas cualificados. Es baja productividad. La mayoría de los posibles fallos pueden pasar desapercibidos.
Recientemente, el llamado mantenimiento predictivo de sistemas de software se ha vuelto cada vez más popular entre las grandes empresas de desarrollo de software de TI. La esencia de este enfoque es encontrar problemas que conduzcan a la degradación del sistema en las primeras etapas, antes de que falle, utilizando inteligencia artificial. Este enfoque no excluye por completo el control manual del sistema. Es auxiliar al proceso de seguimiento en su conjunto.
La principal herramienta para implementar el mantenimiento predictivo es la tarea de buscar anomalías en series temporales, ya que cuando ocurre una anomalía en los datos hay una alta probabilidad de que después de algún tiempo habrá un fracaso o fracaso. Una anomalía es una determinada desviación en el rendimiento de un sistema de software, como identificar una degradación en la velocidad de ejecución de un tipo de solicitud o una disminución en el número promedio de solicitudes atendidas en un nivel constante de sesiones de clientes.
La tarea de buscar anomalías en los sistemas de software tiene sus propias particularidades. En teoría, para cada sistema de software es necesario desarrollar o perfeccionar los métodos existentes, ya que la búsqueda de anomalías depende en gran medida de los datos en los que se realiza, y los datos de los sistemas de software varían mucho según las herramientas para implementar el sistema. , hasta en qué computadora se está ejecutando.
Métodos para buscar anomalías al predecir fallas de sistemas de software.
En primer lugar, cabe decir que la idea de predecir fallos se inspiró en el artículo. . Para probar la eficacia del enfoque con búsqueda automática de anomalías, se eligió el sistema de software Web-Consolidation, que es uno de los proyectos de la empresa NPO Krista. Anteriormente se realizaba un seguimiento manual del mismo en función de las métricas recibidas. Dado que el sistema es bastante complejo, se toman una gran cantidad de métricas: indicadores JVM (carga del recolector de basura), indicadores del sistema operativo bajo el cual se ejecuta el código (memoria virtual,% de carga de CPU del sistema operativo), indicadores de red (carga de red ), el servidor en sí (carga de CPU, memoria), métricas wildfly y las métricas propias de la aplicación para todos los subsistemas críticos.
Todas las métricas se toman del sistema utilizando grafito. Inicialmente, la base de datos Whisper se utilizó como solución estándar para Grafana, pero a medida que la base de clientes creció, Graphite ya no pudo hacer frente, habiendo agotado la capacidad del subsistema de disco DC. Después de esto, se decidió buscar una solución más eficaz. La elección se hizo a favor , lo que permitió reducir la carga en el subsistema de disco en un orden de magnitud y reducir el espacio ocupado en disco de cinco a seis veces. A continuación se muestra un diagrama del mecanismo para recopilar métricas utilizando Graphite+clickhouse (Figura 2).
Figura 2. Esquema de recopilación de métricas
El diagrama está tomado de la documentación interna. Muestra la comunicación entre grafana (la interfaz de usuario de monitoreo que usamos) y grafito. La eliminación de métricas de una aplicación se realiza mediante un software independiente: . Los pone en grafito.
El sistema de consolidación web tiene una serie de características que crean problemas para predecir fallas:
- La tendencia cambia a menudo. Hay varias versiones disponibles para este sistema de software. Cada uno de ellos trae cambios a la parte de software del sistema. En consecuencia, de esta manera, los desarrolladores influyen directamente en las métricas de un sistema determinado y pueden provocar un cambio de tendencia;
- la característica de implementación, así como los fines para los cuales los clientes utilizan este sistema, a menudo causan anomalías sin degradación previa;
- el porcentaje de anomalías en relación con todo el conjunto de datos es pequeño (< 5%);
- Puede haber lagunas en la recepción de indicadores del sistema. En algunos períodos cortos de tiempo, el sistema de seguimiento no logra obtener métricas. Por ejemplo, si el servidor está sobrecargado. Esto es fundamental para entrenar una red neuronal. Es necesario llenar los vacíos sintéticamente;
- Los casos con anomalías a menudo son relevantes solo para una fecha/mes/hora específica (estacionalidad). Este sistema cuenta con regulaciones claras para su uso por parte de los usuarios. En consecuencia, las métricas son relevantes sólo para un momento específico. El sistema no se puede utilizar constantemente, sino sólo algunos meses: de forma selectiva según el año. Surgen situaciones en las que el mismo comportamiento de las métricas en un caso puede provocar un fallo del sistema de software, pero no en otro.
Para empezar, se analizaron métodos para detectar anomalías en los datos de seguimiento de los sistemas de software. En los artículos sobre este tema, cuando el porcentaje de anomalías es pequeño en relación con el resto del conjunto de datos, se propone con mayor frecuencia utilizar redes neuronales.
La lógica básica para buscar anomalías utilizando datos de redes neuronales se muestra en la Figura 3:
Figura 3. Búsqueda de anomalías mediante una red neuronal
Con base en el resultado del pronóstico o restauración de la ventana del flujo actual de métricas, se calcula la desviación de la recibida del sistema de software en ejecución. Si hay una gran diferencia entre las métricas obtenidas del sistema de software y la red neuronal, podemos concluir que el segmento de datos actual es anómalo. Para el uso de redes neuronales surgen la siguiente serie de problemas:
- para funcionar correctamente en modo streaming, los datos para entrenar modelos de redes neuronales deben incluir sólo datos "normales";
- es necesario disponer de un modelo actualizado para su correcta detección. Las tendencias cambiantes y la estacionalidad en las métricas pueden provocar una gran cantidad de falsos positivos en el modelo. Para actualizarlo, es necesario determinar claramente el momento en que el modelo queda desactualizado. Si actualiza el modelo más tarde o antes, lo más probable es que se produzcan una gran cantidad de falsos positivos.
Tampoco debemos olvidarnos de buscar y prevenir la frecuente aparición de falsos positivos. Se supone que ocurrirán con mayor frecuencia en situaciones de emergencia. Sin embargo, también pueden ser consecuencia de un error de la red neuronal debido a un entrenamiento insuficiente. Es necesario minimizar el número de falsos positivos del modelo. De lo contrario, las predicciones falsas harán perder mucho tiempo al administrador destinado a comprobar el sistema. Tarde o temprano, el administrador simplemente dejará de responder al sistema de monitoreo "paranoico".
Red neuronal recurrente
Para detectar anomalías en series de tiempo, puede utilizar con memoria LSTM. El único problema es que sólo se puede utilizar para series temporales previstas. En nuestro caso, no todas las métricas son predecibles. En la Figura 4 se muestra un intento de aplicar RNN LSTM a una serie de tiempo.
Figura 4. Ejemplo de una red neuronal recurrente con celdas de memoria LSTM
Como puede verse en la Figura 4, RNN LSTM pudo hacer frente a la búsqueda de anomalías en este período de tiempo. Cuando el resultado tiene un error de predicción alto (error medio), en realidad se ha producido una anomalía en los indicadores. Usar un solo RNN LSTM claramente no será suficiente, ya que es aplicable a una pequeña cantidad de métricas. Puede utilizarse como método auxiliar para buscar anomalías.
Codificador automático para predicción de fallos
– esencialmente una red neuronal artificial. La capa de entrada es codificadora, la capa de salida es decodificadora. La desventaja de todas las redes neuronales de este tipo es que no localizan bien las anomalías. Se eligió una arquitectura de codificador automático síncrono.
Figura 5. Ejemplo de funcionamiento del codificador automático
Los codificadores automáticos se entrenan con datos normales y luego encuentran algo anómalo en los datos introducidos en el modelo. Justo lo que necesitas para esta tarea. Todo lo que queda es elegir qué codificador automático es adecuado para esta tarea. La forma arquitectónicamente más simple de un codificador automático es una red neuronal directa y sin retorno, que es muy similar a (perceptrón multicapa, MLP), con una capa de entrada, una capa de salida y una o más capas ocultas que las conectan.
Sin embargo, las diferencias entre los codificadores automáticos y los MLP son que en un codificador automático, la capa de salida tiene la misma cantidad de nodos que la capa de entrada y que, en lugar de estar entrenado para predecir un valor objetivo Y dado por una entrada X, el codificador automático está entrenado. para reconstruir sus propias X. Por lo tanto, los codificadores automáticos son modelos de aprendizaje no supervisados.
La tarea del codificador automático es encontrar los índices de tiempo r0 ... rn correspondientes a los elementos anómalos en el vector de entrada X. Este efecto se logra buscando el error al cuadrado.
Figura 6. Codificador automático síncrono
Para el codificador automático se seleccionó . Sus ventajas: la capacidad de utilizar el modo de procesamiento de transmisión y una cantidad relativamente menor de parámetros de red neuronal en comparación con otras arquitecturas.
Mecanismo para minimizar falsos positivos
Debido a que surgen diversas situaciones anormales, así como una posible situación de entrenamiento insuficiente de la red neuronal, para el modelo de detección de anomalías que se está desarrollando se decidió que era necesario desarrollar un mecanismo para minimizar los falsos positivos. Este mecanismo se basa en una base de plantillas que es clasificada por el administrador.
(Algoritmo DTW, del inglés Dynamic Time Warping) le permite encontrar la correspondencia óptima entre secuencias de tiempo. Utilizado por primera vez en reconocimiento de voz: se utiliza para determinar cómo dos señales de voz representan la misma frase hablada original. Posteriormente se le encontró aplicación en otras áreas.
El principio fundamental para minimizar los falsos positivos es recopilar una base de datos de estándares con la ayuda de un operador que clasifica los casos sospechosos detectados mediante redes neuronales. A continuación, se compara el estándar clasificado con el caso que detectó el sistema y se llega a una conclusión sobre si el caso es falso o conduce a una falla. El algoritmo DTW se utiliza precisamente para comparar dos series temporales. La principal herramienta de minimización sigue siendo la clasificación. Se espera que después de recopilar una gran cantidad de casos de referencia, el sistema comience a preguntar menos al operador debido a la similitud de la mayoría de los casos y la aparición de otros similares.
Como resultado, basándose en los métodos de redes neuronales descritos anteriormente, se construyó un programa experimental para predecir fallas del sistema "Web-Consolidation". El objetivo de este programa era, utilizando el archivo existente de datos de monitoreo e información sobre fallas anteriores, evaluar la competencia de este enfoque para nuestros sistemas de software. El esquema del programa se presenta a continuación en la Figura 7.
Figura 7. Esquema de predicción de fallas basado en análisis de espacio métrico
En el diagrama se pueden distinguir dos bloques principales: la búsqueda de periodos de tiempo anómalos en el flujo de datos de seguimiento (métricas) y el mecanismo de minimización de falsos positivos. Nota: Para fines experimentales, los datos se obtienen a través de una conexión JDBC desde la base de datos en la que Graphite los guardará.
La siguiente es la interfaz del sistema de monitoreo obtenida como resultado del desarrollo (Figura 8).
Figura 8. Interfaz del sistema de seguimiento experimental.
La interfaz muestra el porcentaje de anomalía según las métricas recibidas. En nuestro caso, el recibo es simulado. Ya tenemos todos los datos desde hace varias semanas y los estamos cargando poco a poco para comprobar el caso de alguna anomalía que conduzca al fallo. La barra de estado inferior muestra el porcentaje general de anomalías de datos en un momento dado, que se determina mediante un codificador automático. Además, se muestra un porcentaje separado para las métricas previstas, que calcula RNN LSTM.
Un ejemplo de detección de anomalías basada en el rendimiento de la CPU utilizando la red neuronal RNN LSTM (Figura 9).
Figura 9. Descubrimiento de RNN LSTM
Se calculó con éxito un caso bastante simple, esencialmente un valor atípico común, pero que provocó una falla del sistema, utilizando RNN LSTM. El indicador de anomalía en este período de tiempo es del 85 al 95%; todo lo que esté por encima del 80% (el umbral se determinó experimentalmente) se considera una anomalía.
Un ejemplo de detección de anomalía cuando el sistema no pudo iniciar después de una actualización. Esta situación es detectada por el codificador automático (Figura 10).
Figura 10. Ejemplo de detección de codificador automático
Como puede ver en la figura, PermGen está estancado en un nivel. El codificador automático encontró esto extraño porque nunca antes había visto algo así. Aquí la anomalía permanece del 100% hasta que el sistema vuelve a funcionar. Se muestra una anomalía para todas las métricas. Como se mencionó anteriormente, el codificador automático no puede localizar anomalías. En estas situaciones, el operador está llamado a realizar esta función.
Conclusión
La PC "Web-Consolidation" lleva varios años en desarrollo. El sistema se encuentra en un estado bastante estable y el número de incidentes registrados es pequeño. Sin embargo, fue posible encontrar anomalías que provocaron fallas entre 5 y 10 minutos antes de que ocurriera la falla. En algunos casos, la notificación de una falla con anticipación ayudaría a ahorrar el tiempo programado asignado para realizar el trabajo de “reparación”.
Sobre la base de los experimentos que se llevaron a cabo, es demasiado pronto para sacar conclusiones definitivas. Hasta ahora, los resultados son contradictorios. Por un lado, está claro que los algoritmos basados en redes neuronales son capaces de encontrar anomalías “útiles”. Por otro lado, sigue habiendo un gran porcentaje de falsos positivos y no todas las anomalías detectadas por un especialista cualificado en una red neuronal pueden ser detectadas. Las desventajas incluyen el hecho de que ahora la red neuronal requiere entrenamiento por parte de un maestro para su funcionamiento normal.
Para seguir desarrollando el sistema de predicción de fallos y llevarlo a un estado satisfactorio, se pueden considerar varias formas. Se trata de un análisis más detallado de casos con anomalías que conducen al fallo, debido a que se añaden a la lista métricas importantes que influyen mucho en el estado del sistema, y se descartan aquellas innecesarias que no lo afectan. Además, si avanzamos en esta dirección, podemos intentar especializar algoritmos específicamente para nuestros casos con anomalías que conduzcan a fallos. Hay otra manera. Esta es una mejora en las arquitecturas de redes neuronales y, por lo tanto, aumenta la precisión de la detección con una reducción en el tiempo de entrenamiento.
Expreso mi gratitud a mis colegas que me ayudaron a escribir y mantener la relevancia de este artículo: y Serguéi Finógenov.
Fuente: habr.com