Como você pode depurar um script do Método de Entrada de Dados no Cacti?

8

(Veja abaixo as atualizações ...)

Eu escrevi um script de método de entrada de dados para o Cacti (em Ruby, para coletar estatísticas do beanstalkd) e funciona a partir da linha de comando (retornando um único inteiro simples, documentado aqui ) quando executado como a conta de usuário cacti mas a própria ferramenta Cacti não coleta nenhum dado e não há nada nos logs.

Aqui está a configuração dos Métodos de Entrada de Dados: Método de entrada de dados do Cacti http://img.skitch.com/20091009-gh7g1kukn9yradj6y2iqrd5qm1.jpg

E aqui está o gráfico resultante (depois que ele foi adicionado ao modelo de gráfico de um host e deixado para ser executado por tempo suficiente para coletar dados): Gráfico dos cactos http://img.skitch.com/20091009-xq1kn3qxkteb5hb11wtx6tbs8m.jpg

Atualização # 1 : parece que o Cacti pode estar removendo o ambiente:

sudo su - cacti -c 'env -i /script/beanstat --host 10.11.12.13 --port 11300 --stat current-waiting'
/script/beanstat:4:in 'require': no such file to load -- rubygems (LoadError)
    from /script/beanstat:4

Se for esse o caso, como posso contornar isso?

Atualização # 2 : Esta resposta em stackoverflow.com parece ter resolvido o problema do ambiente, mas ainda não há dados no gráfico.

Atualização # 3 : Graças à sugestão do @ Heath, eu aumentei o nível de registro do poller e percebi isso:

WARNING: Result from CMD not valid.  Partial Result: U

Não teve sorte pesquisando o que "Resultado parcial: U" significa. O script apenas imprime um único valor inteiro.

Atualização # 4 : Eu finalmente consegui isso funcionar. A questão central era a falta de ambiente quando o script de shell é executado. Eu tive que resolver isso prefixando meu script Ruby com as seguintes linhas:

#!/bin/sh
PATH=/usr/local/bin:$PATH
exec ruby -x"/full/path/to/script/directory" $0 "$@"
#!/usr/bin/env ruby

E o problema secundário era a configuração adequada dos métodos de entrada de dados (um para cada métrica separada que eu queria coletar, embora todos eles usassem o mesmo script) que alimenta as fontes de dados que alimentam os modelos de dados (ou vice-versa , Eu ainda não estou claro sobre isso) que alimenta os modelos de gráficos que precisam ser atribuídos aos dispositivos, em seguida, adicionados às árvores do gráfico. Em resumo, é um grande desastre com porcaria de documentação e espero nunca ter que fazê-lo novamente.

Atualização # 5 : compartilhei meu script no GitHub link

    
por Teflon Ted 09.10.2009 / 20:56

1 resposta

4

Quando eu estava tentando depurar um script personalizado, achei útil ter o script anexando algumas informações a um arquivo temporário toda vez que ele era executado; Dessa forma, eu poderia ter certeza de que estava sendo chamado da maneira que eu esperava. Coisas como os argumentos de linha do cmd, ambiente e qual valor (s) ele retornaria. Você também pode querer redirecionar o stderr para um arquivo de log para capturar a saída de erro do script.

Vejo que você criou um método de entrada de dados e um modelo de gráfico. você também criou um modelo de dados?

    
por 14.10.2009 / 17:51