Verificações de hardware para servidores Dell R820 através do Nagios usando SNMP

6

Usamos o Nagios para monitoramento. Existe uma maneira de criar verificações de hardware usando a MIB SNMP para servidores R820 executando o ESXi5.x neles? Neste momento estamos usando este plugin python:

plug-in atual do python

Mas podemos usá-lo não mais devido a políticas de segurança dentro da organização. Estamos satisfeitos com a saída do plug-in atual, portanto, seria ótimo se pudéssemos usar um agente similar a menos usando o SNMP. Obrigado

    
por Danila Ladner 14.08.2013 / 15:47

4 respostas

4

Talvez eu seja esquisito, mas prefiro monitorar meus hosts ESXi em um cluster do vSphere por meio da interface SNMP do vCenter ( acoplado ao email para determinados eventos ). Isso cobre a maior parte do que preciso. Por isso, está alertando sobre os eventos em vez de pesquisar o hardware por meio de algo como o Nagios.

Você pode esclarecer quais itens específicos você está mais interessado em monitorar no nível do host?

Acho que as armadilhas e os alertas de e-mail do vSphere podem ser tão granulares quanto você deseja ...

    
por 14.08.2013 / 16:11
2

Não. A VMware escolheu a rota CIM em vez do SNMP, por isso você não pode fazer exatamente o que perguntou. O único suporte a SNMP que eles implementaram é o envio de armadilhas, que foi muito problemático da última vez que tentei (reconhecidamente há alguns anos).

Duas boas opções já foram discutidas aqui ( check_esxi_hardware.py , do OP5 check-esx-plugin ).

Como você provavelmente sabe, Nagios Exchange está repleto de tentativas de outras pessoas para resolver isso , mas a maioria deles está desatualizada e não funcionará com os produtos modernos da VMware.

Em relação ao problema de ter acesso root, o plugin do python costumava funcionar sem acesso root após o nível raiz da árvore CIM (por exemplo, não herdado nas próprias VMs), mas isso parece deixar de ser o caso a partir de 5.1. Você provavelmente poderia criar uma função especial para o Nagios usar (que não é a função de administrador).

A julgar pelos comentários que você fez acima (sobre querer monitoramento de status de hardware mais detalhado), você pode ser melhor servido por alguma verificação IPMI através do processador de serviço (BMC, LOM, iLO, o que você quiser chamá-lo) nesse caso.

Se você lida especificamente com o hardware da Dell, pode adicionar o Dell pacote específico off-line (VIB) para ativar o suporte OpenManage no ESXi.

No futuro, você pode usar o excelente plug-in check_openmanage para isso, mas é atualmente não é possível.

    
por 14.08.2013 / 17:34
0

usamos exatamente o plugin check_esx do op5 ( link ) exatamente para este propósito. Você precisa instalar o vmware perl sdk.

Nós usamos assim:

check_esx -H $HOSTADDRESS$ -u root -p passwd -l runtime -s health
CHECK_ESX.PL OK - All 449 health checks are Green | Alerts=0;;

O plugin check_esx pode monitorar muitas coisas, ótimo trabalho dos caras do op5.

    
por 14.08.2013 / 16:54
0

O problema com check_esxi_hardware e um usuário de função somente leitura ou não administrador (não raiz) é devido a um recurso PAM ou bug no ESXi 5.1 e posterior, dependendo do seu ponto de vista.

Qualquer usuário que seja criado e atribuído a qualquer função que não seja a função de administrador está configurado para negar ALL em /etc/security/access.conf. Mesmo se você clonar a função de administrador e designar o usuário criado para essa função de clone, ele será configurado para negar ALL em /etc/security/access.conf.

Eu criei um usuário "nagios" em um host ESXi 5.5 localmente (não pelo vCenter) e o atribui à "Função somente leitura" na guia Permissões. Por padrão, suas permissões no access.conf são "-: nagios: ALL"

Se eu ssh para o host do ESXi edite o /etc/security/access.conf e mude as permissões do usuário nagios para "+: nagios: sfcb" ou "+: nagios: ALL", então check_esxi_hardware funciona.

Usar "+: nagios: sfcb" restringe o usuário "nagios" para que ele possa acessar somente o Serviço CIM.

O problema que você encontra agora é que as alterações em /etc/security/access.conf não são persistentes nas reinicializações.

Este é um tópico nas comunidades da VMware que está discutindo esse problema: link

Este é um artigo muito bom que discute o mesmo problema usando o wbem: link

Estes são dois blogs discutindo mudanças persistentes durante as reinicializações no ESXi:

www.therefinedgeek.com.au/index.php/2012/02/01/enabling-ssh-access-in-esxi-5-0-for-non-root-users /

www.virtuallyghetto.com/2011/08/how-to-persist-configuration-changes-in.html

Eu não posso fazer os dois últimos links hiperlinks, pois este é o meu primeiro post para serverfault e até você ter 10 pontos de reputação, você só pode colocar dois links em uma resposta (o que é justo).

Ainda não decidi qual solução utilizarei para tornar isso persistente nas reinicializações. Ainda estou testando.

Obrigado

    
por 05.01.2016 / 02:41