Моніторинг WordPress: перевірки, які сайту на WordPress справді потрібні

Набір моніторів для одного сайту на WordPress

У WordPress немає окремого типу монітора, і він не потрібен. Надійний набір складається зі стандартних типів, а для типового сайту це п’ять-шість моніторів:

• Keyword на головній: фраза з футера має бути, а «Error establishing a database connection» — ні (з тарифу Starter).
• HTTP на /wp-login.php із типовим діапазоном 200-299 або 200-399, якщо він перенаправляє на https.
• JSON API на /?rest_route=/ із шляхом name і назвою вашого сайту як очікуваним значенням; це працює без «гарних» постійних посилань і разом перевіряє PHP, базу даних і шар REST.
• Heartbeat для запланованих завдань (наступний розділ).
• SSL / домен для дат закінчення сертифіката й реєстрації.
• За бажанням DNS для A-запису або HTTP-монітор, що очікує 403 на /xmlrpc.php, якщо ви заблокували його навмисно.

wp-cron — це не годинник

За замовчуванням WordPress виконує заплановані завдання лише тоді, коли хтось відвідує сайт. Тому на малолюдному сайті заплановані записи виходять із запізненням, черги листів відправляються пізно, а резервні копії пропускаються. Гірше того, на жвавому сайті те саме завдання може запуститися двічі. Виправлення, яке радить більшість гайдів від хостерів: встановити в wp-config.php DISABLE_WP_CRON у true і запускати завдання зі справжнього планувальника кожні п’ять хвилин: */5 * * * * cd /var/www/site && wp cron event run --due-now && curl -fsS https://YOUR-APP-HOST/hb/hb_TOKEN. Створіть heartbeat із періодом 600 секунд і допуском 300. Тепер відсутній пінг означає, що зупинився сам планувальник, а це заодно пояснює, чому зникли резервні копії та заплановані записи.

Heartbeat починається зі Starter, ліміти щедрі: 20 на Starter і 100 на Pro, тож один на сайт реально навіть для студії.

Перші п’ять хвилин після оновлення

Більшість збоїв WordPress починається з оновлення плагіна, теми чи ядра. Три екрани помилок заслуговують окремих перевірок «фрази не має бути», бо кожен кеш або власний шаблон помилки може віддати зі звичайним кодом: «There has been a critical error on this website» (екран фатальної помилки), «Briefly unavailable for scheduled maintenance» (оновлення зависло й лишило файл обслуговування) та «Error establishing a database connection». Додайте їх в окремі монітори ключових слів або виберіть дві, які бачите найчастіше; тоді повідомлення про збій назве, яка саме з’явилася.

Поєднуйте перевірки з вікном обслуговування, коли оновлюєте навмисно, щоб кілька хвилин запланованого простою не лякали клієнта й не псували аптайм у місячному звіті.

Кеш може приховати збій

Кеш сторінок і CDN створені, щоб і далі віддавати останню справну копію, що чудово для відвідувачів і погано для моніторингу. Коли база даних лежить, закешована головна може бути «зеленою» годинами. Тримайте хоча б один монітор на тому, що обов’язково виконує PHP і звертається до бази: wp-login.php за розумного налаштування не кешується, а корінь REST за адресою /?rest_route=/ також динамічний. Якщо ваш кеш якийсь час віддає сторінки помилок, перевірка «фрази не має бути» їх теж виявить.

Трапляється й зворотне: плагін безпеки чи WAF сприймає IP-адресу моніторингу як зловмисника. Wordfence, правила Cloudflare та fail2ban можуть заблокувати її після кількох запитів. Додайте список IP-адрес перевіряльників до білого списку (allow-list) або надсилайте заголовок X-Tenium-Secret, за яким спрацьовує ваше правило, і монітор перестане бути частиною поверхні атаки. Перевірка на бота з’являється як інцидент «заблоковано», а не «недоступно».

Коли сайтів сорок

При п’яти моніторах на сайт 300 моніторів тарифу Pro вистачить приблизно на 60 сайтів, а 1000 моніторів тарифу Agency — на 200 сайтів. Послідовність важливіша за винахідливість: однакові назви моніторів (Client A, home keyword), однакові теги й однакові контакти для сповіщень скрізь, щоб інциденти однаково читалися на сторінці статусу й у звіті. Монітори можна створити масово через імпорт CSV; потрібні стовпці наведено в документації з імпорту. На тарифі Agency дайте кожному клієнту власний простір із логіном для перегляду та місячним звітом під вашим брендом; детальніше для агенцій.

Знайте межі. Tenium дивиться на ваш сайт ззовні, тож повідомить, що сайт недоступний, чого плагін уже не зробить, коли сайт упав. Версій плагінів, змін у файлах, шкідливого коду й резервних копій він не бачить. Це роблять ManageWP і MainWP, і вони доповнюють, а не замінюють Tenium.