Ganglia e Nagios, Parte 1: Monitorar Clusters Corporativos com o Ganglia

Instale, configure e estenda o software livre Ganglia para monitorar efetivamente um datacenter

Este é o primeiro artigo em uma série de duas partes que faz uma abordagem prática do monitoramento de um datacenter usando as ferramentas de software livre Ganglia e Nagios. Na Parte 1, aprenda a instalar e a configurar o Ganglia, um sistema de monitoramento escalável e distribuído para clusters de alto desempenho baseado em um design hierárquico. Aprenda também a incluir mais capacidade de monitoramento gravando plug-ins do Ganglia e ativando spoofing de origem externa.

Vallard Benincosa, Certified Technical Sales Specialist, IBM

Vallard Benincosa é um profissional preguiçoso de TI Certificado em Linux trabalhando para a equipe IBM Linux Clusters. Ele mora em Portland, OR, com sua esposa e dois filhos.



04/Mar/2009

Conforme os datacenters crescem e a administração diminui, a necessidade de ferramentas de monitoramento eficientes para recursos computacionais é mais importante do que nunca. O termo monitor quando aplicado a um datacenter pode ser confundido, já que pode ter significados diferentes, dependendo do ponto de vista de quem diz e de quem ouve. Por exemplo:

  • A pessoa que executa os aplicativos no cluster pensa: "Quando minha tarefa vai ser executada? Quando ela será concluída? E como ela está sendo executada comparada com a última vez?"
  • O operador no network operations center (NOC) pensa: "Quando uma luzinha vermelha vai acender indicando que algo precisa ser corrigido e uma chamada de serviço identificada?"
  • A pessoa no grupo de engenharia de sistema pensa: "Como nossas máquinas estão executando? Todos os serviços estão funcionando corretamente? Quais são as tendências que podemos ver e como podemos melhorar o uso dos nossos recursos computacionais?"

Em algum ponto dessas definições você encontrará terabytes de código para monitorar exatamente o que você deseja monitorar. E não para por aí, também há uma abundânca de produtos e serviços. E para ajudar ainda mais, muitas dessas ferramentas de monitoramento são softwares livres. De fato, algumas das ferramentas de software livre fazem um trabalho melhor do que alguns aplicativos comerciais que tentam fazer a mesma coisa.

A parte mais difícil do uso das ferramentas de monitoramento de software livre é implementar uma instalação e configuração que dê certo para seu ambiente. Os dois maiores problemas com o uso das ferramentas de monitoramento de software livre são

  • Não há nenhuma ferramenta que irá monitorar tudo o que você quer e do jeito que você quer. Por quê? Porque usuários diferentes definirão um monitoramento de maneiras diferentes (como eu citei anteriormente).
  • Devido ao primeiro problema, muita customização poderá ser necessária para que a ferramenta funcione no datacenter exatamente do jeito que você quer. Por quê? Porque cada ambiente, independente do padrão, é exclusivo.

A propósito, esses mesmos dois problemas também existem para as ferramentas de monitoramento comercial.

Assim, vou falar sobre o Ganglia e o Nagios, duas ferramentas que monitoram datacenters. Os dois são muito usados em ambientes do tipo high performance computing (HPC), mas possuem qualidades que os tornam atrativos também para outros ambientes (como nuvens, fazendas de renderizações e centros de host). Além disso, os dois assumem posições diferentes na definição de monitoramento. O Ganglia enfoca mais as coletas de métricas e o controle delas ao longo do tempo, enquanto o Nagios considera o fato de ser um mecanismo de alerta.

Conforme os projetos separados são desenvolvidos, os dois acabam se unindo. Por exemplo:

  • O Ganglia costumava exigir um agente que era executado em cada host para reunir informações sobre ele, mas agora as métricas podem ser obtidas de qualquer coisa através do mecanismo de spoof do Ganglia.
  • O Nagios também era usado apenas para reunir informações dos hosts de destino, mas agora ele possui plug-ins que executam agentes nos hosts de destino.

Embora as ferramentas tenham partes em comum em algumas áreas funcionais, elas ainda têm diferenças e você pode ter benefícios executando os dois. Executar os dois juntos pode preencher as lacunas de cada produto:

  • O Ganglia não possui um sistema de notificação integrado enquanto que o Nagios se destaca nisso.
  • Já o Nagios não possui agentes integrados escaláveis nos hosts de destino (um motivo de reclamação das pessoas), enquanto que isso já faz parte do projeto original e intencional do Ganglia.

Há também vários projetos de software livre que fazem coisas que esses e alguns outros fazem melhor em certas áreas que outros não fazem. As soluções de monitoramento de software livre populares incluem o Cacti, Zenoss, Zabbix, Performance Copilot (PCP) e o Clumon (e algum outro que você prefira e que eu não citei). Muitos desses (incluindo o Ganglia e alguns plug-ins Nagios) usam o RRDTool ou o Multi Router Traffic Grapher (MRTG) da Tobi Oetiker implicitamente para gerar grandes quantias de gráficos e de dados de armazenamento.

Com tantas soluções de software livre para monitorar um datacenter, é de se admirar a maneira pela qual muitos centros computacionais expandidos desenvolvem suas próprias soluções e ignoram o trabalho que já foi feito por outros.

Neste artigo de duas partes, falarei sobre o Ganglia e o Nagios já que há alguns indícios de que esses sejam os mais populares. Também acho que há pouquíssimo material escrito que ensina como integrá-los, embora essa prática seja bem atual, especialmente nos grandes laboratórios HPC e das universidades.

No final dessa série, você poderá instalar o Ganglia e fazer ligações com o Nagios, além de responder às perguntas de monitoramento que poderão ser feitas a você por diferentes grupos de usuários. Isso será apenas o começo, mas ajudará você a dar os primeiros passos e a ter uma visão total do cluster.

Neste artigo, você aprenderá a:

  • Definir e configurar a instalação básica do Ganglia.
  • Usar os módulos Python para estender a funcionalidade com a Intelligent Platform Management Interface (IPMI).
  • Usar o spoof de host do Ganglia para monitorar o IPMI.

Nosso objetivo: Configurar um sistema de monitoramento de linha de base de um cluster HPC Linux® no qual essas três visões diferentes de monitoramento, mostradas acima, possam ser abordadas no mesmo nível:

  • O usuário do aplicativo pode saber quão cheio está as filas e saber os nós disponíveis para as tarefas em execução.
  • O NOC pode receber alertas de falhas do sistema ou ver uma luz vermelha de erro se acender na Interface da Web do Nagios. Eles também são notificados por e-mail se a temperatura dos nós estiver diminuindo ou aumentando muito.
  • O engenheiro do sistema pode traçar um gráfico dos dados, reportar o uso do cluster e tomar decisões sobre futuras aquisições de hardware.

Introduzindo o Ganglia

O Ganglia é um projeto de monitoramento de software livre, designado para ser escalado para milhares de nós, iniciado na Universidade de Berkeley (EUA). Cada máquina executa um daemon chamado gmond que coleta e envia as métricas (como velocidade do processador, uso da memória, etc.) coletadas do sistema operacional para um host especificado. O host que recebe todas as métricas pode exibi-las e transmiti-las em um formato compactado em uma hierarquia. Esse esquema hierárquico é o que permite que o Ganglia seja escalado tão bem. gmond causa pouca sobrecarga permitindo que grande parte do código seja executada em cada máquina no cluster sem prejudicar o desempenho do usuário.

Há momentos em que toda essa coleta de dados impacta o desempenho do nó. Um "Jitter" na rede (como é conhecido) ocorre quando muitas mensagens pequenas são recebidas ao mesmo tempo. Nós descobrimos que isso pode ser evitado ao controlar o tempo dos nós.


Instalando o Ganglia

Há vários artigos e recursos na Internet que mostram como instalar o Ganglia. Vamos rever um artigo que escrevi no wiki xCAT. Vou assumir para a finalidade deste artigo, que o sistema operacional tem um quê do Red Hat 5 Update 2 (embora as etapas não sejam muito diferentes para outros sistemas operacionais corporativos Linux).

Pré-requisitos

Se você já tiver o repositório yum configurado, a instalação dos pré-requisitos será mais fácil na maior parte. Algo como isso:

yum -y install apr-devel apr-util check-devel cairo-devel pango-devel libxml2-devel
  rpmbuild glib2-devel dbus-devel freetype-devel fontconfig-devel gcc-c++ expat-devel
  python-devel libXrender-devel

(Nota: Na realidade, o Yum deve manipular a maioria das dependências, mas em um dos meus testes ocorreram falhas de compilação que foram corrigidas ao incluir todos esses pacotes).

Depois de fazer isso, você precisará de um outro pré-requisito que não está no repositório Red Hat. Você poderá conseguir e construir isso enquanto sua máquina estiver conectada à Internet:

wget \ http://ga13.files.bigpond.com:4040/fedora/linux/releases/9/Everything/source/
       SRPMS/libconfuse-2.6-1.fc9.src.rpm

rpmbuild --rebuild libconfuse-2.6-1.fc9.src.rpm
cd /usr/src/redhat/RPMS/x86_64/
rpm -ivh libconfuse-devel-2.6-1.x86_64.rpm libconfuse-2.6-1.x86_64.rpm

Lembre-se de que os espelhos mudam constantemente. Se isso não funcionar, use um mecanismo de procura para localizar a origem libconfuse-2.6.-1.fc9 do RPM.

RRDTool

RRDTool significa Round Robin Database Tool. Ele foi criado por Tobias Oetiker e fornece um mecanismo para várias ferramentas de monitoramento de alto desempenho. O Ganglia é uma delas, mas o Cacti e o Zenoss são outros exemplos.

Para instalar o Ganglia, primeiro é necessário executar o RRDTool no servidor de monitoramento. O RRDTool fornece duas funções muito legais que são muito usadas por outros programas:

  • Ele armazena dados em um Banco de Dados Round Robin. Conforme os dados capturados ficam obsoletos, a resolução se torna menos definida. Com isso a área de ocupação fica menor mas ainda útil na maioria dos casos.
  • Ele pode criar gráficos usando argumentos da linha de comandos para gerá-los a partir dos dados capturados.

Para instalar o RRDTool, execute o seguinte (testado nas versões 1.3.4 e 1.3.6):

cd /tmp/
wget http://oss.oetiker.ch/rrdtool/pub/rrdtool.tar.gz
tar zxvf rrdtool*
cd rrdtool-*
./configure --prefix=/usr
make -j8
make install
which rrdtool
ldconfig  # make sure you have the new rrdtool libraries linked.

Há várias maneiras de usar o RRDTool como um utilitário independente no seu ambiente, mas não vou me dedicar a isso agora.

A Instalação Principal do Ganglia

Agora que você tem todos os pré-requisitos, já poderá instalar o Ganglia. Primeiro você precisará obtê-lo. Neste artigo estamos usando o Ganglia 3.1.1. Faça download do arquivo ganglia-3.1.1.tar.gz e coloque no diretório /tmp do seu servidor de monitoramento. Em seguida, faça o seguinte:

cd /tmp/
tar zxvf ganglia*gz
cd ganglia-3.1.1/
./configure --with-gmetad
make -j8
make install

Você deverá sair sem nenhum erro. Se ocorrer algum erro, verifique se há alguma biblioteca ausente.


Configurando o Ganglia

Agora que a instalação básica foi feita, há vários itens de configuração que você precisa gerenciar para colocá-lo em execução. Execute as seguintes etapas:

  1. Manipulações do arquivo de linha de comando.
  2. Modificar /etc/ganglia/gmond.conf.
  3. Gerenciar as máquinas multihomed.
  4. Iniciá-lo em um servidor de gerenciamento.

Etapa 1: Manipulações do Arquivo da Linha de Comandos

Execute como mostrado a seguir:

cd /tmp/ganglia-3.1.1/   # you should already be in this directory
mkdir -p /var/www/html/ganglia/  # make sure you have apache installed
cp -a web/* /var/www/html/ganglia/   # this is the web interface
cp gmetad/gmetad.init /etc/rc.d/init.d/gmetad  # startup script
cp gmond/gmond.init /etc/rc.d/init.d/gmond
mkdir /etc/ganglia  # where config files go
gmond -t | tee /etc/ganglia/gmond.conf  # generate initial gmond config
cp gmetad/gmetad.conf /etc/ganglia/  # initial gmetad configuration
mkdir -p /var/lib/ganglia/rrds  # place where RRDTool graphs will be stored
chown nobody:nobody /var/lib/ganglia/rrds  # make sure RRDTool can write here.
chkconfig --add gmetad  # make sure gmetad starts up at boot time
chkconfig --add gmond # make sure gmond starts up at boot time

Etapa 2: Modificar /etc/ganglia/gmond.conf

Agora você pode modificar /etc/ganglia/gmond.conf para nomear seu cluster. Se o nome do cluster for, por exemplo,"matlock", altere name = "unspecified" para name = "matlock".

Etapa 3: Gerenciar as Máquinas Multihomed

Neste cluster, eth0 é o endereço IP público do sistema. Porém, o servidor de monitoramento se comunica com os nós na rede de cluster privada através de eth1. É necessário certificar-se de que o multicast que o Ganglia usa esteja ligado ao eth1. Isso pode ser feito ao criar o arquivo /etc/sysconfig/network-scripts/route-eth1. Inclua o conteúdo 239.2.11.71 dev eth1.

Você pode reiniciar a rede e certificar-se de que as rotas que mostram este IP estão direcionadas ao eth1 usando reinício de rede de serviço. Nota: É necessário digitar 239.2.11.71 porque este é o canal de multicast padrão do Ganglia. Altere-o se você mudar o canal ou incluir mais.

Etapa 4: Iniciá-lo em um servidor de gerenciamento.

Agora você pode iniciar tudo no servidor de monitoramento:

service gmond start
service gmetad start
service httpd restart

Escolha um navegador da Web e aponte-o para o servidor de gerenciamento em http://localhost/ganglia. Você verá que o seu servidor de gerenciamento agora está monitorado e também verá várias métricas sendo monitoradas e registradas em gráfico. Uma das maiores utilidades é que você pode monitorar o carregamento nesta máquina. A seguir há um exemplo:

Figura 1. Monitorando o carregamento
Monitorando o Carregamento

Aqui não acontece muita coisa porque a máquina está ficando inativa.

Obter o Ganglia nos Nós

Até agora, nós executamos o Ganglia no servidor de gerenciamento. Agora precisamos dar mais atenção sobre qual será a aparência dos nós computacionais. Como pode ser visto, é possível colocar o Ganglia nos nós computacionais apenas ao copiar alguns arquivos. Isso é algo que pode ser incluído em um script de pós-instalação se você usar o Kickstart ou algo que pode ser incluído nas outras ferramentas de atualização.

A maneira rápida e fácil de fazer isso é: Criar um arquivo com todos os nomes de host. Suponha que você possua os nós deathstar001-deathstar100. Então você terá um arquivo chamado /tmp/mynodes que será semelhante a:

deathstar001
deathstar002
...skip a few...
deathstar099
deathstar100

Agora execute isso:

# for i in `cat /tmp/mynodes`; do
scp /usr/sbin/gmond $i:/usr/sbin/gmond
ssh $i mkdir -p /etc/ganglia/
scp /etc/ganglia/gmond.conf $i:/etc/ganglia/
scp /etc/init.d/gmond $i:/etc/init.d/
scp /usr/lib64/libganglia-3.1.1.so.0 $i:/usr/lib64/
scp /lib64/libexpat.so.0 $i:/lib64/
scp /usr/lib64/libconfuse.so.0 $i:/usr/lib64/
scp /usr/lib64/libapr-1.so.0 $i:/usr/lib64/
scp -r /usr/lib64/ganglia $i:/usr/lib64/
ssh $i service gmond start
done

Você pode reiniciar o gmetad, atualizar o navegador da Web e ver os seus nós exibidos na lista.

Alguns problemas possíveis podem ocorrer:

  • É necessário configurar explicitamente a rota estática conforme no início da etapa 3 também nos nós.
  • É possível que haja firewalls bloqueando as portas. gmond é executado na porta 8649. Se gmond estiver em execução em uma máquina, você deverá executar o comando telnet localhost 8649. Você verá uma quantia de saída XML ao rolar a tela.

Observando o Ganglia

Muitos engenheiros de sistema passam horas tentando entender o comportamento da sua própria carga de trabalho ou da tarefa. Eles podem ter um código customizado ou não fizeram uma pesquisa para saber o que seus produtos comerciais executam. O Ganglia pode ajudar a criar um perfil dos aplicativos.

Nós usaremos o Ganglia para examinar os atributos de execução da avaliação de desempenho do Linpack. A Figura 2 mostra o espaço de tempo no qual eu ativei três tarefas diferentes do Linpack.

Figura 2. Observando o Linpack
Observando o Linpack

Como você pode ver neste gráfico, quando a tarefa é iniciada, há alguma atividade na rede. O interessante, porém, é que quando a tarefa se aproxima do final, o tráfego de rede aumenta enormemente. Se você não sabia nada sobre o Linpack, você dirá: O tráfego de rede aumenta no final da tarefa.

A Figura 3 e a Figura 4 mostram o uso de CPU e de memória respectivamente. Aqui você pode ver que estamos forçando os limites do processador e que o uso de memória está muito alto.

Figura 3. Uso de CPU
Uso de CPU
Figura 4. Uso de Memória
Uso de Memória

Esses gráficos dão uma visão geral do aplicativo que estamos executando: Estamos usando muita CPU e memória e criando mais tráfego de rede próximo ao final da execução da tarefa. Ainda há muitos outros atributos sobre essa tarefa que ainda não sabemos, mas isso para nós já é um grande começo.

Saber todas essas coisas poderá ajudar a melhorar as decisões de compra de mais hardware no futuro. É lógico que ninguém vai comprar um hardware para executar só o Linpack ... certo?


Estendendo a Capacidade

A instalação básica do Ganglia tem nos dado muitas informações legais. O uso dos plug-ins do Ganglia nos dá duas maneiras de incluir mais capacidade:

  • Através da inclusão dos plug-ins in-band.
  • Através da inclusão de spoofs out-of-band de alguma outra origem.

O primeiro método foi a prática comum no Ganglia por um momento. O segundo método é desenvolvimento e sobreposições mais recentes com o Nagios em termos de funcionalidade. Vamos explorar os dois métodos rapidamente com um exemplo prático.


Plug-ins In-band

Os plug-ins in-band podem ocorrer de duas maneiras.

  • Usar um método de tarefa cron e chamada do comando gmetric do Ganglia nos dados de entrada.
  • Usar os novos plug-ins de módulo Python e criar um script deles.

O primeiro método foi a maneira comum que fizemos anteriormente e falarei mais sobre isso na próxima seção nos plug-ins out-of-band. O problema é que isso não era tão fácil de se fazer. O Ganglia 3.1.x incluía os plug-ins de módulo Python e C para poder estender o Ganglia com mais naturalidade. Agora, mostrarei o segundo método.

Primeiro, ative os plug-ins Python com o Ganglia. Faça o seguinte:

  1. Edite o arquivo /etc/ganglia/gmond.conf.

Se você abri-lo, verá que em um determinado ponto do caminho há uma seção chamada módulos que é semelhante à seguinte:

modules {
    module {
           name = "core_metrics"
     }
     ...
}

Incluiremos outro módulo na seção de módulos. O módulo que você deve inserir é este:

  module {
    name = "python_module"
    path = "modpython.so"
    params = "/usr/lib64/ganglia/python_modules/"
  }

No gmond.conf, incluí a sub-rotina de código anterior na linha 90. Isso permite que o Ganglia use os módulos Python. Além disso, depois algumas linhas abaixo dessa, após a instrução include ('/etc/ganglia/conf.d/*.conf'), inclua a linha include ('/etc/ganglia/conf.d/*.pyconf'). Isso inclui as definições dos itens que nós adicionaremos a seguir.

  1. Crie alguns diretórios.

Eis um exemplo:

mkdir /etc/ganglia/conf.d
mkdir /usr/lib64/ganglia/python_modules
  1. Repita as etapas 1 e 2 em todos os nós.

Para fazer isso:

  • Copie o novo gmond.conf em cada nó a ser monitorado.
  • Crie os dois diretórios, como na etapa 2, em cada nó a ser monitorado para que possam usar as extensões Python.

Agora que os nós estão configurados para usar os módulos Python, vamos criar um diretório. Neste exemplo, incluiremos um plug-in que usa os drivers IPMI Linux. Se você não estiver familiarizado com o IPMI e trabalhar com máquinas Intel e AMD modernas, aprenda mais sobre ele. (consulte Recursos).

Usaremos o software livre IPMItool para nos comunicar com o dispositivo IPMI na máquina local. Há várias outras opções, como o OpenIPMI ou freeipmi. Isso é apenas um exemplo, então, se você preferir usar um outro, vá em frente.

Antes de começar a trabalhar com o Ganglia, certifique-se de que o IPMItool esteja funcionando na sua máquina. Execute o comando ipmitool -c sdr type temperature | sed 's/ /_/g'. Se o comando não funcionar, tente carregar os drivers de dispositivo IPMI e execute-o novamente:

modprobe ipmi_msghandler
modprobe ipmi_si
modprobe ipmi_devintf

Depois de executar o comando ipmitool a saída mostra

Ambient_Temp,20,degrees_C,ok
CPU_1_Temp,20,degrees_C,ok
CPU_2_Temp,21,degrees_C,ok

Então no meu plug-in do Ganglia, apenas a temperatura do ambiente será monitorada. Eu criei um plug-in mal gravado chamado ambientTemp.py que usa o IPMI baseado em um plug-in encontrado no wiki Ganglia que faz isso:

Lista 1. Plug-in Python mal gravado ambientTemp.py
import os
def temp_handler(name):
  # our commands we're going to execute
  sdrfile = "/tmp/sdr.dump"
  ipmitool = "/usr/bin/ipmitool"
  # Before you run this Load the IPMI drivers:
  # modprobe ipmi_msghandler
  # modprobe ipmi_si
  # modprobe ipmi_devintf
  # you'll also need to change permissions of /dev/ipmi0 for nobody
  # chown nobody:nobody /dev/ipmi0
  # put the above in /etc/rc.d/rc.local

  foo = os.path.exists(sdrfile)
  if os.path.exists(sdrfile) != True:
    os.system(ipmitool + ' sdr dump ' + sdrfile)

  if os.path.exists(sdrfile):
    ipmicmd = ipmitool + " -S " + sdrfile + " -c sdr"
  else:
    print "file does not exist... oops!"
    ipmicmd = ipmitool + " -c sdr"
  cmd = ipmicmd + " type temperature | sed 's/ /_/g' "
  cmd = cmd + " | awk -F, '/Ambient/ {print $2}' "
  #print cmd
  entries = os.popen(cmd)
  for l in entries:
    line = l.split()
  # print line
  return int(line[0])

def metric_init(params):
    global descriptors

    temp = {'name': 'Ambient Temp',
        'call_back': temp_handler,
        'time_max': 90,
        'value_type': 'uint',
        'units': 'C',
        'slope': 'both',
        'format': '%u',
        'description': 'Ambient Temperature of host through IPMI',
        'groups': 'IPMI In Band'}

    descriptors = [temp]

    return descriptors

def metric_cleanup():
    '''Clean up the metric module.'''
    pass

#This code is for debugging and unit testing
if __name__ == '__main__':
    metric_init(None)
    for d in descriptors:
        v = d['call_back'](d['name'])
        print 'value for %s is %u' % (d['name'],  v)

Copie a Lista 1 e coloque-a em /usr/lib64/ganglia/python_modules/ambientTemp.py. Faça isso em todos os nós no cluster.

Agora que incluímos o script em todos os nós no cluster, informe ao Ganglia como executar o script. Crie um novo arquivo chamado /etc/ganglia/conf.d/ambientTemp.pyconf. O conteúdo é o seguinte:

Lista 2. Ambient.Temp.pyconf
modules {
  module {
    name = "Ambient Temp"
    language = "python"
  }
}

collection_group {
  collect_every = 10
  time_threshold = 50
  metric {
    name = "Ambient Temp"
    title = "Ambient Temperature"
    value_threshold = 70
  }
}

Salve a Lista 2 em todos os nós.

A última coisa que precisa ser feita antes de reiniciar o gmond é alterar as permissões do dispositivo IPMI para que ninguém possa executar as operações nele. Isso tornará sua interface IPMI extremamente vulnerável a usuários mal intencionados!

Este é apenas um exemplo: chown nobody:nobody /dev/ipmi0.

Agora reinicie o gmond em qualquer lugar. Se você executar isso, poderá atualizar o navegador da Web e ver algo semelhante ao seguinte:

Figura 5. Métricas in-band do IPMI
Métricas in-band do IPMI

O melhor das métricas in-band é que elas permitem executar programas nos hosts e fornecem informações na cadeia através do mesmo mecanismo de coleta que outras métricas utilizam. A desvantagem desta abordagem, especialmente para o IPMI, é a necessidade de fazer uma configuração considerável nos hosts para fazê-lo funcionar.

Observe que é necessário certificar-se de que o script foi gravado no Python, de que o arquivo de configuração esteja lá e de que o gmond.conf esteja configurado corretamente. Nós fizemos apenas uma métrica! Lembre-se de que você precisa fazer tudo isso para gravar outras métricas! Fazer isso em cada host para cada métrica pode ser um tanto cansativo. O IPMI é uma ferramenta out-of-band, então, deve haver uma melhor maneira, certo? Certo, tem sim!


Plug-ins Out-of-band (spoof de host)

O spoof de host é exatamente a ferramenta de que precisamos. Aqui usamos o poderoso gmetric e informamos a ele quais hosts estamos executando -- gmetric é uma ferramenta de linha de comandos para inserir informações no Ganglia. Dessa forma, você pode monitorar tudo o que quiser.

A melhor parte do gmetric? Há uma imensa quantidade de scripts já gravados.

Como uma experiência de aprendizagem, mostrarei como recriar e como executar o ipmitool nas máquinas de acesso remotamente:

  1. Certifique-se de que o ipmitool funcione sozinho out of band.

Eu configurei o BMC (o chip na máquina de destino) para poder executar os comandos do IPMI nele. Por exemplo: O nome dos meus hosts de monitoramento é redhouse. A partir do redhouse eu quero monitorar todos os outros nós no cluster. O redhouse é onde o gmetad é executado e onde eu aponto meu navegador da Web para acessar todas as informações do Ganglia.

Um dos nós no meu cluster possui o nome de host x01. Configurei o BMC como x01 para ter um endereço IP resolvido para o host x01-bmc. Agora eu tento acessar esse host remotamente:

# ipmitool -I lanplus -H x01-bmc -U USERID -P PASSW0RD sdr dump \ /tmp/x01.sdr
Dumping Sensor Data Repository to '/tmp/x01.sdr'
# ipmitool -I lanplus -H x01-bmc -U USERID -P PASSW0RD -S /tmp/x01.sdr \ sdr type
                                                                            Temperature
Ambient Temp     | 32h | ok  | 12.1 | 20 degrees C
CPU 1 Temp       | 98h | ok  |  3.1 | 20 degrees C
CPU 2 Temp       | 99h | ok  |  3.2 | 21 degrees C

Parece bom. Agora vamos colocálo em um script para suprir o gmetric.

  1. Crie um script que use o ipmitool para suprir o gmetric.

O seguinte script /usr/local/bin/ipmi-ganglia.pl foi criado; coloque-o no servidor de monitoramento:

#!/usr/bin/perl
# vallard@us.ibm.com
use strict;  # to keep things clean... er cleaner
use Socket;  # to resolve host names into IP addresses

# code to clean up after forks
use POSIX ":sys_wait_h";
# nodeFile: is just a plain text file with a list of nodes:
# e.g:
# node01
# node02
# ...
# nodexx
my $nodeFile = "/usr/local/bin/nodes";
# gmetric binary
my $gmetric = "/usr/bin/gmetric";
#ipmitool binary
my $ipmi = "/usr/bin/ipmitool";
# userid for BMCs
my $u = "xcat";
# password for BMCs
my $p = "f00bar";
# open the nodes file and iterate through each node
open(FH, "$nodeFile") or die "can't open $nodeFile";
while(my $node = <FH>){
  # fork so each remote data call is done in parallel
  if(my $pid = fork()){
    # parent process
    next;
  }
  # child process begins here
  chomp($node);  # get rid of new line
  # resolve node's IP address for spoofing
  my $ip;
  my $pip = gethostbyname($node);
  if(defined $pip){
    $ip = inet_ntoa($pip);
  }else{
    print "Can't get IP for $node!\n";
    exit 1;
  }
  # check if the SDR cache file exists.
  my $ipmiCmd;
  unless(-f "/tmp/$node.sdr"){
    # no SDR cache, so try to create it...
    $ipmiCmd = "$ipmi -I lan -H $node-bmc -U $u -P $p sdr dump /tmp/$node.sdr";
    `$ipmiCmd`;
  }
  if(-f "/tmp/$node.sdr"){
    # run the command against the cache so that its faster
    $ipmiCmd = "$ipmi -I lan -H $node-bmc -U $u -P $p -S /tmp/$node.sdr sdr type
                                                                       Temperature ";
    # put all the output into the @out array
    my @out = `$ipmiCmd`;
    # iterate through each @out entry.
    foreach(@out){
      # each output line looks like this:
      # Ambient Temp     | 32h | ok  | 12.1 | 25 degrees C
      # so we parse it out
      chomp(); # get rid of the new line
      # grap the first and 5th fields.  (Description and Temp)
      my ($descr, undef, undef, undef,$temp) = split(/\|/);
      # get rid of white space in description
      $descr =~ s/ //g;
      # grap just the temp, (We assume C anyway)
      $temp = (split(' ', $temp))[0];
      # make sure that temperature is a number:
      if($temp =~ /^\d+/ ){
        #print "$node: $descr $temp\n";
        my $gcmd = "$gmetric -n '$descr' -v $temp -t int16 -u Celcius -S $ip:$node";
        `$gcmd`;
      }
    }
  }
  # Child Thread done and exits.
  exit;
}
# wait for all forks to end...
while(waitpid(-1,WNOHANG) != -1){
  1;
}

À parte de toda a análise, este script apenas executa o comando ipmitool e mede a temperatura. Em seguida ele coloca todos esses valores no Ganglia com o comando gmetric para cada uma das métricas.

  1. Execute o arquivo como uma tarefa cron.

Execute crontab -e. Incluí a seguinte entrada para executar a cada 30 minutos: 30 * * * * /usr/local/bin/ipmi-ganglia.sh. Você pode ajustar para ocorrer com mais ou menos frequência.

  1. Abra o Ganglia e observe os resultados.

Ao abrir o navegador da Web do Ganglia e analisar os gráficos de um dos nós, note que os nós foram "disfarçados" (spoofing) e atualizados em cada entrada dos nós:

Figura 6. As métricas no_group
As métricas no no_group

Uma das desvantagens do spoofing é que a categoria entra no grupo de métricas no_group. gmetric parece não ter uma maneira de alterar os agrupamentos de uma melhor forma, como na versão in-band.


O que vem a seguir?

Este artigo dá uma visão geral do que você pode fazer com o Ganglia e o Nagios como um software livre de monitoramento, seja individualmente ou em conjunto. Você fez um tour sobre a instalação e a configuração do Ganglia e aprendeu como o Ganglia pode ser útil para entender as características do aplicativo. Por fim, você aprendeu como estender o Ganglia usando um script in-band e como usar os scripts out-of-band com spoof de host.

Este é um bom começo. Mas esse artigo apenas respondeu à pergunta de monitoramento feita pelo engenheiro de sistema. Agora podemos notar o desempenho geral do sistema e como as máquinas estão sendo usadas. Podemos informar se as máquinas estão inativas o tempo inteiro ou se ela está executando apenas com 60% da capacidade. Também podemos informar inclusive quais máquinas estão operando com temperatura muito baixa ou muito alta e se a troca do rack é recomendável.

A Parte 2 nesta série de duas partes explora a configuração do Nagios e sua integração com o Ganglia, incluindo:

  • Definição e configuração da instalação básica do Nagios para alertas.
  • Comutadores de monitoramento e outras infraestruturas
  • Ligar o Nagios com o Ganglia para alertas

E como prêmio, a segunda parte mostra como estender o sistema de monitoramento inteiro para executar tarefas e outras infraestruturas. Ao fazer tudo isso, poderemos responder as outras perguntas de monitoramento que outros grupos podem fazer.

Recursos

Aprender

Obter produtos e tecnologias

Discutir

Comentários

developerWorks: Conecte-se

Los campos obligatorios están marcados con un asterisco (*).


Precisa de um ID IBM?
Esqueceu seu ID IBM?


Esqueceu sua senha?
Alterar sua senha

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


A primeira vez que você entrar no developerWorks, um perfil é criado para você. Informações no seu perfil (seu nome, país / região, e nome da empresa) é apresentado ao público e vai acompanhar qualquer conteúdo que você postar, a menos que você opte por esconder o nome da empresa. Você pode atualizar sua conta IBM a qualquer momento.

Todas as informações enviadas são seguras.

Elija su nombre para mostrar



Ao se conectar ao developerWorks pela primeira vez, é criado um perfil para você e é necessário selecionar um nome de exibição. O nome de exibição acompanhará o conteúdo que você postar no developerWorks.

Escolha um nome de exibição de 3 - 31 caracteres. Seu nome de exibição deve ser exclusivo na comunidade do developerWorks e não deve ser o seu endereço de email por motivo de privacidade.

Los campos obligatorios están marcados con un asterisco (*).

(Escolha um nome de exibição de 3 - 31 caracteres.)

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


Todas as informações enviadas são seguras.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=Linux, Software livre
ArticleID=395335
ArticleTitle=Ganglia e Nagios, Parte 1: Monitorar Clusters Corporativos com o Ganglia
publish-date=03042009