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

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

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

Въведение

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

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

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

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

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

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

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

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

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

Преди всичко, трябва да се каже, че идеята за прогнозиране на откази беше вдъхновена от статията „Машинно обучение в IT мониторинга“. За проверка на ефективността на подхода с автоматичното откриване на аномалии беше избрана програмната система „Web-Консолидация“, която е един от проектите на НПО „Криста“. За нея преди това е извършван ръчен мониторинг на получените метрики. Тъй като системата е доста сложна, за нея се записват голямо количество метрики: показателите на JVM (натоварване на сборщика на боклук), показателите на ОС, под която се изпълнява кодът (виртуална памет, % натоварване на CPU), показателите на мрежата (натоварване на мрежата), самия сървър (натоварване на CPU, памет), метрики на 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-свързване от базата данни, в която се съхраняват в graphite.
По-долу е представен интерфейс на системата за мониторинг, разработена в резултат на проекта (фигура 8).

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

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

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

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

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

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

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

Заключение

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

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

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

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

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