Contentores e estado do sistema
    Atualizado Junho de 2026
    Supervisor logo

    Supervisor Monitorização

    Monitorize todos os processos geridos pelo Supervisor — estado (`RUNNING`/`FATAL`), tempo de atividade, encerramentos inesperados, ciclos de reinício e códigos de saída — em tempo real. Funciona com base no agente através do `supervisorctl`, com um alerta assim que um processo passa para o estado `FATAL`.

    Iniciar período de avaliação gratuitaVer documentos

    Por que monitorizar Supervisor?

    O Supervisor (`supervisord`) mantém ativos os seus processos em segundo plano — workers do Celery e do Sidekiq, servidores de aplicações Gunicorn e uWSGI, consumidores de filas e daemons de longa duração. No entanto, após `startretries` tentativas falhadas de reinício, desiste e coloca o processo no estado `FATAL`, onde permanece inativo sem qualquer aviso. A monitorização por processo é a diferença entre um alerta de uma linha e uma fila entupida que ninguém reparou durante horas.

    Detecção automática através do Xitogent — todos os programas e grupos de processos sob o `supervisord` são detetados automaticamente
    Acompanhamento do estado por processo ao longo de toda a máquina de estados (`RUNNING`, `STARTING`, `BACKOFF`, `EXITED`, `FATAL`, `STOPPED`, `UNKNOWN`)
    Detecção `FATAL` — alerta quando o Supervisor abandona um processo após esgotar `startretries`
    Detecção de reinício em loop / `BACKOFF` para identificar workers instáveis que nunca atingem um estado `RUNNING` estável
    Tempo de atividade por processo e acompanhamento do PID («início desde») para detetar reinícios silenciosos e processos de curta duração
    Verificação do último código de saída, comparado com os `exitcodes` configurados no programa
    Número de processos em execução vs. número de processos configurados — saiba imediatamente quando faltam trabalhadores
    Funciona em conjunto com `numprocs`, grupos de processos e o arranque ordenado por `priority`
    Limites e níveis de gravidade de alertas personalizáveis por processo
    Recolha baseada em agentes — não é necessário expor nem proteger nenhuma interface HTTP/XML-RPC
    O que é a monitorização do Supervisor?

    Monitorização por parte do supervisor, explicado

    A monitorização do Supervisor consiste no acompanhamento contínuo do estado de todos os programas geridos pelo supervisord, além de emitir alertas quando um processo sai do estado RUNNING. O Supervisor é excelente a reiniciar um processo que falha — mas apenas startretries vezes dentro de startsecs. Se esse limite for ultrapassado, o processo passa para o estado FATAL e o Supervisor deixa de tentar. Nada mais repara nisso: o anfitrião está ativo, o daemon está ativo, a fila simplesmente deixa de ser esvaziada. Xitoring lê a tabela de processos em tempo real através do supervisorctl, acompanha cada programa de forma independente e envia um alerta para a sua rotação de plantão no instante em que um processo entra no estado FATAL, fica a oscilar num ciclo BACKOFF ou termina com um código de erro inesperado.

    Métricas

    O que monitorizamos

    Estado do processo

    O estado atual de cada programa (`RUNNING`, `STARTING`, `BACKOFF`, `EXITED`, `FATAL`, `STOPPED`, `STOPPING`, `UNKNOWN`). O sinal mais importante do Supervisor — qualquer coisa que não seja `RUNNING` para um trabalhador de execução prolongada constitui um problema.

    Estado FATAL

    Um processo que ultrapassou o limite `startretries` e foi abandonado pelo Supervisor. Não irá reiniciar por si próprio. Qualquer programa em `FATAL` constitui um sinal grave, digno de ser destacado.

    BACKOFF / Reiniciar o ciclo

    Um processo que continua a falhar antes do `startsecs` e está a ser reiniciado. Um `BACKOFF` prolongado significa que um worker instável está a consumir recursos da CPU nas reinicializações e nunca chega a processar o tráfego.

    Tempo de funcionamento (desde o arranque)

    Há quanto tempo cada processo mantém o seu PID atual. Um worker cujo tempo de atividade está constantemente a ser reiniciado está, silenciosamente, a entrar num ciclo de falhas, mesmo que apresente brevemente o estado `RUNNING` entre os reinícios.

    PID do processo

    O PID em tempo real de cada programa, obtido através do comando `supervisorctl status`. A sua presença confirma que o processo está efetivamente a ser executado, e não apenas configurado.

    Código da Última Saída

    O código de saída da execução mais recente. Compare-o com os `códigos de saída` do programa para distinguir um encerramento esperado de uma falha inesperada.

    Em execução vs. Configurado

    Contagem do número de processos efetivamente em `RUNNING` em relação ao número declarado (incluindo `numprocs`). Permite identificar rapidamente a falta de trabalhadores num grupo.

    Saídas inesperadas

    Encerra com um código fora do intervalo `exitcodes` quando `autorestart=unexpected`. Estas são as falhas que nunca deveriam ter ocorrido — uma tendência de aumento aponta para uma regressão.

    Contagem de reinícios

    A frequência com que cada processo foi reiniciado ao longo do tempo. A reinicialização constante de um processo que deveria funcionar de forma contínua constitui um sinal precoce de instabilidade ou de uma fuga de memória.

    Processos interrompidos

    Programas com o estado `STOPPED` ou `EXITED` que deveriam estar a ser executados. Deteta um processo que alguém parou manualmente e se esqueceu, ou que terminou sem reiniciar automaticamente.

    Alerta e notificação

    Configurável condições de alerta

    Configure alertas personalizados no seu painel para ser notificado assim que as métricas dSupervisor ultrapassarem os limites que definiu.

    Supervisor painel de controlo da configuração dos gatilhos de monitorização

    Processo FATAL

    crítico

    É acionado quando um processo entra no estado `FATAL` — o Supervisor desistiu de o reiniciar e o processo fica inativo até que alguém intervenha.

    O processo não está a ser executado

    crítico

    É acionado quando um programa que deveria estar em `RUNNING` está em `STOPPED`, `EXITED` ou `UNKNOWN`.

    Reiniciar o ciclo

    aviso

    Alertas em caso de `BACKOFF` prolongado ou reinícios repetidos — um worker que continua a falhar e nunca se estabiliza.

    Código de saída inesperado

    aviso

    É disparado quando um processo termina com um código que não se encontra entre os `exitcodes` configurados.

    01

    Importância de Monitorização do supervisor

    O Supervisor irá reiniciar um processo que tenha entrado em falha — até que isso deixe de ser possível. Após o `startretries`, o processo fica em estado `FATAL` e permanece inativo, sem que haja qualquer indicação no anfitrião a alertar-te para isso.

    • Detetar processos que atingem o estado `FATAL` e impedir que sejam reiniciados
    • Detetar trabalhadores que ficam presos em loops `BACKOFF`
    • Detetar reinícios silenciosos através da reinicialização do tempo de atividade
    • Saiba quando os trabalhadores saem com códigos inesperados
    Painel de controlo do estado dos processos do supervisor
    Análise do reinício de processos e do tempo de atividade
    02

    Por que escolher Xitoring

    Monitorização do Supervisor baseada em agentes, com configuração automática e visibilidade por processo em todos os programas geridos pelo supervisord.

    • Instalação e integração com um único comando
    • Acompanhamento por processo e por grupo
    • Não há nenhuma interface XML-RPC ou HTTP a disponibilizar
    • Alertas multicanal para a sua escala de plantão
    • Estado histórico e histórico de reinícios
    Visão geral do Xitoring Supervisor
    Configuração de alertas por processo
    Casos de utilização

    Monitorização do Supervisor Comum cenários

    Onde o Supervisor costuma ser executado — e o que falha silenciosamente quando ninguém está a ver.

    Processos em segundo plano (Celery, Sidekiq, RQ, Resque)

    Os trabalhadores da fila são precisamente os processos que terminam silenciosamente — uma implementação mal sucedida ou uma mensagem inválida leva-os a entrar num ciclo de reinício, seguido de FATAL. Emitimos um alerta assim que um trabalhador deixa de funcionar, antes que a fila fique congestionada e as tarefas comecem a atingir o tempo limite.

    Servidores de aplicações e daemons (Gunicorn, uWSGI, Daphne, Node)

    Quando o Supervisor gere o seu servidor de aplicações, um processo que não arranca após uma implementação significa que o site está em baixo, embora o estado do servidor continue a indicar «verde». Detetamos os erros FATAL e BACKOFF instantaneamente, para que, em caso de falha na implementação, seja enviado um aviso a alguém, em vez de ficarmos à espera de uma notificação do cliente.

    Processos em contentores e em hosts antigos

    Muitos contentores e servidores mais antigos utilizam o Supervisor em vez do systemd para manter vários processos ativos num único local. Monitorizamos cada um deles de forma independente, para que um único processo que tenha falhado num contentor com muita atividade não passe despercebido por entre os outros.

    Antes de começar

    Pré-requisitos para Supervisor

    Certifique-se de que tem tudo isto pronto — depois disso, a maioria das instalações leva 60 segundos.

    • Um servidor Linux com o Supervisor (supervisord) instalado e a gerir, pelo menos, um programa
    • O Xitogent está instalado no mesmo anfitrião e é possível executar o comando supervisorctl status
    • Aceda para executar o comando sudo xitogent integrate e selecione a integração com o Supervisor
    Guia de configuração

    Comece a minutos

    1

    Instale o Xitogent no seu servidor

    Instale o agente de monitorização leve da Xitogent no anfitrião onde está a ser executado o Supervisor.

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

    Ativar a integração com o Supervisor

    Execute `sudo xitogent integrate` e selecione o Supervisor. O Xitogent cria o ficheiro `/etc/xitogent/integrations/supervisor_integration.conf`, lê a tabela de processos através do `supervisorctl` e deteta automaticamente todos os programas e grupos sob o `supervisord` — não é necessário alterar a configuração do Supervisor.

    sudo xitogent integrate
    3

    Configurar gatilhos (opcional)

    Defina gatilhos e níveis de gravidade por processo no painel do Xitoring — por exemplo, envie uma notificação sempre que um processo entrar no estado `FATAL` e emita um aviso em caso de estado `BACKOFF` prolongado ou de um código de saída inesperado — para que as falhas cheguem à equipa de plantão antes que a fila fique congestionada.

    4

    Confirme que está a funcionar

    Execute este comando no servidor para confirmar que o Xitogent detetou a integração. Em cerca de 30 segundos começam a chegar novas métricas ao seu painel.

    sudo xitogent status
    Comparar

    Está a considerar alternativas?

    Veja como o Xitoring se compara às alternativas para a monitorização de Supervisor — preços fixos, integrações mais profundas e um único agente que cobre toda a sua stack.

    Ver todas as comparações

    Frequentemente perguntas feitas

    O que é a monitorização do Supervisor?
    A monitorização do Supervisor consiste no acompanhamento contínuo do estado de cada programa gerido pelo `supervisord` — `RUNNING`, `STARTING`, `BACKOFF`, `EXITED`, `FATAL`, `STOPPED`, `UNKNOWN` — juntamente com o tempo de atividade por processo, PID, código de saída e histórico de reinicializações, além de emitir um alerta quando um processo sai do estado `RUNNING`. Como o Supervisor deixa de reiniciar um processo após `startretries` e o coloca no estado `FATAL`, o monitoramento é a única forma de saber que um worker gerido deixou de funcionar.
    Como é que a Xitoring recolhe os dados dos supervisores?
    Do lado do agente. O Xitogent executa o comando `supervisorctl status` a intervalos curtos e analisa o estado, o PID e o tempo de atividade de cada programa. Não é necessário ativar o `inet_http_server` do Supervisor nem expor a sua interface XML-RPC — o agente lê os mesmos dados que a CLI, localmente.
    Como posso configurar a integração com o Supervisor?
    Instale o Xitogent (`curl -s https://xitoring.com/install.sh | sudo bash -s -- --key=YOUR_API_KEY`), depois execute `sudo xitogent integrate` e selecione o Supervisor. O Xitogent cria o ficheiro `/etc/xitogent/integrations/supervisor_integration.conf`, deteta automaticamente todos os programas e grupos geridos pelo `supervisord` e começa a monitorizá-los. Não é necessário efetuar quaisquer alterações na configuração do Supervisor.
    O que significam os estados do processo «Supervisor»?
    `STOPPED` — não foi iniciado. `STARTING` — iniciado, à espera de `startsecs` para ser considerado `RUNNING`. `RUNNING` — em funcionamento e estável. `BACKOFF` — iniciado, mas encerrou antes de `startsecs`; o Supervisor está a tentar novamente. `EXITED` — foi executado e encerrou (de forma esperada ou inesperada, conforme `exitcodes`). `FATAL` — excedeu `startretries`; o Supervisor desistiu e não o irá reiniciar. `STOPPING` — está a ser encerrado. `UNKNOWN` — o Supervisor perdeu o rasto do processo. No caso de trabalhadores de longa duração, qualquer estado que não seja `RUNNING` merece atenção.
    O que significa o estado FATAL e por que é que isso é importante?
    Um processo entra no estado `FATAL` quando não consegue manter-se ativo mais do que `startretries` vezes no espaço de `startsecs`. Nessa altura, o Supervisor deixa de tentar e considera-o inativo. Nada no anfitrião o recupera automaticamente — o servidor está ativo, o daemon `supervisord` está ativo, mas o seu processo de trabalho desapareceu. `FATAL` é o alerta mais importante do Supervisor: significa quase sempre que uma implementação falhou, que falta uma dependência ou que o processo está a falhar ao iniciar.
    Como posso detetar um ciclo de reinício do Supervisor?
    Fique atento ao estado `BACKOFF` e à reinicialização do tempo de atividade. Um processo instável entra repetidamente no estado `STARTING` → termina antes de atingir `startsecs` → `BACKOFF` → nova tentativa, nunca alcançando um estado `RUNNING` estável. O Xitoring deteta tanto o estado `BACKOFF` prolongado como um processo cujo tempo de atividade está constantemente a ser reiniciado, permitindo-lhe detetar o ciclo enquanto este consome recursos da CPU, em vez de só o fazer depois de o processo entrar no estado `FATAL`. A correção consiste, normalmente, em aumentar os valores de `startsecs`/`startretries` apenas depois de resolver a causa pela qual o processo termina prematuramente.
    Qual é a diferença entre «autorestart» «true», «false» e «unexpected»?
    `autorestart=true` reinicia sempre o processo quando este termina. `autorestart=false` nunca o faz. `autorestart=unexpected` (um valor predefinido comum) reinicia apenas quando o código de saída não consta da lista `exitcodes` do programa — ou seja, trata um código listado como um encerramento normal e qualquer outro como uma falha. Xitoring compara o último código de saída com a lista `exitcodes`, para que possa alertar especificamente sobre saídas inesperadas, em vez de alertar sobre todas as paragens intencionais.
    Posso monitorizar vários processos e grupos de processos?
    Sim. O Xitogent deteta automaticamente todos os programas geridos pelo `supervisord`, incluindo processos agrupados e programas com `numprocs > 1` (por exemplo, `worker:worker_00`, `worker:worker_01`). Cada processo é monitorizado, alerteado e registado no histórico de forma independente, pelo que um único worker que tenha falhado num grupo muito ativo nunca fica oculto por trás dos que ainda estão em execução.
    Supervisor vs. systemd — por que monitorizar especificamente o Supervisor?
    Muitas pilhas continuam a depender do Supervisor: contentores Docker que executam vários processos, hosts antigos anteriores à utilização generalizada do systemd e aplicações Python/Ruby cujas ferramentas de implementação se padronizaram em torno dele. O comportamento de reinício do Supervisor também difere do systemd — ele abandona um processo com o estado `FATAL` após `startretries`, em vez de adiar indefinidamente. Monitorizar diretamente a máquina de estados do Supervisor permite detetar esses processos abandonados, independentemente do que mais esteja a ser executado no host.

    Comece a monitorizar Supervisor hoje

    Configure em menos de 60 segundos. Não é necessário cartão de crédito. Estatísticas completas desde o primeiro dia.

    Iniciar período de avaliação gratuita

    Continue a explorar

    Relacionado Integrações