Моніторинг хостингу своїми руками: як зібрати систему спостереження, що попередить вас раніше за клієнтів
Уявіть ситуацію: п'ятниця, 23:47, ви вже в ліжку з серіалом. Телефон вибухає повідомленнями - клієнти пишуть, що сайт не працює. Ви лізете в панель хостингу, бачите, що сервер ще живий, але CPU горить на 98%, а RAM з'їдений якимось процесом-зомбі. Знайомо? Якби у вас працювала нормальна система моніторингу, ви б дізналися про проблему за 40 хвилин до першої скарги. І, можливо, навіть не прокинулися б - бо автоматичний скрипт перезапустив би сервіс сам. Сьогодні розберемо, як зібрати таку систему з нуля, навіть якщо ваш бюджет - нуль гривень.
Чому вбудований моніторинг хостера - це окуляри з чужим рецептом
Майже кожен хостинг-провайдер має якусь панель зі статистикою. cPanel покаже завантаження CPU. Plesk намалює графік трафіку. Але ось проблема: ці дані - як середня температура по лікарні. Вони показують загальну картину з запізненням у 5-15 хвилин і без контексту.
Що конкретно не так із вбудованим моніторингом більшості хостерів:
- Оновлення графіків раз на 5-15 хвилин - за цей час сайт встигне втратити сотні відвідувачів
- Немає алертів - ви дізнаєтесь про проблему, коли самі зайдете подивитися
- Моніториться тільки «залізо», а не ваш додаток - сервер може бути живий, а WordPress вже лежить
- Історія зберігається максимум 30 днів - шукати тренди та закономірності неможливо
- Нуль кастомізації - ви не можете додати перевірку конкретного URL чи API-ендпоінта
Вбудований моніторинг хостера створений для хостера, а не для вас. Його мета - показати, що з їхнього боку все нормально. Ваша мета інша - знати, що відбувається з вашим проєктом кожну секунду.
П'ять інструментів, які перетворять вас на всевидяче око
Гарна новина: збудувати повноцінну систему моніторингу у 2025 році можна безкоштовно або майже безкоштовно. Погана новина: доведеться трохи попрацювати руками. Але один раз - і потім воно працює роками.
| Інструмент | Що моніторить | Вартість | Складність налаштування | Найкраще для |
|---|---|---|---|---|
| UptimeRobot | Доступність сайту, час відгуку, SSL | Безкоштовно (50 моніторів) | Легко (5 хвилин) | Будь-якого проєкту |
| Netdata | CPU, RAM, диск, мережа, процеси | Безкоштовно (open-source) | Середньо (20 хвилин) | VPS та виділених серверів |
| Grafana + Prometheus | Все, що можна виміряти цифрою | Безкоштовно (self-hosted) | Складно (2-4 години) | Серйозних продакшн-проєктів |
| Hetrixtools | Аптайм, блеклісти, ресурси сервера | Безкоштовно (15 моніторів) | Легко (10 хвилин) | Кількох сайтів одночасно |
| Healthchecks.io | Cron-завдання, бекапи, скрипти | Безкоштовно (20 перевірок) | Легко (5 хвилин) | Контролю фонових задач |
Моя рекомендація для старту: UptimeRobot + Netdata. Перший перевіряє сайт ззовні (як його бачать користувачі), другий показує, що відбувається всередині сервера. Разом вони закривають 80% потреб типового проєкту.
Покроковий рецепт: від голого сервера до повного контролю
Давайте конкретно. Без абстракцій. Ось що я раджу зробити в перший вихідний, коли знайдеться година вільного часу.
- Реєстрація в UptimeRobot - додайте всі ваші сайти (до 50 безкоштовно). Налаштуйте перевірку кожні 5 хвилин. Підключіть Telegram-бота для алертів - email у 2025 році надто повільний для критичних сповіщень.
- Встановіть Netdata на VPS - одна команда: bash <(curl -Ss https://my-netdata.io/kickstart.sh). Через 60 секунд у вас буде дашборд з 2000+ метриками в реальному часі.
- Налаштуйте алерти в Netdata - за замовчуванням він вже має розумні пороги, але підкрутіть їх під себе. CPU вище 85% протягом 10 хвилин? Алерт. Вільного місця менше 10%? Алерт. RAM заповнена на 90%? Негайний алерт.
- Додайте Healthchecks.io для cron-задач - ваші бекапи, очищення кешу, оновлення пошукового індексу - все це має «відзначатися» в Healthchecks. Якщо задача не виконалась вчасно - ви отримаєте повідомлення.
- Створіть status-page - UptimeRobot дає безкоштовну сторінку статусу. Розшарте її команді та ключовим клієнтам. Прозорість будує довіру.
Весь процес займе близько години. Одну годину - і ви більше ніколи не дізнаєтесь про падіння сайту від розлюченого клієнта.
Три метрики, які всі ігнорують - а потім шкодують
CPU, RAM, диск - це очевидно. Але досвідчені адміністратори стежать за речами, про які новачки навіть не підозрюють.
Disk I/O wait. Процесор може бути завантажений на 30%, а сайт все одно гальмує. Чому? Тому що він чекає, поки диск прочитає дані. На shared-хостингу це бич - ваш «сусід» запустив важкий запит до бази, і ваш сайт страждає. Netdata показує iowait окремим графіком. Якщо він регулярно вище 20% - час мігрувати.
Кількість відкритих з'єднань до бази даних. MySQL за замовчуванням дозволяє 151 одночасне з'єднання. Коли ліміт вичерпано - нові запити стають у чергу. Відвідувач бачить білий екран або помилку 503. Моніторте це число - воно покаже, чи ваш код ефективно працює з базою.
Час відповіді від origin до CDN. Якщо ви використовуєте Cloudflare чи інший CDN, стежте за TTFB (Time To First Byte) на самому сервері, а не через CDN. CDN маскує повільність - ви думаєте, що все добре, а насправді origin-сервер відповідає за 3 секунди. Просто кеш рятує. Поки не перестане рятувати.
«Ви не можете покращити те, що не вимірюєте. Але ще небезпечніше - вимірювати не те, що потрібно.» - Пітер Друкер, теоретик менеджменту, чия думка ідеально лягає на моніторинг серверів.
Автоматичне зцілення: коли моніторинг не тільки дивиться, а й діє
Спостерігати за метриками - це добре. Але найкращий моніторинг - той, який вирішує проблеми сам, поки ви спите.
Ось реальний приклад. На одному з моїх проєктів PHP-FPM іноді «зависав» - воркери накопичувалися, нові запити не оброблялися. Сайт лежав. Що я зробив:
- Netdata виявляє, що кількість активних PHP-FPM воркерів дорівнює максимуму протягом 2 хвилин
- Алерт тригерить webhook на простий bash-скрипт
- Скрипт перезапускає PHP-FPM і записує подію в лог
- Я отримую повідомлення в Telegram: «PHP-FPM перезапущено автоматично, даунтайм 4 секунди»
Замість 15-30 хвилин простою (поки прокинувся, зрозумів, підключився, перезапустив) - 4 секунди. Клієнти навіть не помітили. А я спокійно доспав ніч.
Такий підхід називають self-healing infrastructure. Monit, Supervisor, systemd watchdog - інструменти, які вміють перезапускати сервіси автоматично. Підключіть їх до вашого моніторингу, і ваш сервер навчиться «лікувати» себе сам.
Скільки це коштує і коли себе окупає
Давайте порахуємо. Інтернет-магазин з середнім чеком 1200 грн і конверсією 2% отримує 500 відвідувачів на годину в пік. Одна година простою - це мінус 10 замовлень, мінус 12 000 грн. А якщо падіння стається вночі і його помічають тільки вранці? 8 годин - мінус 96 000 грн.
Вартість моніторингу: нуль гривень (безкоштовні інструменти) + 1 година вашого часу на налаштування. Навіть якщо ваш час коштує 2000 грн/год - це окупається при першому ж запобіганому простої тривалістю 10 хвилин.
Для тих, хто хоче преміум: платний план UptimeRobot - $7/міс, Grafana Cloud Free - безкоштовно до 10 000 метрик, Better Stack (колишній Better Uptime) - від $24/міс з красивими дашбордами та інтеграцією з PagerDuty. Але чесно? Для 90% проєктів безкоштовних інструментів вистачає з головою.
Що зробити прямо зараз
Не закладайте цю статтю в закладки, щоб «прочитати потім». Потім - це ніколи, ми ж обидва це знаємо. Замість цього відкрийте нову вкладку, зайдіть на uptimerobot.com, зареєструйтесь і додайте свій перший монітор. Це займе 3 хвилини. Серйозно - я засікав.
А тепер запитання, яке не дає мені спокою: якщо ваш сайт упав прямо зараз - через скільки хвилин ви б про це дізналися? Якщо відповідь «не знаю» або «коли напишуть клієнти» - у вас є чим зайнятися цього вечора. Ваш сервер уже намагається щось вам розповісти. Питання тільки в тому, чи слухаєте ви його.