Przemysłowy rozwój systemów oprogramowania wymaga dużej uwagi do odporności końcowego produktu oraz szybkiej reakcji na awarie i błędy, jeśli już się zdarzą. Monitorowanie oczywiście pomaga reagować na awarie i błędy skuteczniej i szybciej, ale to nie wystarcza. Po pierwsze, bardzo trudno śledzić dużą liczbę serwerów – potrzebna jest duża liczba osób. Po drugie, trzeba dobrze rozumieć, jak działa aplikacja, aby przewidzieć jej stan. W związku z tym potrzebne są dziesiątki osób, które dobrze rozumieją systemy, które rozwijamy, ich wskaźniki i cechy. Załóżmy, że nawet gdyby znaleźć wystarczającą liczbę osób chętnych do zajmowania się tym, potrzeba jeszcze sporo czasu, aby je przeszkolić.
Co zrobić? Tu z pomocą przychodzi sztuczna inteligencja. W artykule mowa będzie o (predictive maintenance). To podejście zyskuje na popularności. Napisano dużą ilość artykułów, w tym na Habrze. Duże firmy powszechnie stosują to podejście do utrzymania sprawności swoich serwerów. Po zapoznaniu się z dużą ilością artykułów postanowiliśmy spróbować zastosować tę metodę. Co z tego wynikło?
Wprowadzenie
Opracowany system oprogramowania prędzej czy później trafia do eksploatacji. Użytkownikowi zależy na tym, aby system działał bezawaryjnie. Jeśli jednak dojdzie do sytuacji awaryjnej, powinna ona być eliminowana z minimalnymi opóźnieniami.
Aby uprościć wsparcie techniczne systemu oprogramowania, zwłaszcza gdy serwerów jest dużo, zazwyczaj korzysta się z programów monitorujących, które zbierają metryki z działającego systemu oprogramowania, umożliwiają diagnozowanie jego stanu i pomagają określić, co spowodowało awarię. Proces ten nazywa się monitorowaniem systemu oprogramowania.
Rysunek 1. Interfejs do monitorowania grafana
Metryki to różne wskaźniki systemu programowego, środowiska jego uruchomienia lub fizycznej maszyny obliczeniowej, pod którą działa system z oznaczeniem czasu, w którym metryki zostały zebrane. W analizie statycznej dane metryk nazywane są szeregami czasowymi. Aby monitorować stan systemu programowego, metryki przedstawiane są w formie wykresów: na osi X znajduje się czas, a na osi Y wartości (rysunek 1). Z działającego systemu programowego można zbierać kilka tysięcy metryk (z każdego węzła). Tworzą one przestrzeń metryk (wielowymiarowych szeregów czasowych).
Ponieważ w złożonych systemach programowych zbiera się dużą ilość metryk, ręczne monitorowanie staje się trudnym zadaniem. Aby zmniejszyć objętość danych analizowanych przez administratora, narzędzia monitorujące zawierają środki do automatycznego wykrywania potencjalnych problemów. Na przykład można skonfigurować wyzwalacz, który uruchamia się w przypadku spadku dostępnego miejsca na dysku poniżej określonego progu. Można również automatycznie diagnozować zatrzymanie serwera lub krytyczne spowolnienie prędkości usług. W praktyce narzędzia monitorujące dobrze radzą sobie z wykrywaniem już występujących awarii lub identyfikowaniem prostych objawów przyszłych awarii, ale generalnie przewidywanie możliwej awarii pozostaje dla nich twardym orzechem do zgryzienia. Przewidywanie poprzez ręczną analizę metryk wymaga zaangażowania wykwalifikowanych specjalistów. Jest to mało produktywne. Większość potencjalnych awarii może pozostawać niezauważona.
W ostatnim czasie wśród dużych firm IT zajmujących się tworzeniem oprogramowania zyskuje na popularności tak zwane predykcyjne utrzymanie systemów programowych. Istota tego podejścia polega na wczesnym wykrywaniu usterek prowadzących do degradacji systemu, zanim dojdzie do jego awarii, z użyciem sztucznej inteligencji. Podejście to nie wyklucza całkowicie ręcznego monitorowania systemu. Jest ono pomocnicze dla procesu monitorowania jako całości.
Podstawowym narzędziem do realizacji predykcyjnego utrzymania jest zadanie znajdowania anomalii w szeregach czasowych, ponieważ przy wystąpieniu anomalii w danych istnieje wysokie prawdopodobieństwo, że wkrótce wystąpi awaria lub błąd. Anomalia to pewne odchylenie w wynikach systemu programowego, takie jak wykrycie degradacji prędkości realizacji zapytania tego samego rodzaju lub zmniejszenie średniej liczby obsługiwanych zapytań przy stałym poziomie sesji klientów.
Zadanie wykrywania anomalii w systemach programowych ma swoją specyfikę. Zasadniczo dla każdego systemu programowego konieczne jest opracowanie lub poprawienie istniejących metod, ponieważ wykrywanie anomalii bardzo zależy od danych, w których jest realizowane, a dane systemów programowych bardzo różnią się w zależności od narzędzi implementacji systemu, aż po to, na jakiej maszynie obliczeniowej jest uruchomiony.
Metody wykrywania anomalii przy prognozowaniu awarii systemów programowych
Przede wszystkim warto powiedzieć, że pomysł prognozowania awarii został zainspirowany artykułem . Do weryfikacji skuteczności podejścia do automatycznego wykrywania anomalii wybrano system programowy „Web-Konsolidacja”, który jest jednym z projektów firmy NPO „Krista”. Dla tego systemu wcześniej przeprowadzano ręczne monitorowanie na podstawie uzyskiwanych metryk. Ponieważ system jest dość skomplikowany, zbiera się dla niego dużą ilość metryk: wskaźniki JVM (obciążenie zbieracza śmieci), wskaźniki systemu operacyjnego, na którym wykonuje się kod (pamięć wirtualna, % obciążenia CPU systemu operacyjnego), wskaźniki sieci (obciążenie sieci), samego serwera (obciążenie CPU, pamięci), metryki wildfly oraz własne metryki aplikacji dla wszystkich krytycznych podsystemów.
Wszystkie metryki są zbierane z systemu przy użyciu graphite. Początkowo używano bazy whisper jako standardowego rozwiązania dla grafany, ale wraz ze wzrostem bazy klientów graphite przestał sobie radzić, wyczerpując przepustowość systemu dyskowego centrum danych. Po tym podjęto decyzję o poszukiwaniu bardziej efektywnego rozwiązania. Wybór padł na , co pozwoliło znacząco zmniejszyć obciążenie systemu dyskowego i pięciokrotnie-sześciokrotnie zmniejszyć zajmowaną przestrzeń dyskową. Poniżej przedstawiono schemat mechanizmu zbierania metryk z użyciem graphite+clickhouse (rysunek 2).
Rysunek 2. Schemat zbierania metryk
Schemat został zaczerpnięty z dokumentacji wewnętrznej. Pokazuje wymianę danych między grafana (interfejs użytkownika do monitorowania, którego używamy) a graphite. Zbieranie metryk z aplikacji odbywa się za pomocą osobnego oprogramowania – . To oprogramowanie również zapisuje je w graphite.
System „Web-Konsolidacja” ma szereg cech, które stwarzają problemy w prognozowaniu awarii:
- często dochodzi do zmiany trendu. Dla tego systemu oprogramowania wydawane są różne wersje. Każda z nich wprowadza zmiany w części programowej systemu. W ten sposób deweloperzy mają bezpośredni wpływ na metryki tego systemu i mogą spowodować zmianę trendu;
- cecha realizacji oraz cele korzystania z tego systemu przez klientów często wywołują anomalia bez wcześniejszej degradacji;
- odsetek anomalii w stosunku do całego zbioru danych jest mały (< 5%);
- mogą występować przerwy w otrzymywaniu wskaźników z systemu. W niektórych krótkich interwałach czasowych system monitorowania nie jest w stanie uzyskać metryk. Na przykład, jeśli serwer jest przeciążony. Dla szkolenia sieci neuronowej jest to krytyczne. Pojawia się potrzeba syntetycznego wypełniania luk;
- Przypadki z anomaliami często są aktualne tylko dla konkretnego dnia/miesiąca/czasu (sezonowość). System ma jasno określony regulamin korzystania przez swoich użytkowników. Odpowiednio, metryki są aktualne tylko dla konkretnego czasu. System może być używany nieustannie, ale tylko w wybrane miesiące: selektywnie w zależności od roku. Pojawiają się sytuacje, kiedy to samo zachowanie metryk w jednym przypadku może prowadzić do awarii systemu oprogramowania, a w innym nie.
Na początku analizowane były metody wykrywania anomalii w danych monitorowania systemów oprogramowania. W artykułach na ten temat, przy małych procentach anomalii w stosunku do reszty zbioru danych, najczęściej proponuje się użycie sieci neuronowych.
Główna logika wyszukiwania anomalii z użyciem danych sieci neuronowych jest przedstawiona na rysunku 3:
Rysunek 3. Wyszukiwanie anomalii z użyciem sieci neuronowej
W wyniku prognozy lub przywracania okna bieżącego strumienia metryk obliczane jest odchylenie od uzyskanych z działającego systemu programowego. W przypadku dużej różnicy między uzyskanymi metrykami z systemu programowego a siecią neuronową można wnioskować o nieprawidłowości bieżącego segmentu danych. Pojawia się szereg problemów związanych z wykorzystaniem sieci neuronowych:
- Aby zapewnić prawidłowe działanie w trybie strumieniowym, dane do uczenia modeli sieci neuronowych muszą obejmować tylko „normalne” dane;
- Należy mieć aktualny model, aby prawidłowo wykrywać. Zmiana trendu i sezonowości w metrykach może wywołać dużą liczbę fałszywych alarmów modelu. Aby go zaktualizować, konieczne jest dokładne określenie momentu, w którym model jest przestarzały. Jeżeli zaktualizujemy model za późno lub za wcześnie, prawdopodobnie nastąpi wiele fałszywych alarmów.
Nie można także zapominać o poszukiwaniu i zapobieganiu częstemu występowaniu fałszywych alarmów. Zakłada się, że będą one najczęściej występować w sytuacjach awaryjnych. Mogą one być jednak także skutkiem błędów w sieci neuronowej z powodu niedostatecznego jej uczenia. Należy zminimalizować liczbę fałszywych alarmów modelu. W przeciwnym razie fałszywe prognozy będą pochłaniać dużo czasu administratora, który powinien być wykorzystany do kontroli systemu. Prędzej czy później doprowadzi to do tego, że administrator po prostu przestanie reagować na „paranoidalny” system monitorowania.
Rekurencyjna sieć neuronowa
Aby wykrywać nieprawidłowości w szeregach czasowych, można zastosować z pamięcią LSTM. Problem polega tylko na tym, że może być stosowana tylko do prognozowanych szeregów czasowych. W naszym przypadku nie wszystkie metryki są prognozowane. Próba zastosowania RNN LSTM dla szeregu czasowego została przedstawiona na rysunku 4.
Rysunek 4. Przykład działania rekurencyjnej sieci neuronowej z komórkami pamięci LSTM
Jak przedstawiono na rysunku 4, RNN LSTM udało się poradzić z wykrywaniem anomalii w tym czasie. Tam, gdzie wynik ma wysokie błędy prognozowania (średni błąd), rzeczywiście miała miejsce anomalia wskaźników. Użycie tylko RNN LSTM będzie zdecydowanie niewystarczające, ponieważ nadaje się do ograniczonej liczby metryk. Można użyć go jako pomocniczej metody wykrywania anomalii.
Autoenkoder do prognozowania awarii
– to w zasadzie sztuczna sieć neuronowa. Warstwa wejściowa – encoder, warstwa wyjściowa – decoder. Wadą wszystkich sieci neuronowych tego typu jest słaba lokalizacja anomalii. Wybrano architekturę synchronicznego autoenkodera.
Rysunek 5. Przykład działania autoenkodera
Autoenkodery są szkolone na normalnych danych i następnie identyfikują coś anormalnego w przekazywanych do modelu danych. To dokładnie to, czego potrzebujemy do tego zadania. Pozostaje tylko wybrać, który z autoenkoderów będzie odpowiedni. Architektonicznie najprostsza forma autoenkodera to prosta, jednokierunkowa sieć neuronowa, która jest bardzo podobna do (multilayer perceptron, MLP), z warstwą wejściową, warstwą wyjściową i jedną lub kilkoma ukrytymi warstwami, które je łączą.
Jednak różnice między autoenkoderami a MLP polegają na tym, że w autoenkoderze warstwa wyjściowa ma tyle samo węzłów co warstwa wejściowa, oraz że zamiast uczyć się przewidywania wartości docelowej Y, danej przez wejście X, autoenkoder uczy się rekonstruować swoje własne X. Dlatego autoenkodery są modelami uczenia się nienadzorowanego.
Zadanie autoenkodera polega na znalezieniu indeksów czasowych r0 … rn odpowiadających anormalnym elementom w wektorze wejściowym X. Efekt ten osiąga się poprzez poszukiwanie błędu kwadratowego.
Rysunek 6. Synchroniczny autoenkoder
Dla autoenkodera wybrano . Jej zalety to możliwość użycia trybu przetwarzania strumieniowego oraz stosunkowo mniejsza liczba parametrów sieci neuronowej w porównaniu z innymi architekturami.
Mechanizm minimalizacji fałszywych alarmów
Ze względu na występowanie różnych sytuacji niestandardowych, a także możliwość niewystarczającego szkolenia sieci neuronowej, podjęto decyzję o konieczności opracowania mechanizmu minimalizacji fałszywych alarmów dla opracowywanego modelu wykrywania anomalii. Mechanizm ten oparty jest na bazie szablonów, którą klasyfikuje administrator.
(Algorytm DTW, z ang. dynamic time warping) umożliwia znalezienie optymalnego dopasowania między sekwencjami czasowymi. Po raz pierwszy zastosowano go w rozpoznawaniu mowy: użyto go do określenia, jak dwa sygnały mowy przedstawiają tę samą pierwotnie wypowiedzianą frazę. W późniejszym czasie znaleziono dla niego zastosowanie również w innych dziedzinach.
Podstawową zasadą minimalizacji fałszywych alarmów jest zbieranie bazy wzorców za pomocą operatora, który klasyfikuje podejrzane przypadki zidentyfikowane przez sieci neuronowe. Następnie następuje porównanie sklasyfikowanego wzorca z przypadkiem wykrytym przez system, co pozwala na ustalenie, czy przypadek jest fałszywy, czy prowadzi do awarii. Algorytm DTW jest używany właśnie do porównania dwóch szeregów czasowych. Głównym narzędziem minimalizacji jest jednak klasyfikacja. Zakłada się, że po zebraniu dużej liczby wzorców system zacznie rzadziej pytać operatora z powodu podobieństwa większości przypadków i pojawiania się podobnych.
W wyniku opisanych powyżej metod sieci neuronowych stworzono eksperymentalny program do prognozowania awarii systemu „Web-Konsolidacja”. Celem tego programu było, wykorzystując istniejący archiwum danych monitorujących i informacje o już zaistniałych awariach, ocenić skuteczność tego podejścia dla naszych systemów programowych. Schemat działania programu przedstawiono poniżej, na rysunku 7.
Rysunek 7. Schemat prognozowania awarii na podstawie analizy przestrzeni metryk
Na schemacie można wyróżnić dwa podstawowe bloki: wyszukiwanie anomálních segmentów czasowych w strumieniu danych monitorujących (metrykach) oraz mechanizm minimalizacji fałszywych alarmów. Uwaga: w celach eksperymentalnych dane uzyskuje się przez połączenie JDBC z bazą danych, w której są one przechowywane przez graphite.
Poniżej przedstawiono interfejs uzyskany w wyniku opracowania systemu monitorowania (rysunek 8).
Rysunek 8. Interfejs eksperymentalnego systemu monitorowania
Na interfejsie wyświetlany jest procent anomalii w otrzymywanych metrykach. W naszym przypadku modelowanie jest symulowane. Dysponujemy już wszystkimi danymi z kilku tygodni i stopniowo je wczytujemy, aby sprawdzić przypadek anomalii prowadzącej do awarii. W dolnym pasku statusu wyświetlany jest ogólny procent anomalii danych w danym momencie, który określany jest przy pomocy autoenkodera. Dla prognozowanych metryk wyświetlany jest także osobny procent, który oblicza RNN LSTM.
Przykład wykrywania anomalii w wskaźnikach CPU przy użyciu sieci neuronowej RNN LSTM (rysunek 9).
Rysunek 9. Wykrywanie RNN LSTM
W dosyć prostym przypadku, który w zasadzie jest zwykłym odchyleniem, jednak prowadzącym do awarii systemu, udało się skutecznie obliczyć z użyciem RNN LSTM. Wskaźnik anomalii w tym okresie wynosi 85 – 95%, wszystko, co powyżej 80% (próg określony eksperymentalnie), uważane jest za anomalię.
Przykład wykrywania anomalii, gdy system nie mógł się uruchomić po aktualizacji. Tę sytuację wykrywa autoenkoder (rysunek 10).
Rysunek 10. Przykład wykrywania przez autoenkodera
Jak widać na rysunku, PermGen utknął na jednym poziomie. Autoenkoder uznał to za dziwne, ponieważ wcześniej nie widział nic podobnego. Anomalia utrzymuje się na poziomie 100% aż do przywrócenia systemu do stanu operacyjnego. Anomalia jest wyświetlana we wszystkich metrykach. Jak wcześniej wspomniano, autoenkoder nie potrafi lokalizować anomalii. Operator jest powołany do pełnienia tej funkcji w takich sytuacjach.
Podsumowanie
PK „Web-Konsolidacja” jest rozwijany od wielu lat. System jest w dość stabilnym stanie, a liczba rejestrowanych incydentów jest niewielka. Niemniej jednak udało się znaleźć anomalie prowadzące do awarii na 5 – 10 minut przed jej wystąpieniem. W niektórych przypadkach wcześniejsze powiadomienie o awarii mogłoby pomóc zaoszczędzić regulaminowy czas przeznaczony na przeprowadzenie „prac naprawczych”.
Na podstawie przeprowadzonych eksperymentów wciąż jest za wcześnie na wyciągnięcie ostatecznych wniosków. Na ten moment wyniki są sprzeczne. Z jednej strony widać, że algorytmy oparte na sieciach neuronowych potrafią znajdować "użyteczne" anomalie. Z drugiej strony pozostaje wysoki procent fałszywych alarmów, a nie wszystkie anomalie, które wykrywa wykwalifikowany specjalista, udaje się zidentyfikować przez sieć neuronową. Do wad można także zaliczyć konieczność uczenia ze wsparciem, aby sieć mogła prawidłowo funkcjonować.
Aby dalej rozwijać system prognozowania awarii i doprowadzić go do zadowalającego stanu, można przewidzieć kilka ścieżek. To bardziej szczegółowa analiza przypadków z anomaliami, które prowadzą do awarii, poprzez uzupełnienie listy ważnych metryk, które mają duży wpływ na stan systemu oraz eliminację zbędnych, które na niego nie wpływają. Ponadto, jeśli będziemy podążać w tym kierunku, możemy podjąć próby specjalizacji algorytmów konkretnie pod nasze przypadki z anomaliami, które prowadzą do awarii. Jest także inna ścieżka, czyli udoskonalenie architektur sieci neuronowych i dzięki temu zwiększenie dokładności wykryć przy jednoczesnym skróceniu czasu uczenia.
Wyrażam wdzięczność kolegom, którzy pomogli mi w pisaniu i aktualizacji tej artykułu: i Siergiejowi Finogenowowi.
Źródło: habr.com
