Всім привіт!
Наша компанія займається розробкою програмного забезпечення та подальшою технічною підтримкою. В рамках технічної підтримки потрібно не просто виправляти помилки, а стежити за працездатністю наших програм.
Наприклад, якщо «упав» один із сервісів, то потрібно автоматично зафіксувати цю проблему і приступити до її вирішення, а не чекати звернень у технічну підтримку незадоволених користувачів.
У нас невелика компанія, немає ресурсів вивчати та утримувати якісь складні рішення для моніторингу додатків, потрібно було знайти просте та ефективне рішення.
Стратегія моніторингу
Виконати перевірку працездатності програми не просто, це завдання нетривіальне, можна навіть сказати творче. Особливо складно виконати перевірку складної багатоланкової системи.
Як можна з'їсти слона? Тільки частинами! Використовуємо цей підхід для моніторингу програм.
Суть нашої стратегії моніторингу:
Розбийте програму на компоненти.
До кожного компонента придумайте контрольні перевірки.
Компонент вважається справним, якщо його контрольні перевірки виконуються без помилок. Програма вважається справною, якщо справні всі її компоненти.
Таким чином, будь-яку систему можна представити у вигляді дерева компонентів. Складні компоненти розбиваються більш прості. Найпростіші компоненти мають перевірки.
Контрольні перевірки не мають виконувати функціональне тестування, це не юніт-тести. Контрольні перевірки повинні перевіряти, як почувається компонент у поточний момент часу, чи є всі необхідні для його функціонування ресурси, чи є якісь проблеми.
Див не буває, більшість перевірок потрібно буде розробити самостійно. Але не варто лякатися, тому що в більшості випадків одна перевірка займає 5-10 рядків коду, але ви зможете реалізувати будь-яку логіку і вам буде чітко зрозуміло, як відпрацьовує перевірка.
Система моніторингу
Допустимо ми розбили додаток на компоненти, придумали та реалізували для кожного компонента перевірки, але що робити з результатами цих перевірок? Як ми дізнаємося про те, що якась перевірка здійснилася з помилкою?
Нам потрібна система моніторингу. Вона виконуватиме такі завдання:
- Отримувати результати перевірок і визначати статус компонентів.
Візуально це виглядає як підсвічування компонентів дерева. Справні компоненти стають зеленими, проблемні червоними. - Виконувати загальні перевірки "з коробки".
Деякі перевірки система моніторингу вміє виконувати сама. Навіщо винаходити велосипед, використовуватимемо їх. Наприклад, можна перевірити, що сторінка сайту відкриває або сервер пінгується. - Надсилання повідомлень про проблеми зацікавленим особам.
- Візуалізація даних моніторингу, надання звітів, графіків та статистики.
Короткий опис системи АСМО
Найкраще пояснювати на прикладі. Погляньмо, як організований моніторинг працездатності системи АСМО.
АСМО – це автоматизована система метеорологічного забезпечення. Система допомагає фахівцям дорожніх служб зрозуміти, де і коли необхідно обробляти дорогу протиожеледними матеріалами. Система збирає дані із пунктів дорожнього контролю. Пункт дорожнього контролю – це місце на дорозі, де встановлено обладнання: метеостанція, відеокамера та інше. Для прогнозування небезпечних ситуацій система отримує прогнози погоди із зовнішніх джерел.
Отже, склад системи досить типовий: сайт, агент, обладнання. Приступимо до моніторингу.
Розбиваємо систему на компоненти
У системі АСМО можна виділити такі компоненти:
1. Особистий кабінет
Це веб-додаток. Як мінімум потрібно перевіряти, що програма доступна в Інтернеті.
2. База даних
У базі даних зберігаються важливі для звітності дані, необхідно перевіряти, що резервні копії бази даних успішно створюються.
3. Сервер
Під сервером мається на увазі залізо, на якому працюють програми. Потрібно перевіряти стан HDD, RAM, CPU.
4. Агент
Це windows-служба, яка виконує багато різних завдань за розкладом. Як мінімум, необхідно перевіряти, що служба працює.
5. Завдання агента
Просто знати, що агент працює недостатньо. Агент може працювати, але не виконувати покладені на нього завдання. Розіб'ємо компонент агента на завдання і перевірятимемо успішно чи працює кожне завдання агента.
6. Пункти дорожнього контролю (контейнер усіх ГДК)
Пунктів дорожнього контролю багато, тому поєднаємо всі ГДК в одному компоненті. Це дозволить зручніше читати дані моніторингу. При перегляді стану компонента «система АСМО» відразу буде зрозуміло, де проблеми: у додатках, залізі або в ГДК.
7. Пункт дорожнього контролю (один ГДК)
Даний компонент будемо вважати справним, якщо справні всі пристрої на цьому ГДК.
8. пристрій
Це відеокамера або метеостанція, встановлені на ГДК. Необхідно перевіряти, що пристрій справно працює.
У системі моніторингу дерево компонентів виглядатиме так:
Моніторинг веб-програми
Отже, ми розбили систему на компоненти, тепер потрібно вигадати для кожного компонента перевірки.
Для моніторингу веб-програми ми використовуємо такі перевірки:
1. Перевірка відкриття головної сторінки
Цю перевірку виконує система моніторингу. Для її виконання вказуємо адресу сторінки, очікуваний фрагмент відповіді та максимальний час виконання запиту.
2. Перевірка терміну оплати домену
Дуже важлива перевірка. Коли домен залишається без оплати, користувачі не можуть відкрити веб-сайт. Вирішення проблеми може тривати кілька днів, т.к. зміни ДНР застосовуються не відразу.
3. Перевірка SSL сертифіката
Зараз майже всі сайти використовують для доступу протокол https. Для коректної роботи протоколу потрібний сертифікат валідний SSL.
Нижче наведено компонент «Особистий кабінет» у системі моніторингу:
Усі перевірки вище підійдуть більшість додатків і вимагають написання коду. Це дуже здорово, тому що можна почати моніторинг будь-якої веб-програми за 5 хвилин. Нижче наведено додаткові перевірки, які можна виконати для веб-додатків, але їх реалізація складніша і специфічніша для різних програм, тому ми не розбиратимемо їх у цій статті.
Що ще можна перевірити?
Для більш повного моніторингу веб-програми можна виконати такі перевірки:
- Кількість помилок JavaScript за період
- Кількість помилок на стороні веб-програми (back-end) за період
- Кількість не успішних відповідей веб-застосунку (код відповіді 404, 500 і т.д.)
- Середній час виконання запиту
Моніторинг windows-служби (агента)
У системі АСМО агент виконує роль планувальника завдань, який у фоновому режимі виконує завдання за розкладом.
Якщо всі завдання агента виконуються успішно, агент працює справно. Виходить, щоб виконати моніторинг агента потрібно виконати моніторинг його завдань. Тому розбиваємо компонент Агент на завдання. Створимо кожному за завдання окремий компонент у системі моніторингу, де компонент «Агент» буде «батьком».
Розбиваємо компонент «Агент» на дочірні компоненти (завдання):
Отже, ми розтрощили складний компонент на кілька простих. Тепер потрібно для кожного простого компонента вигадати перевірки. Зверніть увагу, що батьківський компонент «Агент» не матиме жодної перевірки, тому що його стан система моніторингу обчислить самостійно за статусом його дочірніх компонентів. Іншими словами, якщо всі завдання виконуються успішно, значить агент працює успішно.
У системі АСМО понад сто завдань, невже для кожного завдання потрібно вигадувати унікальні перевірки? Звичайно, контроль буде кращим, якщо для кожного завдання агента ми придумаємо та реалізуємо свої спеціальні перевірки, але в більшості випадків достатньо використовувати універсальні перевірки.
У системі АСМО використовуються лише універсальні перевірки для завдань і цього достатньо, щоб стежити за працездатністю системи.
Перевірка виконання
Найпростіша та найефективніша перевірка – це перевірка виконання. Перевірка перевіряє, що завдання виконується, без помилок. Ця перевірка є у всіх завдань.
алгоритм перевірки
Після кожного виконання завдання потрібно надіслати в систему моніторингу результат перевірки SUCCESS, якщо виконання завдання пройшло успішно, або ERROR, якщо виконання завершилося з помилкою.
Ця перевірка дозволяє виявити такі проблеми:
- Завдання виконується, але завершується помилкою.
- Завдання перестало виконуватися, наприклад, зависло.
Розглянемо, як вирішуються ці проблеми докладніше.
Проблема 1 – Завдання виконується, але завершується помилкою
Нижче наведено випадок, коли завдання виконується, але з 14:00 до 16:00 завершується помилкою.
По малюнку видно, що коли завдання завершується помилкою, то відразу надсилається сигнал у систему моніторингу і статус відповідної перевірки у системі моніторингу стає alarm.
Зауважте, що в системі моніторингу від статусу перевірки залежить і статус компонента. Статус alarm перевірки переведе в alarm усі вищестоящі компоненти, див. малюнок нижче.
Проблема 2 - Завдання перестало виконуватися (зависло)
Як система моніторингу зрозуміє, що завдання зависло?
Результат перевірки має час актуальності, наприклад, 1:XNUMX. Якщо проходить година, а нового результату перевірки немає, то система моніторингу встановить перевірці статус alarm.
На малюнку вище о 14:00 вимкнули світло. О 15:00 система моніторингу виявить, що результат перевірки (від 14:00) зник, т.к. закінчився час актуальності (одна година), а нового результату немає, і переведе перевірку у статус alarm.
О 16:00 світло знову ввімкнули, програма виконає завдання та надішле результат виконання в систему моніторингу, статус перевірки знову стане success.
Який час актуальності перевірки використати?
Час актуальності має бути більшим за період виконання завдання. Рекомендую встановлювати час актуальності у 2-3 рази більший, ніж період виконання завдання. Це потрібно, щоб не отримувати хибні сповіщення, коли, наприклад, завдання виконувалося довше, ніж зазвичай, або хтось перезавантажував програму.
Перевірка прогресу
У системі АСМО є завдання «Завантаження прогнозу», яке щогодини намагається завантажити новий прогноз із зовнішнього джерела. Точний час, коли у зовнішній системі з'являється новий прогноз, не відомо, але відомо, що це відбувається 2 рази на день. Виходить, що якщо нового прогнозу немає кілька годин, то це нормально, але якщо нового прогнозу немає вже більше доби, то десь щось зламалося. Наприклад, у зовнішній системі прогнозів може змінитися формат даних, через що АСМО не побачить нового релізу прогнозу.
алгоритм перевірки
Завдання надсилає в систему моніторингу результат перевірки SUCCESS, коли вдається отримати прогрес (завантажити новий прогноз погоди). Якщо прогресу немає або відбулася помилка, то в систему моніторингу нічого не відправляється.
Перевірка повинна мати такий інтервал актуальності, щоб за цей час гарантовано отримати новий прогрес.
Зверніть увагу, що проблему ми дізнаємося із затримкою, тому що система моніторингу чекає, коли закінчиться час актуальності останнього результату перевірки. Тому час актуальності перевірки не потрібно робити надто великим.
Моніторинг бази даних
Для контролю бази даних у системі АСМО ми виконуємо такі перевірки:
- Перевірка створення резервних копій
- Перевірка вільного місця на диску
Перевірка створення резервних копій
У більшості програм важливо мати актуальні резервні копії бази даних, щоб у разі поломки сервера можна було розгорнути програму на новому сервері.
АСМО раз на тиждень створює резервну копію та відправляє її до сховища. Коли дана процедура успішно завершується в систему моніторингу, відправляється результат перевірки success. Підсумок перевірки має час актуальності 9 днів. Тобто. Для контролю над створенням резервних копій використовується механізм «перевірка прогресу», який ми розбирали вище.
Перевірка вільного місця на диску
Якщо на диску не буде достатньо вільного місця, база даних не зможе нормально працювати, тому важливо контролювати розмір вільного місця.
Для перевірки числових параметрів зручно використовувати метрики.
метрика – це числова змінна, значення якої передається до системи моніторингу. Система моніторингу перевіряє порогові значення та обчислює статус метрики.
Нижче наведено малюнок як виглядає компонент «База даних» у системі моніторингу:
Моніторинг сервера
Для моніторингу сервера ми використовуємо такі перевірки та метрики:
1. Вільне місце на диску
Якщо місце на диску закінчиться, програма не зможе працювати. У нас використовується 2 порогові значення: перший рівень WARNING, другий рівень ALARM.
2. Середнє значення RAM у відсотках за годину
Ми використовуємо середнє за годину, т.к. нас не цікавлять рідкісні стрибки.
3. Середнє значення CPU у відсотках за годину
Ми використовуємо середнє за годину, т.к. нас не цікавлять рідкісні стрибки.
4. Перевірка ping
Перевіряє, що сервер у мережі. Цю перевірку вміє виконувати система моніторингу, не потрібно писати код.
Нижче наведено малюнок як виглядає компонент «Сервер» у системі моніторингу:
Моніторинг обладнання
Розповім, як відбувається отримання даних. Для кожного пункту дорожнього контролю (ГДК) у планувальнику завдань є завдання, наприклад, «Опитування ГДК М2 км 200». Завдання раз на 30 хвилин отримує дані з усіх пристроїв ГДК.
Проблема каналу зв'язку
Більшість обладнання стоїть за містом, для передачі даних використовується GSM мережа, яка працює не стабільно (мережа тобто її немає).
Через часті збої мережі перший час перевірка опитування ГДК в моніторингу виглядала так:
Стало зрозуміло, що це не робочий варіант, тому що виходило багато помилкових повідомлень про проблеми. Тоді було прийнято рішення для кожного пристрою використовувати перевірку прогресу, тобто. у систему моніторингу відправляється лише сигнал success, у разі, коли пристрій опитується без помилки. Час актуальності встановили 5 годин.
Тепер моніторинг надсилає повідомлення про проблеми лише тоді, коли пристрій не вдається опитати більше 5 годин. З високою ймовірністю це не помилкові тривоги, а реальні проблеми.
Нижче наведено малюнок як виглядає обладнання в системі моніторингу:
Важливо!
Коли мережа GSM перестає працювати, то не опитуються всі пристрої ГДК. Щоб зменшити кількість листів від системи моніторингу, наші інженери підписуються на повідомлення про проблеми компонентів з типом ГДК, а не Пристрій. Це дозволяє отримати одне повідомлення по кожному ГДК, а не отримувати окреме повідомлення щодо кожного пристрою.
Підсумкова схема моніторингу АСМО
Давайте зберемо все разом і подивимося, яка схема моніторингу у нас вийшла.
Висновок
Давайте підіб'ємо підсумки.
Що нам дав моніторинг працездатності АСМО?
1. Зменшився час усунення дефектів
Раніше ми дізнавалися про дефекти від користувачів, але не всі користувачі повідомляють про дефекти. Бувало так, що про несправність будь-якого компонента системи ми дізнавалися за тиждень після його появи. Тепер система моніторингу повідомляє нас про проблеми відразу, як тільки проблема виявлена.
2. Збільшилася стабільність роботи системи
Оскільки дефекти почали усуватися раніше, те й система загалом стала працювати набагато стабільніше.
3. Зниження кількості звернень на технічну підтримку
Багато проблем тепер усуваються до того, як про них дізнаються користувачі. Користувачі стали менше звертатися на технічну підтримку. Все це добре впливає на нашу репутацію.
4. Збільшення лояльності замовника та користувачів
Замовник помітив позитивні зміни у стабільності роботи системи. Користувачі менше стикаються з проблемами в роботі із системою.
5. Скорочення витрат на технічну підтримку
Ми перестали вручну виконувати будь-які перевірки. Тепер усі перевірки автоматизовані. Раніше ми дізнавалися про проблеми від користувачів, часто було складно зрозуміти, яку проблему говорить користувач. Тепер про більшість проблем повідомляє система моніторингу, сповіщення містять технічні дані, за якими завжди зрозуміло, що і де зламалося.
Важливо!
Не можна встановлювати систему моніторингу на той же сервер, де працюють ваші програми. Якщо сервер вийде з ладу, то програми перестануть працювати, і нікому буде надсилати повідомлення.
Система моніторингу має працювати на окремому сервері в іншому ЦОДі.
Якщо ви не хочете використовувати виділений сервер у новому ЦОДі, можна скористатися хмарною системою моніторингу. У нашій компанії використовується хмарна моніторингова система Zidium, але ви можете використовувати будь-яку іншу систему моніторингу. Вартість хмарної системи моніторингу нижча за оренду нового сервера.
рекомендації:
- Розбивайте додатки та системи у вигляді дерева компонентів якомога детальніше, так буде зручно розуміти, де і що зламалося, а контроль буде повніший.
- Щоб перевірити працездатність компонента, використовуйте перевірки. Краще використовувати багато простих перевірок, аніж одну складну.
- Порогові значення метрик налаштовуйте на боці системи моніторингу, а не прописуйте код. Це позбавить вас від перекомпілювання, переконфігурування або перезапуск програми.
- Для користувацьких перевірок використовуйте час актуальності із запасом, щоб не отримувати хибні сповіщення через те, що якась перевірка виконувалася трохи довше, ніж зазвичай.
- Постарайтеся зробити так, щоб компоненти в системі моніторингу ставали червоними лише тоді, коли проблема є точно. Якщо вони стануть червоними через дрібниці, то ви перестанете звертати увагу на повідомлення системи моніторингу, її сенс буде втрачено.
Якщо ви ще не використовуєте систему моніторингу, починайте! Це не так складно, як здається. Отримайте кайф, роздивляючись зелене дерево компонентів, яке ви виростили самі.
Удачи.
Джерело: habr.com