Assegure-se de que um processo esteja sempre em execução

21

Comecei a hospedar sites há algum tempo usando o Cherokee. Para fontes externas (FastCGI, etc), ele tem uma opção para iniciar o processo, caso não encontre um em execução no soquete ou porta designada. Isso é ótimo porque significa que se o site do Django ou do PHP cair (como acontece ocasionalmente), ele será reiniciado automaticamente.

Em um novo servidor usando PHP-FPM eu não pude usar o Cherokee (ele tem um bug com PHP) então mudei para o NGINX. Eu realmente gosto do NGINX (por seu estilo de configuração), mas estou tendo sérios problemas com processos caindo e nunca reaparecendo. O PHP faz isso algumas vezes, mas os sites do Django são mais um problema. Eu criei scripts de init para eles e eles surgem na inicialização, mas isso não me ajuda se eles saírem entre as reinicializações.

Acho que estou procurando um proxy FastCGI. Algo que, como o Cherokee, sabe quais processos devem ser executados em quais soquetes / portas e os respawns sob demanda. Será que tal coisa existe? Existe alguma maneira de construir isso no NGINX (para facilitar a configuração)?

    
por Oli 20.08.2010 / 13:56

9 respostas

12

Que tal daemontools e especificamente a ferramenta de supervisão

supervise monitors a service. It starts the service and restarts the service if it dies. Setting up a new service is easy: all supervise needs is a directory with a run script that runs the service.

    
por 20.08.2010 / 14:31
8

respawn em inittab

    
por 20.08.2010 / 14:41
5

Eu sigo a sugestão de daemontools , mas se você não gosta do modo como o software de DJB funciona (por qualquer motivo), também há supervisord .

Eu configurei uma imagem do FreeBSD há um tempo atrás que usava supervisord para gerenciar nginx e gunicorn , que eu costumava usar hospedar alguns aplicativos WSGI simples, e todo o processo foi bem direto.

Se você está fazendo isso para o Django, o Gunicorn torna realmente simples implementar os aplicativos do Django, btw. Consulte esta postagem do blog para obter mais detalhes.

    
por 20.08.2010 / 14:40
4

Outra opção poderia ser usar monit , que é o que geralmente uso.

    
por 24.08.2010 / 21:44
3

Você considerou god ?

God is an easy to configure, easy to extend monitoring framework written in Ruby.

Keeping your server processes and tasks running should be a simple part of your deployment process. God aims to be the simplest, most powerful monitoring application available.

Eu uso isso para ter certeza que se as instâncias Rails / nginx caírem, elas serão recuperadas, e embora eu não veja o suporte embutido para verificar se ele está usando a porta certa ou não, mas se o problema é que o processo falha ou não está mais sendo executado, você não pode errar com god .

    
por 20.08.2010 / 18:04
0

Além do daemontools e do supervisord, há daemonização .

    
por 20.08.2010 / 19:14
0

Uma solução interessante seria lançar periodicamente um script (via cron ) que detecta se o processo está inativo e, neste caso, reiniciá-lo.

    
por 20.08.2010 / 19:00
0

Existem várias maneiras de reiniciar um daemon com falha, a recomendação usual é "respawn in inittab", mas com alguma consideração de um limite se a máquina for realmente parafusada.

O daemon de watchdog também pode monitorar um processo através de seu arquivo PID. No entanto, isso deve ser considerado apenas como uma linha secundária de defesa para reinicializar uma máquina que está muito doente para funcionar adequadamente (por exemplo, sem memória, com garfo, etc.) e não como uma maneira principal de monitorar e reiniciar um daemon.

Finalmente, você pode considerar o monitoramento de sistemas complexos usando nagios para fornecer ao administrador uma visão global. Ele pode executar plug-ins para investigar a operação do daemon externamente, o que é um teste mais completo do seu funcionamento que simplesmente o PID está ativo.

    
por 14.09.2013 / 10:19
-1

Resposta simples - comece, escreva seu pid em algum lugar, e cada x vezes (segundos, minutos, sua aposta) verifique se o processo está em alta.

Resposta longa - todos os itens acima são bons métodos. Mas um pouco complicado.

Lembre-se também de que estar vivo e responder a solicitações é algo diferente.

    
por 25.08.2010 / 00:08