[Cascavel-pm] Res: Res: Problema com pipe

Gabriel Sancinetti gabrielssan em yahoo.com
Quinta Fevereiro 18 17:14:52 PST 2010


Alceu,

Os plugins são o que eu quero aproveitar nos meus hosts remotos através do check_nrpe.

Para fazer algo do tipo eu teria que refazer o "check_nrpe".
Se houver algo nesse sentido já implementado talvez resolveria parte do meu problema, mas não a questão do tempo de execução do script.

A solução sobre arquivos texto é umas das opções que posso seguir, pensei nela quando inseri um trace no processo filho escrevendo no mesmo arquivop de log que o processo pai. ( Estou tendendo para esse lado.)

Sobre o pipe, a resposta é não. É criado um pipe para cada processo filho.
Sua pergunta esta diretamente relacionada ao meu problema.
Não sei qual a limitação de nível de SO que preciso controlar com maior cuidado.
Os sleeps do código foram inseridos pensando no contexto de problema de bufferização nos pipes.
Quando adiciono um sleep de 10 segundos (que é o timeout dos comandos) no processo pai antes de chamar cada filho a taxa de erro é quase nula. (1 a 5 erros entre mais de 2000 comandos processados)
Mas coloquei todo tipo de log e de "eval" em de cada linha e nada de erro.

Daí minha desconfiança no tratamendo do sinal ("USR1") que o processo filho envia ao pai para informar que terminou. 
Pois a lógica do script parte do princípio que a cada resposta de um processo filho, a váriável $gotone é incrementada. 
Aí vem a dúvida, será que os pipes estão OK e simplesmente o script não está incrementando a variável devido a acessos simultaneos e com isso o script interpreta que perdeu alguma resposta?

Pior é que pelo visto vou ficar sem saber qual é o problema e partir para outra solução.

ps: Antes que me questionem, meu servidor é muito bom. (QuadCore, 4GB, rodando CentOS 4.7 ).

Att.

Gabriel




________________________________
De: Alceu R. de Freitas Jr. <glasswalk3r em yahoo.com.br>
Para: Cascavel Perl Mongers <cascavel-pm em pm.org>
Enviadas: Quinta-feira, 18 de Fevereiro de 2010 22:04:40
Assunto: Re: [Cascavel-pm] Res:  Problema com pipe


--- Em qui, 18/2/10, Gabriel Sancinetti <gabrielssan em yahoo.com> escreveu:

> O comando executado pode ser qualquer script da libexec do
> Nagios. 
> Em 99% dos casos check_nrpe ou check_nt.

O Nagios não permite a escrita de plugins em Perl?

Você não consegue desenvolver um plugin para o Nagios utilizando a funcionalidade de script em Perl de sua aplicação proprietária?

> Quanto ao "ForkManager" foi a minha primeira
> tentativa sem sucesso. Não me lembro por qual motivo o
> abandonei, mas com certeza está relacionado à necessidade
> aguardar a execução de multiplos processos filhos e
> processar seus resultados assincronamente.
> Se é possível, eu não me lembro.

Eu não sou craque neste módulo, então não vou nem me atraver.

Mas lembro do código que você enviou que você estava usando um pipe para saber o resultado dos processos filhos. Se os programas do Nagios sempre retornam uma resposta, você não poderia fazer com que os processos filhos atualizem seu status de execução escrevendo em arquivos texto? Ou então atualizando uma tabela de banco de dados com o resultado?

Seu código está tentando utilizar o mesmo pipe para todos os processos? O que acontece se vários deles tentam fazer acesso simultâneo?

Talvez você queira pesquisar sobre I/O assíncrono em Perl. O Perlbal faz uso de tal recurso com bastante sucesso.

Abraços,
Alceu


      ____________________________________________________________________________________
Veja quais são os assuntos do momento no Yahoo! +Buscados
http://br.maisbuscados.yahoo.com
_______________________________________________
Cascavel-pm mailing list
Cascavel-pm em pm.org
http://mail.pm.org/mailman/listinfo/cascavel-pm



      ____________________________________________________________________________________
Veja quais são os assuntos do momento no Yahoo! +Buscados
http://br.maisbuscados.yahoo.com
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://mail.pm.org/pipermail/cascavel-pm/attachments/20100218/c23e5774/attachment.html>


Mais detalhes sobre a lista de discussão Cascavel-pm