Търсим аномалии и предсказваме повреди с помощта на невронни мрежи

Продуктова разработка на софтуерни системи изисква голямо внимание към устойчивостта на крайния продукт, а също и бърза реакция при сривове и проблеми, ако те все пак се появят. Мониторингът, разбира се, помага за по-ефективна и бърза реакция при сривове и проблеми, но това не е достатъчно. Първо, много трудно е да се следят голям брой сървъри – необходима е голяма бройка хора. Второ, трябва добре да се разбира как е устроено приложението, за да се прогнозира неговото състояние. Следователно, нужни са много хора, които добре разбират разработваните от нас системи, техните показатели и особености. Да предположим, даже ако намерим достатъчно хора, желаещи да се занимават с това, ще отнеме още доста време, за да ги обучим.

Какво да правим? Тук на помощ идва изкуственият интелект. Статията ще бъде за предиктивното обслужване (predictive maintenance). Този подход активно набира популярност. Написани са много статии, включително и в Хабра. Големи компании активно използват този подход за поддръжка на работоспособността на своите сървъри. След като проучихме много статии, решихме да опитаме да приложим този подход. Какво излезе от това?

Въведение

Разработеният софтуерен продукт рано или късно влиза в експлоатация. Важно е за потребителя, че системата работи безпроблемно. Ако все пак се случи извънредна ситуация, тя трябва да се отстрани с минимални забавяния.

За улесняване на техническата поддръжка на софтуерната система, особено при наличие на много сървъри, обикновено се използват програми за мониторинг, които взимат метрики от работещата софтуерна система, дават възможност за диагностициране на нейното състояние и помагат да се определи какво точно е предизвикало срив. Този процес се нарича мониторинг на софтуерната система.

Фигура 1. Интерфейс за мониторинг grafana

Метриките са различни показатели на софтуерната система, средата на нейната изпълнение или физическата изчислителна машина, под която е стартирана системата с времеви печат, този момент, в който метриките са били получени. В статичния анализ данните от метриките се наричат времеви редици. За наблюдение на състоянието на софтуерната система, метриките се представят под формата на графики: по оста X – времето, а по оста Y – стойностите (рисунок 1). От работещата софтуерна система могат да бъдат извлечени хиляди метрики (от всеки възел). Те образуват пространство от метрики (многомерни времеви редици).

Тъй като при сложните софтуерни системи се извлича голямо количество метрики, ръчният мониторинг става сложна задача. За да се намали обемът на данните, анализирани от администратора, средствата за мониторинг съдържат инструменти за автоматично откриване на потенциални проблеми. Например, може да се настрои тригер, който да сработи при намаляване на свободното дисково пространство под зададен праг. Също така, може автоматично да се диагностицира спиране на сървъра или критично забавяне на скоростта на обслужване. На практика средствата за мониторинг успешно откриват вече настъпили откази или идентифицират прости симптоми на бъдещи откази, но като цяло предсказването на потенциален провал остава за тях трудна задача. Предсказването чрез ръчен анализ на метриките изисква привличане на квалифицирани специалисти. То е неефективно. Повечето потенциални откази могат да останат незабелязани.

В последно време сред крупните IT компании, които разработват софтуер, все по-голяма популярност придобива така нареченото предиктивно обслужване на софтуерните системи. Същността на този подход е намирането на неизправности, водещи до деградация на системата в ранните етапи, преди нейния отказ, с използването на изкуствен интелект. Този подход не изключва напълно ръчния мониторинг на системата. Той е допълнителен към процеса на мониторинг като цяло.

Основният инструмент за реализиране на предиктивно обслужване е задачата за откриване на аномалии във времевите редици, тъй като при възникване на аномалия в данните вероятността е голяма, че след малко време може да възникне грешка или отказ. Аномалия е отклонение в показателите на програмната система, като например откритие на влошаване на времето за изпълнение на зададена заявка или намаляване на средния брой обслужвани запитвания при постоянен брой клиентски сесии.

Задачата за идентификация на аномалии в програмните системи има свои спецификации. По принцип, за всяка програмна система е необходимо разработването или подобряването на съществуващи методи, тъй като идентификацията на аномалии е много зависима от данните, в които се извършва, а данните на програмните системи се различават в зависимост от инструментите за реализация, до такава степен, че зависят дори от компютърната машина, на която те работят.

Методи за откриване на аномалии при прогнозиране на откази на програмните системи

Преди всичко, трябва да се каже, че идеята за прогнозиране на откази беше вдъхновена от статията «Машинно обучение в IT мониторинга». За проверка на ефективността на подхода с автоматично откриване на аномалии беше избрана програмната система «Web-Консолидация», която е един от проектите на компанията НПО «Криста». За нея преди това се извършваше ръчно наблюдение на получените метрики. Тъй като системата е сравнително сложна, за нея се събират множество метрики: показателите на JVM (натоварване на събирача на боклук), показателите на операционната система, под която се изпълнява кодът (виртуална памет, % натоварване на ЦПУ), показателите на мрежата (натоварване на мрежата), самият сървър (натоварване на ЦПУ, памет), метрики на wildfly и собствени метрики на приложението за всички критични подсистеми.

Всички метрики се извличат от системата с помощта на graphite. Първоначално се използваше whisper база като стандартно решение за grafana, но с нарастващата клиентска база graphite спря да се справя, изчерпвайки пропускната способност на дисковата подсистема на централата. След това беше взето решение за търсене на по-ефективно решение. Изборът беше направен в полза на graphite+clickhouse, което позволи значително да се намали натоварването на дисковата подсистема и да се намали обемът заемащото дисково пространство пет-шест пъти. По-долу е представена схемата на механизма за събиране на метрики с използването на graphite+clickhouse (фигура 2).

Фигура 2. Схема за извличане на метрики

Схемата е взета от вътрешната документация. Тя показва обмена на данни между grafana (потребителски интерфейс за мониторинг, който използваме) и graphite. Събирането на метрики от приложението се извършва от отделен софтуер – jmxtrans. Той също така ги съхранява в graphite.
Системата "Web-Консолидиране" има редица особености, които създават проблеми при прогнозиране на откази:

1. често се наблюдава смяна на тренда. За тази софтуерна система излизат различни версии. Всяка от тях носи промени в софтуерната част на системата. Съответно, по този начин разработчиците пряко влияят на метриките на системата и могат да предизвикат смяна на тренда;
2. особеностите на реализирането, както и целите за използване от потребителите на системата, често предизвикват аномалии без предшествуваща деградация;
3. процентът на аномалии спрямо целия набор от данни е малък (< 5%);
4. могат да възникват пропуски в получаването на показателите от системата. В някои кратки промеждутъци от време системата за мониторинг не успява да получи метрики. Например, ако сървърът е претоварен. За обучението на невронна мрежа това е критично. Възниква необходимостта от синтетично запълване на празнините;
5. Случаите с аномалии често са актуални само за конкретен брой/месец/време (сезонност). Тази система има ясни правила за използване от потребителите ѝ. Съответно, метриките са актуални само за конкретно време. Системата може да не се използва постоянно, а само в определени месеци: избирателно в зависимост от годината. Възникват ситуации, когато едно и също поведение на метриките в един случай може да доведе до отказ на софтуерната система, а в друг - не.
   За начало бяха анализирани методите за откриване на аномалии в данните за мониторинг на софтуерни системи. В статии по тази тема, при малки проценти аномалии относно останалия набор от данни, често се предлага използването на невронни мрежи.

Основната логика за откриване на аномалии с помощта на данни от невронните мрежи е представена на рисунка 3:

Рисунка 3. Откриване на аномалии с помощта на невронна мрежа

В резултат на прогнозата или възстановяването на прозореца на текущия поток метрики се изчислява отклонението от полученото с работещата софтуерна система. В случай на голяма разлика между получените метрики от софтуерната система и невронната мрежа, може да се направи извод за аномалността на текущия набор от данни. Появява се следният набор от проблеми за използването на невронни мрежи:

1. за коректната работа в потоков режим данните за обучение на моделите на невронни мрежи трябва да включват само "нормални" данни;
2. необходимо е да имате актуален модел за коректно откриване. Смяната на тренда и сезонността в метриките може да предизвика голям брой фалшиви срабатывания на модела. За нейното обновяване трябва ясно да се определи времето, когато моделът е остарял. Ако обновите модела по-късно или по-рано, най-вероятно ще последва голямо количество фалшиви срабатывания.
   Също така не бива да забравяте за търсенето и предотвратяването на честото възникване на фалшиви срабатывания. Предполага се, че те ще възникват най-често в нестандартни ситуации. Въпреки това, те могат да бъдат и следствие от грешка на невронната мрежа поради недостатъчност на нейното обучение. Необходимо е да се минимизира броят на фалшивите срабатывания на модела. В противен случай фалшивите прогнози ще изразходват много време на администратора, предназначено за проверка на системата. Рано или късно ще приключи с това, че администраторът просто ще престане да реагира на "параноидалната" система за мониторинг.

Рекурентна невронна мрежа

За откриване на аномалии в времеви редици може да се приложи рекурентна невронна мрежа с LSTM памет. Проблемът е, че тя може да се прилага само за прогнозируеми времеви редици. В нашия случай не всички метрики са прогнозируеми. Опитът да се приложи RNN LSTM за времеви ред е представен на фигура 4.

Фигура 4. Пример за работа на рекурентна невронна мрежа с LSTM паметни клетки

Както е видно от рисунка 4, RNN LSTM успя да се справи с откритията на аномалии в този времеви интервал. Там, където резултатът има висока прогнозна грешка (средна грешка), наистина е настъпила аномалия в показателите. Използването на само една RNN LSTM очевидно не е достатъчно, тъй като тя се прилага за малък брой метрики. Може да се използва като помощен метод за търсене на аномалии.

Автокодировчик за прогнозиране на повреди

Автокодировчик – по същество изкуствена невронна мрежа. Входният слой – encoder, изходният слой – decoder. Недостатък на всички невронни мрежи от този вид е, че те слабо локализират аномалиите. Беше избрана архитектура на синхронен автокодировчик.

Рисунок 5. Пример за работа на автокодировчика

Автокодировците се обучават на нормални данни и след това откриват нещо аномално в подаваните към модела данни. Точно това, което е необходимо за тази задача. Остава само да се избере кой от автокодировците е подходящ за тази задача. Архитектурно най-простата форма на автокодировчик представлява права, невъзвратима невронна мрежа, която много прилича на многослоен перцептрон (multilayer perceptron, MLP), с входен слой, изходен слой и един или повече скрити слоеве, свързващи ги.
Обаче разликите между автокодировците и MLP се състоят в това, че в автокодировчика изходният слой има същия брой възли, каквито има входният, и че вместо да се обучава в предсказването на целевата стойност Y, зададена от входа X, автокодировчикът се обучава да реконструира собствените си X. Следователно автокодировците са неконтролирани обучаващи модели.

Задачата на автокодировчика е да намери времевите индекси r0 … rn, които съответстват на аномалните елементи във входния вектор X. Този ефект се постига чрез търсене на квадратична грешка.

Рисунок 6. Синхронен автокодировчик

За автокодировчика беше избрана синхронна архитектура. Нейните предимства: възможност за използване на потоков режим на обработка и сравнително по-малко количество параметри на невронната мрежа в сравнение с други архитектури.

Механизъм за минимизиране на фалшиви срабатывания

Поради различни извънредни ситуации, както и заради възможностите за недостатъчно обучение на невронната мрежа, беше взето решение за необходимостта от разработването на механизъм за минимизиране на фалшивите срабатывания за разработената модел за откриване на аномалии. Този механизъм е основан на база от шаблони, която класифицира администратор.

Алгоритъм за динамична трансформация на времевата ос (DTW-алгоритъм, от английски dynamic time warping) позволява да се намери оптимално съответствие между времевите последователности. Впервые е приложен в разпознаването на реч: използва се за определяне на това как два говорни сигнала представят една и съща произнесена фраза. Впоследствие му бяха намерени приложения и в други области.

Основният принцип на минимизиране на фалшивите срабатывания е събирането на база еталони с помощта на оператор, който класифицира съмнителни случаи, открити с помощта на невронни мрежи. След това става сравнение на класифицирания еталон с случая, който е открит от системата, и се прави заключение за принадлежността на случая към фалшиво или водещо до срив. Именно за сравнение на два времеви реда се използва алгоритъмът DTW. Основният инструмент за минимизиране обаче остава класификацията. Предполага се, че след събиране на голямо количество еталонни случаи системата ще започне да пита оператора по-малко поради сходството на повечето случаи и появата на подобни.

В крайна сметка на базата на гореописаните методи на невронни мрежи беше изградена експериментална програма за прогнозиране на сривовете на системата „Web-Консолидиране“. Целта на тази програма беше да оцени компетентността на този подход за нашите софтуерни системи, използвайки съществуващ архив от данни за мониторинг и информация за вече настъпили сривове. Схемата на работа на програмата е представена по-долу, на рисунка 7.

Рисунка 7. Схема за прогнозиране на сривове на базата на анализа на пространството на метрики

На схемата могат да се откроят два основни блока: търсене на аномални времеви отсечки в потока от данни за мониторинг (метрики) и механизъм за минимизиране на фалшивите срабатывания. Забележка: за експериментални цели данните се получават чрез JDBC-свързване от база данни, в която те се съхраняват графит.
Представен е интерфейс на създадената в резултат на разработката система за мониторинг (фигура 8).

Фигура 8. Интерфейс на експерименталната система за мониторинг

На интерфейса се показва процентът на аномалия по получените метрики. В нашия случай получаването се моделира. Вече имаме всички данни за няколко седмици и ги зареждаме постепенно, за да проверим случая с аномалия, водеща до отказ. В долния статус бар се показва общият процент на аномалия на данните в момента, който се определя с помощта на автокодировчика. Също така за прогнозируемите метрики се показва отделен процент, който изчислява RNN LSTM.

Пример за откриване на аномалия по показателите на ЦПУ с помощта на невронна мрежа RNN LSTM (фигура 9).

Фигура 9. Откриване с RNN LSTM

Доста прост случай, по същество обикновен изключение, но водещ до отказ на системата, успешно е изчислен с помощта на RNN LSTM. Показателят за аномалия в този период от време е 85 – 95%, всичко над 80% (праг, определен експериментално) се счита за аномалия.
Пример за откриване на аномалия, когато системата не успя да се зареди след актуализация. Тази ситуация се детектира от автокодировчика (фигура 10).

Фигура 10. Пример за откриване от автокодировчика

Както се вижда от фигурата, PermGen е заседнал на едно ниво. Автокодировчикът е оценил това като странно, защото преди не е виждал нищо подобно. Тук аномалията остава 100% до възстановяване на системата в работоспособно състояние. Аномалията се показва по всички метрики. Както бе посочено по-рано, автокодировчикът не може да локализира аномалии. Операторът е призван да извършва тази функция в тези ситуации.

Заключение

ПК "Web-Консолидация" се разработва не от една година. Системата е в достатъчно стабилно състояние и броят на регистрираните инциденти е малък. Въпреки това, успяхме да намерим аномалии, водещи до отказ само 5 – 10 минути преди възникването на отказа. В някои случаи предварителното предупреждение за отказ би помогнало да спестим регламентираното време, което е отделено за извършване на "ремонтни" работи.

Според проведените експерименти, е рано да се правят окончателни изводи. Към момента резултатите са противоречиви. От една страна, е видно, че алгоритмите на база невронни мрежи могат да откриват "полезни" аномалии. От друга страна, остава висок процент на фалшиви срабатывания, и не всички аномалии, идентифицирани от квалифициран специалист, могат да бъдат открити от невросетите. Недостатък е и това, че в момента невромрежата изисква обучение с учител за нормална работа.

За по-нататъшното развитие на системата за прогнозиране на отказы и довеждането й до удовлетворително състояние могат да бъдат предвидени няколко пътища. Това е по-подробен анализ на случаите с аномалии, които водят до отказ, чрез добавяне на списък с важни метрики, които много влияят на състоянието на системата, и отхвърляне на ненужните, които не влияят на нея. Също така, ако се напредва в тази посока, могат да се направят опити за специализация на алгоритмите конкретно за нашите случаи с аномалии, които водят до откази. Има и друг път. Това е усъвършенстване на архитектурите на невронните мрежи и повишаване на точността на откритията чрез намаляване на времето за обучение.

Изразявам благодарност на колегите, които ми помогнаха с написването и поддържането на актуалността на тази статия: Виктор Вербицки и Сергей Финогенов.

Източник: habr.com