Supervision d'une plateforme WordPress avec Nagios

Projet en bref

Contexte

Ce projet répond à un besoin courant d’exploitation : surveiller une application web afin de détecter rapidement une saturation des ressources, une indisponibilité du site ou une panne de sa base de données.

Le laboratoire associe une plateforme WordPress à un serveur de supervision indépendant. La solution collecte à la fois des indicateurs techniques et les journaux applicatifs nécessaires à l’analyse d’un incident.

Objectifs techniques

• Automatiser le déploiement d’un environnement de supervision reproductible ;
• contrôler l’état du système, du serveur web et de la base de données ;
• exécuter les sondes à distance avec NRPE ;
• centraliser les journaux Apache sur un serveur distinct ;
• fournir des seuils d’alerte compréhensibles et exploitables.

Architecture retenue

flowchart LR
    Admin["Administrateur"]

    subgraph App["Serveur applicatif — Ubuntu 22.04"]
        WordPress["WordPress + Apache"]
        Database["MySQL"]
        Agent["Agent NRPE<br/>7 sondes"]
        Sender["rsyslog<br/>expéditeur"]
    end

    subgraph Ops["Serveur de supervision — Ubuntu 22.04"]
        Nagios["Nagios Core"]
        UI["Tableau de bord web"]
        Collector["rsyslog<br/>collecteur"]
    end

    Admin --> UI
    Admin --> WordPress
    Nagios -->|"TCP 5666"| Agent
    Sender -->|"TCP 514"| Collector
    WordPress --> Database
    Nagios --> UI

    style App fill:#eff6ff,stroke:#2563eb
    style Ops fill:#ecfdf5,stroke:#059669
    style Nagios fill:#f8fafc,stroke:#475569
    style WordPress fill:#f8fafc,stroke:#475569

La séparation en deux machines maintient la supervision disponible indépendamment de l’application observée. Nagios interroge l’agent NRPE sur le serveur applicatif, tandis que rsyslog transmet les journaux dans le sens inverse vers le collecteur.

Travaux réalisés

Infrastructure

• Définition des deux machines virtuelles avec Vagrant ;
• attribution d’adresses privées fixes sur un réseau isolé ;
• allocation de ressources cohérentes pour la plateforme et la supervision ;
• provisionnement automatisé au moyen de scripts Bash.

Plateforme web

• Installation d’Apache, PHP, WordPress et MySQL ;
• création de la base, de l’utilisateur applicatif et du fichier de configuration WordPress ;
• déclaration d’un hôte virtuel Apache et de journaux dédiés.

Supervision

• Compilation et installation de Nagios Core et de ses plugins ;
• installation de NRPE sur les deux serveurs ;
• déclaration de l’hôte applicatif et de sept services supervisés ;
• création d’une sonde personnalisée pour mesurer l’occupation de la mémoire.

Les contrôles couvrent :

• la mémoire vive ;
• la charge système ;
• l’espace disque ;
• le nombre d’utilisateurs connectés ;
• le processus Apache ;
• la réponse HTTP de WordPress ;
• la connexion à MySQL.

Centralisation des journaux

• Lecture des journaux d’accès et d’erreur Apache avec le module imfile ;
• transfert vers le serveur de supervision en TCP ;
• activation de la réception rsyslog sur le port 514 ;
• classement automatique des événements par hôte et par programme.

Difficultés et choix techniques

Exécuter des sondes applicatives à distance

Problème — Aller au-delà d’un simple test de disponibilité réseau

Un contrôle ICMP ne permet pas de savoir si Apache répond, si MySQL accepte les connexions ou si les ressources du serveur sont saturées.

Solution et résultat : un agent NRPE exécute localement les plugins avec les bons droits et renvoie leur état à Nagios. La supervision couvre ainsi le système et les composants de l’application.

Rendre les alertes directement exploitables

Problème — Transformer une mesure brute en état opérationnel

Une valeur de mémoire, de charge ou d’espace disque n’est utile que si elle est associée à un seuil cohérent.

Solution et résultat : chaque sonde de ressources définit des niveaux WARNING et CRITICAL. Par exemple, la mémoire déclenche un avertissement à 70 % d’utilisation et une alerte critique à 85 %.

Conserver les éléments utiles au diagnostic

Problème — Les journaux locaux deviennent difficiles à consulter lorsque le serveur applicatif est indisponible.

Solution et résultat : les journaux Apache sont expédiés vers le serveur de supervision et rangés par source. Les indicateurs Nagios et les événements rsyslog peuvent alors être rapprochés pendant l’analyse d’un incident.

Résultats

Le dépôt regroupe l’infrastructure et les configurations nécessaires à la recréation du laboratoire. La supervision ne se limite pas à la disponibilité de la machine : elle vérifie également les ressources, le serveur HTTP, la page applicative et l’accès à la base de données.

Compétences démontrées

• Administrer des serveurs Ubuntu ;
• automatiser une infrastructure locale avec Vagrant et Bash ;
• déployer une pile Apache, PHP, WordPress et MySQL ;
• installer et configurer Nagios Core, ses plugins et NRPE ;
• définir des indicateurs et des seuils de supervision ;
• écrire un plugin Nagios personnalisé ;
• centraliser et organiser des journaux avec rsyslog ;
• diagnostiquer un incident à partir de métriques et de journaux ;
• documenter une architecture et ses procédures d’exploitation.

Retour d’expérience

Ce projet m’a permis de relier trois dimensions complémentaires de l’exploitation : déployer un service, mesurer son état et conserver les événements nécessaires au diagnostic. Une supervision pertinente ne consiste pas seulement à vérifier qu’une machine répond ; elle doit contrôler chaque maillon critique de l’application avec des seuils permettant de prioriser les actions.

Pour faire évoluer ce laboratoire, je rendrais les scripts idempotents, j’externaliserais tous les secrets, j’épinglerais les versions téléchargées et je chiffrerais les flux de journaux. J’ajouterais également des notifications, des tests automatisés du provisionnement et des mesures/métriques de performance HTTP telles que le temps de réponse.