Menu
security

Uptime 101: как настроить базовый мониторинг и алерты для вашего сайта

Аптайм — не магия, а дисциплина. Его обеспечивают две вещи: наблюдаемость (вы видите, что происходит) и оповещения (вы узнаёте о проблеме раньше пользователя). Базовый мониторинг — это минимальный набор проверок и метрик, которые круглосуточно следят за сайтом и инфраструктурой и сигналят в нужный канал, когда что‑то идёт не так.

Цель статьи — дать практический, приземлённый план. Без перегруза терминологией, но с конкретными чек‑листами, примерами алертов и советами по порогам. Подходит для владельцев сайтов, техлидов небольших команд, разработчиков и DevOps‑инженеров, которые хотят «закрыть базу» за один вечер и спать спокойнее.

Как работает (минимальная теория)

Черный ящик vs белый ящик

  • Blackbox‑мониторинг — вы смотрите на систему снаружи, как пользователь: пинг, TCP/HTTP‑проверки, измерение времени ответа, валидность TLS‑сертификата, DNS. Это отвечает на вопрос: «Жив ли сайт с точки зрения клиента?»
  • Whitebox‑мониторинг — вы заглядываете внутрь: CPU/RAM/Disk/IO, сеть, количество открытых файлов, пул подключений БД, ошибки приложений, метрики веб‑сервера, очереди задач. Это отвечает на вопрос: «Почему стало плохо?»

Нужны оба подхода: чёрный ящик даёт быстрый сигнал, белый — контекст для устранения причин.

Метрики, логи, трассировки

  • Метрики — числа по времени (например, p95 времени ответа, процент ошибок 5xx, утилизация CPU). Они компактны и идеально подходят для алертов.
  • Логи — детали событий. Полезны для расследования инцидента (stack trace, IP клиента, путь запроса).
  • Трейсы — путь запроса через сервисы; помогают найти узкое место (БД, внешнее API).

Для старта достаточно метрик + логов. Трейсы можно добавить позже.

SLI, SLO и ошибка бюджета

  • SLI (Service Level Indicator) — измеряемая величина качества: доля успешных запросов, p95 латентности, аптайм за период.
  • SLO (Service Level Objective) — цель по SLI (например, «99,9% успехов и p95 < 300 мс за 30 дней»).
  • Ошибка бюджета — сколько «плохих» запросов/минут простоя можно «потратить» в периоде, не нарушив SLO. На его основе строится приоритет работ и агрессивность релизов.

Почему важно (и с чего начинать)

1) Вы узнаёте о проблеме раньше пользователей

Пуш‑алерт в минуту деградации дешевле, чем час потери конверсии, корзин и заявок. Простая HTTP‑проверка из нескольких регионов обнаружит падение быстрее, чем поток жалоб в поддержку.

2) Вы сокращаете MTTR

Среднее время восстановления (MTTR) падает, если алерт ведёт к понятному дашборду и плейбуку: «что проверить, где логи, как перезапустить, как откинуться снапшотом».

3) Вы перестаёте «бояться релизов»

Снабжённая алертами система безопаснее для экспериментов: видно, где болит, и есть обратимость.

4) Вы считаете экономику на фактах

С наблюдаемостью легко сравнить: «переезд на NVMe», «новый кэш», «оптимизация SQL» — что реально дало прирост и окупилось.

Что мониторить: базовый чек‑лист

A. Доступность и периметр

  1. DNS: запись A/AAAA/CNAME резолвится? TTL разумный? Есть ли аварийная NS?
  2. ICMP Ping: хост отвечает? Рост RTT/потери пакетов?
  3. TCP/порт: 80/443/ваши сервисные порты открыты и принимают соединения?
  4. HTTP/HTTPS: код ответа 2xx/3xx, время TTFB/p95, размер ответа, ключевые слова на странице (проверка контента).
  5. TLS‑сертификат: срок годности, цепочка, соответствие домену; алерт за 30/14/7 дней до истечения.
  6. WAF/DDoS‑щит: изменений правил нет? Нет ли блокировки легитимного трафика?

B. Приложение

  1. Error rate: доля 5xx/4xx (с фокусом на 5xx) > порога X% за N минут.
  2. Латентность: p95/p99 API или страницы — пороги по SLO (например, p95 < 300 мс).
  3. Критические эндпоинты: /healthz, /readyz, /login, /checkout, RPC/GraphQL‑методы.
  4. Очереди: глубина и возраст задач (email/SMS, фоновые джобы).
  5. Кеш: hit‑ratio ниже Y%? Пулы соединений к БД.

C. Инфраструктура (whitebox)

  1. CPU: утилизация, steal time (на виртуалках), нагрузка на ядро.
  2. RAM: свободно/кэшировано, page cache, OOM‑эвенты.
  3. Диск/FS: заполнение > 80–90%, inodes, IOPS/latency, separate том под логи/журналы.
  4. Сеть: ошибки/дропы, PPS, bandwidth, SYN backlog, ESTABLISHED/WAIT.
  5. Процессы: systemd‑юниты «упали»? Перезапустились?
  6. БД: репликация, задержки, долгие запросы, блокировки.

D. Зависимости

  1. Платёжные/почтовые/geo‑API: SLA провайдера, HTTP‑ошибки/таймауты.
  2. Объектное хранилище/CDN: латентность/ошибки на PUT/GET, egress.
  3. Очереди/кэши: доступность и рост задержек.

E. Бэк‑офис

  1. Бэкапы: свежесть, размер, контроль проверки восстановления.
  2. Снапшоты: по расписанию и перед релизами.
  3. Cron/планировщики: регулярность выполнения, ошибки в журнале.
  4. Аудит доступа: подозрительные логины, sudo, изменения правил фаервола.

Пороговые значения: как не утонуть в фальшивых тревогах

  1. Тишина ночью ≠ тишина днём. Настройте разные пороги для офф‑пика и пика (или используйте относительные пороги: «выше среднего на 50% в течение 10 минут»).
  2. Дедупликация и группировка. Один отказ БД не должен ронять 20 алертов от всех сервисов. Группируйте по корневой причине (root cause).
  3. Проверка с нескольких локаций. HTTP‑фолс‑позитив из‑за одного узла не должен будить дежурного. Требуйте 2/3 согласных проверок.
  4. Задержка оповещения (grace). 30–60 секунд перед «красной» тревогой фильтруют кратковременные «шумы».
  5. Maintenance‑окна. Правила «молчания» на время релизов и регламентных работ.
  6. Шаблоны сообщений. В алерте сразу ссылка на дашборд, последние деплои, плейбук с «первой помощью».

Каналы доставки алертов

  • Email — для не срочных уведомлений и отчётов (ежедневные/еженедельные дайджесты).
  • Мессенджеры (Slack/Telegram/Discord) — для оперативной команды: каналы #alerts, треды по инцидентам, реакции‑квитирования.
  • SMS/звонок — для критичных инцидентов вне рабочего времени (эскалации дежурному).
  • Вебхуки — интеграции с внешними системами (дашборды статуса, тикет‑системы, CI/CD).

Настройте эскалации: если нет подтверждения алерта за N минут — дойдёт до следующего уровня. Это защищает от «залипания» тревог.

Практика: базовый стек наблюдаемости

Ниже — один из минимальных, но рабочих наборов инструментов на открытом ПО.

  1. Node Exporter — отдает системные метрики (CPU/RAM/Disk/Net).
  2. Blackbox Exporter — пинг/TCP/HTTP‑проверки снаружи (поддержка TLS‑проверок, ключевых слов).
  3. Prometheus — собирает метрики по pull‑модели, хранит временные ряды.
  4. Alertmanager — правила алертов, маршрутизация, дедупликация, эскалации.
  5. Grafana — дашборды для визуализации, аннотации релизов.
  6. Filebeat/Vector + ELK/Opensearch — сбор и поиск логов.
  7. Healthcheck‑эндпоинты — /healthz (жизнь), /readyz (готовность обслуживать трафик), /metrics (whitebox‑метрики приложения).

Пример правила алерта (Prometheus Alerting):

Шаблон (заполните под свой сервис): — Название: HighErrorRate — Условие: «доля ответов 5xx за последние 5 минут > 5% по агрегату service» — Окно удержания: 10 минут (для защиты от всплесков) — Метки/критичность: severity = critical — Текст уведомления: {{service}}: 5xx > 5% (10m) — Runbook: ссылка на вашу страницу «как расследовать высокий error rate»

Как проверить: откройте график доли 5xx по сервисам за 1–7 дней и подберите порог, при котором шум минимален, а инциденты ловятся вовремя.

Пример проверки TLS‑сертификата (Blackbox):

Параметры проверки: — Протокол: HTTPS с ожиданием кода 2xx — Таймаут запроса: 10 секунд — Версии HTTP: HTTP/1.1 и HTTP/2 допускаются — Проверка цепочки TLS: включена (сертификат не должен быть просрочен и должен соответствовать домену)

Практика: настройте три внешние точки мониторинга в разных регионах и включите отдельный алерт за 30/14/7 дней до истечения сертификата.

Пример алерта на свободное место на диске:

Шаблон правила: — Название: LowDiskSpace — Условие: «свободное место на файловой системе < 10%» (исключая tmpfs/devtmpfs) — Окно удержания: 15 минут (исключить кратковременные пики) — Критичность: warning (поднимите до critical при <5%) — Сообщение: INSTANCE: осталось <10% диска — очистите логи/артефакты или увеличьте том — Подсказка: проверьте ротацию логов, размер кешей, вынесите артефакты в объектное хранилище

Пошаговый план за вечер

Шаг 1. Определите SLO. Например: «аптайм 99,9% в 30 дней; p95 < 300 мс; 5xx < 1%».

Шаг 2. Выберите точки проверки. 3–5 географий (Европа/США/Азия), по одной на каждый ключевой эндпоинт (главная, логин, checkout, API‑метод).

Шаг 3. Поднимите Healthchecks. Добавьте /healthz и /readyz в приложение; проверка должна зависеть от БД/кэша, если без них сервис не работает.

Шаг 4. Разверните стек. Prometheus + Node/Blackbox Exporter, Grafana, Alertmanager. Импортируйте готовые дашборды.

Шаг 5. Напишите 10 ключевых алертов. Доступность HTTP, истечение TLS, 5xx>1–5%, p95>порога, CPU>85% 10м, RAM<15% свободно, диск<15%, БД‑репликация/лаг, очередь задач, рост ошибок в логах.

Шаг 6. Настройте каналы и эскалации. Slack/Telegram + Email + SMS для «красных». Добавьте «тихие часы» и окна техработ.

Шаг 7. Сделайте страницу статуса. Внешний статус (public) + внутренний (детально для команды). Автоматические обновления от Alertmanager.

Шаг 8. Проведите «игру хаоса». Искусственно уроните зависимость (например, выключите кэш) — проверьте, что алерты пришли и плейбук понятен.

Шаг 9. Заведите плейбуки. Для каждого алерта — 5–10 шагов диагностики и решения + контакты ответственных.

Шаг 10. Пересматривайте пороги раз в месяц. На основе реальных графиков и инцидентов.

Типовые ошибки

  • Слишком много алертов. Слабые сигналы забивают сильные. Держите компактный набор «красных» и «жёлтых» правил; остальное — отчёты.
  • Алерты без контекста. Всегда прикладывайте ссылку на дашборд и плейбук. «CPU высок» без графика — бесполезно.
  • Нет проверки контента. HTTP 200 не гарантирует, что рендерится правильная страница. Ищите ключевое слово/паттерн.
  • Один регион мониторинга. Сетевая «ямка» в одном ЦОДе даст фальшивые срабатывания. Нужны независимые точки.
  • Всё в одном VPS. Мониторинг лучше держать отдельно от приложения, иначе «всё упало — никто не видел».
  • Без DR и бэкапов. Бэкап, который вы не восстанавливали, — не бэкап. Тестируйте восстановление.

Почему Unihost облегчает жизнь с аптаймом

Сеть и инфраструктура. Низкая p95‑латентность благодаря пирингам, DDoS‑фильтрация, приватные VLAN, IPv4/IPv6, предсказуемый uplink. Это уменьшает шанс ложных тревог и упрощает изоляцию prod/stage/dev.

Хранилище. Быстрые NVMe Gen4/Gen5 для БД/индексов и логов: стабильные IOPS = меньше «микро‑инцидентов».

Платформа. Поддержка IaC (Terraform/Ansible), снапшоты/бэкапы по политике, интеграции с Prometheus/Grafana/ELK/OTel.

Сопровождение. 24/7 мониторинг площадок, SLA по реакции и аптайму; помощь инженеров в тюнинге ядра/сети/БД и настройке healthcheck‑эндпоинтов.

Масштабирование. Стартуйте на VPS, переходите на выделенные серверы и GPU‑узлы без смены провайдера и с минимальными перестройками — мониторинг переедет вместе с IaC.

Короткий шаблон запуска (TL;DR)

  • Blackbox: HTTP/HTTPS из 3 локаций, TLS‑expiry, DNS.
  • Whitebox: Node Exporter + метрики приложений /metrics.
  • Алерты: 5xx, p95, CPU/RAM/Disk, TLS, БД, очередь.
  • Каналы: Slack/Telegram + Email + SMS для критичных.
  • Плейбуки и страница статуса.
  • Ежемесячный разбор инцидентов и корректировка порогов.

Заключение и CTA

Базовый мониторинг — это не роскошь и не «ещё один проект». Это страховка вашего дохода и репутации. Начните сегодня: добавьте healthchecks, поднимите метрики, соберите первые алерты и подключите каналы. Через неделю у вас будет первая статистика, через месяц — уверенность, что сайт переживёт пик, релиз и каприз внешнего API.

Unihost помогает пройти путь быстро и без боли: подобрать конфигурации (VPS или выделенные сервера), настроить сеть и хранилище, включить наблюдаемость и алерты, автоматизировать снапшоты/бэкапы и подготовить DR‑план.

Попробуйте серверы Unihost — стабильная инфраструктура для ваших проектов.
Закажите VPS или выделенный сервер на Unihost и поднимите аптайм на новый уровень — с метриками, алертами и понятной эксплуатацией.