Dezvoltarea industrială a sistemelor software necesită o mare atenție la toleranța la erori a produsului final, precum și un răspuns rapid la defecțiuni și defecțiuni dacă apar. Monitorizarea, desigur, ajută să răspundem la eșecuri și eșecuri mai eficient și mai rapid, dar nu suficient. În primul rând, este foarte dificil să urmăriți un număr mare de servere - este nevoie de un număr mare de oameni. În al doilea rând, trebuie să înțelegeți bine cum funcționează aplicația pentru a prezice starea acesteia. Prin urmare, avem nevoie de mulți oameni care să înțeleagă bine sistemele pe care le dezvoltăm, performanța și caracteristicile acestora. Să presupunem că, chiar dacă găsești destui oameni dispuși să facă acest lucru, este nevoie de mult timp pentru a-i antrena.
Ce să fac? Aici ne vine în ajutor inteligența artificială. Articolul va vorbi despre (întreținere predictivă). Această abordare câștigă în mod activ popularitate. S-au scris un număr mare de articole, inclusiv despre Habré. Companiile mari folosesc pe deplin această abordare pentru a menține performanța serverelor lor. După ce am studiat un număr mare de articole, am decis să încercăm această abordare. Ce a venit din asta?
Introducere
Sistemul software dezvoltat intră mai devreme sau mai târziu în funcțiune. Este important pentru utilizator ca sistemul să funcționeze fără erori. Dacă apare o urgență, aceasta ar trebui rezolvată cu o întârziere minimă.
Pentru a simplifica suportul tehnic al unui sistem software, mai ales dacă există multe servere, se folosesc de obicei programe de monitorizare care preiau valori de la un sistem software care rulează, fac posibilă diagnosticarea stării acestuia și ajută la determinarea exactă a cauzei defecțiunii. Acest proces se numește monitorizarea sistemului software.
Figura 1. Interfața de monitorizare Grafana
Metricurile sunt diverși indicatori ai unui sistem software, a mediului de execuție al acestuia sau a computerului fizic sub care rulează sistemul, cu un marcaj temporal al momentului în care au fost primite valorile. În analiza statică, aceste valori sunt numite serii de timp. Pentru a monitoriza starea sistemului software, valorile sunt afișate sub formă de grafice: timpul este pe axa X, iar valorile sunt de-a lungul axei Y (Figura 1). Câteva mii de metrici pot fi preluate dintr-un sistem software care rulează (de la fiecare nod). Ele formează un spațiu de metrici (serie temporală multidimensională).
Deoarece un număr mare de metrici sunt colectate pentru sisteme software complexe, monitorizarea manuală devine o sarcină dificilă. Pentru a reduce cantitatea de date analizate de administrator, instrumentele de monitorizare conțin instrumente pentru a identifica automat posibilele probleme. De exemplu, puteți configura un declanșator să se declanșeze atunci când spațiul liber pe disc scade sub un prag specificat. De asemenea, puteți diagnostica automat o oprire a serverului sau o încetinire critică a vitezei serviciului. În practică, instrumentele de monitorizare fac o treabă bună în detectarea defecțiunilor care au avut loc deja sau identificarea simptomelor simple ale defecțiunilor viitoare, dar, în general, prezicerea unei posibile defecțiuni rămâne o nucă greu de spart pentru ele. Predicția prin analiza manuală a metricilor necesită implicarea unor specialiști calificați. Este o productivitate scăzută. Majoritatea potențialelor eșecuri pot trece neobservate.
Recent, așa-numita întreținere predictivă a sistemelor software a devenit din ce în ce mai populară în rândul companiilor mari de dezvoltare de software IT. Esența acestei abordări este de a găsi probleme care duc la degradarea sistemului în stadiile incipiente, înainte ca acesta să eșueze, folosind inteligența artificială. Această abordare nu exclude complet monitorizarea manuală a sistemului. Este auxiliară procesului de monitorizare în ansamblu.
Instrumentul principal pentru implementarea întreținerii predictive este sarcina de a căuta anomalii în serii de timp, deoarece când apare o anomalie în date există o mare probabilitate ca după ceva timp va exista un eșec sau un eșec. O anomalie este o anumită abatere a performanței unui sistem software, cum ar fi identificarea degradării vitezei de execuție a unui tip de solicitare sau o scădere a numărului mediu de cereri deservite la un nivel constant de sesiuni client.
Sarcina de căutare a anomaliilor pentru sistemele software are propriile sale specificități. În teorie, pentru fiecare sistem software este necesară dezvoltarea sau rafinarea metodelor existente, deoarece căutarea anomaliilor este foarte dependentă de datele în care este efectuată, iar datele sistemelor software variază foarte mult în funcție de instrumentele de implementare a sistemului. , până la computerul pe care rulează.
Metode de căutare a anomaliilor la prezicerea defecțiunilor sistemelor software
În primul rând, merită spus că ideea de a prezice eșecurile a fost inspirată de articol . Pentru a testa eficacitatea abordării cu căutare automată a anomaliilor s-a ales sistemul software Web-Consolidation, care este unul dintre proiectele companiei NPO Krista. Anterior, monitorizarea manuală a fost efectuată pentru acesta pe baza valorilor primite. Deoarece sistemul este destul de complex, se iau un număr mare de metrici pentru acesta: indicatori JVM (încărcare colector de gunoi), indicatori ai sistemului de operare sub care este executat codul (memorie virtuală, % încărcare CPU OS), indicatori de rețea (încărcarea rețelei). ), serverul în sine (încărcare CPU, memorie), valorile wildfly și propriile valori ale aplicației pentru toate subsistemele critice.
Toate valorile sunt preluate din sistem folosind grafit. Inițial, baza de date whisper a fost folosită ca soluție standard pentru grafana, dar pe măsură ce baza de clienți a crescut, grafitul nu a mai putut face față, epuizând capacitatea subsistemului de disc DC. După aceasta, s-a decis să se găsească o soluție mai eficientă. Alegerea a fost făcută în favoarea , ceea ce a făcut posibilă reducerea încărcării subsistemului de disc cu un ordin de mărime și reducerea spațiului pe disc ocupat de cinci până la șase ori. Mai jos este o diagramă a mecanismului de colectare a valorilor folosind grafit+clickhouse (Figura 2).
Figura 2. Schema de colectare a valorilor
Diagrama este preluată din documentația internă. Afișează comunicarea dintre grafana (interfața de utilizare de monitorizare pe care o folosim) și grafit. Eliminarea valorilor dintr-o aplicație se face printr-un software separat - . Le pune în grafit.
Sistemul de consolidare web are o serie de caracteristici care creează probleme pentru prezicerea eșecurilor:
- Tendința se schimbă adesea. Pentru acest sistem software sunt disponibile diferite versiuni. Fiecare dintre ele aduce modificări părții software a sistemului. În consecință, în acest fel, dezvoltatorii influențează direct valorile unui sistem dat și pot provoca o schimbare de tendință;
- caracteristica de implementare, precum și scopurile pentru care clienții folosesc acest sistem, provoacă adesea anomalii fără degradare prealabilă;
- procentul de anomalii raportat la întregul set de date este mic (< 5%);
- Pot exista lacune în primirea indicatorilor de la sistem. În unele perioade scurte de timp, sistemul de monitorizare nu reușește să obțină metrici. De exemplu, dacă serverul este supraîncărcat. Acest lucru este esențial pentru formarea unei rețele neuronale. Este nevoie de a umple golurile sintetic;
- Cazurile cu anomalii sunt adesea relevante doar pentru o anumită dată/lună/oră (sezonalitate). Acest sistem are reglementări clare pentru utilizarea sa de către utilizatori. În consecință, valorile sunt relevante doar pentru un anumit timp. Sistemul nu poate fi utilizat constant, ci doar în câteva luni: selectiv în funcție de an. Apar situații când același comportament al metricilor într-un caz poate duce la o defecțiune a sistemului software, dar nu și în altul.
Pentru început, au fost analizate metode de detectare a anomaliilor în datele de monitorizare ale sistemelor software. În articolele pe această temă, când procentul de anomalii este mic față de restul setului de date, cel mai adesea se propune utilizarea rețelelor neuronale.
Logica de bază pentru căutarea anomaliilor folosind datele rețelei neuronale este prezentată în Figura 3:
Figura 3. Căutarea anomaliilor folosind o rețea neuronală
Pe baza rezultatului prognozei sau restabilirii ferestrei fluxului curent de metrici, se calculează abaterea de la cea primită de la sistemul software care rulează. Dacă există o diferență mare între metricile obținute din sistemul software și rețeaua neuronală, putem concluziona că segmentul de date actual este anormal. Următoarele serii de probleme apar pentru utilizarea rețelelor neuronale:
- pentru a funcționa corect în modul streaming, datele pentru antrenarea modelelor de rețele neuronale trebuie să includă doar date „normale”;
- este necesar să existe un model la zi pentru detectarea corectă. Schimbarea tendințelor și a sezonului în valori poate provoca un număr mare de fals pozitive în model. Pentru a-l actualiza, este necesar să se determine în mod clar momentul în care modelul este depășit. Dacă actualizați modelul mai târziu sau mai devreme, atunci, cel mai probabil, va urma un număr mare de fals pozitive.
De asemenea, nu trebuie să uităm de căutarea și prevenirea apariției frecvente a rezultatelor false pozitive. Se presupune că acestea vor apărea cel mai adesea în situații de urgență. Cu toate acestea, acestea pot fi, de asemenea, o consecință a unei erori de rețea neuronală din cauza antrenamentului insuficient. Este necesar să se minimizeze numărul de fals pozitive ale modelului. În caz contrar, predicțiile false vor pierde mult timp administratorului destinat verificării sistemului. Mai devreme sau mai târziu, administratorul pur și simplu nu va mai răspunde la sistemul de monitorizare „paranoic”.
Rețea neuronală recurentă
Pentru a detecta anomalii în seriile temporale, puteți utiliza cu memorie LSTM. Singura problemă este că poate fi folosit doar pentru serii temporale prognozate. În cazul nostru, nu toate valorile sunt previzibile. O încercare de a aplica RNN LSTM unei serii de timp este prezentată în Figura 4.
Figura 4. Exemplu de rețea neuronală recurentă cu celule de memorie LSTM
După cum se poate observa din Figura 4, RNN LSTM a reușit să facă față căutării anomaliilor în această perioadă de timp. În cazul în care rezultatul are o eroare mare de predicție (eroare medie), a apărut de fapt o anomalie în indicatori. Utilizarea unui singur RNN LSTM nu va fi în mod clar suficientă, deoarece este aplicabilă unui număr mic de metrici. Poate fi folosit ca metodă auxiliară pentru căutarea anomaliilor.
Autoencoder pentru predicția defecțiunilor
– în esență o rețea neuronală artificială. Stratul de intrare este codificator, stratul de ieșire este decodor. Dezavantajul tuturor rețelelor neuronale de acest tip este că nu localizează bine anomaliile. A fost aleasă o arhitectură de autoencoder sincron.
Figura 5. Exemplu de funcționare a autoencoderului
Codificatoarele automate sunt antrenate pe date normale și apoi găsesc ceva anormal în datele furnizate modelului. Exact ceea ce ai nevoie pentru această sarcină. Tot ce rămâne este să alegeți ce codificator automat este potrivit pentru această sarcină. Cea mai simplă formă arhitecturală a unui autoencoder este o rețea neuronală înainte, nereturnabilă, care este foarte asemănătoare cu (perceptron multistrat, MLP), cu un strat de intrare, un strat de ieșire și unul sau mai multe straturi ascunse care le conectează.
Cu toate acestea, diferențele dintre autoencoder și MLP sunt că într-un autoencoder, stratul de ieșire are același număr de noduri ca și stratul de intrare și că, în loc să fie antrenat să prezică o valoare țintă Y dată de o intrare X, autoencoderul este antrenat. pentru a-și reconstrui propriile X. Prin urmare, Autoencoders sunt modele de învățare nesupravegheate.
Sarcina autoencoderului este să găsească indicii de timp r0 ... rn corespunzători elementelor anormale din vectorul de intrare X. Acest efect se realizează prin căutarea erorii pătrate.
Figura 6. Autoencoder sincron
Pentru autoencoder a fost selectat . Avantajele sale: capacitatea de a utiliza modul de procesare în flux și un număr relativ mai mic de parametri ai rețelei neuronale în comparație cu alte arhitecturi.
Mecanism de minimizare a rezultatelor false pozitive
Datorită faptului că apar diverse situații anormale, precum și o posibilă situație de antrenare insuficientă a rețelei neuronale, pentru modelul de detectare a anomaliilor aflat în curs de dezvoltare, s-a decis că este necesar să se elaboreze un mecanism de minimizare a fals pozitive. Acest mecanism se bazează pe o bază de șablon care este clasificată de administrator.
(Algoritmul DTW, din engleza dynamic time warping) vă permite să găsiți corespondența optimă între secvențele de timp. Utilizat pentru prima dată în recunoașterea vorbirii: folosit pentru a determina modul în care două semnale vocale reprezintă aceeași frază vorbită originală. Ulterior, s-a găsit aplicare pentru el în alte domenii.
Principiul principal al minimizării fals-pozitivelor este colectarea unei baze de date de standarde cu ajutorul unui operator care clasifică cazurile suspecte detectate folosind rețelele neuronale. În continuare, standardul clasificat este comparat cu cazul pe care sistemul l-a detectat și se face o concluzie dacă cazul este fals sau duce la o defecțiune. Algoritmul DTW este folosit tocmai pentru a compara două serii de timp. Principalul instrument de minimizare este încă clasificarea. Este de așteptat ca după colectarea unui număr mare de cazuri de referință, sistemul să înceapă să ceară mai puțin operatorului din cauza asemănării majorității cazurilor și apariției unora similare.
Ca urmare, pe baza metodelor rețelei neuronale descrise mai sus, a fost construit un program experimental pentru a prezice eșecurile sistemului „Web-Consolidation”. Scopul acestui program a fost, folosind arhiva existentă de date de monitorizare și informații despre eșecurile anterioare, de a evalua competența acestei abordări pentru sistemele noastre software. Schema programului este prezentată mai jos în Figura 7.
Figura 7. Schema de predicție a defecțiunilor bazată pe analiza spațiului metric
În diagramă se pot distinge două blocuri principale: căutarea unor perioade anormale de timp în fluxul de date de monitorizare (metrice) și mecanismul de minimizare a fals-pozitivelor. Notă: În scopuri experimentale, datele sunt obținute printr-o conexiune JDBC din baza de date în care grafitul le va salva.
Mai jos este interfața sistemului de monitorizare obținută ca urmare a dezvoltării (Figura 8).
Figura 8. Interfața sistemului de monitorizare experimentală
Interfața afișează procentul de anomalie pe baza valorilor primite. În cazul nostru, chitanța este simulată. Avem deja toate datele de câteva săptămâni și le încărcăm treptat pentru a verifica cazul unei anomalii care duce la eșec. Bara de stare inferioară afișează procentul total de anomalie de date la un moment dat, care este determinat folosind un codificator automat. De asemenea, este afișat un procent separat pentru valorile prezise, care este calculat de RNN LSTM.
Un exemplu de detectare a anomaliilor bazat pe performanța CPU folosind rețeaua neuronală RNN LSTM (Figura 9).
Figura 9. Descoperirea RNN LSTM
Un caz destul de simplu, în esență o valoare anormală obișnuită, dar care duce la defecțiunea sistemului, a fost calculat cu succes utilizând RNN LSTM. Indicatorul de anomalie în această perioadă de timp este de 85–95%; totul peste 80% (pragul a fost determinat experimental) este considerat o anomalie.
Un exemplu de detectare a unei anomalii când sistemul nu a putut porni după o actualizare. Această situație este detectată de autoencoder (Figura 10).
Figura 10. Exemplu de detectare a autoencoderului
După cum puteți vedea din figură, PermGen este blocat la un nivel. Autoencoderul i s-a părut ciudat, deoarece nu a mai văzut așa ceva până acum. Aici anomalia rămâne 100% până când sistemul revine la starea de funcționare. Este afișată o anomalie pentru toate valorile. După cum am menționat mai devreme, autoencoderul nu poate localiza anomalii. Operatorul este chemat să îndeplinească această funcție în aceste situații.
Concluzie
PC "Web-Consolidation" este în dezvoltare de câțiva ani. Sistemul este într-o stare destul de stabilă, iar numărul de incidente înregistrate este mic. Cu toate acestea, a fost posibil să se găsească anomalii care duc la defecțiune cu 5 - 10 minute înainte de producerea defecțiunii. În unele cazuri, notificarea în avans a unei defecțiuni ar ajuta la economisirea timpului programat alocat pentru efectuarea lucrărilor de „reparație”.
Pe baza experimentelor care au fost efectuate, este prea devreme pentru a trage concluzii finale. Până acum, rezultatele sunt contradictorii. Pe de o parte, este clar că algoritmii bazați pe rețele neuronale sunt capabili să găsească anomalii „utile”. Pe de altă parte, rămâne un procent mare de fals pozitive și nu pot fi detectate toate anomaliile detectate de un specialist calificat într-o rețea neuronală. Dezavantajele includ faptul că acum rețeaua neuronală necesită pregătire cu un profesor pentru funcționarea normală.
Pentru a dezvolta în continuare sistemul de predicție a defecțiunilor și pentru a-l aduce într-o stare satisfăcătoare, pot fi avute în vedere mai multe modalități. Aceasta este o analiză mai detaliată a cazurilor cu anomalii care duc la eșec, datorită acestei adăugări la lista de metrici importante care influențează foarte mult starea sistemului, și a eliminării celor inutile care nu îl afectează. De asemenea, dacă ne îndreptăm în această direcție, putem face încercări de a specializa algoritmi special pentru cazurile noastre cu anomalii care duc la eșecuri. Există o altă cale. Aceasta este o îmbunătățire a arhitecturilor rețelelor neuronale și, prin urmare, crește acuratețea detectării cu o reducere a timpului de antrenament.
Îmi exprim recunoștința față de colegii mei care m-au ajutat să scriu și să mențin relevanța acestui articol: și Serghei Finogenov.
Sursa: www.habr.com