Vous rencontrez des plantages fréquents d'Apache2 avec HestiaCP ? Consultez le guide de dépannage et de surveillance automatisée de Monit (avec configuration complète).

Vous rencontrez des plantages fréquents d'Apache2 ou des échecs de redémarrage automatique de Monit dans les environnements HestiaCP ? Cet article propose un guide pratique pour éviter les pièges courants lors de la surveillance d'Apache2 avec Monit. Il analyse en détail les problèmes fréquents tels que les incohérences de chemin des PID et les blocages d'autorisations, et fournit des fichiers de configuration d'automatisation Monit adaptés à la production. Maîtrisez dès maintenant les techniques de maintenance des serveurs haute disponibilité et assurez une reprise automatique de second niveau après les pannes !

Les pièges que j'ai rencontrés en utilisant Monit pour surveiller Apache2

Vendredi dernier, le serveur m'a envoyé une alerte Monit en pleine nuit.

J'ai jeté un coup d'œil hébété au panneau, et dans la colonne d'état d'Apache2, il y avait un délai d'attente rouge.

J'y ai réfléchi un instant. J'ai simplement ajouté la surveillance Monit au serveur dans la journée, en copiant-collant la configuration d'un tutoriel en ligne. Il ne devrait pas y avoir de problème, n'est-ce pas ?

Le lendemain matin, la connexion a de nouveau expiré. Après la troisième tentative, Monitor a tout simplement abandonné et le tableau de bord a affiché « Non surveillé ».

JE...

Je l'avoue, au début, je n'y ai pas prêté attention. La surveillance d'Apache2 ? On trouve des tonnes de modèles de configuration en ligne, il suffit de copier-coller. Mais ce processus de copier-coller m'a vraiment exaspéré.

La cause profonde du conflit entre l'architecture par défaut d'HestiaCP et les ports de Monit

Permettez-moi tout d'abord de vous montrer la configuration qui m'a causé tant de problèmes, afin que vous puissiez vérifier si elle est exactement identique à la version que vous avez vue.

check process apache2 with pidfile /var/run/apache2/apache2.pid
    start program = "/usr/sbin/service apache2 start"
    stop program  = "/usr/sbin/service apache2 stop"
    if failed host 127.0.0.1 port 80 protocol http then restart
    if 5 restarts within 5 cycles then timeout

Tout semble fonctionner correctement, n'est-ce pas ? Le programme vérifie le port 80 et, en cas de plantage, il redémarre. S'il plante encore après cinq redémarrages, il expire.

Le problème, c'est que votre Apache2 ne fonctionne même pas sur le port 80.

C'est un écueil d'HestiaCP, et la principale raison pour laquelle beaucoup d'utilisateurs y tombent. L'architecture par défaut d'HestiaCP est un proxy inverse composé de Nginx et d'Apache2, Nginx occupant les ports 80 et 443 en amont, et Apache2 fonctionnant sur le port local 8081 en aval.

Demander à Monit de vérifier l'état d'Apache2 sur le port 80, c'est comme aller chez McDonald's pour trouver du poulet frit. Le serveur vous regarde d'un air absent, et vous vous fixez du regard. Finalement, Monit conclut que le serveur est hors service et se lance dans un redémarrage frénétique.

Après le redémarrage, le port reste le 8081. Monit tente alors d'interroger le port 80, sans succès, et redémarre à nouveau. Ce cycle se répète jusqu'à ce que Monit considère le problème comme irrémédiable et expire.

Lorsque j'ai découvert cela, j'étais véritablement stupéfait. Neuf tutoriels sur dix que j'ai trouvés en ligne utilisaient le port 80. Si vous les avez suivis, le problème ne venait pas de vous, mais de la source elle-même.

Un fichier PID Apache2 corrompu a conduit Monit à identifier par erreur le processus comme inexistant.

Après avoir changé le port de 80 à 8081, Monit devrait théoriquement pouvoir le détecter, n'est-ce pas ?

Cependant, en réalité, il arrive encore qu'il signale « L'exécution a échoué ».

Après avoir longtemps cherché, j'ai finalement découvert que la raison était simple : le fichier PID était corrompu.

Imaginez : Monit redémarrait frénétiquement Apache2, le forçant à chaque fois à s'arrêter puis à redémarrer, et ce à plusieurs reprises. Durant ce processus, le fichier /var/run/apache2/apache2.pid pouvait devenir vide (0 octet).

Autrement dit, le fichier est toujours là, mais il est vide.

Lorsque Monit tente de lire ce fichier, il ne trouve rien. Il ne reconnaît pas votre instance Apache2, même si celle-ci fonctionne parfaitement en arrière-plan ; Monit considère que le processus n'existe pas.

Quand j'ai vu ça, je suis resté sans voix un instant.

Il s'agit d'un blocage. Monit ne parvient pas à détecter l'instance Apache 2, redémarre Apache2, corrompt le fichier PID lors du redémarrage, échoue à nouveau lors de la détection suivante et redémarre encore. Ce cycle se poursuit jusqu'à expiration du délai.

Étapes de dépannage et de réparation pour la surveillance Apache2 dans l'environnement HestiaCP

Honnêtement, la procédure d'enquête n'est pas compliquée, mais il faut savoir dans quelle direction enquêter.

La première étape consiste à déterminer sur quel port Apache2 écoute. Il suffit de saisir une commande dans le terminal.

netstat -tulpn | grep apache2

Vous pouvez également utiliser la commande `ss` ; l'effet est le même.

ss -tulpn | grep apache2

Vous obtiendrez un résultat similaire à celui-ci.

tcp  0  0 127.0.0.1:8081       0.0.0.0:*  LISTEN  2942372/apache2

Il est confirmé qu'il s'agit de 8081 et non de 80. C'est là l'origine du problème.

La deuxième étape consiste à réparer le fichier PID corrompu. C'est plus simple.

monit unmonitor apache2
systemctl restart apache2
cat /var/run/apache2/apache2.pid

Commencez par suspendre la surveillance Monit pour éviter toute interférence pendant la résolution du problème. Redémarrez ensuite Apache2 afin qu'il puisse réécrire un PID propre. Enfin, utilisez la commande `cat` pour vérifier le contenu du fichier ; il doit contenir une chaîne de chiffres, et non une chaîne vide.

Une fois cette étape franchie, le problème est en gros résolu.

Analyse comparative des configurations de protection adaptatives et agressives traditionnelles de Monit

Les tutoriels en ligne sur la configuration d'Apache2 avec Monit se répartissent généralement en deux catégories.

L'un des types d'adaptation est l'« adaptation traditionnelle », qui utilise la commande `service` pour gérer les services et vérifier les ports locaux sans imposer de restrictions trop complexes. Cette configuration peut être utilisée sur HestiaCP en modifiant simplement le port, et elle est relativement stable.

Une autre approche consiste en la méthode de « protection agressive », qui utilise systemctl pour gérer les services, ajoute des restrictions aux processus enfants et emploie une logique de détection plus stricte. Elle semble prometteuse, mais présente un défaut majeur : la commande d'arrêt utilisée est `killall -9`.

Que signifie `killall -9` ? Cela signifie forcer l'arrêt du périphérique, quelle que soit son activité. Cette opération brutale peut facilement corrompre les fichiers PID, ce qui correspond au problème que je viens d'évoquer.

D'après mon expérience, limiter le nombre de processus enfants dans une configuration agressive est effectivement utile. Lorsqu'un serveur Apache2 est submergé par une attaque par copie de contenu (CC), cette limitation peut éviter une saturation de la mémoire. En revanche, la commande `killall -9` est totalement inutilisable.

J'ai donc finalement fait un compromis et combiné les avantages des deux configurations.

Configuration optimale d'HestiaCP Apache2 Monit

Modifiez le fichier /etc/monit/conf.d/apache2 avec le contenu suivant.

check process apache2 with pidfile /var/run/apache2/apache2.pid
    start program = "/bin/systemctl start apache2"
    stop program  = "/bin/systemctl stop apache2"
    if children > 120 for 2 cycles then restart
    if failed host 127.0.0.1 port 8081 protocol http for 2 cycles then restart
    if 5 restarts within 10 cycles then timeout

Permettez-moi d'expliquer brièvement la logique qui sous-tend ces quelques lignes de configuration.

Écrivez sur le port 8081 pour correspondre précisément à l'architecture du proxy inverse d'HestiaCP ; arrêtez d'écrire bêtement sur le port 80.

Utilisez la commande `systemctl stop` au lieu de `killall -9` pour arrêter le fichier PID, afin de ne pas le corrompre.

Une limite de processus enfants a été ajoutée : si le nombre d’enfants dépasse 120, le processus redémarrera après deux cycles consécutifs pour empêcher les attaques par copie conforme, mais cette mesure n’est pas excessive.

La logique de détection des pannes a été modifiée pour utiliser une approche « sur 2 cycles », ce qui signifie qu'un redémarrage n'est déclenché qu'après deux pannes consécutives, réduisant ainsi les faux positifs. La configuration précédente, qui redémarrait après une seule détection, était, il faut bien le dire, un peu trop sensible.

Le seuil de délai d'expiration final est assoupli à 5 redémarrages sur 10 cycles, laissant une tolérance aux pannes suffisante.

Hestia CP Surveillance du moniteurRésumé et partage d'expérience sur le dépannage de la configuration

Après avoir effectué les modifications de configuration, j'ai surveillé Apache2, et le panneau a finalement affiché un indicateur vert « OK ».

Comment décrire ce que j'ai ressenti à ce moment-là ? C'était comme passer deux jours à lutter contre un bug, pour finalement découvrir que la cause était une simple ligne de configuration erronée. C'était à la fois frustrant et risible.

Monit est un outil précieux, et la surveillance des démons est une pratique courante sur tous les serveurs. Cependant, de nombreux tutoriels en ligne partent du principe qu'« Apache2 utilise exclusivement le port 80 », alors qu'HestiaCP utilise un proxy inverse, ce qui invalide cette hypothèse.

Si vous suivez les instructions, le problème ne vient pas de vous ; c'est que le tutoriel s'applique à un scénario différent du vôtre.

Si vous utilisez également HestiaCP et Monit pour surveiller Apache2, n'oubliez pas deux choses : changez le port pour 8081 et utilisez la commande `systemctl` pour l'arrêter, et non `killall -9`. En suivant ces deux instructions, vous devriez éviter tout problème ultérieur.

Puisque vous avez lu jusqu'ici, si cela vous a été utile, n'hésitez pas à aimer et à partager. Si vous souhaitez être informé(e) en priorité des nouveautés, vous pouvez aussi me suivre !

Merci d'avoir lu mon article. À bientôt !