Česti padovi Apache2 sa HestiaCP? Vodič za automatsko praćenje i rješavanje problema Monit (sa kompletnom konfiguracijom)

Česti padovi Apache2 ili greške pri automatskom ponovnom pokretanju Monita u HestiaCP okruženjima? Ovaj članak pruža praktičan vodič za izbjegavanje uobičajenih zamki prilikom praćenja Apache2 pomoću Monita, dubinski analizirajući uobičajene probleme kao što su neusklađenost PID putanje i blokiranje dozvola, te nudeći konfiguracijske datoteke za automatizaciju Monita produkcijskog nivoa. Savladajte tehnike održavanja servera visoke dostupnosti sada i postignite automatski oporavak drugog nivoa od kvarova!

Zamke na koje sam naišao prilikom korištenja Monita za praćenje Apache2

Prošlog petka, server mi je usred noći poslao Monit upozorenje.

U bunilu sam bacio pogled na panel i u koloni statusa apache2, prikazivalo se crveno "Timeout".

Malo sam razmišljao o tome. Upravo sam tokom dana dodao Monit monitoring na server i kopirao konfiguraciju iz online tutorijala. Ne bi trebalo biti problema, zar ne?

Sljedećeg jutra, vrijeme je ponovo isteklo. Nakon trećeg pokušaja, Monitor je jednostavno odustao, a panel je prikazao "Nije nadzirano".

Ja...

Priznajem, nisam to u početku shvatio ozbiljno. Praćenje Apache2? Možete pronaći gomilu konfiguracija predložaka na internetu, samo kopirajte i zalijepite. Ali taj proces lijepljenja me je zaista razbjesnio.

Osnovni uzrok konflikta između HestiaCP-ove zadane arhitekture i Monit portova

Prvo ću vam pokazati konfiguraciju koja mi je uzrokovala toliko problema, kako biste mogli vidjeti da li je potpuno ista kao verzija koju ste vidjeli.

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

Izgleda dobro, zar ne? Provjerava port 80 i ako se sruši, ponovo se pokreće. Ako se i dalje ruši nakon 5 ponovnih pokretanja, ističe vremensko ograničenje.

Problem je što vaš Apache2 čak ni ne radi na portu 80.

Ovo je zamka HestiaCP-a i glavni uzrok zašto mnogi ljudi upadaju u njega. Zadana arhitektura HestiaCP-a je obrnuti proxy Nginx + Apache2, gdje Nginx zauzima portove 80 i 443 sprijeda, a Apache2 radi na lokalnom portu 8081 pozadi.

Ako zamolite Monita da provjeri dostupnost Apache2 na portu 80, to je kao da idete u McDonald's da pronađete KFC. Konobar vas gleda prazno, a vas dvojica se gledate. Na kraju, Monit shvati da ste u kvaru i počne panično ponovo pokretati računar.

Nakon ponovnog pokretanja, port je i dalje 8081. Monit zatim pokušava ispitati port 80, što također ne uspijeva, pa se ponovo pokreće. Ovaj ciklus se ponavlja sve dok Monit ne odluči da je nepopravljiv i istekne vrijeme.

Kada sam se prvi put susreo s ovim, bio sam iskreno zapanjen. Devet od deset tutorijala koje sam pronašao na internetu koristilo je port 80. Ako ste ih pratili, problem nije bio u vama, već u samom izvoru informacija.

Oštećena Apache2 PID datoteka uzrokovala je da Monit pogrešno identificira proces kao nepostojeći.

Nakon promjene porta sa 80 na 8081, Monit bi teoretski trebao biti u stanju da ga detektuje, zar ne?

Međutim, u stvarnosti, i dalje povremeno prijavljuje "Izvršavanje nije uspjelo ".

Nakon dugog mučenja, konačno sam otkrio da je razlog jednostavan: PID datoteka je bila oštećena.

Razmislite o tome, Monit je frenetično restartovao Apache2, svaki put ga prisilno ubijajući i ponovo pokrećući, prelazeći naprijed-nazad nekoliko puta. Tokom ovog procesa, datoteka /var/run/apache2/apache2.pid je mogla postati 0 bajtova.

Drugim riječima, datoteka je još uvijek tu, ali je prazna.

Kada Monit čita ovu datoteku, ne pronalazi ništa. Ne prepoznaje vaš Apache2, čak i ako vaš Apache2 radi savršeno ispravno u pozadini; Monit misli da proces ne postoji.

Kad sam ovo vidio, na trenutak sam ostao bez riječi.

Ovo je zastoj. Monit ne uspijeva detektirati instancu Apache 2, ponovo pokreće Apache 2, oštećuje PID datoteku tokom procesa ponovnog pokretanja, ne uspijeva pri sljedećoj detekciji i ponovo pokreće sistem. Ovaj ciklus se nastavlja sve dok ne istekne vremensko ograničenje.

Koraci za rješavanje problema i popravak za Apache2 monitoring u HestiaCP okruženju

Iskreno, proces istrage nije kompliciran, ali morate znati u kojem smjeru istraživati.

Prvi korak je odrediti na kojem portu vaš Apache2 sluša. Jednostavno ukucajte komandu u terminal.

netstat -tulpn | grep apache2

Alternativno, možete koristiti naredbu `ss`; efekat je isti.

ss -tulpn | grep apache2

Vidjet ćete izlaz sličan ovome.

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

Potvrđeno je da je u pitanju 8081, a ne 80. To je korijen problema.

Drugi korak je popravak oštećene PID datoteke. Ovo je jednostavnije.

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

Prvo, pauzirajte Monitovo praćenje kako biste spriječili njegovo ometanje dok popravljate stvari. Zatim, ponovo pokrenite Apache2 kako biste mu omogućili da prepiše čisti PID. Na kraju, koristite `cat` za provjeru sadržaja datoteke; trebao bi sadržavati niz brojeva, a ne prazan niz.

Nakon što se ovaj korak završi, problem je u osnovi riješen.

Komparativna analiza Monitovih tradicionalnih adaptivnih i agresivnih zaštitnih konfiguracija

Online tutorijali o konfigurisanju Apache2 sa Monitom uglavnom se svrstavaju u dvije kategorije.

Jedan tip je "tradicionalni tip adaptacije", koji koristi naredbu `service` za upravljanje servisima i provjeru lokalnih portova bez dodavanja previše kompliciranih ograničenja. Ova konfiguracija se može koristiti na HestiaCP-u jednostavnom promjenom porta i relativno je stabilna.

Drugi pristup je metoda "agresivne zaštite", koja koristi systemctl za upravljanje servisima, dodaje ograničenja za podprocese i primjenjuje strožu logiku detekcije. Izgleda sjajno, ali ima fatalnu manu: korištena naredba za zaustavljanje je `killall -9`.

Šta znači `killall -9`? To znači prisilno ubiti uređaj bez obzira na to šta radi. Ova brute-force operacija može lako ostaviti iza sebe oštećene PID datoteke, što je problem koji sam upravo spomenuo.

Moje lično iskustvo je da ograničavanje broja podređenih procesa u agresivnoj konfiguraciji zaista jeste korisno. Kada je vaš Apache2 preopterećen CC napadom, ograničavanje broja podređenih procesa može spriječiti da server ostane bez memorije. Međutim, pristup `killall -9` je zaista neupotrebljiv.

Tako da sam na kraju napravio kompromis i kombinovao prednosti obje konfiguracije.

Najbolja praksa konfiguracije HestiaCP Apache2 Monita

Izmijenite datoteku /etc/monit/conf.d/apache2 sljedećim sadržajem.

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

Dozvolite mi da ukratko objasnim logiku koja stoji iza ovih nekoliko konfiguracijskih redova.

Napišite port 8081 da precizno odgovara arhitekturi obrnutog proxyja HestiaCP-a; prestanite glupo pisati port 80.

Koristite naredbu `systemctl stop` umjesto `killall -9` da biste zaustavili PID datoteku, kako je ne biste oštetili.

Dodato je ograničenje za podređene procese: ako broj podređenih procesa premaši 120, proces će se ponovo pokrenuti nakon dva uzastopna ciklusa kako bi se spriječili CC napadi, ali to nije previše agresivno.

Logika za detekciju kvarova je modificirana tako da koristi pristup "za 2 ciklusa", što znači da se ponovno pokretanje pokreće tek nakon dva uzastopna kvara, smanjujući lažno pozitivne rezultate. Prethodna konfiguracija, koja je vršila ponovno pokretanje nakon samo jednog detektiranja, bila je, iskreno rečeno, malo previše osjetljiva.

Konačni prag isteka vremena je smanjen na 5 ponovnih pokretanja unutar 10 ciklusa, ostavljajući dovoljnu toleranciju na greške.

HestiaCP Monitor monitoringSažetak rješavanja problema s konfiguracijom i dijeljenje iskustva

Nakon što sam napravio promjene u konfiguraciji, pratio sam apache2 i panel je konačno pokazao zeleni indikator "OK".

Kako da opišem svoja osjećanja u tom trenutku? Bilo je kao da sam se dva dana borio s greškom, samo da bih otkrio da je uzrok bila jedna pogrešna linija konfiguracije. Bilo je i frustrirajuće i smiješno.

Monit je sam po sebi dobra stvar, a praćenje demona je nešto što bi svaki server trebao raditi. Ali problem je što se mnogi online tutorijali zasnivaju na pretpostavci da "Apache2 isključivo koristi port 80", dok HestiaCP koristi obrnuti proxy, što znači da ova pretpostavka ne vrijedi.

Ako pratite upute, problem nije u vama; problem je u tome što je tutorijal primjenjiv na drugačiji scenario od vašeg.

Dakle, ako koristite i HestiaCP i igrate se s Monitom za praćenje Apache2, samo zapamtite dvije stvari: Promijenite port na 8081 i koristite naredbu `systemctl` da ga zaustavite, a ne `killall -9`. Ako uradite ove dvije stvari, trebali biste moći izbjeći daljnje probleme.

Pošto ste pročitali do sada, ako vam je bilo korisno, molimo vas da lajkujete i podijelite. Ako želite prvi primati novosti, možete me i pratiti!

Hvala vam što ste pročitali moj članak. Vidimo se sljedeći put.