Мониторинг сайта: что проверять автоматически, чтобы узнать о сбое раньше клиента

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

При этом одного запроса к главной странице недостаточно. Сайт может отвечать кодом 200, но не работать по существу: база недоступна, корзина падает, закончился диск или SSL-сертификат скоро истечёт.

Минимум: доступность по HTTP

Самый простой контроль — регулярно открывать сайт с внешнего сервера и проверять HTTP-код и время ответа. Такая проверка показывает, доступен ли домен из интернета и отвечает ли веб-сервер.

Лучше контролировать не только главную, но и одну-две типовые динамические страницы. Тогда кешированная главная не будет скрывать проблему приложения.

Что ещё стоит контролировать

• срок действия SSL-сертификата;
• свободное место и inode на диске;
• использование памяти и CPU;
• статус Nginx, PHP-FPM и базы данных;
• время ответа ключевых страниц;
• работу cron и фоновых заданий;
• ошибки в логах и необычный рост их количества.

Мониторинг бизнес-функций

Для важных проектов полезны синтетические проверки: открыть каталог, отправить тестовую форму, проверить ответ API или убедиться, что обмен обновлялся не позднее заданного времени. Это уже не просто контроль сервера, а проверка того, что бизнес-сценарий действительно работает.

Алерт должен быть полезным

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

Что должно быть в уведомлении

• какой сайт или сервис затронут;
• время начала проблемы;
• что именно не прошло проверку;
• HTTP-код или измеренное значение;
• ссылка на график или журнал, если он есть.

Сообщение «сайт упал» менее полезно, чем «главная отвечает 504 более трёх минут, время ответа выросло с 0,4 до 30 секунд».

Следите за трендом, а не только аварией

История метрик помогает замечать постепенные проблемы: диск заполняется по 2 ГБ в день, время ответа растёт после каждой выгрузки, память стабильно заканчивается вечером. Такой тренд позволяет исправить причину до полной недоступности.

Хороший мониторинг не заменяет поддержку, но даёт ей главное преимущество — время на реакцию до жалобы пользователя.

Практический набор для небольшого проекта

1. HTTP-проверка сайта раз в несколько минут.
2. Контроль SSL и DNS.
3. Алерты по диску, памяти и нагрузке.
4. Проверка статуса основных сервисов.
5. Контроль выполнения критичных cron-задач.
6. Периодический тест ключевой формы или сценария.

Когда мониторинг сообщает о недоступности, дальнейшая диагностика зависит от уровня сбоя. Базовый порядок проверки собран в статье «Сайт не открывается: DNS, сервер, SSL или код».

Настройка мониторинга и реакции на инциденты может входить в техническую поддержку сайта.