Česti rušenja Apache2 s HestiaCP? Vodič za automatsko praćenje i rješavanje problema Monit (s potpunom konfiguracijom)

Česti rušenja Apache2 ili kvarovi automatskog ponovnog pokretanja Monita u HestiaCP okruženjima? Ovaj članak pruža praktičan vodič za izbjegavanje uobičajenih zamki pri praćenju Apache2 pomoću Monita, dubinski analizirajući uobičajene probleme poput neusklađenosti PID putanje i blokiranja dozvola te nudeći konfiguracijske datoteke za automatizaciju Monita produkcijske razine. Savladajte tehnike održavanja visokodostupnih poslužitelja sada i postignite automatski oporavak druge razine od kvarova!

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

Prošli petak, poslužitelj mi je usred noći dao Monit upozorenje.

U bunilu sam pogledao na ploču i u stupcu statusa apache2 prikazao se crveni Timeout.

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

Sljedećeg jutra, vrijeme je opet isteklo. Nakon trećeg puta, Monitor je jednostavno odustao, a ploča je prikazala "Nije nadzirano".

Ja...

Priznajem, isprva to nisam shvatio ozbiljno. Praćenje Apache2? Možete pronaći hrpu konfiguracija predložaka na internetu, samo kopirajte i zalijepite. Ali taj proces lijepljenja me stvarno razbjesnio.

Osnovni uzrok sukoba između zadane arhitekture HestiaCP-a i Monit portova

Prvo ću vam pokazati konfiguraciju koja mi je uzrokovala toliko problema, kako biste mogli vidjeti je li 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

Čini se u redu, zar ne? Provjerava port 80 i ako se sruši, ponovno se pokreće. Ako se i dalje ruši nakon 5 ponovnih pokretanja, istječe vrijeme.

Problem je što tvoj Apache2 uopće 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, pri čemu Nginx zauzima portove 80 i 443 sprijeda, a Apache2 radi na lokalnom portu 8081 straga.

Ako zamolite Monita da provjeri živost Apache2 na portu 80, to je kao da idete u McDonald's pronaći KFC. Konobar vas prazno gleda, a vas dvoje se gledate. Na kraju, Monit shvati da ste u kvaru i počne panično ponovno pokretati računalo.

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

Kad 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 slijedili, 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 s 80 na 8081, Monit bi ga teoretski trebao moći detektirati, zar ne?

Međutim, u stvarnosti, još uvijek 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 mahnito ponovno pokretao Apache2, svaki put ga prisilno ubijajući i ponovno pokrećući, vraćajući se naprijed-natrag nekoliko puta. Tijekom tog procesa, datoteka /var/run/apache2/apache2.pid mogla bi 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 savršeno radi u pozadini; Monit misli da proces ne postoji.

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

Ovo je zastoj. Monit ne uspijeva otkriti instancu Apache 2, ponovno pokreće Apache 2, oštećuje PID datoteku tijekom procesa ponovnog pokretanja, ne uspijeva sljedeće otkriti i ponovno se pokreće. Ovaj ciklus se nastavlja sve dok ne istekne vrijeme.

Koraci za rješavanje problema i popravak za praćenje Apache2 u okruženju HestiaCP

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 upišite naredbu u terminal.

netstat -tulpn | grep apache2

Alternativno, možete koristiti naredbu `ss`; učinak 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 8081, a ne 80. To je korijen problema.

Drugi korak je popravak oštećene PID datoteke. To 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 ponovno pokrenite Apache2 kako biste mu omogućili da prepiše čisti PID. Na kraju, upotrijebite `cat` za provjeru sadržaja datoteke; trebao bi sadržavati niz brojeva, a ne prazan niz.

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

Komparativna analiza Monitovih tradicionalnih adaptivnih i agresivnih zaštitnih konfiguracija

Online tutorijali o konfiguriranju Apache2 s Monitom općenito se svrstavaju u dvije kategorije.

Jedan tip je "tradicionalni tip prilagodbe", koji koristi naredbu `service` za upravljanje uslugama 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 uslugama, dodaje ograničenja podprocesima i primjenjuje strožu logiku detekcije. Izgleda sjajno, ali ima fatalnu manu: korištena naredba za zaustavljanje je `killall -9`.

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

Moje osobno iskustvo je da je ograničavanje broja podređenih procesa u agresivnoj konfiguraciji doista korisno. Kada je vaš Apache2 preopterećen CC napadom, ograničavanje broja podređenih procesa može spriječiti da poslužitelju ponestane memorije. Međutim, pristup `killall -9` je zaista neupotrebljiv.

Tako sam na kraju napravio kompromis i kombinirao 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 iza ovih nekoliko redaka konfiguracije.

Napišite port 8081 kako bi precizno odgovarao arhitekturi obrnutog proxyja HestiaCP-a; prestanite glupo pisati port 80.

Umjesto naredbe `killall -9`, za zaustavljanje PID datoteke koristite naredbu `systemctl stop`, kako je ne biste oštetili.

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

Logika za otkrivanje kvarova modificirana je kako bi se koristio pristup "za 2 ciklusa", što znači da se ponovno pokretanje pokreće tek nakon dva uzastopna kvara, čime se smanjuju lažno pozitivni rezultati. Prethodna konfiguracija, koja je ponovno pokretala nakon samo jednog otkrivanja, iskreno, bila je malo preosjetljiva.

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

HestiaCP Monitoring nadzoraSažetak rješavanja problema s konfiguracijom i dijeljenje iskustva

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

Kako bih opisao svoje osjećaje 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 poslužitelj trebao raditi. Ali problem je što se mnogi online tutorijali temelje na pretpostavci da "Apache2 isključivo koristi port 80", dok HestiaCP koristi obrnuti proxy, što znači da ta pretpostavka ne vrijedi.

Ako slijedite upute, problem nije u vama; problem je u tome što je vodič primjenjiv na drugačiji scenarij od vašeg.

Dakle, ako također koristite HestiaCP i igrate se s Monitom za praćenje Apache2, samo zapamtite dvije stvari: Promijenite port na 8081 i koristite naredbu `systemctl` za zaustavljanje, a ne `killall -9`. Ako učinite ove dvije stvari, trebali biste moći izbjeći daljnje probleme.

Budući da ste pročitali do sada, ako vam je bilo korisno, lajkajte 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.