O desenvolvemento industrial de sistemas de software require unha gran atención á tolerancia a fallos do produto final, así como unha resposta rápida aos fallos e fallos se se producen. O seguimento, por suposto, axuda a responder aos fallos e fallos de forma máis eficiente e rápida, pero non o suficiente. En primeiro lugar, é moi difícil facer un seguimento dun gran número de servidores: é necesario un gran número de persoas. En segundo lugar, debes ter unha boa comprensión de como funciona a aplicación para predicir o seu estado. Polo tanto, necesitamos moita xente que teña unha boa comprensión dos sistemas que estamos a desenvolver, o seu rendemento e as súas características. Supoñamos que aínda que atopes suficientes persoas dispostas a facelo, aínda leva moito tempo adestralos.
Que facer? Aquí é onde a intelixencia artificial vén na nosa axuda. O artigo vai falar (mantemento preditivo). Este enfoque está gañando popularidade activamente. Escribiuse un gran número de artigos, entre eles sobre Habré. As grandes empresas fan pleno uso deste enfoque para manter o rendemento dos seus servidores. Despois de estudar un gran número de artigos, decidimos probar este enfoque. Que saíu?
Introdución
O sistema de software desenvolvido tarde ou cedo entra en funcionamento. É importante para o usuario que o sistema funcione sen fallos. Se se produce unha emerxencia, debe resolverse coa mínima demora.
Para simplificar o soporte técnico dun sistema de software, especialmente se hai moitos servidores, adoitan utilizarse programas de monitorización que toman métricas dun sistema de software en execución, permiten diagnosticar o seu estado e axudan a determinar o que causou exactamente o fallo. Este proceso chámase monitorización do sistema de software.
Figura 1. Interface de monitorización de Grafana
As métricas son varios indicadores dun sistema de software, o seu entorno de execución ou o ordenador físico baixo o que se está a executar o sistema cunha marca de tempo do momento en que se recibiron as métricas. Na análise estática, estas métricas chámanse series temporais. Para supervisar o estado do sistema de software, as métricas móstranse en forma de gráficos: o tempo está no eixe X e os valores están ao longo do eixe Y (Figura 1). Pódense tomar varios miles de métricas dun sistema de software en execución (de cada nodo). Forman un espazo de métricas (serie temporal multidimensional).
Dado que se recollen un gran número de métricas para sistemas de software complexos, o seguimento manual convértese nunha tarefa difícil. Para reducir a cantidade de datos analizados polo administrador, as ferramentas de seguimento conteñen ferramentas para identificar automaticamente posibles problemas. Por exemplo, pode configurar un disparador para que se active cando o espazo libre no disco caia por debaixo dun limiar especificado. Tamén pode diagnosticar automaticamente un apagado do servidor ou unha desaceleración crítica da velocidade do servizo. Na práctica, as ferramentas de vixilancia fan un bo traballo para detectar fallos que xa se produciron ou identificar síntomas simples de fallos futuros, pero en xeral, prever un posible fallo segue sendo unha porca difícil de romper para eles. A predición mediante a análise manual das métricas require a participación de especialistas cualificados. É de baixa produtividade. A maioría dos posibles fallos poden pasar desapercibidos.
Recentemente, o chamado mantemento preditivo dos sistemas de software fíxose cada vez máis popular entre as grandes empresas de desenvolvemento de software de TI. A esencia deste enfoque é atopar problemas que levan á degradación do sistema nas primeiras etapas, antes de que falle, utilizando intelixencia artificial. Este enfoque non exclúe completamente o seguimento manual do sistema. É auxiliar do proceso de seguimento no seu conxunto.
A principal ferramenta para implementar o mantemento preditivo é a tarefa de buscar anomalías en series temporais, xa que cando se produce unha anomalía nos datos hai unha alta probabilidade de que despois dun tempo haberá un fracaso ou fracaso. Unha anomalía é unha certa desviación no rendemento dun sistema de software, como identificar a degradación na velocidade de execución dun tipo de solicitude ou unha diminución do número medio de solicitudes atendidas nun nivel constante de sesións do cliente.
A tarefa de buscar anomalías para sistemas de software ten as súas propias especificidades. En teoría, para cada sistema de software é necesario desenvolver ou perfeccionar os métodos existentes, xa que a busca de anomalías é moi dependente dos datos nos que se realiza, e os datos dos sistemas de software varían moito en función das ferramentas de implantación do sistema. , ata o ordenador no que se está a executar.
Métodos de busca de anomalías á hora de prever fallos dos sistemas de software
En primeiro lugar, vale a pena dicir que a idea de prever fallos inspirouse no artigo . Para probar a eficacia do enfoque coa busca automática de anomalías, optouse polo sistema de software Web-Consolidation, que é un dos proxectos da empresa NPO Krista. Previamente realizouse un seguimento manual do mesmo en función das métricas recibidas. Dado que o sistema é bastante complexo, tómanse un gran número de métricas para iso: indicadores JVM (carga do colector de lixo), indicadores do SO baixo o que se executa o código (memoria virtual, % de carga da CPU do SO), indicadores de rede (carga da rede). ), o propio servidor (carga da CPU, memoria), as métricas de wildfly e as propias métricas da aplicación para todos os subsistemas críticos.
Todas as métricas son tomadas do sistema usando grafito. Inicialmente, a base de datos Whisper utilizouse como solución estándar para grafana, pero a medida que creceu a base de clientes, o grafito xa non puido facer fronte, esgotando a capacidade do subsistema de disco DC. Despois diso, decidiuse buscar unha solución máis eficaz. A elección foi a favor , o que permitiu reducir a carga do subsistema de disco nunha orde de magnitude e reducir o espazo de disco ocupado de cinco a seis veces. A continuación móstrase un diagrama do mecanismo para recoller métricas usando grafito+clickhouse (Figura 2).
Figura 2. Esquema de recollida de métricas
O diagrama está tomado da documentación interna. Mostra a comunicación entre grafana (a IU de monitorización que usamos) e grafito. A eliminación de métricas dunha aplicación realízase mediante un software separado: . Ponos en grafito.
O sistema de consolidación web ten unha serie de funcións que crean problemas para predicir fallos:
- A tendencia adoita cambiar. Existen varias versións dispoñibles para este sistema de software. Cada un deles trae cambios na parte de software do sistema. En consecuencia, deste xeito, os desenvolvedores inflúen directamente nas métricas dun sistema determinado e poden provocar un cambio de tendencia;
- a característica de implementación, así como os propósitos para os que os clientes usan este sistema, adoitan causar anomalías sen degradación previa;
- a porcentaxe de anomalías con respecto a todo o conxunto de datos é pequena (< 5%);
- Pode haber lagoas na recepción de indicadores do sistema. Nalgúns períodos curtos de tempo, o sistema de seguimento non consegue obter métricas. Por exemplo, se o servidor está sobrecargado. Isto é fundamental para adestrar unha rede neuronal. Hai que cubrir os ocos sintéticamente;
- Os casos con anomalías adoitan ser relevantes só para unha data/mes/hora específicos (estacionalidade). Este sistema ten unha normativa clara para o seu uso polos usuarios. En consecuencia, as métricas só son relevantes para un tempo específico. O sistema non se pode utilizar constantemente, senón só nalgúns meses: de forma selectiva segundo o ano. Xorden situacións nas que o mesmo comportamento das métricas nun caso pode levar a un fallo do sistema de software, pero non noutro.
Para comezar, analizáronse métodos para detectar anomalías nos datos de monitorización dos sistemas de software. Nos artigos sobre este tema, cando a porcentaxe de anomalías é pequena en relación ao resto do conxunto de datos, a maioría das veces proponse o uso de redes neuronais.
A lóxica básica para buscar anomalías usando datos da rede neuronal móstrase na Figura 3:
Figura 3. Busca de anomalías mediante unha rede neuronal
En función do resultado da previsión ou da restauración da xanela do fluxo actual de métricas, calcúlase a desviación da recibida do sistema de software en execución. Se hai unha gran diferenza entre as métricas obtidas do sistema de software e da rede neuronal, podemos concluír que o segmento de datos actual é anómalo. A seguinte serie de problemas xorden para o uso das redes neuronais:
- para funcionar correctamente no modo de transmisión, os datos para adestrar modelos de redes neuronais deben incluír só datos "normais";
- é necesario ter un modelo actualizado para a correcta detección. O cambio de tendencias e estacionalidade nas métricas pode provocar un gran número de falsos positivos no modelo. Para actualizalo, é necesario determinar claramente o momento no que o modelo está desactualizado. Se actualiza o modelo máis tarde ou antes, o máis probable é que siga un gran número de falsos positivos.
Tampouco debemos esquecernos de buscar e previr a frecuente aparición de falsos positivos. Suponse que a maioría das veces ocorrerán en situacións de emerxencia. Non obstante, tamén poden ser consecuencia dun erro da rede neuronal debido a un adestramento insuficiente. É necesario minimizar o número de falsos positivos do modelo. En caso contrario, as predicións falsas perderán moito tempo do administrador destinado a comprobar o sistema. Tarde ou cedo, o administrador simplemente deixará de responder ao sistema de vixilancia "paranoico".
Rede neuronal recorrente
Para detectar anomalías en series temporais, pode usar con memoria LSTM. O único problema é que só se pode usar para series de tempo previstas. No noso caso, non todas as métricas son previsibles. Na Figura 4 móstrase un intento de aplicar RNN LSTM a unha serie temporal.
Figura 4. Exemplo dunha rede neuronal recorrente con células de memoria LSTM
Como se pode ver na Figura 4, RNN LSTM foi capaz de facer fronte á busca de anomalías neste período de tempo. Cando o resultado ten un erro de predición elevado (erro medio), produciuse realmente unha anomalía nos indicadores. Usar un único RNN LSTM claramente non será suficiente, xa que é aplicable a un pequeno número de métricas. Pódese utilizar como método auxiliar para buscar anomalías.
Codificador automático para predicción de fallos
- esencialmente unha rede neuronal artificial. A capa de entrada é un codificador, a capa de saída é un decodificador. A desvantaxe de todas as redes neuronais deste tipo é que non localizan ben as anomalías. Elixiuse unha arquitectura de codificador automático síncrono.
Figura 5. Exemplo de funcionamento do autocodificador
Os codificadores automáticos son adestrados en datos normais e despois atopan algo anómalo nos datos que se alimentan ao modelo. Só o que necesitas para esta tarefa. Só queda escoller que codificador automático é axeitado para esta tarefa. A forma arquitectónicamente máis sinxela dun codificador automático é unha rede neuronal cara adiante e non retornable, que é moi semellante á (perceptrón multicapa, MLP), cunha capa de entrada, unha capa de saída e unha ou máis capas ocultas que as conectan.
Non obstante, as diferenzas entre os codificadores automáticos e os MLP son que nun codificador automático, a capa de saída ten o mesmo número de nós que a capa de entrada e que, en lugar de ser adestrada para predecir un valor obxectivo Y dado por unha entrada X, o codificador automático está adestrado. para reconstruír as súas propias X. Polo tanto, os Autoencoders son modelos de aprendizaxe sen supervisión.
A tarefa do autocodificador é atopar os índices de tempo r0 ... rn correspondentes aos elementos anómalos no vector de entrada X. Este efecto conséguese buscando o erro cadrado.
Figura 6. Autocodificador síncrono
Seleccionouse o codificador automático . As súas vantaxes: a capacidade de utilizar o modo de procesamento de streaming e un número relativamente menor de parámetros de rede neuronal en comparación con outras arquitecturas.
Mecanismo para minimizar os falsos positivos
Debido a que se producen diversas situacións anormais, así como unha posible situación de insuficiente adestramento da rede neuronal, para o modelo de detección de anomalías que se está a desenvolver, decidiuse que era necesario desenvolver un mecanismo para minimizar os falsos positivos. Este mecanismo baséase nunha base de modelos que é clasificada polo administrador.
(Algoritmo DTW, do inglés dynamic time warping) permítelle atopar a correspondencia óptima entre as secuencias de tempo. Úsase por primeira vez no recoñecemento de voz: úsase para determinar como dous sinais de fala representan a mesma frase falada orixinal. Posteriormente, atopouse a súa aplicación noutras áreas.
O principio fundamental de minimizar os falsos positivos é a recollida dunha base de datos de estándares coa axuda dun operador que clasifica os casos sospeitosos detectados mediante redes neuronais. A continuación, compárase o estándar clasificado co caso que detectou o sistema e tómase unha conclusión sobre se o caso é falso ou leva a un fallo. O algoritmo DTW úsase precisamente para comparar dúas series temporais. A principal ferramenta de minimización segue sendo a clasificación. Espérase que despois de recoller un gran número de casos de referencia, o sistema comece a preguntar menos ao operador debido á semellanza da maioría dos casos e á aparición de outros similares.
Como resultado, baseándose nos métodos de redes neuronais descritos anteriormente, construíuse un programa experimental para predicir fallos do sistema "Web-Consolidation". O obxectivo deste programa era, utilizando o arquivo existente de datos de seguimento e información sobre fallos anteriores, avaliar a competencia deste enfoque para os nosos sistemas de software. O esquema do programa preséntase a continuación na figura 7.
Figura 7. Esquema de predición de fallos baseado na análise do espazo métrico
No diagrama pódense distinguir dous bloques principais: a busca de períodos de tempo anómalos no fluxo de datos de seguimento (métricas) e o mecanismo para minimizar os falsos positivos. Nota: Para fins experimentais, os datos obtéñense mediante unha conexión JDBC da base de datos na que o grafito os gardará.
A continuación móstrase a interface do sistema de seguimento obtido como resultado do desenvolvemento (Figura 8).
Figura 8. Interface do sistema de seguimento experimental
A interface mostra a porcentaxe de anomalía en función das métricas recibidas. No noso caso, o recibo é simulado. Xa temos todos os datos dende hai varias semanas e imos cargando aos poucos para comprobar o caso dunha anomalía que provoca un fallo. A barra de estado inferior mostra a porcentaxe global de anomalía de datos nun momento determinado, que se determina mediante un codificador automático. Ademais, móstrase unha porcentaxe separada para as métricas previstas, que é calculada polo RNN LSTM.
Un exemplo de detección de anomalías baseada no rendemento da CPU mediante a rede neuronal RNN LSTM (Figura 9).
Figura 9. Descubrimento de RNN LSTM
Un caso bastante sinxelo, esencialmente un valor atípico común, pero que leva a un fallo do sistema, calculouse con éxito usando RNN LSTM. O indicador de anomalía neste período de tempo é do 85-95%; todo por riba do 80% (o limiar determinouse experimentalmente) considérase unha anomalía.
Un exemplo de detección de anomalías cando o sistema non puido iniciarse despois dunha actualización. Esta situación é detectada polo autocodificador (Figura 10).
Figura 10. Exemplo de detección de autocodificador
Como podes ver na figura, PermGen está atrapado nun nivel. O codificador automático atopou isto estraño porque nunca antes vira nada semellante. Aquí a anomalía permanece ao 100% ata que o sistema volva a funcionar. Móstrase unha anomalía para todas as métricas. Como se mencionou anteriormente, o codificador automático non pode localizar anomalías. O operador está chamado a realizar esta función nestas situacións.
Conclusión
PC "Web-Consolidation" estivo en desenvolvemento durante varios anos. O sistema atópase nun estado bastante estable e o número de incidentes rexistrados é pequeno. Non obstante, foi posible atopar anomalías que provocaron un fallo 5 - 10 minutos antes de que ocorrese o fallo. Nalgúns casos, a notificación dunha avaría con antelación axudaría a aforrar o tempo programado que se destina á realización de traballos de "reparación".
A partir dos experimentos que se realizaron, é demasiado pronto para sacar conclusións finais. Ata agora, os resultados son conflitivos. Por unha banda, está claro que os algoritmos baseados en redes neuronais son capaces de atopar anomalías "útiles". Por outra banda, permanece unha gran porcentaxe de falsos positivos, e non se poden detectar todas as anomalías detectadas por un especialista cualificado nunha rede neuronal. As desvantaxes inclúen o feito de que agora a rede neuronal require formación cun profesor para o funcionamento normal.
Para seguir desenvolvendo o sistema de predición de fallos e levalo a un estado satisfactorio, pódense contemplar varias formas. Trátase dunha análise máis detallada dos casos con anomalías que conducen ao fallo, debido a esta incorporación á lista de métricas importantes que inflúen moito no estado do sistema, e ao descarte das innecesarias que non o afectan. Ademais, se nos movemos nesta dirección, podemos facer intentos de especializar algoritmos especificamente para os nosos casos con anomalías que leven a fallos. Hai outro xeito. Esta é unha mellora nas arquitecturas de redes neuronais e, polo tanto, aumenta a precisión da detección cunha redución do tempo de adestramento.
Expreso o meu agradecemento aos meus compañeiros que me axudaron a escribir e manter a relevancia deste artigo: e Sergei Finogenov.
Fonte: www.habr.com