Ние търсим аномалии и прогнозираме повреди, използвайки невронни мрежи

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

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

въведение

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

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

Фигура 1. Интерфейс за наблюдение на Grafana

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

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

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

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

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

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

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

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

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

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

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

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

Фигура 3. Търсене на аномалии с помощта на невронна мрежа

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

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

Повтаряща се невронна мрежа

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

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

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

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

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

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

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

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

Фигура 6. Синхронен автоенкодер

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

Механизъм за минимизиране на фалшиви положителни резултати

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

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

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

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

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

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

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

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

Пример за откриване на аномалия чрез индикатори на процесора с помощта на невронната мрежа RNN LSTM (Фигура 9).

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

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

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

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

Заключение

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

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

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

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

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