{"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\/ro\/blog\/administrirovanie\/ishhem-anomalii-i-predskazyvaem-sboi-s-pomoshhyu-nejrosetej","title":{"rendered":"C\u0103ut\u0103m anomalii \u0219i prezicem defec\u021biuni cu ajutorul re\u021belelor neuronale","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"C\u0103ut\u0103m<\/p>\n

<\/p>\n

Dezvoltarea industrial\u0103 a sistemelor software necesit\u0103 o aten\u021bie mare la fiabilitatea produsului final, precum \u0219i un r\u0103spuns rapid la defec\u021biuni \u0219i erori, \u00een cazul \u00een care acestea au loc. Monitorizarea, desigur, ajut\u0103 la reac\u021bionarea mai eficient\u0103 \u0219i mai rapid\u0103 \u00een fa\u021ba defec\u021biunilor, dar nu este suficient\u0103. \u00cen primul r\u00e2nd, este foarte dificil s\u0103 urm\u0103re\u0219ti un num\u0103r mare de servere - este nevoie de multe persoane. \u00cen al doilea r\u00e2nd, trebuie s\u0103 \u00een\u021belegi bine cum func\u021bioneaz\u0103 aplica\u021bia pentru a prognoza starea acesteia. Prin urmare, este nevoie de multe persoane care s\u0103 \u00een\u021beleag\u0103 bine sistemele pe care le dezvolt\u0103m, metricile \u0219i caracteristicile acestora. S\u0103 presupunem c\u0103, chiar dac\u0103 g\u0103sim un num\u0103r suficient de persoane dornice s\u0103 se ocupe de aceasta, mai este nevoie de mult timp pentru a le antrena.<\/p>\n

<\/p>\n

Ce trebuie s\u0103 facem? Aici ne vine \u00een ajutor inteligen\u021ba artificial\u0103. Articolul va vorbi despre \u00eentre\u021binerea predictiv\u0103<\/a><\/noindex> (predictive maintenance). Aceast\u0103 abordare c\u00e2\u0219tig\u0103 tot mai mult\u0103 popularitate. Au fost scrise un num\u0103r mare de articole, inclusiv pe Habr. Mari companii folosesc \u00een mod activ aceast\u0103 abordare pentru a men\u021bine func\u021bionalitatea serverelor lor. Dup\u0103 ce am studiat un num\u0103r mare de articole, am decis s\u0103 \u00eencerc\u0103m s\u0103 aplic\u0103m aceast\u0103 abordare. Ce a ie\u0219it din aceasta? <\/p>\n

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

Introducere<\/h2>\n

<\/p>\n

Sistemul software dezvoltat ajunge, mai devreme sau mai t\u00e2rziu, \u00een exploatare. Este important pentru utilizator ca sistemul s\u0103 func\u021bioneze f\u0103r\u0103 \u00eentreruperi. Dac\u0103 totu\u0219i apare o situa\u021bie de urgen\u021b\u0103, aceasta trebuie rezolvat\u0103 cu \u00eent\u00e2rzieri minime. <\/p>\n

<\/p>\n

Pentru a simplifica suportul tehnic al sistemului software, \u00een special dac\u0103 exist\u0103 multe servere, se folosesc de obicei programe de monitorizare care preiau metrici de la sistemul software \u00een func\u021biune, ofer\u0103 posibilitatea de a diagnostica starea acestuia \u0219i ajut\u0103 la determinarea cauzei defec\u021biunii. Acest proces se nume\u0219te monitorizarea sistemului software.<\/p>\n

\n\"C\u0103ut\u0103m<\/p>\n

Figura 1. Interfa\u021ba pentru monitorizarea grafana<\/em><\/p>\n

Metricile sunt diferite indicatori ai unui sistem software, al mediului s\u0103u de execu\u021bie sau al unei ma\u0219ini de calcul fizice sub care este lansat sistemul, cu un marcaj temporal, acel moment \u00een care au fost ob\u021binute metricile. \u00cen analiza static\u0103, datele metricilor se numesc serii temporale. Pentru a observa starea unui sistem software, metricile sunt prezentate sub form\u0103 de grafice: pe axa X se afl\u0103 timpul, iar pe axa Y valorile (figura 1). Dintr-un sistem software func\u021bional pot fi extrase c\u00e2teva mii de metrici (din fiecare nod). Acestea formeaz\u0103 un spa\u021biu metric (serii temporale multidimensionale). <\/p>\n

<\/p>\n

Deoarece pentru sistemele software complexe se extrag un num\u0103r mare de metrici, monitorizarea manual\u0103 devine o sarcin\u0103 complicat\u0103. Pentru a reduce volumul de date analizate de administrator, instrumentele de monitorizare con\u021bin unelte pentru identificarea automat\u0103 a problemelor posibile. De exemplu, se poate configura un trigger care s\u0103 se activeze \u00een cazul \u00een care spa\u021biul liber de pe disc scade sub un prag specificat. De asemenea, se poate diagnostica automat oprirea serverului sau o \u00eencetinire critic\u0103 a vitezei de servicii. \u00cen practic\u0103, instrumentele de monitorizare se descurc\u0103 bine cu identificarea defectelor deja survenite sau cu identificarea simptomelor simple ale defectelor viitoare, dar, \u00een general, prezicerea unei posibile defec\u021biuni r\u0103m\u00e2ne o provocare pentru ele. Prezicerea prin analiza manual\u0103 a metricilor necesit\u0103 implicarea speciali\u0219tilor califica\u021bi. Este o activitate cu o productivitate sc\u0103zut\u0103. Majoritatea posibilelor defecte pot r\u0103m\u00e2ne neobservate.<\/p>\n

<\/p>\n

\u00cen ultima vreme, printre marii IT-\u0219ti care dezvolt\u0103 software, devine din ce \u00een ce mai popular a\u0219a-numitul serviciu de \u00eentre\u021binere predictiv\u0103 a sistemelor software. Esen\u021ba acestui abord\u0103ri const\u0103 \u00een identificarea defectelor care duc la degradarea sistemului \u00een etape incipiente, \u00eenainte de apari\u021bia unei defec\u021biuni, folosind inteligen\u021ba artificial\u0103. Aceast\u0103 abordare nu exclude complet monitorizarea manual\u0103 a sistemului. Ea serve\u0219te ca suport pentru procesul de monitorizare \u00een sine. <\/p>\n

<\/p>\n

Principalul instrument pentru realizarea \u00eentre\u021binerii predictive este sarcina de a g\u0103si anomalii \u00een seriile temporale, deoarece atunci c\u00e2nd apare o anomalia<\/strong> \u00een date exist\u0103 o mare probabilitate ca, dup\u0103 un timp, s\u0103 apar\u0103 o defec\u021biune apare o defect sau o defec\u021biune<\/strong>. O anomalie este o devia\u021bie a indicatorilor unui sistem software, cum ar fi identificarea degrad\u0103rii vitezei de execu\u021bie a unei cereri de un anumit tip sau sc\u0103derea medie a num\u0103rului de solicit\u0103ri procesate \u00eentr-un nivel constant de sesiuni ale clien\u021bilor.<\/p>\n

<\/p>\n

Timpul de c\u0103utare a anomaliilor pentru sistemele software are specificul s\u0103u. Ideea este c\u0103 pentru fiecare sistem software este necesar\u0103 dezvoltarea sau ajustarea metodelor existente, deoarece c\u0103utarea anomaliilor depinde foarte mult de datele \u00een care este realizat\u0103, iar datele sistemelor software variaz\u0103 foarte mult \u00een func\u021bie de instrumentele de implementare a sistemelor, p\u00e2n\u0103 la tipul de ma\u0219in\u0103 de calcul pe care ruleaz\u0103.<\/p>\n

<\/p>\n

Metode de c\u0103utare a anomaliilor \u00een prognoza defectelor sistemelor software<\/h2>\n

<\/p>\n

\u00cen primul r\u00e2nd, merit\u0103 men\u021bionat c\u0103 ideea de prognozare a defectelor a fost inspirat\u0103 de articolul \u201e\u00cenv\u0103\u021barea automat\u0103 \u00een monitorizarea IT\u201d<\/a><\/noindex>. Pentru a verifica eficien\u021ba abord\u0103rii de c\u0103utare automat\u0103 a anomaliilor, a fost aleas\u0103 sistemul software \u201eWeb-Consolidare\u201d, care este unul dintre proiectele companiei NPO \u201eKrista\u201d. Pentru acesta, anterior se efectua un monitorizare manual\u0103 pe baza metricelor ob\u021binute. Deoarece sistemul este destul de complex, se colecteaz\u0103 un num\u0103r mare de metrici: indicatori JVM (\u00eenc\u0103rcarea colectorului de gunoi), indicatori ai sistemului de operare sub care ruleaz\u0103 codul (memorie virtual\u0103, % utilizare CPU), indicatori de re\u021bea (\u00eenc\u0103rcarea re\u021belei), serverului (\u00eenc\u0103rcarea CPU, memorie), metricile wildfly \u0219i metricele proprii ale aplica\u021biei pentru toate subsistemele critice. <\/p>\n

<\/p>\n

Toate metricile sunt colectate din sistem cu ajutorul graphite. Ini\u021bial, a fost folosit\u0103 baza whisper ca solu\u021bie standard pentru grafana, dar odat\u0103 cu cre\u0219terea num\u0103rului de clien\u021bi graphite nu a mai putut face fa\u021b\u0103, epuiz\u00e2nd capacitatea de transmisie a subsistemului de stocare a datelor. Dup\u0103 aceasta, s-a decis c\u0103utarea unei solu\u021bii mai eficiente. Alegerea a fost \u00een favoarea graphite+clickhouse<\/a><\/noindex>, ceea ce a permis reducerea semnificativ\u0103 a \u00eenc\u0103rc\u0103rii subsistemului de stocare \u0219i a diminuat cu cinci-sase ori volumul de stocare ocupat. Mai jos este prezentat\u0103 schema mecanismului de colectare a metricilor utiliz\u00e2nd graphite+clickhouse (figura 2).<\/p>\n

\n\"C\u0103ut\u0103m
\n<\/p>\n

Figura 2. Schema de colectare a metricilor<\/em><\/p>\n

Schema preluat\u0103 din documenta\u021bia intern\u0103. Aceasta ilustreaz\u0103 schimbul de date \u00eentre grafana (interfa\u021b\u0103 utilizator pentru monitorizare, pe care o folosim) \u0219i graphite. Colectarea metricilor din aplica\u021bie este realizat\u0103 de un software separat \u2013 jmxtrans<\/a><\/noindex>. Acesta le stocheaz\u0103 \u00een graphite.
\nSistemul \u201eWeb-Consolidare\u201d are o serie de caracteristici care cauzeaz\u0103 probleme \u00een prognozarea defec\u021biunilor:<\/p>\n

<\/p>\n

    \n
  1. adesea se schimb\u0103 trendul. Pentru acest sistem software sunt lansate diverse versiuni. Fiecare dintre ele aduce modific\u0103ri \u00een partea de program a sistemului. Prin urmare, dezvoltatorii afecteaz\u0103 direct metricile acestui sistem \u0219i pot provoca schimb\u0103ri de trend; <\/li>\n
  2. particularit\u0103\u021bile implement\u0103rii, precum \u0219i scopurile utiliz\u0103rii de c\u0103tre clien\u021bi ale acestui sistem, adesea genereaz\u0103 anomalii f\u0103r\u0103 o degradare prealabil\u0103; <\/li>\n
  3. procentul de anomalii \u00een raport cu \u00eentregul set de date este mic (< 5%); <\/li>\n
  4. pot ap\u0103rea \u00eentreruperi \u00een ob\u021binerea datelor din sistem. \u00cen anumite intervale scurte de timp, sistemul de monitorizare nu reu\u0219e\u0219te s\u0103 ob\u021bin\u0103 metrici. De exemplu, dac\u0103 serverul este suprasolicitat. Pentru antrenarea re\u021belei neuronale, acest lucru este critic. Se creeaz\u0103 necesitatea de a umple golurile \u00een mod sintetic;<\/li>\n
  5. Cazurile cu anomalii sunt adesea relevante doar pentru un anumit num\u0103r\/ lun\u0103\/ timp (sezonalitate). Acest sistem are un regulament clar de utilizare de c\u0103tre utilizatori. Prin urmare, metricile sunt relevante doar pentru un anumit moment. Sistemul poate fi utilizat nu constant, ci doar \u00een anumite luni: selectiv, \u00een func\u021bie de an. Apar situa\u021bii \u00een care acela\u0219i comportament al metricilor \u00eentr-un caz poate duce la defec\u021biunea sistemului software, iar \u00een altul nu.
    \nLa \u00eenceput, au fost analizate metodele de detectare a anomaliilor \u00een datele de monitorizare a sistemelor software. \u00cen articolele din acest domeniu, la procente mici de anomalii \u00een raport cu restul setului de date, se propune adesea utilizarea re\u021belelor neuronale. <\/li>\n<\/ol>\n

    <\/p>\n

    Logica principal\u0103 pentru c\u0103utarea anomaliilor folosind datele re\u021belelor neuronale este ilustrat\u0103 \u00een figura 3:<\/p>\n

    \n\"C\u0103ut\u0103m
    \n<\/p>\n

    Figura 3. C\u0103utarea anomaliilor prin intermediul re\u021belei neuronale<\/em><\/p>\n

    \u00cen rezultatul prognozei sau al recuper\u0103rii feroniei fluxului actual de metrici se calculeaz\u0103 abaterea de la cele ob\u021binute de la sistemul software func\u021bional. \u00cen cazul unei diferen\u021be mari \u00eentre metricii ob\u021binu\u021bi de la sistemul software \u0219i cei ai re\u021belei neuronale, se poate concluziona despre anomalia actualului segment de date. Acest lucru genereaz\u0103 o serie de probleme \u00een utilizarea re\u021belelor neuronale:<\/p>\n

    <\/p>\n

      \n
    1. pentru func\u021bionarea corect\u0103 \u00een modul de flux, datele pentru antrenarea modelelor de re\u021bele neuronale trebuie s\u0103 con\u021bin\u0103 doar date \u201enormale\u201d; <\/li>\n
    2. este necesar\u0103 o modelare actualizat\u0103 pentru o detec\u021bie corect\u0103. Schimbarea tendin\u021belor \u0219i sezonalit\u0103\u021bii \u00een metrici poate cauza un num\u0103r mare de alarme false ale modelului. Pentru a o actualiza, trebuie s\u0103 se defineasc\u0103 clar momentul \u00een care modelul devine \u00eenvechit. Dac\u0103 modelul este actualizat prea devreme sau prea t\u00e2rziu, este probabil s\u0103 apar\u0103 un num\u0103r mare de alarme false.
      \nDe asemenea, nu trebuie uitat\u0103 c\u0103utarea \u0219i prevenirea apari\u021biei frecvente a alarmelor false. Se presupune c\u0103 acestea vor ap\u0103rea cel mai des \u00een situa\u021bii anormale. Totu\u0219i, ele pot fi \u0219i rezultatul erorilor re\u021belei neuronale din cauza insuficien\u021bei antren\u0103rii acesteia. Este necesar s\u0103 se minimizeze num\u0103rul alarmelor false ale modelului. \u00cen caz contrar, previziunile false vor consuma mult timp al administratorului destinat verific\u0103rii sistemului. Mai devreme sau mai t\u00e2rziu, va duce la situa\u021bia \u00een care administratorul pur \u0219i simplu va \u00eenceta s\u0103 reac\u021bioneze la sistemul de monitorizare \u201eparanoic\u201d.<\/li>\n<\/ol>\n

      <\/p>\n

      Re\u021bea neuronal\u0103 recurent\u0103<\/h2>\n

      <\/p>\n

      Pentru detectarea anomaliilor \u00een seriile temporale se poate aplica o re\u021bea neuronal\u0103 recurent\u0103 <\/a><\/noindex>cu memorie LSTM. Problema este doar c\u0103 aceasta poate fi aplicat\u0103 doar pentru seriile temporale previzibile. \u00cen cazul nostru, nu toate metricile sunt previzibile. \u00cencercarea de a aplica RNN LSTM pentru seria temporal\u0103 este prezentat\u0103 \u00een figura 4.<\/p>\n

      \n\"C\u0103ut\u0103m
      \n<\/p>\n

      Figura 4. Exemplu de func\u021bionare a re\u021belei neuronale recursive cu celule de memorie LSTM<\/em><\/p>\n

      Dup\u0103 cum se poate observa din figura 4, RNN LSTM a reu\u0219it s\u0103 identifice anomaliile \u00een aceast\u0103 perioad\u0103 de timp. Acolo unde rezultatul are o eroare de predic\u021bie mare (eroare medie), a avut loc cu adev\u0103rat o anomalie \u00een indicatori. Utilizarea unei singure RNN LSTM va fi clar insuficient\u0103, deoarece aceasta este aplicabil\u0103 unui num\u0103r mic de metrici. Poate fi utilizat\u0103 ca metod\u0103 auxiliar\u0103 de c\u0103utare a anomaliilor. <\/p>\n

      <\/p>\n

      Autoencoder pentru prognozarea defectelor<\/h2>\n

      <\/p>\n

      Autoencoder<\/a><\/noindex> \u2013 este, \u00een esen\u021b\u0103, o re\u021bea neuronal\u0103 artificial\u0103. Strat de intrare \u2013 encoder, strat de ie\u0219ire \u2013 decoder. Dezavantajul tuturor re\u021belelor neuronale de acest tip este c\u0103 nu localizeaz\u0103 bine anomaliile. S-a ales arhitectura unui autoencoder sincron.<\/p>\n

      \n\"C\u0103ut\u0103m
      \n<\/p>\n

      Figura 5. Exemplu de func\u021bionare a autoencoder-ului<\/em><\/p>\n

      Autoencoderele sunt antrenate pe date normale \u0219i apoi g\u0103sesc ceva anormal \u00een datele furnizate modelului. Exact ceea ce este necesar pentru aceast\u0103 sarcin\u0103. R\u0103m\u00e2ne doar s\u0103 alegem care dintre autoencodere se potrive\u0219te cel mai bine acestei sarcini. Cea mai simpl\u0103 form\u0103 arhitectural\u0103 a unui autoencoder este o re\u021bea neuronal\u0103 simpl\u0103, de tip feedforward, foarte similar\u0103 cu perceptronul multicluostr\u0103<\/a><\/noindex> (multilayer perceptron, MLP), av\u00e2nd un strat de intrare, un strat de ie\u0219ire \u0219i unul sau mai multe straturi ascunse care le conecteaz\u0103.
      \nCu toate acestea, diferen\u021bele dintre autoencodere \u0219i MLP constau \u00een faptul c\u0103 \u00een autoencoder stratul de ie\u0219ire are acela\u0219i num\u0103r de noduri ca \u0219i stratul de intrare \u0219i c\u0103, \u00een loc s\u0103 \u00eenve\u021be s\u0103 prezic\u0103 valoarea \u021bint\u0103 Y, dat\u0103 de intrarea X, autoencoder-ul \u00eenva\u021b\u0103 s\u0103-\u0219i reconstruiasc\u0103 propriile X. Prin urmare, autoencoderele sunt modele de \u00eenv\u0103\u021bare nesupravegheat\u0103. <\/p>\n

      <\/p>\n

      Sarcina autoencoder-ului const\u0103 \u00een g\u0103sirea indicilor temporali r0 \u2026 rn, corespunz\u0103tori elementelor anormale din vectorul de intrare X. Acest efect este realizat prin c\u0103utarea erorii p\u0103tratice.<\/p>\n

      \n\"C\u0103ut\u0103m <\/p>\n

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

      Pentru autoencoder s-a ales arhitectura sincron\u0103<\/a><\/noindex>. Avantajele sale: posibilitatea utiliz\u0103rii modului de procesare \u00een flux \u0219i un num\u0103r relativ mai mic de parametri ai re\u021belei neuronale \u00een compara\u021bie cu alte arhitecturi.<\/p>\n

      <\/p>\n

      Mecanismul de minimizare a falselor alarme<\/h2>\n

      <\/p>\n

      Av\u00e2nd \u00een vedere c\u0103 apar diferite situa\u021bii neprev\u0103zute, precum \u0219i posibila insuficient\u0103 instruire a re\u021belei neuronale, s-a luat decizia de a dezvolta un mecanism de minimizare a alarmelor false pentru modelul dezvoltat de detectare a anomaliilor. Acest mecanism se bazeaz\u0103 pe o baz\u0103 de \u0219abloane clasificat\u0103 de administrator. <\/p>\n

      <\/p>\n

      Algoritmul de transformare dinamic\u0103 a axei temporale<\/a><\/noindex> (algoritmul DTW, de la engl. dynamic time warping) permite g\u0103sirea unei coresponden\u021be optime \u00eentre secven\u021be temporale. A fost utilizat pentru prima dat\u0103 \u00een recunoa\u0219terea vocal\u0103: folosit pentru a determina cum cele dou\u0103 semnale vocale reprezint\u0103 aceea\u0219i fraz\u0103 pronun\u021bat\u0103 ini\u021bial. Ulterior, i s-au g\u0103sit aplica\u021bii \u0219i \u00een alte domenii.<\/p>\n

      <\/p>\n

      Principiul de baz\u0103 al minimiz\u0103rii alarmelor false este colectarea unei baze de etaloane prin intermediul unui operator care clasific\u0103 cazurile suspecte detectate cu ajutorul re\u021belelor neuronale. Ulterior, se compar\u0103 etalonul clasificat cu cazul detectat de sistem \u0219i se trage o concluzie cu privire la apartenen\u021ba acestuia la o alarm\u0103 fals\u0103 sau la o eroare real\u0103. Precis, pentru a compara cele dou\u0103 serii temporale se utilizeaz\u0103 algoritmul DTW. Principalul instrument \u00een minimizare r\u0103m\u00e2ne clasificarea. Se presupune c\u0103, dup\u0103 colectarea unui num\u0103r mare de cazuri etalon, sistemul va solicita mai pu\u021bin operatorului din cauza similitudinii majorit\u0103\u021bii cazurilor \u0219i a apari\u021biei similare.<\/p>\n

      <\/p>\n

      \u00cen final, pe baza metodelor de re\u021bele neuronale descrise mai sus, a fost construit un program experimental pentru prognoza defec\u021biunilor sistemului \u201eWeb-Consolidare\u201d. Scopul acestui program a fost, folosind arhiva existent\u0103 de date de monitorizare \u0219i informa\u021bii despre defec\u021biunile deja petrecute, s\u0103 evalueze competen\u021ba acestei abord\u0103ri pentru sistemele noastre software. Schema de func\u021bionare a programului este prezentat\u0103 mai jos, \u00een figura 7.<\/p>\n

      \n\"C\u0103ut\u0103m <\/p>\n

      Figura 7. Schema prognozei defec\u021biunilor pe baza analizei spa\u021biului metricilor<\/em><\/p>\n

      \u00cen schem\u0103 se pot eviden\u021bia dou\u0103 blocuri principale: c\u0103utarea segmentelor anormale de timp \u00een fluxul de date de monitorizare (metrici) \u0219i mecanismul de minimizare a alarmelor false. Not\u0103: \u00een scopuri experimentale, datele sunt ob\u021binute prin conexiune JDBC din baza de date, \u00een care sunt salvate cu graphite.
      \nUrm\u0103torul este interfa\u021ba rezultat\u0103 \u00een urma dezvolt\u0103rii sistemului de monitorizare (figura 8).<\/p>\n

      \n\"C\u0103ut\u0103m<\/p>\n

      Figura 8. Interfa\u021ba sistemului experimental de monitorizare<\/em><\/p>\n

      Interfa\u021ba afi\u0219eaz\u0103 procentul de anomalii pe metricile ob\u021binute. \u00cen cazul nostru, ob\u021binerea este modelat\u0103. Avem deja toate datele pentru c\u00e2teva s\u0103pt\u0103m\u00e2ni \u0219i le \u00eenc\u0103rc\u0103m treptat pentru a verifica cazul cu anomalia care duce la defectare. \u00cen bara de stare de jos se afi\u0219eaz\u0103 procentul total de anomalii al datelor \u00een momentul respectiv, care este determinat prin intermediul unui autoencoder. De asemenea, pentru metricile prognozate se afi\u0219eaz\u0103 un procent separat, calculat de RNN LSTM.<\/p>\n

      <\/p>\n

      Exemplu de detectare a anomaliilor pe baza indicatorilor CPU prin intermediul re\u021belei neuronale RNN LSTM (figura 9).<\/p>\n

      \n\"C\u0103ut\u0103m<\/p>\n

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

      Un caz destul de simplu, practic un simplu outlier, dar care duce la defectarea sistemului, a fost calculat cu succes prin RNN LSTM. Indicatorul de anomalii \u00een acest interval de timp este de 85 \u2013 95%, orice valoare peste 80% (prag stabilit experimental) este considerat\u0103 anomalie.
      \nExemplu de detectare a anomaliilor, c\u00e2nd sistemul nu a reu\u0219it s\u0103 se \u00eencarce dup\u0103 actualizare. Aceast\u0103 situa\u021bie este detectat\u0103 de autoencoder (figura 10).<\/p>\n

      \n\"C\u0103ut\u0103m<\/p>\n

      Figura 10. Exemplu de detectare cu autoencoderul<\/em><\/p>\n

      Dup\u0103 cum se poate observa din figur\u0103, PermGen a r\u0103mas blocat la un anumit nivel. Autoencoderul a considerat aceasta ca fiind ciudat, deoarece anterior nu a v\u0103zut nimic asem\u0103n\u0103tor. Aici anomalia r\u0103m\u00e2ne la 100% p\u00e2n\u0103 c\u00e2nd sistemul revine \u00een stare de func\u021bionare. Anomalia este afi\u0219at\u0103 pe toate metricile. A\u0219a cum s-a spus anterior, autoencoderul nu poate localiza anomaliile. Operatorul este responsabil s\u0103 \u00eendeplineasc\u0103 aceast\u0103 func\u021bie \u00een aceste situa\u021bii.<\/p>\n

      <\/p>\n

      Concluzie<\/h2>\n

      <\/p>\n

      PC-ul \u201eWeb-Consolidare\u201d este dezvoltat de mai mul\u021bi ani. Sistemul se afl\u0103 \u00eentr-o stare destul de stabil\u0103, iar num\u0103rul incidentelor \u00eenregistrate este mic. Cu toate acestea, au fost identificate anomalii care duc la defectare cu 5 \u2013 10 minute \u00eenainte de apari\u021bia defectului. \u00cen unele cazuri, notificarea despre defectare ar fi ajutat s\u0103 se economiseasc\u0103 timpul alocat pentru efectuarea lucr\u0103rilor de \u201erepara\u021bie\u201d.<\/p>\n

      <\/p>\n

      \u00cen urma experimentelor realizate, este prea devreme pentru a trasa concluzii definitive. \u00cen acest moment, rezultatele sunt contradictorii. Pe de o parte, se observ\u0103 c\u0103 algoritmii pe baz\u0103 de re\u021bele neuronale sunt capabili s\u0103 identifice anomalii \u201eutile\u201d. Pe de alt\u0103 parte, r\u0103m\u00e2ne un procent mare de alarme false, iar nu toate anomaliile identificate de un specialist calificat pot fi detectate de re\u021beaua neuronal\u0103. Un dezavantaj este c\u0103, \u00een prezent, re\u021beaua neuronal\u0103 necesit\u0103 un antrenament bazat pe un profesor pentru a func\u021biona corect.<\/p>\n

      <\/p>\n

      Pentru dezvoltarea ulterioar\u0103 a sistemului de prognoz\u0103 a defectelor \u0219i pentru a-l aduce \u00eentr-o stare satisf\u0103c\u0103toare, se pot lua \u00een considerare mai multe direc\u021bii. Este necesar un analize mai detaliate ale incidentelor cu anomalii care conduc la defec\u021biuni, prin ad\u0103ugarea unei liste de metri critici care afecteaz\u0103 semnificativ starea sistemului \u0219i eliminarea celor irelevante. De asemenea, continu\u00e2nd \u00een aceast\u0103 direc\u021bie, s-ar putea \u00eencerca specializarea algoritmilor specific pentru cazurile noastre de anomalii care duc la defecte. Exist\u0103 \u0219i o alt\u0103 cale. Aceasta ar fi \u00eembun\u0103t\u0103\u021birea arhitecturilor re\u021belelor neuronale \u0219i, \u00een acest fel, cre\u0219terea preciziei de detec\u021bie \u0219i reducerea timpului de antrenare.<\/p>\n

      <\/p>\n

      \u00cei mul\u021bumesc colegilor care m-au ajutat la redactarea \u0219i men\u021binerea actualit\u0103\u021bii acestui articol: Victor Verbitsky<\/a><\/noindex> \u0219i Serghei Finogenov.<\/p>\n

      Sursa: 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\udd47C\u0103ut\u0103m anomalii \u0219i prezicem defecte cu ajutorul re\u021belelor neuronale | ProHoster","description":"Dezvoltare industrial\u0103.","canonical_url":"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/ishhem-anomalii-i-predskazyvaem-sboi-s-pomoshhyu-nejrosetej","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"ro_RO","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.","og:url":"https:\/\/prohoster.info\/ro\/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","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/posts\/53531","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/comments?post=53531"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/posts\/53531\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/media?parent=53531"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/categories?post=53531"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/tags?post=53531"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}