Lo sviluppo industriale dei sistemi software richiede grande attenzione alla tolleranza agli errori del prodotto finale, nonché una risposta rapida ai guasti e ai guasti qualora si verifichino. Il monitoraggio, ovviamente, aiuta a rispondere a guasti e guasti in modo più efficiente e rapido, ma non è sufficiente. In primo luogo, è molto difficile tenere traccia di un gran numero di server: è necessario un gran numero di persone. In secondo luogo, è necessario comprendere bene il funzionamento dell'applicazione per prevederne lo stato. Pertanto, abbiamo bisogno di molte persone che abbiano una buona conoscenza dei sistemi che stiamo sviluppando, delle loro prestazioni e caratteristiche. Supponiamo che anche se trovi abbastanza persone disposte a farlo, ci vuole comunque molto tempo per addestrarle.
Cosa fare? È qui che l’intelligenza artificiale ci viene in aiuto. L'articolo parlerà di (manutenzione predittiva). Questo approccio sta guadagnando attivamente popolarità. Sono stati scritti numerosi articoli, anche su Habré. Le grandi aziende sfruttano appieno questo approccio per mantenere le prestazioni dei propri server. Dopo aver studiato un gran numero di articoli, abbiamo deciso di provare questo approccio. Cosa ne è venuto fuori?
Introduzione
Il sistema software sviluppato prima o poi entra in funzione. Per l'utente è importante che il sistema funzioni senza guasti. Se si verifica un’emergenza, dovrebbe essere risolta con un ritardo minimo.
Per semplificare il supporto tecnico di un sistema software, soprattutto se sono presenti molti server, vengono solitamente utilizzati programmi di monitoraggio che ricavano parametri da un sistema software in esecuzione, consentono di diagnosticarne le condizioni e aiutano a determinare cosa ha causato esattamente il guasto. Questo processo è chiamato monitoraggio del sistema software.
Figura 1. Interfaccia di monitoraggio Grafana
Le metriche sono vari indicatori di un sistema software, del suo ambiente di esecuzione o del computer fisico su cui è in esecuzione il sistema con un timestamp del momento in cui le metriche sono state ricevute. Nell'analisi statica, queste metriche sono chiamate serie temporali. Per monitorare lo stato del sistema software, le metriche vengono visualizzate sotto forma di grafici: il tempo è sull'asse X e i valori sono lungo l'asse Y (Figura 1). Diverse migliaia di parametri possono essere ricavati da un sistema software in esecuzione (da ciascun nodo). Formano uno spazio di metriche (serie temporali multidimensionali).
Poiché viene raccolto un gran numero di parametri per sistemi software complessi, il monitoraggio manuale diventa un compito difficile. Per ridurre la quantità di dati analizzati dall'amministratore, gli strumenti di monitoraggio contengono strumenti per identificare automaticamente possibili problemi. Ad esempio, puoi configurare un trigger affinché si attivi quando lo spazio libero su disco scende al di sotto di una soglia specificata. Puoi anche diagnosticare automaticamente l'arresto del server o un rallentamento critico della velocità del servizio. In pratica, gli strumenti di monitoraggio fanno un buon lavoro nel rilevare i guasti che si sono già verificati o nell’identificare semplici sintomi di guasti futuri, ma in generale, prevedere un possibile guasto rimane un osso duro per loro. La previsione attraverso l'analisi manuale delle metriche richiede il coinvolgimento di specialisti qualificati. È una bassa produttività. La maggior parte dei potenziali fallimenti potrebbero passare inosservati.
Recentemente, la cosiddetta manutenzione predittiva dei sistemi software è diventata sempre più popolare tra le grandi aziende di sviluppo software IT. L’essenza di questo approccio è individuare i problemi che portano al degrado del sistema nelle fasi iniziali, prima che fallisca, utilizzando l’intelligenza artificiale. Questo approccio non esclude completamente il monitoraggio manuale del sistema. È ausiliario al processo di monitoraggio nel suo insieme.
Lo strumento principale per implementare la manutenzione predittiva è il compito di ricercare anomalie nelle serie temporali, poiché quando si verifica un'anomalia nei dati c'è un'alta probabilità che dopo qualche tempo ci sarà un fallimento o un fallimento. Un'anomalia è una certa deviazione nelle prestazioni di un sistema software, come l'identificazione di un degrado nella velocità di esecuzione di un tipo di richiesta o una diminuzione del numero medio di richieste servite a un livello costante di sessioni client.
Il compito di ricercare anomalie per i sistemi software ha le sue specificità. In teoria, per ogni sistema software è necessario sviluppare o affinare metodi esistenti, poiché la ricerca di anomalie dipende molto dai dati in cui viene eseguita, e i dati dei sistemi software variano molto a seconda degli strumenti per implementare il sistema , fino al computer su cui è in esecuzione.
Metodi per la ricerca di anomalie nella previsione dei guasti dei sistemi software
Innanzitutto va detto che l’idea di prevedere i fallimenti è stata ispirata dall’articolo . Per testare l'efficacia dell'approccio con ricerca automatica delle anomalie è stato scelto il sistema software Web-Consolidation, che è uno dei progetti della società NPO Krista. In precedenza, veniva effettuato il monitoraggio manuale in base alle metriche ricevute. Poiché il sistema è piuttosto complesso, vengono presi in considerazione numerosi parametri: indicatori JVM (carico del Garbage Collector), indicatori del sistema operativo in cui viene eseguito il codice (memoria virtuale, % di carico della CPU del sistema operativo), indicatori di rete (carico di rete ), il server stesso (carico della CPU, memoria), parametri selvaggi e parametri propri dell'applicazione per tutti i sottosistemi critici.
Tutte le metriche sono prese dal sistema utilizzando la grafite. Inizialmente, il database Whisper veniva utilizzato come soluzione standard per Grafana, ma con la crescita della base clienti, la grafite non poteva più farcela, avendo esaurito la capacità del sottosistema del disco DC. Successivamente si è deciso di trovare una soluzione più efficace. La scelta è stata fatta a favore , che ha permesso di ridurre il carico sul sottosistema del disco di un ordine di grandezza e di ridurre lo spazio su disco occupato da cinque a sei volte. Di seguito è riportato un diagramma del meccanismo per la raccolta dei parametri utilizzando grafite+clickhouse (Figura 2).
Figura 2. Schema per la raccolta dei parametri
Lo schema è tratto dalla documentazione interna. Mostra la comunicazione tra grafana (l'interfaccia utente di monitoraggio che utilizziamo) e grafite. La rimozione delle metriche da un'applicazione viene eseguita da un software separato: . Li mette in grafite.
Il sistema Web Consolidation presenta una serie di funzionalità che creano problemi nella previsione dei guasti:
- La tendenza cambia spesso. Per questo sistema software sono disponibili diverse versioni. Ognuno di essi apporta modifiche alla parte software del sistema. Di conseguenza, in questo modo, gli sviluppatori influenzano direttamente le metriche di un dato sistema e possono provocare un cambiamento di tendenza;
- le caratteristiche di implementazione, così come gli scopi per i quali i clienti utilizzano questo sistema, spesso causano anomalie senza precedenti degradi;
- la percentuale di anomalie relativa all'intero data set è piccola (< 5%);
- Potrebbero esserci delle lacune nel ricevere gli indicatori dal sistema. In alcuni brevi periodi di tempo, il sistema di monitoraggio non riesce a ottenere metriche. Ad esempio, se il server è sovraccarico. Questo è fondamentale per addestrare una rete neurale. È necessario colmare sinteticamente le lacune;
- I casi con anomalie sono spesso rilevanti solo per una data/mese/ora specifica (stagionalità). Questo sistema ha regole chiare per il suo utilizzo da parte degli utenti. Di conseguenza, le metriche sono rilevanti solo per un periodo di tempo specifico. Il sistema non può essere utilizzato costantemente, ma solo in alcuni mesi: selettivamente a seconda dell'anno. Si verificano situazioni in cui lo stesso comportamento delle metriche in un caso può portare al guasto del sistema software, ma non in un altro.
Per cominciare, sono stati analizzati i metodi per rilevare anomalie nel monitoraggio dei dati dei sistemi software. Negli articoli su questo argomento, quando la percentuale di anomalie è piccola rispetto al resto del set di dati, viene spesso proposto di utilizzare le reti neurali.
La logica di base per la ricerca di anomalie utilizzando i dati della rete neurale è mostrata nella Figura 3:
Figura 3. Ricerca di anomalie utilizzando una rete neurale
In base al risultato della previsione o ripristino della finestra del flusso corrente di metriche, viene calcolata la deviazione da quella ricevuta dal sistema software in esecuzione. Se c'è una grande differenza tra le metriche ottenute dal sistema software e dalla rete neurale, possiamo concludere che il segmento di dati corrente è anomalo. Per quanto riguarda l’utilizzo delle reti neurali sorgono i seguenti problemi:
- per funzionare correttamente in modalità streaming, i dati per l'addestramento dei modelli di rete neurale devono includere solo dati “normali”;
- è necessario disporre di un modello aggiornato per un corretto rilevamento. Il cambiamento delle tendenze e della stagionalità delle metriche può causare un gran numero di falsi positivi nel modello. Per aggiornarlo, è necessario determinare chiaramente il momento in cui il modello è obsoleto. Se aggiorni il modello più tardi o prima, molto probabilmente seguirà un gran numero di falsi positivi.
Non dobbiamo inoltre dimenticare la ricerca e la prevenzione del frequente verificarsi di falsi positivi. Si presume che si verifichino più spesso in situazioni di emergenza. Potrebbero però anche essere la conseguenza di un errore della rete neurale dovuto ad un addestramento insufficiente. È necessario ridurre al minimo il numero di falsi positivi del modello. In caso contrario, false previsioni faranno sprecare molto tempo all'amministratore destinato a controllare il sistema. Prima o poi l'amministratore semplicemente smetterà di rispondere al sistema di monitoraggio “paranoico”.
Rete neurale ricorrente
Per rilevare anomalie nelle serie temporali, è possibile utilizzare con memoria LSTM. L'unico problema è che può essere utilizzato solo per serie temporali previste. Nel nostro caso, non tutti i parametri sono prevedibili. Un tentativo di applicare RNN LSTM a una serie temporale è mostrato nella Figura 4.
Figura 4. Esempio di rete neurale ricorrente con celle di memoria LSTM
Come si può vedere dalla Figura 4, RNN LSTM è stata in grado di far fronte alla ricerca di anomalie in questo periodo di tempo. Laddove il risultato presenta un errore di previsione elevato (errore medio), si è effettivamente verificata un'anomalia negli indicatori. L’utilizzo di un singolo RNN LSTM chiaramente non sarà sufficiente, poiché è applicabile a un numero limitato di parametri. Può essere utilizzato come metodo ausiliario per la ricerca di anomalie.
Codificatore automatico per la previsione dei guasti
– essenzialmente una rete neurale artificiale. Lo strato di input è il codificatore, lo strato di output è il decodificatore. Lo svantaggio di tutte le reti neurali di questo tipo è che non localizzano bene le anomalie. È stata scelta un'architettura di codifica automatica sincrona.
Figura 5. Esempio di funzionamento del codificatore automatico
Gli autocodificatori vengono addestrati su dati normali e quindi trovano qualcosa di anomalo nei dati forniti al modello. Proprio quello che ti serve per questo compito. Non resta che scegliere quale autoencoder è adatto a questo compito. La forma architettonicamente più semplice di un autocodificatore è una rete neurale diretta e di non ritorno, molto simile a (perceptron multistrato, MLP), con uno strato di input, uno strato di output e uno o più strati nascosti che li collegano.
Tuttavia, le differenze tra autoencoder e MLP sono che in un autoencoder, lo strato di output ha lo stesso numero di nodi dello strato di input e che invece di essere addestrato a prevedere un valore target Y dato da un input X, l'autoencoder è addestrato per ricostruire le proprie X. Pertanto, gli Autoencoder sono modelli di apprendimento non supervisionato.
Il compito dell'autoencoder è trovare gli indici temporali r0 ... rn corrispondenti agli elementi anomali nel vettore di ingresso X. Questo effetto si ottiene ricercando l'errore quadratico.
Figura 6. Codificatore automatico sincrono
Per l'autoencoder è stato selezionato . I suoi vantaggi: la possibilità di utilizzare la modalità di elaborazione in streaming e un numero relativamente inferiore di parametri di rete neurale rispetto ad altre architetture.
Meccanismo per ridurre al minimo i falsi positivi
A causa del fatto che si verificano varie situazioni anomale, nonché una possibile situazione di addestramento insufficiente della rete neurale, per il modello di rilevamento delle anomalie in fase di sviluppo, si è deciso che fosse necessario sviluppare un meccanismo per ridurre al minimo i falsi positivi. Questo meccanismo si basa su un database modello classificato dall'amministratore.
(Algoritmo DTW, dall'inglese Dynamic Time Warping) consente di trovare la corrispondenza ottimale tra sequenze temporali. Utilizzato per la prima volta nel riconoscimento vocale: utilizzato per determinare come due segnali vocali rappresentano la stessa frase parlata originale. Successivamente è stata trovata applicazione in altri settori.
Il principio fondamentale per ridurre al minimo i falsi positivi è raccogliere un database di standard con l'aiuto di un operatore che classifica i casi sospetti rilevati utilizzando le reti neurali. Successivamente, lo standard classificato viene confrontato con il caso rilevato dal sistema e si conclude se il caso è falso o porta a un fallimento. È proprio per confrontare due serie temporali che viene utilizzato l’algoritmo DTW. Il principale strumento di minimizzazione è ancora la classificazione. Si prevede che dopo aver raccolto un gran numero di casi di riferimento, il sistema inizierà a chiedere meno all'operatore a causa della somiglianza della maggior parte dei casi e del verificarsi di casi simili.
Di conseguenza, sulla base dei metodi di rete neurale sopra descritti, è stato costruito un programma sperimentale per prevedere i guasti del sistema “Web-Consolidation”. L'obiettivo di questo programma era, utilizzando l'archivio esistente di dati di monitoraggio e informazioni sui guasti precedenti, valutare la competenza di questo approccio per i nostri sistemi software. Lo schema del programma è presentato di seguito nella Figura 7.
Figura 7. Schema di previsione dei guasti basato sull'analisi dello spazio metrico
Nel diagramma si possono distinguere due blocchi principali: la ricerca di periodi di tempo anomali nel flusso di dati di monitoraggio (metriche) e il meccanismo per ridurre al minimo i falsi positivi. Nota: a scopo sperimentale, i dati vengono ottenuti tramite una connessione JDBC dal database in cui la grafite li salverà.
Quella che segue è l'interfaccia del sistema di monitoraggio ottenuta a seguito dello sviluppo (Figura 8).
Figura 8. Interfaccia del sistema di monitoraggio sperimentale
L'interfaccia visualizza la percentuale di anomalia in base alle metriche ricevute. Nel nostro caso lo scontrino è simulato. Abbiamo già tutti i dati da diverse settimane e li stiamo caricando gradualmente per verificare il caso di un'anomalia che porti al guasto. La barra di stato inferiore visualizza la percentuale complessiva di anomalia dei dati in un dato momento, determinata utilizzando un codificatore automatico. Inoltre, viene visualizzata una percentuale separata per le metriche previste, calcolata da RNN LSTM.
Un esempio di rilevamento di anomalie basato sulle prestazioni della CPU utilizzando la rete neurale RNN LSTM (Figura 9).
Figura 9. Rilevamento RNN LSTM
Un caso abbastanza semplice, essenzialmente un valore anomalo ordinario, ma che ha portato al guasto del sistema, è stato calcolato con successo utilizzando RNN LSTM. L'indicatore di anomalia in questo periodo di tempo è dell'85–95%; tutto ciò che è superiore all'80% (la soglia è stata determinata sperimentalmente) è considerato un'anomalia.
Un esempio di rilevamento di un'anomalia quando il sistema non è riuscito ad avviarsi dopo un aggiornamento. Questa situazione viene rilevata dall'autoencoder (Figura 10).
Figura 10. Esempio di rilevamento del codificatore automatico
Come puoi vedere dalla figura, PermGen è bloccato ad un livello. L'autocodificatore lo trovò strano perché non aveva mai visto nulla di simile prima. Qui l'anomalia rimane al 100% finché il sistema non ritorna in uno stato funzionante. Viene visualizzata un'anomalia per tutte le metriche. Come accennato in precedenza, l'autocodificatore non può localizzare le anomalie. L'operatore è chiamato a svolgere questa funzione in queste situazioni.
conclusione
Il PC "Web-Consolidation" è in sviluppo da diversi anni. Il sistema è in uno stato abbastanza stabile e il numero di incidenti registrati è piccolo. Tuttavia, è stato possibile riscontrare anomalie che portavano al guasto 5 - 10 minuti prima che si verificasse il guasto. In alcuni casi, la notifica anticipata di un guasto aiuterebbe a risparmiare il tempo previsto per l'esecuzione dei lavori di "riparazione".
Sulla base degli esperimenti condotti è troppo presto per trarre conclusioni definitive. Finora i risultati sono contrastanti. Da un lato è chiaro che gli algoritmi basati sulle reti neurali sono in grado di trovare anomalie “utili”. D'altra parte, rimane una grande percentuale di falsi positivi e non tutte le anomalie rilevate da uno specialista qualificato in una rete neurale possono essere rilevate. Gli svantaggi includono il fatto che ora la rete neurale richiede la formazione con un insegnante per il normale funzionamento.
Per sviluppare ulteriormente il sistema di previsione dei guasti e portarlo ad uno stato soddisfacente, si possono prevedere diversi modi. Si tratta di un'analisi più dettagliata dei casi con anomalie che portano al fallimento, a causa dell'aggiunta all'elenco di metriche importanti che influenzano notevolmente lo stato del sistema e dell'eliminazione di quelle non necessarie che non lo influenzano. Inoltre, se ci muoviamo in questa direzione, possiamo tentare di specializzare gli algoritmi appositamente per i nostri casi con anomalie che portano a fallimenti. C'è un altro modo. Si tratta di un miglioramento delle architetture delle reti neurali e quindi di un aumento della precisione di rilevamento con una riduzione dei tempi di addestramento.
Esprimo la mia gratitudine ai miei colleghi che mi hanno aiutato a scrivere e a mantenere la rilevanza di questo articolo: e Sergei Finogenov.
Fonte: habr.com