Моніторинг: що треба знати новачку?
Уявіть собі адміністрування без моніторингу. Представили кількість того, що відпало і багнуло? А як ви все це намагаєтеся доводити до ладу представили? Складно, розуміємо.
Ще у 2000-х моніторинг був простішім, ніж зараз. Якщо раніше досить було моніторити кілька серверів і це вважалося інфраструктурою, то сьогодні інфраструктура — це безліч рівнів, для кожного з яких потрібна своя система моніторингу зі своїми нюансами.
Якщо раніше падали сервери й горіли жорсткі диски, то тепер потрібно розбиратися у всіх рівнях. І на швидкість взаємодії дивитися, і на мікросервіси всякі.
Щоб зрозуміти, куди саме потрібно дивитися адміністратору, розбираймося в моніторингу.
Було/Стало
Старі добрі часи
У 2000-х моніторити свою систему було простіше. В основному, відстежували процесори, мережі, диски, пам’ять, — тобто, показники системи. А все чому? Тому що навантаження були невеликими, на кшталт одного пхпшного додатку.
Головна проблема такого підходу — ці дані малоінформативні. Можна було зрозуміти, чи все працює або зовсім відпало. А ось нутро програми не побачити. Тому, коли з ним виникали проблеми, то доводилося чекати зауваженнь від користувачів і лагодити все в міру надходження інформації. Мало схоже на сьогодні, правда?
Сувора сучасність
Все ускладнилося. Системи стали динамічними з усіма масштабуваннями та мікросервісами. Іноді навіть невідомо, звідки і як саме все працює — настільки все серйозно.
Що частіше ламається: пісочний годинник або механічний? Чим складніше система, тим більше у неї проблем. Так і в нашому випадку. Метрики додатків, кількість подій в черзі, моніторинг масштабування. До всього треба прикрутити метрики, щоб зловити проблему в потрібний момент.
Що найцікавіше — проблеми на всьому цьому тлі стали не такими помітними, їх важче знайти. Розділимо їх на два сегменти: “все пропало” і “все працює, але не так”.
Якщо з першими начебто зрозуміло, то другі можуть завести далеко і надовго. Але водночас через багатошаровість моніторингу їх хоча б можна знайти до по-справжньому великих проблем.
Не дивуйтеся, якщо виявиться, що бізнесу теж цікавий моніторинг: транзакції, час між ними та все комерційне теж стали частиною задач моніторингу.
Як же моніторити?
Проєктувати
Потрібно розуміти, що саме ви моніторите ще на стадії розробки архітектури та додатків. Причому, важливіше вся архітектура додатку, а не серверна архітектура.
Розробники та архітектори повинні усвідомлювати, що є критичні частини в системі. Це слабкі місця можуть заважати розвитку проєкту і компанії взагалі, тому важливо розуміти, що є потреба постійно перевіряти їхню працездатність.
Хто в першу чергу повинен розуміти дані моніторингу? Адміністратор. Тому моніторинг потрібно зробити зручним і функціональним для адміністрування: отримане в потрібний момент сповіщення і розуміння проблеми швидко покажуть, що саме відпало.
Налаштувати метрики та алертів
Сповіщення потрібно зробити зрозумілими. Дуже зрозумілими. Якщо новий адміністратор отримає сповіщення, то він повинен зрозуміти все: в чому справа, куди дивитися або дзвонити, і як розв’язувати цю проблему.
Проблема не з’являється просто так: важливо зрозуміти першопричину її виникнення. Якщо щось перестало працювати, то в алерті потрібно побачити не тільки сам факт, але і вплив цієї проблеми на інші компоненти. Може щось пригальмовує, а може і зовсім не працює.
Але, щоб теза вище був правдивою, потрібно розуміти, чи нормально або ненормально це для системи. Десь повинна бути історія правок і параметрів роботи системи, щоб алертами покрити всі аномальні моменти.
Що ви зробите, якщо побачите сповіщення про проблему? Потрібно або вміти щось зробити з проблемою, або знати хто може допомогти з цим. Завжди повинен бути план дій на такі випадки. Постійно оновлюйте його, щоб інформація була актуальною.
Користуйтеся системами оркестрування, щоб ваш моніторинг завжди був актуальним. Якщо ви користуєтеся нею, то зміни та моніторинг проходять через неї. Головне — вміти цим користуватися.
Кидайте моніторинг на все нові проблеми. Якщо щось відпало в обхід моніторингу, то в цьому місці він зобов’язаний бути.
Моніторте моніторинг
Повинен бути зовнішній скрипт, який моніторить моніторинг. Розумієте, що буде, якщо моніторинг відпаде з усім-усім, що він моніторив? Катастрофа.
Чим моніторити?
Zabbix
Відмінний вибір, якщо адмініструєте великі системи. Взагалі підходить і для малих і середніх підприємств. Спочатку може бути не дуже просто розібратися, але цей з часом окупиться. У Zabbix легко додати свої параметри моніторингу, збирати дані, аналізувати дії, створювати графіки й тригери.
Cacti
Додаток для роботи з RRDTool. Легко працює з великими та малими мережами. Творці поставили завдання зробити простий у використанні інтерфейс, і у них це вийшло. У Cacti все будується на графіках, які можна сортувати по самих різних параметрах і групам. Є шаблони графіків, що спрощує настройку. З огляду на кастомізацію, сильний інструмент.
munin
Взагалі топ для невеликих мереж. Принцип роботи простий: один сервер (умовно munin) збирає всі дані з munin-node на інших серверах, які ми моніторимо. Сервер підключається до нод і отримує від них інформацію, яку зберігає в бази rrdtool. Нам навіть не потрібна MySQL. Модулі можна написати під все і зробити це просто. Рекомендуємо.
Висновок
Сучасний адміністратор повинен вміти налаштовувати та користуватися системами моніторингу. Це значною мірою знижує й оптимізує діяльність всієї системи, яку він обслуговує.
Цікава ця тема? Швидше переходьте на наш курс про системи моніторингу, де ми навчимо правильно працювати з усіма інструментами.