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 Nable: 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
informaes de monitoramento e o envio conjunto dessas informaes
servidor Zabbix recebe o nome de Arquitetura Distribuda. A utilizao
proxies fundamental quando se deseja organizar um sistema
monitoramento centralizado.

de
ao
de
de

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.
2.
3.
4.
5.

Comandos IPMI;
Script personalizado;
Comandos SSH;
Comandos Telnet;
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 frontend 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/2015
Verso 2 11/03/2015
Verso 3 **/03/2015