Introduction

Certains services Linux sont conçus pour s'arrêter après initialisation — ce qui déclenche les moniteurs de service. Si vous en surveillez un avec un moniteur de service dans Level, vous obtiendrez des fausses alertes. La solution est un moniteur de script qui litSubState instead of ActiveState.

Pourquoi les moniteurs de service déclenchent des fausses alertes

systemd suit chaque unité dans deux champs d'état : ActiveState and SubState. Les moniteurs de service vérifient ActiveState — values like active, inactive , or failed.

The problem: certains services s'arrêtent après avoir accompli leur tâche et n'entrent jamais dans un état persistant active La wg-quickest l'exemple le plus courant. Il configure l'interface VPN, puis s'arrête. systemd enregistre ActiveState as inactive (exited) . Un moniteur de service voit inactive et déclenche une alerte — même si le VPN fonctionne correctement, l'interface est active et le trafic est routé.

SubState raconte une histoire plus précise. Pour les services comme wg-quick , un SubState sain est exited — attendu et normal. Un SubState defailedsignifierait que quelque chose s'est vraiment mal passé. VérifierSubStatedirectement est ce qui vous permet de faire la différence.

Vérifier SubState avec un script

Use systemctl showpour lire le SubState de n'importe quelle unité :

systemctl show -p SubState --value <unit_name>

Cela retourne une seule chaîne — running, exited, dead , failed, etc. — que vous pouvez évaluer dans un moniteur de script.

🖥️ REMARQUE SUR LA PLATE-FORME :

Linux : Supporté sur toute distribution utilisant systemd.
Windows / macOS : Not applicable. systemctl is Linux-only.

Exemple : Surveillance d'une interface WireGuard

Le script ci-dessous vérifie siwg-quick@wg0 est dans le exitedSubState attendu. Remplacez le nom d'unité réel si c'est différent.

#!/bin/bash

UNIT_NAME="wg-quick@wg0"
STATUS=$(systemctl show -p SubState --value $UNIT_NAME)

if [ "$STATUS" = "exited" ]; then
    echo "Service is running correctly."
    exit 0
else
    echo "ALERT: Service is not running. SubState: $STATUS"
    exit 1
fi

Le script affiche une chaîne d'état lisible et se termine avec le code 0 (sain) ou 1 (état inattendu). Configurez le moniteur de script pour déclencher quand la sortie Contains la chaîne d'erreur « ALERT ».

Configuration du moniteur :

Field	Value
Type	Run script
OS	Linux
Script	Linux - Vérification SubState WireGuard
Script output	Contains
Value	`ALERT`
Run frequency	5 minutes
Trigger count	2

💡 CONSEIL : Set Trigger count à 2 ou plus pour éviter les alertes des états transitoires lors des redémarrages ou reboots de service.

Autres types d'unité qui s'arrêtent par conception

wg-quick est le cas le plus courant, mais n'importe lequel de ceux-ci peut déclencher le même motif de fausse alerte :

Services oneshot — exécutent une tâche et s'arrêtent ;SubState will be exited when healthy
Timer units— s'exécute selon un horaire ; vérifiezActiveState pour l'unité timer elle-même, pas le service qu'elle lance
Services Type=forking— le processus parent s'arrête après avoir généré un enfant ; SubState peut être exited pendant que l'enfant s'exécute

Pour tous ces cas, un moniteur de script vérifiantSubStatepar rapport à votre valeur connue comme bonne est la bonne approche.

FAQ

Mon service WireGuard s'affiche comme Down dans Level mais le trafic est routé correctement. Que se passe-t-il ? wg-quick s'arrête après avoir configuré l'interface VPN — c'est normal. L'interface réseau reste active même si le processus de service s'est arrêté. Un moniteur de service voit inactiveet déclenche une alerte. Utilisez un moniteur de script qui vérifieSubState (which returns exited , la valeur saine) à la place.
Comment savoir quelle valeur SubState attendre quand un service est sain ? Run systemctl show -p SubState --value <unit_name> sur un appareil où le service fonctionne correctement. Quelle que soit la valeur retournée, c'est votre ligne de base saine. Script contre cette valeur.
Puis-je vérifier à la fois ActiveState et SubState dans le même moniteur ?Oui. Écrivez le script pour lire les deux et échouez si l'un d'eux est inattendu. Cela vous donne une couverture plus large — vous pouvez attraper les services qui se sont arrêtés de manière inattendue (SubState: failed) séparément des services qui sont simplement arrêtés (ActiveState: inactive ).
Cela fonctionne-t-il sur les distributions Linux qui n'utilisent pas systemd ? No. systemctl nécessite systemd. Sur les distributions utilisant SysVinit ou Upstart, vous auriez besoin d'outils différents (par exemple, service <name> status ). La plupart des distributions Linux activement maintenues sont livrées avec systemd.

Surveillance des fichiers d'unité systemd sur Linux

Introduction

Pourquoi les moniteurs de service déclenchent des fausses alertes

Vérifier SubState avec un script

Exemple : Surveillance d'une interface WireGuard

Autres types d'unité qui s'arrêtent par conception

FAQ