Rënie të shpeshta të Apache2 me HestiaCP? Udhëzuesi i monitorimit automatik dhe zgjidhjes së problemeve të Monit (me konfigurim të plotë)

Rrëzime të shpeshta të Apache2 ose dështime të rinisjes automatike të Monit në mjediset HestiaCP ? Ky artikull ofron një udhëzues praktik për të shmangur grackat e zakonshme gjatë monitorimit të Apache2 me Monit, duke analizuar në thellësi problemet e zakonshme siç janë keqpozicionimi i shtegut PID dhe bllokimi i lejeve, dhe duke ofruar skedarë konfigurimi të automatizimit Monit të nivelit të prodhimit. Zotëroni teknikat e mirëmbajtjes së serverit me disponueshmëri të lartë tani dhe arrini rikuperim automatik të nivelit të dytë nga dështimet!

Grackat që hasa gjatë përdorimit të Monit për të monitoruar Apache2

Të premten e kaluar, serveri më dha një alarm Monit në mes të natës.

E shikova panelin i hutuar dhe në kolonën e statusit të apache2, kishte një Timeout të kuq.

E mendova pak. Sapo shtova monitorimin e Monit në server gjatë ditës dhe kopjova e ngjisnim konfigurimin nga një tutorial online. Nuk duhet të ketë probleme, apo jo?

Të nesërmen në mëngjes, koha skadoi përsëri. Pas herës së tretë, Monitori thjesht hoqi dorë dhe paneli shfaqi "Nuk monitorohet".

Unë...

E pranoj, në fillim nuk e mora seriozisht. Monitorimi i Apache2? Mund të gjesh shumë konfigurime shabllonësh në internet, thjesht kopjo dhe ngjit. Por ai proces ngjitjeje më tërboi vërtet.

Shkaku rrënjësor i konfliktit midis arkitekturës së parazgjedhur të HestiaCP dhe porteve Monit

Më lejoni së pari t'ju tregoj konfigurimin që më shkaktoi kaq shumë probleme, në mënyrë që të shihni nëse është saktësisht i njëjtë me versionin që keni parë.

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

Duket mirë, apo jo? Kontrollon portin 80 dhe nëse bllokohet, riniset. Nëse vazhdon të bllokohet pas 5 rinisjeve, koha i skadon.

Problemi është se Apache2 juaj nuk po funksionon as në portin 80.

Ky është një problem i HestiaCP dhe shkaku rrënjësor që shumë njerëz e përdorin atë. Arkitektura e parazgjedhur e HestiaCP është një proxy e kundërt e Nginx + Apache2, me Nginx që zë portet 80 dhe 443 përpara, dhe Apache2 që funksionon në portin lokal 8081 prapa.

Nëse i kërkon Monit të kontrollojë nëse Apache2 është aktiv në portin 80, është sikur të shkosh në McDonald's për të gjetur KFC. Kamerieri të shikon me sy të verbër dhe ju të dy shikoni njëri-tjetrin në sy. Në fund, Monit përcakton se je jashtë funksionit dhe fillon ta rifillojë me nxitim.

Pas rinisjes, porta është ende 8081. Pastaj Monit përpiqet të provojë portën 80, e cila gjithashtu dështon, kështu që riniset përsëri. Ky cikël përsëritet derisa Monit vendos se është i pandreqshëm dhe skadon koha.

Kur e hasa për herë të parë këtë, mbeta vërtet i shtangur. Nëntë nga dhjetë tutoriale që gjeta në internet përdornin portin 80. Nëse i ndoqët, problemi nuk ishte tek ju, por tek vetë burimi i informacionit.

Një skedar Apache2 PID i korruptuar bëri që Monit ta identifikonte gabimisht procesin si joekzistent.

Pas ndryshimit të portit nga 80 në 8081, Monit teorikisht duhet të jetë në gjendje ta zbulojë atë, apo jo?

Megjithatë, në realitet, ai ende raporton herë pas here "Ekzekutimi dështoi ".

Pasi u mundova për një kohë të gjatë, më në fund zbulova se arsyeja ishte e thjeshtë: skedari PID ishte i dëmtuar.

Mendojeni pak, Monit po e ristartonte me tërbim Apache2, çdo herë duke e mbyllur dhe ristartuar me forcë, duke bërë disa lëvizje para dhe mbrapa. Gjatë këtij procesi, skedari /var/run/apache2/apache2.pid mund të bëhet 0 bajt.

Me fjalë të tjera, skedari është ende aty, por është bosh.

Kur Monit lexon këtë skedar, nuk gjen asgjë. Nuk e njeh Apache2 tuaj, edhe nëse Apache2 funksionon në mënyrë perfekte në sfond; Monit nuk mendon se procesi ekziston.

Kur e pashë këtë, mbeta pa fjalë për një moment.

Ky është një bllokim. Monit dështon në zbulimin e instancës Apache 2, rinis Apache2, dëmton skedarin PID gjatë procesit të rinisjes, dështon në zbulimin tjetër dhe rinis përsëri. Ky cikël vazhdon derisa të ndodhë skadimi i kohës.

Hapat e Zgjidhjes së Problemeve dhe Riparimit për Monitorimin Apache2 në Mjedisin HestiaCP

Të them të drejtën, procesi i hetimit nuk është i ndërlikuar, por duhet të dish se në cilin drejtim të hetosh.

Hapi i parë është të përcaktoni se në cilin port po dëgjon Apache2 juaj. Thjesht shkruani një komandë në terminal.

netstat -tulpn | grep apache2

Si alternativë, mund të përdorni komandën `ss`; efekti është i njëjtë.

ss -tulpn | grep apache2

Do të shihni një rezultat të ngjashëm me këtë.

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

Është konfirmuar të jetë 8081, jo 80. Ky është rrënja e problemit.

Hapi i dytë është riparimi i skedarit PID të dëmtuar. Kjo është më e thjeshtë.

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

Së pari, ndërpritni monitorimin e Monit për ta parandaluar atë të ndërhyjë ndërsa jeni duke rregulluar gjërat. Pastaj, rinisni Apache2 për ta lejuar atë të rishkruajë një PID të pastër. Së fundmi, përdorni `cat` për të kontrolluar përmbajtjen e skedarit; ai duhet të përmbajë një varg numrash, jo një varg bosh.

Pasi të përfundojë ky hap, problemi në thelb zgjidhet.

Analiza Krahasuese e Konfigurimeve Tradicionale Adaptuese dhe Agresive Mbrojtëse të Monit

Tutorialet online mbi konfigurimin e Apache2 me Monit përgjithësisht ndahen në dy kategori.

Një lloj është "lloji tradicional i adaptimit", i cili përdor komandën `service` për të menaxhuar shërbimet dhe për të kontrolluar portet lokale pa shtuar shumë kufizime të ndërlikuara. Ky konfigurim mund të përdoret në HestiaCP thjesht duke ndryshuar portin dhe është relativisht i qëndrueshëm.

Një qasje tjetër është metoda "mbrojtje agresive", e cila përdor systemctl për të menaxhuar shërbimet, shton kufizime të proceseve të fëmijëve dhe përdor logjikë më të rreptë zbulimi. Duket shkëlqyeshëm, por ka një të metë fatale: komanda ndaluese e përdorur është `killall -9`.

Çfarë do të thotë `killall -9`? Do të thotë ta çaktivizosh me forcë pajisjen pavarësisht se çfarë po bën. Ky operacion me forcë brutale mund të lërë lehtësisht pas skedarë PID të korruptuar, i cili është problemi që sapo përmenda.

Përvoja ime personale është se kufizimi i numrit të proceseve fëmijë në një konfigurim agresiv është me të vërtetë i dobishëm. Kur Apache2 juaj mbingarkohet nga një sulm CC, kufizimi i numrit të proceseve fëmijë mund të parandalojë që serveri të mbetet pa memorie. Megjithatë, qasja `killall -9` është me të vërtetë e papërdorshme.

Kështu që në fund bëra kompromis dhe kombinova avantazhet e të dy konfigurimeve.

Konfigurimi i Praktikave më të Mira të HestiaCP Apache2 Monit

Modifikoni skedarin /etc/monit/conf.d/apache2 me përmbajtjen e mëposhtme.

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

Më lejoni të shpjegoj shkurtimisht logjikën që fshihet pas këtyre pak rreshtave të konfigurimit.

Shkruani portin 8081 që të përputhet saktësisht me arkitekturën reverse proxy të HestiaCP; ndaloni së shkruari pa mend portin 80.

Përdorni komandën `systemctl stop` në vend të `killall -9` për të ndaluar skedarin PID, në mënyrë që të mos e korruptoni atë.

Është shtuar një limit për proceset fëmijë: nëse numri i fëmijëve tejkalon 120, procesi do të rifillojë pas dy cikleve të njëpasnjëshme për të parandaluar sulmet CC, por nuk do të jetë shumë agresiv.

Logjika për zbulimin e dështimeve është modifikuar për të përdorur një qasje "për 2 cikle", që do të thotë se një rinisje aktivizohet vetëm pas dy dështimeve të njëpasnjëshme, duke zvogëluar pozitivët e rremë. Konfigurimi i mëparshëm, i cili riniste vetëm pas një zbulimi, ishte sinqerisht paksa tepër i ndjeshëm.

Pragu përfundimtar i kohës së skadimit zbutet në 5 rinisje brenda 10 cikleve, duke lënë tolerancë të mjaftueshme ndaj defekteve.

HestiaCP Monitoroni monitoriminPërmbledhje e Problemeve të Konfigurimit dhe Ndarja e Përvojës

Pasi bëra ndryshimet e konfigurimit, monitorova apache2 dhe paneli më në fund tregoi një tregues të gjelbër "OK".

Si t’i përshkruaj ndjenjat e mia në atë kohë? Ishte sikur të kaloja dy ditë duke u përballur me një insekt, vetëm për të zbuluar se shkaku ishte një vijë e vetme konfigurimi që ishte e gabuar. Ishte njëkohësisht frustruese dhe qesharake.

Monit është një gjë e mirë në vetvete, dhe monitorimi i daemonëve është diçka që çdo server duhet ta bëjë. Por problemi është se shumë tutoriale online bazohen në supozimin se "Apache2 përdor ekskluzivisht portin 80", ndërsa HestiaCP përdor një proxy të kundërt, që do të thotë se ky supozim nuk është i vërtetë.

Nëse i ndiqni udhëzimet, problemi nuk jeni ju; problemi është se tutoriali është i zbatueshëm në një skenar të ndryshëm nga i juaji.

Pra, nëse përdorni edhe HestiaCP dhe luani me Monit për të monitoruar Apache2, mbani mend dy gjëra: Ndryshoni portin në 8081 dhe përdorni komandën `systemctl` për ta ndaluar atë, jo `killall -9`. Nëse i bëni këto dy gjëra, duhet të jeni në gjendje të shmangni probleme të tjera.

Meqenëse e lexuat deri këtu, nëse e gjetët të dobishme, ju lutem pëlqeni dhe shpërndajeni. Nëse doni të merrni përditësime të parët, mund të më ndiqni edhe mua!

Faleminderit që lexuat artikullin tim. Shihemi herën tjetër.