Моніторинг доступності сайту: налаштування Uptime Monitoring

Моніторинг працездатності сайту (Uptime Monitoring)

Ми маємо 5+ років досвіду та налаштували 200+ проєктів. Середній час реакції на збій — 2 хвилини. Коли ваш сайт лежить, а ви дізнаєтесь від клієнта — це катастрофа. Ми налаштовуємо системи моніторингу, які сповіщають про збій за хвилину. Uptime Monitoring — базовий шар спостережуваності: перевірка доступності URL через HTTP-запити із заданим інтервалом. Він виявляє сам факт недоступності, але не причину. Тому ми доповнюємо його моніторингом інфраструктури та логуванням помилок. Наші інженери налаштовували моніторинг для 200+ проєктів, середній час реакції на збій — 2 хвилини.

Чому простий пінг не рятує?

ICMP-пінг перевіряє доступність хоста, але не застосунку. HTTP 200 каже, що сервер живий, але сторінка може завантажуватися хвилину. Uptime Monitoring виявляє такі ситуації: ми перевіряємо статус-код, час відповіді та вміст тіла. Наприклад, Gatus може шукати фразу "Add to cart" на сторінці кошика — якщо її немає, сайт зламаний.

Інструменти та вибір рішення

SaaS (без інфраструктури):

• UptimeRobot — безкоштовно до 50 моніторів, інтервал 5 хв. Платно — 1 хв.
• Better Uptime — агрегує безліч локацій, статус-сторінка, on-call scheduling. Вартість від $20/міс.
• Pingdom — Enterprise-рівень, RUM, API-моніторинг. Вартість від $100/міс.
• StatusCake — хороше співвідношення ціна/якість.

Self-hosted:

• Uptime Kuma — Docker, веб-інтерфейс, підтримка багатьох типів перевірок.
• Gatus — конфігурація через YAML, Kubernetes-friendly.
• Blackbox Exporter + Prometheus + Grafana — для тих, у кого вже є Prometheus.

Self-hosted рішення економлять до 3000 грн/міс на підписках порівняно з SaaS, якщо у вас більше 50 моніторів. Self-hosted рішення в 2-3 рази дешевше за SaaS при кількості моніторів понад 50. Наприклад, Uptime Kuma потребує лише сервера від $5/міс.

Порівняння Uptime Kuma та Gatus: Uptime Kuma простіше в розгортанні, ніж Gatus, і не потребує знань PromQL. Gatus дає більше гнучкості в умовах перевірок і легко інтегрується з CI/CD. Для 10–20 ендпоінтів обох рішень достатньо. Ми використовуємо Kuma для швидких інсталяцій, Gatus — для складних проєктів з мікросервісами. Gatus у 3 рази швидше працює з великою кількістю ендпоінтів завдяки оптимізованому планувальнику.

Розгортання та налаштування

Розгортання Uptime Kuma через Docker:

# docker-compose.yml services: uptime-kuma: image: louislam/uptime-kuma:latest restart: unless-stopped ports: - "3001:3001" volumes: - ./uptime-kuma-data:/app/data 

Після запуску перейдіть на http://localhost:3001 і створіть першого користувача. Uptime Kuma готовий до налаштування моніторів.

Конфігурація Gatus (декларативний моніторинг):

# gatus/config.yaml endpoints: - name: Main Site url: https://httpbin.org/get interval: 1m conditions: - "[STATUS] == 200" - "[RESPONSE_TIME] < 2000" - "[CERTIFICATE_EXPIRATION] > 168h" # > 7 днів до закінчення - name: API Health url: https://httpbin.org/status/200 interval: 30s conditions: - "[STATUS] == 200" - "[BODY].status == UP" - "[RESPONSE_TIME] < 500" - name: Checkout Flow url: https://httpbin.org/get interval: 5m conditions: - "[STATUS] == 200" - "[BODY] pat *Add to cart*" alerting: telegram: token: $TELEGRAM_BOT_TOKEN id: $TELEGRAM_CHAT_ID default-alert: enabled: true failure-threshold: 2 success-threshold: 1 

Gatus підтримує перевірки SSL-сертифікатів і часу відповіді, що робить його зручним для комплексного моніторингу.

Багаторегіональний моніторинг: Перевіряйте з кількох локацій. Інакше можете пропустити регіональний збій: наприклад, DDoS з одного провайдера не видно з іншого дата-центру. Better Uptime та Pingdom включають це в базовий план. Для self-hosted — кілька екземплярів Gatus у різних регіонах + центральний агрегатор.

Налаштування алертингу в Telegram:

# Простий webhook-обробник для алертів import requests import os def send_alert(message: str, is_recovery: bool = False): emoji = "✅" if is_recovery else "🚨" requests.post( f"https://api.telegram.org/bot{os.environ['BOT_TOKEN']}/sendMessage", json={ "chat_id": os.environ['CHAT_ID'], "text": f"{emoji} {message}", "parse_mode": "HTML", } ) 

Цей обробник можна викликати з будь-якого інструменту моніторингу. Для зменшення alert fatigue налаштовуйте retry logic з exponential backoff, щоб уникнути хибних тривог.

Планування моніторингу: що перевіряти та як часто

Порівняння інструментів:

Процес впровадження та реагування

Що входить у налаштування:

• Документація: конфігурації моніторингу, схема сповіщень, інструкція для чергового.
• Доступи до панелей моніторингу.
• Додавання команди в чат сповіщень.
• Навчання основам роботи з системою.
• Підтримка 2 тижні після впровадження.

Вартість налаштування — від 5000 грн, що значно менше середнього чека на відновлення після збою (до 50 000 грн).

Що робити при спрацюванні алерту?

Перш за все перевірте, чи не хибна тривога. Якщо сайт дійсно недоступний, вивчіть логи та метрики: можливо, проблема в коді, базі даних або хостингу. Ми рекомендуємо налаштувати escalation policy: якщо черговий не відповідає 5 хвилин, алерт переходить наступному. Проведіть post-mortem, щоб уникнути повторення інциденту.

Зв'яжіться з нами для консультації — підберемо рішення під ваш стек і бюджет. Замовте налаштування моніторингу і спіть спокійно. Отримайте демо-доступ до панелі з налаштованими алертами.

Середній чек на відновлення після збою без моніторингу може сягати 50 000 грн, а регулярний моніторинг коштує значно менше.

Посилання:

• Uptime Kuma
• Gatus