Arresti anomali frequenti di Apache2 con HestiaCP? Guida al monitoraggio automatico e alla risoluzione dei problemi di Monit (con configurazione completa)

Arresti anomali frequenti di Apache2 o errori di riavvio automatico di Monit negli ambienti HestiaCP ? Questo articolo fornisce una guida pratica per evitare gli errori più comuni nel monitoraggio di Apache2 con Monit, analizzando a fondo problematiche frequenti come il disallineamento del percorso PID e il blocco dei permessi, e offrendo file di configurazione per l'automazione di Monit di livello produttivo. Padroneggia subito le tecniche di manutenzione dei server ad alta disponibilità e ottieni un ripristino automatico di secondo livello in caso di guasti!

Le insidie ​​che ho incontrato durante l'utilizzo di Monit per monitorare Apache2

Venerdì scorso, il server mi ha inviato un avviso Monit nel cuore della notte.

Ho dato un'occhiata distratta al pannello e nella colonna dello stato di apache2 è apparso un Timeout in rosso.

Ci ho pensato un po'. Ho appena aggiunto il monitoraggio Monit al server durante il giorno e ho copiato e incollato la configurazione da un tutorial online. Non dovrebbero esserci problemi, giusto?

La mattina successiva, si è verificato un altro timeout. Dopo la terza volta, Monitor ha semplicemente rinunciato e sul pannello è apparso il messaggio "Non monitorato".

IO...

Lo ammetto, all'inizio non l'ho preso sul serio. Monitoraggio di Apache2? Si trovano tantissime configurazioni predefinite online, basta copiare e incollare. Ma quel processo di incollaggio mi ha fatto davvero infuriare.

La causa principale del conflitto tra l'architettura predefinita di HestiaCP e le porte di Monit

Innanzitutto, permettetemi di mostrarvi la configurazione che mi ha causato tanti problemi, così potrete verificare se è esattamente identica alla versione che avete visto.

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

Sembra tutto a posto, vero? Controlla la porta 80 e, se si blocca, si riavvia. Se si blocca ancora dopo 5 riavvii, va in timeout.

Il problema è che il tuo Apache2 non è nemmeno in esecuzione sulla porta 80.

Questo è un punto debole di HestiaCP e la causa principale per cui molte persone ci cadono in trappola. L'architettura predefinita di HestiaCP è un reverse proxy di Nginx + Apache2, con Nginx che occupa le porte 80 e 443 sul front-end e Apache2 in esecuzione sulla porta locale 8081 sul back-end.

Se chiedi a Monit di verificare lo stato di Apache2 sulla porta 80, è come andare da McDonald's e cercare il KFC. Il server ti guarda con aria perplessa e voi due vi fissate a vicenda. Alla fine, Monit determina che il server è offline e inizia a riavviarlo freneticamente.

Dopo il riavvio, la porta rimane la 8081. Monit tenta quindi di sondare la porta 80, operazione che fallisce, e si riavvia di nuovo. Questo ciclo si ripete finché Monit non decide che non è più possibile ripararlo e va in timeout.

Quando mi sono imbattuto in questo problema per la prima volta, sono rimasto sinceramente sbalordito. Nove tutorial su dieci che ho trovato online utilizzavano la porta 80. Se li avete seguiti, il problema non era vostro, ma della fonte stessa delle informazioni.

Un file PID di Apache2 danneggiato ha indotto Monit a identificare erroneamente il processo come inesistente.

Dopo aver cambiato la porta da 80 a 8081, Monit dovrebbe teoricamente essere in grado di rilevarlo, giusto?

Tuttavia, in realtà, a volte segnala ancora "Esecuzione non riuscita ".

Dopo aver faticato a lungo, ho finalmente scoperto che la ragione era semplice: il file PID era danneggiato.

Pensaci, Monit stava riavviando freneticamente Apache2, arrestandolo e riavviandolo forzatamente ogni volta, ripetendo l'operazione più volte. Durante questo processo, il file /var/run/apache2/apache2.pid potrebbe diventare di 0 byte.

In altre parole, il file è ancora presente, ma è vuoto.

Quando Monit legge questo file, non trova nulla. Non riconosce il tuo Apache2, anche se Apache2 è in esecuzione senza problemi in background; Monit non pensa che il processo esista.

Quando ho visto ciò, sono rimasto senza parole per un attimo.

Si tratta di una situazione di stallo. Monit non riesce a rilevare l'istanza di Apache 2, riavvia Apache2, corrompe il file PID durante il processo di riavvio, fallisce al successivo rilevamento e si riavvia di nuovo. Questo ciclo continua fino al verificarsi del timeout.

Procedure di risoluzione dei problemi e riparazione per il monitoraggio di Apache2 nell'ambiente HestiaCP

A dire il vero, il processo investigativo non è complicato, ma bisogna sapere in quale direzione indagare.

Il primo passo è determinare su quale porta è in ascolto Apache2. È sufficiente digitare un comando nel terminale.

netstat -tulpn | grep apache2

In alternativa, puoi usare il comando `ss`; l'effetto è lo stesso.

ss -tulpn | grep apache2

Vedrai un output simile a questo.

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

È confermato che si tratta di un 8081, non di un 80. Questa è la radice del problema.

Il secondo passaggio consiste nel riparare il file PID danneggiato. Questa operazione è più semplice.

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

Innanzitutto, metti in pausa il monitoraggio di Monit per evitare che interferisca mentre stai risolvendo il problema. Quindi, riavvia Apache2 per consentirgli di riscrivere un PID pulito. Infine, usa `cat` per controllare il contenuto del file; dovrebbe contenere una stringa di numeri, non una stringa vuota.

Una volta completato questo passaggio, il problema è sostanzialmente risolto.

Analisi comparativa delle configurazioni protettive tradizionali, adattive e aggressive di Monit

I tutorial online sulla configurazione di Apache2 con Monit si dividono generalmente in due categorie.

Un tipo è quello di "adattamento tradizionale", che utilizza il comando `service` per gestire i servizi e controllare le porte locali senza aggiungere troppe restrizioni complicate. Questa configurazione può essere utilizzata su HestiaCP semplicemente cambiando la porta ed è relativamente stabile.

Un altro approccio è il metodo di "protezione aggressiva", che utilizza systemctl per gestire i servizi, aggiunge restrizioni ai processi figli e impiega una logica di rilevamento più rigorosa. Sembra ottimo, ma ha un difetto fatale: il comando di arresto utilizzato è `killall -9`.

Cosa significa `killall -9`? Significa terminare forzatamente il dispositivo, indipendentemente da ciò che sta facendo. Questa operazione bruta può facilmente lasciare file PID corrotti, che è il problema che ho appena menzionato.

La mia esperienza personale mi dice che limitare il numero di processi figli in una configurazione aggressiva è effettivamente utile. Quando il tuo Apache2 viene sovraccaricato da un attacco CC, limitare il numero di processi figli può impedire al server di esaurire la memoria. Tuttavia, il metodo `killall -9` è assolutamente inutilizzabile.

Alla fine ho optato per un compromesso, combinando i vantaggi di entrambe le configurazioni.

Configurazione ottimale di HestiaCP Apache2 Monit

Modifica il file /etc/monit/conf.d/apache2 con il seguente contenuto.

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

Permettetemi di spiegare brevemente la logica alla base di queste poche righe di configurazione.

Modifica la porta 8081 in modo che corrisponda esattamente all'architettura del reverse proxy di HestiaCP; smetti di modificare inutilmente la porta 80.

Per arrestare il file PID ed evitare di corromperlo, utilizzare il comando `systemctl stop` anziché `killall -9`.

È stato aggiunto un limite per i processi figli: se il numero di figli supera 120, il processo si riavvierà dopo due cicli consecutivi per prevenire attacchi CC, ma non è eccessivamente restrittivo.

La logica per il rilevamento dei guasti è stata modificata per utilizzare un approccio "per 2 cicli", il che significa che il riavvio viene attivato solo dopo due guasti consecutivi, riducendo i falsi positivi. La configurazione precedente, che si riavviava dopo un solo rilevamento, era francamente un po' troppo sensibile.

La soglia di timeout finale è stata ridotta a 5 riavvii entro 10 cicli, garantendo una tolleranza ai guasti sufficiente.

EstiaCP Monitorare il monitoraggioRiepilogo della risoluzione dei problemi di configurazione e condivisione delle esperienze

Dopo aver apportato le modifiche alla configurazione, ho monitorato apache2 e il pannello ha finalmente mostrato un indicatore verde "OK".

Come descrivere le mie sensazioni in quel momento? Era come passare due giorni a lottare con un bug, solo per scoprire che la causa era una singola riga di configurazione errata. Era allo stesso tempo frustrante e ridicolo.

Monit è di per sé un'ottima soluzione, e il monitoraggio dei daemon è un'attività che ogni server dovrebbe svolgere. Il problema, però, è che molti tutorial online si basano sul presupposto che "Apache2 utilizzi esclusivamente la porta 80", mentre HestiaCP utilizzi un reverse proxy, il che significa che tale presupposto non è corretto.

Se segui le istruzioni, il problema non sei tu; il problema è che il tutorial è applicabile a uno scenario diverso dal tuo.

Quindi, se anche voi utilizzate HestiaCP e Monit per monitorare Apache2, ricordate due cose: cambiate la porta in 8081 e usate il comando `systemctl` per arrestarlo, non `killall -9`. Se seguite questi due consigli, dovreste evitare ulteriori problemi.

Visto che sei arrivato a leggere fin qui, se hai trovato utile questo articolo, metti mi piace e condividilo. Se vuoi ricevere gli aggiornamenti in anteprima, puoi anche seguirmi!

Grazie per aver letto il mio articolo. Alla prossima.