Моніторинг доступності сайту: налаштування 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

Технічна підтримка сайту: оновлення, моніторинг, SLA

Сайт на Laravel 8 з PHP 7.4. PHP 7.4 більше не підтримується, Laravel 8 — теж не отримує оновлень безпеки. Хостинг-провайдер попередив про обов'язкове оновлення PHP до 8.1 — після оновлення два плагіни та одна бібліотека зламалися, сайт упав. Ми регулярно стикаємося з такими сценаріями: проект без регулярного ТО перетворює кожне оновлення середовища на аварію.

Цей кейс — не виняток, а правило. Комерційні сайти втрачають конверсію через повільне завантаження, вразливості, недоступність. Ми беремо на себе моніторинг, оновлення залежностей, бекапи та SLA — щоб ви займалися бізнесом, а не сервером.

Без системної підтримки кожне оновлення середовища стає сюрпризом: ламаються залежності, падає продуктивність, з'являються діри безпеки. Технічна підтримка сайту — це страховка від таких сюрпризів та гарантія стабільної роботи.

Що реально входить у технічну підтримку сайту?

Підтримка — не «відповісти на дзвінок, коли щось зламалося». Це систематичне запобігання поломкам.

Оновлення залежностей. Composer packages, npm packages, CMS або фреймворк. composer audit та npm audit показують відомі вразливості. Dependabot або Renovate створюють автоматичні PR — завдання підтримки перевірити, що оновлення не зламало staging, і змержити.

Оновлення бувають: patch (1.2.3 → 1.2.4, тільки bugfix, безпечно), minor (1.2.0 → 1.3.0, нові фічі зі зворотною сумісністю, зазвичай безпечно), major (1.x → 2.x, ламаючі зміни, вимагають тестування). Ігнорувати оновлення 6+ місяців — накопичити техборг: розрив більший, роботи більше.

WordPress — окрема розмова. Популярність платформи робить її головною ціллю атак. Застарілі плагіни — вектор №1 зломів. Регулярні оновлення ядра, плагінів, тем + правильні дозволи файлової системи + WAF — необхідний мінімум. Наш досвід показує, що автоматичні оновлення WordPress Core без тестового середовища — ризик, який ми не допускаємо.

Як моніторинг запобігає простоям?

Uptime моніторинг. Базовий HTTP-чек раз на хвилину. Better Uptime, Upptime (self-hosted), Checkly, New Relic Synthetics. Алерт у Telegram або Slack при падінні — і сповіщення при відновленні. Якщо сайт недоступний 10 хвилин у робочий час — прямий збиток.

Продуктивність. TTFB, LCP, INP — відстежуємо через Google Search Console (реальні користувачі, CrUX) та синтетичний моніторинг (Lighthouse CI, SpeedCurve). Деградація часто поступова — без моніторингу ви помічаєте через місяць, коли LCP вже 5s.

Помилки додатку. Sentry — стандарт для відстеження JavaScript та PHP/Python помилок у реальному часі. Кожен необроблений виняток із трасуванням стеку, контекстом запиту, версією браузера. Особливо важливо для помилок, які користувачі не повідомляють — вони просто йдуть.

База даних. Зростання об'єму, повільні запити (MySQL slow query log, pg_stat_statements для PostgreSQL), розмір індексів. Таблиця без VACUUM у PostgreSQL розростається до гігабайт через dead tuples. Рутинне обслуговування БД — частина підтримки.

Дисковий простір та логи. logrotate налаштований? /var/log/nginx росте без обмежень і заповнює диск — класика. Автоматична ротація + алерт при disk > 80%.

Чому бекапи без перевірки — ілюзія?

Бекап без перевірки відновлення — не бекап, а ілюзія безпеки. Бачили випадки, коли mysqldump створював файл 0 байт через помилку прав, а ніхто не перевіряв вміст місяцями. Ми гарантуємо, що всі копії працездатні.

Схема бекапів:

• Щоденний інкрементальний бекап бази даних + медіафайли
• Щотижневий повний бекап
• Зберігання: мінімум 3 копії, 2 різних медіа, 1 offsite (S3, Backblaze B2)
• Автоматична перевірка цілісності (pg_restore --list, mysqldump verify)
• Тестове відновлення раз на квартал в ізольоване середовище

Retention політика: 7 щоденних, 4 щотижневих, 3 щомісячних. S3 Lifecycle rules автоматизують видалення.

SLA: що це означає на практиці

SLA (Service-Level Agreement) Wikipedia — конкретні зобов'язання щодо часу реакції та відновлення:

SLA має сенс тільки за наявності моніторингу — інакше про проблеми дізнаються від користувачів, а не від систем. Неробоча кнопка у формі може непомітно вбивати конверсію тижнями.

Процес оновлення контенту

Розробник не повинен бути в ланцюжку для правки тексту на сторінці. CMS зі зручним редактором, розмежування прав (редактор править контент, не чіпає код), історія змін. Для Laravel-проектів — Nova, Filament, або headless CMS (Strapi, Contentful) залежно від складності.

Preview перед публікацією, staged rollout для важливих змін. Якщо редактори працюють напряму з prod — це ризик.

Типові ситуації, які вирішуємо

Злом сайту: аналіз вектора атаки, очищення, посилення безпеки (WAF, fail2ban, обмеження прав файлової системи). Відновлення з бекапу займає години, а не дні — якщо бекапи налаштовані правильно. Регулярна підтримка запобігає таким інцидентам.

Падіння продуктивності після оновлення: feature flag + можливість швидкого rollback. Canary деплой — оновлюємо 5% трафіку, дивимось метрики, потім 100%.

Що входить у пакет підтримки (deliverables)

При укладенні договору ви отримуєте:

• Документація: схема інфраструктури, доступи, процедури відновлення
• Моніторинг: uptime, продуктивність, помилки, логи — налаштований з першого дня
• Резервне копіювання: щоденні/щотижневі копії з перевіркою
• Оновлення залежностей: щомісячний аудит та оновлення з тестуванням
• SLA-реагування: за пріоритетами з таблиці вище
• Звіти: щотижневі дашборди, щомісячний огляд, квартальний техплан
• Підтримка редагування контенту: навчання редакторів, налаштування прав

Зв'яжіться з нами, щоб підібрати відповідний план та отримати первинний аудит стану вашого проекту.

Як ми працюємо: етапи

1. Онбординг (3–5 днів): аудит поточного стану, налаштування моніторингу та бекапів, документування інфраструктури.
2. Регулярний ритм: щотижневий звіт за метриками, щомісячний огляд оновлень, квартальний технічний аудит.
3. Реагування: за SLA, з фіксацією причини та часу вирішення.
4. Розвиток: за вашим запитом — новий функціонал, оптимізація, рефакторинг.

Ми працюємо з 2016 року, підтримуємо понад 50 проектів від лендінгів до маркетплейсів.

Строки та вартість

Налаштування моніторингу та бекапів: 3–5 днів. Регулярна підтримка — ongoing контракт з фіксованим об'ємом годин на місяць або абонемент. Вартість розраховується індивідуально після аудиту. Отримайте консультацію — оцінимо ваш проект за 1–2 дні.

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

Автоматичний моніторинг Better Uptime в 10 разів швидше реагує на збої, ніж ручна перевірка.