Հաճախակի՞ են Apache2-ի խափանումները HestiaCP-ի հետ։ Monit ավտոմատացված մոնիթորինգի և խնդիրների լուծման ուղեցույց (ամբողջական կազմաձևմամբ):

Հաճախակի՞ են Apache2-ի խափանումները կամ Monit-ի ավտոմատ վերագործարկման ձախողումները HestiaCP միջավայրերում: Այս հոդվածը տրամադրում է գործնական ուղեցույց՝ Apache2-ը Monit-ի միջոցով վերահսկելիս տարածված թակարդներից խուսափելու համար, խորը վերլուծելով այնպիսի տարածված խնդիրներ, ինչպիսիք են PID ուղու անհամապատասխանությունը և թույլտվությունների արգելափակումը, և առաջարկելով արտադրական մակարդակի Monit ավտոմատացման կոնֆիգուրացիայի ֆայլեր: Հենց հիմա տիրապետեք բարձր մատչելիության սերվերի սպասարկման տեխնիկաներին և հասեք երկրորդ մակարդակի ավտոմատ վերականգնմանը ձախողումներից հետո:

Apache2-ը վերահսկելու համար Monit-ն օգտագործելիս հանդիպած թերությունները

Անցյալ ուրբաթ սերվերը կեսգիշերին ինձ Monit ահազանգ տվեց։

Ես ապշած նայեցի վահանակին, և apache2 կարգավիճակի սյունակում կարմիր «Timeout» էր գրված։

Մի փոքր մտածեցի այդ մասին։ Օրվա ընթացքում սերվերին ավելացրի Monit մոնիթորինգը և առցանց ձեռնարկից պատճենեցի ու տեղադրեցի կարգավորումները։ Ոչ մի խնդիր չպետք է լինի, այնպես չէ՞։

Հաջորդ առավոտյան ժամանակը կրկին սպառվեց։ Երրորդ անգամից հետո մոնիտորը պարզապես դադարեց աշխատել, և վահանակը ցուցադրեց «Չի մոնիթորավորվում» գրառումը։

Ես...

Խոստովանում եմ, սկզբում լուրջ չընդունեցի։ Apache2 մոնիթորինգ՞։ Կարող եք առցանց գտնել բազմաթիվ ձևանմուշների կոնֆիգուրացիաներ, պարզապես պատճենեք և տեղադրեք։ Բայց այդ տեղադրման գործընթացը ինձ իսկապես զայրացրեց։

HestiaCP-ի լռելյայն ճարտարապետության և Monit պորտերի միջև հակամարտության հիմնական պատճառը

Նախ թույլ տվեք ցույց տալ այն կոնֆիգուրացիան, որն այդքան մեծ խնդիրներ առաջացրեց ինձ համար, որպեսզի տեսնեք, թե արդյոք այն ճիշտ նույնն է, ինչ տեսել եք։

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

Թվում է՝ ամեն ինչ կարգին է, չէ՞։ Այն ստուգում է 80-րդ պորտը, և եթե այն խափանվում է, վերագործարկվում է։ Եթե այն դեռ խափանվում է 5 վերագործարկումից հետո, ապա ժամանակը սպառվում է։

Խնդիրն այն է, որ ձեր Apache2-ը նույնիսկ չի աշխատում 80-րդ պորտի վրա։

Սա HestiaCP-ի թակարդներից մեկն է և շատերի կողմից դրա օգտագործման հիմնական պատճառը։ HestiaCP-ի լռելյայն ճարտարապետությունը Nginx + Apache2-ի հակադարձ պրոքսի է, որտեղ Nginx-ը զբաղեցնում է առջևում գտնվող 80 և 443 պորտերը, իսկ Apache2-ը աշխատում է հետևի մասում գտնվող տեղական 8081 պորտի վրա։

Եթե ​​դուք Monit-ին խնդրեք ստուգել Apache2-ի ակտիվությունը 80-րդ պորտում, դա նույնն է, թե McDonald's գնալ KFC գտնելու։ Սպասարկողը դատարկ նայում է ձեզ, իսկ դուք երկուսով նայում եք միմյանց։ Վերջում Monit-ը որոշում է, որ դուք անջատված եք և սկսում է խելագարորեն վերագործարկել այն։

Վերագործարկումից հետո պորտը դեռևս 8081 է։ Այնուհետև Monit-ը փորձում է ստուգել 80-րդ պորտը, որը նույնպես ձախողվում է, ուստի այն կրկին վերագործարկվում է։ Այս ցիկլը կրկնվում է մինչև Monit-ը որոշի, որ այն չի կարող վերանորոգվել և ժամանակը սպառվի։

Երբ առաջին անգամ հանդիպեցի դրան, իսկապես ապշեցի։ Առցանց գտած տասը ձեռնարկներից ինը օգտագործում էին 80-րդ պորտը։ Եթե հետևել եք դրանց, խնդիրը ձեր մեջ չէր, այլ տեղեկատվության աղբյուրի։

Վնասված Apache2 PID ֆայլը ստիպեց Monit-ին սխալմամբ նույնականացնել գործընթացը որպես գոյություն չունեցող։

Պորտը 80-ից 8081 փոխելուց հետո, Monit-ը տեսականորեն պետք է կարողանա այն հայտնաբերել, այնպես չէ՞։

Սակայն, իրականում, այն դեռ երբեմն հաղորդում է «Կատարումը ձախողվեց »։

Երկար ժամանակ պայքարելուց հետո, ես վերջապես հասկացա, որ պատճառը պարզ էր. PID ֆայլը վնասված էր։

Մտածեք այդ մասին, Monit-ը խելահեղորեն վերագործարկում էր Apache2-ը, ամեն անգամ բռնի կերպով անջատելով և վերագործարկելով այն, մի քանի անգամ առաջ-ետ անելով։ Այս գործընթացի ընթացքում /var/run/apache2/apache2.pid ֆայլը կարող է դառնալ 0 բայթ։

Այլ կերպ ասած, ֆայլը դեռ այնտեղ է, բայց դատարկ է։

Երբ Monit-ը կարդում է այս ֆայլը, այն ոչինչ չի գտնում։ Այն չի ճանաչում ձեր Apache2-ը, նույնիսկ եթե այն ֆոնային ռեժիմում կատարյալ անխափան աշխատում է. Monit-ը չի կարծում, որ այդ գործընթացը գոյություն ունի։

Երբ սա տեսա, մի պահ խոսքս կորցրի։

Սա փակուղի է։ Monit-ը չի կարողանում հայտնաբերել Apache 2 օրինակը, վերագործարկում է Apache2-ը, վերագործարկման ընթացքում վնասում է PID ֆայլը, ձախողում է հաջորդ հայտնաբերումը և կրկին վերագործարկում է։ Այս ցիկլը շարունակվում է մինչև ժամանակի սպառումը։

Apache2 մոնիթորինգի խնդիրների լուծում և վերականգնման քայլեր HestiaCP միջավայրում

Անկեղծ ասած, հետաքննության գործընթացը բարդ չէ, բայց դուք պետք է իմանաք, թե որ ուղղությամբ հետաքննել։

Առաջին քայլը որոշելն է, թե ձեր Apache2-ը որ պորտին է լսում։ Պարզապես մուտքագրեք հրաման տերմինալում։

netstat -tulpn | grep apache2

Այլընտրանքորեն, կարող եք օգտագործել `ss` հրամանը. ազդեցությունը նույնն է։

ss -tulpn | grep apache2

Դուք կտեսնեք նմանատիպ արդյունք։

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

Հաստատվել է, որ դա 8081 է, այլ ոչ թե 80: Սա է խնդրի արմատը:

Երկրորդ քայլը վնասված PID ֆայլը վերականգնելն է։ Սա ավելի պարզ է։

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

Նախ, դադարեցրեք Monit-ի մոնիթորինգը՝ կանխելու համար, որ այն խանգարի ձեզ, մինչ դուք շտկում եք խնդիրները։ Այնուհետև վերագործարկեք Apache2-ը՝ մաքուր PID-ը վերաշարադրելու համար։ Վերջապես, օգտագործեք `cat` ֆայլի պարունակությունը ստուգելու համար. այն պետք է պարունակի թվերի տող, այլ ոչ թե դատարկ տող։

Այս քայլն ավարտվելուց հետո խնդիրը հիմնականում լուծված է։

Monit-ի ավանդական ադապտիվ և ագրեսիվ պաշտպանիչ կոնֆիգուրացիաների համեմատական ​​վերլուծություն

Apache2-ը Monit-ով կարգավորելու առցանց ձեռնարկները սովորաբար բաժանվում են երկու կատեգորիայի։

Մի տեսակը «ավանդական ադապտացիայի տեսակն» է, որն օգտագործում է `service` հրամանը՝ ծառայությունները կառավարելու և տեղական պորտերը ստուգելու համար՝ առանց չափազանց շատ բարդ սահմանափակումներ ավելացնելու: Այս կոնֆիգուրացիան կարող է օգտագործվել HestiaCP-ի վրա՝ պարզապես պորտը փոխելով, և այն համեմատաբար կայուն է:

Մեկ այլ մոտեցում է «ագրեսիվ պաշտպանության» մեթոդը, որն օգտագործում է systemctl-ը ծառայությունները կառավարելու համար, ավելացնում է դուստր գործընթացների սահմանափակումներ և կիրառում է ավելի խիստ հայտնաբերման տրամաբանություն: Այն հիանալի տեսք ունի, բայց ունի մեկ կարևոր թերություն. օգտագործվող կանգառի հրամանը `killall -9` է:

Ի՞նչ է նշանակում `killall -9`-ը: Դա նշանակում է սարքը հարկադիր կերպով անջատել՝ անկախ նրանից, թե ինչ է այն անում: Այս կոպիտ բռնի գործողությունը կարող է հեշտությամբ թողնել վնասված PID ֆայլեր, ինչը հենց այն խնդիրն է, որը ես հենց նոր նշեցի:

Իմ անձնական փորձը ցույց է տալիս, որ ագրեսիվ կոնֆիգուրացիայում դուստր պրոցեսների քանակի սահմանափակումը իսկապես օգտակար է: Երբ ձեր Apache2-ը ծանրաբեռնված է CC հարձակման կողմից, դուստր պրոցեսների քանակի սահմանափակումը կարող է կանխել սերվերի հիշողության սպառումը: Այնուամենայնիվ, `killall -9` մոտեցումը իսկապես անօգտագործելի է:

Այսպիսով, վերջում ես փոխզիջման գնացի և համատեղեցի երկու կոնֆիգուրացիաների առավելությունները։

HestiaCP Apache2 Monit-ի լավագույն փորձի կարգավորում

Փոփոխեք /etc/monit/conf.d/apache2 ֆայլը հետևյալ բովանդակությամբ։

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

Թույլ տվեք համառոտ բացատրել այս մի քանի տողերի կարգավորման տրամաբանությունը։

Գրեք 8081 պորտը այնպես, որ այն ճշգրտորեն համապատասխանի HestiaCP-ի հակադարձ պրոքսիի ճարտարապետությանը։ Դադարեք 80 պորտը հիմարաբար գրելուց։

PID ֆայլը կանգնեցնելու համար օգտագործեք `systemctl stop` հրամանը՝ `killall -9`-ի փոխարեն, որպեսզի այն չփչանա։

Ավելացվել է դուստր պրոցեսների սահմանափակում. եթե դուստր պրոցեսների թիվը գերազանցում է 120-ը, գործընթացը կվերսկսվի երկու հաջորդական ցիկլից հետո՝ CC հարձակումները կանխելու համար, բայց դա չափազանց ագրեսիվ չէ։

Խափանումների հայտնաբերման տրամաբանությունը փոփոխվել է՝ օգտագործելով «2 ցիկլի համար» մոտեցումը, ինչը նշանակում է, որ վերագործարկումը տեղի է ունենում միայն երկու անընդմեջ խափանումից հետո, ինչը նվազեցնում է կեղծ դրական արդյունքները: Նախորդ կարգավորումը, որը վերագործարկվում էր ընդամենը մեկ հայտնաբերումից հետո, անկեղծ ասած, մի փոքր չափազանց զգայուն էր:

Վերջնական ժամանակի սահմանափակման շեմը մեղմացվում է մինչև 5 վերագործարկում 10 ցիկլի ընթացքում, ինչը թողնում է բավարար խափանումների հանդուրժողականություն։

HestiaCP Վերահսկել մոնիտորինգԿարգավորման խնդիրների լուծման ամփոփում և փորձի փոխանակում

Կարգավորումների փոփոխությունները կատարելուց հետո ես մոնիթորինգի ենթարկեցի apache2-ը, և վահանակը վերջապես ցույց տվեց կանաչ «OK» ցուցիչը։

Ինչպե՞ս նկարագրեմ այդ ժամանակ իմ զգացողությունները։ Դա նման էր երկու օր միջատի դեմ պայքարելուն, միայն թե պարզվի, որ պատճառը սխալ կարգավորման մեկ տողն էր։ Դա և՛ հիասթափեցնող էր, և՛ ծիծաղելի։

Monit-ը ինքնին լավ բան է, և դեմոնների մոնիթորինգը այն է, ինչ յուրաքանչյուր սերվեր պետք է անի։ Սակայն խնդիրն այն է, որ շատ առցանց ձեռնարկներ հիմնված են այն ենթադրության վրա, որ «Apache2-ը բացառապես օգտագործում է 80-րդ պորտը», մինչդեռ HestiaCP-ն օգտագործում է հակադարձ պրոքսի, ինչը նշանակում է, որ այս ենթադրությունը ճիշտ չէ։

Եթե ​​հետևեք հրահանգներին, խնդիրը դուք չեք, այլ այն, որ ձեռնարկը կիրառելի է ձերից տարբեր իրավիճակում։

Այսպիսով, եթե դուք նաև օգտագործում եք HestiaCP-ն և խառնվում եք Monit-ին՝ Apache2-ը վերահսկելու համար, պարզապես հիշեք երկու բան. փոխեք պորտը 8081-ի և օգտագործեք `systemctl` հրամանը՝ այն կանգնեցնելու համար, այլ ոչ թե `killall -9`-ը: Եթե անեք այս երկու բաները, պետք է կարողանաք խուսափել հետագա խնդիրներից:

Քանի որ մինչև հիմա կարդացիք, եթե օգտակար գտաք, խնդրում եմ հավանեք և կիսվեք։ Եթե ուզում եք առաջինը թարմացումներ ստանալ, կարող եք նաև հետևել ինձ։

Շնորհակալություն եմ հայտնում իմ հոդվածը կարդալու համար։ Կհանդիպենք հաջորդ անգամ։