Fallades freqüents d'Apache2 amb HestiaCP? Guia de monitorització i resolució de problemes automatitzada de Monit (amb configuració completa)

Fallades freqüents d'Apache2 o errors de reinici automàtic de Monit en entorns HestiaCP ? Aquest article proporciona una guia pràctica per evitar errors comuns en monitoritzar Apache2 amb Monit, analitzant en profunditat problemes comuns com ara la desalineació de la ruta PID i el bloqueig de permisos, i oferint fitxers de configuració d'automatització de Monit de nivell de producció. Domineu ara les tècniques de manteniment del servidor d'alta disponibilitat i aconseguiu una recuperació automàtica de segon nivell després d'errors!

Els entrebancs que vaig trobar mentre utilitzava Monit per monitoritzar Apache2

Divendres passat, el servidor em va donar una alerta de Monit a mitjanit.

Vaig mirar el panell atordit i, a la columna d'estat de l'apache2, hi havia un temps d'espera vermell.

Ho vaig pensar una mica. Acabo d'afegir la monitorització Monit al servidor durant el dia i he copiat i enganxat la configuració d'un tutorial en línia. No hi hauria d'haver cap problema, oi?

L'endemà al matí, el temps d'espera va tornar a expirar. Després de la tercera vegada, Monitor simplement es va rendir i el panell va mostrar "No monitoritzat".

jo. . .

Admeto que al principi no m'ho vaig prendre seriosament. Monitorització d'Apache2? Pots trobar tones de configuracions de plantilles en línia, només cal copiar i enganxar. Però aquell procés d'enganxar em va enfurir molt.

La causa principal del conflicte entre l'arquitectura per defecte d'HestiaCP i els ports Monit

Deixa'm que et mostri primer la configuració que m'ha causat tants problemes, perquè puguis veure si és exactament la mateixa que la versió que has vist.

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

Sembla que està bé, oi? Comprova el port 80 i, si falla, es reinicia. Si encara falla després de 5 reinicis, s'espera el temps d'espera.

El problema és que el teu Apache2 ni tan sols s'executa al port 80.

Això és un error d'HestiaCP i la causa principal que molta gent hi caigui. L'arquitectura per defecte d'HestiaCP és un proxy invers de Nginx + Apache2, amb Nginx ocupant els ports 80 i 443 al davant i Apache2 executant-se al port local 8081 al darrere.

Si li demanes a Monit que comprovi l'activitat d'Apache2 al port 80, és com anar a McDonald's a buscar KFC. El servidor et mira amb cara de desconcert i vosaltres dos us mireu fixament. Al final, Monit determina que no tens res i comença a reiniciar frenèticament.

Després de reiniciar, el port continua sent el 8081. Monit intenta sondar el port 80, però també falla, de manera que es reinicia de nou. Aquest cicle es repeteix fins que Monit decideix que no es pot reparar i s'espera el temps d'espera.

Quan vaig trobar això per primera vegada, em va sorprendre molt. Nou de cada deu tutorials que vaig trobar en línia feien servir el port 80. Si els seguies, el problema no era teu, sinó de la font de la informació en si.

Un fitxer PID d'Apache2 corrupte va fer que Monit identifiqués erròniament el procés com a inexistent.

Després de canviar el port de 80 a 8081, Monit teòricament hauria de poder detectar-lo, oi?

No obstant això, en realitat, encara ocasionalment informa que "L'execució ha fallat ".

Després de lluitar durant molt de temps, finalment vaig descobrir que el motiu era simple: el fitxer PID estava corromput.

Pensa-hi, Monit estava reiniciant frenèticament Apache2, i cada vegada el matava i el reiniciava per la força, anant i venint diverses vegades. Durant aquest procés, el fitxer /var/run/apache2/apache2.pid podria arribar a tenir 0 bytes.

En altres paraules, el fitxer encara hi és, però és buit.

Quan Monit llegeix aquest fitxer, no troba res. No reconeix el vostre Apache2, fins i tot si el vostre Apache2 s'executa perfectament en segon pla; Monit no creu que el procés existeixi.

Quan vaig veure això, em vaig quedar sense paraules per un moment.

Això és un bloqueig. Monit no detecta la instància d'Apache 2, reinicia Apache2, corromp el fitxer PID durant el procés de reinici, falla la següent detecció i es reinicia de nou. Aquest cicle continua fins que es produeix el temps d'espera.

Passos de resolució de problemes i reparació per a la monitorització d'Apache2 en un entorn HestiaCP

Si he de ser sincer, el procés d'investigació no és complicat, però cal saber en quina direcció investigar.

El primer pas és determinar en quin port escolta el vostre Apache2. Simplement escriviu una ordre al terminal.

netstat -tulpn | grep apache2

Alternativament, podeu utilitzar l'ordre `ss`; l'efecte és el mateix.

ss -tulpn | grep apache2

Veureu una sortida similar a aquesta.

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

S'ha confirmat que és el 8081, no el 80. Aquesta és l'arrel del problema.

El segon pas és reparar el fitxer PID danyat. Això és més senzill.

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

Primer, atureu la monitorització de Monit per evitar que interfereixi mentre esteu arreglant les coses. Després, reinicieu Apache2 per permetre que reescrigui un PID net. Finalment, utilitzeu `cat` per comprovar el contingut del fitxer; ha de contenir una cadena de números, no una cadena buida.

Un cop finalitzat aquest pas, el problema està bàsicament resolt.

Anàlisi comparativa de les configuracions de protecció adaptativa i agressiva tradicionals de Monit

Els tutorials en línia sobre la configuració d'Apache2 amb Monit generalment es divideixen en dues categories.

Un tipus és el "tipus d'adaptació tradicional", que utilitza l'ordre `service` per gestionar els serveis i comprovar els ports locals sense afegir massa restriccions complicades. Aquesta configuració es pot utilitzar a HestiaCP simplement canviant el port i és relativament estable.

Un altre enfocament és el mètode de "protecció agressiva", que utilitza systemctl per gestionar els serveis, afegeix restriccions de processos fills i empra una lògica de detecció més estricta. Té un aspecte fantàstic, però té un defecte fatal: l'ordre d'aturada que s'utilitza és `killall -9`.

Què significa `killall -9`? Significa tancar el dispositiu per la força independentment del que estigui fent. Aquesta operació de força bruta pot deixar fàcilment fitxers PID corruptes, que és el problema que acabo d'esmentar.

La meva experiència personal és que limitar el nombre de processos fills en una configuració agressiva és realment útil. Quan el vostre Apache2 es veu desbordat per un atac CC, limitar el nombre de processos fills pot evitar que el servidor es quedi sense memòria. Tanmateix, l'enfocament `killall -9` és realment inutilitzable.

Així que al final vaig fer un compromís i vaig combinar els avantatges d'ambdues configuracions.

Configuració de les millors pràctiques de HestiaCP Apache2 Monit

Modifiqueu el fitxer /etc/monit/conf.d/apache2 amb el contingut següent.

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

Permeteu-me que expliqui breument la lògica que hi ha darrere d'aquestes poques línies de configuració.

Escriviu el port 8081 perquè coincideixi exactament amb l'arquitectura de proxy invers de HestiaCP; deixeu d'escriure absurdament el port 80.

Feu servir l'ordre `systemctl stop` en comptes de `killall -9` per aturar el fitxer PID, per tal d'evitar-lo corrompre.

S'ha afegit un límit de processos fills: si el nombre de fills supera els 120, el procés es reiniciarà després de dos cicles consecutius per evitar atacs CC, però no és massa agressiu.

La lògica per detectar errors s'ha modificat per utilitzar un enfocament de "durant 2 cicles", és a dir, un reinici només s'activa després de dos errors consecutius, reduint els falsos positius. La configuració anterior, que es reiniciava després d'una sola detecció, era francament una mica massa sensible.

El llindar de temps d'espera final es relaxa a 5 reinicis en 10 cicles, deixant una tolerància a fallades suficient.

HestiaCP Monitorització del seguimentResum de resolució de problemes de configuració i intercanvi d'experiències

Després de fer els canvis de configuració, vaig monitoritzar apache2 i el panell finalment va mostrar un indicador verd de "D'acord".

Com descriuria els meus sentiments en aquell moment? Va ser com passar dos dies lluitant amb un error, només per descobrir que la causa era una sola línia de configuració incorrecta. Va ser frustrant i ridícul alhora.

Monit és una bona cosa en si mateixa, i monitoritzar els daemons és una cosa que tot servidor hauria de fer. Però el problema és que molts tutorials en línia es basen en la suposició que "Apache2 utilitza exclusivament el port 80", mentre que HestiaCP utilitza un proxy invers, cosa que significa que aquesta suposició no és certa.

Si segueixes les instruccions, el problema no ets tu; és que el tutorial és aplicable a un escenari diferent del teu.

Així doncs, si també feu servir HestiaCP i esteu jugant amb Monit per monitoritzar Apache2, només heu de recordar dues coses: canvieu el port a 8081 i utilitzeu l'ordre `systemctl` per aturar-lo, no `killall -9`. Si feu aquestes dues coses, hauríeu de poder evitar més problemes.

Ja que has llegit fins aquí, si t'ha semblat útil, fes-hi un "m'agrada" i comparteix-ho. Si vols rebre actualitzacions primer, també em pots seguir!

Gràcies per llegir el meu article. Fins la propera.