Мониторинг PHP-сайта и uptime

Мониторинг uptime проверяет, что сайт отвечает, пока об этом не написали пользователи в мессенджер. Для PHP-скрипта на VDS это обязательный минимум: HTTP-проверка главной и пары ключевых URL, алерт в Telegram/почту, плюс взгляд на диск и SSL.

Это не APM уровня «трейс каждого SQL». Сначала узнайте, что сайт лежит. Потом уже лезьте в логи.

Что мониторить

• HTTP 200 на главной.
• Страница логина / админки (без брутфорса — просто доступность).
• Время ответа: если вместо 0.5s стало 30s — тоже сигнал.
• Срок SSL-сертификата.
• Место на диске и inode на VDS.
• Процесс php-fpm / mysql — если есть agent на сервере.

Внешний ping с двух регионов ловит «у провайдера легло». Локальный cron на самой машине не заметит полный даун сети.

Простые инструменты

UptimeRobot, Healthchecks, свой cron с curl на другой VPS — всё годится. Главное: алерт туда, куда смотрите. Письмо на ящик, который не читаете — бесполезно.

curl -fsS -o /dev/null -w "%{http_code}" https://example.com/

Код не 200 — уведомление. Не проверяйте URL, который тяжёлый и бьёт по БД каждую минуту без нужды; главной достаточно часто.

Ложные срабатывания

Короткий глюк сети у чекера ≠ падение сайта. Имеет смысл подтверждение: две проверки подряд или второй узел. Техработы с ответом 503 лучше заранее исключать из алертов, если отдаёте корректный код обслуживания.

Базовая auth на админке заставит чекер получать 401 — либо не мониторьте админку снаружи, либо отдавайте отдельный health URL.

Диск и логи

Сайт «лежит», а HTTP 200 — бывает, когда диск 100% и пишутся ошибки, но кэш главной ещё отдаётся. Мониторьте df -h и inode. Ротация логов nginx/php-fpm обязательна. Заваленные бэкапы на том же диске — частая причина внезапного filled disk: бэкап.

SSL и домены

Просроченный сертификат ломает оплату и часть API. Алерт за 14 дней до expiry. Выпуск и продление: SSL. После смены DNS мониторьте уже новый IP.

Связь с инцидентами скрипта

Uptime зелёный, а «форма не шлёт письма» — мониторинг HTTP это не поймает. Тут логи приложения и cron: cron. 500 на внутренней странице при живой главной — добавьте второй URL в проверку.

Разбор падений PHP: ошибка 500, БД: MySQL. Серверная база: VDS, firewall (иногда после неудачного ufw «сайт недоступен» — и это видно в uptime).

Кого будить

Ночной алерт — к тому, кто может зайти на VDS. Поддержка продукта по SLA реагирует на тикеты, но не заменяет дежурного админа вашей инфраструктуры: SLA, как писать в поддержку.

Минимальный чеклист внедрения

1. Внешняя проверка https главной каждые 1–5 минут.
2. Алерт в Telegram/почту с именем сайта.
3. Проверка диска на VDS раз в час через cron.
4. Напоминание про SSL.
5. Раз в квартал — тест: остановите nginx на стейдже и убедитесь, что алерт пришёл.

Локальный MicroServer мониторить снаружи обычно не нужно. Боевой контур — да. Перенос на новый сервер: не забудьте переключить проверки на новый URL/IP — перенос.

Что писать в алерте

Имя сайта, URL, код ответа, время. Без этого в три ночи не вспомните, какой из пяти VDS лежит. Для команды — ссылка на runbook: куда смотреть логи, как рестартнуть php-fpm, куда писать хостеру.

Не дублируйте один и тот же алерт в десять чатов. Один канал дежурства. Иначе все решат, что ответил сосед.

Проверка не только главной

Главная из кэша может быть 200, а /login и /cart уже 500. Добавьте 1–2 критичных пути. Не надо мониторить 50 URL каждую минуту — получите нагрузку и шум. Для доски разумно: главная + страница входа + случайная карточка если стабильный URL есть.

Ошибки приложения: 500, база: MySQL.

SSL-мониторинг

Отдельный чек expiry сертификата. Let’s Encrypt на 90 дней: забыли cron renew — получите алерт от браузеров клиентов раньше, чем от uptime, если проверяете только TCP. Настройте renew и dry-run: SSL.

Диск, inode, очередь бэкапов

Скрипт на cron:

df -h / | tail -1
df -i / | tail -1

Если used > 90% — алерт. Часто виноваты логи и старые dump.sql. Ротация и бэкап-политика: бэкап. На shared лимиты другие — смотрите панель, не df.

Синтетика vs метрики сервера

Внешний HTTP-check отвечает на вопрос «доступно ли из интернета». Node exporter / netdata / агент провайдера — на вопрос «почему CPU 100%». Начните с внешнего uptime; железовые графики добавьте, когда появится время. Для PHP-скрипта на одном VDS этого хватает месяцами.

Стек: VDS, Nginx, firewall (после неверного правила uptime покраснеет первым).

Реакция на алерт — короткий порядок

1. Открыть URL с телефона (другая сеть).
2. Если лежит — SSH, systemctl status nginx php-fpm mysql.
3. Хвост error.log.
4. Диск df -h.
5. Если не ясно — откат к последнему бэкапу по ситуации, тикет в поддержку продукта с логом: поддержка.

Не начинайте с reboot как с единственного инструмента — теряете state для диагностики. SLA продукта: SLA. Установка с нуля как крайняя мера: установка.

Отдельно стоит мониторить очередь диска под бэкапы и логи: сайт может отвечать 200, пока mysql ещё пишет, а через час встанет с read-only из‑за 100% disk. Связка с политикой копий: бэкап. После переноса на новый IP обновите проверки в кабинете мониторилки в тот же день, не «когда вспомним»: перенос. Если алерт ложный из‑за вашего же firewall — смотрите firewall и security group провайдера. Для PHP-приложения полезен ещё простой лог-алерт по строке Fatal в error.log (агент или grep по cron), но это второй этап после внешнего uptime. Тикет в поддержку с фактом downtime: поддержка.