Conteneurs et état du système
    Mis à jour le juin 2026
    Supervisor logo

    Supervisor Suivi

    Surveillez en temps réel tous les processus gérés par Supervisor : état (`RUNNING`/`FATAL`), durée de fonctionnement, arrêts inattendus, boucles de redémarrage et codes de sortie. Solution basée sur un agent via `supervisorctl`, avec une alerte dès qu’un processus passe à l’état `FATAL`.

    Commencer l'essai gratuitConsulter les documents

    Pourquoi surveiller ? Supervisor?

    Supervisor (`supervisord`) maintient vos processus en arrière-plan actifs : les workers Celery et Sidekiq, les serveurs d’applications Gunicorn et uWSGI, les consommateurs de files d’attente et les démons à exécution longue. Mais après `startretries` tentatives de redémarrage infructueuses, il abandonne et place le processus dans l’état `FATAL`, où il reste inactif sans avertissement. La surveillance par processus fait toute la différence entre une alerte en une ligne et une file d’attente saturée que personne n’a remarquée pendant des heures.

    Détection automatique via Xitogent — tous les programmes et groupes de processus gérés par `supervisord` sont détectés automatiquement
    Suivi de l'état de chaque processus sur l'ensemble de la machine à états (`RUNNING`, `STARTING`, `BACKOFF`, `EXITED`, `FATAL`, `STOPPED`, `UNKNOWN`)
    Détection `FATAL` — déclenche une alerte lorsque le superviseur abandonne un processus après avoir épuisé le nombre de tentatives `startretries`
    Boucle de redémarrage / Détection `BACKOFF` pour repérer les workers instables qui n'atteignent jamais un état `RUNNING` stable
    Temps de fonctionnement par processus et suivi des PID (« start since ») pour détecter les redémarrages silencieux et les processus de courte durée
    Détection du dernier code de sortie, comparée aux valeurs définies dans la variable `exitcodes` du programme
    Nombre de processus en cours d'exécution vs nombre de processus configurés — sachez immédiatement quand des processus de travail manquent
    Fonctionne conjointement avec `numprocs`, les groupes de processus et le démarrage classé par `priority`
    Seuils et niveaux de gravité des alertes personnalisables pour chaque processus
    Collecte basée sur des agents — aucune interface HTTP/XML-RPC à exposer ou à sécuriser
    Qu'est-ce que la surveillance par un superviseur ?

    Suivi par le responsable, expliqué

    La surveillance par Supervisor consiste à suivre en permanence l'état de chaque programme géré par supervisord, ainsi qu'à déclencher une alerte lorsqu'un processus quitte l'état RUNNING. Supervisor est très efficace pour redémarrer un processus qui plante — mais uniquement startretries fois au cours de startsecs. Une fois cette limite dépassée, le processus passe à l’état FATAL et Supervisor cesse toute tentative de redémarrage. Rien d’autre ne s’en rend compte : l’hôte est opérationnel, le démon est opérationnel, mais la file d’attente cesse simplement de se vider. Xitoring lit la table des processus en temps réel via supervisorctl, suit chaque programme indépendamment et envoie une alerte à votre équipe de permanence dès qu’un worker passe à l’état FATAL, entre dans une boucle BACKOFF ou se termine avec un code de sortie inattendu.

    Indicateurs

    Ce que nous surveillons

    État du processus

    L'état actuel de chaque programme (`RUNNING`, `STARTING`, `BACKOFF`, `EXITED`, `FATAL`, `STOPPED`, `STOPPING`, `UNKNOWN`). Le signal le plus important du superviseur : tout état autre que `RUNNING` pour un worker s'exécutant depuis longtemps constitue un problème.

    État FATAL

    Un processus qui a dépassé la limite `startretries` et qui a été interrompu par Supervisor. Il ne redémarrera pas de lui-même. Tout programme se trouvant dans `FATAL` génère un signal grave, justifiant la création d'une page.

    BACKOFF / Redémarrer la boucle

    Un processus qui s'arrête sans cesse avant `startsecs` et qui fait l'objet d'une nouvelle tentative. Un `BACKOFF` prolongé signifie qu'un worker instable consomme des ressources CPU lors des redémarrages et ne traite jamais le trafic.

    Temps de fonctionnement (depuis le démarrage)

    Depuis combien de temps chaque processus détient son PID actuel. Un worker dont le temps de fonctionnement est constamment réinitialisé est en boucle de plantage silencieuse, même s’il affiche brièvement « RUNNING » entre deux redémarrages.

    PID du processus

    La valeur PID en temps réel par programme, telle qu'indiquée par la commande `supervisorctl status`. Sa présence confirme que le processus est bel et bien en cours d'exécution, et pas seulement configuré.

    Code de la dernière sortie

    Le code de sortie de la dernière exécution. Comparez-le aux `exitcodes` du programme pour distinguer un arrêt normal d'un plantage inattendu.

    En cours d'exécution ou configuré

    Nombre de processus effectivement en état `RUNNING` par rapport au nombre déclaré (y compris `numprocs`). Permet de repérer d'un seul coup d'œil les travailleurs manquants dans un groupe.

    Départs inattendus

    Génère une sortie avec un code ne figurant pas dans `exitcodes` lorsque `autorestart=unexpected`. Il s'agit de plantages qui n'auraient jamais dû se produire ; une augmentation de leur nombre indique une régression.

    Nombre de redémarrages

    Nombre de redémarrages de chaque processus au fil du temps. Un redémarrage fréquent d’un processus censé fonctionner en continu constitue un signe avant-coureur d’instabilité ou d’une fuite de mémoire.

    Processus arrêtés

    Programmes dont le statut est « `STOPPED` » ou « `EXITED` » et qui devraient être en cours d'exécution. Détecte un processus qu'un utilisateur a arrêté manuellement et qu'il a oublié, ou un processus qui s'est arrêté sans se redémarrer automatiquement.

    Déclencheurs et alertes

    Configurables déclencheurs d'alerte

    Configurez des déclencheurs personnalisés dans votre tableau de bord pour être averti dès que les indicateurs d{name}s dépassent les seuils que vous avez définis.

    Supervisor tableau de bord de configuration des déclencheurs de surveillance

    Processus FATAL

    crucial

    Se déclenche lorsqu'un processus passe à l'état `FATAL` — le superviseur a renoncé à le redémarrer et celui-ci reste inactif jusqu'à ce que quelqu'un intervienne.

    Le processus ne s'exécute pas

    crucial

    Se déclenche lorsqu'un programme qui devrait être en état `RUNNING` est en état `STOPPED`, `EXITED` ou `UNKNOWN`.

    Redémarrer la boucle

    avertissement

    Alertes en cas de `BACKOFF` prolongé ou de redémarrages répétés — un worker qui plante sans cesse et ne parvient jamais à se stabiliser.

    Code de sortie inattendu

    avertissement

    Se déclenche lorsqu'un processus se termine avec un code ne figurant pas parmi les `exitcodes` configurés.

    01

    Importance de Suivi par le responsable

    Le superviseur relancera un processus qui plante — jusqu'à ce qu'il n'y parvienne plus. Une fois le nombre de tentatives `startretries` atteint, le processus est mis en attente dans l'état `FATAL` et reste inactif, sans qu'aucun message ne s'affiche sur l'hôte pour vous en informer.

    • Intercepter les processus qui rencontrent une erreur `FATAL` et empêcher leur redémarrage
    • Détecter les processus bloqués dans des boucles « BACKOFF »
    • Détecter les redémarrages silencieux en réinitialisant la durée de fonctionnement
    • Savoir quand les employés quittent leur poste avec des codes inattendus
    Tableau de bord de l'état des processus du superviseur
    Analyse du redémarrage des processus et de la disponibilité
    02

    Pourquoi choisir Xitoring

    Surveillance de « Supervisor » basée sur des agents, avec une configuration automatique et une visibilité au niveau de chaque processus pour tous les programmes gérés par « supervisord ».

    • Installation et intégration en une seule commande
    • Suivi par processus et par groupe
    • Aucune interface XML-RPC ou HTTP à exposer
    • Alertes multicanaux pour votre planning de permanence
    • État historique et historique des redémarrages
    Présentation de Xitoring Supervisor
    Configuration des alertes par processus
    Cas d'utilisation

    Surveillance par le superviseur commun scénarios

    Où Supervisor s'exécute généralement — et ce qui échoue en silence quand personne ne regarde.

    Tâches en arrière-plan (Celery, Sidekiq, RQ, Resque)

    Les workers de file d’attente sont précisément ces processus qui s’arrêtent sans crier gare : un déploiement raté ou un message corrompu les plonge dans une boucle de redémarrage, puis provoque une erreur FATAL. Nous envoyons une alerte dès qu’un worker cesse de fonctionner, avant que la file d’attente ne s’engorge et que les tâches ne commencent à expirer.

    Serveurs d'applications et démons (Gunicorn, uWSGI, Daphne, Node)

    Lorsque Supervisor gère votre serveur d'applications, un processus qui ne démarre pas après un déploiement signifie que le site est hors service alors que l'hôte est toujours en état « vert ». Nous détectons instantanément les codes FATAL et BACKOFF, ce qui permet d'alerter immédiatement un responsable en cas d'échec de déploiement, plutôt que d'attendre qu'un client signale le problème.

    Processus dans des conteneurs et sur des hôtes existants

    De nombreux conteneurs et serveurs plus anciens utilisent Supervisor à la place de systemd pour maintenir plusieurs processus actifs au même endroit. Nous surveillons chacun d'entre eux de manière indépendante, afin qu'un processus qui plante dans un conteneur très sollicité ne passe pas inaperçu parmi les autres.

    Avant de commencer

    Prérequis pour Supervisor

    Assurez-vous d'avoir tout cela en place — la plupart des installations sont une affaire de 60 secondes une fois ces conditions réunies.

    • Un serveur Linux sur lequel Supervisor (supervisord) est installé et qui gère au moins un programme
    • Xitogent est installé sur le même hôte et permet d'exécuter la commande supervisorctl status
    • Accédez à la commande sudo xitogent integrate et sélectionnez l'intégration « Supervisor ».
    Guide d'installation

    Commencez par procès-verbal

    1

    Installez Xitogent sur votre serveur

    Installez l'agent de surveillance léger Xitogent sur l'hôte exécutant Supervisor.

    curl -s https://xitoring.com/install.sh | sudo bash -s -- --key=YOUR_API_KEY
    2

    Activer l'intégration de Supervisor

    Exécutez la commande `sudo xitogent integrate` et sélectionnez « Supervisor ». Xitogent crée le fichier `/etc/xitogent/integrations/supervisor_integration.conf`, lit la table des processus via `supervisorctl` et détecte automatiquement tous les programmes et groupes gérés par `supervisord` — aucune modification de la configuration de Supervisor n'est nécessaire.

    sudo xitogent integrate
    3

    Configurer les déclencheurs (facultatif)

    Définissez des déclencheurs et des niveaux de gravité par processus dans le tableau de bord Xitoring — par exemple, envoyez une alerte par page dès qu’un processus passe à l’état `FATAL`, et un avertissement en cas de `BACKOFF` prolongé ou de code de sortie inattendu — afin que les défaillances soient signalées à la personne de garde avant que la file d’attente ne s’engorge.

    4

    Vérifier que tout fonctionne

    Exécutez cette commande sur le serveur pour confirmer que Xitogent a bien détecté l'intégration. De nouvelles métriques apparaîtront sur votre tableau de bord dans environ 30 secondes.

    sudo xitogent status
    Comparer

    Vous envisagez des alternatives ?

    Découvrez comment Xitoring se positionne face aux alternatives pour la surveillance de Supervisor — tarifs forfaitaires, intégrations plus poussées et un seul agent pour couvrir tout votre stack.

    Voir toutes les comparaisons

    Souvent a posé des questions

    Qu'est-ce que la surveillance par un superviseur ?
    La surveillance par Supervisor consiste à suivre en continu l'état de chaque programme géré par `supervisord` — `RUNNING`, `STARTING`, `BACKOFF`, `EXITED`, `FATAL`, `STOPPED`, `UNKNOWN` — ainsi que la durée de fonctionnement de chaque processus, son PID, son code de sortie et l’historique de ses redémarrages, ainsi que le déclenchement d’une alerte lorsqu’un processus quitte l’état `RUNNING`. Étant donné que Supervisor cesse de redémarrer un processus après `startretries` et le place dans l’état `FATAL`, la surveillance est le seul moyen de savoir qu’un worker géré a cessé de fonctionner.
    Comment Xitoring collecte-t-il les données relatives aux superviseurs ?
    Côté agent. Xitogent exécute la commande `supervisorctl status` à intervalles réguliers et analyse l'état de chaque programme, son PID et sa durée de fonctionnement. Il n'est pas nécessaire d'activer le service `inet_http_server` de Supervisor ni d'exposer son interface XML-RPC : l'agent lit localement les mêmes données que l'interface en ligne de commande.
    Comment configurer l'intégration de Supervisor ?
    Installez Xitogent (`curl -s https://xitoring.com/install.sh | sudo bash -s -- --key=VOTRE_CLÉ_API`), puis exécutez `sudo xitogent integrate` et sélectionnez « Supervisor ». Xitogent crée le fichier `/etc/xitogent/integrations/supervisor_integration.conf`, détecte automatiquement tous les programmes et groupes gérés par `supervisord`, puis commence à les surveiller. Aucune modification de la configuration de votre Supervisor n'est nécessaire.
    Que signifient les états du processus « Supervisor » ?
    `STOPPED` — pas encore démarré. `STARTING` — démarré, en attente de `startsecs` pour être considéré comme `RUNNING`. `RUNNING` — opérationnel et stable. `BACKOFF` — démarré mais s'est arrêté avant `startsecs` ; le superviseur tente à nouveau le démarrage. `EXITED` — s’est exécuté puis s’est arrêté (de manière attendue ou inattendue, selon `exitcodes`). `FATAL` — a dépassé `startretries` ; le superviseur a abandonné et ne le redémarrera pas. `STOPPING` — en cours d’arrêt. `UNKNOWN` — le superviseur a perdu la trace du processus. Pour les workers s’exécutant sur une longue durée, tout état autre que `RUNNING` mérite une attention particulière.
    Que signifie l'état « FATAL » et pourquoi est-ce important ?
    Un processus passe à l'état « FATAL » lorsqu'il n'a pas réussi à rester opérationnel plus de « startretries » fois au cours de « startsecs ». À ce stade, Supervisor cesse toute tentative et le laisse inactif. Aucun élément de l’hôte ne le rétablit automatiquement : le serveur est opérationnel, le démon `supervisord` est opérationnel, mais votre worker a disparu. `FATAL` est l’alerte la plus importante de Supervisor : elle signifie presque toujours qu’un déploiement a échoué, qu’une dépendance est manquante ou que le processus plante au démarrage.
    Comment détecter une boucle de redémarrage du superviseur ?
    Surveillez l'état `BACKOFF` et la réinitialisation de la durée de fonctionnement. Un processus instable passe de manière répétée de `STARTING` → s'arrête avant `startsecs` → `BACKOFF` → nouvelle tentative, sans jamais atteindre un état stable `RUNNING`. Xitoring signale à la fois un état `BACKOFF` prolongé et un processus dont la durée de fonctionnement est sans cesse réinitialisée, ce qui vous permet de détecter la boucle tant qu’elle sollicite encore le processeur, plutôt qu’une fois qu’elle a abouti à l’état `FATAL`. La solution consiste généralement à augmenter les valeurs `startsecs`/`startretries` uniquement après avoir corrigé la cause de l’arrêt prématuré du processus.
    Quelle est la différence entre « autorestart true », « false » et « unexpected » ?
    `autorestart=true` redémarre toujours le processus lorsqu'il se termine. `autorestart=false` ne le fait jamais. `autorestart=unexpected` (une valeur par défaut courante) ne redémarre que lorsque le code de sortie ne figure pas dans la liste `exitcodes` du programme — c'est-à-dire qu'il considère un code figurant dans cette liste comme un arrêt normal et tout autre code comme un plantage. Xitoring compare le dernier code de sortie à la liste `exitcodes`, ce qui vous permet de déclencher des alertes spécifiquement en cas de sorties inattendues, plutôt que pour chaque arrêt intentionnel.
    Puis-je surveiller plusieurs processus et groupes de processus ?
    Oui. Xitogent détecte automatiquement tous les programmes gérés par `supervisord`, y compris les processus regroupés et les programmes pour lesquels `numprocs > 1` (par exemple, `worker:worker_00`, `worker:worker_01`). Chaque processus est suivi, fait l'objet d'alertes et enregistré dans l'historique de manière indépendante ; ainsi, un seul worker en panne au sein d'un groupe très sollicité n'est jamais masqué par ceux qui continuent de fonctionner.
    Supervisor ou systemd ? — Pourquoi surveiller spécifiquement Supervisor ?
    De nombreuses piles s'appuient encore sur Supervisor : des conteneurs Docker exécutant plusieurs processus, des hôtes hérités antérieurs à l'utilisation généralisée de systemd, et des applications Python/Ruby dont les outils de déploiement s'étaient standardisés autour de ce dernier. Le comportement de redémarrage de Supervisor diffère également de celui de systemd : il abandonne un processus en le marquant comme `FATAL` après `startretries` au lieu de reculer indéfiniment. La surveillance directe de la machine à états de Supervisor permet de détecter ces processus abandonnés, quel que soit le reste des processus en cours d’exécution sur l’hôte.

    Commencer à surveiller Supervisor aujourd'hui

    Configuration en moins de 60 secondes. Aucune carte bancaire requise. Statistiques complètes dès le premier jour.

    Commencer l'essai gratuit

    Continuez à explorer

    Connexes Intégrations