Промислова розробка програмних систем вимагає великої уваги до стійкості до відмови кінцевого продукту, а також швидкого реагування на відмови і збої, якщо вони все-таки трапляються. Моніторинг, звичайно ж, допомагає реагувати на відмови та збої ефективніше та швидше, але недостатньо. По-перше, дуже складно встежити за великою кількістю серверів – потрібна велика кількість людей. По-друге, потрібно добре розуміти, як влаштовано програму, щоб прогнозувати її стан. Отже, потрібно багато людей, які добре розуміють системи, що розробляються нами, їх показники та особливості. Припустимо, навіть якщо знайти достатню кількість людей, які бажають займатися цим, потрібно ще багато часу, щоб їх навчити.
Що ж робити? Тут нам на допомогу поспішає штучний інтелект. Мова у статті піде про (Predictive maintenance). Цей підхід активно набирає популярності. Написано велику кількість статей, у тому числі і на Хабрі. Великі компанії використовують такий підхід для підтримки працездатності своїх серверів. Вивчивши велику кількість статей, ми вирішили спробувати застосувати цей підхід. Що з того вийшло?
Запровадження
Розроблена програмна система рано чи пізно надходить в експлуатацію. Користувачеві важливо, щоб система працювала без збоїв. Якщо позаштатна ситуація все ж таки відбудеться, вона повинна усуватися з мінімальними затримками.
Для спрощення технічної підтримки програмної системи, особливо якщо серверів багато, зазвичай використовуються програми моніторингу, які знімають метрики з працюючої програмної системи, дають можливість діагностувати її стан та допомагають визначити, що саме викликало збій. Цей процес називається моніторингом програмної системи.
Рисунок 1. Інтерфейс для моніторингу grafana
Метрики - це різні показники програмної системи, середовища її виконання або фізичної обчислювальної машини, під якою запущена система з міткою часу, моменту, коли метрики були отримані. У статичному аналізі дані метрик називаються часовими рядами. Для спостереження станом програмної системи метрики відображають як графіків: по осі X – час, а, по осі Y – значення (рисунок 1). З працюючої програмної системи може зніматися кілька тисяч метриків (з кожного вузла). Вони утворюють простір метрик (багатомірних часових рядів).
Так як у складних програмних систем знімається велика кількість метриків, ручний моніторинг стає складним завданням. Для скорочення обсягу аналізованих адміністратором даних засоби моніторингу містять інструменти автоматичного виявлення можливих проблем. Наприклад, можна налаштувати тригер, який спрацьовує у разі зменшення вільного дискового простору до вказаного порога. Також можна автоматично діагностувати зупинку сервера чи критичне уповільнення швидкості обслуговування. На практиці кошти моніторингу непогано справляються з виявленням відмов, що вже відбулися, або виявленням простих симптомів майбутніх відмов, але в цілому передбачення можливого збою залишається для них міцним горішком. Передбачення шляхом ручного аналізу метрик вимагає залучення кваліфікованих фахівців. Воно низькопродуктивне. Більшість потенційних відмов можуть залишитися непоміченими.
Останнім часом серед великих IT-компаній з розробки ПЗ все більшої популярності набуває саме так зване передиктивне обслуговування програмних систем. Суть даного підходу полягає у знаходженні неполадок, що ведуть до деградації системи на ранніх етапах до її відмови з використанням штучного інтелекту. Цей підхід не виключає повністю ручний моніторинг системи. Він є допоміжним для процесу моніторингу загалом.
Основним інструментом реалізації передиктивного обслуговування є завдання пошуку аномалій у часових рядах, оскільки у разі виникнення аномалії у даних велика ймовірність того, що через деякий час виникне збій чи відмова. Аномалія - це деяке відхилення показників програмної системи, таке як виявлення деградації швидкості виконання запиту одного виду або зниження середньої кількості звернень, що обслуговуються при постійному рівні клієнтських сесій.
Завдання пошуку аномалій для програмних систем має власну специфіку. За ідеєю кожної програмної системи необхідна розробка чи доопрацювання наявних методів, оскільки пошук аномалій залежить від даних, у яких виробляється, а дані програмних систем дуже різняться залежно від інструментів реалізації системи до того, під якою обчислювальної машиною вона запущена.
Методи пошуку аномалій під час прогнозування відмов програмних систем
Насамперед, варто сказати, що ідея прогнозування відмов була навіяна статтею . Для перевірки ефективності підходу з автоматичним пошуком аномалій було обрано програмну систему «Web-Консолідація», яка є одним із проектів компанії НВО «Криста». Для неї раніше проводився ручний моніторинг за метриками. Оскільки система досить складна, для неї знімається велика кількість метрик: показники JVM (завантаження збирача сміття), показники ОС, під якою виконується код (віртуальна пам'ять, % завантаження ЦПУ ос), показники мережі (завантаження мережі), самого сервера (завантаження ЦПУ) , пам'яті), метрики wildfly та власні метрики додатки по всіх критичних підсистем.
Всі метрики знімаються із системи за допомогою graphite. Спочатку використовувалася база whisper як стандартне рішення для grafana, але зі зростанням клієнтської бази graphite перестав справлятися, вичерпавши пропускну спроможність дискової підсистеми ДЦ. Після цього було ухвалено рішення про пошук більш ефективного рішення. Вибір було зроблено на користь , що дозволило на порядок зменшити навантаження на дискову підсистему і в п'ять-шість разів зменшити дисковий об'єм, що займає. Нижче наведена схема механізму збору метрик з використанням graphite+clickhouse (рисунок 2).
Малюнок 2. Схема зняття метрик
Схема взята із внутрішньої документації. На ній показаний обмін даними між grafana (інтерфейс користувача для моніторингу, який ми використовуємо) і graphite. Зняття метрик із додатку робить окремий софт – . Він же складає їх у graphite.
Система «Web-Консолідація» має низку особливостей, які створюють проблеми для прогнозування відмов:
- часто відбувається зміна тренду. Для цієї програмної системи виходять різні версії. Кожна з них несе зміни у програмній частині системи. Відповідно, таким чином, розробники безпосередньо впливають на метрики даної системи і можуть викликати зміну тренда;
- особливість реалізації, і навіть мети використання клієнтами цієї системи часто закликають аномалії без попередньої деградації;
- відсоток аномалій щодо всього набору даних малий (<5%);
- можуть виникати розриви отримання показників від системи. У деякі короткі часові відтинки системі моніторингу не вдається отримати метрики. Наприклад, якщо сервер перевантажено. Для навчання нейромережі це критично. Виникає необхідність заповнювати прогалини синтетично;
- Випадки з аномаліями часто бувають актуальними лише для конкретного числа/місяця/часу (сезонність). Ця система має чіткий регламент використання її користувачами. Відповідно, метрики є актуальними лише для конкретного часу. Система може використовуватися не завжди, а лише в деякі місяці: вибірково залежно від року. Виникають ситуації, коли одне й те поведінка метрик у разі може вести до відмови програмної системи, а іншому немає.
Для початку були проаналізовані методи виявлення аномалій даних моніторингу програмних систем. У статтях з цієї тематики при малих відсотках аномалій щодо решти набору даних найчастіше пропонується використовувати нейронні мережі.
Основна логіка пошуку аномалій з допомогою даних нейронних мереж зображено малюнку 3:
Малюнок 3. Пошук аномалій за допомогою нейромережі
У результаті прогнозу чи відновлення вікна поточного потоку метрик розраховується відхилення від отриманого з працюючої програмної системи. У разі великої різниці між отриманими метриками від програмної системи та нейронної мережі можна робити висновок про аномальність поточного відрізка даних. Виникає наступна низка проблем для використання нейронних мереж:
- для коректної роботи в потоковому режимі дані для навчання моделей нейронних мереж повинні включати лише «нормальні» дані;
- потрібно мати актуальну модель для коректного виявлення. Зміна тренду та сезонності в метриках можуть викликати велику кількість помилкових спрацьовувань моделі. Для оновлення необхідно чітко визначити час, коли модель є застарілою. Якщо оновити модель пізніше або раніше, то, найімовірніше, буде велика кількість помилкових спрацьовувань.
Також не можна забувати про пошук і запобігання частому виникненню помилкових спрацьовувань. Передбачається, що вони найчастіше виникатимуть у позаштатних ситуаціях. Однак вони можуть бути і наслідком помилки нейронної мережі через недостатність її навчання. Необхідно мінімізувати кількість помилкових спрацьовувань моделі. В іншому випадку помилкові прогнози витрачатимуть багато часу адміністратора, призначеного для перевірки системи. Рано чи пізно закінчиться тим, що адміністратор просто перестане реагувати на «параноїдальну» систему моніторингу.
Рекурентна нейронна мережа
Для виявлення аномалій у часових рядах можна застосувати із пам'яттю LSTM. Проблема є лише в тому, що вона може застосовуватися тільки для тимчасових рядів, що прогнозуються. У нашому випадку не всі метрики прогнозовані. Спроба застосувати RNN LSTM для часового ряду представлена малюнку 4.
Рисунок 4. Приклад роботи рекурентної нейронної мережі з осередками пам'яті LSTM
Як очевидно з малюнка 4, RNN LSTM вдалося впоратися з пошуком аномалії цьому ділянці часу. Там, де результат має високу помилку прогнозування (mean error), справді відбулася аномалія за показниками. Використання однієї 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