Tíð hrun í Apache2 með HestiaCP? Leiðbeiningar um sjálfvirka eftirlit og bilanaleit hjá Monit (með fullri stillingu).

Tíð Apache2 hrun eða sjálfvirk endurræsingarvillur Monit í HestiaCP umhverfum? Þessi grein veitir hagnýtar leiðbeiningar um hvernig á að forðast algengar gryfjur þegar Apache2 er fylgst með með Monit, greinir ítarlega algeng vandamál eins og ranga stillingu PID slóða og leyfisblokkun og býður upp á sjálfvirkar stillingarskrár fyrir Monit í framleiðsluflokki. Náðu tökum á viðhaldsaðferðum fyrir háa tiltækileika netþjóna núna og náðu sjálfvirkri endurheimt á öðru stigi eftir bilanir!

Gildrurnar sem ég rakst á þegar ég notaði Monit til að fylgjast með Apache2

Síðastliðinn föstudag gaf þjónninn mér Monit viðvörun um miðja nótt.

Ég kastaði augnaráði á spjaldið og í stöðudálknum fyrir apache2 var rauður „Timeout“-tíminn.

Ég hugsaði mig aðeins um. Ég bætti Monit eftirliti við netþjóninn um daginn og afritaði og límdi stillingarnar úr kennslumyndbandi á netinu. Það ættu ekki að vera nein vandamál, ekki satt?

Næsta morgun rann það út aftur. Eftir þriðja skiptið gafst Skjárinn einfaldlega upp og skjárinn birti „Ekki fylgst með“.

Ég...

Ég viðurkenni að ég tók þetta ekki alvarlega í fyrstu. Apache2 eftirlit? Það er hægt að finna fullt af sniðmátastillingum á netinu, bara afritaðu og límdu. En þetta límingaferli gerði mig virkilega reiðan.

Rót árekstrarins milli sjálfgefins arkitektúrs HestiaCP og Monit tengi

Leyfðu mér fyrst að sýna þér stillinguna sem olli mér svona miklum vandræðum, svo þú getir séð hvort hún sé nákvæmlega eins og útgáfan sem þú hefur séð.

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

Þetta virðist í lagi, ekki satt? Það athugar port 80 og ef það hrynur, þá endurræsir það. Ef það hrynur enn eftir 5 endurræsingar, þá rennur það út á tíma.

Vandamálið er að Apache2 stýrikerfið þitt keyrir ekki einu sinni á porti 80.

Þetta er gildra HestiaCP og undirrót þess að margir lenda í henni. Sjálfgefin arkitektúr HestiaCP er öfug milligönguþjónn Nginx + Apache2, þar sem Nginx er á tengi 80 og 443 fremst og Apache2 keyrir á staðbundnu tengi 8081 aftast.

Ef þú biður Monit að kanna hvort Apache2 sé virkt á porti 80, þá er það eins og að fara á McDonald's til að finna KFC. Þjónninn horfir á þig tómlega og þið tvö glápið hvort á annað. Að lokum kemst Monit að því að þið séuð niðri og byrjar að endurræsa tölvuna í örvæntingu.

Eftir endurræsingu er tengið enn 8081. Monit reynir síðan að kanna tengi 80, sem mistekst líka, svo það endurræsir aftur. Þessi hringrás endurtekur sig þar til Monit ákveður að það sé óviðgerðarlegt og tímaramminn rennur út.

Þegar ég rakst fyrst á þetta varð ég hreinlega agndofa. Níu af hverjum tíu kennslumyndböndum sem ég fann á netinu notuðu tengi 80. Ef þú fylgdir þeim, þá var vandamálið ekki hjá þér, heldur hjá uppsprettu upplýsinganna sjálfra.

Skemmd Apache2 PID skrá olli því að Monit ranglega greindi ferlið sem ekki til.

Eftir að portinu hefur verið breytt úr 80 í 8081, ætti Monit í orði kveðnu að geta greint það, ekki satt?

Hins vegar, í raun og veru, tilkynnir það stundum „Keyrsla mistókst “.

Eftir langa erfiðleika uppgötvaði ég loksins að ástæðan var einföld: PID skráin var skemmd.

Hugsaðu um það, Monit var að endurræsa Apache2 í örvæntingu, í hvert skipti með því að drepa það og endurræsa það, og fór fram og til baka nokkrum sinnum. Á meðan þessu ferli stóð gæti skráin /var/run/apache2/apache2.pid orðið 0 bæti.

Með öðrum orðum, skráin er ennþá til staðar, en hún er tóm.

Þegar Monit les þessa skrá finnur það ekkert. Það þekkir ekki Apache2 skrána þína, jafnvel þótt Apache2 skráin þín keyri fullkomlega í bakgrunni; Monit heldur ekki að ferlið sé til.

Þegar ég sá þetta varð ég orðlaus um stund.

Þetta er pattstaða. Monit finnur ekki Apache 2 tilvikið, endurræsir Apache2, spillir PID skránni við endurræsingarferlið, mistekst næstu greiningu og endurræsir aftur. Þessi hringrás heldur áfram þar til biðtími rennur út.

Úrræðaleit og viðgerðarskref fyrir Apache2 eftirlit í HestiaCP umhverfi

Satt best að segja er rannsóknarferlið ekki flókið, en þú þarft að vita í hvaða átt þú átt að rannsaka.

Fyrsta skrefið er að ákvarða hvaða port Apache2 þinn hlustar á. Sláðu einfaldlega inn skipun í flugstöðina.

netstat -tulpn | grep apache2

Einnig er hægt að nota skipunina `ss`; áhrifin eru þau sömu.

ss -tulpn | grep apache2

Þú munt sjá svipaða úttak og þetta.

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

Það hefur verið staðfest að það sé 8081, ekki 80. Það er rót vandans.

Annað skrefið er að gera við skemmda PID skrána. Þetta er einfaldara.

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

Fyrst skaltu gera hlé á eftirliti með Monit til að koma í veg fyrir að það trufli á meðan þú ert að laga hluti. Endurræstu síðan Apache2 til að leyfa því að endurskrifa hreint PID. Að lokum skaltu nota `cat` til að athuga innihald skráarinnar; það ætti að innihalda talnalínu, ekki tóman streng.

Þegar þessu skrefi er lokið er vandamálið í grundvallaratriðum leyst.

Samanburðargreining á hefðbundnum aðlögunarhæfum og árásargjarnum verndarstillingum Monit

Netkennsluefni um stillingu Apache2 með Monit skiptist almennt í tvo flokka.

Ein gerð er „hefðbundin aðlögunargerð“ sem notar skipunina „service“ til að stjórna þjónustu og athuga staðbundnar tengi án þess að bæta við of mörgum flóknum takmörkunum. Þessa stillingu er hægt að nota á HestiaCP með því einfaldlega að breyta tenginu og hún er tiltölulega stöðug.

Önnur aðferð er „árásargjörn vernd“ aðferðin, sem notar systemctl til að stjórna þjónustum, bætir við takmörkunum á undirferlum og notar strangari greiningarrökfræði. Hún lítur vel út en hefur alvarlegan galla: stöðvunarskipunin sem notuð er er `killall -9`.

Hvað þýðir „killall -9“? Það þýðir að slökkva á tækinu með valdi, óháð því hvað það er að gera. Þessi aðgerð með óþarfa auðveldum aðgerðum getur auðveldlega skilið eftir sig skemmdar PID skrár, sem er vandamálið sem ég nefndi rétt í þessu.

Persónuleg reynsla mín er sú að það er mjög gagnlegt að takmarka fjölda undirferla í árásargjarnri stillingu. Þegar Apache2 þjónninn þinn verður fyrir yfirþyrmandi CC árás getur það komið í veg fyrir að minni þjónsins klárist með því að takmarka fjölda undirferla. Hins vegar er aðferðin `killall -9` í raun ónothæf.

Svo að lokum gerði ég málamiðlun og sameinaði kosti beggja stillinga.

Bestu starfsvenjur fyrir HestiaCP Apache2 Monitor stillingar

Breyttu skránni /etc/monit/conf.d/apache2 með eftirfarandi efni.

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

Leyfðu mér að útskýra stuttlega rökfræðina á bak við þessar fáu stillingarlínur.

Skrifaðu port 8081 þannig að það passi nákvæmlega við öfuga umboðsarkitektúr HestiaCP; hættu að skrifa port 80 svona heimskulega.

Notaðu skipunina `systemctl stop` í stað `killall -9` til að stöðva PID skrána, svo hún skemmist ekki.

Takmörkun á undirferlum hefur verið bætt við: ef fjöldi undirferla fer yfir 120, mun ferlið endurræsa eftir tvær samfelldar lotur til að koma í veg fyrir CC árásir, en það er ekki of árásargjarnt.

Rökfræðin fyrir bilanagreiningu hefur verið breytt til að nota „í 2 lotur“ aðferð, sem þýðir að endurræsing er aðeins virkjuð eftir tvær bilanir í röð, sem dregur úr fölskum jákvæðum niðurstöðum. Fyrri stillingin, sem endurræsti eftir aðeins eina greiningu, var hreinskilnislega svolítið of viðkvæm.

Lokatímamörkin eru slakuð niður í 5 endurræsingar innan 10 lotna, sem skilur eftir nægilegt bilanaþol.

HestiaCP Monit eftirlitYfirlit yfir bilanaleit í stillingum og miðlun reynslu

Eftir að hafa gert stillingarbreytingarnar fylgdist ég með apache2 og spjaldið sýndi loksins grænt „Í lagi“ vísi.

Hvernig á að lýsa tilfinningum mínum á þeim tíma? Það var eins og að eyða tveimur dögum í að glíma við villu, bara til að komast að því að orsökin var ein lína af stillingum sem var röng. Það var bæði pirrandi og fáránlegt.

Að fylgjast með þjónum er gott í sjálfu sér, og það er eitthvað sem allir netþjónar ættu að gera að fylgjast með þjónum. En vandamálið er að margar kennslumyndbönd á netinu byggjast á þeirri forsendu að „Apache2 noti eingöngu tengi 80“, en HestiaCP notar öfugan milliþjón, sem þýðir að þessi forsenda stenst ekki.

Ef þú fylgir leiðbeiningunum, þá er vandamálið ekki þú; það er að kennslan á við um aðra aðstæður en þína.

Svo ef þú ert líka að nota HestiaCP og fikta í Monit til að fylgjast með Apache2, þá skaltu bara muna tvo hluti: Breyttu tengitákninu í 8081 og notaðu `systemctl` skipunina til að stöðva það, ekki `killall -9`. Ef þú gerir þessa tvo hluti ættirðu að geta forðast frekari vandamál.

Þar sem þú hefur lesið þetta hingað til, ef þér fannst þetta gagnlegt, vinsamlegast líkaðu við og deildu því. Ef þú vilt fá uppfærslur fyrst geturðu líka fylgst með mér!

Takk fyrir að lesa greinina mína. Sjáumst næst.