{"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\/pl\/blog\/administrirovanie\/ishhem-anomalii-i-predskazyvaem-sboi-s-pomoshhyu-nejrosetej","title":{"rendered":"Wykrywamy anomalie i przewidujemy awarie za pomoc\u0105 sieci neuronowych","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Wykrywamy<\/p>\n

<\/p>\n

Przemys\u0142owy rozw\u00f3j system\u00f3w oprogramowania wymaga du\u017cej uwagi do odporno\u015bci ko\u0144cowego produktu oraz szybkiej reakcji na awarie i b\u0142\u0119dy, je\u015bli ju\u017c si\u0119 zdarz\u0105. Monitorowanie oczywi\u015bcie pomaga reagowa\u0107 na awarie i b\u0142\u0119dy skuteczniej i szybciej, ale to nie wystarcza. Po pierwsze, bardzo trudno \u015bledzi\u0107 du\u017c\u0105 liczb\u0119 serwer\u00f3w \u2013 potrzebna jest du\u017ca liczba os\u00f3b. Po drugie, trzeba dobrze rozumie\u0107, jak dzia\u0142a aplikacja, aby przewidzie\u0107 jej stan. W zwi\u0105zku z tym potrzebne s\u0105 dziesi\u0105tki os\u00f3b, kt\u00f3re dobrze rozumiej\u0105 systemy, kt\u00f3re rozwijamy, ich wska\u017aniki i cechy. Za\u0142\u00f3\u017cmy, \u017ce nawet gdyby znale\u017a\u0107 wystarczaj\u0105c\u0105 liczb\u0119 os\u00f3b ch\u0119tnych do zajmowania si\u0119 tym, potrzeba jeszcze sporo czasu, aby je przeszkoli\u0107.<\/p>\n

<\/p>\n

Co zrobi\u0107? Tu z pomoc\u0105 przychodzi sztuczna inteligencja. W artykule mowa b\u0119dzie o predykcyjnym utrzymaniu<\/a><\/noindex> (predictive maintenance). To podej\u015bcie zyskuje na popularno\u015bci. Napisano du\u017c\u0105 ilo\u015b\u0107 artyku\u0142\u00f3w, w tym na Habrze. Du\u017ce firmy powszechnie stosuj\u0105 to podej\u015bcie do utrzymania sprawno\u015bci swoich serwer\u00f3w. Po zapoznaniu si\u0119 z du\u017c\u0105 ilo\u015bci\u0105 artyku\u0142\u00f3w postanowili\u015bmy spr\u00f3bowa\u0107 zastosowa\u0107 t\u0119 metod\u0119. Co z tego wynik\u0142o? <\/p>\n

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

Wprowadzenie<\/h2>\n

<\/p>\n

Opracowany system oprogramowania pr\u0119dzej czy p\u00f3\u017aniej trafia do eksploatacji. U\u017cytkownikowi zale\u017cy na tym, aby system dzia\u0142a\u0142 bezawaryjnie. Je\u015bli jednak dojdzie do sytuacji awaryjnej, powinna ona by\u0107 eliminowana z minimalnymi op\u00f3\u017anieniami. <\/p>\n

<\/p>\n

Aby upro\u015bci\u0107 wsparcie techniczne systemu oprogramowania, zw\u0142aszcza gdy serwer\u00f3w jest du\u017co, zazwyczaj korzysta si\u0119 z program\u00f3w monitoruj\u0105cych, kt\u00f3re zbieraj\u0105 metryki z dzia\u0142aj\u0105cego systemu oprogramowania, umo\u017cliwiaj\u0105 diagnozowanie jego stanu i pomagaj\u0105 okre\u015bli\u0107, co spowodowa\u0142o awari\u0119. Proces ten nazywa si\u0119 monitorowaniem systemu oprogramowania.<\/p>\n

\n\"Wykrywamy<\/p>\n

Rysunek 1. Interfejs do monitorowania grafana<\/em><\/p>\n

Metryki to r\u00f3\u017cne wska\u017aniki systemu programowego, \u015brodowiska jego uruchomienia lub fizycznej maszyny obliczeniowej, pod kt\u00f3r\u0105 dzia\u0142a system z oznaczeniem czasu, w kt\u00f3rym metryki zosta\u0142y zebrane. W analizie statycznej dane metryk nazywane s\u0105 szeregami czasowymi. Aby monitorowa\u0107 stan systemu programowego, metryki przedstawiane s\u0105 w formie wykres\u00f3w: na osi X znajduje si\u0119 czas, a na osi Y warto\u015bci (rysunek 1). Z dzia\u0142aj\u0105cego systemu programowego mo\u017cna zbiera\u0107 kilka tysi\u0119cy metryk (z ka\u017cdego w\u0119z\u0142a). Tworz\u0105 one przestrze\u0144 metryk (wielowymiarowych szereg\u00f3w czasowych). <\/p>\n

<\/p>\n

Poniewa\u017c w z\u0142o\u017conych systemach programowych zbiera si\u0119 du\u017c\u0105 ilo\u015b\u0107 metryk, r\u0119czne monitorowanie staje si\u0119 trudnym zadaniem. Aby zmniejszy\u0107 obj\u0119to\u015b\u0107 danych analizowanych przez administratora, narz\u0119dzia monitoruj\u0105ce zawieraj\u0105 \u015brodki do automatycznego wykrywania potencjalnych problem\u00f3w. Na przyk\u0142ad mo\u017cna skonfigurowa\u0107 wyzwalacz, kt\u00f3ry uruchamia si\u0119 w przypadku spadku dost\u0119pnego miejsca na dysku poni\u017cej okre\u015blonego progu. Mo\u017cna r\u00f3wnie\u017c automatycznie diagnozowa\u0107 zatrzymanie serwera lub krytyczne spowolnienie pr\u0119dko\u015bci us\u0142ug. W praktyce narz\u0119dzia monitoruj\u0105ce dobrze radz\u0105 sobie z wykrywaniem ju\u017c wyst\u0119puj\u0105cych awarii lub identyfikowaniem prostych objaw\u00f3w przysz\u0142ych awarii, ale generalnie przewidywanie mo\u017cliwej awarii pozostaje dla nich twardym orzechem do zgryzienia. Przewidywanie poprzez r\u0119czn\u0105 analiz\u0119 metryk wymaga zaanga\u017cowania wykwalifikowanych specjalist\u00f3w. Jest to ma\u0142o produktywne. Wi\u0119kszo\u015b\u0107 potencjalnych awarii mo\u017ce pozostawa\u0107 niezauwa\u017cona.<\/p>\n

<\/p>\n

W ostatnim czasie w\u015br\u00f3d du\u017cych firm IT zajmuj\u0105cych si\u0119 tworzeniem oprogramowania zyskuje na popularno\u015bci tak zwane predykcyjne utrzymanie system\u00f3w programowych. Istota tego podej\u015bcia polega na wczesnym wykrywaniu usterek prowadz\u0105cych do degradacji systemu, zanim dojdzie do jego awarii, z u\u017cyciem sztucznej inteligencji. Podej\u015bcie to nie wyklucza ca\u0142kowicie r\u0119cznego monitorowania systemu. Jest ono pomocnicze dla procesu monitorowania jako ca\u0142o\u015bci. <\/p>\n

<\/p>\n

Podstawowym narz\u0119dziem do realizacji predykcyjnego utrzymania jest zadanie znajdowania anomalii w szeregach czasowych, poniewa\u017c przy wyst\u0105pieniu anomalii<\/strong> w danych istnieje wysokie prawdopodobie\u0144stwo, \u017ce wkr\u00f3tce wyst\u0105pi awaria lub b\u0142\u0105d<\/strong>. Anomalia to pewne odchylenie w wynikach systemu programowego, takie jak wykrycie degradacji pr\u0119dko\u015bci realizacji zapytania tego samego rodzaju lub zmniejszenie \u015bredniej liczby obs\u0142ugiwanych zapyta\u0144 przy sta\u0142ym poziomie sesji klient\u00f3w.<\/p>\n

<\/p>\n

Zadanie wykrywania anomalii w systemach programowych ma swoj\u0105 specyfik\u0119. Zasadniczo dla ka\u017cdego systemu programowego konieczne jest opracowanie lub poprawienie istniej\u0105cych metod, poniewa\u017c wykrywanie anomalii bardzo zale\u017cy od danych, w kt\u00f3rych jest realizowane, a dane system\u00f3w programowych bardzo r\u00f3\u017cni\u0105 si\u0119 w zale\u017cno\u015bci od narz\u0119dzi implementacji systemu, a\u017c po to, na jakiej maszynie obliczeniowej jest uruchomiony.<\/p>\n

<\/p>\n

Metody wykrywania anomalii przy prognozowaniu awarii system\u00f3w programowych<\/h2>\n

<\/p>\n

Przede wszystkim warto powiedzie\u0107, \u017ce pomys\u0142 prognozowania awarii zosta\u0142 zainspirowany artyku\u0142em \u201eUczenie maszynowe w monitorowaniu IT\u201d<\/a><\/noindex>. Do weryfikacji skuteczno\u015bci podej\u015bcia do automatycznego wykrywania anomalii wybrano system programowy \u201eWeb-Konsolidacja\u201d, kt\u00f3ry jest jednym z projekt\u00f3w firmy NPO \u201eKrista\u201d. Dla tego systemu wcze\u015bniej przeprowadzano r\u0119czne monitorowanie na podstawie uzyskiwanych metryk. Poniewa\u017c system jest do\u015b\u0107 skomplikowany, zbiera si\u0119 dla niego du\u017c\u0105 ilo\u015b\u0107 metryk: wska\u017aniki JVM (obci\u0105\u017cenie zbieracza \u015bmieci), wska\u017aniki systemu operacyjnego, na kt\u00f3rym wykonuje si\u0119 kod (pami\u0119\u0107 wirtualna, % obci\u0105\u017cenia CPU systemu operacyjnego), wska\u017aniki sieci (obci\u0105\u017cenie sieci), samego serwera (obci\u0105\u017cenie CPU, pami\u0119ci), metryki wildfly oraz w\u0142asne metryki aplikacji dla wszystkich krytycznych podsystem\u00f3w. <\/p>\n

<\/p>\n

Wszystkie metryki s\u0105 zbierane z systemu przy u\u017cyciu graphite. Pocz\u0105tkowo u\u017cywano bazy whisper jako standardowego rozwi\u0105zania dla grafany, ale wraz ze wzrostem bazy klient\u00f3w graphite przesta\u0142 sobie radzi\u0107, wyczerpuj\u0105c przepustowo\u015b\u0107 systemu dyskowego centrum danych. Po tym podj\u0119to decyzj\u0119 o poszukiwaniu bardziej efektywnego rozwi\u0105zania. Wyb\u00f3r pad\u0142 na graphite+clickhouse<\/a><\/noindex>, co pozwoli\u0142o znacz\u0105co zmniejszy\u0107 obci\u0105\u017cenie systemu dyskowego i pi\u0119ciokrotnie-sze\u015bciokrotnie zmniejszy\u0107 zajmowan\u0105 przestrze\u0144 dyskow\u0105. Poni\u017cej przedstawiono schemat mechanizmu zbierania metryk z u\u017cyciem graphite+clickhouse (rysunek 2).<\/p>\n

\n\"Wykrywamy
\n<\/p>\n

Rysunek 2. Schemat zbierania metryk<\/em><\/p>\n

Schemat zosta\u0142 zaczerpni\u0119ty z dokumentacji wewn\u0119trznej. Pokazuje wymian\u0119 danych mi\u0119dzy grafana (interfejs u\u017cytkownika do monitorowania, kt\u00f3rego u\u017cywamy) a graphite. Zbieranie metryk z aplikacji odbywa si\u0119 za pomoc\u0105 osobnego oprogramowania \u2013 jmxtrans<\/a><\/noindex>. To oprogramowanie r\u00f3wnie\u017c zapisuje je w graphite.
\nSystem \u201eWeb-Konsolidacja\u201d ma szereg cech, kt\u00f3re stwarzaj\u0105 problemy w prognozowaniu awarii:<\/p>\n

<\/p>\n

    \n
  1. cz\u0119sto dochodzi do zmiany trendu. Dla tego systemu oprogramowania wydawane s\u0105 r\u00f3\u017cne wersje. Ka\u017cda z nich wprowadza zmiany w cz\u0119\u015bci programowej systemu. W ten spos\u00f3b deweloperzy maj\u0105 bezpo\u015bredni wp\u0142yw na metryki tego systemu i mog\u0105 spowodowa\u0107 zmian\u0119 trendu; <\/li>\n
  2. cecha realizacji oraz cele korzystania z tego systemu przez klient\u00f3w cz\u0119sto wywo\u0142uj\u0105 anomalia bez wcze\u015bniejszej degradacji; <\/li>\n
  3. odsetek anomalii w stosunku do ca\u0142ego zbioru danych jest ma\u0142y (< 5%); <\/li>\n
  4. mog\u0105 wyst\u0119powa\u0107 przerwy w otrzymywaniu wska\u017anik\u00f3w z systemu. W niekt\u00f3rych kr\u00f3tkich interwa\u0142ach czasowych system monitorowania nie jest w stanie uzyska\u0107 metryk. Na przyk\u0142ad, je\u015bli serwer jest przeci\u0105\u017cony. Dla szkolenia sieci neuronowej jest to krytyczne. Pojawia si\u0119 potrzeba syntetycznego wype\u0142niania luk;<\/li>\n
  5. Przypadki z anomaliami cz\u0119sto s\u0105 aktualne tylko dla konkretnego dnia\/miesi\u0105ca\/czasu (sezonowo\u015b\u0107). System ma jasno okre\u015blony regulamin korzystania przez swoich u\u017cytkownik\u00f3w. Odpowiednio, metryki s\u0105 aktualne tylko dla konkretnego czasu. System mo\u017ce by\u0107 u\u017cywany nieustannie, ale tylko w wybrane miesi\u0105ce: selektywnie w zale\u017cno\u015bci od roku. Pojawiaj\u0105 si\u0119 sytuacje, kiedy to samo zachowanie metryk w jednym przypadku mo\u017ce prowadzi\u0107 do awarii systemu oprogramowania, a w innym nie.
    \nNa pocz\u0105tku analizowane by\u0142y metody wykrywania anomalii w danych monitorowania system\u00f3w oprogramowania. W artyku\u0142ach na ten temat, przy ma\u0142ych procentach anomalii w stosunku do reszty zbioru danych, najcz\u0119\u015bciej proponuje si\u0119 u\u017cycie sieci neuronowych. <\/li>\n<\/ol>\n

    <\/p>\n

    G\u0142\u00f3wna logika wyszukiwania anomalii z u\u017cyciem danych sieci neuronowych jest przedstawiona na rysunku 3:<\/p>\n

    \n\"Wykrywamy
    \n<\/p>\n

    Rysunek 3. Wyszukiwanie anomalii z u\u017cyciem sieci neuronowej<\/em><\/p>\n

    W wyniku prognozy lub przywracania okna bie\u017c\u0105cego strumienia metryk obliczane jest odchylenie od uzyskanych z dzia\u0142aj\u0105cego systemu programowego. W przypadku du\u017cej r\u00f3\u017cnicy mi\u0119dzy uzyskanymi metrykami z systemu programowego a sieci\u0105 neuronow\u0105 mo\u017cna wnioskowa\u0107 o nieprawid\u0142owo\u015bci bie\u017c\u0105cego segmentu danych. Pojawia si\u0119 szereg problem\u00f3w zwi\u0105zanych z wykorzystaniem sieci neuronowych:<\/p>\n

    <\/p>\n

      \n
    1. Aby zapewni\u0107 prawid\u0142owe dzia\u0142anie w trybie strumieniowym, dane do uczenia modeli sieci neuronowych musz\u0105 obejmowa\u0107 tylko \u201enormalne\u201d dane; <\/li>\n
    2. Nale\u017cy mie\u0107 aktualny model, aby prawid\u0142owo wykrywa\u0107. Zmiana trendu i sezonowo\u015bci w metrykach mo\u017ce wywo\u0142a\u0107 du\u017c\u0105 liczb\u0119 fa\u0142szywych alarm\u00f3w modelu. Aby go zaktualizowa\u0107, konieczne jest dok\u0142adne okre\u015blenie momentu, w kt\u00f3rym model jest przestarza\u0142y. Je\u017celi zaktualizujemy model za p\u00f3\u017ano lub za wcze\u015bnie, prawdopodobnie nast\u0105pi wiele fa\u0142szywych alarm\u00f3w.
      \nNie mo\u017cna tak\u017ce zapomina\u0107 o poszukiwaniu i zapobieganiu cz\u0119stemu wyst\u0119powaniu fa\u0142szywych alarm\u00f3w. Zak\u0142ada si\u0119, \u017ce b\u0119d\u0105 one najcz\u0119\u015bciej wyst\u0119powa\u0107 w sytuacjach awaryjnych. Mog\u0105 one by\u0107 jednak tak\u017ce skutkiem b\u0142\u0119d\u00f3w w sieci neuronowej z powodu niedostatecznego jej uczenia. Nale\u017cy zminimalizowa\u0107 liczb\u0119 fa\u0142szywych alarm\u00f3w modelu. W przeciwnym razie fa\u0142szywe prognozy b\u0119d\u0105 poch\u0142ania\u0107 du\u017co czasu administratora, kt\u00f3ry powinien by\u0107 wykorzystany do kontroli systemu. Pr\u0119dzej czy p\u00f3\u017aniej doprowadzi to do tego, \u017ce administrator po prostu przestanie reagowa\u0107 na \u201eparanoidalny\u201d system monitorowania.<\/li>\n<\/ol>\n

      <\/p>\n

      Rekurencyjna sie\u0107 neuronowa<\/h2>\n

      <\/p>\n

      Aby wykrywa\u0107 nieprawid\u0142owo\u015bci w szeregach czasowych, mo\u017cna zastosowa\u0107 rekurencyjn\u0105 sie\u0107 neuronow\u0105 <\/a><\/noindex>z pami\u0119ci\u0105 LSTM. Problem polega tylko na tym, \u017ce mo\u017ce by\u0107 stosowana tylko do prognozowanych szereg\u00f3w czasowych. W naszym przypadku nie wszystkie metryki s\u0105 prognozowane. Pr\u00f3ba zastosowania RNN LSTM dla szeregu czasowego zosta\u0142a przedstawiona na rysunku 4.<\/p>\n

      \n\"Wykrywamy
      \n<\/p>\n

      Rysunek 4. Przyk\u0142ad dzia\u0142ania rekurencyjnej sieci neuronowej z kom\u00f3rkami pami\u0119ci LSTM<\/em><\/p>\n

      Jak przedstawiono na rysunku 4, RNN LSTM uda\u0142o si\u0119 poradzi\u0107 z wykrywaniem anomalii w tym czasie. Tam, gdzie wynik ma wysokie b\u0142\u0119dy prognozowania (\u015bredni b\u0142\u0105d), rzeczywi\u015bcie mia\u0142a miejsce anomalia wska\u017anik\u00f3w. U\u017cycie tylko RNN LSTM b\u0119dzie zdecydowanie niewystarczaj\u0105ce, poniewa\u017c nadaje si\u0119 do ograniczonej liczby metryk. Mo\u017cna u\u017cy\u0107 go jako pomocniczej metody wykrywania anomalii. <\/p>\n

      <\/p>\n

      Autoenkoder do prognozowania awarii<\/h2>\n

      <\/p>\n

      Autoenkoder<\/a><\/noindex> \u2013 to w zasadzie sztuczna sie\u0107 neuronowa. Warstwa wej\u015bciowa \u2013 encoder, warstwa wyj\u015bciowa \u2013 decoder. Wad\u0105 wszystkich sieci neuronowych tego typu jest s\u0142aba lokalizacja anomalii. Wybrano architektur\u0119 synchronicznego autoenkodera.<\/p>\n

      \n\"Wykrywamy
      \n<\/p>\n

      Rysunek 5. Przyk\u0142ad dzia\u0142ania autoenkodera<\/em><\/p>\n

      Autoenkodery s\u0105 szkolone na normalnych danych i nast\u0119pnie identyfikuj\u0105 co\u015b anormalnego w przekazywanych do modelu danych. To dok\u0142adnie to, czego potrzebujemy do tego zadania. Pozostaje tylko wybra\u0107, kt\u00f3ry z autoenkoder\u00f3w b\u0119dzie odpowiedni. Architektonicznie najprostsza forma autoenkodera to prosta, jednokierunkowa sie\u0107 neuronowa, kt\u00f3ra jest bardzo podobna do wielowarstwowego perceptronu<\/a><\/noindex> (multilayer perceptron, MLP), z warstw\u0105 wej\u015bciow\u0105, warstw\u0105 wyj\u015bciow\u0105 i jedn\u0105 lub kilkoma ukrytymi warstwami, kt\u00f3re je \u0142\u0105cz\u0105.
      \nJednak r\u00f3\u017cnice mi\u0119dzy autoenkoderami a MLP polegaj\u0105 na tym, \u017ce w autoenkoderze warstwa wyj\u015bciowa ma tyle samo w\u0119z\u0142\u00f3w co warstwa wej\u015bciowa, oraz \u017ce zamiast uczy\u0107 si\u0119 przewidywania warto\u015bci docelowej Y, danej przez wej\u015bcie X, autoenkoder uczy si\u0119 rekonstruowa\u0107 swoje w\u0142asne X. Dlatego autoenkodery s\u0105 modelami uczenia si\u0119 nienadzorowanego. <\/p>\n

      <\/p>\n

      Zadanie autoenkodera polega na znalezieniu indeks\u00f3w czasowych r0 \u2026 rn odpowiadaj\u0105cych anormalnym elementom w wektorze wej\u015bciowym X. Efekt ten osi\u0105ga si\u0119 poprzez poszukiwanie b\u0142\u0119du kwadratowego.<\/p>\n

      \n\"Wykrywamy <\/p>\n

      Rysunek 6. Synchroniczny autoenkoder<\/em><\/p>\n

      Dla autoenkodera wybrano architektur\u0119 synchroniczn\u0105<\/a><\/noindex>. Jej zalety to mo\u017cliwo\u015b\u0107 u\u017cycia trybu przetwarzania strumieniowego oraz stosunkowo mniejsza liczba parametr\u00f3w sieci neuronowej w por\u00f3wnaniu z innymi architekturami.<\/p>\n

      <\/p>\n

      Mechanizm minimalizacji fa\u0142szywych alarm\u00f3w<\/h2>\n

      <\/p>\n

      Ze wzgl\u0119du na wyst\u0119powanie r\u00f3\u017cnych sytuacji niestandardowych, a tak\u017ce mo\u017cliwo\u015b\u0107 niewystarczaj\u0105cego szkolenia sieci neuronowej, podj\u0119to decyzj\u0119 o konieczno\u015bci opracowania mechanizmu minimalizacji fa\u0142szywych alarm\u00f3w dla opracowywanego modelu wykrywania anomalii. Mechanizm ten oparty jest na bazie szablon\u00f3w, kt\u00f3r\u0105 klasyfikuje administrator. <\/p>\n

      <\/p>\n

      Algorytm dynamicznej transformacji osi czasu<\/a><\/noindex> (Algorytm DTW, z ang. dynamic time warping) umo\u017cliwia znalezienie optymalnego dopasowania mi\u0119dzy sekwencjami czasowymi. Po raz pierwszy zastosowano go w rozpoznawaniu mowy: u\u017cyto go do okre\u015blenia, jak dwa sygna\u0142y mowy przedstawiaj\u0105 t\u0119 sam\u0105 pierwotnie wypowiedzian\u0105 fraz\u0119. W p\u00f3\u017aniejszym czasie znaleziono dla niego zastosowanie r\u00f3wnie\u017c w innych dziedzinach.<\/p>\n

      <\/p>\n

      Podstawow\u0105 zasad\u0105 minimalizacji fa\u0142szywych alarm\u00f3w jest zbieranie bazy wzorc\u00f3w za pomoc\u0105 operatora, kt\u00f3ry klasyfikuje podejrzane przypadki zidentyfikowane przez sieci neuronowe. Nast\u0119pnie nast\u0119puje por\u00f3wnanie sklasyfikowanego wzorca z przypadkiem wykrytym przez system, co pozwala na ustalenie, czy przypadek jest fa\u0142szywy, czy prowadzi do awarii. Algorytm DTW jest u\u017cywany w\u0142a\u015bnie do por\u00f3wnania dw\u00f3ch szereg\u00f3w czasowych. G\u0142\u00f3wnym narz\u0119dziem minimalizacji jest jednak klasyfikacja. Zak\u0142ada si\u0119, \u017ce po zebraniu du\u017cej liczby wzorc\u00f3w system zacznie rzadziej pyta\u0107 operatora z powodu podobie\u0144stwa wi\u0119kszo\u015bci przypadk\u00f3w i pojawiania si\u0119 podobnych.<\/p>\n

      <\/p>\n

      W wyniku opisanych powy\u017cej metod sieci neuronowych stworzono eksperymentalny program do prognozowania awarii systemu \u201eWeb-Konsolidacja\u201d. Celem tego programu by\u0142o, wykorzystuj\u0105c istniej\u0105cy archiwum danych monitoruj\u0105cych i informacje o ju\u017c zaistnia\u0142ych awariach, oceni\u0107 skuteczno\u015b\u0107 tego podej\u015bcia dla naszych system\u00f3w programowych. Schemat dzia\u0142ania programu przedstawiono poni\u017cej, na rysunku 7.<\/p>\n

      \n\"Wykrywamy <\/p>\n

      Rysunek 7. Schemat prognozowania awarii na podstawie analizy przestrzeni metryk<\/em><\/p>\n

      Na schemacie mo\u017cna wyr\u00f3\u017cni\u0107 dwa podstawowe bloki: wyszukiwanie anom\u00e1ln\u00edch segment\u00f3w czasowych w strumieniu danych monitoruj\u0105cych (metrykach) oraz mechanizm minimalizacji fa\u0142szywych alarm\u00f3w. Uwaga: w celach eksperymentalnych dane uzyskuje si\u0119 przez po\u0142\u0105czenie JDBC z baz\u0105 danych, w kt\u00f3rej s\u0105 one przechowywane przez graphite.
      \nPoni\u017cej przedstawiono interfejs uzyskany w wyniku opracowania systemu monitorowania (rysunek 8).<\/p>\n

      \n\"Wykrywamy<\/p>\n

      Rysunek 8. Interfejs eksperymentalnego systemu monitorowania<\/em><\/p>\n

      Na interfejsie wy\u015bwietlany jest procent anomalii w otrzymywanych metrykach. W naszym przypadku modelowanie jest symulowane. Dysponujemy ju\u017c wszystkimi danymi z kilku tygodni i stopniowo je wczytujemy, aby sprawdzi\u0107 przypadek anomalii prowadz\u0105cej do awarii. W dolnym pasku statusu wy\u015bwietlany jest og\u00f3lny procent anomalii danych w danym momencie, kt\u00f3ry okre\u015blany jest przy pomocy autoenkodera. Dla prognozowanych metryk wy\u015bwietlany jest tak\u017ce osobny procent, kt\u00f3ry oblicza RNN LSTM.<\/p>\n

      <\/p>\n

      Przyk\u0142ad wykrywania anomalii w wska\u017anikach CPU przy u\u017cyciu sieci neuronowej RNN LSTM (rysunek 9).<\/p>\n

      \n\"Wykrywamy<\/p>\n

      Rysunek 9. Wykrywanie RNN LSTM<\/em><\/p>\n

      W dosy\u0107 prostym przypadku, kt\u00f3ry w zasadzie jest zwyk\u0142ym odchyleniem, jednak prowadz\u0105cym do awarii systemu, uda\u0142o si\u0119 skutecznie obliczy\u0107 z u\u017cyciem RNN LSTM. Wska\u017anik anomalii w tym okresie wynosi 85 \u2013 95%, wszystko, co powy\u017cej 80% (pr\u00f3g okre\u015blony eksperymentalnie), uwa\u017cane jest za anomali\u0119.
      \nPrzyk\u0142ad wykrywania anomalii, gdy system nie m\u00f3g\u0142 si\u0119 uruchomi\u0107 po aktualizacji. T\u0119 sytuacj\u0119 wykrywa autoenkoder (rysunek 10).<\/p>\n

      \n\"Wykrywamy<\/p>\n

      Rysunek 10. Przyk\u0142ad wykrywania przez autoenkodera<\/em><\/p>\n

      Jak wida\u0107 na rysunku, PermGen utkn\u0105\u0142 na jednym poziomie. Autoenkoder uzna\u0142 to za dziwne, poniewa\u017c wcze\u015bniej nie widzia\u0142 nic podobnego. Anomalia utrzymuje si\u0119 na poziomie 100% a\u017c do przywr\u00f3cenia systemu do stanu operacyjnego. Anomalia jest wy\u015bwietlana we wszystkich metrykach. Jak wcze\u015bniej wspomniano, autoenkoder nie potrafi lokalizowa\u0107 anomalii. Operator jest powo\u0142any do pe\u0142nienia tej funkcji w takich sytuacjach.<\/p>\n

      <\/p>\n

      Podsumowanie<\/h2>\n

      <\/p>\n

      PK \u201eWeb-Konsolidacja\u201d jest rozwijany od wielu lat. System jest w do\u015b\u0107 stabilnym stanie, a liczba rejestrowanych incydent\u00f3w jest niewielka. Niemniej jednak uda\u0142o si\u0119 znale\u017a\u0107 anomalie prowadz\u0105ce do awarii na 5 \u2013 10 minut przed jej wyst\u0105pieniem. W niekt\u00f3rych przypadkach wcze\u015bniejsze powiadomienie o awarii mog\u0142oby pom\u00f3c zaoszcz\u0119dzi\u0107 regulaminowy czas przeznaczony na przeprowadzenie \u201eprac naprawczych\u201d.<\/p>\n

      <\/p>\n

      Na podstawie przeprowadzonych eksperyment\u00f3w wci\u0105\u017c jest za wcze\u015bnie na wyci\u0105gni\u0119cie ostatecznych wniosk\u00f3w. Na ten moment wyniki s\u0105 sprzeczne. Z jednej strony wida\u0107, \u017ce algorytmy oparte na sieciach neuronowych potrafi\u0105 znajdowa\u0107 \"u\u017cyteczne\" anomalie. Z drugiej strony pozostaje wysoki procent fa\u0142szywych alarm\u00f3w, a nie wszystkie anomalie, kt\u00f3re wykrywa wykwalifikowany specjalista, udaje si\u0119 zidentyfikowa\u0107 przez sie\u0107 neuronow\u0105. Do wad mo\u017cna tak\u017ce zaliczy\u0107 konieczno\u015b\u0107 uczenia ze wsparciem, aby sie\u0107 mog\u0142a prawid\u0142owo funkcjonowa\u0107.<\/p>\n

      <\/p>\n

      Aby dalej rozwija\u0107 system prognozowania awarii i doprowadzi\u0107 go do zadowalaj\u0105cego stanu, mo\u017cna przewidzie\u0107 kilka \u015bcie\u017cek. To bardziej szczeg\u00f3\u0142owa analiza przypadk\u00f3w z anomaliami, kt\u00f3re prowadz\u0105 do awarii, poprzez uzupe\u0142nienie listy wa\u017cnych metryk, kt\u00f3re maj\u0105 du\u017cy wp\u0142yw na stan systemu oraz eliminacj\u0119 zb\u0119dnych, kt\u00f3re na niego nie wp\u0142ywaj\u0105. Ponadto, je\u015bli b\u0119dziemy pod\u0105\u017ca\u0107 w tym kierunku, mo\u017cemy podj\u0105\u0107 pr\u00f3by specjalizacji algorytm\u00f3w konkretnie pod nasze przypadki z anomaliami, kt\u00f3re prowadz\u0105 do awarii. Jest tak\u017ce inna \u015bcie\u017cka, czyli udoskonalenie architektur sieci neuronowych i dzi\u0119ki temu zwi\u0119kszenie dok\u0142adno\u015bci wykry\u0107 przy jednoczesnym skr\u00f3ceniu czasu uczenia.<\/p>\n

      <\/p>\n

      Wyra\u017cam wdzi\u0119czno\u015b\u0107 kolegom, kt\u00f3rzy pomogli mi w pisaniu i aktualizacji tej artyku\u0142u: Wiktorowi Werbickiemu<\/a><\/noindex> i Siergiejowi Finogenowowi.<\/p>\n

      \u0179r\u00f3d\u0142o: 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\udd47Wykrywamy anomalie i prognozujemy awarie za pomoc\u0105 sieci neuronowych | ProHoster","description":"Przemys\u0142owy rozw\u00f3j.","canonical_url":"https:\/\/prohoster.info\/pl\/blog\/administrirovanie\/ishhem-anomalii-i-predskazyvaem-sboi-s-pomoshhyu-nejrosetej","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"pl_PL","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\/pl\/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\/pl\/wp-json\/wp\/v2\/posts\/53531","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/comments?post=53531"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/posts\/53531\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/media?parent=53531"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/categories?post=53531"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/tags?post=53531"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}