Faak crashes fan Apache2 mei HestiaCP? Monit automatyske monitoring- en probleemoplossingsgids (mei folsleine konfiguraasje)

Faak crashes Apache2 of automatyske opnij starte fan Monit yn HestiaCP -omjouwings? Dit artikel jout in praktyske hantlieding foar it foarkommen fan faak foarkommende falstrikken by it kontrolearjen fan Apache2 mei Monit, analysearret faak foarkommende problemen lykas ferkearde ôfstimming fan PID-paden en blokkearjen fan tastimming, en biedt konfiguraasjebestannen foar automatisearring fan produksjeklasse foar Monit. Behearskje no ûnderhâldstechniken foar hege beskikberens fan servers en berik automatysk herstel op it twadde nivo fan flaters!

De falstriken dy't ik tsjinkaam by it brûken fan Monit om Apache2 te kontrolearjen

Ofrûne freed joech de server my midden yn 'e nacht in Monit-warskôging.

Ik seach ferbjustere nei it paniel, en yn 'e apache2-statuskolom stie in reade Timeout.

Ik haw der efkes oer neitocht. Ik haw krekt oerdeis Monit-monitoring tafoege oan 'e server, en ik haw de konfiguraasje fan in online tutorial kopiearre en plakt. Der moatte gjin problemen wêze, toch?

De oare moarns rûn de tiid wer op. Nei de tredde kear joech Monitor it gewoan op, en it dashboard liet "Net kontrolearre" sjen.

IK. , ,

Ik moat tajaan, ik naam it earst net serieus. Apache2-monitoring? Jo kinne in soad sjabloankonfiguraasjes online fine, gewoan kopiearje en plakke. Mar dat plakproses makke my echt lilk.

De woarteloarsaak fan it konflikt tusken de standertarsjitektuer fan HestiaCP en Monit-poarten

Lit my jo earst de konfiguraasje sjen litte dy't my safolle problemen feroarsake hat, sadat jo kinne sjen oft it krekt itselde is as de ferzje dy't jo sjoen hawwe.

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

It liket goed, toch? It kontrolearret poarte 80, en as it crasht, start it opnij op. As it nei 5 opnij starte noch altyd crasht, dan rint it út.

It probleem is, dyn Apache2 rint net iens op poarte 80.

Dit is in falstrik fan HestiaCP, en de woartel fan 'e oarsaak dat in protte minsken deryn falle. De standertarsjitektuer fan HestiaCP is in reverse proxy fan Nginx + Apache2, mei Nginx dy't poarten 80 en 443 foaroan beset, en Apache2 dy't rint op 'e lokale poarte 8081 efteroan.

As jo ​​Monit freegje om de libbensduur fan Apache2 op poarte 80 te ûndersiikjen, is it as gean nei McDonald's om KFC te finen. De tsjinner sjocht jo leech oan, en jimme twa stoarje inoar oan. Uteinlik stelt Monit fêst dat jimme del binne en begjint frenetyk opnij te starten.

Nei it opnij opstarten is de poarte noch altyd 8081. Monit besiket dan poarte 80 te ûndersiikjen, wat ek mislearret, dus start it opnij op. Dizze syklus werhellet him oant Monit beslút dat it net mear te reparearjen is en in time-out krijt.

Doe't ik dit foar it earst tsjinkaam, wie ik echt ferbjustere. Njoggen fan de tsien tutorials dy't ik online fûn brûkten poarte 80. As jo ​​se folge hawwe, lei it probleem net by jo, mar by de boarne fan 'e ynformaasje sels.

In beskeadige Apache2 PID-bestân soarge derfoar dat Monit it proses fersinlik as net-besteand identifisearre.

Nei it feroarjen fan de poarte fan 80 nei 8081 moat Monit it teoretysk wol detektearje kinne, toch?

Yn werklikheid rapportearret it lykwols noch wolris "Utfiering mislearre ".

Nei lange tiid wrakseljen, ûntduts ik úteinlik dat de reden ienfâldich wie: it PID-bestân wie beskeadige.

Tink derom, Monit wie Apache2 panyk oan it opnij starte, elke kear mei geweld deadzjend en opnij startend, ferskate kearen hinne en wer geand. Tidens dit proses kin it bestân /var/run/apache2/apache2.pid 0 bytes wurde.

Mei oare wurden, it bestân is der noch, mar it is leech.

As Monit dit bestân lêst, fynt it neat. It herkent jo Apache2 net, sels as jo Apache2 perfekt op 'e eftergrûn rint; Monit tinkt net dat it proses bestiet.

Doe't ik dit seach, wie ik efkes sprakeloos.

Dit is in deadlock. Monit kin it Apache 2-eksimplaar net detektearje, start Apache2 opnij, beskeadiget it PID-bestân tidens it opnij starteproses, mislearret de folgjende deteksje en start opnij op. Dizze syklus giet troch oant in time-out optreedt.

Problemen oplosse en reparearje stappen foar Apache2-monitoring yn HestiaCP-omjouwing

Om earlik te wêzen, it ûndersyksproses is net yngewikkeld, mar jo moatte witte yn hokker rjochting jo ûndersykje moatte.

De earste stap is om te bepalen op hokker poarte jo Apache2 harket. Typ gewoan in kommando yn 'e terminal.

netstat -tulpn | grep apache2

As alternatyf kinne jo it kommando `ss` brûke; it effekt is itselde.

ss -tulpn | grep apache2

Jo sille útfier sjen dy't fergelykber is mei dit.

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

It is befêstige dat it 8081 is, net 80. Dat is de woartel fan it probleem.

De twadde stap is it reparearjen fan it beskeadige PID-bestân. Dit is ienfâldiger.

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

Earst, pauzearje Monit-monitoring om te foarkommen dat it ynterfereart wylst jo dingen reparearje. Start dan Apache2 opnij op om it in skjinne PID opnij te skriuwen. Brûk úteinlik `cat` om de ynhâld fan it bestân te kontrolearjen; it moat in tekenrige fan sifers befetsje, gjin lege tekenrige.

As dizze stap foltôge is, is it probleem yn prinsipe oplost.

Ferlykjende analyze fan Monit Tradisjonele Adaptive en Agressive Beskermjende Konfiguraasjes

Online tutorials oer it konfigurearjen fan Apache2 mei Monit falle oer it algemien yn twa kategoryen.

Ien type is it "tradisjonele oanpassingstype", dat it kommando `service` brûkt om tsjinsten te behearjen en lokale poarten te kontrolearjen sûnder tefolle yngewikkelde beheiningen ta te foegjen. Dizze konfiguraasje kin brûkt wurde op HestiaCP troch gewoan de poarte te feroarjen, en it is relatyf stabyl.

In oare oanpak is de "agressive beskerming"-metoade, dy't systemctl brûkt om tsjinsten te behearjen, beheiningen foar bernprosessen tafoeget en strangere deteksjelogika brûkt. It sjocht der geweldich út, mar it hat in fatale flater: it brûkte stopkommando is `killall -9`.

Wat betsjut `killall -9`? It betsjut dat it apparaat mei geweld deadzje moat, nettsjinsteande wat it docht. Dizze brute-force-operaasje kin maklik beskeadige PID-bestannen efterlitte, dat is it probleem dat ik krekt neamde.

Myn persoanlike ûnderfining is dat it beheinen fan it oantal bernprosessen yn in agressive konfiguraasje yndie nuttich is. As jo ​​Apache2 oerweldige wurdt troch in CC-oanfal, kin it beheinen fan it oantal bernprosessen foarkomme dat de server te min ûnthâld krijt. De `killall -9`-oanpak is lykwols echt net te brûken.

Dat úteinlik haw ik in kompromis sletten en de foardielen fan beide konfiguraasjes kombinearre.

HestiaCP Apache2 Monit bêste praktykkonfiguraasje

Wizigje it bestân /etc/monit/conf.d/apache2 mei de folgjende ynhâld.

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

Lit my koart de logika efter dizze pear konfiguraasjelinen útlizze.

Skriuw poarte 8081 om presys oerien te kommen mei de reverse proxy-arsjitektuer fan HestiaCP; hâld op mei it ûnferstannich skriuwen fan poarte 80.

Brûk it kommando `systemctl stop` ynstee fan `killall -9` om it PID-bestân te stopjen, sadat it net beskeadige wurdt.

In limyt foar bernprosessen is tafoege: as it oantal bern mear as 120 is, sil it proses nei twa opienfolgjende syklusen opnij starte om CC-oanfallen te foarkommen, mar it is net te agressyf.

De logika foar it opspoaren fan flaters is oanpast om in "foar 2 syklusen"-oanpak te brûken, wat betsjut dat in opnij starte allinich nei twa opienfolgjende flaters wurdt aktivearre, wêrtroch falske positiven wurde fermindere. De foarige konfiguraasje, dy't nei mar ien deteksje opnij starte, wie earlik sein wat oergefoelich.

De definitive time-outdrompel wurdt ûntspannen nei 5 opnij starte binnen 10 syklusen, wêrtroch genôch fouttolerânsje oerbliuwt.

HestiaCP Monit tafersjochGearfetting fan probleemoplossing en it dielen fan ûnderfiningen

Nei it meitsjen fan de konfiguraasjewizigingen haw ik apache2 kontrolearre, en it paniel liet úteinlik in griene "OK" yndikator sjen.

Hoe moat ik myn gefoelens doe beskriuwe? It wie as twa dagen mei in bug wrakselje, allinnich om út te finen dat de oarsaak ien ferkearde konfiguraasjeline wie. It wie sawol frustrerend as laitsjend.

Monit is op himsels in goed ding, en it kontrolearjen fan daemons is wat elke server dwaan moat. Mar it probleem is dat in protte online tutorials basearre binne op 'e oanname dat "Apache2 allinich poarte 80 brûkt", wylst HestiaCP in reverse proxy brûkt, wat betsjut dat dizze oanname net wier is.

As jo ​​de ynstruksjes folgje, leit it probleem net by jo; it is dat de tutorial fan tapassing is op in oar senario as jo eigen.

Dus as jo ek HestiaCP brûke en mei Monit rommelje om Apache2 te kontrolearjen, tink dan oan twa dingen: feroarje de poarte nei 8081, en brûk it kommando `systemctl` om it te stopjen, net `killall -9`. As jo ​​dizze twa dingen dogge, moatte jo fierdere problemen foarkomme kinne.

Om't jo oant no ta lêzen hawwe, as jo it nuttich fûnen, like en diel it dan asjebleaft. As jo ​​earst updates ûntfange wolle, kinne jo my ek folgje!

Tankewol foar it lêzen fan myn artikel. Oant de folgjende kear.