Você está na página 1de 70

UNIVERSIDADE FEDERAL DO RIO GRANDE DO SUL

INSTITUTO DE INFORMTICA
CINCIA DA COMPUTAO

RODRIGO FRAGA MOHR

Anlise de Ferramentas de Monitorao de


Cdigo Aberto

Monografia apresentada para obteno do Grau


de Bacharel em Cincia da Computao pela
Universidade Federal do Rio Grande do Sul

Taisy Weber
Orientador

Porto Alegre, Dezembro de 2012


UNIVERSIDADE FEDERAL DO RIO GRANDE DO SUL
Reitor: Prof. Carlos Alexandre Netto
Diretor do Instituto de Informtica: Prof. Lus da Cunha Lamb
Coordenador da Cincia da Computao: Prof. Raul Fernando Weber
Bibliotecria-chefe do Instituto de Informtica: Beatriz Regina Bastos Haro
S lutador quem sabe lutar consigo mesmo.
C ARLOS D RUMMOND DE A NDRADE
AGRADECIMENTOS

Agradeo ao meu pai, me e irmo, por todo o apoio e carinho durante toda a minha
vida e, em especial, nessa mais breve realizao.
A todos os meus familiares que, uns mais perto, outros mais longe, todos mostraram
confiana no meu trabalho.
A todos os meus amigos de dentro da faculdade, em especial aos do time QCB por
todo os momentos felizes passados juntos. Iremos em busca de mais campeonatos!
A todos os meus colegas de trabalho da Dell pelo entendimento da importncia desse
momento. Em especial aos meus colegas Hulbe, Lilyan e Araray pela ajuda na elaborao
do tema e conceitos.
orientadora Taisy, por toda a ajuda, preocupao e ateno dedicados nesse ltimo
semestre.
Tambm agradeo UFRGS, por todo o ensino de excelente qualidade disponibilizado
durante esses ltimos 5 anos.
Muito obrigado a todos. Vocs fizeram e fazem um papel muito importante na minha
vida e foram essenciais para a concluso deste trabalho.
SUMRIO

LISTA DE ABREVIATURAS E SIGLAS . . . . . . . . . . . . . . . . . . . . 9


LISTA DE FIGURAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
LISTA DE TABELAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
RESUMO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
ABSTRACT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1 INTRODUO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.1 Motivao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.3 Resultados Alcanados . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.4 Organizao do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2 CONCEITOS BSICOS . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.1 Servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.2 Monitorao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.2.1 Ferramentas de Monitorao . . . . . . . . . . . . . . . . . . . . . . . . 22
2.2.2 Limiar de Alerta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.2.3 Dashboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.3 Protocolos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.3.1 SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.3.2 SSH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.3.3 TELNET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.3.4 JMX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.3.5 WMI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3 APRESENTAO DAS FERRAMENTAS . . . . . . . . . . . . . . . . . 27
3.1 Critrios de Escolha . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.2 Zabbix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.2.1 Coleta de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.2.2 Deteco de Erros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.2.3 Anlise de Problemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.3 Nagios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.3.1 Coleta de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.3.2 Deteco de Erros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.3.3 Anlise de Problemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.4 Zenoss . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.4.1 Coleta de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.4.2 Deteco de Erros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.4.3 Anlise de Problemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4 COMPARAO ENTRE OS SOFTWARES . . . . . . . . . . . . . . . . 37
4.1 Critrios de Escolha . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.2 Documentao e Disponibilidade . . . . . . . . . . . . . . . . . . . . . . 37
4.2.1 Cdigo Fonte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.2.2 Fruns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.2.3 Suporte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.2.4 Instalao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.2.5 Tabela Parcial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.3 Interface com Usurio . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.3.1 Criao de Monitores . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.3.2 Estado dos Monitores . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.3.3 Grficos de Anlise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.3.4 Relatrios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.3.5 Usabilidade Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.4 Capacidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.4.1 Compatibilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.4.2 Alertas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.4.3 Escalabilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.4.4 Configurao e Personalizao . . . . . . . . . . . . . . . . . . . . . . . 55
4.5 Tabela Final . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5 ESTUDO DE CASO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.1 Configuraes Bsicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.2 Principais Indicadores . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.2.1 Ping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.2.2 Uso de CPU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.2.3 Espao Livre em Disco . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.3 Aplicao em Servidor Linux . . . . . . . . . . . . . . . . . . . . . . . . 60
5.3.1 Zabbix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.3.2 Nagios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.3.3 Zenoss . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.4 Resultado da Comparao . . . . . . . . . . . . . . . . . . . . . . . . . . 65
6 CONCLUSO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
6.1 Resultados Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
6.2 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
REFERNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
LISTA DE ABREVIATURAS E SIGLAS

CPU Central Processing Unit


CSV Comma-Separated Values
FTP File Transfer Protocol
HTTP HyperText Transfer Protocol
ICMP Internet Control Message Protocol
IETF Internet Engineering Task Force
IP Internet Protocol
IT Information Technology
JMX Java Management Extensions
MSDN MicroSoft Developer Network
NAGIOS Nagios Aint Gonna Insist On Sainthood
NRPE Nagios Remote Plugin Executor
PDF Portable Document Format
RAM Random-Access Memory
SNMP Simple Network Management Protocol
SSH Secure Shell
TCP Transmission Control Protocol
UDP User Datagram Protocol
URL Uniform Resource Locator
WMI Windows Management Instrumentation
XML Extensible Markup Language
LISTA DE FIGURAS

Figura 2.1: Modelo de Funcionamento do SNMP. Extrado de (KOCH, 2008) . . 24


Figura 2.2: Modelo de Funcionamento do WMI . . . . . . . . . . . . . . . . . . 26

Figura 3.1: Zabbix: Locais de uso. Extrado de (ZABBIX, 2012) . . . . . . . . . 28


Figura 3.2: Nagios: Chamada do plugin de checagem de Ping . . . . . . . . . . . 32
Figura 3.3: Zenoss: Descrio dos objetos modeladores. Extrado de (LINUX
WORLD MAGAZINE, 2006) . . . . . . . . . . . . . . . . . . . . . 34
Figura 3.4: Zenoss: Camadas e Arquitetura. Extrado de (LINUX WORLD MA-
GAZINE, 2006) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Figura 4.1: Zabbix: Detalhes sobre os Cursos. Extrado de (ZABBIX, 2012) . . . 38


Figura 4.2: Nagios: Detalhes sobre os vdeos tutoriais. Extrado de (NAGIOS,
2012) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Figura 4.3: Tabelas ilustradas sobre opes de suporte disponveis . . . . . . . . 41
Figura 4.4: Zenoss: Exemplo de descrdito pelos scripts de instalao. Extrado
de (ZENOSS, 2012) . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Figura 4.5: Nagios: Possveis objetos a serem criados. Extrado de (TURN-
BULL, 2006) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Figura 4.6: Zenoss: Criao de um novo monitor usando a interface . . . . . . . 45
Figura 4.7: Zabbix: Criao de um novo monitor usando a interface . . . . . . . 45
Figura 4.8: Zabbix: Visualizao do estado dos monitores . . . . . . . . . . . . . 46
Figura 4.9: Zabbix: Visualizao dos ltimos dados coletados . . . . . . . . . . 47
Figura 4.10: Nagios: Visualizao do estado dos monitores . . . . . . . . . . . . . 48
Figura 4.11: Zenoss: Visualizao do estado dos monitores . . . . . . . . . . . . . 48
Figura 4.12: Zabbix: Grficos de anlise . . . . . . . . . . . . . . . . . . . . . . 49
Figura 4.13: Nagios: Grfico de anlise . . . . . . . . . . . . . . . . . . . . . . . 50
Figura 4.14: Zenoss: Grficos de anlise . . . . . . . . . . . . . . . . . . . . . . 50
Figura 4.15: Zenoss: Opes de exportar dados . . . . . . . . . . . . . . . . . . . 51
Figura 4.16: Sistemas Operacionais Suportados . . . . . . . . . . . . . . . . . . . 53
Figura 4.17: Zabbix: Tabela ilustrativa com os requisitos de software necessrios.
Extrado de (ZABBIX, 2012) . . . . . . . . . . . . . . . . . . . . . 53
Figura 4.18: Requisitos mnimos de hardware . . . . . . . . . . . . . . . . . . . . 55

Figura 5.1: Ping para um servidor desligado . . . . . . . . . . . . . . . . . . . . 58


Figura 5.2: Alto uso de CPU . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Figura 5.3: Pouco espao livre em Disco . . . . . . . . . . . . . . . . . . . . . . 59
Figura 5.4: Zabbix: Interface aps configurao dos monitores . . . . . . . . . . 60
Figura 5.5: Zabbix: Pgina inicial em que possvel localizar o monitor falhado . 61
Figura 5.6: Nagios: Plugins instalados na verso padro . . . . . . . . . . . . . . 61
Figura 5.7: Nagios: Exemplo de configurao de um servio . . . . . . . . . . . 62
Figura 5.8: Nagios: Interface aps configurao dos monitores . . . . . . . . . . 62
Figura 5.9: Nagios: Viso Ttica mostrando um monitor alertando . . . . . . . . 63
Figura 5.10: Zenoss: Algumas das classes de eventos existentes . . . . . . . . . . 63
Figura 5.11: Zenoss: Tela inicial . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Figura 5.12: Zenoss: Alto uso de CPU e memria RAM ao iniciar . . . . . . . . . 64
LISTA DE TABELAS

Tabela 4.1: Linguagens de programao utilizadas . . . . . . . . . . . . . . . . . 39


Tabela 4.2: Endereo dos fruns oficiais . . . . . . . . . . . . . . . . . . . . . . 40
Tabela 4.3: Tempo de resposta, em horas, dos fruns oficiais . . . . . . . . . . . 40
Tabela 4.4: Disponibilidade dos Tipos de Suporte . . . . . . . . . . . . . . . . . 42
Tabela 4.5: Tabela parcial de comparao . . . . . . . . . . . . . . . . . . . . . 43
Tabela 4.6: Experimento de usabilidade . . . . . . . . . . . . . . . . . . . . . . 52
Tabela 4.7: Tipos de Alertas Possveis . . . . . . . . . . . . . . . . . . . . . . . 54
Tabela 4.8: Tabela final de comparao . . . . . . . . . . . . . . . . . . . . . . . 56
Tabela 4.9: Tabela final de comparao com anlises . . . . . . . . . . . . . . . 56
RESUMO

O uso da Internet vem crescendo cada vez mais nos ltimos anos. Estamos chegando
em um nvel que nos acostumamos com os erros cada vez mais comuns de serem vistos
nos sites e das mais variadas empresas. Para lutar contra isso, necessrio o investimento
em ferramentas de monitorao para detectar os problemas antes que o usurio perceba
que existe algo errado.
O objetivo deste trabalho avaliar e comparar trs ferramentas de monitorao de
cdigo aberto: Zabbix, Nagios e Zenoss. O mercado de ferramentas livre tambm vem
crescendo muito e esse um mercado a ser explorado e analisado com cuidado. Ter em
mos softwares gratuitos que so capazes de disponibilizar todos os recursos necess-
rios para efetivar uma monitorao precisa e simples um ponto que poder facilitar o
desenvolvimento de qualquer empresa.
Sero avaliados aqui os mais variados pontos de cada uma das ferramentas escolhidas.
Ser feita uma anlise desde o nvel de funcionamento de rede, passando pela documen-
tao existente, interface grfica e configurao da ferramenta. O objetivo ter certeza
que todas elas so capazes de efetuar as tarefas bsicas de uma monitorao com sucesso
e, ainda, compar-las para indicar qual se sobressai em cada critrio observado.
Tambm sero efetuados estudos de casos prticos onde cada uma das ferramentas
ser aplicada em um ambiente virtual para que sejam efetuadas medies de performance,
facilidade de uso e capacidade das ferramentas.
De uma maneira geral, a ferramenta Zabbix mostrou ser a mais completa de todas,
incluindo um bom poder computacional com uma interface bastante boa. O Nagios no
tem muito foco na interface mas provou ser bastante adaptvel ao facilitar o desenvolvi-
mento de plugins. Pode ser observado que o Zenoss teve um grande investimento na sua
interface grfica, que pareceu ser o foco para essa ferramenta.

Palavras-chave: Monitorao, Ferramenta Livre, Servidor, Desempenho, Falha, Inter-


face.
Analysis of Open Source Monitoring Tools

ABSTRACT

The use of Internet has been growing more and more in last years. We are reaching
a level which we are getting used to each time more common errors are being seen in
the websites of most varied companies. To fight against that, it is necessary to invest in
monitoring tools to detect problems before the user realizes there is something wrong.
The goal of this work is to analyse and compare three open source monitoring tools:
Zabbix, Nagios and Zenoss. The market of free tools is also growing a lot and this is a
market to be explored e analysed carefully. To have in hands free softwares that are capa-
ble of make available all resources necessary to make an accurate and simple monitoring
is a point that will make easier the development of every company.
The most varied aspects of the chosen tools will be validated here. It will be done an
analysis of since the behaviour in the network side, going to the existing documentation,
graphic interface and tool configuration. The goal is to make sure all of them are capable
of, with success, provide basic tasks of a monitoring and, still, compare them to indicate
which of them will be best in each observed criteria.
It will also be done case studies in which each tool will be applied to a virtual envi-
ronment so that it will be possible to measure performance, ease of use and capacity of
the tools.
In a global way, the tool Zabbix was the one that showed to be more complete, in-
cluding a good computation power with a very nice interface. Nagios does not have a big
focus on the interface but has proven to be very adaptable by making easier the develop-
ment of plugins. It was also possible to observe that Zenoss had a great investment on its
graphic interface, which seems to be the focus for this tool.

Keywords: Monitoring, Open Tool, Server, Performance, Fault, Interface.


19

1 INTRODUO

O constante crescimento da utilizao da Internet em todo o mundo faz com que, cada
vez mais, seja necessrio ter uma ateno especial s aplicaes e servidores das empre-
sas. A monitorao faz um papel essencial para que os clientes tenham uma experincia
livre de problemas acontecendo nas mquinas e aplicaes da empresa.
O mercado de ferramentas de cdigo aberto vem crescendo muito nos ltimos anos
(URLOCKER, 2009). Isso mostra o grande impulso que as ferramentas de monitorao
livres esto tendo no mercado.

1.1 Motivao
O tema do trabalho foi escolhido pois segue a linha de atividades profissionais do
autor. Trabalhar no setor de monitorao de uma grande empresa da rea de IT um
grande incentivo.
Foram escolhidas 3 ferramentas de cdigo aberto para serem analisadas: Zabbix, Na-
gios e Zenoss. Essas trs ferramentas tambm esto sendo analisadas na empresa do autor
e isso favoreceu sua escolha.
A opo por usar ferramentas de cdigo livre pela facilidade de mudana que elas
apresentam. So ferramentas que, se houver um estudo sobre a melhor maneira de usar
cada uma delas, podem desempenhar um grande papel na monitorao de uma empresa.

1.2 Objetivos
O principal objetivo analisar alguns critrios que so considerados essenciais para
uma ferramenta de monitoramento, de acordo com o autor. Facilitar a escolha entre essas
trs ferramentas uma vez que se conheam as necessidades.
Tambm um objetivo identificar oportunidades de melhorias nessas ferramentas.
Como todas elas so de cdigo aberto, isso poderia ser uma realidade plausvel.
Ao final, analisar comparativamente as trs ferramentas e chegar a concluso de qual
delas a mais completa. No ser feita nenhuma anlise voltada a alguma aplicao para
manter a investigao o mais genrica possvel.

1.3 Resultados Alcanados


A ferramenta que teve a melhor performance geral e se mostrou a mais completa foi
o Zabbix. O Nagios mostrou ser bastante completo mas com pouco investimento na parte
grfica. J o Zenoss pareceu ter muito investimento na parte grfica, o que acabou fazendo
20

ela ficar meio confusa.

1.4 Organizao do Trabalho


No Captulo 2, ser feita uma abordagem com a finalidade de esclarecer os conceitos
utilizados neste trabalho. O objetivo que o entendimento do autor sobre monitorao,
ferramentas de monitoria e os protocolos utilizados esteja bem explicado.
J no Captulo 3 haver um estudo sobre o funcionamento das trs ferramentas es-
colhidas: Zabbix, Nagios e Zenoss. O estudo foi divido em trs tpicos principais e
igualmente importantes: como acontece a coleta de informao, como os problemas so
detectados e de que forma as ferramentas auxiliam os usurios na anlises dos problemas.
Os Captulos 4 e 5 trazem uma anlise mais prtica sobre essas ferramentas. No
primeiro ser feito um estudo sobre uma srie de critrios e atributos considerados impor-
tantes para uma ferramenta de monitoria. No segundo, haver uma aplicao prtica das
ferramentas e observao dos resultados.
Para finalizar, o Captulo 6 traz um encerramento do trabalho. Tambm sero aborda-
das aqui futuras oportunidades de trabalho e aprofundamento deste estudo.
21

2 CONCEITOS BSICOS

Antes de comear a descrever o funcionamento das ferramentas de monitorao esco-


lhidas e os motivos de escolha tomados, ser formada uma base conceitual para facilitar
o entendimento deste trabalho. O objetivo aqui melhorar o entendimento de todos os
conceitos para que o autor possa se expressar com mais preciso.
Sero revistos vrios tpicos, com uma abrangncia maior do que apenas monitoria.
Haver uma introduo sobre servidores conectados em rede (como eles se comportam,
quais seus principais indicadores de performance sem especificar uma aplicao), ferra-
mentas de monitoria (o que se espera delas, como elas so comumente usadas) e alguns
protocolos de comunicao e monitorao (SNMP, SSH, WMI, entre outros).

2.1 Servidor
Um servidor de rede um computador designado para processar requisies e entre-
gar dados para outro (chamado cliente) computador em uma rede local ou na internet.
Servidores normalmente so configurados com capacidades adicionais de processamento,
memria e disco para serem capazes de lidar com a carga gerada pelos clientes. Tipos
comuns de servidores em rede incluem:
Servios de Internet (lojas virtuais, redes sociais, entretenimento digital, ...);

Proxy (Porto que faz requisies de internet no lugar de outro);

FTP (transferncia de arquivos);

Jogos online;

Bancos de Dados.
Na maioria dos casos, um servidor um computador fsico, apesar do crescimento
da utilizao de mquinas virtuais (servidor virtualmente alocado em outro, consumindo
seus recursos). Em grandes empresas, existem muitos servidores co-existindo, o que
faz com que seja necessrio utilizar tcnicas para evitar problemas fsicos (dissipao de
calor, sujeira e outros).

2.2 Monitorao
Monitorao a observao e gravao regular de atividades acontecendo em um
servidor remoto (em rede) ou local (fsico) (COLLECTIVE, 2012). um processo de
constante coleta de informaes em muitos aspectos diferentes. Monitorar checar o
22

progresso/desempenho de uma determinada atividade/comportamento. uma observao


sistemtica e muito importante.
Monitoria tambm envolve dar constantes retornos e comunicados do estado do objeto
sendo monitorado para o administrador ou usurio (PHAAL, 1994). Habilidade de gerar
relatrios um aspecto importante na tomada de decises para melhor o desempenho de
um determinado servidor.
Entre os principais propsitos da monitoria esto:

Analisar informaes;

Determinar que os recursos esto sendo utilizados da melhor maneira;

Identificar problemas nas aplicaes;

Garantir que todas as atividades so executadas de forma correta;

Facilitar a tomada de decises ao resolver problemas.

Para uma boa monitorao, essencial que exista uma ferramenta de monitorao
com uma boa capacidade de processamento de informaes. Uma habilidade importante
a capacidade de se gerar alertas, a partir da definio de limiares (chamados thresholds)
(BALIS et al., 2002).
Em algumas empresas, existem times de profissionais dedicados exclusivamente
monitorao. As pessoas que trabalham nesse time, na rea de suporte das empresas,
so as responsveis por resolver os problemas que acontecem nos servidores e que foram
detectados pela monitorao.
Para que times assim consigam trabalhar com eficincia, de extrema importncia
que a ferramenta possua um dashboard. Dashboard um painel que mostra o estado de
todos os monitores configurados.

2.2.1 Ferramentas de Monitorao


Uma ferramenta de monitorao usada para executar checagens regulares nas aplica-
es da empresa com a finalidade de detectar problemas antes que o usurio da aplicao
perceba (RAKOSHITZ et al., 2003). No mundo ideal da monitoria, nenhum usurio re-
ceberia um erro do tipo HTTP 503 (Servio Indisponvel).
Usurios de ferramentas de monitoria normalmente trabalham nas reas de suporte
das empresas, caso ela possua um setor especfico para suporte. Dessa maneira, elas tm
acesso direto ao todos os tipos de problemas que acontecem nas aplicaes dessa empresa
e esto acostumadas, e treinadas, para saber resolver os problemas.
Desse modo, a melhor maneira que um software de monitoramento pode ajudar o tra-
balho dessa pessoas ajudando a detectar o mais rpido possvel os problemas. Facilidade
de uso, rapidez de alerta e visualizao simplificada dos problemas so caractersticas de-
sejveis (NETO, 2001).
Tambm importante a possibilidade e agilidade de validar o estado atual de cada
monitor, uma vez que o usurio precisa ter certeza que o problema que estava investigando
realmente parou de acontecer.

2.2.2 Limiar de Alerta


Sem a capacidade de gerar alertas, ferramentas de monitoria perdem grande parte
de sua utilidade. Sem isso, seria necessrio que hajam pessoas totalmente dedicadas
23

utilizao das ferramentas, tendo que checar manualmente todos os monitores. Isso seria
extremamente custoso.
Um dos pontos crticos na hora de se definir um alerta a escolha de um valor limiar
(threshold). Ele ser o valor comparado com uma expresso, calculada periodicamente
para verificar o estado do monitor. Existem tambm monitores que no so apenas nu-
mricos. Um monitor pode ser usado para checar se uma determinada URL abriu corre-
tamente ao procurar na pgina por uma frase ou palavra. Como o foco deste trabalho est
na monitoria dos servidores, esse tipo de monitoria ser deixado de lado.
crucial que a escolha do valor limiar de alerta de um monitor seja bem feita. Sendo
feita uma escolha errada, o monitor poder concluir que existe um problema quando no
existe (situaes de falso-positivo). A situao contrria tambm deve ser cuidada. No
se pode relaxar muito no valor e chegar ao ponto em que haja um problema mas o monitor
determina que est tudo bem (falso-negativo).
Uma utilidade interessante de uma ferramenta de monitorao a possibilidade de
possuir um threshold dinmico. Um exemplo seria, ao invs de ter um nmero fixo, cal-
cular esse nmero a cada checagem para ver se o monitor deve alertar. Isso facilitaria a
adaptabilidade do monitor a mudanas permanentes no ambiente monitorado (um exem-
plo seria uma expanso do site, o que aumentaria o trfico nas mquinas). Infelizmente,
nenhuma das ferramentas aqui estudadas permite a utilizao de valores limiares dinmi-
cos nativamente.

2.2.3 Dashboard
Quando no for possvel a gerao de alertas, imprescindvel a presena de um
dashboard. Isso seria um painel que facilitaria a visualizao dos monitores e o estado
de cada um deles. Mesmo havendo a gerao de alertas, muito importante que haja um
lugar em que o usurio das ferramentas (pessoa que recebe os alertas) possa verificar se o
problema continua acontecendo.
muito importante que haja uma clara separao entre quais monitores esto com
problema e quais esto indicando um funcionamento correto do sistema. Isso facilitaria
as decises das pessoas responsveis por cuidar das aplicaes sendo monitoradas.
Ainda existem os casos em que a gerao de alertas no ocorre propriamente. Nesses
casos, as pessoas responsveis por cuidar dos alertas devem ficar atentas nos painis para
garantir que no existe nenhum monitor alertando sem que tenha algum trabalhando nele.

2.3 Protocolos
Aqui ser vista a maneira como cada um dos protocolos (SNMP, SSH, Telnet, JMX
e WMI) funciona a nvel de rede. Qual tipo de informao eles permitem verificar ou
acessar tambm ser um ponto importante a ser abordado.

2.3.1 SNMP
O SNMP (Simple Network Management Protocol) um protocolo para gerncia de
redes. Ele usado para coletar informaes, e at mesmo ajustar configuraes, de dispo-
sitivos ligados em rede, como servidores, impressoras, roteadores em uma rede utilizando
o protocolo IP. Ele um dos padres de operao e manuteno de protocolos para a
internet (FEIT, 1993). SNMP tem sido uma tecnologia essencial para o crescimento da
Internet.
Esse protocolo fica localizado no nvel de aplicao, utilizando UDP como para rea-
24

Figura 2.1: Modelo de Funcionamento do SNMP. Extrado de (KOCH, 2008)

lizar o transporte de informaes (CASE et al., 1990). O funcionamento do SNMP exige


que exista um gerente de SNMP que ser responsvel pela organizao da rede e centra-
lizao da informao. Alm dele, tambm dever existir um agente SNMP instalado na
mquina alvo a ser monitorada.
O protocolo funciona a partir da utilizao de trs operaes genricas, que leem ou
alteram o contedo de objetos das mquinas alvos (KOCH, 2008). As trs operaes
bsicas so:
Get: Essa a principal operao utilizada por ferramentas de monitoria. Ela permite
que o gerente consulte informaes dos agentes.
Set: Essa operao permite que o gerente modifique algum objeto do agente. Nas
ferramentas de monitoria, pode ser usada na inicializao e configurao dos atri-
butos necessrios de monitorar.
Trap: Tambm bastante usada na monitorao, essa operao permite que o agente
notifique o gerente, sem necessitar de uma requisio, de algum evento.
Atravs do envio de mensagens SNMP, ilustradas na Figura 2.1, o servidor explicita
qual objeto ele gostaria de visualizar (operao Get) e, na resposta, ele consegue visualizar
o estado daquele objeto. Para um entendimento melhor, possvel imaginar como o Disco
Rgido sendo um objeto e a requisio perguntaria qual o percentual de memria livre em
determinada partio.

2.3.2 SSH
SSH (Secure Shell) um protocolo de rede criptografado para comunicao de dados,
servios Shell remotos, execuo de comandos de maneira segura entre dois computado-
res conectados em rede (YLONEN; LONVICK, 2006). Do mesmo modo que o protocolo
25

SNMP, esse protocolo tambm exige a instalao de um servidor SSH, na mquina moni-
torando, e um agente SSH, na mquina a ser monitorada.
Esse protocolo utiliza o mtodo criptogrfico de chave pblica para autenticar com-
putadores remotos. Como o objetivo desse protocolo a comunicao protegida, neces-
sria a utilizao do transporte de dados utilizando TCP.
Basicamente, toda a informao enviada criptografada. Dessa maneira, so dimi-
nudas as possibilidades de informaes importantes (como usurio e senha) serem extra-
viadas no meio da comunicao. Uma vez que a conexo segura esteja estabelecida, o
servidor gerente pode requisitar qualquer tipo de informao sobre o agente. Isso faz com
que seja possvel cobrir uma grande quantidade de monitores diferentes.

2.3.3 TELNET
Telnet um protocolo de rede muito parecido com o SSH. Ele possibilita uma comu-
nicao orientada a texto bi-direcional utilizando um terminal virtual de comunicao. A
comunicao estabelecida atravs do Telnet no segura, diferentemente do SSH, pois
a informao no criptografada (POSTEL; REYNOLDS, 1983). Ele um protocolo
orientado a conexo, utilizando o TCP.
Diferente dos protocolos vistos anteriormente, o Telnet no exige que haja um es-
quema servidor-agente configurado. A comunicao toda feita por uma interface de
linha de comandos. Nessa linha de comandos possvel obter informaes sobre a m-
quina alvo a ser monitorada.

2.3.4 JMX
JMX (Java Management Extensions) , diferentemente do visto at aqui, uma tecno-
logia de desenvolvimento de aplicaes Java. Com a imensa utilizao de Java no mundo
todo, imprescindvel a capacidade de monitorar esse tipo de aplicao. E o Java acaba
facilitando a monitoria pelo JMX.
Utilizando o console JMX possvel extrair informaes importantes do funciona-
mento e execuo da aplicao rodando na mquina alvo. Um exemplo a obteno da
informao de quantidade de memria livre na pilha do Java. Essa uma informao
possvel de ser extrada de um console JMX.
Em outras palavras, JMX no um protocolo de comunicao nem de monitoria, e sim
uma plataforma de execuo e desenvolvimento que facilita a monitoria ao disponibilizar
informaes importantes de operao para usurios remotos.

2.3.5 WMI
WMI (Windows Management Instrumentation) a infraestrutura para gerenciamento
de dados e operaes em sistemas operacionais do tipo Microsoft Windows (MSDN,
2012). Todo computador com sistema operacional Windows instalado possui uma ins-
tncia do WMI rodando. Ele possibilita que usurios remotos possam obter informaes
sobre os servidores sem que seja necessrio logar no computador.
O WMI funciona por um esquema de classes e entidades. Cada classe pode conter
diversas entidades, que so os objetos a serem buscados para se obter informaes mais
detalhadas sobre a mquina alvo. A Figura 2.2 mostra um exemplo de uma classe e seus
objetos disponveis de serem consultados.
Isso possibilita uma grande quantidade de monitores de serem configurados, reali-
zando checagens peridicas dos servios. Entretanto, caso seja necessrio monitorar al-
26

Figura 2.2: Modelo de Funcionamento do WMI

gum atributo que no possua uma classe configurada pela Microsoft, isso vir a ser um
problema.
Agora que todos os principais conceitos foram devidamente apresentados, ser feito
um estudo mais profundo sobre cada uma das ferramentas escolhidas.
27

3 APRESENTAO DAS FERRAMENTAS

Nesse captulo, ser feito um estudo sobre as ferramentas. Na introduo de cada


ferramenta ser apresentado o seu histrico, com informaes de quando ela foi criada, o
que motivou a sua criao e quais as principais empresas utilizando essa ferramenta.
Aps uma apresentao inicial das ferramentas, ser feita uma anlise mais profunda
de como essas ferramentas trabalham. Ser detalhado como elas coletam os dados (quais
protocolos de comunicao so usados), como a deteco de erros aparece para o usurio
e como essas ferramentas auxiliam para a investigao dos erros aps a sua deteco.

3.1 Critrios de Escolha


O mercado das ferramentas de cdigo aberto est crescendo significativamente nos
ltimos anos. No s no lado de monitoria, mas em todas as reas do mercado tecnolgico
(DUBIE, 2009).
Com esse pensamento em mente, foram pesquisadas as trs principais ferramentas de
monitoramento com cdigo aberto. Outro critrio de escolha foi a procura por ferramentas
com propsitos levemente diferentes.
O Nagios foi escolhido por ser uma ferramenta voltada a usurios mais avanados, por
usar muito pouco a interface grfica e facilitar o desenvolvimento de plugins. J o Zenoss
altamente voltado para a interface grfica e compatibilidade com plugins j existentes.
O Zabbix uma mescla das outras duas, com potencial para ser a mais completa entre as
trs.

3.2 Zabbix
O projeto do Zabbix comeou a ser desenvolvido em 1998, liderado por Alexei Vla-
dishev. Trs anos aps o incio do projeto, foi feita a primeira publicao da ferramenta
j com o cdigo aberto ao pblico. Apenas em 2005, foi criada a empresa ZABBIX SIA
para fornecer servios de suporte tcnico aos seus clientes e usurios (ZABBIX, 2012).
O Zabbix possui diversos clientes de todo o mundo. Entre os principais clientes,
existem alguns brasileiros:

Dataprev;

Lojas Renner SA;

Petrobras;

Procergs;
28

Figura 3.1: Zabbix: Locais de uso. Extrado de (ZABBIX, 2012)

Serpro.

A misso dos profissionais do Zabbix desenvolver uma soluo de monitorao


superior disponvel e acessvel para todos. Um dado interessante de ser observado a
Figura 3.1. Ela mostra todos os locais em que existe uma empresa utilizando o Zabbix.
Em vermelho, a principal sede da empresa: Riga, Latvia.

3.2.1 Coleta de Dados


O Zabbix um software que utiliza o tipo servidor-agente de funcionamento, inclusive
possibilitando que mais de um servidor esteja rodando ao mesmo tempo, o que possibili-
taria uma melhor performance e maior consistncia de dados (OLUPS, 2010).
O sistema servidor conversa com o sistema agente (instalado em cada uma das mqui-
nas que devem ser monitoradas) para requisitar informaes sobre a mquina alvo. Essas
informaes so armazenadas em bancos de dados relacionais, que pode ser qualquer um
dos abaixo:

MySQL;

PostreSQL;

Oracle.

Se no houver a disponibilidade de um agente instalado na mquina a ser monitorada,


essa monitorao tambm pode ser feita utilizando os seguintes protocolos (explicados
em detalhes no captulo anterior):

SNMP;

SSH;
29

TELNET;

JMX.

Com isso, essa ferramenta se mostra bastante completa ao cobrir uma grande rea
de possibilidades de monitorao. Todos esses tipos de monitoria podem co-existir. Isto
quer dizer que podem haver monitores fazendo checagens pelos agentes instalados e, ao
mesmo tempo, outros monitores esto utilizando o protocolo SNMP de comunicao para
efetuar outras checagens.

3.2.2 Deteco de Erros


A deteco de erros e problemas acontece no servidor de processamento. As regras de
gerenciamento das informaes, como os valores limites de alerta, so armazenadas nos
bancos relacionais que ficam nas mquinas servidores.
O Zabbix permite o monitoramento online onde possvel visualizar todos os dispo-
sitivos e seus principais indicadores de problema. Monitores de performance, segurana
e utilizao de CPU e memria so facilmente acessados atravs da interface web da
ferramenta.
Um problema caracterizado por uma expresso de monitoramento, configurada atra-
vs da interface grfica, ultrapassar seu valor limite. Um valor limite pode ser definido de
muitas maneiras diferentes.
Existem vrios tipos de valores que podem ser calculados para se comparar com um
valor limite. Isso mostra um grande potencial existente nessa ferramenta, pois facilita
muito a configurao de monitores que melhor se ajustem s necessidades dos usurios.
Um erro ser detectado sempre que um valor calculado, "X", fizer a expresso "Y",
calculada a partir de "N", retornar um valor falso. O valor limite definido estaticamente
quando da criao do monitor a varivel "N". Para a expresso "Y", sua construo
pode ser de uma das seguintes maneiras:

X < N (X menor que N);

X > N (X maior que N);

X = N (X igual a N);

X <> N (X diferente de N).

Quanto aos valores de "X", existem muitas maneiras de isso ser calculado. Ainda
possvel usar a varivel "T", um valor temporal a ser definido na criao do monitor. As
principais, e mais comumente usadas, so:

Diferena entre os dois ltimos valores da expresso;

Mdia de valores dos ltimos T minutos;

ltimo valor calculado;

Maior/menor valor nos ltimos T minutos;

Soma dos valores nos ltimos T minutos;

Dia da semana/ms.
30

A expresso a ser calculada o valor do monitor em si. Um exemplo para esclarecer


esse atributo pensar no uso de CPU. Em um monitor que cuidaria disso, esse valor seria
o percentual do processador sendo utilizado.
Aps a deteco de um problema pela ferramenta, o usurio pode ser alertado de
diversas maneiras disponveis, que vo desde um alerta por e-mail at executar um script
no agente.

3.2.3 Anlise de Problemas


A ferramenta fornece diversas solues que auxiliam na investigao do usurio. To-
dos os monitores configurados podem ser observados de forma grfica. Isso quer dizer
que podem ser observadas tendncias de comportamento.
Um exemplo para utilizao disso seria o uso em um monitor de espao em disco.
Ao receber um alerta desse tipo, o usurio poderia entrar na interface da ferramenta e
verificar o estado do disco nos ltimos dias. Se a diminuio do espao livre aconteceu
em um espao curto de tempo, pode ser que seja um nico arquivo grande que foi criado
no sistema. Se o espao foi diminuindo gradualmente, pode ser que sejam arquivos de log
do sistema.
Por possuir uma interface centralizada, com todas as informaes, possvel acessar
mais de um dado ao mesmo tempo e comparar seus resultados. O software disponibiliza
diversas informaes sobre o servidor que so atualizados em tempo real, e que podem
vir a ajudar na investigao de algum problema.

3.3 Nagios
Ethan Galstad o idealizar criador da ferramenta Nagios. Em 1999, Ethan e seu time
divulgaram a primeira verso, com o nome de NetSaint. Em 2002, devido a mudanas de
estratgia, o nome foi mudado para NAGIOS, que na verdade um acrnimo recursivo
para "Nagios Aint Gonna Insist On Sainthood"(Nagios no vai insistir em santidades),
onde h uma referncia para o antigo nome, "Sainthood"(NAGIOS, 2012).
Os produtos da empresa Nagios Enterprises so usados em todo o mundo e possuem
diversos clientes que muito famosos nas suas reas de atuao:

AT&T;

McAfee;

Philips;

Siemens;

Sony;

Toshiba;

Ubisoft;

Universal;

Yahoo.
31

3.3.1 Coleta de Dados


A ferramenta Nagios no uma ferramenta feita exclusivamente para monitorao de
recursos de servidores. Ela possui diversos modos de funcionamento. O escopo deste
trabalho focar na monitorao de servidores.
Assim como o Zabbix, possvel a instalao de um agente do Nagios na mquina
alvo. Dessa maneira, a comunicao toda feita entre servidor e agente. O Agente
fica na mquina a ser monitorada esperando requisies feitas pelo servidor. Ao receber
uma requisio, por exemplo quantidade de espao livre em um determinado disco, ele
descobre a informao requisitada e retorna ao servidor.
A coleta de dados tambm pode ser feita utilizando protocolos como o SNMP e o
SSH. Nessas opes, no necessria a instalao de um agente do Nagios nas mquinas
a serem monitoradas.
Uma outra opo disponvel, que uma opo bastante utilizada, a instalao do
plugin NRPE (Nagios Remote Plugin Executor) (PERVIL, 2007). Ele instalado tanto
na mquina a ser monitorada, quando na mquina monitorando. As checagens do Nagios
so todas feitas localmente. Por isso, o NRPE se encarrega de realizar a comunicao com
o servidor remoto. A mquina servidor imagina estar rodando a requisio internamente,
pois apenas chama o plugin do NRPE, passando como parmetro o plugin a ser executado
e os parmetros adicionais necessrios para esse plugin.
O NRPE um plugin padro do Nagios, que faz a comunicao entre servidor e cli-
ente. O seu objetivo que o servidor acredite estar rodando todos os comandos local-
mente, atravs da sua verso do NRPE instalada. Toda a comunicao com o cliente fica,
dessa maneira, escondida do Nagios (IMAMAGIC; DOBRENIC, 2007).
O Nagios uma ferramenta com uma grande capacidade de modificao. Dessa ma-
neira, qualquer tipo de comunicao estabelecida utilizando plugins pode ser efetuada
com sucesso, independente do tipo de comunicao em vigor.

3.3.2 Deteco de Erros


Na execuo dos plugins do Nagios onde acontece toda a manipulao de resultados.
Na chamada de um plugin, so passados os valores limtrofes daquele monitor (chamado
no Nagios de servio). Assim, o prprio plugin processa o resultado e explicita se aquele
um resultado bom, alarmante ou ruim.
Na Figura 3.2, pode ser observada a chamada do plugin que faz a checagem se uma
mquina pode ser alcanada atravs da rede. Parmetros importantes de serem observados
so o -w"e o -c"que indicam os valores limites para indicar se um monitor est em estado
alarmante (warning) ou crtico (critical).
bom ressaltar que a definio de quais so os valores limites feita na criao do
monitor, pelo administrador do sistema.
Assim, resta apenas ao Nagios repassar ao usurio o estado notificado pelo plugin.
Isso faz com que o Nagios tenha um menor controle sobre os resultados. Pelo outro
lado, possibilita aos desenvolvedores de plugins controlarem muito bem os seus prprios
resultados.

3.3.3 Anlise de Problemas


A interface do Nagios no facilita muito a tarefa do usurio quando se deseja analisar
comportamentos e tendncias. A capacidade grfica da ferramenta no foi um ponto
investido quando do seu desenvolvimento.
32

Figura 3.2: Nagios: Chamada do plugin de checagem de Ping


33

Por outro lado, possvel a instalao de plugins que facilitam a visualizao grfica
dos eventos. Isso requer um pouco mais de investigao pelo lado do administrador da
ferramenta, mas facilitaria para os usurios.
possvel extrair os dados, mais uma vez, utilizando plugins adicionais, e manipul-
los da maneira necessria. Um ponto a ser enfatizado aqui que, com a instalao pa-
dro do Nagios, no existem muitas possibilidades de anlise dos dados. Entretanto,
estendendo-se a ferramenta com a instalao de plugins possvel tornar a ferramenta
mais completa.

3.4 Zenoss
Zenoss a mais nova das trs ferramentas aqui estudadas. Seu desenvolvimento co-
meou em 2002. Em Agosto de 2005 foi fundada a empresa Zenoss Inc, uma parceria
entre Erik Dahl (principal desenvolvedor) e Bill Karpovich (ZENOSS, 2012).
Entre seus principais clientes, encontram-se algumas grandes empresas como:

Linkedin;

Motorola;

Exrcito dos EUA;

Fora Area dos EUA;

Universidade de Chicago;

VMWare.

3.4.1 Coleta de Dados


Toda a coleta de informao do Zenoss feita utilizando os protocolo SNMP, prin-
cipalmente, e SSH. Na mquina a ser monitorada, deve ser instalado um agente desse
protocolo para que ele possa se comunicar com o servidor.
As informaes esto sempre no cliente SNMP, basta o servidor buscar essas infor-
maes. Dessa maneira, a checagem feita a partir da iniciativa do servidor que est
monitorando, ao requisitar informaes para o servidor monitorado.
Com isso, perde-se um pouco de poder de adaptabilidade, uma vez que as informaes
disponveis so as que existem no cliente. Se, para um monitor novo, deseja-se extrair
uma informao que no existia previamente configurada, talvez isso no seja possvel.
Isso tambm pode causar um problema de escalabilidade, uma vez que todos os ser-
vidores agentes devem ser reconfigurados para possibilitar a visualizao de um tipo di-
ferenciado de monitoria.
No caso de a monitorao estar voltada para uma mquina cujo sistema operacional
instalado da famlia Microsoft Windows, existe a possibilidade de utilizar o servio de
WMI para coletar as informaes necessrias.
Pelo lado do servidor, todo o gerenciamento de informaes acontece em alguns cha-
mados objetos de modelao do Zenoss. A Figura 3.3 ilustra todos os principais objetos
utilizados para realizar a modelagem de um dispositivo.
34

Figura 3.3: Zenoss: Descrio dos objetos modeladores. Extrado de (LINUX WORLD
MAGAZINE, 2006)

3.4.2 Deteco de Erros


O Zenoss todo ele estruturado pensando sempre em trs camadas (INC, 2009):
a) Usurio;
b) Dados;
c) Coleta e Controle.
A terceira camada responsvel pela coleta e controle dos dados. Nessa camada
que existe toda a comunicao com os servidores clientes que esto sendo monitorados.
A segunda camada a responsvel pelo armazenamento e processamento dos dados e
eventos. Nela que acontece toda a lgica de deteco de erros. A primeira camada a
camada visvel para o usurio, em que seu principal elemento a interface grfica.
A Figura 3.4 ilustra todas as trs camadas e os objetos (plugins) existentes em cada
uma delas. possvel observar tambm qual a funo especfica de cada plugin.
A deteco dos erros acontece no plugin chamado ZenEvents (INC, 2012). Ele possui
uma base de dados, em MySQL, com todas as informaes dos eventos j previamente
criados. Ao receber e processar as informaes dos plugins que coletam os dados, ele
armazena em seu prprio banco de dados e, aps aplicar a lgica dos eventos, informar
o estado de cada um deles.

3.4.3 Anlise de Problemas


A interface grfica do Zenoss possui diversas funcionalidades prticas para auxiliar na
visualizao e investigao dos problemas. Uma vez que o dispositivo tenha sido mode-
35

Figura 3.4: Zenoss: Camadas e Arquitetura. Extrado de (LINUX WORLD MAGAZINE,


2006)
36

lado, existem muitas informaes importantes atualizadas online que facilitam qualquer
investigao (uso de CPU/memria/disco, usurios conectados, entre outras).
Essa ferramenta tambm muito voltada para a parte grfica. Dessa maneira exis-
tem muitos grficos disponveis para o usurio acessar. Tambm existe a possibilidade
de serem configurados relatrios peridicos para serem gerados, que podem facilitar a
indicao de problemas ao investigar as tendncias de comportamento.
No prximo captulo ser feita uma comparao entre essas trs ferramentas e como
elas se comportam perante uma srie de atributos, caractersticas e critrios escolhidos.
37

4 COMPARAO ENTRE OS SOFTWARES

Este captulo abordar comparaes de uma srie de conceitos escolhidos para as


ferramentas. O objetivo principal aqui identificar pontos fracos e pontos fortes de cada
uma delas.
Se for possvel, identificar oportunidades de melhoria tambm sero ressaltadas neste
captulo.

4.1 Critrios de Escolha


As sees e subsees abaixo foram escolhidas por terem sido identificadas como os
principais atributos de uma ferramenta de monitorao. Foram feitas algumas reunies
com profissionais da rea de IT para se chegar a essa lista.
Esses critrios no so especficos de nenhuma aplicao. Eles deveriam ser comuns a
todas as ferramentas de monitoria e, nas prximas pginas, ser visto que existem muitas
oportunidades de melhoria.

4.2 Documentao e Disponibilidade


Uma vez que foram escolhidas ferramentas de cdigo aberto para serem analisadas,
de extrema importncia que elas tenham uma documentao completa. Sem isso, pode-
ria ficar muito difcil aproveitar a capacidade de personalizao que uma ferramenta de
cdigo livre possui.
Aqui ser avaliada a documentao oficial sobre cada uma das ferramentas. O que
existe nessa documentao (tutoriais, explicao da estrutura do cdigo) e como ela di-
vulgada (livro, livre na internet, pago na internet). Pontos que tambm sero considerados
a disponibilidade de treinamentos e a linguagem em que a documentao liberada.
O Zabbix possui uma ampla gama de artigos tutoriais que so disponibilizados dire-
tamente do site da ferramenta. Toda a documentao tambm est disponvel em cinco
idiomas diferentes: Ingls, Francs, Japons, Portugus e Russo.
Ainda para o Zabbix, existem diversos cursos que so realizados no mundo todo.
Detalhes sobre os treinamentos podem ser observados na Figura 4.1.
Toda a documentao do Nagios est tambm disponibilizada no site da empresa mas
toda ela em formato PDF. Isso acaba dificultando a navegao pela informao pois os
artigos encontram-se muito divididos e no existe uma clara explicao do que h em
cada um deles. Alm disso, no existem muitos artigos sobre configurao do Nagios
disponveis na internet.
Um ponto favorvel do Nagios que existem alguns tutoriais em vdeo disponibili-
38

Figura 4.1: Zabbix: Detalhes sobre os Cursos. Extrado de (ZABBIX, 2012)

Figura 4.2: Nagios: Detalhes sobre os vdeos tutoriais. Extrado de (NAGIOS, 2012)

zados com informao sobre como escrever novas partes de cdigo e uma rpida reviso
sobre a ferramenta. Eles esto exemplificados na Figura 4.2.
J o Zenoss possui uma documentao bastante atualizada sobre a ferramenta. A
documentao oficial baseada em um arquivo, tambm no formato PDF, que traz todas
as informaes sobre aquela verso da ferramenta. Entretanto, no h uma abordagem
direta quanto a problemas que podem ocorrer durante os processos executados.
Alm disso, no existem tutoriais detalhados oficiais sobre o Zenoss, nem treinamen-
tos abertos ao pblico. Tutoriais so muito importantes para pessoas comeando a usar as
ferramentas para que seja possvel usar todos os benefcios que a ferramenta dispe.
A documentao mais completa encontrada foi a do Zabbix, inclusive disponibili-
zando treinamentos ao redor do mundo. O Nagios possui diversos artigos tutoriais que
facilitam instalaes e configuraes. Sem dvida a documentao do Zenoss no muito
aprofundada e dificulta o uso da ferramenta.
39

Tabela 4.1: Linguagens de programao utilizadas


Ferramenta Linguagem de Programao
Zabbix C e PHP
Nagios Perl
Zenoss Python e Zope

4.2.1 Cdigo Fonte


O objetivo de uma ferramenta ter seu cdigo fonte disponibilizado gratuitamente que
ela possa ser modificada e analisada com mais eficcia. Para isso, necessrio entender
como o cdigo fonte est estruturado, quais linguagens foram utilizadas no desenvolvi-
mento da ferramenta, entre outros atributos. A anlise feita de agora em diante no entrar
em detalhes sobre classes, funes e atributos do cdigo. Ser uma anlise mais estrutural.
A ferramenta Nagios sem dvida a que mais facilita mudanas de cdigo. Ela
estruturada de uma maneira que novos plugins podem ser desenvolvidos sem a necessi-
dade de modificar os antigos. Os servios e monitores novos a serem configurados so
feitos para chamar uma linha de comando de um executvel, passando alguns parme-
tros conforme necessrio. Dessa maneira, para se criar novos tipos de monitores basta
desenvolv-los seguindo os padres documentados.
O cdigo fonte do Nagios foi desenvolvido em Perl. Plugins do Nagios podem ser de-
senvolvidos em qualquer linguagem de programao pois a ferramenta s est interessada
na sada do programa. Entretanto, algumas linguagens so recomendadas:

C;

Perl;

Python;

Shell;

Scripts.

Toda a estrutura do Zabbix desenvolvida em C e PHP. A estrutura do cdigo fica


mais escondida e no to aberta quanto a do Nagios mas possvel se encontrar todos
os arquivos e manipul-los uma vez que se tenha um conhecimento intermedirio de C.
Diferentemente do Nagios, a cada mudana no cdigo a aplicao deve ser compilada
novamente. No Nagios basta reiniciar o servio e as mudanas se adaptaro (a no ser
que seja uma mudana estrutural).
J o Zenoss foi a ferramenta que mostrou menos facilidade de adaptao. O cdigo
aparece muito espalhado, em diversos arquivos e existem muitas interconexes (chamadas
entre os arquivos) que no esto documentadas claramente. As linguagens de programa-
o utilizadas so o Python, majoritariamente, e o Zope.
A Tabela 4.1 traz uma comparao entre as linguagens de programao utilizadas:

4.2.2 Fruns
Os fruns so ferramentas de auxlio extremamente teis. Usurios e administradores
trabalham juntos para ajudar outros usurios e fazer com que todos possam utilizar melhor
as ferramentas.
40

Tabela 4.2: Endereo dos fruns oficiais


Ferramenta Frum
Zabbix http://www.zabbix.com/forum/
Nagios http://support.nagios.com/forum/
Zenoss http://community.zenoss.org/community/forums

Tabela 4.3: Tempo de resposta, em horas, dos fruns oficiais


Zabbix Nagios Zenoss
Perguntas Respondidas 7 10 9
Resposta mais rpida 2,6 0,4 0,05
Resposta mais demorada 1134,65 99,55 6223
Tempo mdio de respostas 229,1 6,45 39,35

Foram analisados os fruns oficiais das ferramentas, que podem ser observados na
tabela 4.2.
Foram analisadas as dez ltimas perguntas de cada um deles e foi analisado o tempo
mdio, em horas, at a primeira resposta. Os resultados encontrados podem ser observa-
dos na tabela 4.3. Foram removidos dos clculos de mdia os pontos mais rpidos e mais
lentos de cada ferramenta.
A partir dessa anlise, podemos observar claramente que o frum com participao
mais assdua dos usurios o frum da ferramenta Nagios. Todos os critrios avaliados
foram melhores no frum dessa ferramenta.
Quanto s outras ferramentas, o site do Zenoss leva uma vantagem sobre o do Zabbix.
A maioria das respostas avaliadas foram respondidas e a mdia, sem considerar os pontos
extremos, ficou muito menor que a do Zabbix.
O frum do Zabbix teve o pior resultado: algumas perguntas no respondidas (repre-
sentando 30% do total), situaes extremas longe do ideal e mdia muito alta.

4.2.3 Suporte
Um outro aspecto bastante importante de ser avaliado a disponibilidade de suporte
oficial. Fruns so apropriados mas, em alguns casos, necessrio um auxlio mais espe-
cializado. Esses casos sero avaliados agora.
Nas empresas Zabbix e Zenoss foi disponibilizada mais de uma opo de suporte.
Nesse caso, a fim de comparar pacotes de mesmo nvel comercial, foram escolhidos os
pacotes mais avanados de suporte.
Foram selecionados alguns dos tipos de suporte considerados mais importantes para
efetuar a comparao. Eles podem ser observados na tabela 4.4. A Figura 4.3 mostra mais
detalhes sobre os tipos de suporte disponvel para cada ferramenta.
Foi possvel observar que as empresas Zabbix e Zenoss possuem um suporte muito
qualificado. O suporte disponvel pela empresa Zabbix mais completo que o das outras
duas, chegando at a disponibilizar atendimento direto no prdio da empresa ou cliente.
A empresa Zabbix tambm disponibiliza treinamento profissional para administrado-
res e usurios. Quanto ao Zenoss, a opo de treinamento no est includa no pacote e
apenas para administradores.
No existe nenhum tipo de suporte mais qualificado para o Nagios. Todo o suporte
feito por contato telefnico ou digital. No h disponibilidade de treinamento nem
41

Figura 4.3: Tabelas ilustradas sobre opes de suporte disponveis

(a) Zabbix. Extrado de (ZABBIX, 2012)

(b) Zenoss. Extrado de (ZENOSS, 2012)


42

Tabela 4.4: Disponibilidade dos Tipos de Suporte


Zabbix Nagios Zenoss
Suporte Online Sim Sim Sim
Suporte Telefnico Sim Sim Sim
Auxlio em Atualizaes/Instalaes Sim No Sim
Auxlio Emergencial Sim No Sim
Visita na empresa Sim No No
Treinamento Sim No No

tratamento de problemas. Alm disso, contato telefnico s possvel durante 8 horas


dos dias de semana, enquanto que nas outras empresas esse tipo de contato era constante.

4.2.4 Instalao
Ferramentas de cdigo aberto devem ter a instalao facilitada com tutoriais uma vez
que existem muitas variveis envolvidas (cdigo, variveis de sistema, pacotes adicionais,
entre outros).
A instalao mais fcil de ser feita , sem dvida alguma, a do Nagios. Em um
sistema operacional Ubuntu, o pacote do Nagios est disponvel no sistema para download
e instalao. Basta baix-lo e instal-lo no servidor e no cliente (pacotes diferentes) e tudo
estar pronto. Todos os pacotes adicionais so instalados junto e todas as configuraes
tambm so ajustadas durante a instalao.
Aps a instalao, basta iniciar a interface web e configurar o usurio. Para novos
monitores, devem ser modificados os arquivos de configurao. Para toda a configurao
e instalao do Nagios existem timos tutoriais disponveis na internet.
Instalar e configurar o Zabbix tambm no uma tarefa muito complicada. Basta se-
guir os tutoriais oficiais disponveis no site oficial e tudo ir correr bem. O nico problema
encontrado foi alguma incompatibilidade de verses, mas que foi resolvida rapidamente
seguindo outros tutoriais disponveis no site.
O caso mais problemtico foi o do Zenoss. Instal-lo no uma tarefa fcil. Uma
mquina virtual com o servidor Zenoss disponibilizada pronta, mas ela no compatvel
com os objetivos desse estudo (instalar diretamente a ferramenta). Sem essa mquina
virtual, a segunda opo utilizar um script de instalao feito para o sistema operacional
Red Hat, que tambm no satisfaz os requisitos do trabalho (sistema operacional Ubuntu).
No sendo possvel seguir a instalao pelos meios convencionais, foi necessrio bus-
car ajuda em fruns. Foram encontrados alguns scripts de instalao mas nenhum deles
se mostrou completo. A sada encontrada foi juntar partes dos scripts para concluir a
instalao com xito.
Durante a execuo desses scripts, foram encontrados muitos erros inesperados. A
figura 4.4 ilustra bem o descrdito que os usurios tm pela facilidade da instalao. Aps
conseguir resolver um problema de instalao, um usurio diz "Esperando para ver onde
ir falhar em seguida".
Aps a instalao terminar, a configurao da interface tambm se mostrou compli-
cada. A documentao oficial existente no leva em conta que o usurio pode encontrar
falhas. Quando elas ocorrem, mais uma vez deve-se recorrer a mtodos no oficiais (f-
runs que no so do Zenoss).
43

Figura 4.4: Zenoss: Exemplo de descrdito pelos scripts de instalao. Extrado de (ZE-
NOSS, 2012)

Tabela 4.5: Tabela parcial de comparao


Zabbix Nagios Zenoss
Documentao e Disponibilidade 3 2 1
Cdigo Fonte 2 3 1
Fruns 1 3 2
Suporte 3 1 2
Instalao 2 3 1

4.2.5 Tabela Parcial


Terminada uma primeira fase de anlises, a Tabela 4.5 mostra um resumo do que foi
identificado nas ferramentas at aqui. possvel observar que a ferramenta Zenoss foi a
que teve o pior desempenho nessa fase inicial. A ferramenta Nagios leva uma pequena
vantagem sobre a Zabbix nessa primeira parte por possuir uma maior variedade de opes.

4.3 Interface com Usurio


Outro aspecto muito importante de uma ferramenta de monitorao a sua capacidade
de mostrar aquilo que monitorado para o usurio de uma forma que ele entenda. Uma
ferramenta pode ser a mais complexa possvel, mas se ela for difcil de ser usada, no
tiver uma interface grfica boa, ela no ser usada.
Nos prximos pargrafos, ser vista uma anlise da interface entre as ferramentas e os
usurios/administradores. No ser avaliada apenas a parte grfica, toda a interao com
os usurios (seja ele final, seja ele moderador) ser levada em conta.

4.3.1 Criao de Monitores


A criao de monitores pode ser feita de diferentes maneiras nas ferramentas de mo-
nitoria. As ferramentas deste estudo se enquadram em trs categorias diferentes:

1. Arquivos de Configurao;
44

Figura 4.5: Nagios: Possveis objetos a serem criados. Extrado de (TURNBULL, 2006)

2. Interface Grfica usando modelos prontos;

3. Interface Grfica e estrutura de classes.

A ferramenta Nagios se enquadra no tipo de criao de monitores utilizando arqui-


vos de configurao. A ideia principal que deve ser entendida para criar monitores para o
Nagios que todas as chamadas so chamadas do terminal. Isso quer dizer que todo o mo-
nitor implementado pode ser testado e ajustado usando o terminal de linhas de comando
do Linux.
Uma vez que o usurio, ou administrador, sabe exatamente o que deseja que o monitor
procure, basta procurar se existe um plugin pronto para isso. Essa informao est dispo-
nvel no site oficial da empresa. Se no houver nenhum plugin disponvel, existe a opo
de tentar baixar algum outro pacote que fao esse trabalho. Se nada disso funcionar, o
usurio pode desenvolver um plugin para fazer o que ele deseja.
A configurao dos arquivos segue os padres da empresa e est muito bem docu-
mentado nos tutoriais. No Nagios, um monitor chamado de servio. A figura 4.5 mostra
todos os objetos de definio que podem ser criados dentro dos arquivos de configurao
Nagios. Como eles, toda a hierarquia de servidores e monitores construda.
O Zenoss se enquadra no tipo de criao de monitores que utiliza modelos prontos
via interface grfica. Aqui segue-se o conceito de classe de eventos, em que um evento
pode herdar atributos de outros (por exemplo, o plugin utilizado). A instalao padro do
Zenoss tambm instala o pacote de plugins do Nagios. A diferena reside na forma que
esses monitores so criados. A figura 4.6 mostra a criao de um novo monitor (chamado
de evento).
Um fato importante de ser observado aqui que se o tipo de monitorao esperada
no encontrada em nenhum dos modelos prontos, deve-se desenvolver um novo modelo.
45

Figura 4.6: Zenoss: Criao de um novo monitor usando a interface

Figura 4.7: Zabbix: Criao de um novo monitor usando a interface

Isso uma tarefa mais complicada com essa ferramenta pois envolve uma interao maior
com outras partes do software.
O Zabbix possui esse mesmo problema. Ele se enquadra no tipo de criao de monitor
utilizando a interface grfica. usada uma estrutura semelhante de chamadas de classe,
o que pode ser observado na Figura 4.7.
A criao mais fcil da monitorao foi a efetuada na ferramenta Zabbix. A interface
facilita bastante a criao e modificao de monitores com o uso do Construtor de Ex-
presses, uma interface grfica criada diretamente para auxiliar na criao dos monitores
(chamados de Disparadores). O Nagios tambm se mostrou bastante simples na criao
dos monitores. Fica em desvantagem pelo fato de no possuir uma interface grfica para
isso. O Zenoss mais uma vez se mostrou com bom potencial, mas muito complicado pois
a criao dos novos eventos deveria acontecer em muitos lugares diferentes para fazer
tudo funcionar corretamente. Ainda, as interfaces encontradas no eram fceis de serem
usadas.
46

Figura 4.8: Zabbix: Visualizao do estado dos monitores

(a) Eventos

(b) Disparadores

(c) Viso Geral (d) Dashboard

4.3.2 Estado dos Monitores


A chamada monitorao via Dashboard muito importante em empresas de monitoria.
Alm de ser notificado quando um monitor identificar um problema, os usurios tambm
devem conseguir visualizar o estado dos monitores a qualquer momento. Esse objetivo
do Dashboard: visualizar o estado de todos os monitores criados, de uma maneira prtica
e rpida.
Esta subseo abordar como os monitores podem ser visualizados na interface. Di-
ferenciao de quais esto alertando, estado atual de cada monitor (inclusive os que esto
concluindo que no h nada errado) e possibilidade de rodar testes a qualquer hora so
atributos desejveis.
A ferramenta Zabbix possui uma viso bastante precisa do estado de todos os mo-
nitores. Podem ser visualizados os monitores por servidor, por hierarquia de servidores
(aspecto muito importante quando se possui uma rede grande), por hierarquia de moni-
tores (tambm importante quando se possui uma rede grande com muitos monitores) e
tambm podem ser visualizados todos os monitores configurados.
A Figura 4.8 mostra algumas das principais telas do Zabbix em que possvel vi-
sualizar o estado dos monitores. possvel observar que podemos ter diversas vises
diferentes para o mesmo monitor, o que facilita bastante a utilizao da ferramenta.
Uma funcionalidade bastante interessante do Zabbix testar o estado atual de um
monitor a qualquer hora. Se um monitor falhar e o usurio achar que resolveu o problema,
ele pode forar um novo teste do monitor para ter certeza que ele ficar bem.
Outro aspecto importante do Zabbix a possibilidade de visualizar os ltimos dados
coletados. Dessa maneira possvel verificar que tudo est sendo coletado corretamente
47

Figura 4.9: Zabbix: Visualizao dos ltimos dados coletados

e ainda verificar se os ltimos dados esto de acordo com o esperado. Isso pode ser
observado na Figura 4.9.
J no software Nagios, existe uma chamada Viso Ttica que mostra quantos servido-
res existem em cada estado. Um servidor pode estar em algum dos seguintes estados:

Fora do Ar (Down);

Inatingvel (Unreachable);

Funcionando (Up);

Pendente (Pending).

Existe tambm uma viso de todos servios e agrupamento dos mesmos por estados.
Um servio, ou monitor, pode ser classificado em:

Crtico (Critical);

Advertncia (Warning);

Desconhecido (Unknown);

OK;

Pendente (Pending).

Ao se procurar mais detalhes sobre cada um dos monitores, possvel obter vises
separando-os por estado, por servidor e por grupo de servidores. A Figura 4.10 mostra
algumas das principais telas do Nagios.
Assim como no Zabbix, o Nagios tambm disponibiliza a funcionalidade de se testar
um monitor a qualquer momento, facilitado assim a investigao. Alm disso, possvel
re-agendar a prxima vez que o monitor ir coletar dados. Isso pode ser til ao se trabalhar
com problemas de durao prolongada.
Na ferramenta Zenoss, no existe uma maneira prtica de visualizar o estado dos
monitores que no esto alertando. Existem algumas visualizaes diferentes disponveis
quando se deseja acessar os eventos (monitores, servios) que esto com problema. Elas
esto ilustradas na Figura 4.11. Existe a possibilidade de acessar relatrios que trazem os
48

Figura 4.10: Nagios: Visualizao do estado dos monitores

(a) Viso Ttica

(b) Servidores

(c) Monitores (d) Histrico de Alertas

Figura 4.11: Zenoss: Visualizao do estado dos monitores

(a) Viso com detalhes de um servidor

(b) Estado dos monitores


49

Figura 4.12: Zabbix: Grficos de anlise

(a) Grfico de uso CPU

(b) Grfico de percentual de utilizao de disco

estados dos monitores. Esse tipo de relatrio ajuda a visualizar o estado dos monitores,
apesar de no trazer muitas informaes.
Sem dvida nenhuma, a comparao das trs ferramentas coloca o Zabbix em primeiro
lugar pela facilidade de uso da interface. O Zenoss possui um alto potencial, mas no
fcil de ser usado. Por isso, a segunda melhor ferramenta o Nagios.

4.3.3 Grficos de Anlise


Uma outra funcionalidade que aumenta muito a capacidade analtica das ferramentas
a capacidade de gerao grfica. Grficos sobre os estados dos monitores, grficos
de anlise de comportamento de um determinado monitor e outros tipos de grficos so
muito importantes para uma ferramenta de monitorao. Aqui, ser realado como cada
uma das ferramentas gera grficos para auxiliar a anlise de problemas.
A ferramenta Zabbix possui uma viso grfica bastante utilizada. possvel gerar
grficos de comportamento de valor de qualquer tipo de monitor. Os grficos armazenam
o valor de um determinado monitor em determinado momento. A Figura 4.12 mostra
alguns tipos de grficos disponveis no Zabbix.
Uma funcionalidade muito importante disponvel no Zabbix a capacidade de gerar
grficos histricos. Isso permite uma anlise de comportamento que ajuda na hora de se
analisar problemas.
O Nagios no possui uma grande capacidade grfica. possvel sim gerar grficos de
50

Figura 4.13: Nagios: Grfico de anlise

Figura 4.14: Zenoss: Grficos de anlise

(a) Grfico de uso CPU (b) Grfico de percentual de utilizao de memria

anlise para ele mas eles so um pouco mais complicados de serem gerados do que nas
outras ferramentas. Alm disso, os grficos gerados so um pouco menos claros.
O Zenoss uma ferramenta muito boa para gerar alguns grficos de anlise especfi-
cos. Existem alguns grficos pr-definidos que so gerados uma vez que um dispositivo
(servidor) adicionado ferramenta. A Figura 4.14 ilustra alguns desses grficos.
Os quatro tipos de grficos enumerados abaixo so os grficos padres do Zenoss:

Mdia de Carga (Load Average);

CPU Utilization (Utilizao de CPU);

Memory Utilization (Utilizao de Memria);

Entrada e Sada (IO);

Se o usurio desejar gerar algum outro tipo de grfico, necessrio modificar o cdigo
da ferramenta para adicionar esses grficos. Entre outras palavras, no uma tarefa fcil.

4.3.4 Relatrios
A gerao de relatrios customizados facilitada por ferramentas manipuladoras de
dados, como o Microsoft Office Excel, LibreOffice Calc, entre outras. O ponto comum
entre as principais ferramentas voltadas analise de dados a existncia de tabelas de
formatao e de dados.
51

Figura 4.15: Zenoss: Opes de exportar dados

bastante normal surgir a necessidade de relatrios diferenciados dos j existentes.


Para que isso possa ser feito, existe a necessidade de extrair os dados da ferramenta de
monitorao em um formato que as ferramentas como o Excel entendam.
A ferramenta Zabbix no fornece compatibilidade para exportar os dados diretamente
no formato CSV, por exemplo. Entretanto, possvel visualizar os dados em formato de
tabela na tela e, a partir disso, colar para uma ferramenta de manipulamento de dados.
A interface do Nagios no possibilita nenhuma criao de relatrios desse tipo. No
possvel visualizar os dados em formato de tabela nem extrair diretamente no formato
CSV, por exemplo. Para se gerar relatrios de Excel, deve-se configurar plugins que iro
buscar essas informaes no banco de dados do Nagios e lidar com a compatibilidade.
O Zenoss a nica ferramenta que traz alguma compatibilidade desejada. Na rea
de manipulao de eventos, possvel extrair os dados no formato CSV ou XML. Essas
opes podem ser observadas na Figura 4.15.

4.3.5 Usabilidade Geral


Aqui ser abordada a satisfao do usurio ao navegar pela interface dessas trs ferra-
mentas.
Foram escolhidas cinco pessoas para auxiliar nesse experimento. Depois de ter todas
as ferramentas funcionando plenamente, com todos os monitores configurados, foi pedido
para que cada uma das pessoas navegasse pelas ferramentas e analisar os itens a seguir
(com notas de 1 a 5, com escala crescente de satisfatoriedade):

Qualidade dos grficos;

Navegao na interface;

Informaes sobre servidor;

Informaes sobre monitor;

Entender funcionamento de monitor.

As cinco pessoas que desenvolveram o experimento trabalham na rea da computao


mas nenhuma delas tinha tido nenhum contato com nenhuma dessas ferramentas. Aps
52

Tabela 4.6: Experimento de usabilidade


Zabbix Nagios Zenoss
Qualidade Grfica 4,2 1,6 4,6
Navegao Livre 4,4 3,4 3,6
Informao sobre Servidor 3 4 4,8
Informao sobre Monitor 2,6 3,8 1,8
Funcionamento de Monitor 1,6 2,4 1

a concluso dos experimentos, foi possvel chegar Tabela 4.6 que traz alguns aspectos
interessantes.
O Nagios e o Zenoss tiveram dois itens em que cada um deles foi eleita a melhor
ferramenta. Pode-se observar a clara distino entre as ferramentas. Nagios foi melhor
nos aspectos que envolvem o compartilhamento de informao, enquanto que o Zenoss
foi o melhor no que envolve a parte grfica.
Um aspecto relevante observado foi que o Zenoss teve um desempenho muito bom
na informao sobre servidores. Isso acontece porque, ao configurar um servidor nessa
ferramenta, ela modela o dispositivo e descobre diversos tipos de informaes sobre ele,
como quantidade de memria, sistema operacional, placas de rede, entre muitos outros.
O Zabbix mostrou ser a ferramenta mais prtica de ser usada, ao ser a melhor ferra-
menta em navegao livre.

4.4 Capacidade
At o final deste captulo, ser feita uma anlise sobre a capacidade das ferramentas
escolhidas. Ser mostrado um estudo um pouco mais detalhado sobre em que situaes
essas ferramentas funcionam corretamente, que tipos de alertas elas podem emitir e como
cada usurio pode personalizar a sua interface.

4.4.1 Compatibilidade
Antes de escolher uma ferramenta de monitoramento para utilizar em um sistema,
preciso saber se a ferramenta funciona corretamente nesse sistema. Neta subseo ser
avaliada a compatibilidade das ferramentas com os pacotes necessrios, com o sistema
operacional do servidor e do cliente.
O sistema operacional que se mostrou preferencial entre todas as ferramentas foi o
sistema Red Hat. Todos os softwares tambm mostraram preferncia por sistemas opera-
cionais do tipo UNIX. A Figura 4.16 mostra os sistemas operacionais divulgados que so
suportados oficialmente.
No caso do Zenoss, os seguintes sistemas operacionais so suportados:

Linux: Red Hat Enterprise;

Linux: Fedora;

Linux: Debian;

Linux: Ubuntu;

Linux: SUSE;
53

Figura 4.16: Sistemas Operacionais Suportados

(a) Zabbix. Extrado de (ZABBIX, 2012) (b) Nagios. Extrado de (NA-


GIOS, 2012)

Figura 4.17: Zabbix: Tabela ilustrativa com os requisitos de software necessrios. Ex-
trado de (ZABBIX, 2012)

Mac OS X.

possvel perceber que no existe a possibilidade de instalar o servidor em mquinas


com o sistema operacional Microsoft Windows em nenhuma das ferramentas. Entretanto,
em todas elas possvel monitorar uma mquina Windows remotamente.
Quanto compatibilidade de softwares necessrios para rodar os servidores, o Zab-
bix foi a ferramenta que forneceu mais detalhes de suas necessidades, que podem ser
observados na Figura 4.17.
O Nagios uma ferramenta que no exige muitos aplicativos para serem instalados
previamente. Junto com o pacote de instalao do Zenoss tambm sero instalados todos
os outros softwares necessrios para o mesmo rodar (mesmo caso do Nagios).

4.4.2 Alertas
Uma outra funcionalidade bastante importante a capacidade de gerar alertas. Em
algumas empresas, existem times focados monitorao que cuidam dos alertas gerados
(FERNANDES, 2011). Para esses times, de extrema importncia que a ferramenta de
54

Tabela 4.7: Tipos de Alertas Possveis


Zabbix Nagios Zenoss
Email Sim Sim Sim
Mensagem de Texto (SMS) Sim Sim Sim
Ligao Telefnica No Sim Sim
Script Sim Sim No

monitorao possua uma maneira de comunicar os alertas que acontecem.


Um alerta deve ser gerado sempre que um monitor estiver apontando um problema.
O monitor pode ser configurado para alertar quando ultrapassar um valor limiar fixo, por
exemplo quando o uso de CPU ultrapassar 95%.
A Tabela 4.7 mostra as possibilidades de alertas que so possveis de serem gerados a
partir das ferramentas. A possibilidade de executar um script remotamente , sem dvida
nenhuma, a mais interessante pois poderia permitir que o script arrumasse o problema
sem que fosse necessria uma interveno humana.
Um exemplo de utilizao de um script para resolver um problema pode ser dado da
seguinte maneira: suponha que existe um monitor que cuida para que um determinado
servio esteja sempre rodando. Se o monitor detectar que esse servio no est mais
executando, um script poderia ser rodado para iniciar esse servio, no sendo necessria
interveno humana para iniciar o servio.
possvel de se observar que o Nagios a ferramenta mais completa, suportando
todas as operaes. Com o Zabbix no possvel realizar ligaes telefnicas (mensagens
gravadas) e com o Zenoss no possvel a execuo de scripts.

4.4.3 Escalabilidade

Em algumas empresas, existem centenas, as vezes milhares de computadores conec-


tados em uma mesma rede. muito importante que essa imensa quantidade de computa-
dores seja monitorada. Para isso ser possvel, as ferramentas de monitoramento utilizadas
devem ser altamente escalveis.
Nos prximos pargrafos, ser feita uma investigao sobre a capacidade de nodos
(servidores) em cada uma das ferramentas. Tambm ser tentado imaginar como o au-
mento significvel do nmero de servidores (de 3 servidores para 1000, por exemplo)
impactaria na interface e visualizao da ferramenta. Essa anlise ser hipottica.
Todas as ferramentas apresentaram uma boa documentao quanto aos requisitos m-
nimos de hardware que devem existir a medida que a rede de servidores monitorados for
crescendo. As tabelas podem ser encontradas na Figura 4.18.
Pode ser observado que o Zenoss , claramente, a ferramenta que mais consome os
recursos da mquina. Ela a que mais necessita espao em disco e memria RAM para
conseguir rodar satisfatoriamente.
Quanto ao impacto na interface das ferramentas, isso no parece ser um problema
para o Zabbix e o Zenoss. Elas so bastante estruturadas e possuem reas distintas para
monitores, servidores e problemas. J no Nagios, ao utilizar a interface padro, isso
poderia ser um problema pois todos os objetos ficam listados no mesmo lugar, o que
tonaria a visualizao muito poluda.
55

Figura 4.18: Requisitos mnimos de hardware

(a) Zabbix. Extrado de (ZABBIX, 2012)

(b) Nagios. Extrado de (NAGIOS, 2012)

(c) Zenoss. Extrado de (ZENOSS, 2012)

4.4.4 Configurao e Personalizao


Nesta parte do trabalho, ser avaliada a capacidade de adaptabilidade e personalizao
das ferramentas. As maneiras que o usurio tem de configurar a interface do programa
(sem ter de modificar o cdigo) para fazer com que a ferramenta se adeque s suas neces-
sidades.
A interface do Nagios no facilmente manipulada. Ela possui vrias restries de
uso e foi a que menos mostrou adaptabilidade nesse quesito.
J as interfaces do Zabbix e do Zenoss se mostraram bastante fceis de serem reconfi-
guradas. Em ambas as ferramentas possvel re-ordenar os elementos grficos. Tambm
possvel adicionar e remover os elementos disponveis em outras partes do programa na
pgina inicial, o que acaba facilitando a navegao.
A configurao da interface do Zenoss se mostrou um pouco melhor de ser configu-
rada do que a do Zabbix pois so disponibilizadas mais opes para o usurio.

4.5 Tabela Final


Nesse captulo, foram mostrados diversos atributos e critrios para avaliar as ferra-
mentas. Foram obtidos muitos resultados diferentes em cada uma das anlises. Agora
ser feita uma tabela comparativa trazendo todos os resultados.
De maneira a simplificar a visualizao dos resultados, ser feito um ranking da fer-
ramenta com melhor performance em cada um dos resultados, sendo que cada ferramenta
ser dada uma nota de 1 a 3, sendo 1 a pior ferramenta para aquele quesito e 3 a melhor
ferramenta. A Tabela 4.8 traz o resultado da comparao final entre as ferramentas e todos
os critrios avaliados.
Observando a Tabela 4.9 possvel identificar que a ferramenta Zabbix se mostrou a
mais completa. Ela um misto de interface grfica boa e muitas funcionalidades interes-
santes.
56

Tabela 4.8: Tabela final de comparao


Zabbix Nagios Zenoss
Documentao e Disponibilidade 3 2 1
Cdigo Fonte 2 3 1
Fruns 1 3 2
Suporte 3 1 2
Instalao 2 3 1
Interface com Usurio 3 1 2
Criao de Monitores 3 2 1
Estado dos Monitores 3 2 1
Grficos de Anlise 3 1 2
Relatrios 2 1 3
Usabilidade Geral 1 2 2
Capacidade 1 3 2
Compatibilidade 1 2 2
Alertas 2 3 1
Escalabilidade 3 1 2
Configurao e Personalizao 2 1 3

Tabela 4.9: Tabela final de comparao com anlises


Zabbix Nagios Zenoss
Mdia 2,1875 1,9375 1,75
Vezes Melhor 7 5 2
Vezes Pior 4 6 6

Em segundo lugar na avaliao fica a ferramenta Nagios. Ela mostrou ser uma fer-
ramenta muito adaptvel, apesar de exigir um usurio mais avanado que no precise
utilizar tanto a interface grfica.
O Zenoss ficou na ltima colocao. Apesar de sua interface grfica extremamente
poderosa, essa ferramenta se mostrou inferior s outras justamente por causa da dificul-
dade de uso. Ela bastante grande, incluindo at os plugins do Nagios, mas que precisa
ter sua manipulao de informaes melhorada.
No prximo captulo ser feita uma anlise de um estudo de caso. Ser feita uma abor-
dagem prtica ao instalar e configurar as ferramentas e monitores. Sero medidos fatores
para ter certeza que as ferramentas atendem os requisitos mnimos de funcionalidade.
57

5 ESTUDO DE CASO

Para comparar a eficincia e a praticidade dos softwares apresentados, estudos de


caso foram elaborados a partir de um objetivo inicial: monitorar um determinado servio.
Foram analisadas as principais propriedades de cada um deles fazendo testes que foraram
que os monitores falhassem.
Todas as ferramentas foram instaladas em mquinas virtuais criadas utilizando o soft-
ware gerenciador de mquinas virtuais Oracle VM Virtual Box. Esse programa foi insta-
lado em um notebook com a seguinte configurao:

Processador: Intel Core i7-2640M 2,80 GHz;

Memria RAM: 6 GB;

Memria Disco: 685 GB;

Sistema Operacional: Windows 7 Professional.

5.1 Configuraes Bsicas


As simulaes ocorreram da seguinte forma: uma mquina virtual foi configurada
com uma das ferramentas de monitorao e outra foi configurada para ser o servidor
monitorado. Foram configuradas 6 mquinas virtuais (duas para cada ferramenta). Cada
mquina virtual teve a seguinte configurao:

Processador: Intel Core i7-2640M 2,80 GHz;

Memria RAM: 2 GB;

Memria Disco: 20 GB;

Sistema Operacional: Ubuntu 12.04.

As ferramentas instaladas esto na seguinte verso:

Zabbix 2.0.3;

Nagios 3.2.3;

Zenoss 4.2.0.
58

Figura 5.1: Ping para um servidor desligado

5.2 Principais Indicadores


Nas subsees a seguir, sero descritos alguns dos principais indicadores de que um
servidor est funcional. O objetivo deste trabalho no analisar nenhuma aplicao espe-
cfica. Por isso, os indicadores escolhidos so os mais gerais possveis.
Para cada um dos fatores descritos abaixo, foi configurado um monitor nas 3 ferra-
mentas escolhidas. Foram simuladas situaes diversas em que esses monitores deveriam
detectar um problema para se confirmar a eficincia da monitorao.

5.2.1 Ping
O Ping um utilitrio de administrao de redes de computadores utilizado para testar
se um servidor alcanvel por outro atravs da Internet. O Ping opera mandando uma
mensagem que utiliza o protocolo ICMP (Internet Control Message Protocol) para um
determinado servidor e analisa e resposta (ou a falta dela) (HALABI, 1997).
O protocolo ICMP foi criado com o intuito de padronizar a confirmao (ou nega-
o) de que um mensagem foi recebida (SILVA CARISSIMI; ROCHOL; GRANVILLE,
2009). Dessa maneira, o servidor que possui a ferramenta de monitorao instalado es-
tar, atravs do comando de Ping, validando se a outra mquina est acessvel.
Se um problema desse tipo acontecer, significa que o servidor cliente, que est com a
aplicao monitorada rodando, no est acessvel atravs da Internet. Ou seja, a mquina
est desligada, trancada ou com problemas de rede. Esse um problema muito grave pois
inutiliza totalmente a mquina.
Um exemplo de problema de Ping pode ser observado na Figura 5.1. Nessa Figura, um
servidor est tentando validar deu caminho at outra mquina mas no consegue porque
ela est desligada.
No contexto deste trabalho, para testar a monitorao sobre o Ping de uma mquina
virtual basta desligar a mquina virtual (se fosse em um ambiente real, isso significaria
desligar a mquina).

5.2.2 Uso de CPU


Um monitor que cuida do uso de CPU de um computador extremamente importante.
Um monitor desse tipo cuida para que o processador da mquina no seja usado por muito
tempo perto do seu limite.
Um computador que fica muito tempo rodando com o uso do processador em 100%
tem grandes chances de comear a apresentar falhas, uma vez que as operaes comearo
a acumular e podem no ser processadas corretamente.
Monitores desse tipo funcionam com valor setado de limiar. O monitor alertar sem-
pre que o percentual de utilizao do processador ultrapassar esse limiar. Esse percentual
pode ser medido estaticamente (uma nica amostra) ou pode ser medido como uma mdia
dos ltimos minutos (mais de uma amostra).
Um exemplo de mquina com alto uso do processador pode ser encontrado na Figura
59

Figura 5.2: Alto uso de CPU

Figura 5.3: Pouco espao livre em Disco

5.2. Nela, podemos observar que o uso do processador chegou a 100%. Por causa disso,
a mquina fica extremamente lenta e muito difcil de ser usada.
Entretanto, a maneira mais prtica de testar a corretude de um monitor de uso de CPU
diminuindo o limite de utilizao. Por exemplo, se o monitor est configurado para
alertar sempre que o uso de CPU estiver acima de 95%, basta baixar esse valor para 0%.
Depois que o monitor for validado, o valor limite pode ser restaurado ao valor inicial.

5.2.3 Espao Livre em Disco


O avano tecnolgico e o constante progresso do desenvolvimento de processamento
de dados vem resultando num crescente volume de dados a serem gerenciados (SIL-
VEIRA, 2012). Fica cada vez mais importante monitorar a quantidade de memria dis-
ponvel nas mquinas.
Muitas tecnologias comerciais salvam muitos arquivos de logs de execuo. Esses
arquivos podem chegar a ocupar centenas de Mega Bytes por dia (SCHAEFER et al.,
2008). Com isso, vemos um grande problema que a gerncia e controle desses arquivos.
Se faltar espao no disco no cliente para salvar algum dado importante para uma
aplicao especfica, pode ser que essa aplicao comece a no mais responder at que
haja espao em livre para salvar os logs ou arquivos (KAMIN, 1988).
Assim, monitores com essa funcionalidade so configurados para alertar caso o per-
centual de espao em disco livre fique menor que um determinado valo limtrofe. O
objetivo que o administrador do servidor tenha tempo de remover arquivos que no so
mais necessrios.
Um exemplo de problema pode ser encontrado na Figura 5.3. Aparentemente isso no
gera nenhum problema imediato na mquina. No entanto, a medida que as aplicaes
comeam a rodar e salvar seus logs e arquivos, problemas comeariam a ser vistos por
no haver onde salv-los. Os prprios arquivos de log do sistema operacional (Windows,
Linux) passam a ser problema nesses casos.
60

Figura 5.4: Zabbix: Interface aps configurao dos monitores

Para confirmar que esse monitor est configurado corretamente possvel mudar do
mesmo modo que no item anterior: temporariamente diminuir o limiar para 0%.

5.3 Aplicao em Servidor Linux


Nos pargrafos abaixo, ser descrito como cada um dos indicadores descritos acima
foram implementados nas ferramentas. Ser possvel observar as diferentes possibilidades
de monitorao existentes visto que cada um dos programas utiliza um mtodo diferente.
Aps a configurao dos monitores, o problema ser simulado segundo indicado an-
teriormente (para cada um dos indicadores existe uma maneira diferente de simular o
problema). Ser analisado o desempenho das ferramentas durante a deteco das falhas,
bem como a visualizao das mesmas na interface e os alertas gerados.

5.3.1 Zabbix
A criao de monitores no Zabbix feita atravs da interface. Para criar cada um dos
monitores acima basta selecionar um dos modelos pr-configurados no sistema, escolher
qual a frequncia do monitor e o valor limite.
Aps a criao dos trs monitores, chega-se tela que pode ser observada na Figura
5.4. Nela podemos observar o estado de cada um dos novos monitores criados, bem como
a severidade deles e a indicao de eles estarem alertando ou no.
Seguindo os modelos descritos previamente para simular uma situao de falha, foi
possvel observar que o Zabbix alertou dentro do tempo esperado (frequncia definida
para cada alerta).
A visualizao dos monitores em estado de erro pode ser observada na tela inicial do
Zabbix, mostrada na Figura 5.5. Como pode ser observado, j nesta tela inicial possvel
obter informaes importantes como a quanto tempo o problema est acontecendo e qual
o servidor com problemas.
Uma funcionalidade que facilita a investigao do usurio a possibilidade de, utili-
zando a interface, descobrir o estado do monitor a qualquer momento. Isso faz com que a
investigao seja mais rpida.
Durante a execuo dos testes a mquina virtual no apresentou significativas mudan-
as de performance, permanecendo com uso de CPU constante em 35% e uso de memria
61

Zabbix

Figura 5.5: Zabbix: Pgina inicial em que possvel localizar o monitor falhado

Figura 5.6: Nagios: Plugins instalados na verso padro

em 23%.

5.3.2 Nagios
Para criar os monitores na ferramenta Nagios, necessrio modificar os arquivos de
configurao do mesmo. No pacote padro de instalao desse programa, no existe uma
interface que facilite a configurao de novos monitores. Tudo deve ser feito utilizando
os arquivos de configurao. Apesar de no ter uma interface de configurao amigvel,
o Nagios fcil de ser configurado uma vez que se sabe onde todos os arquivos esto e
quais devem ser modificados.
Todos os comandos executados pelo Nagios so, na verdade, linhas de comando que
chamam plugins. Muitos plugins so instalados junto com o pacote padro. Todos os
monitores implementados para esse trabalho foram encontrados nos pacotes padres. A
Figura 5.6 mostra alguns desses pacotes.
Para configurar os monitores, devem ser criados servios que iro chamar os plugins.
A declarao e sintaxe desses servios deve seguir os padres estabelecidos pelo Nagios.
A Figura 5.7 mostra a configurao do servio de Ping que foi configurado.
Estando todos os novos monitores prontos nos arquivos de configurao, ainda pre-
62

Figura 5.7: Nagios: Exemplo de configurao de um servio

Figura 5.8: Nagios: Interface aps configurao dos monitores

ciso reiniciar o servio do Nagios para que as mudanas tenham efeito. Nota-se aqui que
as mudanas custam um pouco mais de tempo para serem efetuadas e refletir no sistema.
Aps a criao dos trs servios, chega-se a uma tela que possui dados de todos os
monitores criados. Essa pgina pode ser visualizada na Figura 5.8. Da mesma maneira
que com a ferramenta Zabbix, a monitorao tambm pode ser feita a partir dessa tela,
pois temos os detalhes do estado atual de cada um dos monitores.
Utilizando um dos mtodos para simular uma situao de falha, pode-se observar que
essa ferramenta teve um tempo de atualizao um pouco superior ao esperado. O intervalo
em que a pgina atualiza um valor fixo pr-determinado que no pode ser modificado e
acabou sendo maior do que a frequncia dos monitores criados. Entretanto, alertas foram
disparados no momento correto. A Figura 5.9 permite a visualizao da chamada "Viso
Ttica da Monitorao"do Nagios. Nessa pgina podemos visualizar o estado de todos os
servidores configurados bem como todos os servios.

5.3.3 Zenoss
Toda os monitores do Zenoss so configurados, assim como no Zabbix, pela interface
grfica. A primeira parte para se configurar um monitor cadastrar o dispositivo (servi-
dor) na ferramenta. Essa ao traz uma grande vantagem para o usurio pois, ao fazer isso,
o Zenoss ir automaticamente modelar a mquina alvo utilizando seus plugins. Com isso,
ser possvel obter diversas informaes e grficos importantes sobre cada dispositivo.
A criao dos monitores deve ser feita utilizando alguma das classes de evento exis-
tentes (uma classe representa um plugin). Algumas das classes existentes podem ser
visualizadas na Figura 5.10. A partir da seleo de uma classe, possvel escolher uma
sub-classe dessa classe, havendo a disponibilidade. A hierarquia de classes e sub-classes
pode ser to grande quando se queira.
63

Figura 5.9: Nagios: Viso Ttica mostrando um monitor alertando

Figura 5.10: Zenoss: Algumas das classes de eventos existentes


64

Figura 5.11: Zenoss: Tela inicial

Figura 5.12: Zenoss: Alto uso de CPU e memria RAM ao iniciar

Aps a configurao e criao dos eventos, foi possvel observar que faltou um pouco
de comunicao do estado das solicitaes. A nica maneira encontrada de se certificar
que os eventos realmente haviam sido criados com sucesso foi partir para a fase de testes.
A tela inicial do Zenoss, observada na Figura 5.11, pode ser configurada para mostrar
a localizao fsica das mquinas (utilizando plugin do Google Maps). Nessa Figura
possvel observar a visualizao do usurio quando existe um monitor em estado de falha.
Neste estudo, foi possvel observar que o Zenoss alertou sobre a falha do monitor
dentro do tempo esperado, no apresentando nenhum problema a partir dessa parte. Foi
possvel retornar o monitor ao estado normal sem grande esforo.
Um fato importante observado neste experimento foi a grande quantidade de CPU
e memria RAM utilizados pelo Zenoss no servidor. A Figura 5.12 mostra o gradual
aumento do uso de memria quando o Zenoss comea a ser utilizado na mquina que est
efetuando a monitorao. Esse comportamento no foi observado nas outras ferramentas.
65

5.4 Resultado da Comparao


De todas as ferramentas, a que mostrou o melhor desempenho durante todos os testes
foi a ferramenta Zabbix. Mais uma vez ela mostrou ser bastante completa e precisa. A
configurao dos monitores foi bastante intuitiva, sempre utilizando a interface grfica do
programa.
O software Nagios tambm teve um desempenho bastante satisfatrio. Apesar de a sua
configurao no ser to simples e fcil quanto do Zabbix, para usurios acostumados a
us-la ela mostrou ser eficiente. Foi a ferramenta que menos utilizou recursos da mquina
em que estava instalada, devido pouca utilizao da interface grfica.
O Zenoss mostrou, mais uma vez, ter um potencial bastante bom. possvel utiliz-
lo em conjunto com o Google Maps e diversos outros plugins para tornar a experincia
do usurio a mais agradvel possvel. Entretanto, talvez ao tentar ser muito completa,
a interface acabou ficando difcil de entender e nada simples de ser utilizada. O alto
consumo dos recursos da mquina servidor tambm pontuam contra essa ferramenta.
66
67

6 CONCLUSO

Esse estudo mostrou a importncia de uma empresa que tm seus servios voltados ao
cliente (por exemplo, uma empresa de jogos online) possuir uma ferramenta de monitora-
mento completa. importante que ela possa se comunicar facilmente com seus usurios
e ainda ajud-los nas anlises que eles tm de fazer.
Mais que isso, um bom software de monitoria deve ser completo e capaz de realizar
o tipo de monitorao exigida pelas aplicaes das empresas. Em um ambiente estabele-
cido, a monitorao deve se adaptar a ele para obter os melhores resultados.

6.1 Resultados Finais


Durante esse estudo, foi possvel observar claramente o foco que cada uma das fer-
ramentas recebeu em seu desenvolvimento. O Nagios foi uma ferramenta que mostrou
ser facilmente adaptvel e melhorada, por sua facilidade de receber novos plugins. In-
clusive o desenvolvimento desses plugins bastante facilitado por uma comunidade ativa
bastante grande.
A ferramenta Zenoss foi a que mostrou o pior desempenho entre as trs. Ela se mos-
trou extremamente complicado de instalar e configurar, com uma interface muito bonita
mas com baixa usabilidade. O Zabbix, pelo contrrio, foi a ferramenta mais completa.
Possui uma interface grfica muito boa e tambm capaz de ser utilizada de muitas ma-
neiras diferentes.

6.2 Trabalhos Futuros


Uma possibilidade de aumentar o escopo deste trabalho a incluso e comparao
com ferramentas vendidas comercialmente. Medir suas performances e comportamentos
seria bastante interessante de ser observado para saber se seria melhor apostar em uma
ferramenta livre ou em uma paga.
Outra oportunidade de melhoria deste trabalho seria um estudo mais detalhado so-
bre os tipos de monitores disponveis de serem configurados. A possibilidade de existir
monitores que sigam uma srie de passos em uma pgina da internet, por exemplo,
uma habilidade bastante interessante para uma ferramenta de monitorao e sem dvida
a deixaria mais completa.
68
69

REFERNCIAS

BALIS, B.; BUBAK, M.; FUNIKA, W.; SZEPIENIEC, T.; WISMLLER, R. An In-
frastructure for Grid Application Monitoring. In: Recent Advances in Parallel Virtual
Machine and Message Passing Interface. [S.l.]: Springer Berlin Heidelberg, 2002.

CASE, J.; FEDOR, M.; SCHOFFSTALL, M.; DAVIN, J. Simple Network Management
Protocol (SNMP). [S.l.: s.n.], 1990.

COLLECTIVE, C. E. http://cec.vcn.bc.ca/cmp/modules/mon-wht.htm. 2012.

DUBIE, D. Cheap Tools to Try During Tough Times. PC World, [S.l.], 2009.

FEIT, S. M. SNMP: a guide to network management. [S.l.]: McGraw-Hill Professional,


1993.

FERNANDES, L. A Importncia da Monitorao de Desempenho das Aplicaes


Web com Foco no Negcio. 2011.

HALABI, B. Internet Routing Architectures. [S.l.]: Cisco Systems, 1997.

IMAMAGIC, E.; DOBRENIC, D. Grid infrastructure monitoring system based on Na-


gios. In: GRID MONITORING, 2007., 2007. Proceedings. . . [S.l.: s.n.], 2007.

INC, Z. Zenoss Administration 2.3. [S.l.: s.n.], 2009.

INC, Z. Zenoss Core Administration 4.2. [S.l.: s.n.], 2012.

CIENTFICOS EDITORA, L. T. e (Ed.). Disco Rgido no PC. [S.l.]: Sybex, 1988.

KOCH, M. Uma Proposta de Soluo de Gerenciamento de Contabilizao utilizando


Nagios e Cacti. 2008.

Linux World Magazine. [S.l.]: SYS CON, 2006. v.4, n.4.

MSDN. http://msdn.microsoft.com. 2012.

NAGIOS. http://www.nagios.org/. 2012.

NETO, F. H. G. Guardio: uma ferramenta para monitorao de servios e servidores de


rede. 2001. Dissertao (Mestrado em Cincia da Computao) Universidade Federal
do Rio Grande do Sul.

OLUPS, R. Zabbix 1.8 Network Monitoring. [S.l.: s.n.], 2010.


70

PERVIL, M. Using Nagios to monitor faults in a self-healing environment. Seminar on


Self-Healing Systems, University of Helsinki, [S.l.], 2007.

PHAAL, P. Network Monitoring Device and System. [S.l.: s.n.], 1994.

POSTEL, J.; REYNOLDS, J. Telnet Protocol Specification. RFC 854.ed. [S.l.]: ISI,
1983.

RAKOSHITZ, G.; VAID, A.; PANDIT, A.; PUTTA, S. Traffic Monitoring Tool for
Bandwidth Management. [S.l.: s.n.], 2003.

SCHAEFER, K.; COCHRAN, J.; FORSYTH, S.; BAUGH, R.; EVEREST, M.; GLEN-
DENNING, D. Professional IIS 7. [S.l.]: wrox, 2008.

SILVA CARISSIMI, A. da; ROCHOL, J.; GRANVILLE, L. Z. Redes de Computadores.


[S.l.]: Bookman, 2009.

SILVEIRA, R. P. Novas Metodologias para Compresso de Dados de Processos e


para o Ajuste do Sistema PI. 2012. Dissertao (Mestrado em Cincia da Computao)
Universidade Federal do Rio Grande do SUl.

TURNBULL, J. Pro Nagios 2.0. [S.l.: s.n.], 2006.

URLOCKER, Z. How open source gains market share. Info World, [S.l.], 2009.

YLONEN, Y.; LONVICK, C. The Secure Shell (SSH) Protocol Architecture. RFC
4251.ed. [S.l.]: Cisco Systems, Inc, 2006.

ZABBIX. http://www.zabbix.com/. 2012.

ZENOSS. http://www.zenoss.com/. 2012.