Налаштування моніторингу доступності: Uptime Kuma, Pingdom, UptimeRobot
Ви щойно виклали реліз, і раптом — перші скарги від клієнтів: «сайт не завантажується». Команда дізнається про падіння не з системи моніторингу, а з чату підтримки. Ми стикалися з цим десятки разів: найпростіший і найнадійніший спосіб — налаштувати uptime-моніторинг. Не потрібна складна observability — достатньо перевіряти HTTP-відповідь від /health або /healthz кожні 30–60 секунд. Якщо відповідь не 200 три рази підряд — алерт. Без цього елементарного шару будь-який outage стає сюрпризом. Середній час виявлення (MTTD) скорочується з десятків хвилин до секунд, а економія на витратах від години простою може сягати тисяч доларів. Хочете таку саму надійність? Зв'яжіться з нами — ми підберемо інструмент під вашу інфраструктуру.
Який інструмент моніторингу обрати: Uptime Kuma, Pingdom чи UptimeRobot?
Вибір залежить від того, чи готові ви керувати сервером або віддаєте перевагу SaaS. Порівняємо популярні рішення.
| Інструмент | Тип | Локації | Алерти | Коли обирати |
|---|---|---|---|---|
| Uptime Kuma | Self-hosted | Своя нода | Email, Slack, Telegram, PagerDuty | Є Kubernetes-кластер, не хочеться платити за підписку |
| UptimeRobot | SaaS | 160+ локацій | Email, Slack, Webhook | Швидкий старт, безкоштовний тир на 50 моніторів |
| Pingdom | SaaS | 100+ локацій | Багаті інтеграції, RUM | Потрібні детальні звіти та real-user monitoring |
| Better Uptime | SaaS | 30+ локацій | On-call, status page | Хочете все в одному: моніторинг + incident-менеджмент |
Uptime Kuma — наш фаворит під Kubernetes. Він у 5 разів дешевший за Pingdom при аналогічних можливостях, а розгортання займає 5 хвилин:
helm repo add uptime-kuma https://helm.irsigler.cloud
helm install uptime-kuma uptime-kuma/uptime-kuma \
--set ingress.enabled=true \
--set ingress.hosts[0].host=uptime.example.com \
--namespace monitoring
Для SaaS-варіанту реєстрація — 2 хвилини. Вибір між ними часто впирається в бюджет і бажання контролювати приватність даних.
Як налаштувати Uptime Kuma за 5 хвилин
- Встановіть Helm-чарт, як показано вище.
- Налаштуйте Ingress і TLS — сертифікат від Let's Encrypt через cert-manager.
- Додайте перший монітор: HTTP-перевірка на
/healthз інтервалом 30 секунд. - Налаштуйте сповіщення: Telegram або Slack.
- Перевірте статус-сторінку — дашборд готовий.
Що моніторити та з якою частотою: таблиця типових параметрів
Мінімальний набір перевірок для типового веб-проекту та рекомендовані інтервали.
| Тип перевірки | Приклад endpoint | Інтервал | Таймаут | Retry count |
|---|---|---|---|---|
| HTTP / HTTPS | /health |
30–60 с | 15–30 с | 2 |
| Ping | IP сервера | 60 с | 10 с | 3 |
| TCP port | :443 |
60 с | 15 с | 2 |
| SSL сертифікат | — | раз на 6 годин | — | — |
| Synthetic (браузер) | checkout flow | 5–10 хв | 30 с | 1 |
Для головної сторінки та API health endpoint достатньо HTTP-перевірки раз на хвилину. Якщо сервіс залежить від зовнішнього API (наприклад, платіжного шлюзу) — моніторте і його, щоб відрізняти свої збої від проблем партнера.
Чому виникають хибні спрацьовування і як їх уникнути?
Найчастіший біль uptime-моніторингу — хибні спрацьовування. Через один втрачений пакет ви отримуєте алерт о 3 годині ночі. Ми використовуємо три правила:
- Retry before alert: не менше 2–3 неуспішних перевірок підряд. В Uptime Kuma це Heartbeat Retry.
- Timeout: 10–30 секунд залежно від сервісу. Таймаут у 5 секунд — гарантія хибних алертів при будь-якому навантаженні.
- Alert cooldown: повторне сповіщення не частіше разу на годину для тривалого outage.
Це налаштування варто продумати заздалегідь — воно врятує від шуму в чатах і збереже нерви on-call-інженеру. Згідно з даними Uptime Institute, 30% алертів є хибними при відсутності правильної конфігурації retry та cooldown.
SSL-сертифікати та домени: не дайте HTTPS впасти
Моніторинг терміну дії сертифіката — стандартна, але часто забута практика. Ми налаштовуємо алерт за 30 та за 7 днів до експірації. В Uptime Kuma це вбудована функція: достатньо додати перевірку SSL Certificate на домен. Якщо не моніторити, сертифікат може закінчитися у вихідні — і HTTPS перестане працювати, а ви дізнаєтеся про це від клієнтів. Замовте налаштування моніторингу — і ми передбачимо всі такі сценарії.
Що таке синтетичний моніторинг і навіщо він потрібен?
Synthetic checks симулюють дії користувача (логін, оформлення замовлення) і виявляють проблеми, які не видно простим HTTP-перевіркам. Наприклад, сторінка повертає 200, але корзина не оновлюється. Налаштування таких сценаріїв — наступний рівень після базового uptime. Ми включаємо synthetic моніторинг для критичних бізнес-шляхів. Для кожного сценарію ми пишемо скрипт на Puppeteer або Playwright, запускаємо його раз на 5–10 хвилин з кількох локацій. Алерт спрацьовує при помилці або перевищенні часу відповіді. Один такий чек замінює десятки ручних перевірок QA.
Що ви отримуєте в результаті: повний комплект
Після налаштування моніторингу ви отримуєте:
- Дашборд статусу всіх критичних сервісів (self-hosted або в хмарі)
- Автоматичні алерти в ваш месенджер / PagerDuty без шуму
- Моніторинг SSL-сертифікатів та доменних імен
- Документацію: runbook для кожного монітора, опис порогів та дій при алерті
- Рекомендації по покращенню: які перевірки додати, як налаштувати synthetic моніторинг для складних сценаріїв (логін, checkout)
Ми також передаємо доступи до системи та навчаємо чергових інженерів реагувати на алерти. Uptime Kuma розгорнутий в Kubernetes дає економію на SaaS-підписках до 90% при аналогічному функціоналі. Отримайте консультацію — ми підготуємо пропозицію під вашу інфраструктуру.
Терміни та бюджет
Налаштування базового моніторингу для 5–10 ендпоінтів на SaaS-інструменті займає від 4 годин. Якщо обрано self-hosted Uptime Kuma з інтеграцією в існуючі канали оповіщення та моніторингом 20+ ендпоінтів — до 2 днів. Вартість розраховується індивідуально, залежно від обсягу та складності. Зв'яжіться з нами — ми підготуємо пропозицію під вашу інфраструктуру.
