Script di monitoraggio del servizio per server Linux: 4 passaggi

2024 Autore: John Day | [email protected]. Ultima modifica: 2024-01-30 10:04

Avere un sistema stabile e sempre in esecuzione, anche se stai usando Linux, può essere un compito difficile.

A causa della complessità dei moderni pacchetti software e della cattiva codifica, inevitabilmente alcuni processi potrebbero bloccarsi di tanto in tanto. Questa potrebbe essere una cosa negativa se stai eseguendo un server e alcune persone si affidano a questi servizi.

Passaggio 1: utilizzo dei metodi forniti da Systemd

Come forse già saprai, la maggior parte dei moderni sistemi operativi Linux utilizza systemd.

Se non hai familiarità con systemd, questo è, secondo wikipedia:

"… un sistema di inizializzazione utilizzato nelle distribuzioni Linux per avviare lo spazio utente e gestire successivamente tutti i processi, invece dei sistemi di inizializzazione di UNIX System V o Berkeley Software Distribution (BSD). …"

Molte persone stanno ancora discutendo sul perché fosse necessario sostituire il buon vecchio sistema init con questo più complicato sistema di gestione dei processi, ma al seguente link si potrebbe trovare una buona spiegazione:

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

Il miglioramento più importante sarebbe che è in grado di avviare il sistema più velocemente di init, grazie all'elaborazione simultanea e parallela all'avvio invece dell'approccio sequenziale di init

Senza entrare nelle profondità di systemd, per aggiungere un processo a systemd, è necessario creare un file di servizio. La sintassi di un tale file può variare da molto semplice a estremamente complicata e non entreremo nei dettagli. Per avere un file.service di base è sufficiente utilizzare le seguenti voci:

[Unit]Description=Descrizione di 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

Inseriscili nel file application.service nella cartella /lib/systemd/system.

Cosa fanno ciascuna di queste opzioni è spiegato nel seguente link:

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

Per avviare la tua applicazione, dai il seguente comando:

sudo systemctl start application.service

Nota: l'estensione.service può essere omessa.

Per interrompere l'applicazione:

sudo systemctl stop application.service

Se il file di configurazione è stato modificato e desideri ricaricare le impostazioni:

sudo systemctl reload application.service

Per riavviare l'applicazione:

sudo systemctl riavvia application.service

Per abilitare l'avvio automatico all'avvio:

sudo systemctl enable application.service

Se questa opzione è abilitata, il gestore processi systemd proverà ad avviare l'applicazione in base alle impostazioni fornite dal file di sistema.

Per disabilitarlo, usa lo stesso comando di sopra, ma con il parametro 'disable'.

Se inserisci Restart=sempre nel file di servizio, systemd monitorerà il processo e se non può essere trovato nell'elenco dei processi, proverà a riavviarlo automaticamente.

Se metti

RiavviaSec=30

dopo la direttiva di riavvio, aspetterà 30 secondi prima di provare a riavviare il processo. Questo potrebbe essere utile, poiché un tentativo di riavvio continuo di un servizio/applicazione in errore può portare a un'elevata richiesta sul sistema (scrittura di log degli errori, ecc.)

Come puoi vedere, systemd fornisce già alcuni mezzi per monitorare i processi. Tuttavia, in alcuni casi questo potrebbe non essere sufficiente. Cosa succede se un processo non esce (sarà ancora nell'elenco dei processi), ma smette di rispondere. In questo caso, per essere sicuri che un processo sia effettivamente attivo e funzionante, potrebbe essere necessario eseguire ulteriori controlli.

Qui è dove gli script di questo istruibile torneranno utili.

Passaggio 2: configurazione e utilizzo degli script di Service Checker

Se hai bisogno di un maggiore controllo dei tuoi processi/servizi in esecuzione, questi script saranno sicuramente utili.

Poiché il codice è leggermente grande, viene caricato su github e può essere trovato nel seguente repository:

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

Il 'cuore' di tutto il pacchetto è il

checkService.sh

Prima di utilizzarlo, è necessario sostituire il percorso completo della cartella del servizio. Questo può essere trovato all'inizio dello script.

Lo script può monitorare diversi processi ed eseguire attività aggiuntive, come descritto di seguito:

Passa attraverso ogni file dalla sottocartella /services con estensione.serv o.check e controlla se c'è un processo attivo chiamato 'applicazione'.

Se non esiste un file '.check' per un'applicazione, solo il file application.serv:

Se il processo è attivo, lo considererà attivo

Se il processo è inattivo, riavvierà il servizio emettendo il seguente comando:

systemctl riavvia l'applicazione

se il file.serv è vuoto!

Se il file.serv non è vuoto e dispone dei diritti eseguibili, proverà a eseguirlo come un semplice script BASH.

Questo è utile se è necessario fare qualcosa in più oltre al semplice riavvio del servizio.

Ad esempio, nel file spamd.serv, dal repository sopra, nel caso in cui il servizio spamd sia morto, è necessario riavviare il servizio spamassassin, che riavvierà anche spamd. Riavviare solo spamd non sarebbe sufficiente.

È possibile modificare il contenuto di tale file serv in base alle esigenze.

Un altro esempio è il file pcscd.serv. In questo caso sono stati riavviati/terminati anche molti altri processi.

Se è presente un file di controllo, dopo aver verificato se il processo è in esecuzione, eseguirà anche questo file di script per eseguire ulteriori controlli.

Ad esempio, per il servizio oscam, abbiamo creato un file di controllo che tenta di connettersi alla sua interfaccia web per vedere se ha successo. In caso contrario, nonostante il processo sia attivo, il servizio non risponde e deve essere riavviato. Il riavvio del servizio deve essere eseguito/chiamato dal file.check stesso.

Un altro esempio potrebbe essere il servizio DLNA mediatomb.

Questo è un piccolo server che fornisce contenuti video/audio ai client DLNA e si trasmette sulla rete. A volte il servizio si blocca e non è più rilevabile, ma il processo sarà ancora attivo. Per verificare se il servizio è rilevabile, è stata utilizzata l'utilità CLI denominata gssdp-discover. L'intero codice che controlla il server DLNA è stato inserito all'interno di uno script mediatomb.check.

Questi sono solo alcuni esempi su come utilizzare i file.serv e.check.

Per monitorare un nuovo servizio è necessario creare un.serv e, se necessario, anche un file di controllo e scrivere al loro interno lo script corrispondente.

Se è sufficiente solo la verifica della presenza del processo, sarà sufficiente un file.serv vuoto. Se è necessario eseguire ulteriori controlli, è necessario creare un file.check e scrivere un piccolo script per eseguire il lavoro.

Ovviamente lo script.sh deve essere eseguito periodicamente, quindi deve essere creato anche un cron job per esso:

#check servizi in esecuzione ogni 5 minuti*/5 * * * * /var/bin/ServiceCheck/checkService.sh >/dev/null

Passaggio 3: considerazioni finali

Spero che troverete questo pacchetto utile in quanto può semplificare notevolmente il monitoraggio dei processi Linux e, si spera, ridurre al minimo i tempi di inattività dei vostri servizi.

Sentiti libero di caricare script aggiuntivi su github, se ne crei di nuovi. Fammelo sapere e ti aggiungerò come contributore.