Contenedores y estado del sistema
    Actualizado Junio de 2026
    Supervisor logo

    Supervisor Seguimiento

    Supervisa en tiempo real todos los procesos gestionados por Supervisor: estado (`RUNNING`/`FATAL`), tiempo de actividad, salidas inesperadas, bucles de reinicio y códigos de salida. Funciona mediante un agente a través de `supervisorctl`, con una alerta en el momento en que un proceso pasa a estado `FATAL`.

    Empieza tu prueba gratuitaVer documentos

    ¿Por qué realizar un seguimiento? Supervisor?

    El supervisor (`supervisord`) mantiene activos tus procesos en segundo plano: los trabajadores de Celery y Sidekiq, los servidores de aplicaciones Gunicorn y uWSGI, los consumidores de colas y los demonios de larga duración. Sin embargo, tras `startretries` intentos fallidos de reinicio, se da por vencido y envía el proceso a `FATAL`, donde permanece inactivo sin avisar. La supervisión por proceso marca la diferencia entre una alerta de una sola línea y una cola atascada que nadie ha detectado durante horas.

    Detección automática mediante Xitogent: todos los programas y grupos de procesos bajo `supervisord` se detectan automáticamente
    Seguimiento del estado de cada proceso a lo largo de toda la máquina de estados (`RUNNING`, `STARTING`, `BACKOFF`, `EXITED`, `FATAL`, `STOPPED`, `UNKNOWN`)
    Detección `FATAL`: avisa cuando el Supervisor abandona un proceso tras agotar `startretries`.
    Bucle de reinicio / Detección de `BACKOFF` para detectar procesos en estado inestable que nunca alcanzan un estado `RUNNING` estable
    Tiempo de actividad por proceso y seguimiento del PID («start since») para detectar reinicios silenciosos y procesos de corta duración
    Comprobación del último código de salida, comparado con los `exitcodes` configurados en el programa
    Número de procesos en ejecución frente al número de procesos configurados: averigua al instante si faltan trabajadores
    Funciona junto con `numprocs`, los grupos de procesos y el inicio ordenado por `priority`.
    Umbrales y niveles de gravedad de las alertas personalizables para cada proceso
    Recopilación basada en agentes: no hay que exponer ni proteger ninguna interfaz HTTP/XML-RPC
    ¿En qué consiste la supervisión por parte del supervisor?

    Supervisión por parte del supervisor, explicado

    La supervisión de Supervisor consiste en el seguimiento continuo del estado de todos los programas que gestiona supervisord, además de enviar alertas cuando un proceso deja de estar en estado RUNNING. Supervisor es excelente a la hora de reiniciar un proceso que se bloquea, pero solo startretries veces en un plazo de startsecs. Si se supera ese límite, el proceso pasa al estado «FATAL» y Supervisor deja de intentarlo. Nada más lo detecta: el servidor está activo, el demonio está activo, pero la cola simplemente deja de vaciarse. Xitoring lee la tabla de procesos en tiempo real a través de supervisorctl, realiza un seguimiento independiente de cada programa y envía una alerta a tu turno de guardia en el instante en que un proceso pasa al estado FATAL, entra en un bucle BACKOFF o se cierra con un código de salida inesperado.

    Métricas

    Lo que monitorizamos

    Estado del proceso

    El estado actual de cada programa (`RUNNING`, `STARTING`, `BACKOFF`, `EXITED`, `FATAL`, `STOPPED`, `STOPPING`, `UNKNOWN`). La señal más importante del Supervisor: cualquier estado distinto de `RUNNING` en un trabajador de ejecución prolongada supone un problema.

    Estado FATAL

    Un proceso que ha superado el límite de `startretries` y ha sido abandonado por Supervisor. No se reiniciará por sí solo. Cualquier programa en `FATAL` es una señal grave que merece aparecer en la página.

    BACKOFF / Reiniciar bucle

    Un proceso que se cuelga constantemente antes de `startsecs` y se está reintentando. Un `BACKOFF` prolongado significa que un worker inestable consume recursos de la CPU al reiniciarse y nunca atiende el tráfico.

    Tiempo de actividad (desde el inicio)

    El tiempo que cada proceso lleva manteniendo su PID actual. Un trabajador cuyo tiempo de actividad se reinicia constantemente está entrando en un bucle de fallos silencioso, aunque muestre brevemente el estado `RUNNING` entre reinicios.

    PID del proceso

    El PID en tiempo real de cada programa, según `supervisorctl status`. Su presencia confirma que el proceso se está ejecutando realmente, y no solo que está configurado.

    Código de última salida

    El código de salida de la última ejecución. Compáralo con los `códigos de salida` del programa para distinguir entre un cierre normal y un fallo inesperado.

    En ejecución frente a configurado

    Recuento de los procesos que se encuentran realmente en estado `RUNNING` en comparación con el número declarado (incluido `numprocs`). Permite detectar de un vistazo la falta de trabajadores en un grupo.

    Salidas inesperadas

    Se cierra con un código que no figura en `exitcodes` cuando `autorestart=unexpected`. Se trata de fallos que nunca deberían haber ocurrido; si se observa una tendencia al alza, esto apunta a una regresión.

    Recuento de reinicios

    La frecuencia con la que se ha reiniciado cada proceso a lo largo del tiempo. Un reinicio constante de un proceso que debería ejecutarse de forma continua es una señal de alerta temprana de inestabilidad o de una fuga de memoria.

    Procesos detenidos

    Programas en estado «STOPPED» o «EXITED» que deberían estar en ejecución. Detecta un proceso que alguien ha detenido manualmente y se ha olvidado de ello, o uno que se ha cerrado sin reiniciarse automáticamente.

    Desencadenantes y alertas

    Configurables condiciones de activación de alertas

    Configura alertas personalizadas en tu panel de control para recibir una notificación en cuanto las métricas de «Supervisor» superen los umbrales que hayas definido.

    Supervisor panel de control de la configuración de los desencadenantes de supervisión

    Proceso FATAL

    crítico

    Se activa cuando un proceso entra en estado `FATAL`: el supervisor ha dejado de intentar reiniciarlo y permanece inactivo hasta que alguien intervenga.

    El proceso no se está ejecutando

    crítico

    Se activa cuando un programa que debería estar en estado `RUNNING` se encuentra en estado `STOPPED`, `EXITED` o `UNKNOWN`.

    Reiniciar bucle

    advertencia

    Alertas por un `BACKOFF` prolongado o reinicios repetidos: un trabajador que se cuelga constantemente y nunca se estabiliza.

    Código de salida inesperado

    advertencia

    Se activa cuando un proceso finaliza con un código que no figura entre los `exitcodes` configurados.

    01

    Importancia de Supervisión de los supervisores

    El supervisor reiniciará un proceso que se ha bloqueado… hasta que ya no pueda hacerlo. Tras `startretries`, el proceso queda en estado `FATAL` y permanece inactivo, sin que el servidor te avise de nada.

    • Detectar los procesos que dan error `FATAL` y evitar que se reinicien
    • Detectar a los trabajadores que se atascan en bucles «BACKOFF»
    • Detecta los reinicios silenciosos mediante el restablecimiento del tiempo de actividad
    • Saber cuándo los trabajadores salen con códigos inesperados
    Cuadro de mando del estado de los procesos del supervisor
    Análisis del reinicio de procesos y del tiempo de actividad
    02

    ¿Por qué elegir? Xitoring

    Supervisión basada en agentes con configuración automática y visibilidad por proceso en todos los programas que gestiona «supervisord».

    • Instalación e integración con un solo comando
    • Seguimiento por proceso y por grupo
    • No hay ninguna interfaz XML-RPC ni HTTP que exponer
    • Alertas multicanal para tu turno de guardia
    • Estado histórico e historial de reinicios
    Descripción general de Xitoring Supervisor
    Configuración de alertas por proceso
    Casos de uso

    Supervisión común por parte del supervisor escenarios

    Dónde suele ejecutarse Supervisor… y qué falla de forma silenciosa cuando nadie está mirando.

    Procesos en segundo plano (Celery, Sidekiq, RQ, Resque)

    Los trabajadores de cola son precisamente esos procesos que se cierran sin avisar: una implementación defectuosa o un mensaje erróneo los sumerge en un bucle de reinicio y, a continuación, se produce un error FATAL. Enviamos una alerta en el momento en que un trabajador deja de funcionar, antes de que se produzca un atasco en la cola y los trabajos empiecen a agotar el tiempo de espera.

    Servidores de aplicaciones y demonios (Gunicorn, uWSGI, Daphne, Node)

    Cuando Supervisor gestiona tu servidor de aplicaciones, si un proceso no se inicia tras una implementación, significa que el sitio está inactivo aunque el estado del servidor siga siendo «verde». Detectamos los errores FATAL y BACKOFF al instante, de modo que, si una implementación falla, se avisa a alguien de inmediato en lugar de esperar a que un cliente lo comunique.

    Procesos en contenedores y en servidores heredados

    Muchos contenedores y servidores antiguos utilizan Supervisor en lugar de systemd para mantener activos varios procesos en un mismo lugar. Realizamos un seguimiento de cada uno de ellos de forma independiente, de modo que un único proceso que se haya bloqueado en un contenedor muy activo no pase desapercibido entre los demás.

    Antes de empezar

    Requisitos previos para Supervisor

    Asegúrate de tener todo esto en su sitio — la mayoría de las instalaciones tardan 60 segundos una vez listo.

    • Un servidor Linux con Supervisor (supervisord) instalado y que gestione al menos un programa
    • Xitogent instalado en el mismo servidor, capaz de ejecutar supervisorctl status
    • Accede para ejecutar sudo xitogent integrate y selecciona la integración de Supervisor
    Guía de configuración

    Empieza con minutos

    1

    Instala Xitogent en tu servidor

    Instala el agente de supervisión ligero de Xitogent en el host en el que se ejecuta Supervisor.

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

    Activar la integración con Supervisor

    Ejecuta `sudo xitogent integrate` y selecciona Supervisor. Xitogent crea el archivo `/etc/xitogent/integrations/supervisor_integration.conf`, lee la tabla de procesos a través de `supervisorctl` y detecta automáticamente todos los programas y grupos bajo `supervisord`, sin que sea necesario realizar ningún cambio en la configuración de Supervisor.

    sudo xitogent integrate
    3

    Configurar disparadores (opcional)

    Configura los desencadenantes y los niveles de gravedad por proceso en el panel de control de Xitoring —por ejemplo, envía una notificación cuando cualquier proceso entre en el estado `FATAL` y avisa en caso de un estado `BACKOFF` prolongado o un código de salida inesperado— para que los fallos lleguen al personal de guardia antes de que se acumulen en la cola.

    4

    Verifica que funciona

    Ejecuta este comando en el servidor para confirmar que Xitogent ha detectado la integración. En unos 30 segundos comenzarán a llegar métricas nuevas a tu panel.

    sudo xitogent status
    Comparar

    ¿Estás considerando alternativas?

    Mira cómo se compara Xitoring frente a las alternativas para la supervisión de Supervisor: precios planos, integraciones más profundas y un solo agente que cubre todo tu stack.

    Ver todas las comparaciones

    Con frecuencia preguntas formuladas

    ¿En qué consiste la supervisión por parte del supervisor?
    La supervisión de Supervisor consiste en el seguimiento continuo del estado de cada programa gestionado por `supervisord` —`RUNNING`, `STARTING`, `BACKOFF`, `EXITED`, `FATAL`, `STOPPED`, `UNKNOWN`— junto con el tiempo de actividad de cada proceso, el PID, el código de salida y el historial de reinicios de cada proceso, además de avisar cuando un proceso deja de estar en estado `RUNNING`. Dado que Supervisor deja de reiniciar un proceso tras `startretries` y lo coloca en estado `FATAL`, la supervisión es lo único que te indica que un trabajador gestionado ha dejado de funcionar.
    ¿Cómo recopila Xitoring los datos de los supervisores?
    Del lado del agente. Xitogent ejecuta `supervisorctl status` a intervalos cortos y analiza el estado, el PID y el tiempo de actividad de cada programa. No es necesario habilitar el `inet_http_server` de Supervisor ni exponer su interfaz XML-RPC: el agente lee los mismos datos que la CLI, de forma local.
    ¿Cómo configuro la integración con Supervisor?
    Instala Xitogent (`curl -s https://xitoring.com/install.sh | sudo bash -s -- --key=TU_CLAVE_API`), a continuación ejecuta `sudo xitogent integrate` y selecciona Supervisor. Xitogent crea el archivo `/etc/xitogent/integrations/supervisor_integration.conf`, detecta automáticamente todos los programas y grupos que gestiona `supervisord` y comienza a realizar un seguimiento de ellos. No es necesario realizar ningún cambio en la configuración de Supervisor.
    ¿Qué significan los estados del proceso «Supervisor»?
    `STOPPED`: no se ha iniciado. `STARTING`: se ha iniciado; está a la espera de `startsecs` para pasar al estado `RUNNING`. `RUNNING`: en funcionamiento y estable. `BACKOFF`: se ha iniciado, pero se ha detenido antes de `startsecs`; el supervisor está volviendo a intentarlo. `EXITED`: se ha ejecutado y ha finalizado (de forma esperada o inesperada, según `exitcodes`). `FATAL`: se ha superado el límite de `startretries`; el Supervisor ha desistido y no lo reiniciará. `STOPPING`: se está cerrando. `UNKNOWN`: el Supervisor ha perdido el rastro del proceso. En el caso de los trabajadores de larga duración, cualquier estado que no sea `RUNNING` merece atención.
    ¿Qué significa el estado «FATAL» y por qué es importante?
    Un proceso pasa a estado `FATAL` cuando no ha conseguido mantenerse en funcionamiento más de `startretries` veces en un plazo de `startsecs`. En ese momento, Supervisor deja de intentarlo y lo da por inactivo. Nada en el servidor lo recupera automáticamente: el servidor está en funcionamiento, el demonio `supervisord` está en funcionamiento, pero tu proceso de trabajo ha desaparecido. `FATAL` es la alerta más importante de Supervisor: casi siempre significa que una implementación ha fallado, que falta una dependencia o que el proceso se bloquea al iniciarse.
    ¿Cómo puedo detectar un bucle de reinicio del Supervisor?
    Vigila el estado `BACKOFF` y el reinicio del tiempo de actividad. Un proceso inestable entra repetidamente en `STARTING` → se detiene antes de `startsecs` → `BACKOFF` → reintento, sin llegar nunca a un estado estable `RUNNING`. Xitoring detecta tanto un estado «BACKOFF» prolongado como un proceso cuyo tiempo de actividad se reinicia constantemente, lo que permite detectar el bucle mientras está consumiendo recursos de la CPU, en lugar de hacerlo después de que el proceso entre en estado «FATAL». La solución suele consistir en aumentar los valores de «startsecs» y «startretries» solo después de haber solucionado la causa por la que el proceso se cierra prematuramente.
    ¿Cuál es la diferencia entre «autorestart true», «false» y «unexpected»?
    `autorestart=true` reinicia siempre el proceso cuando este finaliza. `autorestart=false` nunca lo hace. `autorestart=unexpected` (un valor predeterminado habitual) solo reinicia cuando el código de salida no figura en la lista `exitcodes` del programa; es decir, considera que un código incluido en la lista supone un cierre correcto y cualquier otro, un fallo. Xitoring compara el último código de salida con `exitcodes` para que puedas recibir alertas específicas sobre salidas inesperadas, en lugar de sobre cada parada intencionada.
    ¿Puedo supervisar varios procesos y grupos de procesos?
    Sí. Xitogent detecta automáticamente todos los programas que gestiona `supervisord`, incluidos los procesos agrupados y los programas con `numprocs > 1` (por ejemplo, `worker:worker_00`, `worker:worker_01`). Cada proceso se supervisa, se notifica y se registra de forma independiente, por lo que un único trabajador que se haya bloqueado en un grupo muy activo nunca queda oculto tras los que siguen en funcionamiento.
    Supervisor frente a systemd: ¿por qué supervisar específicamente Supervisor?
    Todavía hay muchas pilas que dependen de Supervisor: contenedores de Docker que ejecutan varios procesos, hosts heredados anteriores al uso generalizado de systemd y aplicaciones de Python/Ruby cuyas herramientas de implementación se estandarizaron en torno a él. El comportamiento de reinicio de Supervisor también difiere del de systemd: abandona un proceso con el estado `FATAL` tras `startretries`, en lugar de retrasar el reinicio indefinidamente. La supervisión directa de la máquina de estados de Supervisor permite detectar esos procesos abandonados, independientemente de qué más se esté ejecutando en el host.

    Empieza a seguir a Supervisor hoy

    Se configura en menos de 60 segundos. No se necesita tarjeta de crédito. Estadísticas completas desde el primer día.

    Empieza tu prueba gratuita

    Sigue explorando

    Relacionado Integraciones