{"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\/et\/blog\/administrirovanie\/ishhem-anomalii-i-predskazyvaem-sboi-s-pomoshhyu-nejrosetej","title":{"rendered":"Otsime anomaaliaid ja ennustame t\u00f5rkeid tehisintellekti abil","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Otsime<\/p>\n

<\/p>\n

T\u00f6\u00f6stuslike tarkvara arendamine n\u00f5uab suurt t\u00e4helepanu l\u00f5pp-produkti t\u00f6\u00f6kindlusele ning kiiret reageerimist, kui t\u00f5rkeid ja eba\u00f5nnestumisi ikka juhtub. J\u00e4lgimine aitab loomulikult t\u00f5rgete ja eba\u00f5nnestumistele efektiivsemalt ja kiiremini reageerida, kuid see ei ole piisav. Esiteks on v\u00e4ga keeruline hallata suurt hulka servereid \u2013 selleks on vaja palju inimesi. Teiseks tuleb h\u00e4sti m\u00f5ista, kuidas rakendus t\u00f6\u00f6tab, et prognoosida selle seisundit. Seega on vaja palju inimesi, kes m\u00f5istavad p\u00f5hjalikult meie arendatavaid s\u00fcsteeme, nende n\u00e4itajaid ja erip\u00e4rasid. Eeldame, et isegi kui leida piisavalt inimesi, kes on valmis sellega tegelema, kulub nende koolitamiseks samuti m\u00e4rkimisv\u00e4\u00e4rselt aega.<\/p>\n

<\/p>\n

Mida siis teha? Siin tuleb meile appi tehisintellekt. Artiklis on jutt ennustuslikust hooldusest<\/a><\/noindex> (predictive maintenance). See l\u00e4henemine on aktiivselt populaarsust kogumas. On kirjutatud mitmeid artikleid, sealhulgas ka Habrile. Suured ettev\u00f5tted kasutavad seda l\u00e4henemist juba t\u00e4ie hooga oma serverite t\u00f6\u00f6kindluse tagamiseks. P\u00e4rast paljude artiklite uurimist otsustasime proovida seda l\u00e4henemist rakendada. Mis sellest v\u00e4lja tuli? <\/p>\n

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

Sissejuhatus<\/h2>\n

<\/p>\n

Arendatud tarkvaras\u00fcsteem j\u00f5uab varem v\u00f5i hiljem kasutusse. Kasutajale on oluline, et s\u00fcsteem t\u00f6\u00f6taks t\u00f5rgeteta. Kui siiski juhtub \u00e4\u00e4rmuslik olukord, peab see olema k\u00f5rvaldatud minimaalsete viivitustega. <\/p>\n

<\/p>\n

Tehnilise toe lihtsustamiseks tarkvaras\u00fcsteemis, eriti kui servereid on palju, kasutatakse tavaliselt j\u00e4lgimisprogramme, mis koguvad andmeid t\u00f6\u00f6lt olevast tarkvaras\u00fcsteemist, v\u00f5imaldavad diagnoosida selle seisundit ja aitavad m\u00e4\u00e4rata, mis t\u00f5rkeid p\u00f5hjustas. Seda protsessi nimetatakse tarkvaras\u00fcsteemi j\u00e4lgimiseks.<\/p>\n

\n\"Otsime<\/p>\n

Joonis 1. J\u00e4lgimise liides Grafanas<\/em><\/p>\n

M\u00f5\u00f5dikud on erinevad n\u00e4itajad tarkvaras\u00fcsteemi, selle t\u00f6\u00f6tamise keskkonna v\u00f5i f\u00fc\u00fcsilise arvutimasina kohta, mille all s\u00fcsteem on, koos ajatempli hetkega, mil m\u00f5\u00f5dikud saadi. Statistilises anal\u00fc\u00fcsis nimetatakse m\u00f5\u00f5dikute andmeid ajas tehtud ridadeks. Tarkvaras\u00fcsteemi oleku j\u00e4lgimiseks kuvatakse m\u00f5\u00f5dikud graafikutena: X- telg \u2013 aeg ja Y-telg \u2013 v\u00e4\u00e4rtused (joonis 1). T\u00f6\u00f6tavas tarkvaras\u00fcsteemis saab v\u00f5tta mitut tuhat m\u00f5\u00f5dikut (igal s\u00f5lmel). Need moodustavad m\u00f5\u00f5dikute ruumi (mitmem\u00f5\u00f5tmelised ajas tehtud read). <\/p>\n

<\/p>\n

Kuna keeruliste tarkvaras\u00fcsteemide korral kogutakse suuri m\u00f5\u00f5dikute koguseid, muutub k\u00e4sitsi j\u00e4lgimine keeruliseks \u00fclesandeks. Juhtimise andmete hulga v\u00e4hendamiseks sisaldavad j\u00e4lgimisvahendid automatisatsiooni t\u00f6\u00f6riistu, mis aitavad tuvastada v\u00f5imalikke probleeme. N\u00e4iteks saab seadistada p\u00e4\u00e4stiku, mis aktiveerub, kui vaba k\u00f5vakettaruumi hulk langeb alla m\u00e4\u00e4ratud l\u00e4vendi. Samuti saab automaatselt diagnoosida serveri seiskumist v\u00f5i teenindamise kiiruse kriitilist aeglustumist. Praktikas suudavad j\u00e4lgimisvahendid h\u00e4sti tuvastada juba toimunud v\u00e4\u00e4rasid v\u00f5i lihtsaid s\u00fcmptomeid tulevastest v\u00e4ljasuremistest, kuid kokkuv\u00f5ttes j\u00e4\u00e4b v\u00f5imalikud rikete ennustamine neile keeruliseks p\u00e4hkliks. Ennustamine k\u00e4sitsi anal\u00fc\u00fcsides m\u00f5\u00f5dikuid n\u00f5uab kvalifitseeritud spetsialistide kaasamist. See on madala tootlikkusega. Enamik v\u00f5imalikke riketeid v\u00f5ivad j\u00e4\u00e4da m\u00e4rkamatuks.<\/p>\n

<\/p>\n

Viimasel ajal on suurte IT-ettev\u00f5tete seas tarkvaraarenduse hullus kasvanud nn ennustava hoolduse populaarsus. Selle l\u00e4henemise tuum seisneb t\u00f5rgete leidmises, mis viivad s\u00fcsteemi degradeerumiseni varases faasis, enne rikke teket tehisintellekti kasutades. See l\u00e4henemine ei v\u00e4lista t\u00e4ielikult k\u00e4sitsi s\u00fcsteemi j\u00e4lgimist. See on abistav j\u00e4lgimisprotsessis laiemalt. <\/p>\n

<\/p>\n

Peamine t\u00f6\u00f6riist ennustava hoolduse rakendamiseks on anomaaliate otsimise \u00fclesanne ajas tehtud ridades, kuna anomaalia ilmnemisel<\/strong> andmetes on suur t\u00f5en\u00e4osus, et m\u00f5ne aja p\u00e4rast v\u00f5ib tekkida t\u00f5rge v\u00f5i rike<\/strong>. Anomaalia on mingi programmeerimiss\u00fcsteemi n\u00e4itaja k\u00f5rvalekalle, n\u00e4iteks \u00fche t\u00fc\u00fcbi p\u00e4ringu t\u00f6\u00f6tlemise aegade halvenemine v\u00f5i keskmise teenindatavate p\u00e4ringute arvu v\u00e4henemine pideva kliendiseansside taseme juures.<\/p>\n

<\/p>\n

Anomaaliate otsimise \u00fclesanne programmeerimiss\u00fcsteemides omab oma erip\u00e4ra. Idee kohaselt on iga programmeerimiss\u00fcsteemi jaoks vajalik olemasolevate meetodite v\u00e4ljat\u00f6\u00f6tamine v\u00f5i kohandamine, kuna anomaaliate otsimine s\u00f5ltub v\u00e4ga andmetest, milles see toimub, ja programmeerimiss\u00fcsteemide andmed erinevad oluliselt s\u00f5ltuvalt s\u00fcsteemi teostamisest, sealhulgas sellest, millisel arvutimasinal see t\u00f6\u00f6tab.<\/p>\n

<\/p>\n

Anomaaliate otsimise meetodid programmeerimiss\u00fcsteemide riketegude prognoosimiseks<\/h2>\n

<\/p>\n

Esiteks on oluline v\u00e4lja tuua, et riketegude prognoosimise idee sai inspiratsiooni artiklist \u00abMasin\u00f5pe IT-monitooringus\u00bb<\/a><\/noindex>. Juhul, kui automaatsete anomaaliate otsimise l\u00e4henemise t\u00f5husust kontrolliti, valiti programmeerimiss\u00fcsteemiks \u201eWeb-Konsolideerimine\u201d, mis on \u00fcks NPO \u201eKrista\u201d projektidest. Selle jaoks tehti varem k\u00e4sitsi monitooring saadud n\u00e4itajate p\u00f5hjal. Kuna s\u00fcsteem on piisavalt keeruline, j\u00e4lgitakse selle jaoks suurt hulka n\u00e4itajaid: JVM-i n\u00e4itajad (pr\u00fcgikogujate koormus), operatsioonis\u00fcsteemi n\u00e4itajad, mille all kood t\u00f6\u00f6tab (virtuaalne m\u00e4lu, CPU koormuse %), v\u00f5rgu n\u00e4itajad (v\u00f5rgu koormus), serveri n\u00e4itajad (CPU, m\u00e4lu koormus), wildfly n\u00e4itajad ja rakenduse enda n\u00e4itajad k\u00f5ikide kriitiliste alams\u00fcsteemide p\u00f5hjal. <\/p>\n

<\/p>\n

K\u00f5ik n\u00e4itajad kogutakse s\u00fcsteemist graphite abil. Alguses kasutati whisper andmebaasi standardlahendusena grafana jaoks, kuid klientide arvu kasvades ei suutnud graphite enam koormust taluda, ammendades andmekeskuse kettaaluste l\u00e4bilaskev\u00f5ime. P\u00e4rast seda tehti otsus otsida t\u00f5husamat lahendust. Valik langes graphite+clickhouse<\/a><\/noindex>, mis v\u00f5imaldas oluliselt v\u00e4hendada koormust kettaalustele ja v\u00e4hendada \u00fche kuni kuue korra ketta mahtu. Allpool on esitatud skeem metrikate kogumise mehhanismist graphite+clickhouse abil (joonis 2).<\/p>\n

\n\"Otsime
\n<\/p>\n

Joonis 2. Metrikate kogumise skeem<\/em><\/p>\n

Skeem on saadud sisejuhendist. Sellel on kujutatud andmevahetust grafana (kasutajaliides j\u00e4lgimiseks, mida me kasutame) ja graphite'i vahel. Rakendusest m\u00f5\u00f5tmete v\u00f5tmiseks kasutatakse eraldi tarkvara \u2013 jmxtrans<\/a><\/noindex>. See samuti salvestab need graphite'i.
\nVeebikonsolideerimise s\u00fcsteemil on mitmeid omadusi, mis tekitavad probleemide ennustamisel:<\/p>\n

<\/p>\n

    \n
  1. trendide vahetamine toimub sageli. Sellel tarkvaras\u00fcsteemil ilmuvad erinevad versioonid. Igas neist on muudatused s\u00fcsteemi programmitasandil. Seega m\u00f5jutavad arendajad otse selle s\u00fcsteemi m\u00f5\u00f5tmeid ja v\u00f5ivad p\u00f5hjustada trendide muutumist; <\/li>\n
  2. rakenduse erip\u00e4ra, samuti s\u00fcsteemi klientide kasutusmotiivid toovad sageli esile anomaaliaid ilma eelneva degradatsioonita; <\/li>\n
  3. anomaaliate osakaal kogu andmekogus on v\u00e4ike (< 5%); <\/li>\n
  4. k\u00f5ige m\u00f5\u00f5tmete saamisel v\u00f5ib esineda katkestusi. M\u00f5nel l\u00fchikesel ajaperioodil ei suuda j\u00e4lgimiss\u00fcsteem m\u00f5\u00f5tmeid hankida. N\u00e4iteks, kui server on \u00fcle koormatud. Kuidas see m\u00f5jutab n\u00e4rviv\u00f5rku, on kriitiline. Tekkib vajadus t\u00e4ita l\u00fcnki s\u00fcnteesiliselt;<\/li>\n
  5. Anomaaliad on sageli olulised ainult konkreetse arvu\/kuid\/aja jaoks (hooaegsus). Sellel s\u00fcsteemil on selged reeglid kasutamiseks. Seega on m\u00f5\u00f5dud \u0430\u043a\u0442\u0443\u0430\u043b\u044c\u043d\u044b \u0442\u043e\u043b\u044c\u043a\u043e \u043a\u043e\u043d\u043a\u0440\u0435\u0442\u043d\u043e\u043c\u0443 \u0432\u0440\u0435\u043c\u0435\u043d\u0438. S\u00fcsteemi v\u00f5ib kasutada mitte pidevalt, vaid ainult teatud kuudel: valikuliselt s\u00f5ltuvalt aastast. Tekkivad olukorrad, kus sama m\u00f5\u00f5tmete k\u00e4itumine \u00fches olukorras v\u00f5ib p\u00f5hjustada tarkvaras\u00fcsteemi t\u00f5rke, samas kui teises see ei pruugi;
    \nAlustuseks anal\u00fc\u00fcsiti meetodeid anomaalide avastamiseks tarkvaras\u00fcsteemide j\u00e4lgimisandmetes. Seda teemat k\u00e4sitlevates artiklites, kui anomaaliate osakaal on v\u00e4ike, on sageli soovitatud kasutada n\u00e4rviv\u00f5rke. <\/li>\n<\/ol>\n

    <\/p>\n

    Peamine loogika anomaaliate leidmiseks n\u00e4rviv\u00f5rkude abil on kujutatud joonisel 3:<\/p>\n

    \n\"Otsime
    \n<\/p>\n

    Joonis 3. Anomaaliate leidmine n\u00e4rviv\u00f5rgu abil<\/em><\/p>\n

    Prognoosi v\u00f5i hetkevoo metrikate taastamise tulemuses arvutatakse k\u00f5rvalekalle saadud andmetest aktiivse tarkvaras\u00fcsteemi puhul. Suure erinevuse korral saadud metrikate ja n\u00e4rviv\u00f5rgu vahel v\u00f5ib j\u00e4reldada, et k\u00e4esolev andmeosa on ebanormaalne. Tekivad j\u00e4rgmised probleemid n\u00e4rviv\u00f5rkude kasutamisel:<\/p>\n

    <\/p>\n

      \n
    1. korrektseks t\u00f6\u00f6ks voogesituse re\u017eiimis peavad n\u00e4rviv\u00f5rkude mudelite koolitamiseks kasutatavad andmed sisaldama vaid \"normaalseid\" andmeid; <\/li>\n
    2. peab olema olemas ajakohane mudel korrektseks avastamiseks. Suundumuse ja hooajalisuse muutmine metrikates v\u00f5ib p\u00f5hjustada palju valeh\u00e4ireid mudelis. Selle v\u00e4rskendamiseks on vajalik selgelt m\u00e4\u00e4ratleda aeg, millal mudel muutub aegunuks. Kui mudel uuendatakse liiga vara v\u00f5i liiga hilja, siis on t\u00f5en\u00e4oliselt tagaj\u00e4rjeks suur hulk valeh\u00e4ireid.
      \nSamuti ei tohi unustada valeh\u00e4irete sagedase esinemise otsimist ja ennetamist. Eeldatakse, et need esinevad k\u00f5ige sagedamini avariiliste olukordade korral. Kuid need v\u00f5ivad olla ka n\u00e4rviv\u00f5rgu vea tagaj\u00e4rg selle ebapiisava koolituse t\u00f5ttu. On oluline v\u00e4hendada mudeli valeh\u00e4irete arvu. Vastasel juhul kulutavad valeprognoosid palju administraatori aega s\u00fcsteemi kontrollimiseks. Varem v\u00f5i hiljem j\u00f5uab see sinnamaale, et administraator l\u00f5petab lihtsalt \"paranoilise\" j\u00e4lgimiss\u00fcsteemi j\u00e4lgimise.<\/li>\n<\/ol>\n

      <\/p>\n

      Rekurentsne n\u00e4rviv\u00f5rk<\/h2>\n

      <\/p>\n

      Ajavahemike anomaaliate avastamiseks v\u00f5ib kasutada rekurentsset n\u00e4rviv\u00f5rku <\/a><\/noindex>LSTM m\u00e4luga. Probleem on vaid selles, et seda saab kasutada ainult prognoositavate ajavahemike puhul. Meie juhul ei ole k\u00f5ik metrikad prognoositavad. Katse kasutada RNN LSTM-i ajavahemiku jaoks on esitatud joonisel 4.<\/p>\n

      \n\"Otsime
      \n<\/p>\n

      Joonis 4. N\u00e4ide rekurentsse n\u00e4rviv\u00f5rgust LSTM m\u00e4luelementidega<\/em><\/p>\n

      Nagu jooniselt 4 n\u00e4htub, suutis RNN LSTM tuvastada anomaalia selle ajavahemiku jooksul. Seal, kus tulemuste prognoosimisviga (keskmine viga) on k\u00f5rge, toimus t\u00f5eliselt anomaalia. \u00dche RNN LSTM kasutamine on selgelt ebapiisav, kuna see sobib ainult v\u00e4ikese arvu m\u00f5\u00f5dikute rakendamiseks. Anomaaliate tuvastamiseks v\u00f5ib kasutada k\u00f5rvalmeetodina. <\/p>\n

      <\/p>\n

      Autokooder riketega prognoosimiseks<\/h2>\n

      <\/p>\n

      Autokooder<\/a><\/noindex> \u2013 sisuliselt tehisneurov\u00f5rk. Sissevoolu kiht \u2013 kodeerija, v\u00e4ljundkiht \u2013 dekodeerija. K\u00f5ikide antud t\u00fc\u00fcpi n\u00e4rviv\u00f5rkude puuduseks on halvasti lokaliseeritud anomaaliad. Valiti s\u00fcnkroonse autokooderi arhitektuur.<\/p>\n

      \n\"Otsime
      \n<\/p>\n

      Joonis 5. Autokooderi t\u00f6\u00f6 n\u00e4ide<\/em><\/p>\n

      Autokooderid koolitatakse normaaldatasetel ja seej\u00e4rel tuvastavad nad mudelile sisendatud andmev\u00e4li anomaaliad. Just see, mida antud \u00fclesanne vajab. Peab ainult valima, milline autokooder sobib antud \u00fclesande jaoks. Arhitektiilis k\u00f5ige lihtsam autokooder on sirge, tagasip\u00f6\u00f6rdumatud n\u00e4rviv\u00f5rk, mis on v\u00e4ga sarnane multikiht-perceptroniga<\/a><\/noindex> (multilayer perceptron, MLP), millel on sisendkiht, v\u00e4ljundkiht ja \u00fcks v\u00f5i mitu peidetud kihti, mis neid \u00fchendavad.
      \nKuid erinevused autokooderite ja MLP vahel seisnevad selles, et autokooderi v\u00e4ljundkiht sisaldab sama palju s\u00f5lmi kui sisendkiht ning et autokooder \u00f5pib rekonstrueerima oma X v\u00e4\u00e4rtusi, mitte prognoosima sihtv\u00e4\u00e4rtust Y, mis on m\u00e4\u00e4ratud sisendi X j\u00e4rgi. Seega on autokooderid mittet\u00e4ieliku juhendamisega \u00f5ppe mudelid. <\/p>\n

      <\/p>\n

      Autokooderi \u00fclesanne on leida ajaliselt indekseid r0 ... rn, mis vastavad anomaalsetele elementidele sisendvektoris X. See efekt saavutatakse kvadratuurse vea otsimise kaudu.<\/p>\n

      \n\"Otsime <\/p>\n

      Joonis 6. S\u00fcnkroonne autokooder<\/em><\/p>\n

      Autokooderi jaoks valiti s\u00fcnkroonne arhitektuur<\/a><\/noindex>. Selle eelised: voogude t\u00f6\u00f6tlemise re\u017eiimi kasutamise v\u00f5imalus ning v\u00f5rreldes teiste arhitektuuridega on n\u00e4rviv\u00f5rgu parameetreid m\u00e4rgatavalt v\u00e4hem.<\/p>\n

      <\/p>\n

      Valeh\u00e4irete minimeerimise mehhanism<\/h2>\n

      <\/p>\n

      Seoses erinevate erandlike olukordade esinemise ja tehisintellekti koolituse v\u00f5imalikest puudustest, on v\u00e4lja t\u00f6\u00f6tatavatele anomaaliate avastamise mudelitele otsustatud luua valeh\u00e4irete minimeerimise mehhanism. See mehhanism p\u00f5hineb administraatori klassifitseeritud mallide andmebaasil. <\/p>\n

      <\/p>\n

      D\u00fcnaamilise ajaskaalatansformatsiooni algoritm<\/a><\/noindex> (DTW-algoritm, inglise keeles dynamic time warping) v\u00f5imaldab leida optimaalse vaste ajaj\u00e4rjendite vahel. Esmakordselt rakendati seda k\u00f5netuvastuses, et m\u00e4\u00e4rata, kuidas kaks k\u00f5nesignaalivid esindavad sama algset h\u00e4\u00e4ldatud fraasi. Hiljem leiti selle jaoks rakendusi ka teistes valdkondades.<\/p>\n

      <\/p>\n

      Valeh\u00e4irete minimeerimise p\u00f5hialus on referentside kogumine operaatori abil, kes klassifitseerib kahtlased juhtumid, mis on tuvastatud n\u00e4rviv\u00f5rkude abil. Seej\u00e4rel v\u00f5rreldakse klassifitseeritud referentsi juhtumiga, mille s\u00fcsteem avastas, ning tehakse j\u00e4reldus, kas juhtum on valeh\u00e4ire v\u00f5i t\u00f5rke p\u00f5hjustaja. Just kahe ajaj\u00e4rgu v\u00f5rdlemiseks kasutatakse DTW algoritmi. Peamine t\u00f6\u00f6riist valeh\u00e4irete minimeerimiseks on siiski klassifitseerimine. Eeldatakse, et p\u00e4rast suure hulga referentsjuhtumite kogumist hakkab s\u00fcsteem operaatorilt v\u00e4hem k\u00fcsima, kuna enamik juhtumeid on sarnased ja esinevad sarnased.<\/p>\n

      <\/p>\n

      Tulemusena, tuginedes \u00fclaltoodud n\u00e4rviv\u00f5rkude meetoditele, on loodud eksperimentaalne programm \u201eWeb-Konsolideerimine\u201d s\u00fcsteemi t\u00f5rgete prognoosimiseks. Selle programmi eesm\u00e4rk oli kasutada olemasolevat j\u00e4lgimisandmete arhiivi ja juba toimunud t\u00f5rgete teavet, et hinnata selle l\u00e4henemise sobivust meie tarkvaras\u00fcsteemide jaoks. Programa t\u00f6\u00f6 skeem on esitatud allpool, joonisel 7.<\/p>\n

      \n\"Otsime <\/p>\n

      Joonis 7. T\u00f5rgete prognoosimise skeem metrikate ruumi anal\u00fc\u00fcsi p\u00f5hjal<\/em><\/p>\n

      Skeemil v\u00f5ib eristada kahte p\u00f5hiblokki: anomaliseeritud ajavahemike otsimine j\u00e4lgimisandmete (metrikate) voos ja valeh\u00e4irete minimeerimise mehhanism. M\u00e4rkus: eksperimentaalsetes eesm\u00e4rkides saadakse andmed JDBC-\u00fchenduse kaudu andmebaasist, kuhu need salvestatakse graphite.
      \nAllpool on esitatud arendatud monitooringus\u00fcsteemi liides (joonis 8).<\/p>\n

      \n\"Otsime<\/p>\n

      Joonis 8. Eksperimentaalse monitooringus\u00fcsteemi liides<\/em><\/p>\n

      Liideses kuvatakse saadud meetmete anomaalsuse protsent. Meie puhul simuleeritakse saadud andmeid. Meil on juba olemas andmed mitme n\u00e4dala jooksul ja laadime need j\u00e4rk-j\u00e4rgult, et kontrollida juhtumit, millega kaasneb rike. Alumises staatusteenuses kuvatakse andmete \u00fcldine anomaalsuse protsent antud ajahetkel, mis m\u00e4\u00e4ratakse automaatkooderija abil. Samuti kuvatakse prognoositavate meetmete jaoks eraldi protsent, mida arvutab RNN LSTM.<\/p>\n

      <\/p>\n

      N\u00e4ide CPU n\u00e4itajate anomaalsuse tuvastamisest RNN LSTM n\u00e4rviv\u00f5rgu abil (joonis 9).<\/p>\n

      \n\"Otsime<\/p>\n

      Joonis 9. RNN LSTM tuvastamine<\/em><\/p>\n

      Suhteliselt lihtne juhtum, p\u00f5him\u00f5tteliselt tavaline v\u00e4ljaj\u00e4tmine, kuid s\u00fcsteemi rikke p\u00f5hjustav, tuvastati edukalt RNN LSTM abil. Anomaalsuse n\u00e4itaja sel ajal oli 85 \u2013 95%, k\u00f5ik, mis \u00fcletab 80% (l\u00e4vi m\u00e4\u00e4ratleti eksperimentaalselt), loetakse anomaaliaks.
      \nN\u00e4ide anomaalsuse tuvastamisest, kui s\u00fcsteem ei suutnud p\u00e4rast v\u00e4rskendust k\u00e4ivituda. Antud olukorra tuvastab automaatkooderija (joonis 10).<\/p>\n

      \n\"Otsime<\/p>\n

      Joonis 10. N\u00e4ide automaatkooderija tuvastamisest<\/em><\/p>\n

      Nagu jooniselt n\u00e4ha, j\u00e4i PermGen \u00fchele tasemele. Automaatkooderija pidas seda kummaliseks, kuna ta ei olnud varem midagi sarnast n\u00e4inud. Siin hoiab anomaalsus 100% kuni s\u00fcsteemi t\u00f6\u00f6v\u00f5ime taastumiseni. Anomaalsus kuvatakse k\u00f5ikide meetmete puhul. Nagu mainitud, ei oska automaatkooderija anomaaliat lokaliseerida. Operaatoreid ootab see funktsioon antud olukordades.<\/p>\n

      <\/p>\n

      Kokkuv\u00f5te<\/h2>\n

      <\/p>\n

      PC \"Web-Konsolideerimine\" on arendatud mitte esimest aastat. S\u00fcsteem on piisavalt stabiilses seisundis ja registreeritavate intsidentide arv on v\u00e4ike. Siiski on \u00f5nnestunud tuvastada anomaaliad, mis viivad rikkeni 5 \u2013 10 minutit enne rikke tekkimist. Mitmetel juhtudel aitaks rikkehoiatus aegsasti kokku hoida regulatiivset aega, mis on eraldatud \"remondit\u00f6\u00f6de\" tegemiseks.<\/p>\n

      <\/p>\n

      K\u00e4teval p\u00f5hinevad katsed on n\u00e4idanud, et l\u00f5plikke j\u00e4reldusi on veel vara teha. Praegused tulemused on vastuolulised. \u00dchelt poolt on n\u00e4ha, et n\u00e4rviv\u00f5rgup\u00f5hised algoritmid suudavad tuvastada \"kasulikke\" anomaaliaid. Teiselt poolt j\u00e4\u00e4b suur osa valeh\u00e4ireid ja k\u00f5ik anomaaliad, mille kvalifitseeritud spetsialist tuvastab, ei pruugi n\u00e4rviv\u00f5rk suuta avastada. Negatiivseks k\u00fcljeks on samuti see, et praegu vajab n\u00e4rviv\u00f5rk normaalseks toimimiseks \u00f5petajaga \u00f5petamist.<\/p>\n

      <\/p>\n

      S\u00fcsteemi rikkeennustuse edasiseks arendamiseks ja selle viimiseks rahuldavale tasemele on v\u00f5imalik kaaluda mitmeid teid. Need h\u00f5lmavad \u00fcksikasjalikumat anal\u00fc\u00fcsi anomaaliatest, mis p\u00f5hjustavad rikkeid, muutes oluliseks metrikate loetelu, mis tugevalt m\u00f5jutavad s\u00fcsteemi seisundit, ning k\u00f5rvaldades need, mis ei m\u00f5juta seda. Kui liikuda sellel teel edasi, v\u00f5iks proovida spetsialiseerida algoritme just meie anomaaliate juhtumitele, mis p\u00f5hjustavad rikkeid. On ka teine tee. See on n\u00e4rviv\u00f5rkude arhitektuuride t\u00e4iustamine ja seel\u00e4bi avastuste t\u00e4psuse t\u00f5stmine, v\u00e4hendades samal ajal \u00f5pikestuse aega.<\/p>\n

      <\/p>\n

      T\u00e4nan kolleege, kes aitasid mul selle artikli kirjutamisel ja ajakohasena hoidmisel: Viktor Verbitski<\/a><\/noindex> ja Sergei Finogenov.<\/p>\n

      Allikas: 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\udd47Otsime anomaaliaid ja ennustame rikkeid n\u00e4rviv\u00f5rkude abil | ProHoster","description":"T\u00f6\u00f6stuslik arendus.","canonical_url":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/ishhem-anomalii-i-predskazyvaem-sboi-s-pomoshhyu-nejrosetej","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"et_EE","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\/et\/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\/et\/wp-json\/wp\/v2\/posts\/53531","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/comments?post=53531"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts\/53531\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/media?parent=53531"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/categories?post=53531"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/tags?post=53531"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}