Je, kuna matukio ya mara kwa mara ya Apache2 kupitia HestiaCP? Je, mwongozo wa ufuatiliaji na utatuzi wa matatizo kiotomatiki unafuatiliwa (na usanidi kamili)

Je, kuna hitilafu za mara kwa mara za Apache2 au hitilafu za kuanzisha upya kiotomatiki za Monit katika mazingira ya HestiaCP ? Makala haya yanatoa mwongozo wa vitendo wa kuepuka mitego ya kawaida wakati wa kufuatilia Apache2 na Monit, kuchanganua kwa undani masuala ya kawaida kama vile upangaji mbaya wa njia ya PID na kuzuia ruhusa, na kutoa faili za usanidi otomatiki wa Monit za kiwango cha uzalishaji. Boresha mbinu za matengenezo ya seva zinazopatikana kwa wingi sasa na ufikie urejeshaji otomatiki wa kiwango cha pili kutokana na hitilafu!

Mitego niliyokutana nayo nilipokuwa nikitumia Monit kufuatilia Apache2

Ijumaa iliyopita, seva ilinipa tahadhari ya Monit katikati ya usiku.

Nilitazama paneli kwa mshangao, na katika safu wima ya hali ya apache2, kulikuwa na Timeout nyekundu.

Nilifikiria kuhusu hilo kwa muda. Nimeongeza tu ufuatiliaji wa Monit kwenye seva wakati wa mchana, na nilinakili na kubandika usanidi kutoka kwa mafunzo ya mtandaoni. Hakupaswi kuwa na matatizo yoyote, sivyo?

Asubuhi iliyofuata, muda uliisha tena. Baada ya mara ya tatu, Monitor ilikata tamaa, na paneli ilionyesha "Haifuatiliwi".

I. . .

Nakubali, sikuchukua kwa uzito mwanzoni. Ufuatiliaji wa Apache2? Unaweza kupata usanidi mwingi wa violezo mtandaoni, nakili na ubandike tu. Lakini mchakato huo wa kubandika ulinifanya niwe na hasira sana.

Chanzo kikuu cha mzozo kati ya usanifu chaguo-msingi wa HestiaCP na milango ya Monit

Acha kwanza nikuonyeshe usanidi ulionisababishia matatizo mengi, ili uweze kuona kama ni sawa kabisa na toleo uliloliona.

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

Inaonekana sawa, sivyo? Inaangalia mlango nambari 80, na ikianguka, inaanza tena. Ikiwa bado itaanguka baada ya kuanza tena mara 5, inaisha muda.

Shida ni kwamba, Apache2 yako haifanyi kazi hata kwenye lango 80.

Huu ni mtego wa HestiaCP, na chanzo kikuu cha watu wengi kuanguka ndani yake. Usanifu chaguo-msingi wa HestiaCP ni mbadala wa Nginx + Apache2, huku Nginx ikichukua milango 80 na 443 mbele, na Apache2 ikiendesha kwenye mlango wa ndani 8081 nyuma.

Ukimwomba Monit achunguze uhai wa Apache2 kwenye lango namba 80, ni kama kwenda McDonald's kutafuta KFC. Seva inakuangalia bila kujua, na nyinyi wawili mnatazamana. Mwishowe, Monit anaamua kwamba mmeshindwa na anaanza kuanzisha upya kwa haraka.

Baada ya kuanzisha upya, mlango bado ni 8081. Kisha Monit hujaribu kuchunguza mlango 80, ambao pia hushindwa, kwa hivyo huanza tena. Mzunguko huu hurudia hadi Monit atakapoamua kuwa hauwezi kurekebishwa na muda wake umeisha.

Nilipokutana na hili kwa mara ya kwanza, nilishangaa sana. Mafunzo tisa kati ya kumi niliyoyapata mtandaoni yalitumia lango 80. Ukifuata, tatizo halikuwa kwako, bali lilikuwa chanzo cha taarifa yenyewe.

Faili ya Apache2 PID iliyoharibika ilisababisha Monit kutambua kimakosa mchakato huo kama haupo.

Baada ya kubadilisha mlango kutoka 80 hadi 8081, Monit inapaswa kinadharia kuweza kuugundua, sivyo?

Hata hivyo, kwa kweli, bado mara kwa mara inaripoti "Utekelezaji umeshindwa ".

Baada ya kuhangaika kwa muda mrefu, hatimaye niligundua sababu ilikuwa rahisi: faili ya PID ilikuwa imeharibika.

Fikiria kuhusu hilo, Monit alikuwa akianzisha upya Apache2 kwa kasi, kila wakati akiiua kwa nguvu na kuianzisha tena, akirudi na kurudi mara kadhaa. Wakati wa mchakato huu, faili /var/run/apache2/apache2.pid inaweza kuwa baiti 0.

Kwa maneno mengine, faili bado ipo, lakini ni tupu.

Monit anaposoma faili hii, haipati chochote. Haitambui Apache2 yako, hata kama Apache2 yako inafanya kazi vizuri chinichini; Monit hafikirii mchakato upo.

Nilipoona hili, nilishindwa kusema kwa muda.

Huu ni mkwamo. Monit inashindwa kugundua mfano wa Apache 2, inaanzisha upya Apache2, inaharibu faili ya PID wakati wa mchakato wa kuanzisha upya, inashindwa kugundua tena, na inaanzisha upya tena. Mzunguko huu unaendelea hadi muda utakapoisha.

Hatua za Kutatua Matatizo na Urekebishaji kwa Ufuatiliaji wa Apache2 katika Mazingira ya HestiaCP

Kwa kweli, mchakato wa uchunguzi si mgumu, lakini unahitaji kujua ni mwelekeo gani wa kuchunguza.

Hatua ya kwanza ni kubaini ni mlango gani Apache2 yako inasikiliza. Andika tu amri kwenye terminal.

netstat -tulpn | grep apache2

Vinginevyo, unaweza kutumia amri ya `ss`; athari ni sawa.

ss -tulpn | grep apache2

Utaona matokeo yanayofanana na haya.

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

Imethibitishwa kuwa 8081, si 80. Huo ndio mzizi wa tatizo.

Hatua ya pili ni kurekebisha faili ya PID iliyoharibika. Hii ni rahisi zaidi.

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

Kwanza, sitisha ufuatiliaji wa Monit ili kuizuia isiingilie unaporekebisha mambo. Kisha, anza upya Apache2 ili kuiruhusu kuandika upya PID safi. Hatimaye, tumia `cat` kuangalia maudhui ya faili; inapaswa kuwa na mfuatano wa nambari, si mfuatano mtupu.

Mara tu hatua hii ikikamilika, tatizo kimsingi hutatuliwa.

Uchambuzi wa Ulinganisho wa Mipangilio ya Kinga ya Jadi ya Monit Inayoweza Kubadilika na Kubadilika

Mafunzo ya mtandaoni kuhusu kusanidi Apache2 na Monit kwa ujumla yanagawanywa katika makundi mawili.

Aina moja ni "aina ya marekebisho ya kitamaduni," ambayo hutumia amri ya `service` kudhibiti huduma na kuangalia milango ya ndani bila kuongeza vikwazo vingi sana. Usanidi huu unaweza kutumika kwenye HestiaCP kwa kubadilisha tu mlango, na ni thabiti kiasi.

Mbinu nyingine ni mbinu ya "ulinzi mkali", ambayo hutumia systemctl kusimamia huduma, huongeza vikwazo vya mchakato wa mtoto, na hutumia mantiki kali ya kugundua. Inaonekana nzuri, lakini ina kasoro mbaya: amri ya kusimamisha inayotumika ni `killall -9`.

`killall -9` inamaanisha nini? Inamaanisha kuua kifaa kwa nguvu bila kujali kinachofanya. Uendeshaji huu wa nguvu kali unaweza kuacha faili za PID zilizoharibika kwa urahisi, ambalo ndilo tatizo nililotaja hivi punde.

Uzoefu wangu binafsi ni kwamba kupunguza idadi ya michakato ya watoto katika usanidi mkali ni muhimu sana. Apache2 yako inapozidiwa na shambulio la CC, kupunguza idadi ya michakato ya watoto kunaweza kuzuia seva kukosa kumbukumbu. Hata hivyo, mbinu ya `killall -9` haiwezi kutumika.

Kwa hivyo mwishowe niliathiri na kuchanganya faida za usanidi wote wawili.

Usanidi Bora wa HestiaCP Apache2 Monit

Rekebisha faili /etc/monit/conf.d/apache2 na maudhui yafuatayo.

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

Acha nieleze kwa ufupi mantiki iliyo nyuma ya mistari hii michache ya usanidi.

Andika mlango 8081 ili ulingane kikamilifu na usanifu mbadala wa HestiaCP; acha kuandika mlango 80 kwa upumbavu.

Tumia amri ya `systemctl stop` badala ya `killall -9` ili kusimamisha faili ya PID, ili isiiharibu.

Kikomo cha mchakato wa mtoto kimeongezwa: ikiwa idadi ya watoto itazidi 120, mchakato utaanza upya baada ya mizunguko miwili mfululizo ili kuzuia mashambulizi ya CC, lakini si mkali sana.

Mantiki ya kugundua hitilafu imebadilishwa ili kutumia mbinu ya "kwa mizunguko 2", ikimaanisha kuwa kuanzisha upya kunaanzishwa tu baada ya hitilafu mbili mfululizo, na kupunguza matokeo chanya yasiyo sahihi. Usanidi uliopita, ambao ulianza tena baada ya kugundua mara moja tu, kwa kweli ulikuwa nyeti kupita kiasi.

Kizingiti cha mwisho cha muda wa kuisha hulegezwa hadi kuanza upya mara 5 ndani ya mizunguko 10, na kuacha uvumilivu wa kutosha wa hitilafu.

HestiaCP Monit ufuatiliajiMuhtasari wa Utatuzi wa Usanidi na Kushiriki Uzoefu

Baada ya kufanya mabadiliko ya usanidi, nilifuatilia apache2, na hatimaye paneli ilionyesha kiashiria cha kijani "Sawa".

Jinsi ya kuelezea hisia zangu wakati huo? Ilikuwa kama kutumia siku mbili nikipambana na hitilafu, lakini kugundua chanzo kilikuwa ni safu moja ya usanidi ambayo haikuwa sahihi. Ilikuwa ya kukatisha tamaa na ya kuchekesha.

Monit yenyewe ni jambo zuri, na ufuatiliaji wa daemons ni jambo ambalo kila seva inapaswa kufanya. Lakini tatizo ni kwamba mafunzo mengi ya mtandaoni yanategemea dhana kwamba "Apache2 hutumia lango 80 pekee," huku HestiaCP ikitumia proksi kinyume, kumaanisha dhana hii si kweli.

Ukifuata maagizo, tatizo si wewe; ni kwamba mafunzo yanatumika kwa hali tofauti na yako.

Kwa hivyo ikiwa pia unatumia HestiaCP na unacheza na Monit kufuatilia Apache2, kumbuka mambo mawili tu: Badilisha mlango hadi 8081, na utumie amri ya `systemctl` kuisimamisha, sio `killall -9`. Ukifanya mambo haya mawili, unapaswa kuweza kuepuka matatizo mengine zaidi.

Kwa kuwa umesoma hadi hapa, ikiwa umeona kuwa na manufaa, tafadhali like na ushiriki. Ikiwa unataka kupokea masasisho kwanza, unaweza pia kunifuata!

Asante kwa kusoma makala yangu. Tutaonana wakati mwingine.