Настройка мониторинга доступности: 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 | Хотите всё в одном: мониторинг + инцидент-менеджмент |
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 дней. Стоимость рассчитывается индивидуально, в зависимости от объёма и сложности. Свяжитесь с нами — мы подготовим предложение под вашу инфраструктуру.
