Skrypt monitora usług dla serwerów Linux: 4 kroki

2024 Autor: John Day | [email protected]. Ostatnio zmodyfikowany: 2024-01-30 11:32

Posiadanie stabilnego, zawsze działającego systemu, nawet jeśli używasz Linuksa, może być trudnym zadaniem.

Ze względu na złożoność nowoczesnych pakietów oprogramowania i złe kodowanie, nieuchronnie niektóre procesy mogą od czasu do czasu ulegać awarii. Może to być złe, jeśli korzystasz z serwera i niektórzy ludzie polegają na tych usługach.

Krok 1: Korzystanie z metod dostarczonych przez Systemd

Jak zapewne już wiesz, większość nowoczesnych systemów operacyjnych Linux używa systemd.

Jeśli nie znasz systemd, to według wikipedii:

„… system startowy używany w dystrybucjach Linuksa do ładowania przestrzeni użytkownika i późniejszego zarządzania wszystkimi procesami, zamiast systemów startowych UNIX System V lub Berkeley Software Distribution (BSD).…”

Wiele osób wciąż spiera się, dlaczego konieczne było zastąpienie starego dobrego systemu init tym bardziej skomplikowanym systemem zarządzania procesami, ale pod poniższym linkiem można znaleźć dobre wyjaśnienie:

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

Najważniejszym ulepszeniem byłoby to, że jest w stanie uruchomić system szybciej niż init, dzięki współbieżnemu i równoległemu przetwarzaniu podczas rozruchu zamiast sekwencyjnego podejścia init

Bez zagłębiania się w systemd, aby dodać proces do systemd, musisz utworzyć plik usługi. Składnia takiego pliku może wahać się od bardzo prostej do bardzo skomplikowanej i nie będziemy wchodzić w szczegóły. Aby mieć podstawowy plik.service wystarczy użyć następujących wpisów:

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

Umieść je w pliku application.service w folderze /lib/systemd/system.

Co robi każda z tych opcji, wyjaśniono w następującym łączu:

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

Aby uruchomić aplikację, wydaj następujące polecenie:

sudo systemctl uruchom aplikację.usługa

Uwaga: rozszerzenie.service można pominąć.

Aby zatrzymać aplikację:

sudo systemctl stop application.service

Jeśli plik konfiguracyjny został zmieniony i chcesz ponownie załadować ustawienia:

sudo systemctl reload application.service

Aby ponownie uruchomić aplikację:

sudo systemctl restart application.service

Aby włączyć automatyczne uruchamianie przy starcie:

sudo systemctl włącz application.service

Jeśli ta opcja jest włączona, menedżer procesów systemowych spróbuje uruchomić aplikację na podstawie ustawień dostarczonych przez plik systemowy.

Aby go wyłączyć, użyj tego samego polecenia co powyżej, ale z parametrem 'disable'.

Jeśli umieścisz Restart=always w pliku usługi, systemd będzie monitorować proces i jeśli nie można go znaleźć na liście procesów, spróbuje go automatycznie zrestartować.

Jeśli umieścisz

RestartSec=30

po dyrektywie restart poczeka 30 sekund przed próbą ponownego uruchomienia procesu. Może to być przydatne, ponieważ ciągła próba ponownego uruchomienia nieudanej usługi/aplikacji może prowadzić do dużego obciążenia systemu (zapisywanie dzienników błędów itp.)

Jak widać, systemd zapewnia już pewne środki do monitorowania procesów. Jednak w niektórych przypadkach może to nie wystarczyć. Co się stanie, jeśli proces się nie zakończy (nadal będzie na liście procesów), ale przestanie odpowiadać. W takim przypadku, aby upewnić się, że proces rzeczywiście działa, może być konieczne wykonanie dodatkowych sprawdzeń.

Tutaj przydadzą się skrypty z tej instrukcji.

Krok 2: Konfiguracja i używanie skryptów Service Checker

Jeśli potrzebujesz większej kontroli nad uruchomionymi procesami/usługami, te skrypty z pewnością będą pomocne.

Ponieważ kod jest nieco duży, został przesłany na github i można go znaleźć w następującym repozytorium:

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

„Sercem” całego pakietu jest

checkService.sh

Przed użyciem należy zastąpić pełną ścieżkę do folderu usługi. Można to znaleźć na początku skryptu.

Skrypt może monitorować kilka procesów i wykonywać dodatkowe zadania, opisane poniżej:

Przechodzi przez każdy plik z podfolderu /services z rozszerzeniem.serv lub.check i sprawdza, czy istnieje aktywny proces o nazwie 'aplikacja'.

Jeśli nie ma pliku '.check' dla aplikacji, tylko plik application.serv:

Jeśli proces jest aktywny, uzna go za aktywny

Jeśli proces jest nieaktywny, zrestartuje usługę, wydając następujące polecenie:

aplikacja restartująca systemctl

jeśli plik.serv jest pusty!

Jeśli plik.serv nie jest pusty i ma uprawnienia do wykonywania, spróbuje go uruchomić jako zwykły skrypt BASH.

Jest to przydatne, jeśli oprócz ponownego uruchomienia usługi trzeba coś dodatkowo zrobić.

Na przykład w pliku spamd.serv z powyższego repozytorium, w przypadku gdy usługa spamd nie działa, należy zamiast tego ponownie uruchomić usługę spamassassin, co również spowoduje ponowne uruchomienie spamd. Ponowne uruchomienie samego spamu nie wystarczy.

Zawartość takiego pliku serv można edytować według potrzeb.

Innym przykładem jest plik pcscd.serv. W tym przypadku kilka innych procesów zostało również zrestartowanych/zabitych.

Jeśli istnieje plik sprawdzania, po sprawdzeniu, czy proces jest uruchomiony, uruchomi również ten plik skryptu w celu wykonania dodatkowych sprawdzeń.

Na przykład dla usługi oscam utworzyliśmy plik kontrolny, który próbuje połączyć się z interfejsem sieciowym, aby sprawdzić, czy się powiódł. Jeśli nie, to pomimo aktywnego procesu usługa nie odpowiada i należy ją ponownie uruchomić. Ponowne uruchomienie usługi musi być wykonane/wywołane przez sam plik.check.

Innym przykładem może być usługa mediatomb DLNA.

Jest to mały serwer, który dostarcza treści wideo/audio klientom DLNA i sam nadaje się do sieci. Czasami usługa zawiesza się i nie można jej już wykryć, ale proces będzie nadal aktywny. Aby sprawdzić, czy usługa jest wykrywalna, użyto narzędzia CLI o nazwie gssdp-discover. Cały kod sprawdzający serwer DLNA został umieszczony w skrypcie mediatomb.check.

To tylko kilka przykładów wykorzystania plików.serv i.check.

Aby monitorować nową usługę, musisz utworzyć plik.serv i, jeśli to konieczne, również plik kontrolny i napisać w nim odpowiedni skrypt.

Jeśli tylko sprawdzenie obecności procesu wystarczy, to wystarczy pusty plik.serv. Jeśli konieczne jest przeprowadzenie dodatkowych sprawdzeń, należy utworzyć plik.check i napisać mały skrypt, aby wykonać zadanie.

Oczywiście skrypt.sh musi być uruchamiany okresowo, dlatego też należy dla niego utworzyć zadanie cron:

#check uruchomionych usług co 5 minut*/5 * * * * /var/bin/ServiceCheck/checkService.sh >/dev/null

Krok 3: Końcowe myśli

Mam nadzieję, że ten pakiet okaże się przydatny, ponieważ może znacznie po prostu monitorować procesy Linuksa i, miejmy nadzieję, zminimalizuje przestoje Twoich usług.

Zapraszam do przesyłania dodatkowych skryptów na github, jeśli tworzysz nowe. Daj mi znać, a dodam Cię jako współtwórcę.