El desenvolupament industrial de sistemes de programari requereix una gran atenció a la tolerància a errors del producte final, així com una resposta ràpida als errors i errors si es produeixen. La supervisió, per descomptat, ajuda a respondre a fallades i fallades de manera més eficient i ràpida, però no prou. En primer lloc, és molt difícil fer un seguiment d'un gran nombre de servidors: es necessita un gran nombre de persones. En segon lloc, cal tenir una bona comprensió de com funciona l'aplicació per predir el seu estat. Per tant, necessitem molta gent que conegui bé els sistemes que estem desenvolupant, el seu rendiment i les seves característiques. Suposem que encara que trobeu prou gent disposada a fer-ho, encara trigarà molt de temps entrenar-los.
Què fer? Aquí és on la intel·ligència artificial ens ajuda. L'article en parlarà (manteniment predictiu). Aquest enfocament està guanyant popularitat activament. S'han escrit un gran nombre d'articles, inclòs sobre Habré. Les grans empreses fan un ús total d'aquest enfocament per mantenir el rendiment dels seus servidors. Després d'estudiar un gran nombre d'articles, vam decidir provar aquest enfocament. Què en va sortir?
Introducció
El sistema de programari desenvolupat, tard o d'hora, entra en funcionament. És important per a l'usuari que el sistema funcioni sense errors. Si es produeix una emergència, s'ha de resoldre amb un retard mínim.
Per simplificar l'assistència tècnica d'un sistema de programari, sobretot si hi ha molts servidors, s'acostumen a utilitzar programes de monitorització que prenen mètriques d'un sistema de programari en execució, permeten diagnosticar el seu estat i ajuden a determinar què ha causat exactament la fallada. Aquest procés s'anomena monitorització del sistema de programari.
Figura 1. Interfície de monitorització de Grafana
Les mètriques són diversos indicadors d'un sistema de programari, el seu entorn d'execució o l'ordinador físic en què s'executa el sistema amb una marca de temps del moment en què es van rebre les mètriques. En l'anàlisi estàtica, aquestes mètriques s'anomenen sèries temporals. Per controlar l'estat del sistema de programari, les mètriques es mostren en forma de gràfics: el temps es troba a l'eix X i els valors es troben al llarg de l'eix Y (figura 1). Es poden prendre diversos milers de mètriques d'un sistema de programari en execució (des de cada node). Formen un espai de mètriques (sèries temporals multidimensionals).
Com que es recullen un gran nombre de mètriques per a sistemes de programari complexos, la supervisió manual esdevé una tasca difícil. Per reduir la quantitat de dades analitzades per l'administrador, les eines de monitorització contenen eines per identificar automàticament possibles problemes. Per exemple, podeu configurar un activador per activar-se quan l'espai lliure en disc cau per sota d'un llindar especificat. També podeu diagnosticar automàticament un tancament del servidor o una desacceleració crítica de la velocitat del servei. A la pràctica, les eines de monitorització fan una bona feina per detectar fallades que ja s'han produït o per identificar símptomes simples de fallades futures, però, en general, predir una possible fallada segueix sent difícil de trencar per a ells. La predicció mitjançant l'anàlisi manual de mètriques requereix la participació d'especialistes qualificats. És de baixa productivitat. La majoria de possibles errors poden passar desapercebuts.
Recentment, l'anomenat manteniment predictiu de sistemes de programari s'ha fet cada cop més popular entre les grans empreses de desenvolupament de programari informàtic. L'essència d'aquest enfocament és trobar problemes que portin a la degradació del sistema en les primeres etapes, abans que falli, mitjançant la intel·ligència artificial. Aquest enfocament no exclou completament la supervisió manual del sistema. És auxiliar del procés de seguiment en el seu conjunt.
L'eina principal per implementar el manteniment predictiu és la tasca de cercar anomalies en sèries temporals, ja que quan es produeix una anomalia a les dades hi ha una gran probabilitat que després d'un temps hi haurà un fracàs o un fracàs. Una anomalia és una certa desviació en el rendiment d'un sistema de programari, com ara identificar la degradació en la velocitat d'execució d'un tipus de sol·licitud o una disminució del nombre mitjà de peticions ateses a un nivell constant de sessions de client.
La tasca de cercar anomalies per als sistemes de programari té les seves pròpies especificitats. En teoria, per a cada sistema de programari és necessari desenvolupar o perfeccionar mètodes existents, ja que la recerca d'anomalies depèn molt de les dades en què es realitza, i les dades dels sistemes de programari varien molt en funció de les eines per implementar el sistema. , fins a quin ordinador s'està executant.
Mètodes per a la recerca d'anomalies a l'hora de predir fallades dels sistemes de programari
En primer lloc, val la pena dir que la idea de predir falles es va inspirar en l'article . Per provar l'efectivitat de l'enfocament amb la cerca automàtica d'anomalies, es va escollir el sistema de programari Web-Consolidation, que és un dels projectes de l'empresa NPO Krista. Anteriorment, se n'havia realitzat un seguiment manual en funció de les mètriques rebudes. Com que el sistema és bastant complex, es prenen una gran quantitat de mètriques: indicadors de JVM (càrrega del col·lector d'escombraries), indicadors del sistema operatiu sota el qual s'executa el codi (memòria virtual, % de càrrega de CPU del sistema operatiu), indicadors de xarxa (càrrega de xarxa). ), el propi servidor (càrrega de la CPU, memòria), les mètriques Wildfly i les mètriques pròpies de l'aplicació per a tots els subsistemes crítics.
Totes les mètriques es prenen del sistema amb grafit. Inicialment, la base de dades de xiuxiueig es va utilitzar com a solució estàndard per a grafana, però a mesura que creixia la base de clients, el grafit ja no va poder fer front, havent esgotat la capacitat del subsistema de disc DC. Després d'això, es va decidir trobar una solució més eficaç. L'elecció es va fer a favor , que va permetre reduir la càrrega del subsistema de disc en un ordre de magnitud i reduir l'espai de disc ocupat de cinc a sis vegades. A continuació es mostra un diagrama del mecanisme per recopilar mètriques mitjançant grafit+clickhouse (figura 2).
Figura 2. Esquema de recollida de mètriques
El diagrama està extret de la documentació interna. Mostra la comunicació entre grafana (la interfície d'usuari de monitorització que fem servir) i grafit. L'eliminació de mètriques d'una aplicació es fa mitjançant un programari separat: . Els posa en grafit.
El sistema de consolidació web té una sèrie de funcions que creen problemes per predir errors:
- La tendència sovint canvia. Hi ha diverses versions disponibles per a aquest sistema de programari. Cadascun d'ells aporta canvis a la part de programari del sistema. En conseqüència, d'aquesta manera, els desenvolupadors influeixen directament en les mètriques d'un sistema determinat i poden provocar un canvi de tendència;
- la funció d'implementació, així com els propòsits per als quals els clients utilitzen aquest sistema, sovint provoquen anomalies sense degradació prèvia;
- el percentatge d'anomalies respecte a tot el conjunt de dades és petit (< 5%);
- Pot haver-hi llacunes en la recepció d'indicadors del sistema. En alguns períodes curts de temps, el sistema de monitorització no aconsegueix les mètriques. Per exemple, si el servidor està sobrecarregat. Això és fonamental per entrenar una xarxa neuronal. Cal omplir els buits de manera sintètica;
- Els casos amb anomalies solen ser rellevants només per a una data/mes/hora específics (estacionalitat). Aquest sistema té una normativa clara per al seu ús pels usuaris. En conseqüència, les mètriques només són rellevants per a un temps determinat. El sistema no es pot utilitzar constantment, sinó només en alguns mesos: de manera selectiva segons l'any. Es donen situacions quan el mateix comportament de mètriques en un cas pot provocar una fallada del sistema de programari, però no en un altre.
Per començar, s'han analitzat mètodes per detectar anomalies en les dades de monitoratge dels sistemes de programari. En articles sobre aquest tema, quan el percentatge d'anomalies és petit respecte a la resta del conjunt de dades, es proposa amb més freqüència utilitzar xarxes neuronals.
La lògica bàsica per a la cerca d'anomalies mitjançant dades de la xarxa neuronal es mostra a la figura 3:
Figura 3. Cerca d'anomalies mitjançant una xarxa neuronal
A partir del resultat de la previsió o la restauració de la finestra del flux actual de mètriques, es calcula la desviació de la rebuda del sistema de programari en execució. Si hi ha una gran diferència entre les mètriques obtingudes del sistema de programari i la xarxa neuronal, podem concloure que el segment de dades actual és anòmal. La següent sèrie de problemes sorgeixen per a l'ús de xarxes neuronals:
- per funcionar correctament en mode streaming, les dades per entrenar els models de xarxes neuronals només han d'incloure dades "normals";
- cal disposar d'un model actualitzat per a una correcta detecció. El canvi de tendències i l'estacionalitat de les mètriques pot provocar un gran nombre de falsos positius al model. Per actualitzar-lo, cal determinar clarament el moment en què el model està obsolet. Si actualitzeu el model més tard o abans, llavors, molt probablement, hi haurà un gran nombre de falsos positius.
Tampoc hem d'oblidar-nos de buscar i prevenir l'aparició freqüent de falsos positius. Se suposa que es produiran més sovint en situacions d'emergència. Tanmateix, també poden ser conseqüència d'un error de la xarxa neuronal a causa d'un entrenament insuficient. Cal minimitzar el nombre de falsos positius del model. En cas contrari, les prediccions falses faran perdre molt de temps de l'administrador per comprovar el sistema. Tard o d'hora, l'administrador deixarà de respondre al sistema de monitoratge "paranoic".
Xarxa neuronal recurrent
Per detectar anomalies en sèries temporals, podeu utilitzar amb memòria LSTM. L'únic problema és que només es pot utilitzar per a sèries temporals previstes. En el nostre cas, no totes les mètriques són predictibles. A la figura 4 es mostra un intent d'aplicar RNN LSTM a una sèrie temporal.
Figura 4. Exemple de xarxa neuronal recurrent amb cèl·lules de memòria LSTM
Com es pot veure a la figura 4, RNN LSTM va poder fer front a la recerca d'anomalies en aquest període de temps. Quan el resultat té un error de predicció elevat (error mitjà), realment s'ha produït una anomalia en els indicadors. L'ús d'un únic RNN LSTM clarament no serà suficient, ja que és aplicable a un nombre reduït de mètriques. Es pot utilitzar com a mètode auxiliar per a la recerca d'anomalies.
Autoencoder per a la predicció de fallades
- essencialment una xarxa neuronal artificial. La capa d'entrada és un codificador, la capa de sortida és un descodificador. El desavantatge de totes les xarxes neuronals d'aquest tipus és que no localitzen bé les anomalies. Es va escollir una arquitectura de codificació automàtica síncrona.
Figura 5. Exemple de funcionament del codificador automàtic
Els codificadors automàtics s'entrenen amb dades normals i després troben alguna cosa anòmala a les dades introduïdes al model. Just el que necessites per a aquesta tasca. Només queda triar quin codificador automàtic és adequat per a aquesta tasca. La forma arquitectònicament més senzilla d'un codificador automàtic és una xarxa neuronal cap endavant i sense retorn, que és molt similar a (perceptró multicapa, MLP), amb una capa d'entrada, una capa de sortida i una o més capes ocultes que les connecten.
No obstant això, les diferències entre els codificadors automàtics i els MLP són que en un codificador automàtic, la capa de sortida té el mateix nombre de nodes que la capa d'entrada i que, en lloc d'estar entrenat per predir un valor objectiu Y donat per una entrada X, l'autocodificador està entrenat. per reconstruir les seves pròpies X. Per tant, els Autoencoders són models d'aprenentatge no supervisat.
La tasca de l'autocodificador és trobar els índexs de temps r0 ... rn corresponents als elements anòmals del vector d'entrada X. Aquest efecte s'aconsegueix buscant l'error quadrat.
Figura 6. Autoencoder síncron
Per a l'autocodificador es va seleccionar . Els seus avantatges: la capacitat d'utilitzar el mode de processament de streaming i un nombre relativament menor de paràmetres de xarxa neuronal en comparació amb altres arquitectures.
Mecanisme per minimitzar els falsos positius
Degut al fet que es presenten diverses situacions anormals, així com una possible situació d'entrenament insuficient de la xarxa neuronal, per al model de detecció d'anomalies que s'està desenvolupant, es va decidir que era necessari desenvolupar un mecanisme per minimitzar els falsos positius. Aquest mecanisme es basa en una base de plantilles que l'administrador classifica.
(Algorisme DTW, de l'anglès dynamic time warping) permet trobar la correspondència òptima entre seqüències de temps. S'utilitza per primera vegada en el reconeixement de veu: s'utilitza per determinar com dos senyals de parla representen la mateixa frase parlada original. Posteriorment, se'n va trobar aplicació en altres àmbits.
El principi principal per minimitzar els falsos positius és recollir una base de dades d'estàndards amb l'ajuda d'un operador que classifica els casos sospitosos detectats mitjançant xarxes neuronals. A continuació, es compara l'estàndard classificat amb el cas que el sistema ha detectat i es fa una conclusió sobre si el cas és fals o si ha provocat una fallada. L'algorisme DTW s'utilitza precisament per comparar dues sèries temporals. La principal eina de minimització segueix sent la classificació. S'espera que després de recollir un gran nombre de casos de referència, el sistema comenci a demanar menys a l'operador a causa de la similitud de la majoria de casos i l'ocurrència de similars.
Com a resultat, basant-se en els mètodes de xarxes neuronals descrits anteriorment, es va crear un programa experimental per predir els errors del sistema "Web-Consolidation". L'objectiu d'aquest programa era, utilitzant l'arxiu existent de dades de seguiment i informació sobre errors anteriors, avaluar la competència d'aquest enfocament per als nostres sistemes de programari. L'esquema del programa es presenta a continuació a la figura 7.
Figura 7. Esquema de predicció de fallades basat en l'anàlisi de l'espai mètric
En el diagrama, es poden distingir dos blocs principals: la recerca de períodes de temps anòmals en el flux de dades de seguiment (mètriques) i el mecanisme per minimitzar els falsos positius. Nota: amb finalitats experimentals, les dades s'obtenen mitjançant una connexió JDBC de la base de dades en la qual el grafit les desarà.
A continuació es mostra la interfície del sistema de monitorització obtinguda com a resultat del desenvolupament (Figura 8).
Figura 8. Interfície del sistema de seguiment experimental
La interfície mostra el percentatge d'anomalia en funció de les mètriques rebudes. En el nostre cas, el rebut es simula. Ja tenim totes les dades des de fa diverses setmanes i les anem carregant a poc a poc per comprovar el cas d'una anomalia que condueixi al fracàs. La barra d'estat inferior mostra el percentatge global d'anomalia de dades en un moment determinat, que es determina mitjançant un codificador automàtic. A més, es mostra un percentatge separat per a les mètriques previstes, que és calculat per l'RNN LSTM.
Un exemple de detecció d'anomalies basada en el rendiment de la CPU mitjançant la xarxa neuronal RNN LSTM (figura 9).
Figura 9. Descobriment de RNN LSTM
Un cas bastant senzill, essencialment un valor atípic normal, però que va provocar una fallada del sistema, es va calcular amb èxit mitjançant RNN LSTM. L'indicador d'anomalia en aquest període de temps és del 85 al 95%; tot per sobre del 80% (el llindar es va determinar experimentalment) es considera una anomalia.
Un exemple de detecció d'anomalies quan el sistema no va poder arrencar després d'una actualització. Aquesta situació la detecta l'autocodificador (figura 10).
Figura 10. Exemple de detecció d'autoencoder
Com podeu veure a la figura, PermGen està enganxat a un nivell. L'autoencoder va trobar això estrany perquè mai abans havia vist res semblant. Aquí l'anomalia es manté al 100% fins que el sistema torna a un estat de funcionament. Es mostra una anomalia per a totes les mètriques. Com s'ha esmentat anteriorment, l'autoencoder no pot localitzar anomalies. L'operador està obligat a realitzar aquesta funció en aquestes situacions.
Conclusió
PC "Web-Consolidation" ha estat en desenvolupament durant diversos anys. El sistema es troba en un estat força estable i el nombre d'incidències registrades és petit. No obstant això, va ser possible trobar anomalies que van provocar una fallada entre 5 i 10 minuts abans que es produís la falla. En alguns casos, la notificació d'una fallada amb antelació ajudaria a estalviar el temps programat que s'assigna per dur a terme els treballs de "reparació".
A partir dels experiments que es van dur a terme, és massa aviat per extreure conclusions finals. Fins ara, els resultats són contradictoris. D'una banda, és evident que els algorismes basats en xarxes neuronals són capaços de trobar anomalies "útils". D'altra banda, hi ha un gran percentatge de falsos positius, i no es poden detectar totes les anomalies detectades per un especialista qualificat en una xarxa neuronal. Els desavantatges inclouen el fet que ara la xarxa neuronal requereix formació amb un professor per al funcionament normal.
Per desenvolupar encara més el sistema de predicció de fallades i portar-lo a un estat satisfactori, es poden preveure diverses maneres. Es tracta d'una anàlisi més detallada dels casos amb anomalies que porten al fracàs, a causa d'aquesta incorporació a la llista de mètriques importants que influeixen molt en l'estat del sistema, i descartant d'innecessàries que no l'afecten. A més, si ens movem en aquesta direcció, podem intentar especialitzar algorismes específicament per als nostres casos amb anomalies que condueixen a fallades. Hi ha una altra manera. Aquesta és una millora en les arquitectures de xarxes neuronals i, per tant, augmenta la precisió de la detecció amb una reducció del temps d'entrenament.
Expresso el meu agraïment als meus companys que m'han ajudat a escriure i mantenir la rellevància d'aquest article: i Sergei Finogenov.
Font: www.habr.com