Prăbușiri frecvente ale Apache2 cu HestiaCP? Ghid automat de monitorizare și depanare Monit (cu configurare completă)

Prăbușiri frecvente ale Apache2 sau erori de repornire automată a Monit în mediile HestiaCP ? Acest articol oferă un ghid practic pentru evitarea capcanelor comune la monitorizarea Apache2 cu Monit, analizând în profunzime problemele comune, cum ar fi alinierea greșită a căii PID și blocarea permisiunilor și oferind fișiere de configurare a automatizării Monit la nivel de producție. Stăpâniți acum tehnici de întreținere a serverului cu disponibilitate ridicată și obțineți o recuperare automată de nivel secundar după erori!

Capcanele pe care le-am întâlnit în timp ce foloseam Monit pentru a monitoriza Apache2

Vinerea trecută, serverul mi-a dat o alertă Monit în toiul nopții.

M-am uitat amețit la panou și, în coloana de stare a apache2, era un Timeout roșu.

M-am gândit puțin la asta. Tocmai am adăugat monitorizarea Monit pe server în timpul zilei și am copiat și lipit configurația dintr-un tutorial online. Nu ar trebui să fie probleme, nu?

A doua zi dimineață, a expirat din nou. După a treia oară, Monitorul pur și simplu a renunțat, iar tabloul de bord a afișat „Nemonitorizat”.

Eu...

Recunosc, nu am luat-o în serios la început. Monitorizare Apache2? Poți găsi o mulțime de configurații de șabloane online, trebuie doar să copiezi și să lipești. Dar procesul ăla de lipire m-a înfuriat foarte tare.

Cauza principală a conflictului dintre arhitectura implicită a HestiaCP și porturile Monit

Permiteți-mi să vă arăt mai întâi configurația care mi-a cauzat atâtea probleme, ca să puteți vedea dacă este exact aceeași cu versiunea pe care ați văzut-o.

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 în regulă, nu? Verifică portul 80 și, dacă se blochează, repornește. Dacă se blochează în continuare după 5 reporniri, expiră timpul de așteptare.

Problema este că Apache2-ul tău nici măcar nu rulează pe portul 80.

Aceasta este o capcană a HestiaCP și cauza principală pentru care mulți oameni cad în ea. Arhitectura implicită a HestiaCP este un proxy invers al Nginx + Apache2, cu Nginx ocupând porturile 80 și 443 în față, iar Apache2 rulând pe portul local 8081 în spate.

Dacă îi ceri lui Monit să testeze dacă Apache2 funcționează pe portul 80, e ca și cum ai merge la McDonald's să cauți un KFC. Serverul se uită la tine cu o privire goală, iar voi doi vă priviți unul pe celălalt. În cele din urmă, Monit constată că nu mai funcționează și începe să repornească frenetic.

După repornire, portul este tot 8081. Monit încearcă apoi să testeze portul 80, dar, de asemenea, eșuează, așa că repornește din nou. Acest ciclu se repetă până când Monit decide că este ireparabil și expiră timpul de așteptare.

Când am dat peste asta prima dată, am fost sincer uluit. Nouă din zece tutoriale pe care le-am găsit online foloseau portul 80. Dacă le-ai urmat, problema nu era la tine, ci la sursa informației în sine.

Un fișier PID Apache2 corupt a determinat Monit să identifice în mod eronat procesul ca fiind inexistent.

După schimbarea portului de la 80 la 8081, Monit ar trebui teoretic să îl poată detecta, nu?

Totuși, în realitate, încă raportează ocazional mesajul „Execuția a eșuat ”.

După ce m-am chinuit mult timp, am descoperit în sfârșit că motivul era simplu: fișierul PID era corupt.

Gândește-te, Monit repornea frenetic Apache2, de fiecare dată oprindu-l și repornindu-l forțat, mergând înainte și înapoi de mai multe ori. În timpul acestui proces, fișierul /var/run/apache2/apache2.pid putea deveni 0 octeți.

Cu alte cuvinte, fișierul este încă acolo, dar este gol.

Când Monit citește acest fișier, nu găsește nimic. Nu recunoaște Apache2-ul tău, chiar dacă rulează perfect în fundal; Monit nu crede că procesul există.

Când am văzut asta, am rămas fără cuvinte pentru o clipă.

Acesta este un blocaj. Monit nu reușește să detecteze instanța Apache 2, repornește Apache2, corupe fișierul PID în timpul procesului de repornire, eșuează la următoarea detectare și repornește din nou. Acest ciclu continuă până când apare o expirare.

Pași de depanare și reparare pentru monitorizarea Apache2 în mediul HestiaCP

Ca să fiu sincer, procesul de investigație nu este complicat, dar trebuie să știi în ce direcție să investighezi.

Primul pas este să determinați pe ce port ascultă serverul Apache2. Pur și simplu tastați o comandă în terminal.

netstat -tulpn | grep apache2

Alternativ, puteți utiliza comanda `ss`; efectul este același.

ss -tulpn | grep apache2

Veți vedea un rezultat similar cu acesta.

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

S-a confirmat că este 8081, nu 80. Aceasta este cauza problemei.

Al doilea pas este repararea fișierului PID corupt. Acest lucru este mai simplu.

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

Mai întâi, întrerupe monitorizarea Monit pentru a o împiedica să interfereze în timp ce repari lucrurile. Apoi, repornește Apache2 pentru a-i permite să rescrie un PID curat. În cele din urmă, folosește `cat` pentru a verifica conținutul fișierului; acesta ar trebui să conțină un șir de numere, nu un șir gol.

Odată ce acest pas este finalizat, problema este practic rezolvată.

Analiza comparativă a configurațiilor de protecție adaptive și agresive tradiționale Monit

Tutorialele online despre configurarea Apache2 cu Monit se împart în general în două categorii.

Un tip este „tipul tradițional de adaptare”, care folosește comanda `service` pentru a gestiona serviciile și a verifica porturile locale fără a adăuga prea multe restricții complicate. Această configurație poate fi utilizată pe HestiaCP prin simpla schimbare a portului și este relativ stabilă.

O altă abordare este metoda de „protecție agresivă”, care folosește systemctl pentru a gestiona serviciile, adaugă restricții pentru procesele copil și folosește o logică de detectare mai strictă. Arată grozav, dar are un defect fatal: comanda de oprire utilizată este `killall -9`.

Ce înseamnă `killall -9`? Înseamnă închiderea forțată a dispozitivului, indiferent de ceea ce face. Această operațiune de tip „brute force” poate lăsa în urmă cu ușurință fișiere PID corupte, aceasta fiind problema pe care tocmai am menționat-o.

Experiența mea personală este că limitarea numărului de procese fiu într-o configurație agresivă este într-adevăr utilă. Când Apache2 este copleșit de un atac CC, limitarea numărului de procese fiu poate împiedica serverul să rămână fără memorie. Cu toate acestea, abordarea `killall -9` este cu adevărat inutilizabilă.

Așa că, în cele din urmă, am făcut un compromis și am combinat avantajele ambelor configurații.

Configurarea celor mai bune practici pentru HestiaCP Apache2 Monit

Modificați fișierul /etc/monit/conf.d/apache2 cu următorul conținut.

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

Permiteți-mi să explic pe scurt logica din spatele acestor câteva linii de configurație.

Scrieți portul 8081 pentru a se potrivi exact cu arhitectura proxy inversă a HestiaCP; nu mai scrieți prostește pe portul 80.

Folosește comanda `systemctl stop` în loc de `killall -9` pentru a opri fișierul PID, astfel încât să nu-l corupi.

A fost adăugată o limită pentru procesele fiu: dacă numărul de fii depășește 120, procesul va reporni după două cicluri consecutive pentru a preveni atacurile CC, dar nu este prea agresiv.

Logica de detectare a defecțiunilor a fost modificată pentru a utiliza o abordare „pentru 2 cicluri”, ceea ce înseamnă că o repornire este declanșată doar după două defecțiuni consecutive, reducând numărul de falsuri pozitive. Configurația anterioară, care repornea după o singură detectare, era sincer puțin cam prea sensibilă.

Pragul final de timeout este relaxat la 5 reporniri în 10 cicluri, lăsând o toleranță suficientă la erori.

HestiaCP Monitorizarea monitorizariiRezumatul depanării configurației și împărtășirea experienței

După ce am făcut modificările de configurație, am monitorizat apache2, iar panoul a afișat în sfârșit un indicator verde „OK”.

Cum să descriu sentimentele mele de atunci? A fost ca și cum aș fi petrecut două zile luptându-mă cu o eroare, doar pentru a descoperi că cauza era o singură linie de configurare greșită. A fost frustrant și amuzant în același timp.

Monit este un lucru bun în sine, iar monitorizarea daemonilor este ceva ce ar trebui să facă fiecare server. Dar problema este că multe tutoriale online se bazează pe presupunerea că „Apache2 folosește exclusiv portul 80”, în timp ce HestiaCP folosește un proxy invers, ceea ce înseamnă că această presupunere nu este valabilă.

Dacă urmezi instrucțiunile, problema nu ești tu; ci faptul că tutorialul este aplicabil unui scenariu diferit de al tău.

Deci, dacă folosești și HestiaCP și te joci cu Monit pentru a monitoriza Apache2, amintește-ți doar două lucruri: schimbă portul la 8081 și folosește comanda `systemctl` pentru a-l opri, nu `killall -9`. Dacă faci aceste două lucruri, ar trebui să poți evita orice alte probleme.

Din moment ce ați citit până aici, dacă vi s-a părut util, vă rog să dați like și să distribuiți. Dacă doriți să primiți actualizări mai întâi, puteți să mă urmăriți și pe mine!

Mulțumesc că ai citit articolul meu. Pe data viitoare.