Features

ltima alterao: **/03/2015

1) Entender e testar Netflow.

O Zabbix no , nem possui integrado a si, um coletor Netflow. No frum oficial do Zabbix (https://www.zabbix.com/forum/) discute-se sobre essa funcionalidade ainda no implementada na ferramenta, e h at mesmo um pedido oficial junto Zabbix SIA para que as prximas verses implementem esse recurso. A Zabbix SIA, porm, at agora no se pronunciou sobre isto.

Portanto, uma vez que ainda no exista possibilidade de monitoramento de dados Netflow com o Zabbix, pensei numa forma de enganar o Zabbix para que ele consiga ao menos apresentar os dados coletados pelo Netflow. Segue o diagrama e a explicao da idia.

Uma ferramenta Netflow Collector faria a funo que o Zabbix deveria fazer (coletar dados Netflow diretamente do dispositivo monitorado). Um script seria usado para transferir os dados coletados pelo Netflow para um arquivo temporrio (.tmp). Um agente Zabbix coletaria os dados armazenados no arquivo temporrio e os enviaria para o servidor Zabbix, que armazenaria os dados recebidos no DB e manipularia a informao para a gerao e apresentao de grficos. Assim que o agente enviasse os dados para o servidor Zabbix, esses dados seriam apagados do arquivo temporrio (funo realizada pelo script ou pelo prprio agente).

Eu chamaria esse monitoramento de dados Netflow de item de acompanhamento externo, uma vez que o Zabbix utilizaria uma ferramenta externa (coletor Netflow) para conseguir os dados do dispositivo monitorado. No entanto, o Zabbix entenderia que o agente (aqui considerando-o como ativo) envia dados que coleta diretamente do roteador, ou seja, o Zabbix no enxergaria o Coletor Netflow, nem o script, nem o arquivo temporrio. E considerando que o agente Zabbix (em modo ativo) cria um arquivo temporrio em qualquer dispositivo em que est sendo executado para armazenar as informaes que dever enviar para o servidor Zabbix, esse agente no enxergaria o Coletor Netflow nem o script, de modo que ele entenderia estar fazendo seu trabalho como em qualquer outro dispositivo (buscando sempre as informaes no arquivo temporrio para envi-las ao servidor Zabbix).

Trata-se apenas de uma idia, ainda no testada (como combinado, os testes das ferramentas de Netflow sero feitos depois da concluso dessa lista). Mas acredito que deva ser considerada.

2) Ambiente Multi-User: Simular monitorao do ambiente de dois clientes para entendermos como ser a organizao quando temos mais de um cliente sendo monitorado pelo mesmo Zabbix.

Simulao realizada. Dois dispositivos foram inseridos numa rede X (laboratrio) e outros na rede Y (LAN da 4xpert), na qual o Zabbix est sendo executado. O Zabbix teve acesso aos dispositivos da rede X de forma direta e independente. De forma direta porque o Zabbix, estando na rede Y, acessa diretamente os dispositivos da rede X. De forma independente porque o Zabbix no acessou um nico dispositivo para coletar as informaes, mas cada dispositivo separadamente. Isso gera uma quantidade de trfego considervel, que pode ser suprimida por meio do uso do proxy. O Zabbix Proxy trabalha, de fato, como uma probe do N-able: rene toda a informao de todos os itens monitorados de todos os dispositivos e envia esse conjunto de informaes ao servidor Zabbix. Isso gera uma diminuio considervel da quantidade de trfego entre as redes X e Y, uma vez que o Zabbix Proxy compacta esse conjunto de dados para aliviar o peso do trfego entre as duas redes.

Na simulao feita, a organizao do Zabbix permaneceu a mesma. Na guia de apresentao de hosts, todos os dispositivos monitorados, de ambas as redes, apareciam juntos numa mesma lista. Na aba de grupos, foi possvel separar os hosts por rede. No Dashboard, o Zabbix considerou todos os dispositivos de forma unificada, ou seja, apresentou informaes de todos os hosts indistintamente, sem considerar o grupo no qual estavam inseridos nem a rede qual pertenciam. E at onde eu sei, no possvel manipular o Dashboard para personaliz-lo de qualquer forma que seja no possvel nem mesmo inserir grficos nele (a no ser que essa manipulao seja feita no prprio cdigo).

Com a insero de um Zabbix Proxy em cada rede (at mesmo na rede onde o servidor Zabbix est sendo executado), no sei se a organizao mudar ou se haver uma nova aba na qual seja possvel visualizar os dispositivos monitorados de forma separada pela rede em que esto. Ainda farei os testes com o Zabbix Proxy para ver o que acontecer.

3) Proxy: precisamos entender e testar.

A utilizao de Zabbix Proxies em redes remotas para a coleta de informaes de monitoramento e o envio conjunto dessas informaes ao servidor Zabbix recebe o nome de Arquitetura Distribuda. A utilizao de proxies fundamental quando se deseja organizar um sistema de monitoramento centralizado.

Como foi dito no ponto anterior, o Zabbix Proxy trabalha de modo semelhante probe do N-able: rene os dados de todos os itens monitorados e os envia em conjunto ao servidor Zabbix de tempo em tempo, considerando a configurao de intervalo de envio.

Se o Zabbix monitorasse cada dispositivo da rede remota de forma direta e independente, alguns problemas poderiam vir a ocorrer, entre os quais o mais crtico talvez seja a perda de dados. Se o link ficar indisponvel, por exemplo, as informaes de monitoramento coletadas no perodo da indisponibilidade sero perdidas. O Zabbix Proxy soluciona esse problema armazenando as informaes coletadas em um arquivo temporrio at que o link volte a ficar disponvel e seja possvel envi-las ao servidor Zabbix. Nenhum dado perdido, apesar de chegar atrasado ao servidor Zabbix.

A utilizao de Zabbix Proxies tambm possibilita a distribuio de carga entre o servidor e os proxies, aliviando o processamento no servidor Zabbix e requerendo menos uso de CPU e de I/O.

* * *

Os testes com o Zabbix Proxy foram realizados.

Os proxies funcionam da seguinte forma: os dispositivos monitorados enviam informaes de gerenciamento para o Zabbix Proxy configurado na rede (os dispositivos enxergam o Zabbix Proxy como se fosse o Zabbix Server). O Zabbix Proxy armazena essas informaes num arquivo temporrio at que sejam enviadas ao Zabbix Server. Vale notar que o Zabbix Server enxerga o Zabbix Proxy como um dispositivo sendo monitorado por um agente Zabbix. Foi dito anteriormente que o agente Zabbix trabalha armazenando informaes que recolhe do dispositivo em um arquivo temporrio, da mesma forma que o Zabbix Proxy. Aqui, o agente Zabbix Proxy pode ser tanto ativo como passivo; como passivo, o Zabbix Server ir at o Zabbix Proxy e recolher as informaes armazenadas no arquivo temporrio. Assim, o Zabbix Server entender que o Zabbix Proxy nada mais do que um agente Zabbix comum.

Um outro ponto importante a ser considerado quanto manuteno do sistema de monitoramento. Cedo ou tarde, o sistema precisar passar por algum tipo de manuteno, preventiva ou corretiva, que o deixar por algum tempo fora do ar. O Zabbix Server fora do ar significa perda de informaes de monitoramento durante o perodo em que no estiver sendo executado. Essas informaes no podem ser simplesmente desconsideradas. aqui, ento, que o Zabbix Proxy mostra sua outra utilidade. Foi dito que o Zabbix Proxy, quando no consegue se comunicar com o Zabbix Server, armazena as informaes de gerenciamento em um arquivo temporrio at que o Zabbix Server volte a ficar disponvel. Quando for preciso fazer uma manuteno no Zabbix Server, se todas as redes monitoradas pelo Zabbix estiverem com a arquitetura distribuda com proxies, basta interromper o servio do Zabbix Server e nenhuma informao de monitoramento ser perdida. Por outro lado, caso a manuteno precise ser feita nos Zabbix Proxies, basta apontar os dispositivos monitorados para o Zabbix Server at que o perodo de manuteno termine. Esse um dos motivos pelos quais a documentao oficial do Zabbix recomenda que o Zabbix Proxy seja instalado em todas as redes de uma arquitetura Zabbix, at mesmo na rede em que o Zabbix Server estiver sendo executado.

Quanto organizao da tela do Zabbix, nada foi alterado com a introduo dos proxies.

4) Alta disponibilidade. Entender as opes. possvel sincronizar dois servidores?

O Zabbix em si no fornece recurso prprio para high availability. No entanto, possvel utilizar o mdulo DRBD com o Linux-HA para prover a alta disponibilidade. Dois servidores Zabbix so utilizados, um estando configurado em modo primrio e o outro em modo secundrio. Quando ambos os servidores estiverem em funcionamento normal, a carga de monitoramento distribuda entre eles. Quando o servidor primrio fica fora do ar, o secundrio assume em seu lugar. Apesar de compartilharem a carga, os dois servidores devem ser concebidos de modo a suportar 100% da carga de monitoramento de forma independente (tanto em recursos de memria e CPU, quanto em escalabilidade do banco de dados), uma vez que se um cai, o outro assume o servio sozinho.

Imagem: Zabbix Wiki.

No cenrio acima, os Zabbix Servers Itchy e Scratchy so, na verdade, DRBD primrio e secundrio. O DRBD um mdulo para o kernel do Linux que possibilita uma arquitetura distribuda e sincronizada. Esse mdulo pode ser utilizado nos servidores Zabbix em conjunto com o Linux-HA. Teramos, portanto, um cluster de alta disponibilidade para o sistema Zabbix por meio do DRBD. Esse cluster no est limitado a apenas dois servidores.

5) Trigger: testar usando script para realizar uma tarefa qualquer. Importante entender se a sada ou resultado do script, se for um texto, poder ser armazenada no banco de dados do Zabbix.

O Zabbix pode agir proativa ou reativamente. Para tanto, basta configurar uma ao. H dois tipos de ao no Zabbix:

1. Envio de Mensagem;2. Comando Remoto.

Neste caso, o segundo tipo o utilizado (o primeiro usado para o envio de alertas por e-mail, SMS, etc.). Na opo de comandos remotos, h cinco subtipos possveis a serem escolhidos:

1. Comandos IPMI;2. Script personalizado;3. Comandos SSH;4. Comandos Telnet;5. Script global.

O que nos interessa aqui so os subtipos 2 e 5. A diferena entre script personalizado e script global est em que enquanto o script personalizado s ser utilizado para a ao especfica na qual est sendo configurado, o script global, por sua vez, pode ser utilizado por qualquer host monitorado. Por exemplo, um comando de ping pode ser configurado como script global, enquanto um comando para reiniciar o Apache quando um determinado problema for detectado deve ser configurado como um script personalizado.

Scripts no Zabbix so escritos em linguagem Perl.

Na configurao da Ao do tipo Comado Remoto, deve-se configurar a lista alvo que conter o(s) dispositivo(s) que ser(o) afetado(s) pela ao que est sendo configurada. Essa lista pode conter hosts individuais ou grupo de hosts.

Toda a configurao feita na interface grfica do Zabbix, em Configurao > Aes > Criar ao.

Se o script gerar alguma sada em modo texto que precise ser armazenada, o processo de armazenamento no banco de dados do Zabbix deve estar inserido na lgica do script. Basta entender o Zabbix Server como um sistema operacional, o banco de dados do Zabbix como um HD, e o script em execuo como um software qualquer. Para que um arquivo deste software (script) seja armazenado no HD (banco de dados do Zabbix), a lgica para esse processo deve estar contida no cdigo do software (script), no no sistema operacional (Zabbix). Portanto, armazenar a sada de um script no banco de dados do Zabbix possvel, desde que o cdigo do script em Perl faa isso.

6) Entender melhor a monitorao JAVA - JMX.

Podemos, genericamente, dizer que o JMX para o Java o que o SNMP para um ativo de rede. O JMX uma tecnologia Java que foi criada para atender a alguns requisitos nos sistemas de produo, por exemplo:

O sistema est no ar? Est funcional? Quanto de qual recurso ele est consumindo?

Normalmente, o JMX usado para monitorar aplicaes Java e servidores de aplicao, que um tipo de servidor web que disponibiliza um ambiente para a instalao e execuo de aplicaes Java, centralizando-as e dispensando a instalao de agentes especficos de monitoramento nos computadores clientes. Entre os servidores de aplicao com suporte a aplicaes Java esto Tomcat, JBoss, Glassfish.

As aplicaes Java, alm de utilizarem recursos do sistema operacional, tambm consomem recursos da JVM (Java Virtual Machine) para disponibilizar acesso aos seus aplicativos, fazer conexo a banco de dados, etc. Por isso, altamente recomendado que se monitore os servios e aplicativos Java. Por exemplo: uma aplicao pode estar travando ou mesmo deixando de iniciar por falta de memria na JVM, apesar de ter memria livre no sistema operacional. O Zabbix, pensando nisso, fornece uma interface JMX para monitoramento de aplicaes e servidores de aplicao Java.

O monitoramento de uma aplicao ou um servidor de aplicaes Java pode ser feito exclusivamente por meio do JConsole, disponvel no pacote JDK do Java. Mas, ao integrar esse monitoramento com o Zabbix, possvel criar trigger e aes de acordo com os problemas que podero surgir nas aplicaes ou no servidor de aplicaes, alm do recurso de envio de alertas por e-mail, SMS, etc.

Acredito que o monitoramento JMX possa ser considerado como um servio adicional a ser oferecido a um cliente, caso necessite.

7) Entender diferenas entre informaes disponibilizadas pelos protocolos IPMI e SNMP. Qual melhor? Testar o protocolo IPMI.

O IPMI uma interface utilizada para monitorar recursos especficos de hardware que o SNMP no consegue monitorar. Os itens disponveis por meio de agentes IPMI variam de acordo com o hardware, mas estes so os mais comuns:

Temperatura da CPU e do gabinete como um todo; Velocidade do cooler; Voltagem do sistema; Estado do disco fsico; Estado dos LEDs de manuteno; Controle de configuraes da BIOS.

Por exemplo, o IPMI pode monitorar o estado (cor) dos LEDs de manuteno e informar ao sistema de monitoramento, em texto, o que os LEDs esto indicando. Trata-se de um recurso poderoso, que trabalha diretamente com o hardware em sua linguagem de mquina, e promovido pelas empresas Intel, Dell, HP e NEC.

O IPMI usado tambm em inventrios de hardware, possibilitando ao gerente saber quando um hardware deixou de funcionar, por exemplo.

8) Confirmar se podemos criar script por data ou hora. Testar.

O Zabbix no permite, por si s, criar scripts programados, ou seja, que so executados em determinada data e hora. Para que essa possibilidade seja agregada ao Zabbix, preciso usar uma ferramenta externa que possibilite a programao de scripts. O cdigo Perl do script permanecer no Zabbix, mas estar interagindo com a ferramenta de programao. Na aba de configurao de scripts da interface grfica do Zabbix, no h modo algum de programar a execuo dos scripts por data e hora.

9) Mensagens Syslog: entender e testar se possvel armazenar no Zabbix.

Ao que parece, o Zabbix no possui funcionalidade para tratar syslogs da forma que desejamos.

10) Relatrios: confirmar se j existe pronto um relatrio de disponibilidade. Testar.

O relatrio de disponibilidade do Zabbix apresentado no prprio front-end do sistema. Na guia Reports > Availability report possvel verificar a proporo de tempo em que as triggers estiveram em estado de problem ou ok. A porcentagem de tempo para cada estado exibida. a nica forma que o Zabbix fornece para determinar a situao de disponibilidade dos elementos do sistema.

O nome da trigger linkada para os ltimos eventos dessa trigger.

Clicando em Show, exibe-se o grfico de disponibilidade da trigger em questo. A cor verde da barra determina o tempo em que a trigger esteve em estado ok, ao passo que a cor vermelha mostra o tempo em que ela esteve em estado problem.

11) Alertas SMS (modem GSM / Agenda Google). Definir se ser necessrio.

12) Entender e mapear os processos e recursos para administrar o servidor Zabbix. Backup, Base de Dados, atualizaes, etc.

13) Cisco IP SLA.

Verses do documento

Verso 1 04/03/2015Verso 2 11/03/2015Verso 3 **/03/2015