Как мониторить и диагностировать WordPress по слоям

Диагностика WordPress становится понятной, если идти по пути запроса: внешний клиент → DNS/TLS → Nginx → PHP-FPM → WordPress → MariaDB. Cron, почта и диск проверяются отдельно. Начинайте с первого нарушенного слоя, а не с переустановки плагинов.

Зафиксируйте симптом и время

Запишите URL, код ответа, время UTC, тип пользователя и последнее изменение. Затем выполните внешний запрос:

curl --fail --show-error --silent --output /dev/null \
  --write-out 'code=%{http_code} start=%{time_starttransfer} total=%{time_total}\n' \
  https://example.com/

Проверьте также некешируемый контрольный URL без персональных данных. Если соединения нет, переходите к DNS, TLS и firewall. Если Nginx отвечает, сеть уже не является первой неизвестной.

Сопоставьте Nginx и PHP-FPM

На VPS проверьте конфигурацию, службы и сообщения за последние десять минут:

sudo nginx -t
systemctl --failed --no-pager
journalctl -u nginx --since '-10 minutes' --no-pager
journalctl -u php8.3-fpm --since '-10 minutes' --no-pager

Версию PHP в имени службы замените установленной. Ответ 502 вместе с отсутствующим сокетом указывает на PHP-FPM; 404 — на root или маршрутизацию; 500 требует журнала приложения. Ищите первую ошибку рядом со временем запроса.

Проверьте базу и ресурсы

Следующие команды показывают активные подключения, память, диск и сообщения OOM без изменения данных:

sudo mariadb -e "SHOW PROCESSLIST;"
free -h
df -hT
journalctl -k -b --no-pager | grep -i -E 'out of memory|killed process'

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

Проверьте cron и целостность

Главная из page cache может работать при сломанном cron. Просмотрите просроченные события и checksum официальных компонентов:

wp --path=/srv/www/example.com/current cron event list --fields=hook,next_run_relative,recurrence
wp --path=/srv/www/example.com/current core verify-checksums
wp --path=/srv/www/example.com/current plugin verify-checksums --all --strict

Не удаляйте неизвестный hook и не заменяйте файл до выяснения источника. Коммерческий плагин может не иметь эталонных checksum.

Включайте отладку на ограниченное время

Если штатных журналов недостаточно, направьте WordPress debug в файл, но не показывайте посетителям. Защитите журнал от веб-доступа, следите за ростом и не собирайте лишние персональные данные. После воспроизведения ошибки верните обычный уровень.

Превратите проверки в наблюдение

Минимальный мониторинг включает внешний HTTP-код и время, срок TLS, свободное место, OOM, состояние Nginx/PHP/MariaDB, просроченный cron и неуспешные резервные копии. Оповещение должно сообщать симптом и время, а не просто «сайт сломан».

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

Источники

• WordPress common errors
• WordPress hardening: logging and monitoring
• WP-CLI cron event list
• PHP-FPM configuration