Script de monitorizare a serviciilor pentru serverele Linux: 4 pași

2024 Autor: John Day | [email protected]. Modificat ultima dată: 2024-01-30 11:46

A avea un sistem stabil, care rulează mereu, chiar dacă utilizați Linux poate fi o sarcină dificilă.

Datorită complexității pachetelor software moderne și a codificării defectuoase, inevitabil, unele procese se pot prăbuși din când în când. Acest lucru ar putea fi un lucru rău dacă rulați un server și unii oameni se bazează pe aceste servicii.

Pasul 1: Utilizarea metodelor furnizate de Systemd

Așa cum ați putea ști deja, majoritatea sistemelor moderne de operare Linux folosesc systemd.

Dacă nu sunteți familiarizat cu systemd, acesta este, conform wikipedia:

„… Un sistem de inițiere utilizat în distribuțiile Linux pentru a porni spațiul utilizatorului și pentru a gestiona toate procesele ulterior, în loc de sistemele de inițiere UNIX System V sau Berkeley Software Distribution (BSD).…”

O mulțime de oameni încă se ceartă de ce a fost necesar să se înlocuiască vechiul sistem inițial cu acest sistem mai complicat de gestionare a proceselor, dar pe următorul link s-ar putea găsi o explicație bună:

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

Cea mai importantă îmbunătățire ar fi că este capabil să aducă sistemul mai repede decât init, datorită procesării simultane și paralele la boot în loc de abordarea secvențială a init

Fără a intra în adâncurile systemd, pentru a adăuga un proces la systemd, trebuie să creați un fișier de serviciu. Sintaxa unui astfel de fișier poate varia de la foarte simplu la complet complicat și nu vom intra în detalii. Pentru a avea un fișier.service de bază, este suficient să utilizați următoarele intrări:

[Unitate] Descriere = Descriere applicationDocumentation = https://wikipedia.org/ After = local-fs.target network.target [Service] Type = simpleExecStart = / usr / sbin / applicationExecReload = / usr / sbin / application reloadExecStop = / usr / sbin / application stopRestart = întotdeauna [Instalare] WantedBy = multi-user.target

Plasați-le în fișierul application.service în folderul / lib / systemd / system.

Ce face fiecare dintre aceste opțiuni este explicat în următorul link:

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

Pentru a porni aplicația, lansați următoarea comandă:

sudo systemctl pornește application.service

Notă: extensia.service poate fi omisă.

Pentru a opri aplicația:

sudo systemctl stop application.service

Dacă fișierul de configurare a fost modificat și doriți să reîncărcați setările:

sudo systemctl reload application.service

Pentru a reporni aplicația:

sudo systemctl reporniți application.service

Pentru a activa pornirea automată la pornire:

sudo systemctl permite application.service

Dacă acest lucru este activat, atunci managerul de proces systemd va încerca să pornească aplicația pe baza setărilor furnizate de fișierul de sistem.

Pentru a-l dezactiva, utilizați aceeași comandă ca mai sus, dar cu parametrul „disable”.

Dacă plasați Restart = întotdeauna în fișierul de service, atunci systemd va monitoriza procesul și dacă nu poate fi găsit în lista de procese, va încerca să îl repornească automat.

Dacă plasezi

RestartSec = 30

după directiva de repornire, va aștepta 30 de secunde înainte de a încerca să repornească procesul. Acest lucru ar putea fi util, deoarece o încercare de repornire continuă a unui serviciu / aplicație care eșuează poate duce la o cerere ridicată a sistemului (scrierea jurnalelor de erori etc.)

După cum puteți vedea, systemd oferă deja câteva mijloace de monitorizare a proceselor. Cu toate acestea, în unele cazuri, acest lucru ar putea să nu fie suficient. Ce se întâmplă dacă un proces nu iese (va fi totuși în lista proceselor), dar nu mai răspunde. În acest caz, pentru a vă asigura că un proces funcționează într-adevăr, este posibil să aveți nevoie de verificări suplimentare.

Aici scenariile din acest instructiv vor fi utile.

Pasul 2: Configurarea și utilizarea scripturilor Service Checker

Dacă aveți nevoie de un control mai mare asupra proceselor / serviciilor dvs. în desfășurare, aceste scripturi vă vor fi de ajutor, cu siguranță.

Deoarece codul este puțin mare, este încărcat pe github și poate fi găsit în următorul depozit:

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

„Inima” întregului pachet este

checkService.sh

Înainte de al utiliza, trebuie să înlocuiți calea completă către folderul de servicii. Acest lucru poate fi găsit la începutul scenariului.

Scriptul poate monitoriza mai multe procese și poate efectua sarcini suplimentare, așa cum este descris mai jos:

Parcurge fiecare fișier din subfolderul / services care are extensii.serv sau.check și va verifica dacă există un proces activ numit „aplicație”.

Dacă nu există fișier „.check” pentru o aplicație, numai fișierul application.serv:

Dacă procesul este activ, acesta va considera procesul ca fiind activ

Dacă procesul este inactiv, atunci va reporni serviciul prin lansarea următoarei comenzi:

systemctl reporniți aplicația

dacă fișierul.serv este gol!

Dacă fișierul.serv nu este gol și are drepturi executabile, va încerca să-l ruleze ca un script BASH simplu.

Acest lucru este util dacă trebuie făcut ceva suplimentar în afară de doar repornirea serviciului.

De exemplu, în fișierul spamd.serv, din repo-ul de mai sus, în cazul în care serviciul spamd este mort, serviciul spamassassin trebuie repornit în schimb, ceea ce va reporni și spamd. Repornirea doar a spam-ului nu ar fi suficientă.

Se poate edita conținutul unui astfel de fișier serv în funcție de necesități.

Un alt exemplu este fișierul pcscd.serv. În acest caz, au fost repornite / ucise și alte câteva procese.

Dacă există un fișier de verificare, după ce a verificat dacă procesul rulează, acesta va rula și acest fișier script pentru a efectua verificări suplimentare.

De exemplu, pentru serviciul oscam, am creat un fișier de verificare care încearcă să se conecteze la interfața sa web pentru a vedea dacă are succes. Dacă nu, atunci, în ciuda faptului că procesul este activ, serviciul nu răspunde și trebuie repornit. Repornirea serviciului trebuie efectuată / apelată chiar de fișierul.check.

Un alt exemplu ar fi serviciul DLNA mediatomb.

Acesta este un server mic care furnizează conținut video / audio clienților DLNA și se transmite singur în rețea. Uneori serviciul se blochează și nu mai este descoperit, dar procesul va fi încă activ. Pentru a verifica dacă serviciul este descoperit, a fost utilizat utilitarul CLI numit gssdp-Discover. Întregul cod care verifică serverul DLNA a fost plasat într-un script mediatomb.check.

Acestea sunt doar câteva exemple despre modul în care puteți utiliza fișierele.serv și.check.

Pentru a monitoriza un serviciu nou, trebuie să creați un.serv și, dacă este necesar, și un fișier de verificare și să scrieți scriptul corespunzător în interiorul lor.

Dacă este suficientă verificarea prezenței procesului, este suficient un fișier.serv gol. Dacă trebuie efectuate verificări suplimentare, atunci trebuie creat un fișier.check și trebuie scris un mic script pentru a face treaba.

Desigur, scriptul.sh trebuie să fie rulat periodic, de aceea trebuie creat și un job cron pentru acesta:

#check serviciile care rulează la fiecare 5 minute * / 5 * * * * /var/bin/ServiceCheck/checkService.sh> / dev / null

Pasul 3: Gânduri finale

Sper că veți găsi util acest pachet, deoarece poate monitoriza foarte mult procesele Linux și sperăm că va reduce timpul de nefuncționare al serviciilor dvs.

Nu ezitați să încărcați scripturi suplimentare pe github, dacă creați altele noi. Doar anunțați-mă și vă voi adăuga ca colaborator.