Fallos frecuentes de Apache2 con HestiaCP? Guía de monitorización e resolución de problemas automatizada de Monit (con configuración completa)

Fallos frecuentes de Apache2 ou fallos de reinicio automático de Monit en entornos HestiaCP ? Este artigo ofrece unha guía práctica para evitar erros comúns ao monitorizar Apache2 con Monit, analizando en profundidade problemas comúns como o desalineamento de rutas PID e o bloqueo de permisos, e ofrecendo ficheiros de configuración de automatización de Monit de nivel de produción. Domine agora as técnicas de mantemento de servidores de alta dispoñibilidade e logre unha recuperación automática de segundo nivel ante fallos!

As dificultades que atopei ao usar Monit para monitorizar Apache2

A pasada sexta feira, o servidor deume unha alerta de Monit no medio da noite.

Boteille unha ollada ao panel atordado e, na columna de estado de apache2, había un tempo de espera vermello.

Penseino un pouco. Acabo de engadir a monitorización de Monit ao servidor durante o día e copiei e peguei a configuración dun tutorial en liña. Non debería haber ningún problema, non si?

Á mañá seguinte, volveu a pasar o tempo de espera. Despois da terceira vez, Monitor simplemente desistiu e o panel mostrou "Non monitorizado".

eu. . .

Recoñezo que ao principio non o tomei en serio. Monitorización de Apache2? Podes atopar moitas configuracións de modelos en liña, só tes que copiar e pegar. Pero ese proceso de pegado realmente enfureceume.

A causa raíz do conflito entre a arquitectura predeterminada de HestiaCP e os portos de Monit

Déixame que che mostre primeiro a configuración que me causou tantos problemas, para que poidas ver se é exactamente a mesma que a versión que viches.

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

Parece estar ben, non si? Comproba o porto 80 e, se falla, reiníciase. Se segue fallando despois de 5 reinicios, esgota o tempo de espera.

O problema é que o teu Apache2 nin sequera se executa no porto 80.

Esta é unha trampa de HestiaCP e a causa principal de que moita xente caia nela. A arquitectura predeterminada de HestiaCP é un proxy inverso de Nginx + Apache2, con Nginx ocupando os portos 80 e 443 na parte dianteira e Apache2 executándose no porto local 8081 na parte traseira.

Se lle pides a Monit que probe a actividade de Apache2 no porto 80, é coma ir a McDonald's a buscar KFC. O servidor mírate con expresión perdida e vós dous vos quedades mirando fixamente. Ao final, Monit determina que non tes sistema operativo e comeza a reiniciar freneticamente.

Despois de reiniciar, o porto segue sendo o 8081. Monit tenta entón sondar o porto 80, o cal tamén falla, polo que se reinicia de novo. Este ciclo repítese ata que Monit decide que non se pode reparar e o tempo de espera esgotase.

Cando me atopei con isto por primeira vez, quedei abraiado de verdade. Nove de cada dez tutoriais que atopei en liña usaban o porto 80. Se os seguiches, o problema non estaba en ti, senón na propia fonte da información.

Un ficheiro PID de Apache2 corrupto fixo que Monit identificase erroneamente o proceso como inexistente.

Despois de cambiar o porto de 80 a 8081, Monit debería teoricamente ser capaz de detectalo, non si?

Non obstante, en realidade, aínda informa ocasionalmente de " Fallou a execución ".

Despois de loitar durante moito tempo, finalmente descubrín que a razón era sinxela: o ficheiro PID estaba corrompido.

Pensa niso, Monit estaba reiniciando Apache2 freneticamente, matándoo e reiniciándoo á forza cada vez, indo e vindo varias veces. Durante este proceso, o ficheiro /var/run/apache2/apache2.pid podería chegar a ocupar 0 bytes.

Noutras palabras, o ficheiro aínda está aí, pero está baleiro.

Cando Monit le este ficheiro, non atopa nada. Non recoñece o teu Apache2, mesmo se o teu Apache2 se executa perfectamente en segundo plano; Monit non cre que o proceso exista.

Cando vin isto, quedei sen palabras por un intre.

Isto é un punto morto. Monit non detecta a instancia de Apache 2, reinicia Apache2, corrompe o ficheiro PID durante o proceso de reinicio, falla na seguinte detección e reiníciase de novo. Este ciclo continúa ata que se produce o tempo de espera.

Pasos de resolución de problemas e reparación para a monitorización de Apache2 no entorno HestiaCP

Para ser sincero, o proceso de investigación non é complicado, pero cómpre saber en que dirección investigar.

O primeiro paso é determinar en que porto está escoitando o teu Apache2. Simplemente escribe un comando no terminal.

netstat -tulpn | grep apache2

Alternativamente, podes usar o comando `ss`; o efecto é o mesmo.

ss -tulpn | grep apache2

Verás unha saída semellante a esta.

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

Confirmouse que é 8081, non 80. Esa é a raíz do problema.

O segundo paso é reparar o ficheiro PID corrompido. Isto é máis sinxelo.

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

Primeiro, pausa a monitorización de Monit para evitar que interfira mentres arranxas cousas. Despois, reinicia Apache2 para permitir que reescriba un PID limpo. Finalmente, usa `cat` para comprobar o contido do ficheiro; debe conter unha cadea de números, non unha cadea baleira.

Unha vez completado este paso, o problema está basicamente resolto.

Análise comparativa das configuracións de protección adaptativa e agresiva tradicionais de Monit

Os titoriais en liña sobre a configuración de Apache2 con Monit xeralmente divídense en dúas categorías.

Un tipo é o "tipo de adaptación tradicional", que usa o comando `service` para xestionar servizos e comprobar portos locais sen engadir demasiadas restricións complicadas. Esta configuración pódese usar en HestiaCP simplemente cambiando o porto e é relativamente estable.

Outra estratexia é o método de "protección agresiva", que emprega systemctl para xestionar os servizos, engade restricións de procesos fillos e emprega unha lóxica de detección máis estrita. Ten un aspecto estupendo, pero ten un defecto fatal: o comando de parada empregado é `killall -9`.

Que significa `killall -9`? Significa matar o dispositivo á forza independentemente do que estea facendo. Esta operación de forza bruta pode deixar facilmente ficheiros PID corrompidos, que é o problema que acabo de mencionar.

A miña experiencia persoal é que limitar o número de procesos fillos nunha configuración agresiva é realmente útil. Cando o teu Apache2 se ve desbordado por un ataque CC, limitar o número de procesos fillos pode evitar que o servidor quede sen memoria. Non obstante, o enfoque `killall -9` é realmente inutilizable.

Así que ao final fixen un compromiso e combinei as vantaxes de ambas configuracións.

Configuración das mellores prácticas de HestiaCP para a monitorización de Apache2

Modifica o ficheiro /etc/monit/conf.d/apache2 co seguinte contido.

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

Permítanme explicar brevemente a lóxica que se agocha tras estas poucas liñas de configuración.

Escribe o porto 8081 para que coincida precisamente coa arquitectura de proxy inverso de HestiaCP; deixa de escribir tolasmente no porto 80.

Usa o comando `systemctl stop` en vez de `killall -9` para deter o ficheiro PID, para non corrompelo.

Engadiuse un límite de procesos fillos: se o número de fillos supera os 120, o proceso reiniciarase despois de dous ciclos consecutivos para evitar ataques CC, pero non é demasiado agresivo.

Modificouse a lóxica para detectar fallos para usar unha estratexia de "2 ciclos", o que significa que só se reinicia despois de dous fallos consecutivos, o que reduce os falsos positivos. A configuración anterior, que se reiniciaba despois dunha soa detección, era, francamente, un pouco demasiado sensible.

O limiar de tempo límite final reláxase a 5 reinicios dentro de 10 ciclos, o que deixa unha tolerancia a fallos suficiente.

HestiaCP Monitorización do seguimentoResumo da resolución de problemas de configuración e intercambio de experiencias

Despois de facer os cambios de configuración, monitoricei apache2 e o panel finalmente mostrou un indicador verde de "OK".

Como describir os meus sentimentos nese momento? Foi coma pasar dous días loitando cun erro, só para descubrir que a causa era unha única liña de configuración incorrecta. Foi frustrante e risible ao mesmo tempo.

Monit é algo bo en si mesmo, e a monitorización de daemons é algo que todos os servidores deberían facer. Pero o problema é que moitos tutoriais en liña baséanse na suposición de que "Apache2 usa exclusivamente o porto 80", mentres que HestiaCP usa un proxy inverso, o que significa que esta suposición non se cumpre.

Se segues as instrucións, o problema non es ti; é que o tutorial é aplicable a un escenario diferente ao teu.

Entón, se tamén estás a usar HestiaCP e a experimentar con Monit para monitorizar Apache2, lembra dúas cousas: cambia o porto a 8081 e usa o comando `systemctl` para detelo, non `killall -9`. Se fas estas dúas cousas, deberías poder evitar máis problemas.

Xa que leches ata aquí, se che resultou útil, por favor, dálle a "Gústame" e compárteo. Se queres recibir actualizacións primeiro, tamén podes seguirme!

Grazas por ler o meu artigo. Ata a próxima.