Script Service Monitor pour serveurs Linux : 4 étapes

2024 Auteur: John Day | [email protected]. Dernière modifié: 2024-01-30 09:09

Avoir un système stable et toujours opérationnel, même si vous utilisez Linux, peut être une tâche difficile.

En raison de la complexité des progiciels modernes et du mauvais codage, certains processus peuvent inévitablement planter de temps en temps. Cela pourrait être une mauvaise chose si vous utilisez un serveur et que certaines personnes dépendent de ces services.

Étape 1: Utilisation des méthodes fournies par Systemd

Comme vous le savez peut-être déjà, la plupart des systèmes d'exploitation Linux modernes utilisent systemd.

Si vous n'êtes pas familier avec systemd, voici, selon wikipedia:

"… un système d'initialisation utilisé dans les distributions Linux pour amorcer l'espace utilisateur et gérer tous les processus par la suite, au lieu des systèmes d'initialisation UNIX System V ou Berkeley Software Distribution (BSD). …"

Beaucoup de gens se demandent encore pourquoi il était nécessaire de remplacer le bon vieux système d'initialisation par ce système de gestion de processus plus compliqué, mais sur le lien suivant, on pourrait trouver une bonne explication:

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

L'amélioration la plus importante serait qu'il est capable de lancer le système plus rapidement que init, en raison du traitement simultané et parallèle au démarrage au lieu de l'approche séquentielle d'init

Sans entrer dans les profondeurs de systemd, pour ajouter un processus au systemd, vous devez créer un fichier de service. La syntaxe d'un tel fichier peut aller de très simple à tout à fait compliquée, et nous n'entrerons pas dans les détails. Pour avoir un fichier.service basique, il suffit d'utiliser les entrées suivantes:

[Unit]Description=Description de l'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

Placez-les dans le fichier application.service du dossier /lib/systemd/system.

Le rôle de chacune de ces options est expliqué dans le lien suivant:

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

Afin de démarrer votre application, exécutez la commande suivante:

sudo systemctl démarrer application.service

Remarque: l'extension.service peut être omise.

Pour arrêter l'application:

sudo systemctl arrêter application.service

Si le fichier de configuration a été modifié et que vous souhaitez recharger les paramètres:

sudo systemctl recharger application.service

Pour redémarrer l'application:

sudo systemctl redémarrer application.service

Pour activer le démarrage automatique au démarrage:

sudo systemctl activer application.service

Si cela est activé, le gestionnaire de processus systemd essaiera de démarrer l'application en fonction des paramètres fournis par le fichier système.

Pour le désactiver, utilisez la même commande que ci-dessus, mais avec le paramètre 'disable'.

Si vous placez Restart=always dans le fichier de service, systemd surveillera le processus et s'il est introuvable dans la liste des processus, il essaiera de le redémarrer automatiquement.

Si vous placez

RedémarrerSec=30

après la directive de redémarrage, il attendra 30 secondes avant d'essayer de redémarrer le processus. Cela peut être utile, car une tentative de redémarrage continu d'un service/d'une application défaillante peut entraîner une forte demande sur le système (écriture de journaux d'erreurs, etc.)

Comme vous pouvez le voir, systemd fournit déjà des moyens de surveiller les processus. Cependant, dans certains cas, cela peut ne pas être suffisant. Que se passe-t-il si un processus ne se termine pas (il sera toujours dans la liste des processus), mais qu'il cesse de répondre. Dans ce cas, afin de s'assurer qu'un processus est bien opérationnel, vous devrez peut-être effectuer des vérifications supplémentaires.

Voici où les scripts de cette instructable vous seront utiles.

Étape 2: Configuration et utilisation des scripts de Service Checker

Si vous avez besoin de plus de contrôle sur vos processus/services en cours d'exécution, ces scripts vous seront certainement utiles.

Comme le code est légèrement volumineux, il est téléchargé sur github et se trouve dans le référentiel suivant:

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

Le « cœur » de l'ensemble est le

checkService.sh

Avant de l'utiliser, vous devez remplacer le chemin complet du dossier de service. Celui-ci se trouve au début du script.

Le script peut surveiller plusieurs processus et effectuer des tâches supplémentaires, comme décrit ci-dessous:

Il parcourt chaque fichier du sous-dossier /services ayant les extensions.serv ou.check et vérifie s'il existe un processus actif appelé "application".

S'il n'y a pas de fichier '.check' pour une application, seul le fichier application.serv:

Si le processus est actif, il considérera le processus comme étant actif

Si le processus est inactif, il redémarrera le service en exécutant la commande suivante:

application de redémarrage systemctl

si le fichier.serv est vide !

Si le fichier.serv n'est pas vide et possède des droits d'exécution, il essaiera de l'exécuter comme un simple script BASH.

Ceci est utile si quelque chose doit être fait en plus du simple redémarrage du service.

Par exemple, dans le fichier spamd.serv, à partir du référentiel ci-dessus, au cas où le service spamd est mort, le service spamassassin doit être redémarré à la place, ce qui redémarrera également spamd. Redémarrer juste spamd ne serait pas suffisant.

On peut éditer le contenu d'un tel fichier serv selon les besoins.

Un autre exemple est le fichier pcscd.serv. Dans ce cas, plusieurs autres processus ont également été redémarrés/arrêtés.

S'il existe un fichier de vérification, après avoir vérifié si le processus est en cours d'exécution, il exécutera également ce fichier de script pour effectuer des vérifications supplémentaires.

Par exemple, pour le service oscam, nous avons créé un fichier de vérification qui essaie de se connecter à son interface Web pour voir s'il réussit. Sinon, alors que le processus est actif, le service ne répond pas et doit être redémarré. Le redémarrage du service doit être effectué/appelé par le fichier.check lui-même.

Un autre exemple serait le service DLNA mediatomb.

Il s'agit d'un petit serveur qui fournit du contenu vidéo/audio aux clients DLNA et se diffuse sur le réseau. Parfois, le service se bloque et il n'est plus détectable, mais le processus sera toujours actif. Pour vérifier si le service est détectable, l'utilitaire CLI appelé gssdp-discover a été utilisé. L'ensemble du code qui vérifie le serveur DLNA a été placé dans un script mediatomb.check.

Ce ne sont là que quelques exemples d'utilisation des fichiers.serv et.check.

Afin de surveiller un nouveau service, vous devez créer un.serv et, si nécessaire également un fichier de contrôle et écrire le script correspondant à l'intérieur.

Si seule la vérification de la présence du processus est suffisante, alors un fichier.serv vide sera suffisant. Si des contrôles supplémentaires doivent être effectués, un fichier.check doit être créé et un petit script doit être écrit pour effectuer le travail.

Bien sûr, le script.sh doit être exécuté périodiquement, donc une tâche cron doit également être créée pour cela:

#check les services en cours d'exécution toutes les 5 minutes*/5 * * * * /var/bin/ServiceCheck/checkService.sh >/dev/null

Étape 3: Réflexions finales

J'espère que vous trouverez ce package utile car il peut grandement simplifier la surveillance des processus Linux et, espérons-le, minimisera les temps d'arrêt de vos services.

N'hésitez pas à télécharger des scripts supplémentaires sur github, si vous en créez de nouveaux. Faites-le moi savoir et je vous ajouterai en tant que contributeur.