Surveiller un site WordPress

Ce que vous saurez

• Le site se charge, et c’est bien votre site. La page d’accueil répond 200 et contient un texte que seul votre site affiche. La page « Error establishing a database connection » de WordPress renvoie un 500, et une page parquée ou défigurée n’a pas votre texte : les deux échouent.
• Le certificat et le domaine ne sont pas sur le point d’expirer. Un avertissement 30 jours avant l’expiration du certificat, et 15 jours avant celle de l’enregistrement du domaine.
• La base de données accepte les connexions, et le disque ne se remplit pas. Ces deux vérifications ont besoin de l’agent, et elles expliquent généralement une page en échec avant même que vous cherchiez.
• Les tâches planifiées de WordPress s’exécutent vraiment. Les publications planifiées, les sauvegardes des plugiciels, le nettoyage et la recherche de mises à jour dépendent tous de WP-Cron, qui échoue en silence.

Ce que cette configuration ne peut pas vous dire : si chaque page fonctionne. Un plugiciel défectueux peut faire tomber le paiement pendant que la page d’accueil va bien. Ajoutez une vérification de page pour les pages qui vous rapportent de l’argent ; voyez Variantes.

Avant de commencer

• Le serveur ajouté comme hôte dans Gryphon, avec le nom du site, comme www.example.com, dans Nom d’hôte ou IP.
• Pour les vérifications de la base de données et du disque, l’agent Gryphon sur le serveur. Les vérifications de la page, du certificat, du domaine et de WP-Cron fonctionnent sans lui.
• Pour WP-Cron, un shell sur le serveur et WP-CLI, installé sous /usr/local/bin/wp.

Les exemples supposent que WordPress se trouve dans /var/www/html et s’exécute sous l’utilisateur www-data, comme sur Debian et Ubuntu. Adaptez le chemin et l’utilisateur à votre serveur.

Étapes

1Vérifier la page

Ouvrez l’hôte, allez dans Services, choisissez Ajouter le service, puis Surveiller une page Web.

Pour La réponse contient, choisissez un texte qui apparaît à chaque chargement réussi de la page et nulle part ailleurs, comme le nom de votre site dans l’en-tête ou une ligne du pied de page. Il doit correspondre exactement, majuscules comprises. Les redirections sont suivies : un site qui renvoie / vers /en/ est jugé sur la page où il aboutit.

2Ajouter le certificat et le domaine

Ajoutez Certificat SSL avec Port 443 et Vérifier le certificat true. Ajoutez ensuite Expiration du domaine en laissant Nom de domaine vide : la vérification utilise le nom de l’hôte et cherche le domaine enregistré, si bien que www.example.com est vérifié comme example.com. Les deux sont vérifiés une fois par jour.

3Vérifier la base de données, sans mot de passe

Ajoutez MariaDB/MySQL (agent) :

Avec Authentification réglée sur none, l’agent lit le message d’accueil du serveur et s’arrête là : aucun mot de passe n’est conservé nulle part. Cela indique que le serveur est en marche et accepte les connexions, ce à quoi se résume habituellement une panne de WordPress. Le message ressemble à mariadb is accepting connections (11.8.2-MariaDB).

La vérification se connecte en TCP. Si wp-config.php indique localhost, WordPress utilise peut-être plutôt un fichier de socket, mais MariaDB et MySQL écoutent aussi sur 127.0.0.1:3306 dans la plupart des installations. ss -ltn | grep 3306 sur le serveur vous montre si c’est le cas du vôtre.

4Surveiller le disque

Ajoutez Espace disque avec Nom Racine et Chemin à surveiller /. Les téléversements, les caches, les journaux et les plugiciels de sauvegarde remplissent les disques, et un disque plein brise WordPress de façons difficiles à comprendre à partir de la page seule.

5Exécuter WP-Cron selon un horaire, et le signaler

Par défaut, WP-Cron ne s’exécute que lorsque quelqu’un visite le site. Sur un site peu fréquenté, les publications planifiées sortent en retard et les plugiciels de sauvegarde sautent des nuits. La solution : désactiver ce comportement et exécuter WP-Cron toutes les cinq minutes à partir du cron du système, en signalant chaque exécution à un battement de cœur.

D’abord, ajoutez un Battement de cœur à l’hôte :

Copiez son URL depuis la ligne de la vérification. Empêchez ensuite WordPress d’exécuter WP-Cron lors des visites :

sudo -u www-data /usr/local/bin/wp --path=/var/www/html config set DISABLE_WP_CRON true --raw

Si l’utilisateur du serveur Web ne peut pas écrire dans wp-config.php, ajoutez-y define( 'DISABLE_WP_CRON', true ); à la main, au-dessus de la ligne qui demande d’arrêter les modifications.

Enregistrez ceci sous /usr/local/bin/wp-cron-gryphon, collez-y l’URL de votre battement de cœur et rendez-le exécutable avec sudo chmod 755 /usr/local/bin/wp-cron-gryphon :

#!/bin/sh
# WordPress's scheduled tasks, run by the system's cron and reported to Gryphon.
HB="https://gryphon.gocode.ca/hb/your-token"

if /usr/local/bin/wp --path=/var/www/html cron event run --due-now --quiet; then
    curl -fsS -m 10 --retry 3 "$HB" > /dev/null
else
    curl -fsS -m 10 --retry 3 "$HB/fail" > /dev/null
fi

Et exécutez-le toutes les cinq minutes, sous l’utilisateur du serveur Web :

*/5 * * * * /usr/local/bin/wp-cron-gryphon

wp cron event run --due-now réussit quand rien n’est dû : cinq minutes tranquilles donnent donc quand même un signal en bon état. Il échoue quand WordPress ne peut pas s’exécuter du tout, par exemple quand la base de données est en panne, et signale alors un échec tout de suite, au lieu d’attendre la fin du délai de grâce.

Faire un essai

1. Utilisez Vérifier maintenant sur les vérifications de la page, de la base de données et du disque.
2. Exécutez le script WP-Cron une fois à la main : sudo -u www-data /usr/local/bin/wp-cron-gryphon. En moins d’une minute, le battement de cœur est en bon état. sudo -u www-data wp --path=/var/www/html cron event list montre ce que WordPress a planifié.
3. Signalez volontairement un échec avec curl -fsS https://gryphon.gocode.ca/hb/your-token/fail. En moins d’une minute, le battement de cœur passe en problème et les alertes partent : prévenez d’abord votre équipe. La prochaine exécution par cron le remet en bon état.

Variantes

Les pages qui rapportent

Ajoutez une autre vérification Surveiller une page Web pour chaque page importante, comme /shop/ sur un site WooCommerce, avec La réponse contient réglé sur un texte qui n’apparaît que lorsque les produits se chargent, comme Add to cart.

La base de données sur un autre serveur

Placez MariaDB/MySQL (agent) sur n’importe quel hôte dont l’agent peut joindre le serveur de base de données, et réglez Hôte sur l’adresse privée de ce serveur. Mieux encore, installez l’agent sur le serveur de base de données lui-même, pour que son disque soit surveillé aussi.

Hébergement WordPress géré

Sans shell, les étapes 3 à 5 ne sont pas de votre ressort, et c’est votre hébergeur qui exécute WP-Cron. Les vérifications de la page, du certificat et du domaine fonctionnent toujours, et ce sont elles qui vous disent que le site est en panne.

Sauvegardes

Si un plugiciel fait vos sauvegardes, le battement de cœur ci-dessus montre déjà que WP-Cron les exécute. Pour les sauvegardes faites par le serveur, voyez S’assurer que la sauvegarde de la nuit dernière a bien eu lieu.