Crash frequenti di Apache2 cù HestiaCP? Guida di monitoraghju automatizatu è risoluzione di prublemi Monit (cù cunfigurazione cumpleta)

Crash frequenti di Apache2 o fallimenti di riavviu automaticu di Monit in ambienti HestiaCP ? Questu articulu furnisce una guida pratica per evità i trappule cumuni quandu si monitorizza Apache2 cù Monit, analizendu in prufundità i prublemi cumuni cum'è u disallineamentu di u percorsu PID è u bloccu di permessi, è offrendu fugliali di cunfigurazione di automatizazione Monit di qualità di pruduzzione. Maestrate avà e tecniche di manutenzione di u servitore à alta dispunibilità è ottenete una ripresa automatica di secondu livellu da i fallimenti!

I periculi chì aghju scontru mentre utilizava Monit per monitorà Apache2

U venneri scorsu, u servitore m'hà datu un alerta Monit in piena notte.

Aghju datu un'ochjata à u pannellu in un statu sturditu, è in a colonna di statutu apache2, ci era un Timeout rossu.

Ci aghju pensatu un pocu. Aghju appena aghjuntu u monitoraghju Monit à u servitore durante u ghjornu, è aghju copiatu è incollatu a cunfigurazione da un tutoriale in linea. Ùn ci deve esse micca prublemi, nò ?

A mane dopu, u timeout hè scadutu di novu. Dopu à a terza volta, Monitor hà semplicemente rinunciatu, è u dashboard hà mostratu "Micca monitoratu".

I. . .

Devu ammette, ùn l'aghju micca pigliatu in seriu à u principiu. Monitoraghju Apache2 ? Pudete truvà tunnellate di cunfigurazioni di mudelli in linea, basta à copià è incollà. Ma quellu prucessu di incollà m'hà veramente fattu furiosu.

A causa principale di u cunflittu trà l'architettura predefinita di HestiaCP è i porti Monit

Lasciami prima mustrà ti a cunfigurazione chì m'hà causatu tanti prublemi, affinchì possi vede s'ella hè esattamente a listessa chè a versione chì hai vistu.

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

Pare bè, nò ? Verifica u portu 80, è s'ellu si blocca, si riavvia. S'ellu si blocca sempre dopu à 5 riavvii, u timeout hè scadutu.

U prublema hè chì u vostru Apache2 ùn funziona mancu nant'à u portu 80.

Questu hè un prublemu di HestiaCP, è a causa principale di parechje persone chì ci cascanu. L'architettura predefinita di HestiaCP hè un proxy inversu di Nginx + Apache2, cù Nginx chì occupa i porti 80 è 443 in fronte, è Apache2 chì funziona nantu à u portu lucale 8081 in daretu.

Sè dumandate à Monit di verificà a vita di Apache2 nant'à u portu 80, hè cum'è andà à McDonald's per truvà KFC. U servitore vi guarda cù un'espressione assente, è voi dui vi fissate. À a fine, Monit determina chì site cascatu è principia à riavvià freneticamente.

Dopu u riavviu, u portu hè sempre 8081. Monit prova tandu à sondà u portu 80, chì fiasca ancu ellu, dunque si riavvia di novu. Stu ciclu si ripete finu à chì Monit decide ch'ellu hè irreparabile è u timeout scade.

Quandu aghju scontru questu per a prima volta, eru veramente stupitu. Nove tutoriali nantu à dece chì aghju trovu in linea utilizavanu u portu 80. Sè l'avete seguitati, u prublema ùn era micca cun voi, ma cù a fonte stessa di l'infurmazione.

Un schedariu PID Apache2 curruttu hà fattu chì Monit identifichessi erroneamente u prucessu cum'è inesistente.

Dopu avè cambiatu u portu da 80 à 8081, Monit duveria teoricamente esse capace di rilevallu, nò?

Tuttavia, in realtà, segnala sempre à volte "Esecuzione fallita ".

Dopu avè luttatu per un bellu pezzu, aghju finalmente scupertu chì a ragione era simplice: u schedariu PID era curruttu.

Pensateci, Monit stava riavviendu freneticamente Apache2, ogni volta uccidendulu è riavviendulu à forza, andendu avanti è indietro parechje volte. Durante stu prucessu, u schedariu /var/run/apache2/apache2.pid puderia diventà 0 byte.

In altre parolle, u schedariu hè sempre quì, ma hè viotu.

Quandu Monit leghje stu schedariu, ùn trova nunda. Ùn ricunnosce micca u vostru Apache2, ancu s'ellu funziona perfettamente in u fondu; Monit ùn pensa micca chì u prucessu esista.

Quandu aghju vistu questu, sò statu senza parolle per un mumentu.

Questu hè un bloccu. Monit ùn riesce micca à rilevà l'istanza d'Apache 2, riavvia Apache2, currumpisce u schedariu PID durante u prucessu di riavviu, falla a prossima rilevazione è riavvia di novu. Stu ciclu cuntinueghja finu à chì si verifica un timeout.

Passi di risoluzione di i prublemi è di riparazione per u monitoraghju Apache2 in l'ambiente HestiaCP

À dì a verità, u prucessu d'inchiesta ùn hè micca cumplicatu, ma ci vole à sapè in chì direzzione investigà.

U primu passu hè di determinà quale portu u vostru Apache2 ascolta. Basta à scrive un cumandamentu in u terminal.

netstat -tulpn | grep apache2

In alternativa, pudete aduprà u cumandamentu `ss`; l'effettu hè listessu.

ss -tulpn | grep apache2

Viderete un output simile à questu.

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

Hè cunfirmatu ch'ellu hè 8081, micca 80. Hè a radica di u prublema.

U secondu passu hè di riparà u schedariu PID curruttu. Questu hè più simplice.

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

Prima, mette in pausa u monitoraghju di Monit per impedisce ch'ellu interferisca mentre state riparà e cose. Dopu, riavviate Apache2 per permetteli di riscrive un PID pulitu. Infine, aduprate `cat` per verificà u cuntenutu di u schedariu; deve cuntene una stringa di numeri, micca una stringa viota.

Una volta finitu stu passu, u prublema hè basicamente risoltu.

Analisi cumparativa di e cunfigurazioni di prutezzione adattive è aggressive tradiziunali di Monit

I tutoriali in linea nantu à a cunfigurazione di Apache2 cù Monit si dividenu generalmente in duie categurie.

Un tipu hè u "tipu d'adattazione tradiziunale", chì usa u cumandamentu `service` per gestisce i servizii è verificà i porti lucali senza aghjunghje troppu restrizioni cumplicate. Sta cunfigurazione pò esse aduprata nantu à HestiaCP semplicemente cambiendu u portu, è hè relativamente stabile.

Un altru approcciu hè u metudu di "prutezzione aggressiva", chì usa systemctl per gestisce i servizii, aghjusta restrizioni di prucessu figlioli è impiega una logica di rilevazione più stretta. Hà un bellu aspettu, ma hà un difettu fatale: u cumandamentu di stop utilizatu hè `killall -9`.

Chì significa `killall -9` ? Significa tumbà furzatamente u dispusitivu indipendentemente da ciò ch'ellu face. Questa operazione di forza bruta pò facilmente lascià daretu i fugliali PID currutti, chì hè u prublema chì aghju appena mintuvatu.

A mo sperienza persunale hè chì limità u numeru di prucessi figlioli in una cunfigurazione aggressiva hè veramente utile. Quandu u vostru Apache2 hè sopraffattu da un attaccu CC, limità u numeru di prucessi figlioli pò impedisce à u servitore di esaurisce a memoria. Tuttavia, l'approcciu `killall -9` hè veramente inutilizabile.

Cusì à a fine aghju fattu un compromisu è aghju cumminatu i vantaghji di e duie cunfigurazioni.

Cunfigurazione di e migliori pratiche di HestiaCP Apache2 Monit

Mudificà u schedariu /etc/monit/conf.d/apache2 cù u cuntenutu seguente.

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

Lasciami spiegà brevemente a logica daretu à queste poche linee di cunfigurazione.

Scrivite u portu 8081 per currisponde precisamente à l'architettura di proxy inversu di HestiaCP; smette di scrive stupidamente u portu 80.

Aduprate u cumandamentu `systemctl stop` invece di `killall -9` per fermà u schedariu PID, per ùn currumperlu.

Hè statu aghjuntu un limite di prucessu figliolu: se u numeru di figlioli supera 120, u prucessu ripartirà dopu à dui cicli consecutivi per impedisce l'attacchi CC, ma ùn hè micca troppu aggressivu.

A logica per a rilevazione di i guasti hè stata mudificata per aduprà un approcciu "per 2 cicli", vale à dì chì un riavviu hè attivatu solu dopu à dui guasti consecutivi, riducendu i falsi pusitivi. A cunfigurazione precedente, chì si riavviava dopu à una sola rilevazione, era francamente un pocu troppu sensibile.

A soglia di timeout finale hè rilassata à 5 riavvii in 10 cicli, lascendu una tolleranza à i guasti sufficiente.

HestiaCP Monit monitoringRiepilogu di a risoluzione di i prublemi di cunfigurazione è spartera di l'esperienza

Dopu avè fattu i cambiamenti di cunfigurazione, aghju monitoratu apache2, è u pannellu hà finalmente mostratu un indicatore verde "OK".

Cumu discrive i mo sentimenti à l'epica ? Era cum'è passà dui ghjorni à luttà cù un bug, solu per scopre chì a causa era una sola linea di cunfigurazione chì era sbagliata. Era à tempu frustrante è ridiculu.

Monit hè una bona cosa in sè stessu, è u monitoraghju di i daemon hè qualcosa chì ogni servitore duveria fà. Ma u prublema hè chì parechji tutoriali in linea sò basati nantu à l'ipotesi chì "Apache2 usa esclusivamente u portu 80", mentre chì HestiaCP usa un proxy inversu, ciò chì significa chì sta ipotesi ùn hè micca vera.

Sè seguite l'istruzzioni, u prublema ùn hè micca voi; hè chì u tutoriale hè applicabile à un scenariu diversu da u vostru.

Dunque, sè vo aduprate ancu HestiaCP è ghjucate cù Monit per monitorà Apache2, basta à ricurdà duie cose: Cambiate u portu à 8081, è aduprate u cumandamentu `systemctl` per fermallu, micca `killall -9`. Sè vo fate ste duie cose, duvete esse capace di evità altri prublemi.

Siccomu avete lettu finu à quì, sè l'avete trovu utile, per piacè lasciate un "mi piace" è spartitelu. Sè vo vulete riceve l'aghjurnamenti prima, pudete ancu seguità mi!

Grazie per avè lettu u mo articulu. À a prossima volta.