Мониторинг простого PHP-сайта: что контролировать без сложной инфраструктуры

Небольшой PHP-сайт часто живёт без мониторинга: пока клиент сам не написал, что форма не работает или сайт не открывается. Это плохой режим поддержки. Даже без сложной инфраструктуры можно контролировать базовые вещи: доступность сайта, SSL, место на диске, ошибки PHP, cron, базу, очередь и отправку заявок.

Мониторинг должен отвечать на вопрос: сайт работает для пользователя и выполняет свои ключевые функции?

Доступность сайта

Самая простая проверка — HTTP-код главной и важных страниц.

curl -I https://example.ru/
curl -I https://example.ru/contacts/
curl -I https://example.ru/catalog/

Для автоматического контроля можно использовать внешний uptime-сервис. Важно проверять не только главную, потому что она может открываться из кэша, а форма или каталог уже сломаны.

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

Просроченный SSL сразу бьёт по доверию и заявкам. Нужно контролировать срок действия сертификата.

echo | openssl s_client -servername example.ru -connect example.ru:443 2>/dev/null \
    | openssl x509 -noout -dates

Если используется автоматическое обновление, всё равно нужно проверять, что оно реально срабатывает.

Свободное место

Заполненный диск ломает сессии, кэш, логи, загрузки и базу.

df -h

Желательно получать предупреждение заранее, например при заполнении 80-85%, а не когда осталось 0 байт.

Ошибки PHP и nginx

Если error.log быстро растёт, сайт может формально открываться, но внутри уже есть проблема.

tail -n 50 /var/log/nginx/error.log
tail -n 50 /var/log/php-fpm/error.log
tail -n 50 /var/www/site.ru/runtime/logs/app.log

Для простого контроля можно считать количество свежих error-записей за период и отправлять уведомление при росте.

MySQL

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

mysqladmin ping
mysql -e "SHOW FULL PROCESSLIST;"

Если сайт зависит от MySQL, падение базы должно обнаруживаться раньше, чем пользователь отправит жалобу.

Cron и фоновые задачи

Cron может перестать выполняться молча. Каждая важная задача должна писать лог старта и завершения.

tail -n 100 /var/www/site.ru/runtime/logs/cron.log

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

last_success_at = 2026-06-18 09:00:00

Очереди

Если проект использует queue, нужно следить за размером очереди и failed jobs. Очередь может расти, даже если сайт открывается нормально.

SELECT COUNT(*) FROM queue WHERE status = 'waiting';
SELECT COUNT(*) FROM queue WHERE status = 'failed';

Названия таблиц и статусов зависят от реализации, но смысл один: очередь должна обрабатываться.

Формы и почта

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

1. Открыть страницу формы.
2. Отправить тестовую заявку.
3. Проверить запись в базе или CRM.
4. Проверить письмо менеджеру.
5. Проверить лог ошибок.

Уведомления

Мониторинг без уведомления бесполезен. Сообщение должно приходить туда, где его увидят: email, Telegram, Slack, SMS или система задач.

Не нужно уведомлять о каждом warning. Иначе уведомления начнут игнорировать. Лучше выделить критичные события: сайт недоступен, SSL скоро истечёт, диск заполнен, cron не запускался, очередь растёт.

Чек-лист

1. Проверять главную и важные внутренние страницы.
2. Контролировать срок SSL.
3. Контролировать свободное место на диске.
4. Следить за PHP и nginx error logs.
5. Проверять доступность MySQL.
6. Контролировать последний успешный запуск cron.
7. Следить за очередью и failed jobs.
8. Проверять полный путь заявки.
9. Настроить понятные уведомления.

Базовый мониторинг не обязан быть сложным. Даже несколько простых проверок уже переводят поддержку из режима “клиент сообщил о поломке” в режим раннего обнаружения проблем.