Monitorառայության մոնիտոր սցենար Linux սերվերների համար. 4 քայլ

2024 Հեղինակ: John Day | [email protected]. Վերջին փոփոխված: 2024-01-30 09:51

Կայուն, մշտապես աշխատող համակարգ ունենալը, նույնիսկ եթե օգտագործում եք Linux- ը, կարող է բարդ խնդիր լինել:

Softwareամանակակից ծրագրային փաթեթների բարդության և վատ կոդավորման պատճառով որոշ գործընթացներ կարող են ժամանակ առ ժամանակ խափանվել: Սա կարող է վատ բան լինել, եթե դուք սերվեր եք աշխատում և որոշ մարդիկ ապավինում են այդ ծառայություններին:

Քայլ 1: Օգտագործելով Systemd- ի կողմից տրամադրված մեթոդները

Ինչպես արդեն գիտեք, Linux- ի ժամանակակից օպերացիոն համակարգերի մեծ մասն օգտագործում է systemd:

Եթե դուք ծանոթ չեք systemd- ին, ապա դա, ըստ վիքիպեդիայի.

«… Սկզբնական համակարգ, որն օգտագործվում է Linux բաշխումներում ՝ օգտվողի տարածքը բեռնաթափելու և հետագայում բոլոր գործընթացները կառավարելու համար, UNIX System V կամ Berkeley Software Distribution (BSD) սկզբնական համակարգերի փոխարեն:…»

Շատերը դեռ վիճում են, թե ինչու էր անհրաժեշտ հին հին լավ համակարգը փոխարինել գործընթացի կառավարման ավելի բարդ համակարգով, բայց հետևյալ հղման վրա կարելի է գտնել լավ բացատրություն.

www.tecmint.com/systemd-replaces-init-in-l…

Ամենակարևոր բարելավումը կլինի այն, որ այն ի վիճակի է դաստիարակել համակարգը ավելի արագ, քան init- ը ՝ բեռնման ընթացքում միաժամանակյա և զուգահեռ մշակման շնորհիվ ՝ init- ի հաջորդական մոտեցման փոխարեն:

Առանց systemd- ի խորքերը, համակարգին գործընթաց ավելացնելու համար դուք պետք է ստեղծեք սպասարկման ֆայլ: Նման ֆայլի շարահյուսությունը կարող է տատանվել շատ պարզից մինչև ծայրաստիճան բարդ, և մենք չենք մանրամասնի: Հիմնական. Սպասարկման ֆայլ ունենալու համար բավական է օգտագործել հետևյալ գրառումները.

[Միավոր] Նկարագրություն = Կիրառման նկարագրություն Փաստաթղթավորում = https://wikipedia.org/ Հետո = local-fs.target network.target առայություն] Տեսակ = simpleExecStart =/usr/sbin/applicationExecReload =/usr/sbin/դիմումի վերաբեռնումը ExecStop =/ usr/sbin/application stopRestart = միշտ [Տեղադրեք] WantedBy = multi-user.target

Տեղադրեք դրանք application.service ֆայլում/lib/systemd/system թղթապանակում:

Այս տարբերակներից յուրաքանչյուրը ինչ է անում, բացատրվում է հետևյալ հղումով.

access.redhat.com/documentation/hy-US/Red_…

Ձեր դիմումը սկսելու համար, թողեք հետևյալ հրամանը.

sudo systemctl սկսել դիմումը: ծառայություն

Նշում. Ծառայության ծառայության ընդլայնումը կարող է բաց թողնվել:

Դիմումը դադարեցնելու համար.

sudo systemctl stop application.service

Եթե կազմաձևման ֆայլը փոխվել է, և ցանկանում եք վերաբեռնել պարամետրերը.

sudo systemctl վերաբեռնում application.service

Theրագիրը վերագործարկելու համար.

sudo systemctl վերագործարկման ծրագիր. ծառայություն

Բեռնման ժամանակ ավտոմատ մեկնարկը միացնելու համար.

sudo systemctl միացնել application.service- ը

Եթե դա միացված է, ապա systemd գործընթացի կառավարիչը կփորձի գործարկել ծրագիրը ՝ հիմնվելով այն համակարգի կարգավորումների վրա, որոնք տրամադրվել են համակարգի ֆայլում:

Անջատելու համար օգտագործեք նույն հրամանը, ինչ վերևում, բայց «անջատել» պարամետրով:

Եթե տեղադրեք Restart = միշտ ծառայության ֆայլում, ապա systemd- ը կհետեւի գործընթացին, և եթե այն չի կարող գտնվել գործընթացի ցանկում, կփորձի ինքնաբերաբար վերագործարկել այն:

Եթե տեղադրեք

RestartSec = 30

վերագործարկման հրահանգից հետո այն կսպասի 30 վայրկյան ՝ նախքան գործընթացը վերսկսել փորձելը: Սա կարող է օգտակար լինել, քանի որ խափանված ծառայության/ծրագրի անընդհատ վերագործարկման փորձը կարող է հանգեցնել համակարգի մեծ պահանջարկի (գրել սխալի տեղեկամատյաններ և այլն)

Ինչպես տեսնում եք, systemd- ն արդեն որոշակի միջոցներ է տրամադրում գործընթացները վերահսկելու համար: Այնուամենայնիվ, որոշ դեպքերում դա կարող է բավարար չլինել: Ինչ անել, եթե գործընթացը դուրս չգա (այն դեռ կլինի գործընթացի ցանկում), բայց դադարի արձագանքել: Այս դեպքում, որպեսզի համոզվեք, որ գործընթացն իսկապես գործարկված է, ձեզ կարող են անհրաժեշտ լինել լրացուցիչ ստուգումներ:

Ահա թե որտեղից այս սցենարի սցենարները օգտակար կլինեն:

Քայլ 2. Կարգավորեք և օգտագործեք ծառայության ստուգիչ սցենարները

Եթե Ձեզ անհրաժեշտ է ավելի շատ վերահսկողություն ձեր ընթացող գործընթացների/ծառայությունների վրա, ապա այս սցենարները, անշուշտ, օգտակար կլինեն:

Քանի որ ծածկագիրը փոքր -ինչ մեծ է, այն վերբեռնված է github- ում և կարելի է գտնել հետևյալ շտեմարանի տակ.

github.com/trex2000/Service-Monitor-Scripts/blob/master/checkService.sh

Ամբողջ փաթեթի «սիրտը» այն է

checkService.sh

Օգտագործելուց առաջ դուք պետք է փոխարինեք ծառայության թղթապանակի ամբողջական ուղին: Սա կարելի է գտնել սցենարի սկզբում:

Սցենարը կարող է վերահսկել մի քանի գործընթաց և կատարել լրացուցիչ առաջադրանքներ, ինչպես նկարագրված է ստորև.

Այն անցնում է.serv կամ.check ընդարձակումներով /ծառայությունների ենթապանակից յուրաքանչյուր ֆայլով և ստուգելու է, արդյոք կա «գործընթաց» կոչվող ակտիվ գործընթաց:

Եթե հայտի համար չկա.check ֆայլ, ապա միայն application.serv ֆայլը ՝

Եթե գործընթացն ակտիվ է, ապա այն գործընթացը կդիտարկի որպես ակտիվ:

Եթե գործընթացը անգործուն է, ապա այն կվերագործարկի ծառայությունը ՝ թողարկելով հետևյալ հրամանը

systemctl վերագործարկման ծրագիր

եթե.serv ֆայլը դատարկ է:

Եթե .serv ֆայլը դատարկ չէ և ունի գործարկվող իրավունքներ, այն կփորձի այն գործարկել որպես պարզ BASH սցենար:

Սա օգտակար է, եթե ծառայությունը պարզապես վերագործարկելուց բացի լրացուցիչ բան պետք է արվի:

Օրինակ, spamd.serv ֆայլում, վերը նշված ռեպոից, եթե spamd ծառայությունը մեռած է, դրա փոխարեն անհրաժեշտ է spamassassin ծառայության վերագործարկում, ինչը նույնպես կվերագործարկի spamd- ը: Միայն spam- ի վերագործարկումը բավարար չէր:

Կարելի է խմբագրել նման սպասարկման ֆայլի բովանդակությունը ըստ կարիքների:

Մեկ այլ օրինակ է pcscd.serv ֆայլը: Այս դեպքում մի քանի այլ գործընթացներ նույնպես վերսկսվեցին/ոչնչացվեցին:

Եթե կա ստուգիչ ֆայլ, ապա ստուգելուց հետո գործընթացը ընթացքի մեջ է, այն կաշխատի նաև այս սցենարային ֆայլը լրացուցիչ ստուգումներ կատարելու համար:

Օրինակ, oscam ծառայության համար մենք ստեղծել ենք չեկային ֆայլ, որը փորձում է միանալ իր վեբ ինտերֆեյսին `պարզելու, արդյոք այն հաջողված է: Եթե ոչ, ապա, չնայած գործընթացը ակտիվ է, ծառայությունը չի արձագանքում և պետք է վերագործարկել: Theառայության վերագործարկումը պետք է կատարվի/կանչի հենց.check ֆայլը:

Մեկ այլ օրինակ կլինի mediatomb DLNA ծառայությունը:

Սա փոքր սերվեր է, որը տեսա/ձայնային բովանդակություն է տրամադրում DLNA հաճախորդներին և հեռարձակվում է ցանցով: Երբեմն ծառայությունը կանգ է առնում և այն այլևս անհնար է հայտնաբերել, բայց գործընթացը դեռ ակտիվ կլինի: Checkառայությունը հայտնաբերելի լինելու համար ստուգելու համար օգտագործվել է gssdp-Discover կոչվող CLI կոմունալը: Ամբողջ ծածկագիրը, որը ստուգում է DLNA սերվերը, տեղադրված էր mediatomb.check սցենարի ներսում:

Սրանք ընդամենը մի քանի օրինակ են, թե ինչպես կարող եք օգտագործել.serv և.check ֆայլերը:

Նոր ծառայության մոնիտորինգի համար դուք պետք է ստեղծեք.serv և, անհրաժեշտության դեպքում, նաև չեկի ֆայլ և դրանց ներսում գրեք համապատասխան սցենարը:

Եթե բավարար է միայն գործընթացի առկայության ստուգումը, ապա բավարար է.serv դատարկ ֆայլը: Եթե լրացուցիչ ստուգումներ պետք է կատարվեն, ապա.check ֆայլ պետք է ստեղծվի, և աշխատանքը կատարելու համար պետք է գրվի փոքր սցենար:

Ըստ էության,.sh սցենարը պետք է պարբերաբար գործարկվի, ուստի դրա համար պետք է ստեղծվի նաև cron աշխատանք.

#ստուգեք գործող ծառայությունները յուրաքանչյուր 5 րոպեն մեկ */5 * * * * /var/bin/ServiceCheck/checkService.sh>/dev/null

Քայլ 3: Վերջնական մտքեր

Հուսով եմ, որ այս փաթեթը օգտակար կգտնեք, քանի որ այն կարող է ուղղակիորեն վերահսկել Linux- ի գործընթացները և հուսով եմ, որ նվազագույնի կհասցնի ձեր ծառայությունների խափանումը:

Ազատորեն վերբեռնեք լրացուցիչ սցենարներ github- ում, եթե նորերը ստեղծեք: Պարզապես տեղեկացրեք ինձ, և ես ձեզ կավելացնեմ որպես մասնակից: