Моніторинг та алерти для бізнесу потрібні не “бо так правильно”, а щоб виконувалося просте правило: про збій першими дізнаєтесь ви, а не клієнти.
Частий сценарій: сайт “підвисає”, заявки не приходять, менеджери думають, що “тихий сезон”, а насправді — помилка на сервері або переповнився диск. Іноді такі збої тягнуться днями, бо ніхто не дивиться на метрики.
Нижче — мінімальний набір, який дає результат уже з першого тижня.
1) Моніторинг доступності: сайт/CRM/API “живі чи ні”
Це базовий рівень:
- перевірка HTTP/HTTPS (відповідь сервера, час відповіді);
- моніторинг ключових сторінок (головна, форма заявки, оплата);
- окремо — API/інтеграції (якщо є).
Алерт має бути простим: “недоступно/повільно”.
2) Моніторинг ресурсів сервера: щоб не впасти “тихо”
Щонайменше:
- CPU (піки, тривале завантаження);
- RAM (витоки пам’яті);
- диск (місце + inode, якщо актуально);
- стан бази даних (підключення, час відповіді);
- мережа (пакети/затримки).
Найболючіше — диск. Переповнився диск = база/логування/оновлення падають каскадом.
3) SSL, домени, критичні сервіси
Обов’язково відстежуйте:
- закінчення SSL-сертифікату (за 14/7/3 дні);
- домен (термін реєстрації);
- стан поштових сервісів (якщо бізнес залежить від пошти).
Це ті помилки, які “дивні”, але дуже дорогі: сайт працює — і раптом браузер показує “небезпечний”.
4) Логи та помилки: щоб бачити причину, а не симптом
“Сайт 500” без логів — це гадання. Мінімально потрібне:
- збір логів застосунку;
- помилки 4xx/5xx з частотою;
- алерт, якщо різко зростає кількість помилок або з’являються критичні винятки.
Важливо: алерти мають показувати тренд, а не спамити за кожну дрібницю.
5) Резервні копії: моніторити не тільки факт, а й відновлення
Критична помилка: “бекап є” = “все ок”. Ні.
Правильний мінімум:
- алерт, якщо бекап не створився;
- алерт, якщо бекап менший/більший за норму (ознака проблеми);
- регулярний тест відновлення (хоча б раз на місяць для ключових даних).
Якщо у вас резервне копіювання на власні сервери — це добре, але все одно потрібні перевірки й тести відновлення, інакше “бекап” може виявитися непридатним у найгірший момент.
6) Як налаштувати алерти, щоб вони працювали
Хороший алерт:
- конкретний (що сталося, де, коли);
- має поріг (не “CPU 60%”, а “CPU > 90% 10 хвилин”);
- має дію (що робити першими кроками).
Поганий алерт:
- приходить занадто часто;
- без контексту;
- не має пріоритетів.
Порада: робіть 2–3 рівні важливості: інфо / важливо / критично.
PortGuard IT може налаштувати моніторинг і алерти “під ключ”: метрики серверів, доступність сервісів, логування, контроль бекапів і сценарії реагування — щоб ви бачили проблему раніше, ніж її відчує бізнес.