Lo sviluppo industriale di sistemi software richiede grande attenzione alla resilienza del prodotto finale, nonché una rapida reazione agli errori e ai guasti, se dovessero verificarsi. Il monitoraggio, naturalmente, aiuta a rispondere agli errori e ai guasti in modo più efficiente e veloce, ma non è sufficiente. Innanzitutto, è molto difficile tenere traccia di un gran numero di server, servono molte persone. In secondo luogo, è importante avere una buona comprensione di come è strutturata l'applicazione, per poter prevedere il suo stato. Di conseguenza, ci vogliono molte persone con una buona comprensione dei sistemi che stiamo sviluppando, delle loro metriche e peculiarità. Supponiamo che, anche se si trova un numero sufficiente di persone disposte a farlo, ci vorrà anche molto tempo per addestrarli.
Cosa fare allora? Qui ci viene in aiuto l'intelligenza artificiale. L'articolo parlerà di (predictive maintenance). Questo approccio sta guadagnando popolarità. Sono stati scritti molti articoli, anche su Habr. Grandi aziende stanno già utilizzando questo approccio per mantenere operativi i propri server. Dopo aver esaminato un gran numero di articoli, abbiamo deciso di provare ad applicare questo approccio. Cosa ne è venuto fuori?
Introduzione
Un sistema software sviluppato entrerà in esercizio prima o poi. È importante per l'utente che il sistema funzioni senza interruzioni. Se dovesse verificarsi una situazione straordinaria, deve essere risolta con il minimo ritardo.
Per semplificare il supporto tecnico del sistema software, soprattutto se ci sono molti server, di solito si utilizzano programmi di monitoraggio, che raccolgono metriche dal sistema software in funzione, offrono la possibilità di diagnosticare il suo stato e aiutano a determinare cosa ha causato il guasto. Questo processo è chiamato monitoraggio del sistema software.
Figura 1. Interfaccia per il monitoraggio grafana
Le metriche sono vari indicatori di un sistema software, dell'ambiente in cui esegue o della macchina fisica su cui è in esecuzione, con un timestamp che indica il momento in cui le metriche sono state acquisite. Nell'analisi statica, i dati metrici vengono denominati serie temporali. Per monitorare lo stato del sistema software, le metriche vengono visualizzate sotto forma di grafici: sull'asse X – il tempo, mentre sull'asse Y – i valori (figura 1). Un sistema software in funzione può fornire diverse migliaia di metriche (da ogni nodo). Queste formano uno spazio metrico (serie temporali multidimensionali).
Poiché nei sistemi software complessi vengono registrate un gran numero di metriche, il monitoraggio manuale diventa un compito difficile. Per ridurre il volume dei dati analizzati dall'amministratore, gli strumenti di monitoraggio contengono strumenti per l'individuazione automatica di potenziali problemi. Ad esempio, è possibile configurare un trigger che scatta nel caso in cui lo spazio libero su disco scenda al di sotto di una soglia specificata. È anche possibile diagnosticare automaticamente un arresto del server o un rallentamento critico delle prestazioni. Nella pratica, gli strumenti di monitoraggio riescono a rilevare abbastanza bene i guasti già verificatisi o a identificare sintomi semplici di guasti futuri, ma in generale la previsione di un possibile guasto rimane una sfida difficile. La previsione tramite analisi manuale delle metriche richiede l'intervento di specialisti qualificati ed è poco produttiva. La maggior parte dei guasti potenziali può rimanere inosservata.
Negli ultimi tempi, tra le grandi aziende IT che sviluppano software, sta guadagnando sempre più popolarità il cosiddetto servizio di manutenzione predittiva dei sistemi software. L'essenza di questo approccio consiste nell'individuare i malfunzionamenti che portano a una degradazione del sistema nelle fasi iniziali, prima che si verifichi un guasto, utilizzando l'intelligenza artificiale. Questo approccio non esclude completamente il monitoraggio manuale del sistema, ma lo considera un supporto al processo di monitoraggio nel complesso.
Lo strumento principale per implementare la manutenzione predittiva è il compito di ricerca di anomali nelle serie temporali, poiché quando si verifica un'anomalia nei dati c'è una grande probabilità che, dopo un certo tempo si verificherà un errore o un guasto. Un'anomalia è una deviazione nei parametri di un sistema software, come il riconoscimento di una degradazione della velocità di esecuzione di un tipo di richiesta o una diminuzione del numero medio di richieste gestite a fronte di un livello costante di sessioni client.
Il compito di cercare anomalie nei sistemi software ha le sue peculiarità. In teoria, per ogni sistema software è necessaria la creazione o l'adattamento dei metodi esistenti, poiché la ricerca di anomalie dipende molto dai dati in cui viene effettuata, e i dati dei sistemi software variano notevolmente a seconda degli strumenti di realizzazione, fino a che tipo di macchina di calcolo è in uso.
Metodi di ricerca di anomalie nella previsione dei guasti dei sistemi software
Prima di tutto, bisogna dire che l'idea della previsione dei guasti è stata ispirata dall'articolo . Per testare l'efficacia dell'approccio di ricerca automatica delle anomalie è stato scelto il sistema software «Web-Consolidation», uno dei progetti dell'azienda NPO «Krista». In precedenza, per questo sistema era stato effettuato un monitoraggio manuale basato sui metriche ricevute. Poiché il sistema è piuttosto complesso, vengono estratte numerose metriche: parametri della JVM (carico del garbage collector), parametri del sistema operativo su cui viene eseguito il codice (memoria virtuale, % di utilizzo della CPU), parametri di rete (carico della rete), del server stesso (carico della CPU, della memoria), metriche di wildfly e metriche proprie dell'applicazione su tutti i sottosistemi critici.
Tutte le metriche vengono estratte dal sistema tramite graphite. Inizialmente è stato utilizzato il database whisper come soluzione standard per grafana, ma con la crescita della base clienti graphite ha smesso di essere sufficientemente performante, esaurendo la capacità del sistema di archiviazione del centro dati. Dopo ciò, è stata presa la decisione di cercare una soluzione più efficace. La scelta è ricaduta su , il che ha permesso di ridurre notevolmente il carico sul sistema di archiviazione e di ridurre il volume di archiviazione occupato di cinque-sei volte. Di seguito viene presentato lo schema del meccanismo di raccolta delle metriche tramite graphite+clickhouse (figura 2).
Figura 2. Schema di estrazione delle metriche
Lo schema è stato preso dalla documentazione interna. Mostra lo scambio di dati tra grafana (interfaccia utente per il monitoraggio che utilizziamo) e graphite. La raccolta delle metriche dall'applicazione è effettuata da un software separato – . Questo quindi le archivia in graphite.
Il sistema «Web-Consolidation» presenta una serie di caratteristiche che creano problemi nella previsione dei guasti:
- c'è spesso un cambiamento di trend. Per questo sistema software vengono rilasciate diverse versioni. Ognuna di esse comporta modifiche nella parte software del sistema. Pertanto, in questo modo gli sviluppatori influenzano direttamente le metriche di questo sistema e possono indurre un cambiamento di trend;
- la peculiarità dell'implementazione, così come gli obiettivi di utilizzo da parte dei clienti di questo sistema, spesso evocano anomalie senza una precedente degradazione;
- la percentuale di anomalie rispetto all'intero set di dati è bassa (< 5%);
- possono verificarsi interruzioni nella ricezione delle metriche dal sistema. In alcuni brevi intervalli di tempo, il sistema di monitoraggio non riesce a ottenere le metriche. Ad esempio, se il server è sovraccarico. Per l'addestramento della rete neurale, questo è critico. Si rende necessaria la sintesi per riempire i gap;
- I casi di anomalie sono spesso rilevanti solo per un numero/mese/tempo specifico (stagionalità). Questo sistema ha un regolamento chiaro per l'utilizzo da parte degli utenti. Pertanto, le metriche sono pertinenti solo per un periodo di tempo specifico. Il sistema può non essere utilizzato in modo costante, ma solo in alcuni mesi: in modo selettivo a seconda dell'anno. Si presentano situazioni in cui lo stesso comportamento delle metriche in un caso può portare al guasto del sistema software, mentre in un altro no.
Inizialmente, sono stati analizzati i metodi per la rilevazione delle anomalie nei dati di monitoraggio dei sistemi software. Negli articoli su questo tema, quando le anomalie rappresentano una bassa percentuale rispetto al resto del set di dati, si propone spesso di utilizzare reti neurali.
La logica principale per la ricerca di anomalie tramite i dati delle reti neurali è illustrata nella figura 3:
Figura 3. Ricerca di anomalie tramite rete neurale
Il risultato della previsione o del ripristino della finestra dell'attuale flusso di metriche calcola la deviazione rispetto ai dati ricevuti da un sistema software funzionante. In caso di grande differenza tra le metriche ricevute dal sistema software e la rete neurale, si può concludere che esiste un'anomalia nel segmento dati attuale. Si presenta una serie di problemi per l'utilizzo delle reti neurali:
- per un corretto funzionamento in modalità streaming, i dati per l'addestramento dei modelli delle reti neurali devono includere solo dati "normali";
- è necessario avere un modello attuale per una corretta rilevazione. Un cambiamento di trend e stagionalità nelle metriche può causare un elevato numero di falsi positivi nel modello. Per aggiornarlo, è necessario definire chiaramente il momento in cui il modello diventa obsoleto. Se il modello viene aggiornato troppo tardi o troppo presto, è probabile che ci siano troppi falsi positivi.
Inoltre, non bisogna dimenticare di cercare e prevenire il verificarsi frequente di falsi positivi. Si presume che essi si verifichino più spesso in situazioni anomale. Tuttavia, potrebbero anche dipendere da errori della rete neurale a causa di un'istruzione insufficiente. È necessario minimalizzare il numero di falsi positivi nel modello. In caso contrario, le previsioni errate richiederanno molto tempo all'amministratore, destinato al controllo del sistema. Prima o poi, l'amministratore smetterà di reagire a un sistema di monitoraggio "paranoico".
Rete neurale ricorrente
Per rilevare anomalie nelle serie temporali è possibile applicare con memoria LSTM. Il problema è che essa può essere utilizzata solo per le serie temporali prevedibili. Nel nostro caso, non tutte le metriche sono prevedibili. Il tentativo di applicare RNN LSTM a una serie temporale è rappresentato nella figura 4.
Figura 4. Esempio di funzionamento di una rete neurale ricorrente con celle di memoria LSTM
Come si può vedere dalla figura 4, la RNN LSTM è riuscita a gestire la ricerca di anomalie in questo intervallo di tempo. Lì dove il risultato ha un alto errore di previsione (errore medio), si è effettivamente verificata un'anomalia nei dati. L'uso di una sola RNN LSTM sarà chiaramente insufficiente, poiché è applicabile a un numero limitato di metriche. Si può utilizzare come metodo ausiliario per la ricerca di anomalie.
Autoencoder per la previsione dei guasti
– in sostanza una rete neurale artificiale. Il livello di input – encoder, il livello di output – decoder. Lo svantaggio di tutte le reti neurali di questo tipo è che localizzano male le anomalie. È stata scelta un'architettura di autoencoder sincrono.
Figura 5. Esempio di funzionamento dell'autoencoder
Gli autoencoder si addestrano su dati normali e poi trovano qualcosa di anomalo nei dati forniti al modello. Proprio ciò di cui abbiamo bisogno per questo compito. Resta solo da scegliere quale dei diversi autoencoder si adatti a questa esigenza. La forma architettonicamente più semplice di un autoencoder è una rete neurale feedforward che assomiglia molto a (multilayer perceptron, MLP), con un livello di input, un livello di output e uno o più livelli nascosti che li collegano.
Tuttavia, le differenze tra gli autoencoder e il MLP consistono nel fatto che nell'autoencoder il livello di output ha lo stesso numero di nodi del livello di input e che invece di essere addestrato per prevedere il valore target Y dato l'input X, l'autoencoder viene addestrato a ricostruire i propri X. Pertanto, gli autoencoder sono modelli di apprendimento non supervisionato.
Il compito dell'autoencoder è quello di trovare gli indici temporali r0 … rn corrispondenti agli elementi anomali nel vettore di input X. Questo effetto si ottiene attraverso la ricerca dell'errore quadratico.
Figura 6. Autoencoder sincrono
Per l'autoencoder è stata scelta . I suoi vantaggi: possibilità di utilizzare la modalità di elaborazione in streaming e un numero relativamente inferiore di parametri della rete neurale rispetto ad altre architetture.
Il meccanismo di minimizzazione dei falsi allarmi
A causa del verificarsi di diverse situazioni straordinarie, così come della possibilità di un'adeguata formazione della rete neurale, è stata presa la decisione di sviluppare un meccanismo per minimizzare i falsi allarmi per il modello di rilevamento delle anomalie in fase di sviluppo. Questo meccanismo si basa su una base di modelli che viene classificata dall'amministratore.
(algoritmo DTW, dall'inglese dynamic time warping) consente di trovare la corrispondenza ottimale tra sequenze temporali. È stato applicato per la prima volta nel riconoscimento vocale: utilizzato per determinare come due segnali vocali rappresentano la stessa frase pronunciata. In seguito, è stato trovato impiego in altri settori.
Il principio fondamentale per minimizzare i falsi allarmi è raccogliere una base di riferimenti attraverso l'operatore, che classifica i casi sospetti individuati tramite reti neurali. Successivamente, si confronta il modello classificato con il caso rilevato dal sistema, e si trae una conclusione sulla sua appartenenza a un falso allerta o a un guasto. Proprio per il confronto di due serie temporali si utilizza l'algoritmo DTW. Lo strumento principale per la minimizzazione rimane comunque la classificazione. Si presume che dopo aver raccolto un gran numero di casi di riferimento, il sistema inizierà a richiedere meno l'intervento dell'operatore a causa della somiglianza della maggior parte dei casi e della ricorrenza di situazioni affini.
Alla fine, sulla base dei metodi descritti sopra, è stato sviluppato un programma sperimentale per la previsione dei guasti del sistema "Web-Consulenza". L'obiettivo di questo programma era valutare l'efficacia di questo approccio per i nostri sistemi software utilizzando l'archivio di dati di monitoraggio esistente e le informazioni sui guasti già avvenuti. Lo schema di funzionamento del programma è mostrato di seguito nella figura 7.
Figura 7. Schema di previsione dei guasti basato sull'analisi dello spazio delle metriche
Nello schema si possono distinguere due blocchi principali: la ricerca di segmenti temporali anomali nel flusso di dati di monitoraggio (metriche) e il meccanismo di minimizzazione dei falsi allarmi. Nota: per scopi sperimentali, i dati vengono ottenuti tramite connessione JDBC da un database in cui vengono salvati tramite graphite.
Di seguito è presentata l'interfaccia del sistema di monitoraggio sviluppato (figura 8).
Figura 8. Interfaccia del sistema di monitoraggio sperimentale
Nell'interfaccia viene visualizzata la percentuale di anomalia per le metriche ricevute. Nel nostro caso, il ricevimento è simulato. Abbiamo già tutti i dati di diverse settimane e li carichiamo gradualmente per verificare un caso di anomalia che porta a un guasto. Nella barra di stato in basso viene mostrata la percentuale complessiva di anomalia dei dati in quel momento, che è determinata tramite un auto-codificatore. Inoltre, per le metriche previste viene visualizzata una percentuale separata, calcolata da RNN LSTM.
Esempio di rilevamento di anomalia nei parametri della CPU utilizzando la rete neurale RNN LSTM (figura 9).
Figura 9. Rilevamento RNN LSTM
Un caso piuttosto semplice, essenzialmente un comune outlier, ma che porta a un guasto del sistema, è stato calcolato con successo utilizzando RNN LSTM. Il valore di anomalia in questo intervallo di tempo è compreso tra l'85 e il 95%; tutto ciò che supera l'80% (soglia stabilita sperimentalmente) è considerato un'anomalia.
Esempio di rilevamento di anomalia, quando il sistema non è riuscito a caricarsi dopo un aggiornamento. Questa situazione viene rilevata dall'auto-codificatore (figura 10).
Figura 10. Esempio di rilevamento da parte dell'auto-codificatore
Come si può vedere dalla figura, PermGen è rimasto a un livello costante. L'auto-codificatore ha considerato questo strano, poiché non aveva mai visto nulla di simile in precedenza. Qui, l'anomalia rimane al 100% fino al ritorno del sistema in uno stato operativo. L'anomalia si riflette su tutte le metriche. Come detto in precedenza, l'auto-codificatore non è in grado di localizzare le anomalie. L'operatore è incaricato di svolgere questa funzione in queste situazioni.
Conclusione
Il PC "Web-Consolidazione" è in fase di sviluppo da diversi anni. Il sistema è in uno stato sufficientemente stabile e il numero di incidenti registrati è ridotto. Tuttavia, è stato possibile individuare anomalie che portano a guasti da 5 a 10 minuti prima dell'insorgere del guasto. In alcuni casi, il preavviso di guasto avrebbe potuto aiutare a risparmiare tempo programmato, dedicato alle operazioni di "riparazione".
Per gli esperimenti condotti, è ancora prematuro trarre conclusioni definitive. Al momento, i risultati sono contraddittori. Da un lato, è evidente che gli algoritmi basati su reti neurali sono in grado di identificare anomalie "utili". Dall'altro lato, persiste un alto tasso di falsi positivi, e non tutte le anomalie individuate da un esperto qualificato possono essere rilevate dalla rete neurale. Tra i punti negativi si può anche menzionare che attualmente la rete neurale richiede un apprendimento supervisionato per funzionare correttamente.
Per lo sviluppo futuro del sistema di previsione dei guasti e per portarlo a uno stato soddisfacente, si possono prevedere diverse strade. Un'analisi più dettagliata dei casi di anomalie che portano a un guasto, che consente di ampliare l'elenco delle metriche importanti che influenzano notevolmente lo stato del sistema, scartando quelle superflue, è una di queste. Inoltre, perseguendo questa direzione, si possono tentare specializzazioni degli algoritmi specificamente per i nostri casi di anomalie che portano ai guasti. C'è anche un'altra possibilità: migliorare le architetture delle reti neurali e aumentare così la precisione delle rilevazioni riducendo i tempi di apprendimento.
Esprimo la mia gratitudine ai colleghi che mi hanno assistito nella scrittura e nell'aggiornamento di questo articolo: e Sergey Finogenov.
Fonte: habr.com
