Service Monitor Script за Linux сървъри: 4 стъпки

2024 Автор: John Day | [email protected]. Последно модифициран: 2024-01-30 07:54

Наличието на стабилна, винаги работеща система, дори ако използвате Linux, може да бъде трудна задача.

Поради сложността на съвременните софтуерни пакети и лошото кодиране, неизбежно някои процеси могат да се сринат от време на време. Това може да е лошо, ако използвате сървър и някои хора разчитат на тези услуги.

Стъпка 1: Използване на методи, предоставени от Systemd

Както може би вече знаете, повечето съвременни операционни системи Linux използват systemd.

Ако не сте запознати с systemd, това е според wikipedia:

"… init система, използвана в дистрибуциите на Linux за зареждане на потребителското пространство и управление на всички процеси впоследствие, вместо UNIT System V или Berkeley Software Distribution (BSD) init системи. …"

Много хора все още спорят защо е било необходимо да се замени старата добра init система с тази по -сложна система за управление на процеси, но на следната връзка може да се намери добро обяснение:

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

Най -важното подобрение би било, че е в състояние да изведе системата по -бързо от init, поради едновременната и паралелна обработка при зареждане вместо последователния подход на init

Без да навлизате в дълбочините на systemd, за да добавите процес към systemd, трябва да създадете служебен файл. Синтаксисът на такъв файл може да варира от много прости до напълно сложни и няма да навлизаме в подробности. За да имате основен.service файл, достатъчно е да използвате следните записи:

[Единица] Описание = Описание на applicationDocumentation = https://wikipedia.org/ After = local-fs.target network.target [Service] Type = simpleExecStart =/usr/sbin/applicationExecReload =/usr/sbin/application reloadExecStop =/ usr/sbin/application stopRestart = винаги [Инсталиране] WantedBy = многопотребителска цел

Поставете ги във файла application.service в/lib/systemd/system папка.

Какво прави всяка от тези опции е обяснено в следната връзка:

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

За да стартирате приложението си, издайте следната команда:

sudo systemctl стартирайте application.service

Забележка: Разширението.service може да бъде пропуснато.

За да спрете приложението:

sudo systemctl stop application.service

Ако конфигурационният файл е променен и искате да презаредите настройките:

sudo systemctl презаредете application.service

За да рестартирате приложението:

sudo systemctl рестартирайте application.service

За да активирате автоматичното стартиране при зареждане:

sudo systemctl активира application.service

Ако това е разрешено, тогава системният мениджър на процеси ще се опита да стартира приложението въз основа на настройките, предоставени от системния файл.

За да го деактивирате, използвайте същата команда, както по -горе, но с параметър 'disable'.

Ако поставите Restart = винаги в сервизния файл, тогава systemd ще следи процеса и ако не може да бъде намерен в списъка с процеси, ще се опита да го рестартира автоматично.

Ако поставите

RestartSec = 30

след директивата за рестартиране, тя ще изчака 30 секунди, преди да се опита да рестартира процеса. Това може да бъде полезно, тъй като непрекъснатият опит за рестартиране на неуспешна услуга/приложение може да доведе до голямо търсене на системата (писане на журнали за грешки и т.н.)

Както можете да видите, systemd вече предоставя някои средства за наблюдение на процесите. В някои случаи обаче това може да не е достатъчно. Какво става, ако процесът не излезе (той все още ще бъде в списъка с процеси), но спира да реагира. В този случай, за да се уверите, че процесът наистина е изпълнен и може да се наложи да извършите допълнителни проверки.

Тук скриптовете от тази инструкция ще ви бъдат полезни.

Стъпка 2: Конфигуриране и използване на скриптове за проверка на услуги

Ако имате нужда от по -голям контрол върху вашите работещи процеси/услуги, тези скриптове със сигурност ще ви бъдат полезни.

Тъй като кодът е малко голям, той е качен в github и може да бъде намерен в следното хранилище:

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

„Сърцето“на целия пакет е

checkService.sh

Преди да го използвате, трябва да замените пълния път до служебната папка. Това може да се намери в началото на скрипта.

Скриптът може да наблюдава няколко процеса и да изпълнява допълнителна задача, както е описано по -долу:

Той преминава през всички файлове от подпапката /services с разширения.serv или.check и ще провери дали има активен процес, наречен „приложение“.

Ако няма файл „.check“за приложение, само файл application.serv:

Ако процесът е активен, той ще счита процеса за активен

Ако процесът е неактивен, той ще рестартира услугата, като издаде следната команда:

приложение за рестартиране на systemctl

ако.serv файлът е празен!

Ако.serv файлът не е празен и има изпълними права, той ще се опита да го изпълни като обикновен BASH скрипт.

Това е полезно, ако освен рестартиране на услугата трябва да се направи нещо допълнително.

Например във файла spamd.serv, от горното репо, в случай, че услугата spamd е мъртва, вместо това услугата spamassassin трябва да се рестартира, което също ще рестартира spamd. Рестартирането само на спам не би било достатъчно.

Човек може да редактира съдържанието на такъв serv файл според нуждите.

Друг пример е pcscd.serv файл. В този случай няколко други процеса също бяха рестартирани/убити.

Ако има файл за проверка, след проверка дали процесът се изпълнява, той също ще стартира този скриптов файл, за да извърши допълнителни проверки.

Например за услугата oscam създадохме файл за проверка, който се опитва да се свърже с уеб интерфейса си, за да види дали е успешен. Ако не, тогава, въпреки че процесът е активен, услугата не реагира и трябва да се рестартира. Рестартирането на услугата трябва да се извърши/извика от самия.check файл.

Друг пример би бил DLNA услугата mediatomb.

Това е малък сървър, който предоставя видео/аудио съдържание на DLNA клиенти и се излъчва в мрежата. Понякога услугата виси и вече не може да се открие, но процесът все още ще бъде активен. За да проверите дали услугата може да бъде открита, беше използвана помощната програма за CLI, наречена gssdp-discovery. Целият код, който проверява DLNA сървъра, е поставен в скрипт mediatomb.check.

Това са само няколко примера за това как можете да използвате файловете.serv и.check.

За да наблюдавате нова услуга, трябва да създадете.serv и, ако е необходимо, също и файл за проверка и да напишете съответния скрипт вътре в тях.

Ако е достатъчно да се провери само наличието на процеса, тогава ще бъде достатъчен празен.serv файл. Ако трябва да се извършат допълнителни проверки, тогава трябва да се създаде.check файл и да се напише малък скрипт, за да свърши работата.

Разбира се,.sh скриптът трябва да се изпълнява периодично, затова за него трябва да се създаде и cron работа:

#проверете работещите услуги на всеки 5 минути */5 * * * * /var/bin/ServiceCheck/checkService.sh>/dev/null

Стъпка 3: Заключителни мисли

Надявам се, че ще намерите този пакет за полезен, тъй като може много просто да наблюдава процесите в Linux и да се надяваме, че ще сведе до минимум престоя на вашите услуги.

Чувствайте се свободни да качвате допълнителни скриптове в github, ако създавате нови. Само ме уведомете и ще ви добавя като сътрудник.