Turinys:

„Linux“serverių paslaugų stebėjimo scenarijus: 4 veiksmai
„Linux“serverių paslaugų stebėjimo scenarijus: 4 veiksmai

Video: „Linux“serverių paslaugų stebėjimo scenarijus: 4 veiksmai

Video: „Linux“serverių paslaugų stebėjimo scenarijus: 4 veiksmai
Video: No More Update Nightmares! Windows 10/11 Mastery for IT Pros Part 2 2024, Lapkritis
Anonim
„Linux“serverių paslaugų stebėjimo scenarijus
„Linux“serverių paslaugų stebėjimo scenarijus

Turėti stabilią, visada veikiančią sistemą, net jei naudojate „Linux“, gali būti sudėtinga užduotis.

Dėl šiuolaikinių programinės įrangos paketų sudėtingumo ir blogo kodavimo neišvengiamai kai kurie procesai kartkartėmis gali sugesti. Tai gali būti blogai, jei naudojate serverį ir kai kurie žmonės pasitiki šiomis paslaugomis.

1 žingsnis: „Systemd“pateiktų metodų naudojimas

Kaip jau žinote, dauguma šiuolaikinių „Linux“operacinių sistemų naudoja „systemd“.

Jei nesate susipažinę su „systemd“, tai yra, pagal „wikipedia“:

„…„ Init “sistema, naudojama„ Linux “platinimuose, kad būtų galima paleisti vartotojo erdvę ir vėliau valdyti visus procesus, o ne„ UNIX System V “arba„ Berkeley Software Distribution “(BSD) inicialų sistemas.

Daugelis žmonių vis dar ginčijasi, kodėl seną gerą „init“sistemą reikėjo pakeisti šia sudėtingesne proceso valdymo sistema, tačiau šioje nuorodoje galite rasti gerą paaiškinimą:

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

Svarbiausias patobulinimas būtų tai, kad ji gali sukurti sistemą greičiau nei init, nes vienu metu ir lygiagrečiai apdorojama paleidžiant, o ne nuoseklus metodas init

Nesigilindami į sistemos gilumą, norėdami pridėti procesą prie sistemos, turite sukurti paslaugos failą. Tokio failo sintaksė gali būti nuo labai paprastos iki visiškai sudėtingos, ir mes nesileisime į detales. Norint turėti pagrindinį.service failą, pakanka naudoti šiuos įrašus:

[Vienetas] Aprašymas = applicationDocumentation = https://wikipedia.org/ After = local-fs.target network.target [Paslauga] Tipas = simpleExecStart =/usr/sbin/applicationExecReload =/usr/sbin/application reloadExecStop =/ usr/sbin/application stopRestart = visada [Įdiegti] WantedBy = multi-user.target

Įdėkite juos į application.service failą aplanke/lib/systemd/system.

Ką daro kiekviena iš šių parinkčių, paaiškinta šioje nuorodoje:

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

Norėdami pradėti savo programą, paleiskite šią komandą:

sudo systemctl paleisti application.service

Pastaba:.service plėtinį galima praleisti.

Norėdami sustabdyti programą:

sudo systemctl sustabdyti application.service

Jei konfigūracijos failas buvo pakeistas ir norite iš naujo įkelti nustatymus:

sudo systemctl reload application.service

Norėdami iš naujo paleisti programą:

sudo systemctl iš naujo paleiskite programą. paslauga

Norėdami įjungti automatinį paleidimą paleidžiant:

sudo systemctl įgalinti application.service

Jei tai įjungta, sisteminio proceso valdytojas bandys paleisti programą pagal sistemos failo nustatymus.

Norėdami jį išjungti, naudokite tą pačią komandą, kaip nurodyta aukščiau, bet su parametru „išjungti“.

Jei paslaugų faile įdėsite „Restart =“visada, tada „systemd“stebės procesą ir, jei jo nepavyks rasti procesų sąraše, jis bandys jį automatiškai paleisti iš naujo.

Jei vieta

RestartSec = 30

po paleidimo iš naujo direktyvos ji palauks 30 sekundžių, kol bandys iš naujo paleisti procesą. Tai gali būti naudinga, nes nuolatinis nesėkmingos paslaugos/programos bandymas iš naujo paleisti sistemą gali sukelti didelę paklausą (rašant klaidų žurnalus ir pan.)

Kaip matote, „systemd“jau siūlo tam tikras priemones procesams stebėti. Tačiau kai kuriais atvejais to gali nepakakti. Ką daryti, jei procesas neišeina (jis vis tiek bus procesų sąraše), bet nustoja reaguoti. Tokiu atveju, norint įsitikinti, kad procesas tikrai veikia ir veikia, gali tekti atlikti papildomus patikrinimus.

Štai kur pravers šios instrukcijos scenarijai.

2 veiksmas: Paslaugų tikrinimo scenarijų konfigūravimas ir naudojimas

Jei jums reikia daugiau valdyti savo vykdomus procesus/paslaugas, šie scenarijai tikrai bus naudingi.

Kadangi kodas yra šiek tiek didelis, jis įkeltas į „github“ir jį galima rasti šioje saugykloje:

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

Viso paketo „širdis“yra

checkService.sh

Prieš naudodami, turite pakeisti visą paslaugų aplanko kelią. Tai galima rasti scenarijaus pradžioje.

Scenarijus gali stebėti kelis procesus ir atlikti papildomą užduotį, kaip aprašyta toliau:

Jis eina per visus failus iš /services poaplankio, turinčio.serv arba.check plėtinius, ir patikrins, ar yra aktyvus procesas, vadinamas programa.

Jei programoje nėra.check failo, tik application.serv failas:

Jei procesas yra aktyvus, jis jį laikys aktyviu

Jei procesas neaktyvus, jis iš naujo paleis paslaugą, išleisdamas šią komandą:

systemctl iš naujo paleiskite programą

jei.serv failas tuščias!

Jei.serv failas nėra tuščias ir turi vykdomąsias teises, jis bandys jį paleisti kaip paprastą BASH scenarijų.

Tai naudinga, jei reikia ką nors papildomai padaryti, o ne tik iš naujo paleisti paslaugą.

Pavyzdžiui, spamd.serv faile, iš aukščiau esančios repo, jei šiukšlių siuntimo paslauga yra mirusi, vietoj to reikia iš naujo paleisti „spamassassin“paslaugą, kuri taip pat iš naujo paleidžia šlamštą. Nepakanka iš naujo paleisti tik šlamštą.

Tokio servo failo turinį galima redaguoti pagal poreikius.

Kitas pavyzdys yra failas pcscd.serv. Šiuo atveju taip pat buvo iš naujo paleisti/užmušti keli kiti procesai.

Jei yra patikrinimo failas, patikrinęs, ar procesas vyksta, jis taip pat paleis šį scenarijaus failą, kad atliktų papildomus patikrinimus.

Pavyzdžiui, „oscam“paslaugai sukūrėme tikrinimo failą, kuris bando prisijungti prie jo žiniatinklio sąsajos, kad pamatytumėte, ar ji sėkminga. Jei ne, tada, nepaisant to, kad procesas yra aktyvus, paslauga nereaguoja ir ją reikia iš naujo paleisti. Paslaugos paleidimą iš naujo turi atlikti/iškviesti pats.check failas.

Kitas pavyzdys būtų tarpinės DLNA paslauga.

Tai mažas serveris, kuris teikia vaizdo/garso turinį DLNA klientams ir transliuoja pats tinkle. Kartais paslauga užstringa ir jos nebeįmanoma atrasti, tačiau procesas vis tiek bus aktyvus. Norėdami patikrinti, ar paslauga aptinkama, buvo naudojama CLI programa, vadinama gssdp-discover. Visas kodas, kuris tikrina DLNA serverį, buvo įdėtas į media media.check scenarijų.

Tai tik keli pavyzdžiai, kaip galite naudoti.serv ir.check failus.

Norėdami stebėti naują paslaugą, turite sukurti.serv ir, jei reikia, patikrinti failą ir į juos įrašyti atitinkamą scenarijų.

Jei pakanka tik patikrinti proceso buvimą, pakanka tuščio.serv failo. Jei reikia atlikti papildomus patikrinimus, reikia sukurti.check failą ir parašyti nedidelį scenarijų, kad būtų atliktas darbas.

Žinoma, „.sh“scenarijus turi būti vykdomas periodiškai, todėl jam taip pat turi būti sukurtas „cron“darbas:

#patikrinkite veikiančias paslaugas kas 5 minutes */5 * * * * /var/bin/ServiceCheck/checkService.sh>/dev/null

3 žingsnis: paskutinės mintys

Tikiuosi, kad šis paketas jums bus naudingas, nes jis gali labai lengvai stebėti „Linux“procesus ir, tikiuosi, sumažins jūsų paslaugų prastovas.

Nesivaržykite įkelti papildomų scenarijų į „github“, jei kuriate naujus. Tiesiog praneškite man ir aš pridėsiu jus kaip bendradarbį.

Rekomenduojamas: