Service Monitor-script voor Linux-servers: 4 stappen

2024 Auteur: John Day | [email protected]. Laatst gewijzigd: 2024-01-30 11:19

Het hebben van een stabiel, altijd draaiend systeem, zelfs als je Linux gebruikt, kan een moeilijke taak zijn.

Vanwege de complexiteit van moderne softwarepakketten en slechte codering, kunnen sommige processen onvermijdelijk van tijd tot tijd crashen. Dit kan een slechte zaak zijn als u een server gebruikt en sommige mensen op deze services vertrouwen.

Stap 1: Methoden gebruiken die worden aangeboden door Systemd

Zoals je misschien al weet, gebruiken de meeste moderne Linux-besturingssystemen systemd.

Als je niet bekend bent met systemd, is dit volgens wikipedia:

"… een init-systeem dat wordt gebruikt in Linux-distributies om de gebruikersruimte op te starten en alle processen vervolgens te beheren, in plaats van de UNIX System V of Berkeley Software Distribution (BSD) init-systemen. …"

Veel mensen beweren nog steeds waarom het nodig was om het goede oude init-systeem te vervangen door dit meer gecompliceerde procesbeheersysteem, maar op de volgende link vindt u misschien een goede verklaring:

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

De belangrijkste verbetering zou zijn dat het in staat is om het systeem sneller op te starten dan init, vanwege gelijktijdige en parallelle verwerking bij het opstarten in plaats van de sequentiële benadering van init

Zonder in de diepten van systemd te gaan, om een proces aan systemd toe te voegen, moet u een servicebestand maken. De syntaxis van zo'n bestand kan variëren van heel eenvoudig tot uiterst gecompliceerd, en we zullen niet in details treden. Om een basis.service-bestand te hebben, volstaat het om de volgende vermeldingen te gebruiken:

[Unit]Description=Beschrijving van applicationDocumentation=https://wikipedia.org/ After=local-fs.target network.target[Service]Type=simpleExecStart=/usr/sbin/applicationExecReload=/usr/sbin/application reloadExecStop=/ usr/sbin/application stopRestart=altijd[Install]WantedBy=multi-user.target

Plaats deze in het bestand application.service in de map /lib/systemd/system.

Wat elk van deze opties doet, wordt uitgelegd in de volgende link:

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

Geef de volgende opdracht om uw toepassing te starten:

sudo systemctl start application.service

Let op: de.service-extensie kan worden weggelaten.

Om de toepassing te stoppen:

sudo systemctl stop application.service

Als het configuratiebestand is gewijzigd en u de instellingen opnieuw wilt laden:

sudo systemctl herlaad application.service

Om de applicatie opnieuw te starten:

sudo systemctl herstart application.service

Automatisch starten bij opstarten inschakelen:

sudo systemctl enable application.service

Als dit is ingeschakeld, zal de procesbeheerder van systemd proberen de applicatie op te starten op basis van de instellingen die door het systeembestand zijn verstrekt.

Om het uit te schakelen, gebruikt u dezelfde opdracht als hierboven, maar met de parameter 'uitschakelen'.

Als u Restart=always in het servicebestand plaatst, zal systemd het proces controleren en als het niet in de proceslijst kan worden gevonden, zal het proberen het automatisch opnieuw op te starten.

Als je plaatst

HerstartSec = 30

na de herstartrichtlijn, wacht het 30 seconden voordat het probeert het proces opnieuw op te starten. Dit kan handig zijn, omdat een continue herstartpoging van een falende service/toepassing kan leiden tot een hoge belasting van het systeem (schrijven van foutenlogboeken, enz.)

Zoals u kunt zien, biedt systemd al een aantal middelen om de processen te bewaken. In sommige gevallen is dit echter niet voldoende. Wat als een proces niet afsluit (het staat nog steeds in de proceslijst), maar niet meer reageert. In dit geval, om er zeker van te zijn dat een proces inderdaad actief is, moet u mogelijk aanvullende controles uitvoeren.

Hier komen de scripts uit deze instructable van pas.

Stap 2: De Service Checker-scripts configureren en gebruiken

Als u meer controle over uw actieve processen/services nodig heeft, zullen deze scripts zeker nuttig zijn.

Omdat de code enigszins groot is, wordt deze geüpload naar github en kan deze worden gevonden onder de volgende repository:

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

Het 'hart' van het hele pakket is de

checkService.sh

Voordat u het gebruikt, moet u het volledige pad naar de servicemap vervangen. Deze vind je aan het begin van het script.

Het script kan verschillende processen bewaken en extra taken uitvoeren, zoals hieronder beschreven:

Het doorloopt alle bestanden uit de /services-submap met de extensie.serv of.check en controleert of er een actief proces is genaamd 'application'.

Als er geen '.check'-bestand voor een applicatie is, alleen het applicatie.serv-bestand:

Als het proces actief is, zal het het proces als actief beschouwen

Als het proces inactief is, wordt de service opnieuw gestart door de volgende opdracht uit te voeren:

systemctl herstart applicatie

als het.serv-bestand leeg is!

Als het.serv-bestand niet leeg is en uitvoerrechten heeft, zal het proberen het uit te voeren als een gewoon BASH-script.

Dit is handig als er nog iets anders moet worden gedaan dan alleen de service opnieuw te starten.

Bijvoorbeeld, in het bestand spamd.serv uit de repo hierboven, in het geval dat de spamd-service dood is, moet de spamassassin-service in plaats daarvan opnieuw worden gestart, waardoor spamd ook opnieuw wordt gestart. Herstarten alleen spam zou niet voldoende zijn.

Men kan de inhoud van zo'n serv-bestand aanpassen aan de behoeften.

Een ander voorbeeld is het bestand pcscd.serv. In dit geval zijn ook verschillende andere processen opnieuw gestart/gedood.

Als er een controlebestand is, zal het, na te hebben gecontroleerd of het proces loopt, dit scriptbestand ook uitvoeren om aanvullende controles uit te voeren.

Voor de oscam-service hebben we bijvoorbeeld een controlebestand gemaakt dat verbinding probeert te maken met de webinterface om te zien of het succesvol is. Als dit niet het geval is, reageert de service niet, ondanks dat het proces actief is, en moet deze opnieuw worden gestart. De herstart van de service moet worden uitgevoerd/aangeroepen door het.check-bestand zelf.

Een ander voorbeeld is de mediatomb DLNA-service.

Dit is een kleine server die video/audio-inhoud levert aan DLNA-clients en zichzelf uitzendt op het netwerk. Soms loopt de service vast en is deze niet meer detecteerbaar, maar het proces is nog steeds actief. Om te controleren of de service detecteerbaar is, werd het CLI-hulpprogramma gssdp-discover gebruikt. De hele code die de DLNA-server controleert, is in een mediatomb.check-script geplaatst.

Dit zijn slechts enkele voorbeelden van hoe u de.serv- en.check-bestanden kunt gebruiken.

Om een nieuwe service te monitoren, moet u een.serv-bestand maken en, indien nodig, ook een controlebestand en het bijbehorende script erin schrijven.

Als alleen het controleren van de aanwezigheid van het proces voldoende is, dan is een leeg.serv-bestand voldoende. Als er extra controles moeten worden uitgevoerd, moet er een.check-bestand worden gemaakt en moet er een klein script worden geschreven om de klus te klaren.

Natuurlijk moet het.sh-script periodiek worden uitgevoerd, daarom moet er ook een cron-job voor worden gemaakt:

#check actieve services elke 5 minuten*/5 * * * * /var/bin/ServiceCheck/checkService.sh >/dev/null

Stap 3: Laatste gedachten

Ik hoop dat je dit pakket nuttig zult vinden, omdat het heel eenvoudig de bewaking van Linux-processen kan uitvoeren en hopelijk de downtime van je services zal minimaliseren.

Voel je vrij om extra scripts naar github te uploaden, als je nieuwe maakt. Laat het me weten en ik voeg je toe als bijdrager.