Përmbajtje:

Skenari i Shërbimit të Monitorit për serverët Linux: 4 hapa
Skenari i Shërbimit të Monitorit për serverët Linux: 4 hapa

Video: Skenari i Shërbimit të Monitorit për serverët Linux: 4 hapa

Video: Skenari i Shërbimit të Monitorit për serverët Linux: 4 hapa
Video: OpenSSH for Windows: The IT Admin's Key to Remote Management 2024, Nëntor
Anonim
Skenari i Shërbimit të Monitorit për serverët Linux
Skenari i Shërbimit të Monitorit për serverët Linux

Të kesh një sistem të qëndrueshëm, gjithmonë në punë, edhe nëse po përdor Linux mund të jetë një detyrë e vështirë.

Për shkak të kompleksitetit të paketave softuerike moderne dhe kodimit të keq, në mënyrë të pashmangshme disa procese mund të rrëzohen herë pas here. Kjo mund të jetë një gjë e keqe nëse jeni duke drejtuar një server dhe disa njerëz mbështeten në këto shërbime.

Hapi 1: Përdorimi i Metodave të Ofruara nga Systemd

Siç mund ta dini tashmë, shumica e sistemeve moderne të funksionimit Linux po përdorin systemd.

Nëse nuk jeni të njohur me systemd, kjo është, sipas wikipedia:

"… një sistem init i përdorur në shpërndarjet Linux për të nisur hapësirën e përdoruesit dhe për të menaxhuar të gjitha proceset më pas, në vend të sistemeve të inicimit të Sistemit UNIX System V ose Berkeley Software Distribution (BSD)."

Shumë njerëz ende po argumentojnë pse ishte e nevojshme të zëvendësohej sistemi i vjetër i mirë i fillimit me këtë sistem më të komplikuar të menaxhimit të procesit, por në lidhjen e mëposhtme mund të gjeni një shpjegim të mirë:

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

Përmirësimi më i rëndësishëm do të ishte se ai është në gjendje të sjellë sistemin më shpejt se init, për shkak të përpunimit paralel dhe paralel në nisje në vend të qasjes sekuenciale të init

Pa hyrë në thellësitë e systemd, për të shtuar një proces në systemd, duhet të krijoni një skedar shërbimi. Sintaksa e një skedari të tillë mund të shkojë nga shumë e thjeshtë në tërësisht e komplikuar, dhe ne nuk do të hyjmë në detaje. Për të pasur një skedar bazë të shërbimit. Mjafton të përdorni shënimet e mëposhtme:

[Njësia] Përshkrimi = Përshkrimi i aplikacionitDokumentacioni = https://wikipedia.org/ Pas = local-fs.target network.target [Shërbimi] Type = simpleExecStart =/usr/sbin/applicationExecReload =/usr/sbin/aplikacioni reloadExecStop =/ usr/sbin/application stopRestart = gjithmonë [Instalo] WantedBy = multi-user.target

Vendosini këto në skedarin application.service në dosjen/lib/systemd/system.

Se çfarë bëjnë secila prej këtyre opsioneve shpjegohet në lidhjen e mëposhtme:

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

Për të filluar aplikimin tuaj, lëshoni komandën e mëposhtme:

sudo systemctl filloni aplikimin.shërbim

Shënim: shtesa e shërbimit mund të hiqet.

Për të ndaluar aplikimin:

sudo systemctl ndalo aplikacionin.shërbim

Nëse skedari i konfigurimit është ndryshuar dhe dëshironi të rifreskoni cilësimet:

sudo systemctl aplikacioni i rimbushjes.shërbimi

Për të rinisur aplikacionin:

sudo systemctl rinis aplikacionin.shërbim

Për të aktivizuar fillimin automatik në nisje:

sudo systemctl aktivizoni aplikacionin.shërbim

Nëse kjo është e aktivizuar, atëherë menaxheri i procesit të sistemit do të përpiqet të nisë aplikacionin bazuar në cilësimet e dhëna nga skedari i sistemit.

Për ta çaktivizuar atë, përdorni të njëjtën komandë si më sipër, por me parametrin 'çaktivizo'.

Nëse vendosni Restart = gjithmonë në skedarin e shërbimit, atëherë systemd do të monitorojë procesin dhe nëse nuk mund të gjendet në listën e proceseve, do të përpiqet ta rifillojë atë automatikisht.

Nëse vendosni

RestartSec = 30

pas direktivës së rifillimit, do të presë 30 sekonda para se të përpiqet të rifillojë procesin. Kjo mund të jetë e dobishme, pasi një përpjekje e vazhdueshme e rinisjes së një shërbimi/aplikacioni të dështuar mund të çojë në kërkesë të lartë në sistem (shkrimi i regjistrave të gabimeve, etj.)

Siç mund ta shihni, systemd tashmë ofron disa mjete për të monitoruar proceset. Sidoqoftë, në disa raste kjo mund të mos jetë e mjaftueshme. Po sikur një proces të mos dalë (ai do të jetë ende në listën e proceseve), por ai ndalon së përgjigjuri. Në këtë rast, në mënyrë që të siguroheni që një proces është me të vërtetë në funksion, mund t'ju nevojiten kontrolle shtesë për t'u kryer.

Këtu do të vijnë në ndihmë skriptet nga ky udhëzues.

Hapi 2: Konfigurimi dhe Përdorimi i Skripteve të Kontrollit të Shërbimit

Nëse keni nevojë për më shumë kontroll mbi proceset/shërbimet tuaja në punë, këto skripte do të jenë të dobishme, me siguri.

Meqenëse kodi është pak i madh, është ngarkuar në github dhe mund të gjendet nën depon e mëposhtme:

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

'Zemra' e të gjithë paketës është

checkService.sh

Para se ta përdorni, duhet të zëvendësoni rrugën e plotë në dosjen e shërbimit. Kjo mund të gjendet në fillim të skenarit.

Skenari mund të monitorojë disa procese dhe të kryejë detyra shtesë, siç përshkruhet më poshtë:

Kalon nëpër secilin skedar nga nën -dosja /shërbimet që ka.serv ose.check shtesa dhe do të kontrollojë nëse ka një proces aktiv të quajtur 'aplikim'.

Nëse nuk ka skedar '. Check' për një aplikacion, vetëm file file.serv:

Nëse procesi është aktiv, ai do ta konsiderojë procesin si aktiv

Nëse procesi është joaktiv, atëherë ai do të rifillojë shërbimin duke lëshuar komandën e mëposhtme:

aplikimi i rifillimit systemctl

nëse skedari.serv është bosh!

Nëse skedari.serv nuk është bosh dhe ka të drejta të ekzekutueshme, do të përpiqet ta ekzekutojë atë si një skript të thjeshtë BASH.

Kjo është e dobishme nëse diçka shtesë duhet të bëhet përveç thjesht rifillimit të shërbimit.

Për shembull, në skedarin spamd.serv, nga repoja e mësipërme, në rast se shërbimi spamd ka vdekur, shërbimi spamassassin duhet të riniset në vend të tij, i cili gjithashtu do të rifillojë spamd. Rinisja vetëm e spam -it nuk do të ishte e mjaftueshme.

Dikush mund të redaktojë përmbajtjen e një skedari të tillë shërbimi sipas nevojave.

Një shembull tjetër është skedari pcscd.serv. Në këtë rast, disa procese të tjera u rifilluan/vranë gjithashtu.

Nëse ka një skedar kontrolli, pasi të kontrolloni nëse procesi po funksionon, ai gjithashtu do të ekzekutojë këtë skedar skripti për të kryer kontrolle shtesë.

Për shembull, për shërbimin oscam, ne kemi krijuar një skedar kontrolli i cili përpiqet të lidhet me ndërfaqen e tij në internet për të parë nëse është i suksesshëm. Nëse jo, atëherë, pavarësisht se procesi është aktiv, shërbimi nuk po përgjigjet dhe duhet të riniset. Rinisja e shërbimit duhet të kryhet/thirret nga vetë skedari.check.

Një shembull tjetër do të ishte shërbimi mediatomb DLNA.

Ky është një server i vogël i cili siguron përmbajtje video/audio për klientët DLNA dhe transmeton vetë në rrjet. Ndonjëherë shërbimi varet dhe nuk zbulohet më, por procesi do të jetë akoma aktiv. Për të kontrolluar nëse shërbimi është i zbulueshëm, u përdor mjeti CLI i quajtur gssdp-Discover. I gjithë kodi që kontrollon serverin DLNA u vendos brenda një skripti mediatomb.check.

Këta janë vetëm disa shembuj se si mund të përdorni skedarët.serv dhe.check.

Për të monitoruar një shërbim të ri, duhet të krijoni një.serv dhe, nëse është e nevojshme, edhe një skedar kontrolli dhe të shkruani skriptin përkatës brenda tyre.

Nëse mjafton vetëm kontrollimi i pranisë së procesit, atëherë një skedar boshe.serv do të jetë i mjaftueshëm. Nëse duhet të kryhen kontrolle shtesë, atëherë duhet të krijohet një skedar.check dhe të shkruhet një shkrim i vogël për të kryer punën.

Nga burimi, skripti.sh duhet të ekzekutohet periodikisht, prandaj një punë cron gjithashtu duhet të krijohet për të:

#kontrolloni funksionimin e shërbimeve çdo 5 minuta */5 * * * * /var/bin/ServiceCheck/checkService.sh>/dev/null

Hapi 3: Mendimet përfundimtare

Shpresoj se do ta gjeni të dobishme këtë paketë pasi mund të monitorojë shumë proceset Linux dhe shpresoj se do të minimizojë kohën e ndërprerjes së shërbimeve tuaja.

Mos ngurroni të ngarkoni skripte shtesë në github, nëse krijoni të reja. Thjesht më njoftoni dhe unë do t'ju shtoj si kontribues.

Recommended: