Сайт может упасть в 3 часа ночи. Или замедлиться настолько, что посетители уходят, не дождавшись загрузки. Или SSL-сертификат истечёт в пятницу вечером. Без мониторинга вы узнаете об этом от клиентов. Или не узнаете вообще — потому что клиенты просто уйдут.

Мониторинг — это не «посмотреть, работает ли». Это система раннего обнаружения проблем. Расскажу, что и как отслеживаю в рамках техподдержки сайтов.

Зачем мониторинг нужен

Раннее обнаружение

Проблемы начинаются задолго до того, как сайт падает. Сначала растёт время ответа — с 200 мс до 500, потом до 2 секунд. Потом PHP начинает выжирать память. Потом сервер уходит в своп. Потом — 503 и тишина.

Мониторинг ловит проблему на первом этапе — когда исправление занимает минуты, а не часы.

Данные для решений

Без метрик техподдержка работает вслепую. «Сайт медленный» — а где именно? Главная? Каталог? Поиск? Для всех или для мобильных? В какое время суток?

Мониторинг даёт конкретику: какая страница, какой ответ сервера, с какого момента ухудшилась производительность.

Доказательная база

Хостинг утверждает, что проблема на вашей стороне. Вы утверждаете, что на их. Без мониторинга это спор ни о чём. С мониторингом — у вас графики: вот время ответа, вот момент начала проблемы, вот корреляция с обновлением на сервере.

Что мониторить: обязательный набор

1. Доступность (uptime)

Самое базовое: работает ли сайт. Проверка HTTP-запросом каждые 60 секунд. Если два запроса подряд не получили ответ 200 — алерт.

Что считать «недоступностью»:

  • HTTP 5xx (ошибки сервера)
  • Таймаут (нет ответа больше 10 секунд)
  • Некорректный контент (страница отдаёт 200, но содержит текст ошибки)

Последний пункт важен: сайт может отвечать «200 OK», но показывать пустую страницу или ошибку PHP. Простой пинг этого не поймает — нужна проверка содержимого.

2. Время ответа сервера (TTFB)

Time To First Byte — сколько времени сервер думает, прежде чем начать отдавать страницу. Норма — до 200 мс для кешированных страниц, до 500 мс для динамических.

Если TTFB растёт:

  • Проблема с базой данных (медленные запросы)
  • Нехватка памяти или CPU на сервере
  • Тяжёлые плагины, которые выполняются при каждом запросе
  • Проблемы с хостингом

Слежу за трендом: если TTFB стабильно растёт — ищу причину, не дожидаясь, пока пользователи заметят.

3. SSL-сертификат

Истёкший SSL — это:

  • Предупреждение «Небезопасный сайт» в браузере (посетители уходят)
  • Потеря позиций в поиске (Google помечает как небезопасный)
  • Проблемы с приёмом платежей (если интернет-магазин)

Let’s Encrypt обновляется автоматически, но автоматика ломается. Cron-задача не сработала, DNS изменился, директория .well-known заблокирована — и сертификат не обновился.

Мониторю: срок действия, цепочку сертификатов, корректность конфигурации.

4. Место на диске

Заполненный диск — тихий убийца. Когда на сервере кончается место:

  • База данных перестаёт записывать
  • Логи не пишутся (а значит, не видно ошибок)
  • Сессии не создаются (пользователи не могут залогиниться)
  • Бэкапы не создаются

Причины заполнения: растущие логи, забытые бэкапы на том же сервере, кеш, временные файлы, загруженные пользователями изображения.

Алерт при заполнении на 80% — есть время среагировать.

5. Ошибки в логах

PHP warnings и notices — не страшно (хотя и нехорошо). PHP fatal errors и 500-е — это проблема.

Что ищу:

  • Fatal error — код упал, страница не отобразилась
  • Memory exhausted — скрипту не хватило памяти
  • Database connection error — БД недоступна
  • Permission denied — проблемы с правами
  • Too many connections — БД перегружена

Логи — первое, куда смотрю при диагностике. Если мониторинг ловит всплеск ошибок — ищу причину, даже если сайт визуально работает.

Продвинутый мониторинг

6. Core Web Vitals

Метрики Google для оценки пользовательского опыта:

  • LCP (Largest Contentful Paint) — время загрузки основного контента. Норма: до 2.5 сек.
  • INP (Interaction to Next Paint) — отзывчивость на действия пользователя. Норма: до 200 мс.
  • CLS (Cumulative Layout Shift) — визуальная стабильность. Норма: до 0.1.

Эти метрики влияют на позиции в Google. Слежу за ними в динамике — если LCP вырос после обновления плагина, нужно разбираться.

7. Мониторинг безопасности

Отслеживаю подозрительную активность:

  • Всплеск запросов к wp-login.php (брутфорс)
  • Попытки SQL-инъекций в URL
  • Новые файлы в нетипичных директориях
  • Изменения в файлах ядра CMS

Подробнее — в статье как защитить сайт от взлома и на странице защиты сайта.

8. Мониторинг бэкапов

Бэкап-система может тихо сломаться: скрипт упал, хранилище заполнилось, токен доступа протух. Если не мониторить — обнаружите это в момент, когда бэкап жизненно нужен.

Проверяю:

  • Бэкап создался вовремя
  • Размер бэкапа в пределах нормы (если резко уменьшился — значит, что-то не попало)
  • Бэкап загрузился на внешнее хранилище

9. Мониторинг третьих сторон

Сайт может работать, а платёжный виджет — нет. Или CDN лежит. Или API CRM не отвечает.

Отслеживаю доступность критичных внешних сервисов, от которых зависит функциональность сайта.

Инструменты мониторинга

Бесплатные

  • UptimeRobot — мониторинг доступности, 50 сайтов бесплатно. Проверки каждые 5 минут.
  • Google Search Console — ошибки индексации, Core Web Vitals.
  • Яндекс.Вебмастер — аналогично для Яндекса.

Платные

  • BetterUptime — доступность + статус-страницы + алерты. От $20/мес.
  • New Relic — глубокий APM (мониторинг производительности приложения). Бесплатный тариф для одного хоста.
  • Datadog — всё в одном: серверы, приложения, логи, безопасность. Дорого, но мощно.

Серверные

  • Netdata — красивые дашборды прямо на сервере. Бесплатно.
  • Grafana + Prometheus — гибкая система с кастомными метриками.
  • Monit — лёгкий мониторинг процессов и ресурсов.

Для большинства клиентских сайтов достаточно UptimeRobot + серверный мониторинг + логи. Для крупных проектов — Grafana или Datadog.

Алерты: кому и когда

Мониторинг бесполезен, если алерты уходят в пустоту. Настраиваю эскалацию:

  1. Telegram/Email — первое уведомление. Для некритичных проблем.
  2. SMS/звонок — если проблема не решена за 15 минут или это критичный инцидент.
  3. Эскалация — если не отреагировал я, уведомление уходит клиенту (по желанию).

Ночью — только критичные алерты (сайт упал, взлом). Предупреждения о месте на диске подождут до утра.

Мониторинг vs «проверю сам»

Иногда клиенты говорят: «Я сам захожу на сайт каждый день — зачем мне мониторинг?»

Вот почему:

  • Вы не проверяете сайт в 3 часа ночи
  • Вы не замечаете, что страница грузится на секунду дольше
  • Вы не видите 500-ю ошибку на странице, которую не открываете
  • Вы не знаете, что SSL истечёт через 3 дня
  • Вы не смотрите логи

Мониторинг работает 24/7/365. Без выходных, без перерывов, без «забыл проверить».

Итого

Мониторинг — фундамент осмысленной техподдержки. Без него поддержка реактивна: сломалось → чиним. С мониторингом — проактивна: заметили ухудшение → предотвратили поломку.

Минимальный набор:

  • Доступность каждые 60 сек
  • TTFB и время загрузки
  • SSL-сертификат
  • Место на диске
  • Ошибки в логах

Мониторинг входит во все мои тарифы техподдержки. Настраиваю, слежу, реагирую — чтобы вы спали спокойно.

Автор материала

Антон Ветров Разработка сайтов, поисковая доступность, автоматизация и эксплуатация.