Ganglia e Nagios, Parte 2: Monitorar Clusters Corporativos com Nagios

Instalar Nagios para monitorar de forma efetiva um datacenter; fazer Ganglia e Nagios trabalharem juntos

Este é o segundo artigo de uma série em duas partes que verifica a abordagem prática de monitorar um centro de dados usando as ferramentas Ganglia e Nagios de software livre. Na Parte 2, aprenda como instalar e configurar Nagios, o aplicativo de monitoramento de sistema de computador e rede de software livre popular que observa hosts e serviços, alertando usuários quando as coisas saem erradas. O artigo também mostra como unir Nagios e Ganglia (da Parte 1) e incluir dois outros recursos em Nagios para clusters, grades e nuvens padrão para ajudar no monitoramento de comutadores de rede e do gerenciador de recursos.

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.



25/Mar/2009

Recapitulação da Parte 1

Os datacenters estão crescendo e as equipes administrativas estão diminuindo, exigindo ferramentas de monitoramento eficientes para recursos de computação. A Parte 1 desta série discute os benefícios de usar Ganglia e Nagios juntas, em seguida, mostrou como instalar e estender Ganglia com scripts de monitoramento caseiros.

Lembre-se da Parte 1 das diversas definições de monitoramento (dependendo do indicador e de quem infere):

  • Caso esteja executando aplicativos no cluster, pensa: "Quando minha tarefa será executada? Quando terminará? E como está executando em comparação à última vez?"
  • Caso seja o operador no network operations center, pensa: "Quando veremos uma luz vermelha indicando que algo precisa ser corrigido e uma chamada de serviço realizada?"
  • Caso seja do grupo de engenharia do sistema, pensa: "Como está o desempenho de nossas máquinas? Todos os serviços estão funcionando corretamente? Quais tendências vemos e como podemos melhor utilizar nossos recursos de computação?"

É possível localizar código para monitorar exatamente o que deseja monitorar e esse código pode ser da variedade software livre. A parte mais difícil de usar ferramentas de monitoramento de software livre surge ao tentar implementar uma instalação e descobrir uma configuração que funcione bem para seu ambiente. Dois problemas principais com ferramentas de monitoramento de software livre (e comercial) são os seguintes:

  1. Nenhuma ferramenta irá monitorar tudo que deseja da maneira que deseja.
  2. Muita customização pode ser necessária para que a ferramenta funcione em seu datacenter exatamente como você deseja.

Ganglia é uma ferramenta que monitora datacenters e é muito usada em ambientes de computação de alto desempenho (mas é atraente para outros ambientes também, como nuvens, fazendas de renderização e centros de hosting). Está mais preocupada com reunir métricas e controlá-las ao longo do tempo em comparação ao foco de Nagios de ser um mecanismo de alerta. Ganglia costumava requerer que um agente fosse executado em cada host para reunir informações sobre o mesmo, mas agora métricas podem ser obtidas de praticamente qualquer coisa através do mecanismo de spoofing de Ganglia. Ganglia não possui um sistema de notificação integrado, mas foi projetada para suportar agentes integrados escaláveis em hosts de destino.

Após ler a Parte 1, podia instalar Ganglia, assim como responder as questões de monitoramento que diferentes grupos de usuários tendem a perguntar. Também podia configurar a configuração básica de Ganglia, usar módulos Python para estender a funcionalidade com IPMI (Intelligent Platform Management Interface) e usar spoofing de host de Ganglia para monitorar IPMI.

Agora, vamos dar uma olhada em Nagios.


Introduzindo Nagios

Esta parte mostra como instalar Nagios e amarrar Ganglia no mesmo. Vamos incluir dois recursos no Nagios que ajudarão seus esforços de monitoramento em clusters, grades, nuvens padrão (ou seja lá qual for sua palavra de impacto para computação scale-out). Os dois recursos têm tudo a ver com:

  • Monitoramento de comutadores de rede
  • Monitoramento de gerenciador de recursos

Neste caso, vamos monitorar TORQUE. Quando terminarmos, haverá uma estrutura para controlar o sistema de monitoramento de todo o datacenter.

Nagios, como Ganglia, é muito usado em ambientes HPC e outros, mas Nagios é mais um mecanismo de alerta do que Ganglia (que foca mais a reunião e o controle de métricas). Anteriormente, Nagios somente sondava informações de seus hosts de destino, mas, recentemente, desenvolveu plug-ins que permitem executar agentes nesses hosts. Nagios possui um sistema de notificação integrado.

Agora, vamos instalar Nagios e configurar um sistema de monitoramento de linha de base de um cluster HPC Linux® para abordar as três diferentes perspectivas de monitoramento:

  • A pessoa de aplicativo pode ver o quanto as filas estão cheias e ver nós disponíveis para executar tarefas.
  • O NOC pode ser alertado sobre falhas do sistema ou ver uma luz vermelha brilhante de erro na interface da Web de Nagios. Também é notificado por e-mail se nós ficarem inativos ou temperaturas ficarem muito altas.
  • O engenheiro do sistema pode fazer gráfico de dados, relatar sobre a utilização do cluster e tomar decisões sobre aquisições futuras de hardware.

Instalando Nagios

O esforço de colocar Nagios para rolar em sua máquina está bem documentado na Internet. Como costumo instalá-la muito em diferentes ambientes, gravei um script para fazer isso.

Primeiro, é necessário fazer download de dois pacotes:

  • Nagios (testado com versão 3.0.6)
  • Nagios-plugins (testado com versão 1.4.13)

Os complementos incluem:

  • O Log de Eventos de Nagios, que permite monitorar logs de eventos do Windows
  • O NRPE, que fornece muita funcionalidade de Ganglia

Pegue os tarballs e coloque-os em um diretório. Por exemplo, tenho os três arquivos a seguir em /tmp:

  • nagios-3.0.6.tar.gz
  • nagios-plugins-1.4.13.tar.gz
  • naginstall.sh

A Lista 1 mostra o script de instalação naginstall.sh:

Lista 1. O Script naginstall.sh
#!/bin/ksh

NAGIOSSRC=nagios-3.0.6
NAGIOSPLUGINSRC=nagios-plugins-1.4.13
NAGIOSCONTACTSCFG=/usr/local/nagios/etc/objects/contacts.cfg
NAGIOSPASSWD=/usr/local/nagios/etc/htpasswd.users
PASSWD=cluster
OS=foo

function buildNagiosPlug {

  if [ -e $NAGIOSPLUGINSRC.tar.gz ]
  then
    echo "found $NAGIOSPLUGINSRC.tar.gz  building and installing Nagios"
  else
    echo "could not find $NAGIOSPLUGINSRC.tar.gz in current directory."
    echo "Please run $0 in the same directory as the source files."
    exit 1
  fi
  echo "Extracting Nagios Plugins..."
  tar zxf $NAGIOSPLUGINSRC.tar.gz
  cd $NAGIOSPLUGINSRC
  echo "Configuring Nagios Plugins..."
  if ./configure --with-nagios-user=nagios --with-nagios-group=nagios
      -prefix=/usr/local/nagios > config.LOG.$$ 2>&1
  then
    echo "Making Nagios Plugins..."
    if make -j8 > make.LOG.$$ 2>&1
    then
      make install > make.LOG.$$ 2>&1
    else
      echo "Make failed of Nagios plugins.  See $NAGIOSPLUGINSRC/make.LOG.$$"
      exit 1
    fi
  else
    echo "configure of Nagios plugins failed.  See config.LOG.$$"
    exit 1
  fi
  echo "Successfully built and installed Nagios Plugins!"
  cd ..

}

function buildNagios {
  if [ -e $NAGIOSSRC.tar.gz ]
  then
    echo "found $NAGIOSSRC.tar.gz  building and installing Nagios"
  else
    echo "could not find $NAGIOSSRC.tar.gz in current directory."
    echo "Please run $0 in the same directory as the source files."
    exit 1
  fi
  echo "Extracting Nagios..."
  tar zxf $NAGIOSSRC.tar.gz
  cd $NAGIOSSRC
  echo "Configuring Nagios..."
  if ./configure --with-command-group=nagcmd > config.LOG.$$ 2>&1
  then
    echo "Making Nagios..."
    if make all -j8 > make.LOG.$$ 2>&1
    then
      make install > make.LOG.$$ 2>&1
      make install-init > make.LOG.$$ 2>&1
      make install-config > make.LOG.$$ 2>&1
      make install-commandmode > make.LOG.$$ 2>&1
      make install-webconf > make.LOG.$$ 2>&1
    else
      echo "make all failed.  See log:"
      echo "$NAGIOSSRC/make.LOG.$$"
      exit 1
    fi
  else
    echo "configure of Nagios failed.  Please read $NAGIOSSRC/config.LOG.$$ for details."
    exit 1
  fi
  echo "Done Making Nagios!"
  cd ..
}


function configNagios {
  echo "We'll now configure Nagios."
  LOOP=1
  while [[ $LOOP -eq 1 ]]
  do
    echo "You'll need to put in a user name.  This should be the person"
    echo "who will be receiving alerts.  This person should have an account"
    echo "on this server.  "
    print "Type in the userid of the person who will receive alerts (e.g. bob)> \c"
    read NAME
    print "What is ${NAME}'s email?> \c"
    read EMAIL
    echo
    echo
    echo "Nagios alerts will be sent to $NAME at $EMAIL"
    print "Is this correct? [y/N] \c"
    read YN
    if [[ "$YN" = "y" ]]
    then
      LOOP=0
    fi
  done
  if [ -r $NAGIOSCONTACTSCFG ]
  then
    perl -pi -e "s/nagiosadmin/$NAME/g" $NAGIOSCONTACTSCFG
    EMAIL=$(echo $EMAIL | sed s/\@/\\\\@/g)
    perl -pi -e "s/nagios\@localhost/$EMAIL/g" $NAGIOSCONTACTSCFG
  else
    echo "$NAGIOSCONTACTSCFG does not exist"
    exit 1
  fi

  echo "setting ${NAME}'s password to be 'cluster' in Nagios"
  echo "    you can change this later by running: "
  echo "    htpasswd -c $NAGIOSPASSWD $Name)'"
  htpasswd -bc $NAGIOSPASSWD $NAME cluster
  if [ "$OS" = "rh" ]
  then
    service httpd restart
  fi

}


function preNagios {

  if [ "$OS" = "rh" ]
  then
    echo "making sure prereqs are installed"
    yum -y install httpd gcc glibc glibc-common gd gd-devel perl-TimeDate
    /usr/sbin/useradd -m nagios
    echo $PASSWD | passwd --stdin nagios
    /usr/sbin/groupadd nagcmd
    /usr/sbin/usermod -a -G nagcmd nagios
    /usr/sbin/usermod -a -G nagcmd apache
  fi

}
function postNagios {
  if [ "$OS" = "rh" ]
  then
    chkconfig --add nagios
    chkconfig nagios on
    # toque este arquivo para que se não existir não obteremos erros
    touch /var/www/html/index.html
    service nagios start
  fi
  echo "You may now be able to access Nagios at the URL below:"
  echo "http://localhost/nagios"

}



if [ -e /etc/redhat-release ]
then
  echo "installing monitoring on Red Hat system"
  OS=rh
fi

# certifique-se de que você seja root:
ID=$(id -u)
if [ "$ID" != "0" ]
then
  echo "Must run this as root!"
  exit
fi

preNagios
buildNagios
buildNagiosPlug
configNagios
postNagios

Execute o script ./naginstall.sh

Esse código funciona em sistemas Red Hat e deve se executado se você tiver instalado todas as dependências mencionadas na Parte 1 desta série. Durante a execução de naginstall.sh, será solicitado o usuário para o qual Nagios deve enviar alertas. Será possível incluir outros posteriormente. A maioria das organizações têm um alias de correio que enviará a pessoas de um grupo.

Se houver problemas de instalação, dê uma olhada na página da Web de Nagios (consulte Recursos para obter um link) e junte-se à lista de correspondência. Em minha experiência, a maioria dos pacotes que são bem-sucedidos como Nagios e Ganglia são relativamente fáceis de instalar.


Configurando Nagios

Portanto, vamos imaginar que o script tenha funcionado e que tudo foi instalado perfeitamente. Em seguida, quando o script tiver saído com êxito, deve ser possível abrir seu navegador da Web e ver que seu próprio host local está sendo monitorado (como na Figura 1):

Figura 1. Tela Mostrando seu Host Local Sendo Monitorado
Tela Mostrando seu Host Local Sendo Monitorado

Clicando em Detalhe do Serviço, é possível ver que estamos monitorando diversos serviços (como Ping, HTTP, carregamento, usuários, etc. ) na máquina local. Isso foi configurado por padrão.

Vamos examinar o serviço chamado Partição Raiz. Esse serviço alerta quando a partição raiz fica cheia. É possível obter um entendimento integral de como essa verificação está funcionando, examinando os arquivos de configuração que foram gerados na instalação.

O Arquivo de Configuração Principal

Caso tenha usado o script naginstall.sh, então, o arquivo de configuração principal é /usr/local/nagios/etc/nagios.cfg. Esse script mostra diversos cfg_files que têm definições adicionais. Entre eles está a linha:

cfg_file=/usr/local/nagios/etc/objects/localhost.cfg

Se examinar esse arquivo, verá todos os serviços para o host local que estão presentes na visualização da Web. É onde os serviços padrão estão sendo configurados. A definição da Partição Raiz aparece na linha 77.

A hierarquia de como a verificação da partição raiz é configurada é mostrada na Figura 2.

Figura 2. Como a Verificação da Partição Raiz É Configurada
Como a Verificação da Partição Raiz É Configurada

Primeiro, observe o esquema de herança de objetos Nagios. A definição da Partição Raiz usa definições de serviços locais que, por sua vez, usam as definições de serviço genérico. Isso define como o serviço é chamado, com que frequência, outros parâmetros ajustáveis, etc.

A próxima parte importante da definição é os comandos de verificação usados. Primeiro, usa uma definição de comando chamada check_local_disk. Os parâmetros passados são !20%!10%!/. Isso significa que quando a definição do comando check_local_disk relatar 20%, um aviso será emitido. Quando atingir 10%, será obtido um erro crítico. / significa que está verificando a partição "/". check_local_disk , por sua vez, simplesmente chama o comando check_disk , que está localizado no diretório /usr/local/nagios/libexec.

Essa é a ideia básica de como configurações são realizadas. É possível usar isso para criar seus próprios serviços para monitorar e alterar qualquer um dos parâmetros desejados. Para uma apreciação mais profunda do que está ocorrendo, leia a documentação e tente, você mesmo, configurar alguns dos parâmetros.

Inscrever-se para Alertas

Agora, que está tudo configurado, inscreva-se para alertas. Já fizemos isso no início, mas se quiser alterar ou incluir usuários, é possível modificar o arquivo /usr/local/nagios/etc/objects/contacts.cfg. Simplesmente, altere o nome de contato para seu nome e o e-mail para seu endereço de e-mail. A maioria dos servidores Linux já devem estar configurados para tratar de correio.

Agora, vamos configurar outros nós.

Configurar para Outros Nós em grid/cloud/cluster

Possuo um grupo de nós em meu datacenter Dallas. Criarei um diretório no qual colocarei todos meus arquivos de configuração:

mkdir -p /usr/local/nagios/etc/dallas

Preciso informar à Nagios que meus arquivos de configuração vão estar lá. Faço isso modificando o arquivo nagios.cfg, incluindo esta linha:

cfg_dir=/usr/local/nagios/etc/dallas

Vou criar dois arquivos aqui que podem ser bem confusos. A Figura 3 ilustra as entidades e os arquivos aos quais pertencem e mostra os relacionamentos entre os objetos.

Figura 3. Diagrama de Entidades e seus Arquivos
Diagrama de Entidades e seus Arquivos

Lembre-se desse diagrama à medida que se deslocar pelo restante dessa configuração e instalação.

No arquivo /usr/local/nagios/etc/dallas/nodes.cfg, defino todos os nós e grupos de nós. Tenho três tipos de máquinas para monitorar:

  • Servidores de rede (que no meu caso são servidores Linux e têm Ganglia em execução nos mesmos)
  • Comutadores de rede (meus comutadores, incluindo Gigabit Ethernet de alta velocidade)
  • Dispositivos de gerenciamento (como módulos de gerenciamento blade, antigas placas IBM RSA, BMCs, possivelmente PDUs inteligentes, etc.)

Crio três grupos correspondentes da seguinte forma:

define hostgroup {
 hostgroup_name dallas-cloud-servers
 alias Dallas Cloud Servers
}

define hostgroup
 hostgroup_name dallas-cloud-network
 alias Dallas Cloud Network Infrastructure
}

define hostgroup
 hostgroup_name dallas-cloud-management
 alias Dallas Cloud Management Devides
}

Em seguida, crio três arquivos de template com características comuns para compartilhamento dos nós desses grupos de nós:

define host {
        name dallas-management
        use linux-server
        hostgroups dallas-cloud-management
        # TEMPLATE!
        register 0
}


define host {
        name dallas-server
        use linux-server
        hostgroups dallas-cloud-servers
        # TEMPLATE!
        register 0
}

define host {
        name dallas-network
        use generic-switch
        hostgroups dallas-cloud-network
        # TEMPLATE!
        register 0
}

Agora, minhas definições de nós individuais são dallas-management, dallas-server ou dallas-network. Segue um exemplo de cada:

define host {
 use dallas-server
 host_name x336001
 address 172.10.11.1
}
define host {
 use dallas-network
 host_name smc001
 address 172.10.0.254
}
define host {
 use dallas-management
 host_name x346002-rsa
 address 172.10.11.12
}

Gerei um script para percorrer minha lista de nós e preencher completamente esse arquivo com os nós de meu laboratório em Dallas. Quando reiniciar Nagios, serão verificados para identificar se podem ser alcançados. Mas ainda preciso incluir alguns outros serviços!

Pode querer reiniciar Nagios primeiro para assegurar que suas configurações pegaram. Em caso afirmativo, deverá ver alguns grupos sob a visualização Visão Geral de HostGroup . Caso haja erros, execute:

/usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg

Isso validará seu arquivo e ajudará a localizar quaisquer erros.

Agora, é possível incluir alguns serviços básicos. Seguindo os modelos do host local, um que é fácil é verificar a ocorrência de SSH no grupo dallas-cloud-servers. Vamos iniciar outro arquivo para isso: /usr/local/nagios/etc/dallas/host-services.cfg. A coisa mais fácil é copiar configurações do host local que deseja monitorar. Fiz isso e incluí uma dependência:

define service{
        use                             generic-service
        hostgroup_name                  dallas-cloud-servers
        service_description             SSH
        check_command                   check_ssh
        }

define service{
        use                             generic-service
        hostgroup_name                  dallas-cloud-servers
        service_description             PING
        check_command                   check_ping!100.0,20%!500.0,60%
        }

define servicedependency{
        hostgroup_name                  dallas-cloud-servers
        service_description             PING
        dependent_hostgroup_name        dallas-cloud-servers
        dependent_service_description   SSH
}

Não queria testar SSH se PING não funcionasse. A partir desse ponto, é possível incluir tudo quanto é tipo de coisa, mas isso apresenta algo que devemos verificar primeiro. Reinicie Nagios e teste os menus para assegurar que veja as verificações de ping e ssh para seus nós:

service nagios reload

Tudo bem? OK, agora, vamos ao que interessa, integrar Ganglia.


Integrar Nagios para Relatar sobre Métricas de Ganglia

Nagios Exchange é outro local excelente para obter plug-ins para Nagios. Mas, para nosso plug-in Ganglia para Nagios, não procure além do tarball transferido por download na Parte 1 deste artigo. Supondo que tenha descompactado seu tarball no diretório /tmp, é apenas uma questão de copiar o script check_ganglia.py que está no diretório contrib:

cp /tmp/ganglia-3.1.1/contrib/check_ganglia.py \
/usr/local/nagios/libexec/

check_ganglia é um script Python interessante executado no mesmo servidor que gmetad está em execução (e, no meu caso, é o servidor de gerenciamento onde Nagios também está em execução). Vamos fazer com que consulte o host local na porta 8649. Dessa forma, o tráfego de rede não é expandido executando-se comandos remotos. Obtém-se os benefícios das técnicas de escalagem de Ganglia para fazer isso!

Caso execute telnet localhost 8649, verá uma tonelada de saída no nó de dados que foram coletados dos nós (desde que Ganglia esteja ativado e em execução, como na Parte 1). Vamos monitorar algumas coisas que Ganglia possui.

Fazendo uma pesquisa detalhada do diretório /var/lib/ganglia/rrds, é possível ver as métricas que estão sendo medidas em cada host. Belos gráficos estão sendo gerados e é possível analisar as métricas ao longo do tempo. Vamos medir load_one, disk_free e, como ativamos, na Parte 1, medidas de temperatura de IPMI, vamos incluir essa medida também.

Crie o arquivo /usr/local/nagios/etc/dallas/ganglia-services.cfg e inclua os serviços nele:

define servicegroup {
  servicegroup_name ganglia-metrics
  alias Ganglia Metrics
}

define command {
  command_name check_ganglia
  command_line $USER1$/check_ganglia.py -h $HOSTNAME$ -m $ARG1$ -w $ARG2$ -c $ARG3$
}

define service {
  use generic-service
  name ganglia-service
  hostgroup_name dallas-cloud-servers
  service_groups ganglia-metrics
  notifications_enabled 0
}


define service {
  use ganglia-service
  service_description load_one
  check_command check_ganglia!load_one!4!5
}


define service {
  use ganglia-service
  service_description ambient_temp
  check_command check_ganglia!AmbientTemp!20!30
}

define service {
  use ganglia-service
  service_description disk_free
  check_command check_ganglia!disk_free!10!5
}

Quando reiniciar Nagios, será possível emitir alertas sobre métricas de Ganglia!

Um aviso: O comando check_ganglia.py alerta somente quando os limites ficam muito altos. Caso queira que alerte quando os limites ficarem muito baixos (como no caso de disk_free), então, será necessário alterar o código. Alterei o final do arquivo para ficar assim:

  if critical > warning:
    if value >= critical:
      print "CHECKGANGLIA CRITICAL: %s is %.2f" % (metric, value)
      sys.exit(2)
    elif value >= warning:
      print "CHECKGANGLIA WARNING: %s is %.2f" % (metric, value)
      sys.exit(1)
    else:
      print "CHECKGANGLIA OK: %s is %.2f" % (metric, value)
      sys.exit(0)
  else:
    if critical >= value:
      print "CHECKGANGLIA CRITICAL: %s is %.2f" % (metric, value)
      sys.exit(2)
    elif warning >= value:
      print "CHECKGANGLIA WARNING: %s is %.2f" % (metric, value)
      sys.exit(1)
    else:
      print "CHECKGANGLIA OK: %s is %.2f" % (metric, value)
      sys.exit(0)

Agora, recarregue Nagios:

service nagios restart

Se tido der certo, deverá ver dados de Ganglia sendo monitorados por Nagios!

Figura 4. Dados de Ganglia Monitorados por Nagios
Dados de Ganglia Monitorados por Nagios

Com Ganglia e Nagios funcionando juntos, você pode pirar e monitorar praticamente qualquer coisa agora. Você manda na nuvem!


Estendendo Nagios: Monitorar Comutadores de Rede

À medida que nuvens e virtualização tornam-se parte da vida, os antigos limites de "caras da rede" e "caras de sistemas" se perdem. Um administrador de sistema que continue a ignorar a configuração de comutadores de rede e o entendimento de topologias de rede corre o risco de ficar obsoleto.

Portanto, não será necessário enfrentar algo incompleto, vou mostrar como estender Nagios para monitorar um comutador de rede. A vantagem de usar Nagios para monitorar um comutador de rede (em vez de depender apenas da solução do fornecedor do comutador) é simples - é possível monitorar o comutador de qualquer fornecedor com Nagios. Já viu ping funcionar, agora vamos explorar SNMP nos comutadores.

Alguns comutadores são fornecidos com SNMP ativado por padrão. É possível configurar seguindo as instruções do fornecedor. Para configurar SNMP em um Cisco Switch, pode seguir o exemplo fornecido abaixo para meu comutador, cujo nome do host é c2960g:

telnet c2960g
c2960g>enable
c2960g#configure terminal
c2960g(config)#snmp-server host 192.168.15.1 traps SNMPv1
c2960g(config)#snmp-server community public
c2960g(config)#exit
c2960g#copy running-config startup-config

Agora, para ver o que pode ser monitorado, execute snmpwalk e canalize-o para um arquivo da seguinte forma:

snmpwalk -v 1 -c public c2960g

Se tudo der certo, deverá ver uma tonelada de coisas repassadas. É possível, então, capturar essa saída e verificar diferentes locais para monitorar.

Tenho outro comutador que usarei como exemplo aqui. Ao executar o comando snmpwalk , vejo as portas e como elas estão rotuladas. Estou interessado em obter as seguintes informações:

  • O MTU (IF-MIB::ifMtu.<portnumber>).
  • A velocidade de execução das portas (IF-MIB::ifSpeed.<port number>).
  • Se as portas estão ativadas ou não (IF-MIB::ifOperStatus.<port number>).

Para monitorar isso, criarei um novo arquivo, /usr/local/nagios/etc/dallas/switch-services.cfg. Tenho um mapa de meus hosts de rede para os comutadores, portanto, sei onde tudo está. Também deve ter um, se ainda não tiver. Se realmente deseja ser uma nuvem, todos os recursos devem ter estados conhecidos.

Usarei o nó x336001 como um exemplo aqui. Sei que está na porta 5. Segue a aparência do meu arquivo:

define servicegroup {
  servicegroup_name switch-snmp
  alias Switch SNMP Services
}

define service {
  use generic-service
  name switch-service
  host_name smc001
  service_groups switch-snmp
}

define service {
  use switch-service
  service_description Port5-MTU-x336001
  check_command check_snmp!-o IF-MIB::ifMtu.5
}
define service {
  use switch-service
  service_description Port5-Speed-x336001
  check_command check_snmp!-o IF-MIB::ifSpeed.5
}

define service {
  use switch-service
  service_description Port5-Status-x336001
  check_command check_snmp!-o IF-MIB::ifOperStatus.5
}

Ao concluir, reinicie Nagios e poderá ver que agora posso visualizar minhas entradas de comutador:

Figura 5. Monitorando Comutadores
Monitorando Comutadores

É apenas um exemplo de como monitorar comutadores. Observe que não configurei alertas nem indiquei o que constituiria uma ação crítica. Você também pode observar que há outras opções no diretório libexec que podem fazer coisas semelhantes. check_ifoperstatus e outras também podem dar conta do trabalho. Com Nagios, há diversas maneiras de realizar uma única tarefa.


Estendendo Nagios: Relatório de Tarefa para Monitorar TORQUE

Há muitos scripts que podem ser gravados com relação a TORQUE para determinar como esse sistema de enfileiramento está em execução. Nesta extensão, suponha que TORQUE já esteja ativado e em execução. TORQUE é um gerenciador de recursos que funciona com planejadores como Moab e Maui. Vamos dar uma olhada em um plug-in Nagios de software livre gravado por Colin Morey.

Faça download dele e coloque-o no diretório /usr/local/nagios/libexec e assegure que seja executável. Precisei modificar o código um pouquinho, alterando os diretórios onde Nagios foi instalado, alterando use lib "/usr/nagios/libexec"; para use lib "/usr/local/nagios/libexec";. Também precisei alterar my $qstat = '/usr/bin/qstat' ; para onde quer que o comando qstat esteja. O meu ficou assim: my $qstat = '/opt/torque/x86_64/bin/qstat' ;.

Verifique se funciona (minha fila é chamada dque):

[root@redhouse libexec]# ./check_pbs.pl -Q dque -tw 20 -tm 50
check_pbs.pl Critical: dque on localhost checked, Total number of jobs
higher than 50.  Total jobs:518, Jobs Queued:518, Jobs Waiting:0, Jobs
Halted:0 |exectime=9340us

É possível usar a opção -h para mostrar mais coisas para monitorar. Agora, vamos colocar em nosso arquivo de configuração /usr/local/nagios/etc/dallas/torque.cfg:

define service {
        use                             generic-service
        host_name                       localhost
        service_description             TORQUE Queues
        check_command                   check_pbs!20!50
}

define command {
        command_name                    check_pbs
        command_line                    $USER1$/check_pbs.pl -Q dque
                                         -tw $ARG1$ -tm $ARG2$
}

Após reiniciar Nagios, o serviço aparece sob o host local:

Figura 6. Serviço TORQUE Aparece após Reinício de Nagios
Serviço TORQUE Aparece após Reinício de Nagios

No meu, recebo um alerta crítico, pois tenho 518 tarefas enfileiradas!

Com certeza, há outras maneiras de controlar TORQUE e scripts que podem ser gravados e que foram gravados. É possível até gravar scripts que usam pbsnodes para indicar o status do nó. As pessoas estariam mais preocupadas com onde seus nós estão sendo executados e há quanto tempo a tarefa está em execução. Este pequeno exemplo fornece apenas uma idéia do que é possível e mostra como é possível tornar uma solução de monitoramento boa em pouco tempo.


Conclusão

Após ler esta série em duas partes, um administrador de sistemas deve se sentir capaz de executar Ganglia e Nagios para realmente monitorar seu datacenter como jamais havia feito antes. O escopo desses dois pacotes é enorme. O que mencionamos aqui, no entanto, é relevante para uma infraestrutura de cluster, grade ou nuvem.

A maior parte do tempo da configuração desta solução de monitoramento foi usada configurando os serviços que serão monitorados. Muitas soluções alternativas existentes são só canais, sem nenhuma aplicação - ou seja, fornecem estruturas para permitir plug-ins, mas raramente são fornecidas com plug-in prontos. A maior parte do trabalho de plug-in precisa ser feita por um administrador ou usuário e esse trabalho é frequentemente trivializado, quando, na verdade, é o grosso da excelência do monitoramento do datacenter.

Ganglia e Nagios juntos são muito mais do que um canal.

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=395990
ArticleTitle=Ganglia e Nagios, Parte 2: Monitorar Clusters Corporativos com Nagios
publish-date=03252009