Cerchemu anomalie è predichemu i fallimenti cù e rete neurali

U sviluppu industriale di i sistemi di software richiede una grande attenzione à a tolleranza di difetti di u pruduttu finali, è ancu una risposta rapida à i fallimenti è i fallimenti s'ellu si verificanu. U monitoraghju, sicuru, aiuta à risponde à fallimenti è fallimenti più efficaci è rapidamente, ma micca abbastanza. Prima, hè assai difficiule di seguità un gran numaru di servitori - un gran numaru di persone hè necessariu. Siconda, avete bisognu di avè una bona cunniscenza di cumu funziona l'applicazione per predichendu u so statu. Dunque, avemu bisognu di parechje persone chì anu una bona cunniscenza di i sistemi chì avemu sviluppatu, u so rendiment è e caratteristiche. Assumimu chì ancu s'è truvate abbastanza persone disposti à fà questu, ci vole ancu assai tempu per furmà.

Chì fà ? Hè quì chì l'intelligenza artificiale vene à u nostru aiutu. L'articulu parlerà mantenimentu preditivu (mantenimentu predittivu). Stu approcciu hè attivamente guadagnatu pupularità. Un gran numaru d'articuli sò stati scritti, ancu nantu à Habré. E grande cumpagnie facenu un usu cumpletu di questu approcciu per mantene a prestazione di i so servitori. Dopu avè studiatu un gran numaru d'articuli, avemu decisu di pruvà stu approcciu. Chì ne hè vinutu ?

Introduzione

U sistema di software sviluppatu prima o dopu entra in opera. Hè impurtante per l'utilizatore chì u sistema funziona senza fallimenti. Se una emergenza accade, deve esse risolta cù un minimu ritardu.

Per simplificà u supportu tecnicu di un sistema di software, soprattuttu s'ellu ci sò assai servitori, i prugrammi di surviglianza sò generalmente utilizati chì piglianu metriche da un sistema di software in esecuzione, facenu pussibule di diagnosticà a so cundizione è aiutanu à determinà ciò chì esattamente hà causatu u fallimentu. Stu prucessu hè chjamatu monitoraghju di u sistema di software.

Figura 1. Interfaccia di surviglianza Grafana

I metrici sò diversi indicatori di un sistema di software, u so ambiente di esecutivu, o l'urdinatore fisicu sottu u quale u sistema hè in esecuzione cù un timestamp di u mumentu quandu i metrici sò stati ricevuti. In l'analisi statica, sti metrichi sò chjamati serie di tempu. Per monitorà u statu di u sistema di u software, i metrici sò affissati in forma di grafici: u tempu hè nantu à l'assi X, è i valori sò longu l'assi Y (Figura 1). Diversi milla metriche ponu esse pigliate da un sistema di software in esecuzione (da ogni node). Formanu un spaziu di metrica (serie temporale multidimensionale).

Siccomu un gran numaru di metriche sò cullate per sistemi di software cumplessi, u monitoraghju manuale diventa un compitu difficiule. Per riduce a quantità di dati analizati da l'amministratore, i strumenti di surviglianza cuntenenu strumenti per identificà automaticamente i prublemi pussibuli. Per esempiu, pudete cunfigurà un trigger per u focu quandu u spaziu di discu liberu hè sottu à un limitu specificatu. Pudete ancu diagnosticà automaticamente un arrestu di u servitore o una rallentazione critica in a velocità di serviziu. In pratica, i strumenti di surviglianza facenu un bonu travagliu per detectà fallimenti chì sò digià accaduti o identificà sintomi simplici di fallimenti futuri, ma in generale, predichendu un eventuale fallimentu resta una noce dura per crack per elli. A predizione per mezu di l'analisi manuale di e metriche richiede l'implicazione di specialisti qualificati. Hè bassa produtividade. A maiò parte di i fallimenti potenziali ponu passà inosservati.

Ricertamenti, u cusì chjamatu mantenimentu predittivu di i sistemi di software hè diventatu sempri più populari trà e grandi cumpagnie di sviluppu di software IT. L'essenza di questu approcciu hè di truvà prublemi chì portanu à a degradazione di u sistema in i primi fasi, prima di fallu, utilizendu intelligenza artificiale. Stu approcciu ùn esclude micca cumplettamente u monitoraghju manuale di u sistema. Hè auxiliariu à u prucessu di monitoraghju in tuttu.

L'uttellu principalu per l'implementazione di mantenimentu predittivu hè u compitu di ricerca di anomalie in serie di tempu, postu chì quandu si faci una anomalia in i dati ci hè una alta probabilità chì dopu qualchì tempu ci sarà un fallimentu o fallimentu. Una anomalia hè una certa deviazione in u funziunamentu di un sistema di software, cum'è l'identificazione di a degradazione in a velocità d'esekzione di un tipu di dumanda o una diminuzione di u numeru mediu di richieste servite à un livellu constantu di sessioni di cliente.

U compitu di ricerca di anomalie per i sistemi di software hà e so particularità. In teoria, per ogni sistema di software hè necessariu di sviluppà o raffinà i metudi esistenti, postu chì a ricerca di anomalie hè assai dipendente di e dati in quale hè realizatu, è e dati di i sistemi di software varieghja assai secondu l'arnesi per implementà u sistema. , finu à quale computer hè in esecuzione.

Metudu per a ricerca di anomalie quandu predice fallimenti di sistemi di software

Prima di tuttu, vale a pena dì chì l'idea di predichendu i fallimenti hè stata inspirata da l'articulu "L'apprendimentu automaticu in u monitoraghju IT". Per pruvà l'efficacità di l'approcciu cù a ricerca automatica di anomalie, u sistema di software Web-Consolidation hè statu sceltu, chì hè unu di i prughjetti di a cumpagnia NPO Krista. Nanzu, u monitoraghju manuale hè statu realizatu per ellu basatu annantu à e metriche ricevute. Siccomu u sistema hè abbastanza cumplessu, un gran numaru di metriche sò pigliati per questu: indicatori JVM (carga di cullizzioni di basura), indicatori di u SO sottu u quale u codice hè eseguitu (memoria virtuale, % di carica di CPU OS), indicatori di rete (carica di rete). ), u servitore stessu (CPU load , memoria), metriche wildfly è e metriche di l'applicazione per tutti i sottosistemi critichi.

Tutte e metriche sò pigliate da u sistema cù grafite. Inizialmente, a basa di dati di sussurru hè stata aduprata cum'è una suluzione standard per grafana, ma cum'è a basa di clientella cresce, u grafitu ùn pudia più affruntà, avè esauritu a capacità di u subsistema di discu DC. Dopu questu, hè statu decisu di truvà una suluzione più efficace. A scelta hè stata fatta in favore grafite+clickhouse, chì hà permessu di riduce a carica nantu à u sottosistema di discu da un ordine di grandezza è riduce u spaziu di discu occupatu da cinque à sei volte. Quì sottu hè un diagramma di u mecanismu per a cullizzioni di metriche cù grafite + clickhouse (Figura 2).

Figura 2. Schema per a cullezzione di metrica

U schema hè pigliatu da a documentazione interna. Mostra a cumunicazione trà grafana (a UI di monitorizazione chì usemu) è grafite. L'eliminazione di metriche da una applicazione hè fatta da un software separatu - jmxtrans. Li mette in grafite.
U sistema di Consolidazione Web hà una quantità di funzioni chì creanu prublemi per predichendu i fallimenti:

1. A tendenza spessu cambia. Diverse versioni sò dispunibili per stu sistema di software. Ognunu di elli porta cambiamenti à a parte di u software di u sistema. Per quessa, in questu modu, i sviluppatori influenzanu direttamente a metrica di un sistema determinatu è ponu causà un cambiamentu di tendenza;
2. a funzione di implementazione, è ancu i scopi per i quali i clienti utilizanu stu sistema, spessu causanu anomalie senza degradazione previa;
3. u percentuale di anomalie relative à tuttu u settore di dati hè chjucu (< 5%);
4. Ci ponu esse lacune in riceve indicatori da u sistema. In certi brevi periodi di tempu, u sistema di monitoraghju ùn riesce à ottene metriche. Per esempiu, se u servitore hè sovraccaricatu. Questu hè criticu per a furmazione di una rete neurale. Ci hè bisognu di riempie i lacune sinteticamente;
5. I casi cù anomalie sò spessu pertinenti solu per una data / mese / ora specifica (stagione). Stu sistema hà regulamentu chjaru per u so usu da l'utilizatori. Per quessa, e metriche sò pertinenti solu per un tempu specificu. U sistema ùn pò micca esse usatu constantemente, ma solu in certi mesi: selettivu secondu l'annu. Situazioni sò quandu u listessu cumpurtamentu di metrica in un casu pò purtà à un fallimentu di u sistema di software, ma micca in un altru.
   Per principià, i metudi per a rilevazione di anomalie in i dati di monitoraghju di i sistemi di software sò stati analizati. In l'articuli nantu à questu tema, quandu u percentualità di anomalie hè chjuca in quantu à u restu di u settore di dati, hè più spessu pruposta di utilizà e rete neurali.

A logica basica per a ricerca di anomalie cù e dati di a rete neurale hè mostrata in Figura 3:

Figura 3. A ricerca di anomalie cù una rete neurale

Basatu nantu à u risultatu di a previsione o restaurazione di a finestra di u flussu attuale di metrica, a deviazione da quella ricevuta da u sistema di software in esecuzione hè calculata. Se ci hè una grande diferenza trà e metriche ottenute da u sistema di software è a rete neurale, pudemu cuncludi chì u segmentu di dati attuale hè anomalu. A siguenti seria di prublemi nascenu per l'usu di e rete neurali:

1. per travaglià currettamente in u modu streaming, i dati per a furmazione di mudelli di rete neurale deve include solu dati "normali";
2. hè necessariu avè un mudellu aghjurnatu per a rilevazione curretta. U cambiamentu di i tendenzi è a staghjunalità in metrica pò causà un gran numaru di falsi pusitivi in ​​u mudellu. Per aghjurnà, hè necessariu determinà chjaramente u tempu quandu u mudellu hè obsoletu. Se aghjurnà u mudellu più tardi o prima, allora, assai prubabilmente, seguitarà un gran numaru di falsi pusitivi.
   Ùn ci vole micca scurdà ancu di circà è prevene l'occurrence frequente di falsi pusitivi. Si assume chì a più spessu accade in situazioni d'urgenza. Tuttavia, ponu ancu esse una cunsequenza di un errore di rete neurale per una furmazione insufficiente. Hè necessariu di minimizzà u numeru di falsi pusitivi di u mudellu. Altrimenti, false prediczioni perderanu assai tempu di amministratore destinatu à verificà u sistema. Prima o dopu, l'amministratore solu cesserà di risponde à u sistema di surviglianza "paranoica".

Rete neurale recurrente

Per detectà anomalie in serie di tempu, pudete aduprà rete neurale recurrente cù memoria LSTM. L'unicu prublema hè chì pò esse usatu solu per a serie di tempu prevista. In u nostru casu, micca tutte e metriche sò prevedibili. Un tentativu di applicà RNN LSTM à una serie temporale hè mostratu in Figura 4.

Figura 4. Esempiu di una rete neurale recurrente cù cellule di memoria LSTM

Comu pò esse vistu da a Figura 4, RNN LSTM hà sappiutu affruntà a ricerca di anomalie in questu periodu di tempu. Induve u risultatu hà un altu errore di prediczione (errore mediu), una anomalia in l'indicatori hè veramente accaduta. Aduprà una sola RNN LSTM chjaramente ùn serà micca abbastanza, postu chì hè applicabile à un picculu numeru di metrica. Pò esse usatu cum'è un metudu ausiliariu per a ricerca di anomalie.

Autoencoder per a predizione di fallimentu

Autoencoder - essenzialmente una rete neurale artificiale. U livellu di input hè codificatore, u livellu di output hè decoder. U svantaghju di tutte e rete neurali di stu tipu hè chì ùn localizzanu micca bè l'anomali. Hè stata scelta una architettura di autoencoder sincrona.

Figura 5. Esempiu di operazione autoencoder

Autoencoders sò furmatu nantu à dati nurmali è dopu truvà qualcosa anomalu in i dati alimentati à u mudellu. Solu ciò chì avete bisognu per questu compitu. Tuttu ciò chì resta hè di sceglie quale autoencoder hè adattatu per questu compitu. A forma più simplice architettonicamente di un autoencoder hè una rete neurale in avanti, senza ritornu, chì hè assai simile à perceptron multilayer (multilayer perceptron, MLP), cù una strata di input, una strata di output, è una o più strati nascosti chì li culliganu.
In ogni casu, e diffirenzii trà autoencoder è MLP sò chì in un autoencoder, a capa di output hà u listessu numeru di nodi cum'è a capa di input, è chì invece di esse furmatu per predichendu un valore di destinazione Y datu da un input X, l'autoencoder hè furmatu. per ricustruisce u so propiu X. Per quessa, Autoencoders sò mudelli di apprendimentu senza supervisione.

U compitu di l'autoencoder hè di truvà l'indici di u tempu r0 ... rn chì currispondenu à l'elementi anomali in u vettore di input X. Stu effettu hè ottenutu da a ricerca di l'errore quadratu.

Figura 6. Autoencoder sincronu

Per l'autocoder hè statu sceltu architettura sincrona. I so vantaghji: a capacità d'utilizà u modu di trasfurmazione in streaming è un numeru relativamente più chjucu di parametri di rete neurale cumparatu cù altre architetture.

Meccanismu per minimizzà i falsi pusitivi

A causa di u fattu chì si sviluppanu diverse situazioni anormali, è ancu una pussibile situazione di furmazione insufficiente di a rete neurale, per u mudellu di deteczione di l'anomalia chì hè sviluppatu, hè statu decisu chì era necessariu di sviluppà un mecanismu per minimizzà i falsi pusitivi. Stu mecanismu hè basatu annantu à una basa di dati di mudellu chì hè classificatu da l'amministratore.

Algoritmu per a trasfurmazioni di timeline dinamica (Algoritmu DTW, da l'inglese dynamic time warping) permette di truvà a currispundenza ottima trà e sequenze di u tempu. Prima utilizatu in u ricunniscenza vocale: utilizatu per determinà cumu dui signali di parlà rapprisentanu a stessa frase parlata originale. In seguitu, l'applicazione hè stata trovata in altri spazii.

U principiu principalu di minimizzà i falsi pusitivi hè di cullà una basa di dati di normi cù l'aiutu di un operatore chì classificà i casi sospetti rilevati cù e rete neurali. In seguitu, u standard classificatu hè paragunatu cù u casu chì u sistema hà rilevatu, è una cunclusione hè fatta nantu à se u casu hè falsu o chì porta à un fallimentu. Hè precisamente per paragunà duie serie di tempu chì l'algoritmu DTW hè utilizatu. U principale strumentu di minimizazione hè sempre a classificazione. Hè previstu chì dopu à cullà un gran numaru di casi di riferimentu, u sistema hà da cumincià à dumandà à l'operatore menu per via di a similitudine di a maiò parte di i casi è l'occurrence di simili.

In u risultatu, basatu nantu à i metudi di rete neurale descritti sopra, un prugramma spirimintali hè statu custruitu per predice i fallimenti di u sistema "Web-Consolidation". U scopu di stu prugramma era, utilizendu l'archiviu esistenti di dati di monitoraghju è infurmazioni nantu à i fallimenti precedenti, per evaluà a cumpetenza di questu approcciu per i nostri sistemi di software. U schema di u prugramma hè presentatu sottu in Figura 7.

Figura 7. Schema di predizione di fallimentu basatu annantu à l'analisi di u spaziu metricu

In u diagramma, ponu esse distinti dui blocchi principali: a ricerca di i periodi anomali di u tempu in u flussu di dati di monitoraghju (metrics) è u mecanismu per minimizzà i falsi pusitivi. Nota: Per scopi sperimentali, i dati sò ottenuti via una cunnessione JDBC da a basa di dati in quale u grafitu a salvarà.
U seguitu hè l'interfaccia di u sistema di surviglianza ottenuta com'è u risultatu di u sviluppu (Figura 8).

Figura 8. Interfaccia di u sistema di surviglianza sperimentale

L'interfaccia mostra u percentuale di l'anomalia basatu nantu à e metriche ricevute. In u nostru casu, u ricivutu hè simulatu. Avemu digià tutte e dati per parechje settimane è a carica gradualmente per verificà u casu di una anomalia chì porta à fallimentu. A barra di statutu più bassa mostra u percentualità generale di l'anomalia di dati in un mumentu determinatu, chì hè determinatu cù un autoencoder. Inoltre, un percentinu separatu hè visualizatu per e metriche previste, chì hè calculatu da u RNN LSTM.

Un esempiu di rilevazione di anomalie basatu nantu à u rendiment di CPU utilizendu a rete neurale RNN LSTM (Figura 9).

Figura 9. RNN LSTM scuperta

Un casu abbastanza simplice, essenzialmente un outlier ordinariu, ma chì porta à un fallimentu di u sistema, hè statu calculatu cù successu cù RNN LSTM. L'indicatore di l'anomalia in questu periodu di tempu hè 85-95%; tuttu ciò chì sopra à 80% (u limitu hè statu determinatu sperimentalmente) hè cunsideratu una anomalia.
Un esempiu di una rilevazione di anomalie quandu u sistema ùn era micca capaci di boot dopu una aghjurnazione. Sta situazione hè rilevata da l'autoencoder (Figura 10).

Figura 10. Esempiu di rilevazione autoencoder

Comu pudete vede da a figura, PermGen hè stuck à un livellu. L'autoencoder hà truvatu questu stranu perchè ùn avia mai vistu nunda cum'è prima. Quì l'anomalia ferma 100% finu à chì u sistema torna à un statu di travagliu. Una anomalia hè visualizata per tutte e metriche. Comu diciatu prima, l'autoencoder ùn pò micca localizà anomalie. L'operatore hè chjamatu per fà sta funzione in queste situazioni.

cunchiusioni

PC "Web-Consolidation" hè statu in sviluppu per parechji anni. U sistema hè in un statu abbastanza stabile, è u nùmeru di incidenti registrati hè chjucu. Tuttavia, era pussibule di truvà anomalie chì portanu à u fallimentu 5 - 10 minuti prima di u fallimentu. In certi casi, a notificazione di un fallimentu in anticipu aiuterà à salvà u tempu pianificatu chì hè attribuitu per fà u travagliu di "riparazione".

Basatu nantu à l'esperimenti chì sò stati fatti, hè troppu prestu per piglià cunclusioni finali. Finu a ora, i risultati sò cunflitti. Da una banda, hè chjaru chì l'algoritmi basati nantu à e rete neurali sò capaci di truvà anomalie "utile". Per d 'altra banda, resta un grande percentualità di falsi pusitivi, è micca tutti l'anomali dettati da un specialista qualificatu in una rete neurale ponu esse rilevati. I disadvantages includenu u fattu chì avà a rete neurale richiede furmazione cù un maestru per u funziunamentu normale.

Per sviluppà ulteriormente u sistema di predizione di fallimentu è portà à un statu satisfactoriu, ponu esse previste parechje manere. Questu hè un analisi più detallatu di i casi cù anomalie chì portanu à fallimentu, per via di questa aghjunta à a lista di metriche impurtanti chì influenzanu assai u statu di u sistema, è u scartu di quelli innecessarii chì ùn l'affettanu micca. Inoltre, se movemu in questa direzzione, pudemu fà tentativi di specializà algoritmi specificamente per i nostri casi cù anomalie chì portanu à fallimenti. Ci hè un altru modu. Questa hè una migliione in l'architetture di rete neurale è cusì aumenta a precisione di rilevazione cù una riduzione di u tempu di furmazione.

Aghju espresu a mo gratitudine à i mo culleghi chì m'hà aiutatu à scrive è mantene a pertinenza di questu articulu: Victor Verbitsky è Sergei Finogenov.

Source: www.habr.com