Мониторинг доступности сайта: настройка непрерывного Uptime Monitoring

Мониторинг работоспособности сайта (Uptime Monitoring)

Отметим: когда ваш сайт лежит, а вы узнаёте об этом от клиента — это катастрофа. Мы настраиваем системы мониторинга, которые оповещают о сбое за минуту. 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
• Pingdom — Enterprise-уровень, RUM, API-мониторинг
• StatusCake — хорошее соотношение цена/качество

Self-hosted:

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

Self-hosted решения экономят до 3000 руб/мес на подписках по сравнению с SaaS, если у вас более 50 мониторов.

Как выбрать между Uptime Kuma и Gatus?

Uptime Kuma проще в развертывании, чем Prometheus + Grafana, и не требует знаний PromQL. Gatus даёт больше гибкости в условиях проверок и легко интегрируется с CI/CD. Для 10–20 эндпоинтов обоих решений достаточно. Мы используем Kuma для быстрых инсталляций, Gatus — для сложных проектов с микросервисами.

Развёртывание 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://mysite.com
    interval: 1m
    conditions:
      - "[STATUS] == 200"
      - "[RESPONSE_TIME] < 2000"
      - "[CERTIFICATE_EXPIRATION] > 168h"  # > 7 дней до истечения

  - name: API Health
    url: https://api.mysite.com/health
    interval: 30s
    conditions:
      - "[STATUS] == 200"
      - "[BODY].status == UP"
      - "[RESPONSE_TIME] < 500"

  - name: Checkout Flow
    url: https://mysite.com/cart
    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",
        }
    )

Этот обработчик можно вызывать из любого инструмента мониторинга.

Что мониторить в первую очередь

Сравнение инструментов

Uptime Kuma проще в настройке, чем Gatus, но Gatus в 3 раза быстрее работает с большим количеством эндпоинтов благодаря оптимизированному планировщику.

Что входит в настройку

Документация: конфигурации мониторинга, схема оповещений, инструкция для дежурного. Мы передаём доступы к панелям, добавляем команду в чат оповещений, обучаем основам. Поддержка 2 недели после внедрения.

Что делать при срабатывании алерта?

Первым делом проверьте, не ложная ли тревога. Если сайт действительно недоступен, изучите логи и метрики: возможно, проблема в коде, базе данных или хостинге. Мы рекомендуем настроить escalation policy: если дежурный не отвечает 5 минут, алерт переходит следующему.

Свяжитесь с нами для консультации — подберём решение под ваш стек и бюджет. Закажите настройку мониторинга и спите спокойно. Получите демо-доступ к панели с настроенными алертами.

Средний чек на восстановление после сбоя без мониторинга может достигать 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, ограничение прав файловой системы). Восстановление из бэкапа занимает часы, а не дни — если бэкапы настроены правильно. Средние затраты на ликвидацию последствий взлома — 150 000–300 000 ₽, включая аудит и закрытие уязвимостей. Регулярная поддержка обходится значительно дешевле и предотвращает такие инциденты.

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

Что входит в пакет поддержки (deliverables)

При заключении договора вы получаете:

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

Свяжитесь с нами, чтобы подобрать подходящий план и получить первичный аудит состояния вашего проекта.

Как мы работаем: этапы

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

Мы работаем с 2016 года, поддерживаем более 50 проектов от лендингов до маркетплейсов. Наши клиенты экономят от 50 000 ₽ в месяц за счёт превентивных мер.

Сроки и стоимость

Настройка мониторинга и бэкапов: 3–5 дней. Регулярная поддержка — ongoing контракт с фиксированным объёмом часов в месяц или абонемент. Стоимость рассчитывается индивидуально после аудита. Получите консультацию — оценим ваш проект за 1–2 дня.

Сравнение: мониторинг с автоматическим алертингом vs ручная проверка

Автоматический мониторинг Better Uptime в 10 раз быстрее реагирует на сбои, чем ручная проверка.