UniFi AP manager: como monitorar Wireless Ubiquiti (Unifi APs) via Zabbix

UniFi AP manager: como monitorar Wireless Ubiquiti (Unifi APs) via Zabbix

A Ubiquiti fornece uma gama de produtos Wireless geralmente utilizados por pequenos provedores de acesso à internet. Além da área de comercialização de Acessos à internet, ela vem bastante agressiva para atendimento à área empresarial. Para todos os casos, a empresa apela fortemente ao custo benefício em relação a qualidade x preço: Hardware muito barato, potente e estável, além de Software grátis (para aquisição, uso e atualização).

Controlador Ubiquiti

Controlador Ubiquiti – gerenciador de APs Unifi

Neste tutorial nos focaremos na plataforma Wireless Unifi. Aqui integrarei o Unifi Manager ao Zabbix, trazendo melhorias à gerência Wireless permitindo extrair, visualizar e guardar dados importantes sobre a utilização deste importante parque.

Para melhor aproveitamento deste tutorial é preciso ter experiência com Templates, LLD (configuração no Zabbix) e conhecimento básico de Shell Script (bash).

Motivação

Se já existe um software para gerência fornecido pelo fabricante, porquê reinventar a roda?

  • Para gerência, ele é perfeito:
    • Configuração de todos os APs de forma central (adoção, configuração, atualização, reboot, reset);
    • Análise do parque (área de cobertura, versão dos APs, atividade de clientes);
    • Análise de clientes (conexão atual, histórico e tempos de permanência);
    • Bloqueio de clientes (aplicado uma vez, repassado a todos os APs do parque);
  • Para monitoramento, nem tanto:
    • Os gráficos não são conclusivos;
    • Gráficos são estáticos e limitados (tanto em disposição na tela, quanto mostram dados incorretos);
    • Não é possível ver os dados “granulados” (somente diário e mensal);
    • Não é possível ver nos últimos minutos, dados sobre clientes por SSID;
    • Dados históricos “bagunçados”.

Foco

Neste tutorial, demonstrarei a capacidade do Zabbix monitorar os seguinte itens:

  • Relacionado aos APs:
    • Lista completa de APs (texto);
    • Quantidade total de APs;
    • Quantidade de APs ativos;
    • Estado dos APs (via ICMP-ping).
  • Relacionado aos SSIDs (WLANs):
    • Quantidade total de SSIDs;
    • Lista completa de SSIDs (texto);
  • Em relação aos clientes:
    • Quantidade total de Clientes (considerando todo o parque);
    • Quantidade de clientes em cada AP;
    • Quantidade de clientes em cada SSID (independente da quantidade de APs no SSID).

Recursos

Para viabilizar o acesso aos dados, foram utilizados os seguintes recursos:

  • Controlador Unifi instalado em um CentOS 6.6 (x86_64)
    • Testado nas versões do Unifi 3.2.1 , 3.2.5 , 3.2.7 e 3.2.10, com algumas alterações à partir da 3.2.7 (que serão comentadas adiante);
    • Cliente Zabbix (testado nas versões 2.2.5 e 2.4.5) instalado no mesmo servidor que roda o Controlador Unifi (também pode ser utilizado outro computador para pegar os dados do controlador);
    • Diretório scripts criando dentro da raiz de instalação do Zabbix (por exemplo: /etc/zabbix/scripts ou outro, de acordo com a sua instalação);
    • Python 2.6 (talvez funcione com versões mais novas);
    • pip (um gerenciador de pacotes para Python);
    • Pacote Python unifi (instalado via ‘pip’): aplicação desenvolvida em Python para acesso aos dados da API Unifi;
  • Scripts, desenvolvidos por mim, que acessam os dados do controlador e devolvem ao servidor Zabbix
    • Utilização de LLD (Low Leve Discovery) para descoberta automática de novos itens;
    • Descoberta automática de novas WLANs e novos APs.
  • Arquivo com “UserParameter” para ativar as novas funcionalidades (novos itens do Zabbix)
    • Arquivo com as chamadas aos Scripts citados acima para recuperação de informações.
  • API UNIFI (aberta, por padrão)
    • Fonte de dados fornecida pela Ubiquiti (no controlador) para estender as capacidades e possibilidades de seus Softwares.
  • Servidor Zabbix (testado nas versões 2.2.5 e 2.4.5)
    • Sendo o primeiro teste, recomenda-se utilizar uma instalação do Zabbix server específica para testes com o intuito de não ter nenhum tipo de problema com o server de produção;
    • Com um template criado especificamente para monitoramento do controlador Unifi.

Atenção 1: Os scripts não conseguem trabalhar com nomes (para APs ou WLANs) que possuam dois pontos (“:”), acentos ou caracteres especiais (como “Salão de Festas 01” ou “AP do Terraço”, por exemplo). Antes de prosseguir, altere todos os identificadores.

Atenção 2: De acordo com alguns testes, não foi possível integrar a solução quando o controlador está instalando em Windows (reportado pelo usuário Victor nos comentários).

Preparação/Instalação

Com o controlador instalado e funcionando, será preciso instalar as dependências (logado como root ou utilizando o ‘sudo’).

Instalando o ‘pip’:

yum install -y python-pip

Resultado:

Dependências resolvidas
=================================================================================
 Pacote Arq. Versão Repo Tam.
=================================================================================
Instalando:
 python-pip noarch 1.3.1-4.el6 epel 330 k
Instalando para as dependências:
 python-setuptools noarch 0.6.10-3.el6 base 336 k
Resumo da transação
=================================================================================
Install 2 Package(s)

Obs: Para ver uma lista de comandos suportados pelo ‘pip’, utilize “pip -h”.

Instalando pacote ‘unifi’ via ‘pip’:

pip install unifi

Resultado:

Downloading/unpacking unifi
 Downloading unifi-1.2.2.tar.gz
 Running setup.py egg_info for package unifi
Installing collected packages: unifi
 Running setup.py install for unifi
 changing mode of build/scripts-2.6/unifi-low-snr-reconnect from 644 to 755
 changing mode of build/scripts-2.6/unifi-ls-clients from 644 to 755
 changing mode of build/scripts-2.6/unifi-save-statistics from 644 to 755
 changing mode of build/scripts-2.6/unifi-log-roaming from 644 to 755
 changing mode of /usr/bin/unifi-ls-clients to 755
 changing mode of /usr/bin/unifi-low-snr-reconnect to 755
 changing mode of /usr/bin/unifi-save-statistics to 755
 changing mode of /usr/bin/unifi-log-roaming to 755
Successfully installed unifi
Cleaning up...

Com tudo instalado, vamos aos testes.

Obs: Para versões do controlador a partir da 3.2.7, será preciso editar o arquivo “/usr/lib/python2.6/site-packages/unifi/controller.py” antes de prosseguir com os testes.

Neste arquivo, comente a seguinte linha, salvando a alteração:

_ssl.PROTOCOL_SSLv23 = _ssl.PROTOCOL_SSLv3

Baixando scripts e conf

No CentOS (controlador Unifi), faça o download destes arquivos e descompacte-os no diretório scripts (comentado na área de Recursos). No caso desta instalação, ficou em “/usr/local/zabbix/scripts/”. Depois de descompactado o arquivo, a lista de arquivos resultantes deve ser:

ubiquiti (diretório)
  \
   --> aps.py (arquivo)
  \
   --> clients.py (arquivo)
  \
   --> wlans.py (arquivo)
unifi-discovery.sh (arquivo)
unifi-monitor.sh (arquivo)

Ainda no controlador, faça também o download deste aquivo conf, (unifi.conf) salvando-o no diretório de configurações extras do seu cliente Zabbix (onde ficam os UserParameters). No caso desta instalação, ele ficou no diretório “/usr/local/zabbix/etc/zabbix_agentd.conf.d/”.

Obs: Para ativar a leitura destas configurações pelo Agente Zabbix (no controlador unifi), edite o arquivo de configuração do Agente (zabbix_agentd.conf), procure a linha Include e informe o diretório utilizado para guardar os ‘UserParameter’. No caso desta instalação ficou assim:

Include=/usr/local/zabbix/etc/zabbix_agentd.conf.d/*.conf

Edite o ‘unifi.conf’ alterando a linha que chama os Script ‘unifi-monitor.sh’, para o diretório em que vocês os salvou (baseado nos itens anteriores). Neste caso, a linha ficou desta forma:

UserParameter=up.unifi[*],/usr/local/zabbix/scripts/unifi-monitor.sh $1 $2 "$3" $4

Depois disto, reinicie o agente Zabbix no controlador Unifi para validar o novo item (up.unifi).

O que são e o que fazem estes Scripts:

Tendo navegado até o diretório escolhido para descompactar, será possível verificar alguns aquivos (no diretório ubiquiti): ‘aps.py’, ‘clients.py’ e ‘wlans.py’. Estes são os Scripts Python base para todas as consultas. Estes Scripts são utilizados pelos Scripts ‘unifi-monitor.sh’ e ‘unifi-discovery.sh’ fornecendo os dados brutos. Os Scripts “unifi-monitor.sh” e “unifi-discovery.sh” trabalham os dados e os trazem no formato entendível pelo Zabbix e de acordo com os itens utilizados nas consultas.

A imagem a seguir, ilustrar o roteamento e dependência entre os Scripts:

OBS: Para facilitar, todos os Scripts (Python ou Shell) possuem comentários internos.

A imagem vale mais que mil palavras: toda a interação do servidor Zabbix é feita inicialmente com o Script “unifi-monitor.sh”. Dependendo da necessidade, ele irá buscar serviços no “unifi-discovery.sh” ou diretamente num dos três Scripts Python (aps.py, wlans.py e clients.py).

Primeiro teste (validador das configurações): Listando os APs.

Edite o arquivo “aps.py”, procurando pela linha abaixo, preenchendo com as informações do seu Setup:

c = Controller('endereco-controlador-unifi', 'Usuario', 'Senha', 'v3', 'Site')

Esta configuração será lida pelo Software que acessa a API do Unifi, todas as vezes que um dos Scripts for executado.

Explicação dos parâmetros

  1. Primeiro: IP ou nome do controlador Ubiquiti (aqui, ‘localhost’ que tanto é a máquina onde está o controlador, quanto é a máquina que fará a coleta dos dados);
  2. Segundo: Usuário devidamente cadastrado no controlador;
  3. Terceiro: Senha do usuário informado;
  4. Quarto: versão base do controlador;
  5. Quinto: Nome do site (nas versões mais novas, existe a possibilidade de gerência multi-sites).

Depois de preenchidas as informações, a linha ficaria mais ou menos assim:

c = Controller('localhost', 'Admin', '123lab123', 'v3', 'Site-padrao')

Para testar, no servidor onde estão os Scripts, execute o Script Python “aps.py”:

python /usr/src/unifi/ubiquiti/aps.py

A saída deve ser a lista de APs (algo neste formato):

UniFi LR - Corredor sala01 - SW24-Pt01;10.1.3.102;24:a4:3c:00:00:01;1
Unifi LR - Sala dos Professores - SW39-Pt15;10.1.3.74;24:a4:3c:00:00:02;1
UniFi LR - Reitoria - SW45-Pt05;10.13.3.70;24:a4:3c:00:00:03;None
(...)

Os valores devem chegar em quatro colunas, divididas por “;”:

  1. Nome do AP (conforme configurado no controlador (via interface WEB));
  2. IP do AP;
  3. MAC do AP;
  4. Estado do AP: 1 para ativo e “None” para inativo.

Caso obtenha êxito neste teste, prossiga com a mesma alteração (da linha que informa o endereço do servidor, usuário e senha), para os arquivos “clients.py” e “wlans.py”. Aproveite para testar as saídas dos dois Scripts também.

Testando os Scripts ‘unifi-monitor.sh’ e ‘unifi-discovery.sh’:

Antes de configurar tudo no Zabbix, é importante testar o funcionamento de todos os Scripts, evitando problemas básicos que muitas vezes nos levam à ideia de que o Zabbix não está configurado corretamente. Com todos os Scripts base (‘aps.py’, ‘wlans.py’ e ‘clients.py’) testados, execute o Script ‘unifi-monitor.sh’:

./unifi-monitor.sh

A saída deve ser algo como:

É preciso informar ao menos um parametro! -> aps | clients | wlans

Assim, teste cada um dos três parâmetros e veja se obtém dados corretos. Visualizando o conteúdo do Script é possível ver as variações e filtros de cada um dos parâmetros. É interessante checar  todos eles para que no momento da configuração no Zabbix, não ocorram surpresas.

Se você está acompanhando atentamente o Tutorial e viu a imagem do roteamento de mensagens, percebeu que não é preciso testar diretamente o Script ‘unifi-discovery.sh’, pois o ‘monitor’ utiliza os serviços dele para o ‘LLD’. Assim, se os ‘LLD’ do ‘monitor’ estiverem Ok, o Script ‘discovery’ estará Ok também!

Se qualquer um deles retornar erros, possivelmente não foi seguido algum dos cuidados e configurações expostas acima (incluindo configurações de usuário/URL/senha). Volte um pouco e revise-as confirmando cada passo.

Testando o acesso aos dados pelo Zabbix

Neste ponto você deve estar ávido por colocar logo pra funcionar. Bem, vamos com calma… Só assim conseguiremos garantir que “erros malucos inexplicáveis” não aparecerão na hora H.

Para testar o retorno de dados pelo Servidor Zabbix, podermos utilizar o utilitário “zabbix_get”. Ele está presente em qualquer instalação e precisar apenas ter seu caminho verificado pois, a exemplo da instalação via pacotes (RPM ou DPKG), é possível que o caminho seja diferente. A instalação utilizada como exemplo aqui, tem como raiz o diretório “/usr/local/zabbix”. Assim, o utilitário “zabbix_get” pode ser encontrado em “/usr/local/zabbix/bin”.

Para testar a consulta aos dados do controlador via linha de comandos, execute:

/usr/local/zabbix/bin/zabbix_get -s 10.13.3.49 -k up.unifi[wlans]

O retorno deve ser a lista completa de suas WLANs, como em (IP do controlador onde estão os Scripts):

[root@zabbix-server bin]# /usr/local/zabbix/bin/zabbix_get -s 10.1.3.49 -k up.unifi[wlans]
Sala de aulas 01;Ativo
Area de convivencia;Ativo
Auditorio;Ativo
Biblioteca;Ativo
Ensino Fundamental;Ativo
Professores;Ativo

Para certificar e ver mais resultados, utilize as chaves “up.unifi[aps]” e “up.unifi[clients]”.

Importando os templates

Com todos os testes executados, é chegada a tão esperada hora: A importação dos templates para ver a coisa acontecer. Faça o download deste template e importe-o para o Zabbix.

  1. Cadastre seu host controlador Unifi;
  2. Atrele ele ao template importado acima;
  3. Aguarde por volta de cinco minutos e vá até “Lastest Data” (ou Dados Recentes, de acordo com o idioma utilizado no Zabbix).

Os dados recentes devem se parecer com isto:

Lastest Data - informações dos primeiros itens

Cerca de quinze minutos depois da configuração, será possível ver a lista de gráficos gerados:

Lista de gráficos

Gráfico do panorama:

Panorama Wireless - template unifi

Gráfico de um AP:

Gráfico de um AP

Conclusão

Quais são as capacidades do Zabbix?

Quais são os limites do Zabbix?

Resposta: sua imaginação!

Para mais perguntas e respostas, sinta-se a vontade para nos visitar:

Pendências:

  • Tornar o script LLD multi-sites automático (solicitação Eid Victor);
  • Monitorar dados de consumo dos APs (UP/Download).

Abraço!

Anúncios

Zabbix: Quantas CPUs eu tenho? (sockets, cores, threads…)

Há pouco tempo, me deparei com uma situação estranha relacionada a consumo de recursos. Um de nossos servidores de aplicação reclamava de desempenho (quanto à CPU), quando na verdade sobravam núcleos ociosos (segundo o gráfico gerado pelo Zabbix):

Antes

O servidor em questão roda um Debian 7 e parece possuir 32 núcleos (inclusive confirmado pelo $cat /proc/cpuinfo). Aqui é que está a questão: em alguns momentos do dia as reclamações de lentidão vinham e a resposta era dada pelo gráfico, ou seja, o servidor está “rodando folgado”.

Verificando a configuração da máquina, veio a surpresa: na verdade a soma de núcleos é 16 (2 sockets x 8 núcleos). Mas e de onde veio esse 32?

Explicação: cada núcleo suporta duas Threads. (2 x 8) x 2 = 32

Mas, e como saber qual a real quantidade de núcleos físicos eu tenho? Bem, vamos deixar o Zabbix responder isso.

Script e UserParameter

Para que a informação venha correta, foi preciso desenvolver um script que checa e trabalha algumas informações provenientes do /proc/cpuinfo.

Script: http://1drv.ms/1Ypsxfz

Dados:

./cpu.sh info [cores|threads]
cores: multi / single
threads: on / off
./cpu.sh count [sockets|cores|threads]
sockets, cores, threads = x (número correspondente ao item)

Para complementar, criei um arquivo com o  UserParameter: http://1drv.ms/1YpsArU

UserParameter=up.system.cpu[*],/usr/local/zabbix/scripts/cpu.sh "$1" "$2"

Como visto acima é um parâmetro simples (o “up” é de UserParameter, para diferenciar dos itens originais do Zabbix). O script só precisa estar no local certo (ou no local de escolha) e os itens criados, complementando os que já são utilizados para CPU.

Com isso tudo resolvido, o gráfico gerado será algo assim:

Depois

O item padrão “system.cpu.num” está no gráfico como “CPU – Quantidade de núcleos Virtuais (sockets x threads)”. O Item “CPU – Quantidade total de Núcleos físicos (sockets x cores)” vem do novo UserParameter “up.system.cpu[count,cores]”.

Abraço!

Monitoramento de syslog-ng Server (Linux) com Zabbix

Da mesma forma que visto no Post sobre Monitoramento de Pools DHCP em servidores Linux, é comum que certas vezes esbarremos em necessidades que a ferramenta não oferece monitoramento de forma Nativa. Mas, como estamos falando do Zabbix, isto é só uma questão de vontade e pequenas adaptações. 😀

Primeiro: O que é Syslog?

O crescimento das redes de computadores (como se diz em todas as introduções de Monografias de T.I) se dá devido à adição de mais e mais componentes de Hardware. Estes componentes estão vindo cada vez mais inteligentes, inclusive gerando informações sobre seu estado (impressoras=tonner acabando, quantidade de páginas impressas, interrupções na impressão/papel preso. Switch=acesso às configurações, comandos executados em seu terminal, alteração no estado das portas e etc).

Estas informações geralmente ficam no equipamento em um armazenamento pequeno e temporário (geralmente entre 10 e 50 MegaBytes). Devido a essa baixa capacidade de armazenamento, os registros gerados são descartados em pouco tempo, fazendo com que dados históricos sejam perdidos, junto com a capacidade de acompanhar ou entender certos problemas.

Os sistemas operacionais (proprietários ou livres) também armazenam este tipo de informação em seus sistemas de arquivos. O Linux (em suas várias Distros), geralmente os coloca em /var/log.

Estes equipamentos e sistemas vão se multiplicando (junto com os problemas e famosos ‘causos do além’). Então, como recolher estas informações de maneira centralizada e persistente? Resposta: Servidor Syslog remoto.

Existem alguns servidores Syslog com esta finalidade. Este tutorial se foca no Syslog-NG.

Syslog-NG

O que é?

Servidor Syslog remoto com suporte ao padrão descrito na RFC 5424 que carrega o padrão Syslog de trabalhar os registros, sendo interoperável entre dispositivos e diferentes Sistemas. No servidor que o Hospeda, utiliza as Portas 514 (tanto TCP quanto UDP), gravando os arquivos no diretório configurado no arquivo /etc/syslog-ng/syslog-ng.conf (diretivas destination).

Considerações

  • Este tutorial não pretende cobrir a instalação ou manutenção do Syslog-NG, mas sim oferecer aos Administradores, uma ideia de como monitora-los com o auxílio do Zabbix;
  • Não são dadas garantias de funcionamento ou exata adaptação ao(s) cenário(s) do Leitor. São passos executados em uma instalação ‘do mundo real’, que funcionaram nas configurações descritas ao longo do Tutorial;
  • Sempre faça Backups dos arquivos de configuração, mesmo que em pequenas.

Cenário

  • Servidor Zabbix na versão 2.2.0;
  • Servidor a ser monitorado: Ubuntu 12.04.3 LTS com o Agente Zabbix versão 2.0.9 (a ser atualizado);
    • Os arquivos de configuração do zabbix_agentd estão em /etc/zabbix;
  • Aplicação alvo do monitoramento: Syslog-NG Versão 3.3.4 (apt-get install syslog-ng);
    • O servidor Syslog-NG recebe registros de Switchs, routers e diversos Servidores Linux;
    • Foi criada uma partição com um arranjo de discos utilizando LVM, totalizando 400GB montada em /data
    • Para cada host, o servidor Syslog cria automaticamente um conjunto de diretórios no padrão /data/log/$host/$ano/$mes/$dia/$arquivos_de_log
  • O usuário que roda o zabbix_agent tem que ter um shell válido (/bin/bash neste caso).

O que é importante monitorar em um Servidor deste tipo?

Bem, na verdade seus requisitos podem ser diferentes dos meus. Estes foram os mais importantes pra mim:

  1. portas UDP/TCP 514 e informações de um Template Linux padrão: memória, rede, discos, processos e etc (que não serão abordadas aqui);
  2. partição ou ponto de montagem do armazenamento de Logs;
  3. quantidade de hosts que estão utilizando o servidor para Logs;
  4. lista de hosts que estão utilizando o servidor para Logs;
  5. consumo de disco por host.

Passo a passo para o monitoramento

O monitoramento de dados “não padrão” geralmente é feito via UserParameter. Aqui, para o Syslog, utilizaremos essa técnica novamente.

Primeiro: configurar o sudoers, adicionando as seguinte linhas no fim do arquivo:

zabbix ALL=NOPASSWD:/bin/ls
zabbix ALL=NOPASSWD:/usr/bin/du

Elas “liberam” o usuário zabbix a executar os comandos ls e du como super-usuário, sem precisar informa a senha.

Segundo: editar o arquivo de configuração do Zabbix Agentd (zabbix_agentd.conf), adicionando (ou alterando/descomentando) a seguinte linha:

Include=/etc/zabbix/zabbix_agentd.d/

Isto fará com que o agente Zabbix considere o diretório zabbix_agentd.d como possível fonte de configuração adicional, lendo-o a cada inicialização.

Terceiro: criar um arquivo userparameter_SysLog.conf no diretório /etc/zabbix/zabbix_agentd.d com o seguinte conteúdo:

UserParameter=logged.hosts.list,sudo ls /data/log|sed 's/\t/\n/g'
UserParameter=logged.hosts.count,sudo ls /data/log|wc -w
UserParameter=logged.hosts.space.total,sudo du -s /data/log|sed 's/\t/;/g'|cut -d ";" -f1
UserParameter=logged.hosts.space.host[*],sudo du -s /data/log/$1|sed 's/\t/;/g'|cut -d ";" -f1

Quarto: reiniciar o processo Zabbix_agentd.

OBS: caso o processo não suba, verifique os arquivos de configuração alterados e veja se alguma linha está incorreta inclusive com o arquivo dos “UserParameter”.

Explicando os parâmetros criados

  • logged.hosts.list: traz a lista dos hosts (separados por “new lines”) que estão utilizando este servidor de syslog;
  • logged.hosts.count: quantidade (em número inteiro) de hosts utilizando estes servidor;
  • logged.hosts.space.total: total de dados em uso, do diretório principal na partição utilizada para guardar os logs;
  • logged.hosts.space.host[*]: espaço total ocupado por cada host que utiliza este servidor Syslog;
    • o parâmetro esperado neste item ( [*] ), é o nome/ip do host que se deseja saber o quando ocupa de espaço no Servidor Syslog.

Para o último item, cabe uma ressalva: quando um host ou ativo de rede é apontado para este servidor Syslog, é criada uma pequena árvore (como comentado à cima, em Cenário). Esta árvore tem como Base o Nome ou IP do host:

  • Nome: caso o Servidor Syslog consiga recuperar no servidor DNS, o registro PTR (ponteiro) para o IP que acaba de chegar;
  • IP: Caso o item anterior não funcione.

Criando os itens

Lista de hosts logados:

Item lista de hosts

Item resultante (Lastest data):

Lastest Data - lista hosts

Contador de hosts Logados:

Item qtd de hosts_

Resultado:

Resultado qtd de hosts

Espaço total utilizado pelos hosts:

Item espaço total

Resultado:

Item espaço total - Resultado

Espaço utilizado por um host específico:

Item Espaço do host

Resultado:

Item Espaço do host - Resultado

Implementando a auto-busca para novos hosts adicionados

O servidor Syslog-NG irá receber vários novos hosts ao longo de seu funcionamento na rede. Configura um novo item (logged.hosts.space.host[]) para cada host certamente não é nada prático.

Para resolver isto, iremos utilizar o LLD (Low Level Discovery).

Em resumo, ele fará uma busca, de tempos em tempos, para verificar se existem novos hosts utilizando o servidor Syslog e caso existam, criará automaticamente um item logged.hosts.space.host para cada um deles.

Aviso: O LLD apesar de super útil, pode não ser compreendido no primeiro momento. Para compreender dê uma olhada aquiaqui.

Utilizando LLD para verificar espaço em novos hosts

A continuação deste tutorial vem em breve.

Abraço a todos e feliz ano novo!

Monitoramento de pools ISC-DHCP com Zabbix

O Zabbix não possui nativamente uma forma de monitoramento para Servidores DHCP, então qual a solução? Resposta: fazer com que o Zabbix leia as informações de algum lugar no sistema operacional.

Obs: este tutorial cobre o monitoramento utilizando o Linux como servidor DHCP. Para monitoramento com Windows, veja esta postagem do Zilmar.

Cenário:

  • Servidor Zabbix Versão 2.0.7;
  • Servidor a ser monitorado: Ubuntu 10.04 com o Agente Zabbix versão 2.0.7;
  • Aplicação alvo do monitoramento: ISC-DHCP (apt-get install dhcp3-server);
  • O usuário que roda o zabbix_agent precisa ter um shell válido (/bin/bash).

No meu caso, além da funcionalidade padrão (servir configurações de rede de forma automática), meu DHCP server possui a função de servir múltiplas faixas diferentes que chegam nele através de DHCP-Relay feitos em alguns Switchs.

Mas, o que é importante monitorar em um Servidor deste tipo?

  1. Capacidade de IPs por pool DHCP;
  2. Quantidade de IPs sendo utilizados em cada pool;
  3. Quantidade de IPs “Tocados” em cada pool.

Estes IPs  “Tocados” representa a quantidade máxima de Máquinas diferentes que já foram endereçadas em cada pool. Servem, em linhas gerais, para ver o quão suficiente é este pool (ou seja, agora você tem como planejar!).

Agora, como fazer pra que o Zabbix leia estas informações no servidor DHCP?

Pesquisando uma forma de extrair os dados do DHCP Server, me deparei com esta alternativa.  O problema desta abordagem é que, para cada novo pool configurado, seria necessário, manualmente, fazer uma nova configuração individual no SNMP… Ou seja, nada prático. Continuando a pesquisa, achei a seguinte alternativa: http://dhcpd-pools.sourceforge.net/ A promessa era de ser mais rápido que os “concorrentes” (inclusive do que minha primeira alternativa), pois o arquivo de Leases é bem grande e qualquer “cat + grep + cut” levaria um bom tempo e consumiria recursos da máquina. Bem, só dá pra saber, testando:

Passos:

Instalação das dependências:

apt-get install -y -b  xz-utils gnulib uthash-dev

Criação de um diretório para os fontes:

mkdir /usr/src/dhcpd-pools

Download e descompactação dos fonte do dhcpd-pools:

cd /usr/src/dhcpd-pools

wget http://sourceforge.net/projects/dhcpd-pools/files/dhcpd-pools-2.23.tar.xz/download -O dhcpd-pools-2.23.tar.xz

tar xJf dhcpd-pools-2.23.tar.xz

Compilação e instalação:

./configure && make && make install

Depois de instalado, um teste básico pode ser feito com o seguinte comando:

dhcpd-pools -c local/do/dhcpd.conf -l local/do/dhcpd.leases

No caso do setup utilizado nesta instalação, o comando completo ficaria (procure os arquivos, conforme sua instalação):

dhcpd-pools -c /etc/dhcp3/dhcpd.conf -l /var/lib/dhcp3/dhcpd.leases

A saída do comando, provavelmente será parecida com esta:

Ranges:
shared net name first ip last ip max cur percent touch t+c t+c perc
All networks 172.16.101.1 - 172.16.101.254 254 6 2.362 179 185 72.835

Shared networks:
name max cur percent touch t+c t+c perc

Sum of all ranges:
name max cur percent touch t+c t+c perc
All networks 254 6 2.362 179 185 72.835

Para cada instalação e configuração, a saída poderá ser diferente. Mas é possível ter uma noção através deste arquivo. Lendo o retorno do comando, temos o seguinte:

shared net name first ip last ip max cur percent touch t+c t+c perc
All networks 172.16.101.1 - 172.16.101.254 254 6 2.362 179 185 72.835

Dá pra tirar daí, que minha rede possui uma capacidade máxima de 254 endereços (da forma que foi configurada), está com 6 endereços em uso atualmente, o que representa 2.362% e que dela já foram utilizados 179 endereços diferentes (além dos outros campos que não comentarei). Porém se eu tiver várias redes preciso que, ao invés de ser mostrado “All networks”, seja mostrado o nome da rede. Para isso, será necessário executar alterações nos arquivos de configuração do Serviço DHCP. As alterações são pra “envolver” cada pool com um nome específico, através do uso da diretiva “shared-network”. Em minha instalação, editei o arquivo /etc/dhcp3/dhcpd.conf que estava assim:

subnet 172.16.100.0 netmask 255.255.253.0 {
 default-lease-time 7200;
 max-lease-time 10800;
 range 172.16.101.1 172.16.101.254;
 option routers 172.16.100.15;
 option domain-name-servers 172.16.100.15;
 option broadcast-address 172.16.101.255;
 option domain-name "dominio.local";
}

Deixando-o asim:

shared-network Minha-rede {
subnet 172.16.100.0 netmask 255.255.253.0 {
 default-lease-time 7200;
 max-lease-time 10800;
 range 172.16.101.1 172.16.101.254;
 option routers 172.16.100.15;
 option domain-name-servers 172.16.100.15;
 option broadcast-address 172.16.101.255;
 option domain-name "dominio.local";
}
}

Depois de salvar e reiniciar o serviço DHCPD, execute novamente o seguinte comando:

dhcpd-pools -c /etc/dhcp3/dhcpd.conf -l /var/lib/dhcp3/dhcpd.leases

Veja que em “Shared networks”, agora o retorno é diferente:

Ranges:
shared net name first ip last ip max cur percent touch t+c t+c perc
All networks 172.16.101.1 - 172.16.101.254 254 6 2.362 179 185 72.835

Shared networks:
name max cur percent touch t+c t+c perc
Minha-rede 254 11 4.331 178 189 74.409

Sum of all ranges:
name max cur percent touch t+c t+c perc
All networks 254 6 2.362 179 185 72.835

O dhcpd-pools oferece um help, no estilo man page do Linux, e nele é importante observar o seguinte (man dhcpd-pools):

-L, --limit=NR
The NR will limit what will be printed. Syntax is similar to chmod(1) permission string. The NR limit string uses two digits which vary between
0 to 7. The first digit determines which headers to display, and the second digit determines which numeric analysis tables to include in the output.
The following values are "OR'd" together to create the desired output. The default is 77.

01 Print ranges
02 Print shared networks
04 Print total summary
10 Print range header
20 Print shared network header
40 Print total summary header

Aqui é possível ver que a utilização do parâmetro “-L”, limita a exibição conforme a tabela à cima, de acordo com a combinação escolhida. Então, se executarmos o comando incluindo o “-L 22”, ele retornará somente os dados das “Shared networks”:

dhcpd-pools -c /etc/dhcp3/dhcpd.conf -l /var/lib/dhcp3/dhcpd.leases -L22

Resultado:

Shared networks:
name max cur percent touch t+c t+c perc
Minha-rede 254 11 4.331 178 189 74.409

Você também poderia fazer algum malabarismo para separar o texto, pegar certa linha e etc mas, se o comando já fornece isto, para que reinventar a roda?

Fazendo o zabbix capturar os dados

Sabemos que para obter dados que o Zabbix não consegue nativamente, uma das possibilidades é a utilização de “UserParameters”. Estes, em resumo, são itens criados livremente pelo Administrador para que, quando consultados via Zabbix_agent, retornem algo útil, como o resultado de um comando, por exemplo. Para que isto funcione, é necessário editar o arquivo de configuração do agente. Nele, procure a diretiva “Include” que, provavelmente estará assim:

# Include=/usr/local/etc/zabbix_agentd.userparams.conf

Esta diretiva diz que, além do arquivo .conf padrão, o zabbix (quando iniciar) irá procurar outros arquivos. Nesta caso é possível indicar um arquivo direto (como à cima), ou uma pasta que conterá vários outros arquivos. Para nosso tutorial, ficou da seguinte forma (Claro que este diretório precisa existir e estar acessível para leitura.):

Include=/usr/local/etc/zabbix_agentd.conf.d/

Neste diretório será necessário criar o arquivo “UserParameters_dhcpd.conf”, contendo os itens customizados e seus respectivos comandos. Copie e cole o conteúdo à baixo no arquivo “UserParameters_dhcpd.conf” (antes de copiar, verifique a configuração dos parâmetros “-c” e “-l“):

UserParameter=dhcp.pool.all,dhcpd-pools -c /etc/dhcp3/dhcpd.conf -l /var/lib/dhcp3/dhcpd.leases -L22

UserParameter=dhcp.pool.max[*],dhcpd-pools -c /etc/dhcp3/dhcpd.conf -l /var/lib/dhcp3/dhcpd.leases -L22|grep -i $1|sed 's/ \+/;/g'|cut -d';' -f2

UserParameter=dhcp.pool.use[*],dhcpd-pools -c /etc/dhcp3/dhcpd.conf -l /var/lib/dhcp3/dhcpd.leases -L22|grep -i $1|sed 's/ \+/;/g'|cut -d';' -f3

UserParameter=dhcp.pool.percent[*],dhcpd-pools -c /etc/dhcp3/dhcpd.conf -l /var/lib/dhcp3/dhcpd.leases -L22|grep -i $1|sed 's/ \+/;/g'|cut -d';' -f4

UserParameter=dhcp.pool.touch[*],dhcpd-pools -c /etc/dhcp3/dhcpd.conf -l /var/lib/dhcp3/dhcpd.leases -L22|grep -i $1|sed 's/ \+/;/g'|cut -d';' -f5

Depois de criar o arquivo (sem os espaço entre as linhas), salve e reinicie o zabbix_agent. Cada linha de UserParameter possui dois elementos: o item e o comando. Exemplo:

Item

dhcp.pool.all

Comando

dhcpd-pools -c /etc/dhcp3/dhcpd.conf -l /var/lib/dhcp3/dhcpd.leases -L22

O item é o que será configurado na interface do Servidor Zabbix. Quando o agente receber a solicitação do item (por exemplo, dhcp.pool.all), ele retornará os dados resultantes do comando. Depois disso, no servidor zabbix execute o seguinte comando:

zabbix_get -s ip.do.servidor.dhcp -k dhcp.pool.all

Se tudo estiver correto, um retorno como este será exibido (caso exista mais de um pool configurado):

Shared networks:
name max cur percent touch t+c t+c perc
Minha-rede01 356 260 73.034 87 347 97.472
Minha-rede02 422 0 0.000 0 0 0.000
Minha-rede03 782 539 68.926 232 771 98.593
...
Minha-redeN 250 43 17.200 206 249 99.600

Lembre-se: Para cada pool (Minha-rede01, Minha-rede02, Minha-rede03), serão cadastrados todos os parâmetros (max, use, percent e touch).

Outros testes pode ser feitos, utilizando os outros itens no UserParameter:

dhcp.pool.max[Minha-rede01]
Retorno (exemplo): 200

dhcp.pool.use[Minha-rede01]
Retorno (exemplo): 20
dhcp.pool.percent[Minha-rede01]
Retorno (exemplo): 12.4
dhcp.pool.touch[Minha-rede01]
Retorno (exemplo): 23

Pronto, parâmetros configurados! Agora é hora de ir ao zabbix server (via interface web) e cadastrar os itens para o Servidor DHCP, como no exemplo à baixo:

Conf_itens_DHCP01

No exemplo dos pools dado anteriormente, é possível ver o tipo de dado retornado por cada item. Cadastre um por um, e vá vendo em “Lastest data” se o resultado aparece. Depois, configure os gráficos a seu gosto e pronto, você tem os dados que queria! 😀

Até este ponto, é possível monitorar os pools DHCP tranquilamente. Agora, se você já trabalhou no zabbix com LLD (Low Level Discovery) e sabe que seria mais interessante pegar os pools automaticamente, siga pro próximo parágrafo.

Utilizando LLD para buscar os pools DHCP:

Este LLD precisa de um Script rodando localmente para trazer os nomes dos pools e popular os 4 itens. Para isso, escolhi o diretório /usr/local/etc/zabbix/scripts/ para adicionar o script que retornará os dados no formato JSON. Lá, criei o script dhcppolls.sh com o seguinte conteúdo:

#!/bin/bash
pools_all=`dhcpd-pools -c /etc/dhcp3/dhcpd.conf -l /var/lib/dhcp3/dhcpd.leases -L02|egrep -io "^[a-z]*(\-|\_)?[a-z]*"`
pools_qtd=`echo $pools_all|wc -w`
retorno=`echo -e "{\n\t\t"\"data\"":["`
for p in $pools_all
do
 if [ "$pools_qtd" -le "1" ]
 then
 retorno=$retorno`echo -e "\n\t\t{\"{#DHCPPOOL}\":\"$p\"}"`
 else
 retorno=$retorno`echo -e "\n\t\t{\"{#DHCPPOOL}\":\"$p\"},"`
 fi
 pools_qtd=$(($pools_qtd - 1))
done
retorno=$retorno`echo -e "]}"`
echo -e $retorno

Salve e saia do arquivo. No arquivo UserParameters_dhcpd.conf adicione o seguinte “UserParameter”:

UserParameter=dhcp.pool.discovery,/usr/local/etc/zabbix/scripts/dhcppolls.sh

Reinicie o agente zabbix no servidor DHCP.

Para teste, execute o seguinte no servidor Zabbix:

zabbix_get -s ip.do.servidor.dhcp -k dhcp.pool.discovery

Os dados serão parecidos com estes:

{ "data":[ {"{#DHCPPOOL}":"Minha-rede01"}, {"{#DHCPPOOL}":"Minha-rede02"}, {"{#DHCPPOOL}":"Minha-rede03"}]}

Se tudo correr como descrito, estaremos a um passo de concluir a configuração. Se não, volte ao começo do tutorial e revise as configurações feitas.

Agora, na interface web, vá ao Host Servidor DHCP e cadastre um novo item do Tipo “Discovery rules”, da seguinte forma:

LLD_DHCP

Veja que o parâmetro em “Macro” é o mesmo retornado na execução de “dhcp.pool.discovery”. Agora, será preciso criar os itens a serem populados com o dado trazido pelo LLD. Para isso, depois de criar a “Discovery Rule”, clique em “Item prototype” e crie o item como segue:

LLD_DHCP_item

Crie os 4 itens, conforme vimos anteriormente e, se desejar Triggers, gráficos e o que mais for necessário.

Pronto, fim do tutorial! 😀

Se precisar de algum suporte, é possível me encontrar (e vários outros membros) na lista Brasileira de discussão sobre Zabbix, através deste link.

Abraço!