{"id":53531,"date":"2019-12-04T00:00:00","date_gmt":"2019-12-03T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/ishhem-anomalii-i-predskazyvaem-sboi-s-pomoshhyu-nejrosetej"},"modified":"2020-02-18T14:01:26","modified_gmt":"2020-02-18T11:01:26","slug":"ishhem-anomalii-i-predskazyvaem-sboi-s-pomoshhyu-nejrosetej","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/ishhem-anomalii-i-predskazyvaem-sboi-s-pomoshhyu-nejrosetej","title":{"rendered":"Riconosciamo anomalie e prevediamo guasti attraverso le reti neurali.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Riconosciamo<\/p>\n

<\/p>\n

Lo sviluppo industriale di sistemi software richiede molta attenzione alla resilienza del prodotto finale, oltre a una rapida risposta in caso di guasti o malfunzionamenti, se si verificano. Certo, il monitoraggio aiuta a reagire ai guasti in modo pi\u00f9 efficiente e veloce, ma non \u00e8 sufficiente. In primo luogo, \u00e8 molto difficile tenere traccia di un gran numero di server \u2013 \u00e8 necessario un grande numero di persone. In secondo luogo, \u00e8 importante comprendere bene come \u00e8 strutturata l'applicazione, per poter prevedere il suo stato. Pertanto, \u00e8 necessaria una squadra di esperti che conosca a fondo i sistemi che sviluppiamo, i loro indicatori e le loro caratteristiche. Anche supponendo di trovare un numero sufficiente di persone desiderose di occuparsene, occorre ancora tempo per formarli.<\/p>\n

<\/p>\n

Cosa fare? Qui ci viene in aiuto l'intelligenza artificiale. Questo articolo parler\u00e0 di manutenzione predittiva.<\/a><\/noindex> (manutenzione predittiva). Questo approccio sta guadagnando popolarit\u00e0. Sono stati scritti numerosi articoli, anche su Habr. Le grandi aziende stanno adottando questo metodo per mantenere operativi i propri server. Dopo aver esaminato molti articoli, abbiamo deciso di provare ad applicare questo approccio. Che cosa ne \u00e8 uscito? <\/p>\n

<\/a><\/noindex><\/p>\n

Introduzione<\/h2>\n

<\/p>\n

Un sistema software sviluppato entra in produzione prima o poi. Per l'utente \u00e8 importante che il sistema funzioni senza interruzioni. Se si verifica un'emergenza, deve essere risolta con il minor ritardo possibile. <\/p>\n

<\/p>\n

Per semplificare il supporto tecnico del sistema software, specialmente se ci sono molti server, si usano di solito programmi di monitoraggio che raccolgono metriche dal sistema in esecuzione, permettono di diagnosticare il suo stato e aiutano a determinare cosa ha causato il guasto. Questo processo \u00e8 chiamato monitoraggio del sistema software.<\/p>\n

\n\"Riconosciamo<\/p>\n

Figura 1. Interfaccia per il monitoraggio grafana<\/em><\/p>\n

Le metriche sono diversi indicatori del sistema software, dell'ambiente di esecuzione o della macchina fisica su cui \u00e8 in esecuzione il sistema, registrando il momento in cui sono state raccolte le metriche. Nell'analisi statica, i dati delle metriche sono chiamati serie temporali. Per monitorare lo stato del sistema software, le metriche vengono visualizzate in forma di grafici: sull'asse X c'\u00e8 il tempo, mentre sull'asse Y i valori (figura 1). Un sistema software attivo pu\u00f2 generare diverse migliaia di metriche (da ciascun nodo). Queste formano uno spazio metrico (serie temporali multidimensionali). <\/p>\n

<\/p>\n

Poich\u00e9 nei sistemi software complessi vengono raccolti un gran numero di metriche, il monitoraggio manuale diventa un compito difficile. Per ridurre la quantit\u00e0 di dati da analizzare, gli strumenti di monitoraggio contengono funzioni per rilevare automaticamente potenziali problemi. Ad esempio, \u00e8 possibile impostare un trigger che scatta quando lo spazio libero su disco scende al di sotto di una certa soglia. \u00c8 anche possibile diagnosticare automaticamente l'arresto del server o un significativo rallentamento delle prestazioni. In pratica, gli strumenti di monitoraggio si rivelano efficaci nel rilevare guasti gi\u00e0 avvenuti o nel riconoscere sintomi semplici di guasti futuri, ma in generale la previsione di un possibile guasto rimane una sfida. La previsione tramite analisi manuale delle metriche richiede specialisti qualificati ed \u00e8 poco produttiva. La maggior parte dei potenziali guasti pu\u00f2 rimanere inosservata.<\/p>\n

<\/p>\n

Negli ultimi tempi, tra le grandi aziende IT specializzate nello sviluppo software, sta guadagnando sempre pi\u00f9 popolarit\u00e0 il cosiddetto servizio predittivo per i sistemi software. Questo approccio si basa sull'individuazione precoce di guasti che possono portare alla degradazione del sistema, prima che si verifichi un malfunzionamento, facendo uso dell'intelligenza artificiale. Questo metodo non esclude completamente il monitoraggio manuale del sistema, ma funge da supporto al processo di monitoraggio in generale. <\/p>\n

<\/p>\n

Lo strumento principale per attuare il servizio predittivo \u00e8 la rilevazione di anomalie nelle serie temporali, poich\u00e9 quando si verifica un'anomalia<\/strong> nei dati \u00e8 alta la probabilit\u00e0 che, dopo un po', si verifichi un guasto o un malfunzionamento<\/strong>. Un'anomalia \u00e8 un certo scostamento delle metriche del sistema software, come l'individuazione della degradazione della velocit\u00e0 di risposta per uno specifico tipo di richiesta o la riduzione del numero medio di richieste gestite a fronte di un numero costante di sessioni client.<\/p>\n

<\/p>\n

La ricerca di anomalie per i sistemi software presenta delle specificit\u00e0. In linea di principio, per ogni sistema software \u00e8 necessaria la creazione o l'adattamento dei metodi esistenti, poich\u00e9 la ricerca di anomalie dipende fortemente dai dati in cui viene eseguita, e i dati dei sistemi software variano notevolmente a seconda degli strumenti utilizzati per implementare il sistema, fino all'hardware su cui \u00e8 in esecuzione.<\/p>\n

<\/p>\n

Metodi per la ricerca di anomalie nella previsione dei guasti dei sistemi software<\/h2>\n

<\/p>\n

Prima di tutto, \u00e8 importante sottolineare che l'idea della previsione dei guasti \u00e8 stata ispirata da un articolo \u00abApprendimento automatico nel monitoraggio IT\u00bb<\/a><\/noindex>. Per verificare l'efficacia dell'approccio con ricerca automatica di anomalie, \u00e8 stato scelto il sistema software \u00abWeb-Consolidation\u00bb, uno dei progetti dell'azienda NPO \u00abKrista\u00bb. In precedenza, veniva effettuato un monitoraggio manuale basato sulle metriche ricevute. Data la complessit\u00e0 del sistema, vengono raccolte numerose metriche: indicatori JVM (carico del garbage collector), indicatori del sistema operativo in cui viene eseguito il codice (memoria virtuale, % di utilizzo della CPU del sistema), indicatori di rete (carico della rete), del server stesso (carico della CPU, della memoria), metriche wildfly e metriche proprie dell'applicazione per tutti i sottosistemi critici. <\/p>\n

<\/p>\n

Tutte le metriche sono raccolte dal sistema tramite graphite. Inizialmente \u00e8 stato utilizzato il database whisper come soluzione standard per grafana, ma con la crescita della clientela, graphite ha smesso di funzionare, esaurendo la capacit\u00e0 di throughput del sistema di archiviazione del data center. Dopo ci\u00f2, \u00e8 stata presa la decisione di cercare una soluzione pi\u00f9 efficace. \u00c8 stata scelta graphite+clickhouse<\/a><\/noindex>, che ha permesso di ridurre notevolmente il carico sul sottosistema di archiviazione e diminuire il volume occupato da cinque a sei volte. Di seguito \u00e8 riportato lo schema del meccanismo di raccolta delle metriche utilizzando graphite+clickhouse (figura 2).<\/p>\n

\n\"Riconosciamo
\n<\/p>\n

Figura 2. Schema di raccolta delle metriche<\/em><\/p>\n

Lo schema \u00e8 preso dalla documentazione interna. Mostra lo scambio di dati tra grafana (l'interfaccia utente per il monitoraggio che utilizziamo) e graphite. La raccolta delle metriche dall'applicazione \u00e8 effettuata da un software separato \u2013 jmxtrans<\/a><\/noindex>. Questo software le memorizza in graphite.
\nIl sistema \u00abWeb-Consulenza\u00bb presenta alcune caratteristiche che creano problemi nella previsione dei guasti:<\/p>\n

<\/p>\n

    \n
  1. c'\u00e8 spesso un cambiamento di tendenza. Per questo sistema software vengono rilasciate diverse versioni. Ognuna di esse porta modifiche nella parte software del sistema. Pertanto, in questo modo gli sviluppatori influenzano direttamente le metriche di questo sistema e possono causare un cambiamento di tendenza; <\/li>\n
  2. le caratteristiche di implementazione, cos\u00ec come gli obiettivi di utilizzo da parte dei clienti di questo sistema, spesso generano anomalie senza una precedente degradazione; <\/li>\n
  3. la percentuale di anomalie rispetto all'intero set di dati \u00e8 ridotta (< 5%); <\/li>\n
  4. possono verificarsi interruzioni nella ricezione delle metriche dal sistema. Per brevi periodi di tempo, il sistema di monitoraggio non riesce a ottenere le metriche. Ad esempio, se il server \u00e8 sovraccarico. Questo \u00e8 cruciale per l'addestramento delle reti neurali. Si rende necessaria la sintesi delle lacune;<\/li>\n
  5. I casi di anomalie sono spesso rilevanti solo per un numero\/mese\/tempo specifico (stagionalit\u00e0). Questo sistema ha un regolamento chiaro per l'utilizzo da parte degli utenti. Di conseguenza, le metriche sono pertinenti solo per un momento specifico. Il sistema pu\u00f2 essere utilizzato non costantemente, ma solo in alcuni mesi: in modo selettivo a seconda dell'anno. Ci sono situazioni in cui lo stesso comportamento delle metriche in un caso pu\u00f2 portare al fallimento del sistema software, mentre in un altro no.
    \nIn primo luogo, sono stati analizzati i metodi di rilevamento delle anomalie nei dati di monitoraggio dei sistemi software. Negli articoli su questo argomento, con percentuali basse di anomalie rispetto al resto del set di dati, si consiglia frequentemente di utilizzare le reti neurali. <\/li>\n<\/ol>\n

    <\/p>\n

    La logica principale per la ricerca di anomalie utilizzando dati di reti neurali \u00e8 illustrata nella figura 3:<\/p>\n

    \n\"Riconosciamo
    \n<\/p>\n

    Figura 3. Ricerca di anomalie tramite rete neurale<\/em><\/p>\n

    Nel risultato della previsione o del ripristino della finestra del flusso attuale delle metriche viene calcolata la deviazione rispetto a quella ottenuta dal sistema software in funzione. In caso di una grande differenza tra le metriche ottenute dal sistema software e quelle della rete neurale, si pu\u00f2 concludere che l'attuale intervallo di dati \u00e8 anomalo. Si sollevano i seguenti problemi per l'uso delle reti neurali:<\/p>\n

    <\/p>\n

      \n
    1. per un corretto funzionamento in tempo reale, i dati per l'addestramento dei modelli di reti neurali devono includere solo dati \"normali\"; <\/li>\n
    2. \u00e8 necessario avere un modello attuale per una rilevazione corretta. Un cambiamento nella tendenza e nella stagionalit\u00e0 delle metriche pu\u00f2 causare un gran numero di falsi allarmi del modello. Per il suo aggiornamento \u00e8 necessario definire chiaramente il momento in cui il modello diventa obsoleto. Se il modello viene aggiornato troppo tardi o troppo presto, \u00e8 probabile che ci siano molti falsi allarmi.
      \n\u0422\u0430\u043a\u0436\u0435 \u043d\u0435\u043b\u044c\u0437\u044f \u0437\u0430\u0431\u044b\u0432\u0430\u0442\u044c \u043e \u043f\u043e\u0438\u0441\u043a\u0435 \u0438 \u043f\u0440\u0435\u0434\u043e\u0442\u0432\u0440\u0430\u0449\u0435\u043d\u0438\u0438 \u0447\u0430\u0441\u0442\u043e\u0433\u043e \u0432\u043e\u0437\u043d\u0438\u043a\u043d\u043e\u0432\u0435\u043d\u0438\u044f \u043b\u043e\u0436\u043d\u044b\u0445 \u0441\u0440\u0430\u0431\u0430\u0442\u044b\u0432\u0430\u043d\u0438\u0439. \u041f\u0440\u0435\u0434\u043f\u043e\u043b\u0430\u0433\u0430\u0435\u0442\u0441\u044f, \u0447\u0442\u043e \u043e\u043d\u0438 \u0431\u0443\u0434\u0443\u0442 \u0447\u0430\u0449\u0435 \u0432\u0441\u0435\u0433\u043e \u0432\u043e\u0437\u043d\u0438\u043a\u0430\u0442\u044c \u0432 \u043d\u0435\u0448\u0442\u0430\u0442\u043d\u044b\u0445 \u0441\u0438\u0442\u0443\u0430\u0446\u0438\u044f\u0445. \u041e\u0434\u043d\u0430\u043a\u043e \u043e\u043d\u0438 \u043c\u043e\u0433\u0443\u0442 \u0431\u044b\u0442\u044c \u0438 \u0441\u043b\u0435\u0434\u0441\u0442\u0432\u0438\u0435\u043c \u043e\u0448\u0438\u0431\u043a\u0438 \u043d\u0435\u0439\u0440\u043e\u043d\u043d\u043e\u0439 \u0441\u0435\u0442\u0438 \u043f\u043e \u043f\u0440\u0438\u0447\u0438\u043d\u0435 \u043d\u0435\u0434\u043e\u0441\u0442\u0430\u0442\u0430\u0442\u043e\u0447\u043d\u043e\u0441\u0442\u0438 \u0435\u0451 \u043e\u0431\u0443\u0447\u0435\u043d\u0438\u044f. \u041d\u0435\u043e\u0431\u0445\u043e\u0434\u0438\u043c\u043e \u043c\u0438\u043d\u0438\u043c\u0438\u0437\u0438\u0440\u043e\u0432\u0430\u0442\u044c \u043a\u043e\u043b\u0438\u0447\u0435\u0441\u0442\u0432\u043e \u043b\u043e\u0436\u043d\u044b\u0445 \u0441\u0440\u0430\u0431\u0430\u0442\u044b\u0432\u0430\u043d\u0438\u0439 \u043c\u043e\u0434\u0435\u043b\u0438. \u0412 \u043f\u0440\u043e\u0442\u0438\u0432\u043d\u043e\u043c \u0441\u043b\u0443\u0447\u0430\u0435 \u043b\u043e\u0436\u043d\u044b\u0435 \u043f\u0440\u043e\u0433\u043d\u043e\u0437\u044b \u0431\u0443\u0434\u0443\u0442 \u0442\u0440\u0430\u0442\u0438\u0442\u044c \u043c\u043d\u043e\u0433\u043e \u0432\u0440\u0435\u043c\u0435\u043d\u0438 \u0430\u0434\u043c\u0438\u043d\u0438\u0441\u0442\u0440\u0430\u0442\u043e\u0440\u0430, \u043f\u0440\u0435\u0434\u043d\u0430\u0437\u043d\u0430\u0447\u0435\u043d\u043d\u043e\u0433\u043e \u0434\u043b\u044f \u043f\u0440\u043e\u0432\u0435\u0440\u043a\u0438 \u0441\u0438\u0441\u0442\u0435\u043c\u044b. \u0420\u0430\u043d\u043e \u0438\u043b\u0438 \u043f\u043e\u0437\u0434\u043d\u043e \u043a\u043e\u043d\u0447\u0438\u0442\u0441\u044f \u0442\u0435\u043c, \u0447\u0442\u043e \u0430\u0434\u043c\u0438\u043d\u0438\u0441\u0442\u0440\u0430\u0442\u043e\u0440 \u043f\u0440\u043e\u0441\u0442\u043e \u043f\u0435\u0440\u0435\u0441\u0442\u0430\u043d\u0435\u0442 \u0440\u0435\u0430\u0433\u0438\u0440\u043e\u0432\u0430\u0442\u044c \u043d\u0430 \u00ab\u043f\u0430\u0440\u0430\u043d\u043e\u0438\u0434\u0430\u043b\u044c\u043d\u0443\u044e\u00bb \u0441\u0438\u0441\u0442\u0435\u043c\u0443 \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433\u0430.<\/li>\n<\/ol>\n

      <\/p>\n

      \u0420\u0435\u043a\u0443\u0440\u0440\u0435\u043d\u0442\u043d\u0430\u044f \u043d\u0435\u0439\u0440\u043e\u043d\u043d\u0430\u044f \u0441\u0435\u0442\u044c<\/h2>\n

      <\/p>\n

      \u0414\u043b\u044f \u043e\u0431\u043d\u0430\u0440\u0443\u0436\u0435\u043d\u0438\u044f \u0430\u043d\u043e\u043c\u0430\u043b\u0438\u0439 \u0432\u043e \u0432\u0440\u0435\u043c\u0435\u043d\u043d\u044b\u0445 \u0440\u044f\u0434\u0430\u0445 \u043c\u043e\u0436\u043d\u043e \u043f\u0440\u0438\u043c\u0435\u043d\u0438\u0442\u044c \u0440\u0435\u043a\u0443\u0440\u0440\u0435\u043d\u0442\u043d\u0443\u044e \u043d\u0435\u0439\u0440\u043e\u043d\u043d\u0443\u044e \u0441\u0435\u0442\u044c <\/a><\/noindex>\u0441 \u043f\u0430\u043c\u044f\u0442\u044c\u044e LSTM. \u041f\u0440\u043e\u0431\u043b\u0435\u043c\u0430 \u0435\u0441\u0442\u044c \u043b\u0438\u0448\u044c \u0432 \u0442\u043e\u043c, \u0447\u0442\u043e \u043e\u043d\u0430 \u043c\u043e\u0436\u0435\u0442 \u043f\u0440\u0438\u043c\u0435\u043d\u044f\u0442\u044c\u0441\u044f \u0442\u043e\u043b\u044c\u043a\u043e \u0434\u043b\u044f \u043f\u0440\u043e\u0433\u043d\u043e\u0437\u0438\u0440\u0443\u0435\u043c\u044b\u0445 \u0432\u0440\u0435\u043c\u0435\u043d\u043d\u044b\u0445 \u0440\u044f\u0434\u043e\u0432. \u0412 \u043d\u0430\u0448\u0435\u043c \u0441\u043b\u0443\u0447\u0430\u0435 \u043d\u0435 \u0432\u0441\u0435 \u043c\u0435\u0442\u0440\u0438\u043a\u0438 \u044f\u0432\u043b\u044f\u044e\u0442\u0441\u044f \u043f\u0440\u043e\u0433\u043d\u043e\u0437\u0438\u0440\u0443\u0435\u043c\u044b\u043c\u0438. \u041f\u043e\u043f\u044b\u0442\u043a\u0430 \u043f\u0440\u0438\u043c\u0435\u043d\u0438\u0442\u044c RNN LSTM \u0434\u043b\u044f \u0432\u0440\u0435\u043c\u0435\u043d\u043d\u043e\u0433\u043e \u0440\u044f\u0434\u0430 \u043f\u0440\u0435\u0434\u0441\u0442\u0430\u0432\u043b\u0435\u043d\u0430 \u043d\u0430 \u0440\u0438\u0441\u0443\u043d\u043a\u0435 4.<\/p>\n

      \n\"Riconosciamo
      \n<\/p>\n

      \u0420\u0438\u0441\u0443\u043d\u043e\u043a 4. \u041f\u0440\u0438\u043c\u0435\u0440 \u0440\u0430\u0431\u043e\u0442\u044b \u0440\u0435\u043a\u0443\u0440\u0440\u0435\u043d\u0442\u043d\u043e\u0439 \u043d\u0435\u0439\u0440\u043e\u043d\u043d\u043e\u0439 \u0441\u0435\u0442\u0438 c \u044f\u0447\u0435\u0439\u043a\u0430\u043c\u0438 \u043f\u0430\u043c\u044f\u0442\u0438 LSTM<\/em><\/p>\n

      Come si pu\u00f2 vedere nella figura 4, la RNN LSTM \u00e8 riuscita a rilevare l'anomalia in questo intervallo di tempo. Dove il risultato mostra un'alta percentuale di errore nella previsione (errore medio), si \u00e8 effettivamente verificata un'anomalia nei valori. L'uso di una sola RNN LSTM non sar\u00e0 sufficiente, poich\u00e9 \u00e8 applicabile a un numero limitato di metriche. Si pu\u00f2 utilizzare come metodo ausiliario per la ricerca di anomalie. <\/p>\n

      <\/p>\n

      Autoencoder per la previsione dei guasti<\/h2>\n

      <\/p>\n

      Autoencoder<\/a><\/noindex> \u2013 essenzialmente una rete neurale artificiale. Lo strato di ingresso \u00e8 l'encoder, lo strato di uscita \u00e8 il decoder. Lo svantaggio di tutte le reti neurali di questo tipo \u00e8 che localizzano male le anomalie. \u00c8 stata scelta l'architettura di un autoencoder sincrono.<\/p>\n

      \n\"Riconosciamo
      \n<\/p>\n

      Figura 5. Esempio di funzionamento di un autoencoder<\/em><\/p>\n

      Gli autoencoder vengono addestrati su dati normali e poi trovano qualcosa di anomalo nei dati immessi nel modello. Proprio ci\u00f2 che serve per questo compito. Resta solo da scegliere quale autoencoder si adatti a questa esigenza. La forma architettonicamente pi\u00f9 semplice di autoencoder \u00e8 una rete neurale semplice e diretta, molto simile a un perceptron multistrato<\/a><\/noindex> (perceptron multistrato, MLP), con un livello di ingresso, un livello di uscita e uno o pi\u00f9 strati nascosti che li collegano.
      \nTuttavia, le differenze tra gli autoencoder e gli MLP sono che nell'autoencoder il livello di uscita ha lo stesso numero di nodi dell'ingresso e che, invece di apprendere a prevedere il valore target Y dato l'ingresso X, l'autoencoder impara a ricostruire il proprio X. Pertanto, gli autoencoder sono modelli di apprendimento non supervisionato. <\/p>\n

      <\/p>\n

      L'obiettivo dell'autoencoder \u00e8 trovare gli indici temporali r0 \u2026 rn corrispondenti agli elementi anomali nel vettore di ingresso X. Questo effetto viene raggiunto cercando l'errore quadratico.<\/p>\n

      \n\"Riconosciamo <\/p>\n

      Figura 6. Autoencoder sincrono<\/em><\/p>\n

      Per l'autoencoder \u00e8 stata scelta un'architettura sincrona<\/a><\/noindex>. I suoi vantaggi: la possibilit\u00e0 di utilizzare la modalit\u00e0 di elaborazione in streaming e un numero relativamente ridotto di parametri della rete neurale rispetto ad altre architetture.<\/p>\n

      <\/p>\n

      Meccanismo per minimizzare i falsi allarmi<\/h2>\n

      <\/p>\n

      Considerando che possono verificarsi varie situazioni anomale e che \u00e8 possibile una situazione di insufficiente addestramento della rete neurale, \u00e8 stata presa la decisione di sviluppare un meccanismo per minimizzare i falsi positivi per il modello di rilevamento delle anomalie in fase di sviluppo. Questo meccanismo si basa su un database di modelli classificati dall'amministratore. <\/p>\n

      <\/p>\n

      Algoritmo di trasformazione dinamica della linea temporale<\/a><\/noindex> (algoritmo DTW, dall'inglese dynamic time warping) permette di trovare la corrispondenza ottimale tra sequenze temporali. \u00c8 stato applicato per la prima volta nel riconoscimento vocale: utilizzato per determinare in che modo due segnali vocali rappresentano la stessa frase pronunciata. Successivamente, sono stati trovati impieghi anche in altri settori.<\/p>\n

      <\/p>\n

      Il principio fondamentale per ridurre i falsi positivi \u00e8 la creazione di una base di riferimento attraverso un operatore che classifica i casi sospetti rilevati tramite reti neurali. Successivamente, si confronta il campione classificato con il caso identificato dal sistema, e si determina se il caso \u00e8 da considerare un falso positivo o un malfunzionamento. Per il confronto di due serie temporali si utilizza l'algoritmo DTW. Lo strumento principale per la riduzione rimane comunque la classificazione. Si prevede che, dopo aver raccolto un gran numero di casi di riferimento, il sistema inizier\u00e0 a richiedere meno intervento da parte dell'operatore a causa della somiglianza della maggior parte dei casi e della comparsa di casi simili.<\/p>\n

      <\/p>\n

      Di conseguenza, sulla base dei metodi delle reti neurali descritti sopra, \u00e8 stato sviluppato un programma sperimentale per la previsione dei guasti del sistema \"Web-Consolidazione\". L'obiettivo di questo programma era, utilizzando l'archivio esistente dei dati di monitoraggio e le informazioni sui guasti gi\u00e0 verificatisi, valutare l'efficacia di questo approccio per i nostri sistemi software. Lo schema di funzionamento del programma \u00e8 mostrato di seguito, nella figura 7.<\/p>\n

      \n\"Riconosciamo <\/p>\n

      Figura 7. Schema di previsione dei guasti basata sull'analisi dello spazio delle metriche.<\/em><\/p>\n

      Nella schema si possono evidenziare due blocchi principali: la ricerca di segmenti anomalous nel flusso di dati di monitoraggio (metriche) e il meccanismo di minimizzazione dei falsi allarmi. Nota: a scopo sperimentale, i dati vengono ottenuti tramite una connessione JDBC da un database in cui sono archiviati in Graphite.
      \nDi seguito \u00e8 mostrata l'interfaccia del sistema di monitoraggio sviluppato (figura 8).<\/p>\n

      \n\"Riconosciamo<\/p>\n

      Figura 8. Interfaccia del sistema di monitoraggio sperimentale.<\/em><\/p>\n

      Nell'interfaccia viene visualizzata la percentuale di anomalia delle metriche ottenute. Nel nostro caso, l'acquisizione \u00e8 simulata. Abbiamo gi\u00e0 tutti i dati di alcune settimane e li carichiamo gradualmente per verificare il caso di un'anomalia che porta a un guasto. Nella barra di stato in basso viene visualizzata la percentuale complessiva di anomalia dei dati al momento, che \u00e8 determinata mediante un autoencoder. Inoltre, per le metriche previste viene visualizzata una percentuale separata, calcolata da RNN LSTM.<\/p>\n

      <\/p>\n

      Esempio di rilevamento di anomalie nei parametri della CPU utilizzando la rete neurale RNN LSTM (figura 9).<\/p>\n

      \n\"Riconosciamo<\/p>\n

      Figura 9. Rilevamento RNN LSTM<\/em><\/p>\n

      Un caso piuttosto semplice, fondamentalmente un'uscita normale, ma che porta a un guasto del sistema, \u00e8 stato rilevato con successo utilizzando RNN LSTM. Il livello di anomalia in questo intervallo di tempo \u00e8 pari all'85-95%; qualsiasi valore superiore all'80% (soglia definita sperimentalmente) \u00e8 considerato un'anomalia.
      \nEsempio di rilevamento di anomalie quando il sistema non riesce a caricarsi dopo un aggiornamento. Questa situazione viene rilevata dall'autoencoder (Figura 10).<\/p>\n

      \n\"Riconosciamo<\/p>\n

      Figura 10. Esempio di rilevamento da parte dell'autoencoder<\/em><\/p>\n

      Come si pu\u00f2 vedere dalla figura, PermGen \u00e8 rimasto bloccato a un certo livello. L'autoencoder ha considerato questo comportamento strano, poich\u00e9 non aveva mai visto nulla di simile in precedenza. Qui l'anomalia si mantiene costante al 100% fino al ripristino dello stato operativo del sistema. L'anomalia viene visualizzata su tutte le metriche. Come detto in precedenza, l'autoencoder non \u00e8 in grado di localizzare le anomalie. L'operatore \u00e8 chiamato a svolgere questa funzione in tali situazioni.<\/p>\n

      <\/p>\n

      Conclusione<\/h2>\n

      <\/p>\n

      Il sistema \u00abWeb-Consolidation\u00bb \u00e8 in fase di sviluppo da diversi anni. Attualmente, il sistema \u00e8 in uno stato abbastanza stabile e il numero di incidenti registrati \u00e8 limitato. Tuttavia, sono state trovate anomali che possono portare a un guasto da 5 a 10 minuti prima dell'effettivo problema. In alcuni casi, un avviso tempestivo sul guasto avrebbe potuto ridurre il tempo di inattivit\u00e0 programmato, che \u00e8 previsto per le operazioni di 'manutenzione'.<\/p>\n

      <\/p>\n

      Per gli esperimenti condotti, \u00e8 ancora presto per trarre conclusioni definitive. Al momento, i risultati sono contraddittori. Da un lato, \u00e8 evidente che gli algoritmi basati su reti neurali sono in grado di rilevare anomalie 'utili'. Dall'altro, rimane un alto tasso di falsi positivi e non tutte le anomalie che un specialista qualificato pu\u00f2 individuare riescono ad essere rilevate dalla rete neurale. Tra i lati negativi, va anche considerato che al momento la rete neurale richiede un addestramento supervisionato per funzionare correttamente.<\/p>\n

      <\/p>\n

      Per lo sviluppo ulteriore del sistema di previsione dei guasti e per portarlo a uno stato soddisfacente, si possono considerare diverse strade. Un'analisi pi\u00f9 dettagliata dei casi con anomalie che portano a guasti, arricchendo cos\u00ec la lista delle metriche importanti che influenzano fortemente lo stato del sistema e scartando quelle superflue che non influenzano. Inoltre, seguendo questa direzione, si possono tentare specializzazioni degli algoritmi specificamente per i nostri casi di anomalie che portano ai guasti. C'\u00e8 anche un altro percorso: il miglioramento delle architetture delle reti neurali e, grazie a ci\u00f2, l'aumento della precisione delle rilevazioni con una riduzione dei tempi di apprendimento.<\/p>\n

      <\/p>\n

      Desidero ringraziare i colleghi che mi hanno assistito nella redazione e nel mantenimento dell'accuratezza di questo articolo: Viktor Verbitsky<\/a><\/noindex> e Sergey Finogenov.<\/p>\n

      Fonte: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

      \u041f\u0440\u043e\u043c\u044b\u0448\u043b\u0435\u043d\u043d\u0430\u044f \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u043a\u0430 \u043f\u0440\u043e\u0433\u0440\u0430\u043c\u043c\u043d\u044b\u0445 \u0441\u0438\u0441\u0442\u0435\u043c \u0442\u0440\u0435\u0431\u0443\u0435\u0442 \u0431\u043e\u043b\u044c\u0448\u043e\u0433\u043e \u0432\u043d\u0438\u043c\u0430\u043d\u0438\u044f \u043a \u043e\u0442\u043a\u0430\u0437\u043e\u0443\u0441\u0442\u043e\u0439\u0447\u0438\u0432\u043e\u0441\u0442\u0438 \u043a\u043e\u043d\u0435\u0447\u043d\u043e\u0433\u043e \u043f\u0440\u043e\u0434\u0443\u043a\u0442\u0430, \u0430 \u0442\u0430\u043a\u0436\u0435 \u0431\u044b\u0441\u0442\u0440\u043e\u0433\u043e \u0440\u0435\u0430\u0433\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f \u043d\u0430 \u043e\u0442\u043a\u0430\u0437\u044b \u0438 \u0441\u0431\u043e\u0438, \u0435\u0441\u043b\u0438 \u043e\u043d\u0438 \u0432\u0441\u0435-\u0442\u0430\u043a\u0438 \u0441\u043b\u0443\u0447\u0430\u044e\u0442\u0441\u044f. \u041c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433, \u043a\u043e\u043d\u0435\u0447\u043d\u043e \u0436\u0435, \u043f\u043e\u043c\u043e\u0433\u0430\u0435\u0442 \u0440\u0435\u0430\u0433\u0438\u0440\u043e\u0432\u0430\u0442\u044c \u043d\u0430 \u043e\u0442\u043a\u0430\u0437\u044b \u0438 \u0441\u0431\u043e\u0438 \u044d\u0444\u0444\u0435\u043a\u0442\u0438\u0432\u043d\u0435\u0435 \u0438 \u0431\u044b\u0441\u0442\u0440\u0435\u0435, \u043d\u043e \u043d\u0435\u0434\u043e\u0441\u0442\u0430\u0442\u043e\u0447\u043d\u043e. \u0412\u043e-\u043f\u0435\u0440\u0432\u044b\u0445, \u043e\u0447\u0435\u043d\u044c \u0441\u043b\u043e\u0436\u043d\u043e \u0443\u0441\u043b\u0435\u0434\u0438\u0442\u044c \u0437\u0430 \u0431\u043e\u043b\u044c\u0448\u0438\u043c \u043a\u043e\u043b\u0438\u0447\u0435\u0441\u0442\u0432\u043e\u043c \u0441\u0435\u0440\u0432\u0435\u0440\u043e\u0432 \u2013 \u043d\u0435\u043e\u0431\u0445\u043e\u0434\u0438\u043c\u043e \u0431\u043e\u043b\u044c\u0448\u043e\u0435 \u043a\u043e\u043b\u0438\u0447\u0435\u0441\u0442\u0432\u043e \u043b\u044e\u0434\u0435\u0439. \u0412\u043e-\u0432\u0442\u043e\u0440\u044b\u0445, \u043d\u0443\u0436\u043d\u043e \u0445\u043e\u0440\u043e\u0448\u043e \u043f\u043e\u043d\u0438\u043c\u0430\u0442\u044c, \u043a\u0430\u043a […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-53531","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Cerchiamo anomalie e prevendiamo guasti tramite reti neurali | ProHoster","description":"Lo sviluppo di sistemi software industriali richiede una grande attenzione alla robustezza del prodotto finale e una pronta risposta a eventuali guasti e malfunzionamenti. La sorveglianza aiuta sicuramente a rispondere a guasti e malfunzionamenti in modo pi\u00f9 efficiente e rapido, ma non \u00e8 sufficiente. In primo luogo, \u00e8 molto difficile tenere traccia di un gran numero di server: \u00e8 necessario un grande numero di persone. In secondo luogo, \u00e8 fondamentale comprendere bene come","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/ishhem-anomalii-i-predskazyvaem-sboi-s-pomoshhyu-nejrosetej","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"it_IT","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0418\u0449\u0435\u043c \u0430\u043d\u043e\u043c\u0430\u043b\u0438\u0438 \u0438 \u043f\u0440\u0435\u0434\u0441\u043a\u0430\u0437\u044b\u0432\u0430\u0435\u043c \u0441\u0431\u043e\u0438 \u0441 \u043f\u043e\u043c\u043e\u0449\u044c\u044e \u043d\u0435\u0439\u0440\u043e\u0441\u0435\u0442\u0435\u0439 | ProHoster","og:description":"\u041f\u0440\u043e\u043c\u044b\u0448\u043b\u0435\u043d\u043d\u0430\u044f \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u043a\u0430 \u043f\u0440\u043e\u0433\u0440\u0430\u043c\u043c\u043d\u044b\u0445 \u0441\u0438\u0441\u0442\u0435\u043c \u0442\u0440\u0435\u0431\u0443\u0435\u0442 \u0431\u043e\u043b\u044c\u0448\u043e\u0433\u043e \u0432\u043d\u0438\u043c\u0430\u043d\u0438\u044f \u043a \u043e\u0442\u043a\u0430\u0437\u043e\u0443\u0441\u0442\u043e\u0439\u0447\u0438\u0432\u043e\u0441\u0442\u0438 \u043a\u043e\u043d\u0435\u0447\u043d\u043e\u0433\u043e \u043f\u0440\u043e\u0434\u0443\u043a\u0442\u0430, \u0430 \u0442\u0430\u043a\u0436\u0435 \u0431\u044b\u0441\u0442\u0440\u043e\u0433\u043e \u0440\u0435\u0430\u0433\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f \u043d\u0430 \u043e\u0442\u043a\u0430\u0437\u044b \u0438 \u0441\u0431\u043e\u0438, \u0435\u0441\u043b\u0438 \u043e\u043d\u0438 \u0432\u0441\u0435-\u0442\u0430\u043a\u0438 \u0441\u043b\u0443\u0447\u0430\u044e\u0442\u0441\u044f. \u041c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433, \u043a\u043e\u043d\u0435\u0447\u043d\u043e \u0436\u0435, \u043f\u043e\u043c\u043e\u0433\u0430\u0435\u0442 \u0440\u0435\u0430\u0433\u0438\u0440\u043e\u0432\u0430\u0442\u044c \u043d\u0430 \u043e\u0442\u043a\u0430\u0437\u044b \u0438 \u0441\u0431\u043e\u0438 \u044d\u0444\u0444\u0435\u043a\u0442\u0438\u0432\u043d\u0435\u0435 \u0438 \u0431\u044b\u0441\u0442\u0440\u0435\u0435, \u043d\u043e \u043d\u0435\u0434\u043e\u0441\u0442\u0430\u0442\u043e\u0447\u043d\u043e. \u0412\u043e-\u043f\u0435\u0440\u0432\u044b\u0445, \u043e\u0447\u0435\u043d\u044c \u0441\u043b\u043e\u0436\u043d\u043e \u0443\u0441\u043b\u0435\u0434\u0438\u0442\u044c \u0437\u0430 \u0431\u043e\u043b\u044c\u0448\u0438\u043c \u043a\u043e\u043b\u0438\u0447\u0435\u0441\u0442\u0432\u043e\u043c \u0441\u0435\u0440\u0432\u0435\u0440\u043e\u0432 \u2013 \u043d\u0435\u043e\u0431\u0445\u043e\u0434\u0438\u043c\u043e \u0431\u043e\u043b\u044c\u0448\u043e\u0435 \u043a\u043e\u043b\u0438\u0447\u0435\u0441\u0442\u0432\u043e \u043b\u044e\u0434\u0435\u0439. \u0412\u043e-\u0432\u0442\u043e\u0440\u044b\u0445, \u043d\u0443\u0436\u043d\u043e \u0445\u043e\u0440\u043e\u0448\u043e \u043f\u043e\u043d\u0438\u043c\u0430\u0442\u044c, \u043a\u0430\u043a","og:url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/ishhem-anomalii-i-predskazyvaem-sboi-s-pomoshhyu-nejrosetej","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-12-03T21:00:00+00:00","article:modified_time":"2020-02-18T11:01:26+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"53531","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-24 07:46:24","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 20:23:55","updated":"2026-01-24 07:46:24"},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/53531","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/comments?post=53531"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/53531\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=53531"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=53531"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=53531"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}