Artigo - NMS

Implantao de um NMS Network Monitoring System
num Ambiente Corporativo

Cristiano Goulart Borges, Alexandre Timm Vieira
ULBRA - Universidade Luterana do Brasil Curso de Redes de Computadores
cgborges@gmail.com, xanditv@gmail.com
Resumo. O objetivo deste artigo desenvolver um estudo sobre a implantao

de um Network Monitoring System (NMS) ou Sistema de Monitoramento de
Redes num ambiente corporativo. Sero explorados conceitos sobre o
gerenciamento de redes, por que as redes devem ser gerenciadas, benefcios
trazidos por um sistema de gerenciamento, mtricas de gerenciamento,
posicionamento dos servidores, tipos de administrao, possveis recursos a
serem monitorados, escalonamento de notificaes, MIBs e SNMP, e demais
aspectos relevantes a implantao eficiente de um NMS. Por fim, ser
apresentado o Nagios como ferramenta de monitoramento e sua aplicao
num ambiente real, destacando sua funo de monitoramento dos servios de
rede (SMTP, POP, HTTP, entre outros), instalao e configurao do SNMP,
NRPE, e a modelagem de windows scripts files e plugins que retornam
clculos baseando-se em valores buscados das MIBs dos equipamentos.
Introduo
So 3:00hs da manh, quando o administrador de uma rede despertado pelo toque do

telefone. o help-desk da filial chinesa, informando que os usurios no conseguem
emitir notas fiscais e que o diretor da filial de Pequim est precisando urgentemente dos
relatrios do sistema de Business Inteligence (BI) ou Inteligncia de Negcios, que
por razes desconhecidas, tambm no podem ser gerados. Depois de conectar-se
remotamente, o administrador descobre aps uma hora executando diagnsticos, que o
disco rgido no qual uma base de dados Oracle central armazena seus arquivos de log
atingiu sua capacidade total, indisponibilizando o servio. Depois de liberar espao em
disco e rodar testes que confirmam que o banco est operacional novamente, o
administrador volta a dormir.
A situao relatada hipottica, mas perfeitamente passvel de acontecimento no
cenrio atual. Com a necessidade das empresas de terem cada vez menos colaboradores
executando mais tarefas, comum o pessoal de TI estar geograficamente distante dos
sistemas e aplicaes os quais administram. Sendo assim, nenhum departamento de TI
consegue efetivamente custear a checagem manual regular de todos os seus sistemas,
arquivos de log, configuraes e variveis. Principalmente porque esses sistemas esto
cada vez mais complexos e altamente configurveis. Faz-se ento necessrio o uso de
ferramentas que monitorem e gerenciem os dispositivos crticos que fazem parte do
ambiente computacional da empresa. Ferramentas que detectem falhas, problemas de
performance entre outras anomalias e alertem os responsveis por esses sistemas para
que uma atitude corretiva possa ser tomada em tempo hbil.
1
Ao invs de ter recebido uma ligao as 3:00hs da manh, o administrador da

rede do exemplo anterior poderia ter recebido a seguinte mensagem via pager ou
celular: 31/08/08 03:00AM C:\ drive on Server ORACLE_LOG reached 95%. O
tempo perdido para rever arquivos de log, analisar possibilidades, diagnosticar e corrigir
o problema seria reduzido drasticamente. O problema, alis, sequer aconteceria, pois o
administrador seria avisado com antecedncia de uma possvel irregularidade e tomaria
as medidas necessrias para evit-lo. No importa se a causa do problema foi
maliciosa ou acidental, um dia o seu sistema vai falhar. Quando isto acontecer,
somente duas coisas podero salv-lo do downtime: redundncia e o monitoramento
dos seus sistemas (Josephsen, 2007, p. xix).
Tendo isso em vista, a implantao de um Network Monitoring System (NMS)
ou Sistema de Monitoramento de Redes engloba a aplicao de conceitos que sero
abordados no presente artigo. No Captulo 2 ser conceituado o gerenciamento de
problemas, as vantagens do uso de um NMS, atividades de monitoramento e controle, as
reas funcionais de gerncia, os tipos de administrao que podem ser aplicadas,
notificaes e escalonamentos, redundncia e tolerncia a falhas e, finalmente, a
apresentao do NAGIOS como um NMS completo que tende a satisfazer as
necessidades de empresas de todo porte. No Captulo 3 ser apresentado em detalhes um
ambiente real onde o NAGIOS foi implementado, quais ativos dessa rede foram
monitorados, como est estruturada, quais atividades e tipos de gerenciamento foram
implementados, qual o equipamento disponvel e aspectos gerais sobre a modelagem da
implantao no ambiente proposto. No Captulo 4 sero exibidas as configuraes dos
gerentes e agentes nos dispositivos, como foi realizada a instalao do SNMP e do
NRPE, como foram montados os scripts que buscam valores das MIBs dos
equipamentos, os arquivos de configurao do Nagios, como foi configurado o
monitoramento remoto e as notificaes, alm das configuraes de monitoramento de
servios como e-mail, ftp, web, dns, smtp, pop, dhcp, entre outros.
Fundamentando um NMS
Um Sistema de Gerenciamento de Redes baseia-se no conceito de que problemas, cedo

ou tarde acontecero na rede caso esta no esteja sob constante monitoramento. Logo,
antes que seja visto o conceito de NMS, importante que se saiba que o correto
gerenciamento dos problemas tambm ter reflexos positivos no que tange a sade da
rede, possibilitando recuperar-se rapidamente de falhas.
O conceito de gerenciamento de problemas assemelha-se ao conceito de
Raciocnio Baseado em Casos (RBC), muito utilizado nos sistemas de Inteligncia
Artificial. Nesse tipo de sistema, uma base de dados com casos mantida sob
constante atualizao, criando sistemas especialistas na resoluo de problemas j
conhecidos. Sistemas gerenciadores de problemas so conhecidos como Trouble Ticket
Systems (TTS). Um TTS capaz de escalonar os problemas em nveis, possibilitando
definir prioridades para a soluo dos mesmos, fornecendo ferramentas que permitam
analisar estatisticamente anomalias que acontecem com freqncia, diagnosticando
problemas em diversas camadas da rede, fornecendo histricos completos sobre os
mesmos, permitindo acompanhar as atividades que foram desenvolvidas para sua
resoluo, entre outras funcionalidades. Quando a empresa cogita a implantao de um
NMS bastante oportuno que se cogite tambm a implementao de um sistema

especialista no gerenciamento de problemas.
Qualquer tipo de rede pode ser monitorada, desde que possua as tecnologias
essenciais para este monitoramento. Redes cabeadas, redes sem fio, LANs Corporativas,
VPNs, enfim, qualquer rede pode e deveria receber monitoramento constante. Os
sistemas de monitoramento de redes podem ajud-lo a identificar atividades irregulares
especficas e definir ou controlar mtricas de performance, produzindo resultados que
habilitam seus tomadores de decises a enderearem corretamente suas necessidades e
aumentar seus rendimentos e visibilidade operacional.
Porm no basta ter a conscincia de que monitorar e gerenciar os sistemas
crticos do ambiente corporativo evitaro inmeras dores de cabea aos administradores.
preciso saber como faz-lo, e para isso a palavra chave planejamento, pois
segundo Josephsen (2007), se no for entendido quais sistemas so crticos para a
empresa, a iniciativa de monitoramento estar fadada ao fracasso. preciso saber em
detalhes quais dispositivos e servios so crticos ao bom funcionamento da rede. A
empresa precisa ter um mapa da rede, que por sua vez deve ser mantido atualizado,
mostrando precisamente seu leiaute, sua topologia, quais servidores, quais aplicaes e
em quais sistemas operacionais esto rodando os servios crticos. Mostrar como esses
servios esto distribudos, se existem mecanismos de segurana implementados, quais
dispositivos remotos tero acesso a cada rede, entre outras informaes relevantes ao
conhecimento dos administradores.Quando no estamos bem instrumentados, no
somos capazes de resolver problemas e por conseqncia, no seremos capazes de
solucion-los. Isso nos afastar substancialmente de nosso objetivo que manter a
sade da rede (Lopes et al., 2003, pg. 10).
2.1
Atividades de Gerenciamento
Um sistema que se prope a monitorar uma rede deve ter duas atividades distintas
relacionadas gerncia: atividades de monitoramento e atividades de controle.
Nas atividades de monitoramento, existe a figura de um dispositivo gerente de
rede que ter o papel de coletar informaes e analisar os dados de desempenho e
comportamento dos dispositivos gerenciados, ou seja, ele apenas realiza a leitura das
informaes de gerncia. Nesta etapa no existe nenhuma interferncia do gerente no
dispositivo gerenciado, havendo apenas uma coleta de dados. Como exemplo de uma
atividade de monitoramento, pode-se citar uma estao gerente que pergunta a um
roteador qual a quantidade de erros de uma determinada interface.
J nas atividades de controle, o sistema gerente ter o papel de alterar parmetros
de configuraes que resultaro em comandos diretos aos dispositivos gerenciados, ou
seja, existe uma alterao na informao de gerncia do elemento gerenciado. O gerente
altera parmetros de configurao ou emite comandos para o agente que por sua vez
executa esses comandos de controle. Como exemplo, pode-se citar uma estao gerente
que ordena a um roteador que desligue a sua interface de nmero 2.
2.2
Por que gerenciar?
Para os administradores de redes o fato da rede estar no ar e rodando no o suficiente.

Existem inmeras razes para monitorar o funcionamento de uma rede, e entre as
3
principais podemos citar o alto nvel de manuteno da sade da rede, assegurando

assim alta disponibilidade e bom desempenho. Alm disso, a implementao de um
NMS na rede pode auxili-lo a construir uma base de dados de informaes crticas ou
mesmo um TTS, que pode ser utilizado para planejar mudanas no ambiente ou um
futuro crescimento da rede, visto que os problemas gerados pela tomada de deciso com
pouca ou nenhuma informao pertinente a situao podem ter resultados desastrosos
para a empresa. Dentre as inmeras vantagens da implantao de um NMS citam-se:
O NMS pode alertar os administradores da rede sobre uma anomalia, antes que
se transforme em uma crise;
pode fornecer informaes detalhadas sobre a rede aos administradores, de modo

a facilitar o planejamento de atualizaes;
mostra onde esto os gargalos da rede;
possibilita o gerenciamento dos dispositivos crticos da rede com uma viso bem
detalhada;
uma ferramenta imprescindvel para quem tem contratos de servios em

Service Level Agreement (SLA) , pois pode garantir que um determinado nvel
de servio, dispositivo alvo ou aplicao contratada est sendo mantido;
economiza tempo, dinheiro e traz estabilidade para ambientes complexos;
controla os limites dos canais, o uso, a performance e o trfego, alm de executar

diagnsticos e relatrios estatsticos;
monitora servios de rede como SMTP, POP3, HTTP, NNTP, DNS, LDAP, etc;
avisa sobre problemas causados por sistemas sobrecarregados, servidores

travados ou indisponveis, perdas de conexes, quedas de energia, controle de
estatsticas de visitas a uma pgina na internet ou monitoramento da temperatura
de um ambiente, por exemplo.
Por outro lado, um NMS mal planejado e/ou mal configurado pode comprometer
a eficincia do sistema de monitoramento. Uma configurao incorreta pode emitir
tantos alertas falsos ou informar sobre tantos problemas no crticos, que em pouco
tempo ningum mais prestar ateno nele. Associe-se a isso o custo na alocao de
pessoal qualificado para montar um NMS, pessoal este que poderia estar sendo utilizado
em outros projetos, somado aos custos de um NMS que insere diversos Megabytes de
dados na rede sobre servidores que esto funcionando perfeitamente e o resultado ser
um sistema de monitoramento que faz parte do problema e no da soluo.
2.3
reas funcionais de gerenciamento
A International Standards Organization (ISO) dividiu as diversas atividades das redes

de computadores em cinco reas funcionais de gerenciamento, devido extrema
complexidade de monitorar e controlar grandes redes de maneira eficaz. Cada uma
destas reas engloba uma srie de funes de gerenciamento, o que no impede que
algumas dessas funes estejam disponveis em mais de uma rea funcional. So elas:
Gerenciamento de Falhas, Gerenciamento de Performance ou Desempenho,
Gerenciamento de Configurao, Gerenciamento de Segurana e Gerenciamento de

Contabilizao.
2.3.1
Gerenciamento de Falhas
O gerenciamento de falhas corresponde rea funcional que permite que operaes

anormais na rede sejam identificadas, isoladas e corrigidas. responsvel por monitorar
os estados dos recursos, verificando quando e em qual ponto da rede uma falha pode
ocorrer. Por falha, entende-se uma condio anormal persistente, na qual um reparo
imediato requerido. Tambm faz parte do gerenciamento de falhas, isolar o problema e
buscar solues paliativas at que seja atingida uma soluo final, reduzindo o impacto
da falha sobre o sistema como um todo.
2.3.2
Gerenciamento de Performance ou Desempenho
O gerenciamento de performance corresponde a um conjunto de funcionalidades que

possibilitam monitorar, medir e avaliar o comportamento dos dispositivos gerenciados.
Segundo o CISCO ITO (2008), seu objetivo medir e disponibilizar vrios aspectos de
desempenho da rede, para que a performance de interconexo possa ser mantida em
valores aceitveis. Graas a este modelo de gerenciamento possvel planejar atividades
futuras em uma rede de computadores, garantir o cumprimento dos contratos SLA,
cobrar solues para problemas recorrentes de fornecedores, emitir relatrios sobre o
desempenho da rede, definir mtricas e tresholds1, identificar a degradao de processos
entre outras funcionalidades. O gerenciamento de desempenho permitir quantificar,
medir, informar, analisar e controlar o desempenho dos diferentes dispositivos
componentes da rede.
2.3.3
Gerenciamento de Configurao
O gerenciamento de configurao corresponde a um conjunto de funcionalidades que

mantm e monitoram a estrutura fsica e lgica da rede. Como uma rede de
computadores est geralmente sob constante mudana, novos dispositivos so
adicionados e/ou removidos com certa freqncia. Este gerenciamento permite manter
atualizadas as informaes de software e hardware da rede, incluindo as configuraes
dos seus dispositivos.
2.3.4
Gerenciamento de Segurana
O gerenciamento de segurana corresponde a um conjunto de funcionalidades

responsveis por criar e manter os recursos de segurana de uma rede. Protege os
dispositivos da rede detectando e monitorando violaes da Poltica de Segurana
definida pela empresa. O CISCO ITO (2008) define o gerenciamento de segurana como
o controle de acessos aos recursos da rede de acordo com mtricas locais de forma que a
rede no possa ser sabotada (intencionalmente ou no), e informaes crticas no
possam ser acessadas por pessoas sem a devida autorizao. Basicamente, este
gerenciamento tem como meta controlar o acesso aos recursos que compe a rede.
Limiares, valores mximos aceitveis.
2.3.5
Gerenciamento de Contabilizao
O gerenciamento de contabilizao corresponde a um conjunto de funcionalidades que

visam determinar o custo associado utilizao dos recursos da rede (quais e quantos
recursos esto sendo utilizados). Sua funo bsica de contabilizar e verificar os
limites de utilizao dos recursos da rede, permitindo que seja feita, por exemplo, a
cobrana diferenciada por trfego ou utilizao desses recursos.
2.4
Arquitetura de Gerenciamento
De um modo geral a arquitetura de um sistema de gerenciamento composta por quatro

componentes bsicos:
Elementos gerenciados (agentes);
Estaes de gerncia (gerentes);
Protocolos de gerenciamento (SNMP);
Base de informaes gerenciais (MIBs).
O modelo de um sistema de gerenciamento exemplificado na Figura 1 abaixo:
Figura 1 - Modelo de Arquitetura de Gerenciamento
A seguir veremos a funo destes elementos dentro da arquitetura de

gerenciamento.
2.4.1
Elementos Gerenciados
Os elementos gerenciados so dotados de um software denominado Agente, que o

responsvel por permitir o controle e o monitoramento dos recursos gerenciveis pelas
estaes de gerncia. Um agente um pequeno software que roda nos dispositivos de
rede que esto sendo gerenciados. Pode ser um programa separado (um daemon na
linguagem Unix), ou pode ser incorporado no sistema operacional (por exemplo um
IOS2 de um roteador Cisco ou o sistema operacional de baixo nvel que controla um
UPS3) (Mauro & Schmidt, 2001, pg. 11). Um agente pode escutar e responder as
solicitaes feitas por um gerente relativas ao equipamento no qual est instalado. Alm
disso, o agente pode ser configurado para enviar as informaes necessrias ao gerente
2
IOS ou Internetwork Operating System um software com funes de roteamento, switching,

interconexo e telecomunicao presente na maioria dos dispositivos da CISCO.
3
UPS ou Uninterruptible Power Supply um tipo de dispositivo ou estrutura que visa prover
fornecimento ininterrupto de energia.
automaticamente, em intervalos previamente determinados, processo esse conhecido

como envio de traps.
2.4.2
Estaes de Gerncia
As estaes de gerncia so dotadas de um software denominado Gerente,

responsvel pelas solicitaes das informaes de controle e monitoramento aos
dispositivos gerenciados, ou seja, aos agentes instalados nesses dispositivos. O gerente,
alm de fazer solicitaes aos agentes, tambm pode receber as informaes dos agentes
em intervalos previamente determinados. Atravs dessas estaes, o responsvel pela
rede poder executar suas tarefas de gerenciamento pois ela concentra as informaes
necessrias.
2.4.3
Protocolos de gerenciamento
Apesar das estaes de gerncia e os elementos gerenciados terem funes especficas e

bem definidas, necessrio que elas falem a mesma lngua. Fazendo uma analogia, se
o chefe que s fala francs solicitar informaes ao colaborador que s entende alemo,
ele no conseguir obter a informao desejada. nesse conceito que entra o Simple
Network Management Protocol (SNMP) ou Protocolo Simples de Gerenciamento de
Rede, que um dos protocolos responsveis pela comunicao entre agentes e gerentes
mais populares entre os sistemas de monitoramento.
O SNMP foi introduzido em 1988 ao verificar-se uma crescente necessidade de
criao de um padro de gerenciamento para dispositivos IP. Ele prov comandos
simples de operao que permitem gerenciar recursos de rede remotamente. Este
protocolo foi concebido considerando a necessidade de gerenciar redes cujos
dispositivos fossem de diferentes fabricantes, com uma simples aplicao
(gerenciamento integrado), alm de permitir que o equipamento de um determinado
vendedor fosse gerenciado pelo equipamento de outro vendedor (interoperabilidade),
padronizando o gerenciamento. Outra caracterstica do SNMP que por ele ser simples,
o recurso gerenciado necessita de pouco processamento, visto que as tarefas mais
complexas relativas gerncia so de responsabilidade do sistema gerente. Ainda como
vantagem, o protocolo prov um conjunto limitado de comandos e mensagens que so
enviadas via UDP, ou seja, apesar de no haver garantia da entrega desta mensagem,
no existe a necessidade de aes prvias ou pstumas ao envio das mesmas, pois o
protocolo no orientado a conexo e, logo, nem o gerente nem o agente necessitam um
do outro para estarem operantes.
O protocolo SNMP est na sua terceira verso. A primeira delas, o SNMPv1
caracteriza-se pela sua simplicidade, flexibilidade e popularidade, mas uma de suas
principais desvantagens a pouca preocupao com segurana. A existncia do nome
de comunidade no garante absolutamente nada em matria de segurana, visto que ela
no criptografada, qualquer entidade poderia capturar um pacote e obter o nome de
comunidade atualmente utilizado pelo sistema (Freitas & Monteiro, 2004, pg. 26). O
SNMPv1 consiste dos documentos RFC4 1155, 1157 e 1212 que definem suas unidades
de dados denominadas Protocol Data Units (PDU) e suas operaes, que so trocadas
durante a comunicao entre gerentes e agentes. Os cinco tipos de mensagens SNMP
bsicas so:
Get-request: mensagens enviadas pelo gerente aos agentes solicitando

valor de uma varivel (gerente agente);
Get-next-request: mensagens enviadas pelo gerente aos agentes

solicitando o valor da prxima varivel depois de uma ou mais
variveis que foram especificadas (gerente agente);
Set-request: mensagens enviadas pelo gerente aos agentes solicitando a

alterao do valor de uma varivel (gerente agente);
Get-response: mensagens enviadas pelos agentes ao gerente em

resposta a uma solicitao get-request, get-next-request ou set-request
(gerente agente);
Traps: mensagens enviadas pelos agentes ao gerente informando sobre

um evento ocorrido (gerente agente);
Apesar do SNMPv1 prever um servio de autenticao que d suporte a vrios

mtodos, nenhum mtodo foi efetivamente implementado alm de uma autenticao
simples baseada em comunidades (community strings), usando um controle de acesso
baseado em SNMP MIB views ou visualizaes da MIB via SNMP.
J o SNMPv2 est escrito nas RFCs 1902, 1903, 1904, 1905, 1906 e 1907,
sendo que a relao entre o SNMPv1 e o SNMPv2 est descrito na RFC 1908. No
SNMPv2 existe uma maior preocupao com segurana, alm de uma melhora na
performance e eficincia com a implementao dos operadores GetBulkRequest, que
busca uma grande seo de variveis da tabela de uma nica vez e Inform
Request/Response, que permite o envio de mensagens de gerente para gerente, nos
casos onde h mais de um gerente na rede. Tambm h uma melhoria na definio da
linguagem de dados, maior detalhamento dos erros e modo facilitado de criao e
deleo de linhas da MIB.
J a verso mais atualizada, o SNMPv3, est descrito nas RFCs 2570, 2571,
2572, 2573, 2574 e 2575 e a relao entre SNMPv1, v2 e v3 est descrita na RFC 2576.
Como a equipe que desenvolveu o v3 se baseou bastante nos documentos Draft
Standard5 do v2, o SNMPv3 um SNMPv2 com blocos de segurana e administrao.
No que tange a segurana, o SNMPv3 implementou tcnicas de autenticao,
privacidade, autorizao e controle de acesso. No que tange a administrao,
implementou a nomeao das entidades, gerncia das chaves, notificao dos destinos,
relao dos proxys e configurao remota atravs de operadores SNMP. Mas apesar de o
RFC ou Request for Comments uma srie de documentos com informaes tcnicas detalhadas sobre
protocolos da Internet, usados como referncia padro pelos fabricantes de software comercial e no
comercial na Internet. Podem ser consultadas em: http://www.ietf.org/rfc.html
5
O processo de padronizao do IETF (Internet Engineering Task Force) consiste de trs etapas:
Proposed Standards (Padres Propostos), que pode evoluir para um Draft Standard (Padro de Projeto) e
que finalmente pode evoluir para um Internet Standard (Padro da Internet).
SNMPv3 ter maiores avanos em segurana, tambm tm como desvantagem, o fato de

muitos equipamentos antigos serem incompatveis com essa verso, sendo necessria a
atualizao dos equipamentos da rede para que este protocolo seja suportado, o que
pode encarecer o projeto nas empresas.
Segue abaixo um quadro comparativo entre as trs verses do SNMP:
Tabela 1 - Comparao das verses do Protocolo SNMP
Nmero de troca de mensagens

Suporte
distribudo
gerenciamento
Aspectos de segurana
2.4.4
SNMPv1
SNMPv2
SNMPv3
Elevado
Baixo (com get-bulk)
Baixo (com get-bulk)
Inexistente
Difcil
Difcil
Baixa
Baixa
Alta
Base de Informaes Gerenciais
A base de informaes gerenciais um dos fatores mais importantes em um sistema de

gerenciamento. Segundo Turnbull (2006), as Management Information Bases ou MIBs
so colees hierrquicas de informaes que detalham os atributos e caractersticas de
um dispositivo. Estas informaes precisam estar disponveis sob um padro
determinado, para que possam ser utilizadas pela aplicao de gerncia. De fato, essas
variveis de gerncia formam uma base de dados virtual, acessvel aos agentes dos
dispositivos gerenciados, que podem ser buscadas pela aplicao gerente via SNMP.
Conforme Lopes et al. (2003), devido grande quantidade de variveis de
gerncia o espao de nomes dessas variveis foi organizado de forma hierrquica, que
o que mostra a Figura 2:
Figura 2 Exemplo de Estrutura Hierrquica da MIB
Uma MIB geralmente composta por vrios mdulos MIB. Existe uma MIB
padro chamada MIB-2 que todos os dispositivos devem suportar, porm as MIBs
9
podem ser pblicas ou privadas, ou seja, um fabricante pode definir uma MIB especfica
para atender caractersticas particulares do seu dispositivo. Isto possibilita a criao de
uma MIB especfica para um roteador, por exemplo, apesar de a MIB continuar sendo
acessada via protocolos como o SNMP. Atravs dos objetos disponveis na MIB
possvel acessar informaes como a descrio do dispositivo, quantos pacotes com
erros passaram pela sua interface de rede, h quanto tempo o equipamento est ligado,
entre outras inmeras informaes.
2.5
Tipo de Administrao
A administrao do sistema de gerenciamento pode ser centralizada, hierrquica ou

distribuda.
No modelo centralizado utiliza-se o paradigma do cliente-servidor, onde as
solicitaes feitas aos agentes so enviadas de um nico gerente, que por sua vez
concentra todas as informaes de gerenciamento e monitoramento da rede. O trfego
ao seu redor costuma ser pesado, visto que todas as traps, solicitaes e respostas vo
para o mesmo ponto central na rede. Por outro lado, para redes mdias e pequenas, um
ponto nico de administrao tende a simplificar o trabalho do gerente.
Na administrao hierrquica, as solicitaes feitas aos agentes so enviadas de
diversos gerentes que por sua vez esto subordinados a um gerente central, diminuindo
o trfego de um ponto especfico centralizado da rede. Existe uma delegao de funes
aos gerentes subordinados, porm a recuperao das informaes dos agentes torna-se
mais lenta.
Na administrao distribuda, as solicitaes feitas aos agentes so enviadas de
diversos gerentes que dividem as tarefas de gerenciamento. Porm mesmo havendo a
distribuio do monitoramento, todos os gerentes mantm suas bases de dados
atualizadas com as informaes dos demais gerentes.
2.6
Mtricas de gerenciamento
O uso de um NMS no ambiente corporativo visa promover o melhor aproveitamento dos

recursos computacionais disponveis, e para isso precisa-se conhecer o ambiente
gerenciado. Saber quais os perodos de pico dos servidores, diagnosticar o que pode ser
considerado como processamento normal e o que um gargalo para a rede como um
todo. Logo, antes de implementar um NMS faz-se necessria a definio de algumas
mtricas plausveis para o ambiente gerenciado. No Anexo I Mtricas de
Desempenho, possvel verificar uma compilao de mtricas comuns a maioria dos
ambientes, como percentual de disco tolervel, total de pacotes perdidos de uma
interface, quantidade de processos em execuo, entre outras.
Os monitoramentos tradicionais geralmente comeam pela largura de banda da
WAN, latncia ou tempo de resposta dos switches, roteadores e servidores, e claro, as
taxas de consumo de memria RAM e utilizao da CPU dos dispositivos crticos.
Antigamente, mtricas simples como perda e atraso de pacotes entre determinados ns
eram suficientes para dar ao gerente uma viso razovel do estado da rede. Porm hoje
em dia, como a performance de aplicaes sensveis como VoIP (voz sobre IP), IPTV
(Internet Protocol TV) e VOD (video on demand) aterrissaram as barras dos grficos de
monitoramento das redes, estas mtricas no so mais to eficientes. Os administradores
10
esto mais interessados no quo corretamente essas aplicaes e servios complexos

sero utilizadas e disponibilizadas aos seus usurios. Hoje, gasta-se mais tempo
verificando a performance da aplicao e a utilizao da banda, usando ferramentas que
fornecem janelas em tempo real do que est acontecendo na rede, procurando e
resolvendo problemas geradores de degradao dos servios como latncia, jitter6 e
pacotes descartados.
2.7
Caractersticas desejveis de um NMS
Um sistema de monitoramento de rede uma ferramenta complexa e por vezes exige

conhecimento especializado para implementao. Apesar de existirem muitos
fornecedores no mercado, alguns licenciados sob a licena GNU General Public License
(GPL) e outros que podem custar mais de U$ 150.000,00 dependendo da quantidade de
gerentes e agentes gerenciados, algumas caractersticas so fundamentais implantao
de qualquer sistema de monitoramento de redes.
Possibilidades de monitoramento: O conceito de monitoramento pode
englobar funes diversificadas, como controlar servidores, controlar acessos, controlar
ambientes, e o mesmo aplica-se ao NMS. Um sistema de gerenciamento deve ter a
capacidade de monitorar uma boa gama de dispositivos e servios, desde servidores
temperatura de determinados ambientes. Existem casos onde o administrador quer saber
se o servidor web da companhia est no ar, e em outros, ele apenas quer ser avisado se a
temperatura do datacenter ultrapassou os 18C. Basicamente, a idia deve ser dar
suporte gerencia de todo e qualquer dispositivo, objeto ou ambiente do cenrio
desejado que possa ser gerenciado.
Notificaes: As notificaes so muito importantes porque liberam o
administrador para realizar outras tarefas, se encarregando de enviar-lhe um alerta
quando alguma anomalia for detectada. Deve-se ajustar o sistema de notificaes s
necessidades especficas da situao. O que um erro crtico para um administrador
pode ser um erro tolervel para outro, e assim sendo, ser bombardeado com mensagens
de supostos erros que o administrador considera triviais, poder torn-lo menos
cauteloso; em algum ponto, um erro crtico pode se perder em meio aos falsos alertas.
Para a melhor configurao do sistema de notificaes, Segundo Barth (2006), quatro
perguntas precisam ser feitas antes de se configurar corretamente as notificaes do
sistema, e so elas: Em que situao o sistema deve gerar a mensagem? Quando essa
mensagem deve ser entregue? A quem o sistema deve informar esta mensagem? Como
essa mensagem deve ser entregue?. Outra funo importante do NMS prover
escalonamento, principalmente nos tipos de contrato de SLA. Com essa funo, quando
uma falha identificada, uma mensagem gerada e enviada ao primeiro nvel de
suporte, geralmente o pessoal de help-desk. Se dentro de um determinado perodo de
tempo pr-determinado o problema no for solucionado, o sistema gera ento nova
mensagem e envia para algum de nvel superior na hierarquia da organizao, como o
administrador da rede por exemplo. Se novamente o problema no for solucionado
durante determinado perodo, nova mensagem gerada e enviada, dessa vez para
6
a variao do intervalo entre a chegada de dois pacotes consecutivos em relao ao intervalo de sua
tranmisso. Dependendo de fatores como caminho percorrido, trfego, etc, possvel que um pacote B
chegue ao seu destino muito depois do pacote A, atraso causado pelo jitter.
11
algum superior ao administrador da rede, e assim sucessivamente at a regularizao

do problema identificado.
Redundncia e tolerncia a falhas: outro aspecto desejvel nos sistemas de
gerenciamento de redes que ele seja redundante e tolerante a falhas, ou seja, que ele
fornea mecanismos para que, se o servidor principal de monitoramento falhar, outro
servidor com a mesma capacidade e com as mesmas funes tome seu lugar
automaticamente para que a tarefa de gerenciamento no seja comprometida.
2.8
Melhores prticas de monitoramento
Um NMS monitora os elementos crticos de uma rede em nvel de software e hardware,

e isso envolve diferentes arquiteturas e modelos de gerenciamento. Monitorar e
controlar os ativos de rede pode tornar-se uma tarefa muito complexa e, portanto,
algumas prticas de monitoramento que tm mostrado relativo sucesso na maioria das
implementaes devem ser consideradas ao implementar esse tipo de sistema, segundo
Josephsen (2007).
2.8.1
Planejamento
Para distinguir um sistema de monitoramento eficiente dos demais, precisa-se avaliar o

impacto que ele tem sobre o seu ambiente de rede em reas como a utilizao de
recursos, utilizao de banda e segurana. Sem o entendimento claro de quais servidores
e servios so considerados crticos para o negcio, a iniciativa de monitoramento estar
fadada ao fracasso.
2.8.2
Processamento local x processamento remoto
Muitos sistemas de monitoramento trabalham com o conceito de plugins, ou seja,

pequenos programas de checagem de servios que enviam as informaes para um
mdulo central de monitoramento. Esta funo modular, permite que os plugins sejam
auto-executveis tanto localmente, no servidor de monitoramento, quanto remotamente,
nos hosts monitorados. Ambas as solues so teis e sua utilizao vai depender do
sistema sendo gerenciado. A execuo centralizada geralmente a escolhida por manter
um ponto nico e centralizado de configurao na rede. Entretanto para uma rede com
milhares de hosts o gerenciamento centralizado no desejvel, pois o trfego ao redor
desse servidor bem como seu processamento e recursos seriam saturados rapidamente.
2.8.3
Consideraes sobre o uso de plugins redundantes
preciso estar sempre analisando os plugins utilizados, para evitar a redundncia. Um

administrador de rede pode, por exemplo, monitorar um servidor web chamado
Servidor_POA definido um plugin que checa regularmente se a porta 80 desse
servidor est escutando. Se hipoteticamente, meses depois, os usurios da rede
reclamarem sobre problemas de autenticao e um novo plugin for desenvolvido para
verificar se a autenticao no Servidor_POA bem-sucedida, o primeiro plugin no
est fazendo nada seno desperdiando recursos, pois se possvel autenticar-se no
servidor web, obviamente a porta 80 est escutando e o primeiro plugin tornou-se
redundante.
12
2.8.4
Segurana
As estaes de gerncia utilizam gerenciamento remoto e logo, precisam de certos

direitos de execuo nos hosts gerenciados. Deve-se planejar e revisar e constantemente
esses direitos de acesso, pois sem os cuidados necessrios com a segurana, seria
relativamente fcil introduzir algum tipo de malware7 ou explorar vulnerabilidades nos
sistemas gerenciados. O NMS deve ter apenas o acesso necessrio para executar
remotamente os plugins configurados. Alm disso, o SNMP, que uma das grandes
ferramentas dos sistemas de gerenciamento, deve ser muito bem estudado antes de ser
implementado, sob pena de ter um dispositivo na rede comprometido devido
insegurana e/ou m implementao desse protocolo.
2.8.5
Muito cuidado com alarmes falsos
Tipicamente, sistemas de monitoramento usam limites estticos para determinar o

estado de um servio. Se por exemplo, a memria RAM do Servidor_POA tiver um
limiar de utilizao de 90%, quando o uso da memria RAM ultrapassar esse valor, o
sistema dever gerar um alerta ou executar uma ao automtica de correo. Porm se
a equipe responsvel pela implantao do NMS no tiver definido anteriormente
parmetros operacionais para os servidores, compreendendo corretamente suas taxas
regulares de operao e o Servidor_POA estiver com 96% de utilizao de memria
RAM entre 01:00hs e 03:00hs (que foi, hipoteticamente, o horrio configurado para
executar a verificao automtica de vrus), ento um alarme falso ter sido enviado ao
administrador.
2.8.6
Monitorar portas x Monitorar Aplicaes
Como foi apresentado na seo 2.8.3 Consideraes sobre o uso de plugins

redundantes, um plugin monitorava a porta 80 de um servidor web enquanto o outro
autenticava-se no web site hospedado nesse servidor. O ltimo tipo de plugin
conhecido como End-to-End (E2E) ou Fim-a-Fim e faz o monitoramento da mesma
maneira que um ser humano o faria. Ao invs de monitorar a porta 21 de um servidor
FTP, ele tenta se conectar e buscar um arquivo previamente determinado para testar se o
servio est operacional. Ao invs de verificar a porta tcp 25 de um servidor de e-mail,
ele tenta enviar um e-mail atravs deste servidor. Uma srie de plugins que monitoram
uma aplicao checando as portas web, os servios de banco de dados e a
disponibilidade de um servidor de aplicaes, podem ser substitudos por um nico
plugin E2E que se loga no servidor web e executa uma consulta, ou seja, os plugins E2E
tendem a ser mais espertos. Por outro lado, nem sempre este tipo de plugin poder
informar qual o tipo de problema acontecido (se foi no servio web, no banco de dados
ou na aplicao), portanto novamente, a anlise do administrador na implantao dos
plugins indispensvel para o bom funcionamento do NMS.
2.8.7
Quem supervisionar os monitores
Se o NMS falhar, muito importante que o administrador da rede seja ao menos

informado do ocorrido caso no haja um sistema de tolerncia a falhas que assuma do
Programas maliciosos como virus, trojans, backdoors, rootkits, etc.
13
ponto onde o outro parou. Se a empresa possuir contratos SLA, a implementao de um

NMS para lhe gerar relatrios do perodo de disponibilidade do servio praticamente
obrigatria. J em outros casos, apenas receber uma mensagem informando que um
servidor n saiu do ar o suficiente. De qualquer maneira, o prprio NMS um dos
sistemas com a maior necessidade de monitoramento, e deve-se sempre coloc-lo na
lista de sistemas crticos a serem monitorados.
2.9
O Nagios como ferramenta de monitoramento
O mercado de monitoramento de rede tem crescido tanto nos ltimos anos que at a
gigante Microsoft entrou nesse cenrio com o MOM Microsoft Operations Manager.
E no foi a nica. Segundo o Gartner Group8, o mercado de gerenciamento de redes
movimentou em 2005 cerca de U$9,9bi (nove bilhes e nove milhes de dlares). Uma
ferramenta que se destacou pelas funes de gerncia como o OpenRiver da Riversoft,
foi adquirida em 2002 pela Micromuse, tambm em posio de destaque pela sua
ferramenta Micromuse Netcool; essa por sua vez, foi incorporada pela IBM em 2005,
tendo sua inteligncia inserida no Tivoli Netview. A Veritas, fabricante do NerveCenter
teve seu sistema incorporado pela Symantec. Outros fornecedores de peso como Cisco,
Sun Microsystems e 3COM, tambm aderiram a este mercado e, mesmo adotando uma
estratgia na contramo do mercado, por suas ferramentas focarem suas tecnologias
proprietrias e serem desenvolvidas especificamente para gerenciar seus produtos, j
estriam com grande visibilidade, j que suas marcas atestam seus produtos.
E neste cenrio to competitivo, este artigo apresenta o Nagios como um sistema
de monitoramento para empresas de pequeno, mdio e grande porte que possui as
funes desejveis de um NMS e distribudo sob a licena GPL v2. Apesar de a
primeira verso do Nagios ter sido lanada em 1999, ou seja, a ferramenta ser
relativamente jovem se comparado a outros NMSs consolidados no mercado, sua
gama de funcionalidades impressiona e sua aceitao visvel principalmente no mundo
OpenSource, conforme mostra o grfico da Figura 3 abaixo:
Estatstica das Plataformas onde o Nagios foi Implantado
Redhat
3%
3%
3%
Debian
2% 1% 2%
Suse
28%
4%
Fedora
FreeBSD
6%
Linux (Outros)
Solaris
Gentoo
Mandrake
8%
Outros
9%
20%
Slackware
OpenBSD
11%
Todos os outros
Figura 3 Estatstica das plataformas onde o Nagios foi Implantado
Uma empresa de pesquisa e assessoria fundada em 1979, que se tornou muito conhecida na area de TI
por suas pesquisas, consultoria, mtricas, eventos e publicaes.
14
Dos sistemas operacionais suportados pelo Nagios, v-se que 82,10% rodam
alguma distribuio de Linux.
Olhando-se a Figura 4, que mostra os tipos de ambientes que rodam o Nagios
como ferramenta de monitoramento, v-se que 15,8% so Provedores de Servio de
Internet (ISPs), 15,7% empresas de consultoria em TI, e 6,3% empresas de
telecomunicaes, o que mostra a grande aceitao de um NMS to jovem como o
Nagios pela comunidade especializada.
Tipos de Empresas que usam o Nagios
ISP
Consultoria (TI)
15%
19%
No especificado
Outros
3%
Telecomunicaes
16%
3%
Governo
Sade / Medicina
Educao Superior
Educao / Treinamento
3%
Manufatura (Geral)
4%
4%
5%
9%
5%
6%
8%
ASP
Bancos / Finanas
Todos os outros
Figura 4 Tipos de empresas que usam o Nagios
Na pgina do Nagios na Internet que pode ser acessada em

http://www.nagios.org, possvel ver estatsticas interessantes como a da Tabela 2
mostrada abaixo sobre a quantidade de hosts registrados gerenciados pelo Nagios.
Tabela 2 Estatstica do Nagios nas empresas
Estatstica
Valor
Nmero de perfis de usurios registrados
1.504
Nmero de estaes de gerentes com o Nagios
7.140
Nmero de dispositivos gerenciados
543.894
Nmero de servios monitorados nesses dispositivos
4.251.343
Mdia de estaes gerentes por perfil
4,7
Mdia de dispositivos monitorados por perfil
361,6
Mdia de servios monitorados nesses dispositivos por perfil
2.826,7
Taxa mdia de servios por host
7,8 : 1
Entre essas estatsticas, ressalta-se o caso do Yahoo, empresa norte americana

consagrada por seu mecanismo de buscas na Internet, que possua em outubro de 2007,
cerca de 2.000 (dois mil) servidores rodando o Nagios, responsveis por gerenciar cerca
de 200.000 (duzentos mil) servios em 100.000 (cem mil) dispositivos. A maior
instalao registrada do Nagios do provedor de Internet indiano Tulip IT Services que
em agosto de 2007 registrava 20 (vinte) servidores rodando o Nagios, responsveis por
15
monitorar 1.000.000 (um milho) de servios em 100.000 (cem mil) dispositivos,

mostrando o quo robusto esse sistema pode ser.
Na Tabela 3, v-se um comparativo entre o Nagios e alguns dos NMSs
disponveis no mercado atual, conforme Santos (2008).
Tabela 3 Comparao do Nagios com alguns NMS disponveis no mercado
NMS
Caractersticas
HP Openview
Viabiliza o gerenciamento em larga-escala de redes e aplicaes. Inclui diversos mdulos adicionais,

tanto da HP como de terceiros, pois estratgia da empresa adquirir softwares de gerenciamento e
incorpor-los ao seu sistema. Seus principais mdulos so: Agente TCP/IP/SNMP extensvel; Network
Node Manager (NNM), que permite visualizar os elementos da rede, mapas e etc; Operations (OVO),
que fornece gerenciamentos bsicos de TI; Distributed Management (DM), que um ambiente de
desenvolvimento e execuo das aplicaes baseado no SNMP e no CMIP; Event Correlation Services
(ECS), que trata os erros gerados; Kit de desenvolvimento para plataforma SNMP; e o Service Desk
Aplication, para gerenciamento de servios, problemas, configuraes e SLAs. Roda nas plataformas:
HP-UX 11.x, MS Windows XP / 2000 / 2003, Solaris 8 e Solaris 9.
IBM Tivoli
Netview
uma soluo que tem funo de descoberta de redes TCP/IP, exibe as topologias, gerencia eventos,
traps SNMP, monitora e gerencia dados de desempenho. Alguns monitores de desempenho para redes
TCP/IP, SNA e TN-3270 so disponibilizados como produtos separados. Contm diversos mdulos
para gerenciamento dos servios de TI, storage, etc. Roda nas plataformas: Windows Server 2003,
2003 R2, Sun Solaris 9, 10, Linux s390: Red Hat EL 4.0, SUSE EL 9, Linux Intel: Red Flag 5.0, Red
Hat EL 4.0, SUSE EL 9, AIX 5.2, AIX 5.2H, AIX 5.3 32
Nagios
Distribudo sob licena GPL, verifica constantemente a disponibilidade dos servios e emite alertas via
pager, e-mail ou celular. Permite a criao de relatrios de disponibilidade para problemas ocorridos na
rede. Altamente expansvel atravs de plugins como o nrpe (execuo remota de plugins) e o ncsa
(checagens passivas automticas). Algumas de suas principais caractersticas so sua imensa gama de
servios de monitoramento de rede (SMTP, POP, HTTP, ICMP, SNMP, etc), monitoramento de
recursos dos computadores (disco, carga da CPU, etc), monitoramento remoto atravs de tneis
criptografados SSH ou SSL, desenvolvimento simples de plugins (perfeitamente customizvel pelos
administradores), checagem paralelizada, capacidade de definir a rede hierarquicamente (distinguindo
hosts indisponveis de hosts inalcanveis), escalonamento de notificaes, habilidade para definir
tratadores de eventos, rotao automtica de logs, excelente interface web e suporte a banco de dados.
Roda nas plataformas: Linux ou Unix
OpenNMS
Tambm distribudo sob licena GPL. Pouco focado na gerao de mapas mas com grande enfoque no
tratamento de eventos. Permite visualizao web com detalhes sobre os ns da rede, implementa
mecanismos de auto-descoberta da rede, faz checagens via SNMP, fornece uma console Java, gera
relatrios em XML, suporta SNMPv3, permite paradas agendadas e guarda informaes em bancos de
dados. Roda em qualquer plataforma que suporte Java.
BMC Patrol
Gerencia vrios tipos de servidores e tem uma arquitetura de monitoramento com vrias
funcionalidades extras como console centralizada, possibilidade de monitorar mais de 2000 itens
(memria, usurios autenticados, etc), acompanhamento histrico de dados, gerao de grficos de
vrias fontes, monitoramento de processos e servios alm de integrao de hardware de vrios
fabricantes. Roda nas plataformas: Windows 2000 Server, Windows XP, Windows 2003 Server, Solaris
9
CastleRock
SNMPc
Gerenciamento especificamente via SNMP. possvel gerenciar e coletar informaes em tempo real
de diversos equipamentos como hubs, switches, servidores, e quaisquer outros dispositivos que
suportem SNMP. Os resultados so obtidos atravs de relatrios em tempo real, relatrios salvos em
disco (Trend Reports) alm de alarmes visuais, sonoros, via pager ou celular. Entre suas principais
caractersticas esto o suporte a SNMPv3, gerenciamento remoto e acesso Java, exibies em tempo
real, compilador de MIBs, visualizaes de MIBs em tempo real, gerao automtica de relatrios
dirios, semanais e mensais, alm de emitir alarmes e relatrios automticos numa interface
programvel. Roda nas plataformas: Windows Vista / 2003 / XP / 2000 / NT
Zabbix
Soluo que monitora dispositivos com ou sem suporte SNMP, emite alertas, gera grficos de
performance, armazena em bases de dados e tambm distribudo sob licena GPL. Cria modelos de
mquinas que podem ser utilizadas para herdar caractersticas comuns e personalizar os dispositivos,
16
perfeitamente escalvel, permite monitoramento em tempo real, gera relatrios estatsticos e integra-se
facilmente com mdulos de terceiros. Roda nas plataformas: AIX, FreeBSD, HP-UX, Linux, MAC OS
X, Open BSD, Solaris, SCO Openserver e Tru64/OSF.
Segundo Josephsen (2007), muitas das empresas que desenvolvem ferramentas

de monitoramento, pensam seus produtos como grandes blocos monolticos que
possuem soluo para todo e qualquer dispositivo existente, negligenciando de certa
forma a viso do mercado, pois quando se preocupam com o que monitorar, acabam
esquecendo-se de como monitorar. Qualquer novo dispositivo lanado no mercado
logo incorporado, e quanto mais dispositivos diversificados o NMS puder suportar,
maiores sero as possibilidades da equipe de vendas da empresa efetuar sua funo com
sucesso. Obviamente, alm do valor desses NMSs corresponderem a quantidade de
dispositivos que eles so capazes de gerenciar, eles so de certa forma engessados,
pois sua inteligncia proprietria. Analisando-se o comando ping, por exemplo,
qualquer sistema de monitoramento acaba de uma maneira ou de outra, utilizando
pacotes ICMP request para determinar o status de alguns dispositivos. Porm se
houver a necessidade de especificar a quantidade de pacotes que devam ser enviados, ou
se for necessrio usar IPv6, ou se ainda for necessrio fazer um portknocking9 antes
de enviar os pacotes, enfim, controlar como os pacotes ICMPs devam ser utilizados, as
limitaes das ferramentas proprietrias tornam-se evidentes. Logo, a grande vantagem
do Nagios sua modularidade, escalabilidade e seu desenvolvimento simplificado de
plugins, que podem adequar-se a empresas que tem a necessidade de monitorar 3 ou
3000 servidores de maneira simples e personalizada.
Modelagem do Projeto
No presente artigo ser apresentado um cenrio real onde o Nagios foi escolhido como
NMS em funo da sua simplicidade, custo benefcio e fcil administrao. A empresa
onde se deu a implantao, Moinhos de Trigo Indgena S/A MOTRISA, uma
indstria de mdio porte, produtora de farinha de trigo nos estados do Nordeste, cuja
matriz situa-se em Porto Alegre. Conta com aproximadamente 500 colaboradores e esta
presente no mercado h 75 anos. A rede da matriz, onde ocorreu uma implantao local,
conta com 18 colaboradores, 3 servidores, 14 desktops, 4 laptops, 2 rotadores e 2
switches, que tero suas caractersticas detalhadas nas sees abaixo.
As atividades de gerncia exercidas neste cenrio so de monitoramento em sua
totalidade, no havendo nenhuma atividade de controle, sendo que as atividades de
monitoramento neste cenrio dividem-se entre as reas funcionais Gerncia de Falhas
(como o servio que controla a acessibilidade de um determinado host atravs de
pacotes ICMP) e Gerncia de Performance (como o servio que controla a taxa de
pacotes de entrada/sada de uma interface de rede e compara-o a limiares pr-definidos);
essas informaes sero todas enviadas a um ponto central de gerenciamento na rede.
Como a rede possui equipamentos antigos, que no suportam a verso 3 do protocolo
SNMP, algumas estaes sero gerenciadas atravs do protocolo SNMPv1 e as estaes
mais novas atravs de SNMPv3. Tanto as estaes mais novas quanto as mais antigas
Um mtodo para conectar-se externamente em um firewall onde um host bate em diversas portas
fechadas. Se a sequncia correta de batidas recebida, as regras de firewall mudam-se dinamicamente
para permitir que o host conecte-se a portas especficas que mostram o estado closed para terceiros.
17
tambm sero monitoradas via Nagios Remote Plugin Executor ou NRPE que a
ferramenta nativa do Nagios.
3.1
Mapa da Rede
A rede utilizada apresenta em seu cenrio um roteador central. Atrs dele, encontra-se
um firewall que separa a rede de desktops da empresa da zona desmilitarizada (DMZ)
onde encontram-se um servidor de aplicao e um servidor Proxy e onde futuramente,
ser inserida a estao de gerenciamento. A rede de desktops possui um roteador wifi,
que d suporte a uma rede sem fio para 5 (cinco) laptops de diretores e colaboradores de
algumas filiais. Servidores de e-mail, web e dns, externos a rede, tambm sero
monitorados pela estao de gerncia, conforme pode ser visualizado na Figura 5:
Figura 5 Mapa da rede antes da implantao do Nagios
Tendo esse cenrio como base, foi adicionado um servidor para atuar como
estao de gerncia conforme pode ser verificado na Figura 6.
Figura 6 Mapa da rede aps a implantao do Nagios
Este servidor, por medida de segurana, foi adicionado junto a zona

desmilitarizada impedindo que tanto os usurios da rede interna, quanto os usurios da
rede externa, tivessem acesso aos seus recursos sem passar pelos filtros do firewall. As
18
regras de firewall foram definidas de maneira tal que apenas o IP da estao do

administrador da rede e 2 (dois) endereos IP externos pr-configurados possuam nvel
de acesso suficiente para navegar na interface web da estao de gerncia..Como pde
ser observado nas Figuras 5 e 6, o cenrio composto de diferentes redes que possuem
endereamentos diversificados. A tabela abaixo mostra como esto separadas essas
redes, sendo que a estao de gerncia estar na DMZ com o IP 10.51.1.3.
Tabela 4 Endereamento lgico dos servidores e estaes da rede
Local / Setor
DMZ POA
Rede Firewall /
Roteador
Rede POA
Rede WIFI
Rede
10.51.1.0/29
10.51.2.0/29
10.51.10.0/24
10.51.11.0/28
Mscara
255.255.255.248
255.255.255.248
255.255.255.0
255.255.255.240
Host Inicial
10.51.1.1
10.51.2.1
10.51.10.1
10.51.11.1
Host Final
10.51.1.6
10.51.2.6
10.51.10.254
10.51.11.14
Broadcast
10.51.1.7
10.51.2.7
10.51.10.255
10.51.11.15
Gateway
10.51.1.1
10.51.2.6
10.51.10.1
10.51.11.14
Hosts Possiv.
254
14
Hosts em Uso
14
Alm das redes internas, como comentado acima, tambm sero monitorados
alguns servidores externos a rede, que se encontram na rede do provedor de Internet e
que possuem os endereos 200.143.84.2 (servidor de DNS1), 200.143.84.3 (servidor de
DNS2) e 200.143.84.32 (servidor de e-mail e web).
3.2
Equipamentos utilizados
Os equipamentos dessa rede que sero monitorados pela estao de gerncia esto
especificados detalhadamente na Tabela 5 abaixo:
Tabela 5 Especificao do hardware utilizado no cenrio
Estao de Gerncia Nagios
Processador
AMD K6II 550Mhz
Memria
128MB
HD
20GB
Adaptador de Rede
Realtek 8029 (AS) - 10/100 Fast Ethernet
Sistema Operacional
Linux 2.6.24-19-generic - Ubuntu 8.04

Servidor de Aplicao
Processador
Pentium III 750Mhz
Memria
128MB
HD
10GB
Adaptador de Rede
Sis900 PCI Fast Ethernet Adapter
Sistema Operacional
SCO Openserver 3.2 v5.0.5

Firewall
Processador
Pentium III 1.13Ghz
19
Memria
256MB
HD
20GB
Adaptadores de Rede 1 / 2 / 3 / 4 Realtek RTL8139/8139C/8139C+ (eth0 / eth1 / eth2 / eth3)

Sistema Operacional
Linux 2.6.24-19-server - Ubuntu 8.04

Proxy
Processador
Pentium III 1,1Ghz
Memria
512MB
HD
40GB
Adaptador de Rede
VIA Rhine III VT6105 (rev 8b)
Sistema Operacional
Linux 2.6.24-19-server - Ubuntu 8.04

Backup
Processador
Pentium IV 2.8Ghz
Memria
1,5GB
HD
40GB
Adaptador de Rede
VIA Compatible Fast Ethernet Adapter
Sistema Operacional
Windows XP PRO SP3

Backup/FTP
Processador
Pentium IV 2.8Ghz
Memria
2GB
HD1 / HD2
80GB / 160GB
Adaptador de Rede
VIA Compatible Fast Ethernet Adapter
Sistema Operacional
Windows XP PRO SP3

Router
Fabricante
D-Link
Modelo
D-Link DI-704UP
Firmware
v1.01
Suporte SNMP
somente SNMPv1
Router WIFI
Fabricante
D-Link
Modelo
D-Link DI-524 AirPlus-G 802.11g/2.4Ghz
Firmware
v2.03
Suporte SNMP
no suporta SNMP
Switch 8 portas
Fabricante
D-Link
Modelo
D-Link DES1008D Fast Ethernet
Suporte SNMP
no suporta SNMP / no gerencivel

Switch 24 Portas
Fabricante
Biccnet
Suporte SNMP
no suporta SNMP / no gerencivel
20
3.3
Servios monitorados
Nos hosts acima, que entre estao de gerncia e dispositivos gerenciados totalizam 11
equipamentos, sero monitorados 111 servios, dos quais 55 (cinqenta e cinco) so
monitorados via protocolo SNMP e 56 (cinqenta e seis) so monitorados via NRPE.
Logo, a mdia de servios monitorados por host de 10,09 servios. A tabela 6 mostra
quais os servios monitorados nos dispositivos, bem como o protocolo utilizado para tal
funo.
Tabela 6 Especificao de servios monitorados e seus respectivos protocolos
Servidor
Servios
Radio (200.143.84.1)
PING
DNS1 (200.143.84.2)
DNS
DNS2 (200.143.84.3)
DNS
MAIL/WEB (200.143.84.32)
POP
SMTP
HTTP
PING
HTTPS
ROUTER (10.51.2.6/29)
SNMP
Taxa de pacotes descartados na interface
Taxa de erros nos pacotes de entrada e sada da interface
Quantidade de pacotes icmp da interface
Taxa de pacotes icmp com erros
Taxa de pacotes icmp com destino inalcanvel
Taxa de pacotes IP descartados
Taxa de pacotes IP com erros de endereamento
Taxa de pacotes IP com protocolos desconhecidos
Taxa de pacotes IP sem rota
Taxa de pacotes IP com erros de remontagem
Taxa de pacotes IP com erros de fragmentao
FIREWALL (10.51.1.1/29)
PING
USERS
DISCO "/"
LOAD
SSH
Taxa de pacotes descartados na interface eth1
Taxa de erros nos pacotes de entrada e sada da eth1
21
Nagios
Taxa de pacotes icmp com erros
Taxa de pacotes icmp com destino inalcanvel
Taxa de pacotes IP com erros de cabealho
Taxa de falhas nas tentativas de conexo TCP
PROXY (10.51.1.3/29)
PING
PROCS
USERS
DISCO "/"
Disco "/usr"
Disco "/var"
LOAD
HTTPS
SSH
Taxa de erros nos pacotes de entrada e sada na interface
NAGIOS (10.51.1.3/29)
PING
PROCS
USERS
DISCO "/"
DISCO "/var"
DISCO "/usr"
LOAD
HTTPS
SSH
22
APLICAO (10.51.1.4/29)
PING
PROCS
USERS
DISCO "/"
LOAD
ROUTER_WIFI (10.51.10.14/24)
PING
BACKUP (10.51.10.15/24)
PING
FTP
DISCO C:
Tempo de CPU
RAM
Processo Explorer
Processo AVG
Processo AVG Update
Processo AVG Firewall
Quantidade de processos rodando
Memria Disponvel
Gargalo de memria
Quantidade de pginas por segundo
Quantidade de falhas de pool no paginvel
Quantidade de pginas de pool paginado
Quantidade em MB de pool no paginado usado pelo

servidor
Comprimento da fila de processador
Media de Disco sobre transferncia
Tempo de fila de disco
Quantidade de Bytes por segundo
Quantidade de comandos atuais no redirector
23
IPFRAGFAILS
TCPFAILATTEMPTS
O Nagios traz um conjunto de plugins que podem ser configurados para

monitorar os servios mais populares como servidores de e-mail, navegao, dns, ssh,
entre outros, atravs de NRPE. J o protocolo SNMP disponibiliza acesso aos valores
das MIBs dos dispositivos, ficando o gerente da rede limitado apenas pelos valores que
a MIB utilizada puder disponibilizar. No Captulo 4.4, este artigo apresentar um
exemplo de criao de scripts para Windows que podem realizar clculos com os valores
obtidos atravs dos contadores de performance do Windows. J no Captulo 4.5, pode-se
observar plugins para Linux que acessam os agentes via SNMP, realizam clculos com
os valores coletados e retornam informaes precisas de gerncia, como a relao da
taxa de protocolos desconhecidos em comparao ao trfego total da interface, por
exemplo. As mtricas utilizadas para montar os scripts ta tabela 6, tm suas funes
esclarecidas no Anexo I.
3.4
Anlise da insero de trfego gerado pelo NMS na rede
Durante o perodo de implantao do Nagios, foram realizadas coletas de dados,

objetivando avaliar e tipificar a quantidade de trfego gerado pela estao de gerncia na
rede. Para a correta realizao dessas coletas, fez-se necessrio avaliar o ambiente antes
e depois da implantao do NMS, durante um perodo pr-definido de tempo.
O software NTOP verso 3.2 foi instalado no equipamento gerente da rede
antes da implantao do Nagios. Foram coletados, pelo perodo de cinco dias teis
(totalizando cinco amostras na primeira semana de testes), informaes sobre o trfego
da rede como quantidade de pacotes TCP, UDP e ICMP, a quantidade total do trfego
dirio em MB e a quantidade total diria de pacotes trafegados nas interfaces de rede.
Alm disso, caracterizou-se a diviso do trfego IP entre HTTP, HTTPS, DNS, SNMP,
SSH e outros protocolos da camada IP, de acordo com os servios utilizados na rede.
Note-se que a estao de gerncia tem uma nica funo na rede que justamente a de
atuar como NMS e, sendo assim, a primeira semana de coletas revelou valores
insignificantes pois o trfego gerado por esse equipamento na rede era tambm
insignificante, certificando dessa maneira, que a gerao excedente de trfego nesse
equipamento derivou de alguma ferramenta adicional inserida no cenrio.
Aps a implantao do NMS, coletou-se novamente durante um perodo de
cinco dias teis as mesmas informaes, para avaliar a diferena percentual de trfego
gerado pela estao com e sem a presena do software de gerncia, para analisar a
insero de trfego por ele gerada na rede. Este artigo apresenta os resultados dessa
metodologia de testes no Captulo 4.6.
24
Implantao
A implantao da ferramenta se deu atravs da configurao do SNMP, NET-SNMP e

NRPE nas estaes, instalao e configurao do Nagios, configurao e, em
determinados casos, confeco de scripts ou plugins, necessrios para direcionar o
monitoramento e ajustes finais que se fizeram necessrios. Alm dessas etapas, um
perodo de testes e de observao de trfego foi necessrio para avaliar o impacto do
Nagios no cenrio proposto.
4.1
Configurao do SNMPv3
Para que o Nagios pudesse acessar dispositivos com suporte a SNMPv3, foi necessria a
instalao e configurao deste protocolo nas estaes gerenciadas. No servidor
Backup rodando o sistema operacional Windows XP SP2, essa tarefa ficou a cargo do
NET-SNMP verso 5.4.2 com suporte a SSL, alm dos programas Activeperl 5.10.0
Build 1004, Microsoft Visual C++ 2008 Redistributable Package (x86) e Openssl
v0.9.8i. O servio SNMP padro do Windows precisou ser instalado e posteriormente
desabilitado nas opes de Servios das Ferramentas Administrativas do Windows.
No arquivo C:\usr\etc\snmp\snmpd.conf foram adicionadas as entradas createUser
[usuario] MD5 [senha] DES [senha] e rouser [usurio] informando que o usurio
teria acesso somente leitura (rouser) e que utilizaria autenticao MD5 e criptografia
DES. Aps a configurao desse arquivo, registrou-se o NET-SNMP como um servio
do Windows com o comando C:\usr\registeragent.
Nos servidores proxy e firewall, ambos rodando linux, usou-se o NET-SNMP
verso 5.4.2.1. Para configurar o SNMPv3 nesses equipamentos editou-se o arquivo
/etc/snmp/snmpd.conf e foi adicionada a linha rouser [usurio] para especificar o
usurio que teria acesso somente leitura (se fosse necessrio especificar usurios com
acesso leitura e escrita a linha seria rwuser [usuario]).
Para adicionar o usurio somente leitura do snmp utilizou-se o comando netsnmp-config create-snmpv3-user ro A [senha] X [senha] a MD5 x DES
[usurio]. Neste comando, as opes -a e -A especificam respectivamente o tipo
de autenticao e senha definida para autenticao, enquanto as opes -x e -X
especificam o tipo de criptografia e a senha de criptografia definidas para o usurio
cadastrado no comando.
4.2
Configurao de NRPE_NT
Neste cenrio foi utilizado o NRPE_NT que a verso do NRPE para Windows. A
estao Backup teve esse programa instalado na sua verso NRPE_NT 0.8b, atravs
do comando nrpe_NT i, responsvel por configurar o protocolo como um servio do
Windows. Aps a instalao, foi editado o arquivo c:\nrpe_nt\bin\nrpe.cfg, onde
algumas opes foram configuradas para o correto acesso da estao de gerenciamento a
esse servidor. As alteraes relevantes feitas nesse arquivo ocorreram nos parmetros:
- server_port = 5666: definio da porta onde o servio NRPE receber as
solicitaes da estao de gerncia, por padro, a porta 5666. importante notar que
esta porta teve de ser liberada no firewall para que pudesse ser acessada remotamente.
25
- allowed_hosts = 127.0.0.1, 10.51.10.1: definio das estaes que podem

acessar o servio NRPE neste computador. Aqui deve-se notar tambm, que como
feito um NAT no firewall para pacotes vindos da rede interna para a DMZ, preciso
liberar o IP do firewall para acessar o servio.
- A seo Command Definitions, responsvel pela definio dos comandos que
sero configurados no arquivo commands.cfg e que sero referenciados pela estao
de gerncia. Os comandos cadastrados nesse arquivo, devem obrigatoriamente ter uma
referncia nesta seo. Geralmente os comandos dessa seo chamam Windows Script
Files ou Arquivos de Scripts do Windows, que so pequenos arquivos de extenso
WSF que executam os comandos solicitados na estao. Abaixo, vemos um exemplo de
como esses comandos so definidos no arquivo nrpe.cfg, e no Captulo 4.4 vemos
como criar esses scripts.
# Checar memria RAM disponvel. Warning se < 20% disponvel e critical se < 10%
command[check_ram]=c:\windows\system32\cscript.exe
/w:20 /c:10
//NoLogo
//T:10
c:\nrpe_nt\check_ram.wsf
Na linha acima, utilizado o comando cscript.exe, que interpreta e executa

scripts no ambiente de modo texto do Windows (MS-DOS). O comando wscript.exe,
possui a mesma funo, porm para interface grfica de usurio (GUI). A opo
//NoLogo impede que mensagens como Microsoft (R) Windows Script Host Version
5.6Copyright (C) Microsoft Corporation 1996-2000. All rights reserved. Sejam
exibidas na sada do comando, e a opo //T10 informa a quantidade mxima de
tempo em segundos que o comando pode rodar. Note-se que neste comando, como em
todos os demais comandos, o Nagios precisar ser informado do valor considerado
alarmante (warning) e do valor crtico (critical), para ter um limiar de ajuste a
necessidade do sistema monitorado. Como ser exibido no Captulo 4.10.3, quando uma
checagem de memria RAM for configurada no Nagios atravs de NRPE, a definio do
servio de checagem de memria no arquivo services.cfg precisa ter a entrada
check_command check_nrpe!check_RAM.
4.3
O Nagios
A implementao do Nagios, entre anlise do ambiente, definio das necessidades de

monitoramento, definio das ferramentas, implantao e testes no cenrio definido,
durou aproximadamente 3 meses. A verso do Nagios utilizada foi a 3.0.4 de Outubro
de 2008, conforme se v na Figura 7.
Figura 7 Tela principal do Nagios acessada via navegador
26
Na instalao do Nagios, tambm foram instalados seus plugins, cuja verso

utilizada foi a 1.4.13.
A estrutura de diretrios do Nagios est composta conforme mostra a tabela 7 abaixo:
Tabela 7 Estrutura de diretrios do Nagios
Diretrio
Descrio
/usr/local/nagios/bin
Arquivos executveis da aplicao.
/usr/local/nagios/etc
Arquivos de configurao da ferramenta. Na ltima verso 3.0.4, o arquivo

nagios.cfg (principal arquivo de configurao do programa) reside nesse diretrio,
enquanto os demais arquivos que podem ser segmentados, residem no diretrio
/usr/local/nagios/etc/objects.
/usr/local/nagios/libexec
Diretrio padro da instalao dos plugins do Nagios, como check_http,

check_smtp, etc. Os scripts desenvolvidos nesse artigo como check_errorrate_v3
(para analisar a taxa de erros de uma determinada interface de rede), tambm foram
adicionados a este diretrio.
/usr/local/nagios/sbin
Diretrio onde ficam armazenados os scripts em CGI10 que so utilizados na

interface web do Nagios, como por exemplo o statusmapo.cgi utilizado toda vez
que a funo de mapa de status da rede acionada via navegador.
/usr/local/nagios/share
Diretrio onde ficam armazenados os arquivos html e as imagens para serem

exibidas na interface web. As imagens dos servidores que devem aparecer no
statusmap
devem
estar
armazenadas
no
diretrio
/usr/local/nagios/share/images/logos.
/sr/local/nagios/var
Em geral, os arquivos de log da ferramenta so armazenados nesse diretrio.
4.3.1 Arquivos de configurao

O Nagios, assim como a grande maioria dos softwares que rodam na plataforma linux,
configurado atravs de diversos arquivos que podem ser modificados por um simples
editor de texto. Por definio, tudo o que o Nagios precisa para rodar o arquivo
nagios.cfg e algum outro arquivo que possua as definies dos hosts, servios,
contatos e demais objetos necessrios ao monitoramento do ambiente. Nesta
implementao o arquivo principal nagios.cfg foi configurado de forma a processar
diversos arquivos de configurao para deixar a implantao mais simples e organizada.
Os arquivos esto divididos entre os definidos por padro, durante a instalao
(nagios.cfg, resource.cfg e cgi.cfg) e os que foram criados com as definies de objetos
(timeperiods.cfg, commands.cfg, contacts.cfg, contactgroups.cfg, hosts.cfg, services.cfg
e hostextinfo.cfg).
4.3.2 Nagios.cfg
Este o principal arquivo de configurao do Nagios, que ir determinar o
comportamento do programa. Por padro, fica localizado no diretrio
/usr/local/nagios/etc. Este arquivo gerado durante a instalao do Nagios ao se rodar o
comando configure e efetivamente instalado ao rodar o comando make install-
10
CGI Common Gateway Interface Tecnologia que gera pginas dinmicas e que permite que um
navegador fornea parmetros para programas hospedados em servidores web. Os programas que
interpretam esses parmetros e geram as pginas aps o processamento so chamados scripts CGI.
27
config. lido tanto pelos processos do Nagios quanto pelos arquivos CGI. No cenrio
proposto, para que os demais arquivos pudessem ser processados, uma diretiva foi
inserida nesse arquivo para cada arquivo que deveria ser lido. Abaixo segue o exemplo
de uma linha inserida no nagios.cfg para que ele processasse o arquivo
commands.cfg:
cfg_file=/usr/local/nagios//etc/objects/commands.cfg
4.3.3 Resource.cfg
O arquivo de recurso ou resource file pode ser utilizado para definir as macros utilizadas
pelo usurio, que podem ser chamadas posteriormente nos demais arquivos de
configurao (geralmente no commands.cfg). Uma das macros definidas nesse arquivo
a macro $USER1$, que especifica o caminho onde encontram-se os plugins do
Nagios que so chamados nos comandos: $USER1$=/usr/local/nagios/libexec. O
arquivo de recursos tambm pode conter strings de conexo a bases de dados e outras
informaes importantes que no devem aparecer nos arquivos CGIs. Por motivos de
segurana, esse arquivo pode ter suas permisses definidas para 600 o que o tornar
acessvel apenas pelo seu dono. A diretiva resource_file, pode ser utilizada dentro do
arquivo nagios.cfg para especificar os arquivos de recursos que devem ser lidos pelo
programas, como mostra o exemplo abaixo:
resource_file=/usr/local/nagios//etc/resource.cfg
4.3.4 Cgi.cfg
Este arquivo contm uma srie de diretivas que determinam como funcionam as CGIs
como a diretiva physical_html_path, que indica o local onde ficam armazenadas as
pginas html do Nagios, permitindo que as imagens necessrias ao statusmap sejam
encontradas. Outras diretiva importante a use_authentication que permite definir se
as CGIs devem ou no utilizar autenticao para exibir as informaes de hosts e
servios.
4.3.5 Timeperiods.cfg
O arquivo timeperiods.cfg define blocos de tempo que servem como referncia para
os arquivos de definio de hosts, servios, contatos e dependncias no contexto de
horas operacionais ou perodos de inatividade. Abaixo apresentado o exemplo de uma
das definies do timeperiods do cenrio apresentado, referente carga horria de
trabalho semanal da empresa:
# 'workhours' definio de
define timeperiod{
timeperiod_name
alias
monday
tuesday
wednesday
thursday
friday
}
perodo
workhours
Horas de trabalho
08:00-17:45
08:00-17:45
08:00-17:45
08:00-17:45
08:00-17:45
28
4.3.6 Commands.cfg
Apesar de utilizar apenas duas diretivas em suas definies, este um dos arquivos mais
importantes do Nagios. O commands.cfg define como os comandos (que geralmente
so chamados pelo arquivo services.cfg), devem ser executados pelo NMS, qual o
nome pelo qual deve ser chamado e qual seu caminho de execuo. Como comentado
no arquivo resources.cfg, as macros definidas pelo usurio, tambm podem ser
utilizadas na sintaxe desse comando. Abaixo apresentado o exemplo de definio do
comando que checa a quantidade de usurios logados no computador no momento:
# 'check_local_users' command definition
define command{
command_name check_local_users
command_line
$USER1$/check_users -w $ARG1$ -c $ARG2$
}
De acordo com o comando acima, ser utilizado o plugin check_users que

encontra-se no caminho guardado apela macro $USER1$, provavelmente
/usr/local/anagios/libexec. Tambm possvel notar que o comando exige que seja
definido um valor de warning ou de alerta especificado pelo argumento w $ARG1$
e um valor critical ou crtico, especificado pelo argumento -c $ARG2$. Desta
maneira, o usurio pode definir no arquivo de servios, a estao que deseja checar e
valores que definem estados de alerta ou crtico, para diferentes dispositivos da rede.
Segue abaixo um novo exemplo, desta vez para o servio https:
# 'check_https' command definition
define command{
command_namecheck_https
command_line$USER1$/check_http --ssl -H $HOSTADDRESS$ -a $ARG1$
}
Desta vez, o plugin executado ser o check_http. possvel notar que neste
comando, alm da macro $USER1$ indicando o caminho onde se encontra o plugin,
tambm existe a macro $HOSTADDRESS$, que especifica qual o host no qual o
comando deve ser executado. O parmetro ssl indica que o servio http deve ser
testado numa porta SSL e o parmetro -a indica que deve-se testar autenticao, logo,
no argumento $ARG1$ devem ser fornecidos um nome e uma senha vlidas apara
autenticao no servidor web seguro.
4.3.7 Contacts.cfg
Este arquivo tem informaes relevantes sobre os contatos que devem receber as
notificaes do NMS. Define os perodos, opes e comandos de notificao para hosts
e servios. Abaixo apresentado o exemplo de um contato definido no arquivo
contacts.cfg.
define contact{
contact_name
use generic-contact
alias
email
}
nagiosadmin
Cristiano
cristiano@indigena.com.br
29
4.3.8 Contactgroups.cfg
Este arquivo organiza os contatos do Nagios em grupos, para facilitar a checagem de
hosts e servios que podem notificar grupos ao invs de contatos individuais. A
principal diretiva desse comando o members, onde sero especificados quais
usurios pertencero a esse grupo, como pode-se verificar no exemplo abaixo:
define contactgroup{
contactgroup_name
alias
members
}
admins
Nagios Administrators
nagiosadmin
4.3.9 Hosts.cfg
Este arquivo contm todas as definies para os equipamentos gerenciados no sistema,
incluindo diversas diretivas como o intervalo de checagem, intervalo necessrio para
testar um servio novamente, comandos de checagem dos dispositivos, opes de
notificao, grupos de contatos para o host, entre outras diversas opes. Neste cenrio,
este arquivo foi dividido em 5 (cinco) arquivos menores que so o windows.cfg,
linux.cfg, unix.cfg, router.cfg e isp.cfg, facilitando a administrao de
dispositivos com caractersticas semelhantes. Uma diretiva importantssima que precisa
ser considerada nesse arquivo a address, no qual tanto pode ser utilizado um nome
quanto um endereo IP. Se for definido um nome, problemas no servidor de DNS
podem fazer com que o Nagios no encontre o dispositivo monitorado. Por outro lado,
se for utilizado um IP, preciso estar atento as mudanas de endereamento que podem
acontecer na rede e que no mudam de forma dinmica. Abaixo apresentado um
exemplo de um host definido no arquivo linux.cfg.
define host{
name
use
check_period
check_interval
retry_interval
max_check_attempts
check_command
notification_period
notification_interval
notification_options
contact_groups
hostgroups
register
}
define host{
use
host_name
alias
address
parents
}
servlinux
generic-host
24x7
5
1
10
check-host-alive
workhours
120
d,u,r
admins
linux-servers
0
servlinux
proxy
Servidor Proxy
10.51.1.2
firewall
A diretiva parents, especifica a qual equipamento da rede esse servidor

considerado filho, permitindo que o Nagios organize-o abaixo de um ponto especfico
quando o statusmap da rede for gerado.
30
4.3.10 Services.cfg
O principal arquivo de configurao do Nagios, onde sero especificadas as sintaxes dos
plugins, quando devem ser rodados, com que freqncia, em quais servidores, a
quantidade de checagens que devem ser feitas antes de disparar um alarme, quais os
grupos de contatos, a quem avisar em caso de falhas, entre outras configuraes
relevantes. A diretiva mais importante do arquivo services.cfg a diretiva
check_command, pois ela determina como o host/servio deve ser monitorado.
Abaixo, sero apresentados alguns exemplos dessa diretiva utilizados nesse cenrio,
usando NRPE, SNMPv1 e SNMPv3, alm de mostrar opes para checagem de servios
comuns, como http, dns, smtp, entre outros (como os arquivos so absolutamente
dependentes, ser apresentada a diretiva check_command do arquivo services.cfg
conjuntamente com a diretiva command_line do arquivo commands.cfg).
define service{
use
host_name
service_description
is_volatile
check_period
max_check_attempts
normal_check_interval
retry_check_interval
contact_groups
notification_interval
notification_options
check_command
}
local-service
Proxy
Particao /var
0
24x7
3
5
1
admins
300
w,u,c,r
check_local_disk!20%!10%!/var
No exemplo acima, foi utilizado o plugin check_local_disk do Nagios, para

verificar a utilizao da partio /var do servidor Proxy, que a partio onde so
armazenados os arquivo de log do mesmo. A diretiva command_line do services.cfg
foi definida como: $USER1$/check_disk -w $ARG1$ -c $ARG2$ -p $ARG3$, onde
$ARG1$ equivale ao parmetro 20%, $ARG2$ equivale ao parmetro 10% e
$ARG3$ equivale ao parmetro /var. Na tabela abaixo sero apresentados exemplos
de outros comandos utilizados no cenrio proposto:
Tabela 8 Exemplos dos servios mais comuns utilizados nesse cenrio
Exemplos de servios monitorados com plugins do Nagios
Servio
command_line no
Commands.cfg
check_command no
Services.cfg
HTTP
$USER1$/check_http
$HOSTADDRESS$ $ARG1$
HTTPS
$USER1$/check_http --ssl -H check_https!nagios:nagios

$HOSTADDRESS$ -a $ARG1$
SSH
$USER1$/check_ssh
$HOSTADDRESS$
PING
$USER1$/check_ping
-H check_ping!100.0,20%!500.
$HOSTADDRESS$ -w $ARG1$ - 0,60%
c $ARG2$ -p 5
Observaes
-I check_http
$ARG1$ check_ssh
31
Este servio usa SSL, e

exige usurio e senha
vlidos no servidor
como parmetro
POP
$USER1$/check_pop
-H check_pop
$HOSTADDRESS$ $ARG1$
SMTP
$USER1$/check_smtp
-H check_smtp!mailweb!contat Para
este
servio
$HOSTADDRESS$ -U $ARG1$ - o!nagios
tambm foi utilizada
P $ARG2$
uma conta de e-mail
vlida no servidor
DNS
$USER1$/check_dns
-H check_dns!dns1
www.terra.com.br -s $ARG1$
Neste servio, a pgina

do Terra foi utilizada
para testar o DNS
Exemplos de servios monitorados no Windows com NRPE

Tempo
CPU
de $USER1$/check_nrpe
-H check_nrpe!check_cputime
$HOSTADDRESS$ -c $ARG1$
Espao
Disco C
no $USER1$/check_nrpe
-H check_nrpe!check_disk_c
Testar
processo
AVG
$USER1$/check_nrpe
-H check_nrpe!check_process_
avg
Quantidade
de Processos
$USER1$/check_nrpe
-H check_nrpe!check_qtd_proc
s
Exemplos de servios monitorados utilizando scripts personalizados
Quantidade
$USER1$/check_pktdiscard
check_pktdiscard!public!2!
de
pacotes $HOSTADDRESS$
$ARG1$ 1!2
descartados
$ARG2$ $ARG3$ $ARG4$
Quantidade
$USER1$/check_pktdiscard_v3
de
$ARG1$
descartados
$ARG2$
$ARG3$
$ARG4$
$ARG5$
$ARG6$
$ARG7$
$ARG8$ $ARG9$
SNMPv1
check_pktdiscard_v3!priv!n SNMPv3
agios!
MD5!senha8dig!DES!senha
8dig!2!1!2
Quantidade
$USER1$/check_icmperrors
check_icmperrors!public!1! SNMPv1
de
$ARG1$ 2
icmp
com $ARG2$ $ARG3$
erros
Quantidade
de
pacotes
icmp
com
erros
$USER1$/check_icmperrors_v3
$HOSTADDRESS$
$ARG1$
$ARG2$
$ARG3$
$ARG4$
$ARG5$
$ARG6$
$ARG7$
$ARG8$ $ARG9$
check_icmperrors_v3!priv!
nagios!
SNMPv3
MD5!senha8dig!DES!senha
8dig!2!1!2
possvel notar que nos plugins personalizados, a passagem de parmetros entra

as verses 1 e 3 do protocolo SNMP possui diferenas importantes. Enquanto no v1 a
autenticao feita pela comunidade public, no v3 os mesmos comandos devem
passar o tipo de autenticao (priv), um nome de usurio vlido no servidor (nagios), o
tipo de autenticao (MD5), a senha de autenticao (senha8dig), o protocolo de
criptografia (DES), e a senha de criptografia (senha8dig). Um exemplo de como o script
personalizado foi criado, pode ser visualizado no Captulo 4.5. Alm disso, importante
notar que com o uso de macros, alguns parmetros podem ser omitidos ao chamar o
comando. No exemplo do comando de checagem http, por exemplo a linha de comando
32
$USER1$/check_http -I $HOSTADDRESS$ $ARG1$ mas no arquivo services.cfg,

como a solicitao foi feita dentro de um servio que tinha o parmetro host_name, o
parmetro $HOSTNAME$ no precisa ser especificado novamente, bastando
configurar a diretiva check_command check_http para que o servio HTTP seja
testado no servidor correto.
4.3.11 Hostextinfo.cfg
As diretivas nesse arquivo podem ser definidas para hosts e servios e permitem que o
Nagios adicione informaes estendidas dos dispositivos monitorados. possvel, por
exemplo, especificar uma imagem para o dispositivo que ser utilizada no mapa da rede
desenhado pelo Nagios conhecido como Status Map. Abaixo pode ser observada a
adio de informaes estendidas ao servidor Proxy.
# Linux definition
define hostextinfo{
name
icon_image
icon_image_alt
vrml_image
statusmap_image
gd2_image
register
}
define hostextinfo{
use
linux
host_name proxy
}
linux
ubuntu40.jpg
linux
ubuntu40.jpg
ubuntu40.jpg
ubuntu40.jpg
0
Na Figura 8 abaixo, v-se um exemplo do Nagios Status Map, com as

informaes estendidas sobre os equipamentos definidas.
Figura 8 NAGIOS Status Map
4.4
Outras Funcionalidades
O Nagios possui diversas funes que auxiliam a tarefa de gerenciamento. Atravs da

sua interface web, possvel ter acesso a uma viso geral, bem como uma viso
detalhada de hosts e servios em execuo e em estado de falha, grupos de hosts e
grupos de servios, viso em grid e mapas da rede.
Alm disso, possibilita o acesso ao detalhamento de problemas nos servios e
dispositivos, emite diversos relatrios sobre os processos, downtime, disponibilidade,
33
notificaes, logs, configuraes, entre outras funcionalidades. Abaixo, vemos algumas

figuras que mostram parte dessas funcionalidades acessveis via interface web:
Figura 9 Tela de histrico de alertas do Nagios
Na Figura 9, vemos uma tela que mostra o histrico de alertas do Nagios, que
armazena informaes sobre os servios, quando o processo do Nagios foi reiniciado,
entre outras informaes relevantes. Na Figura 10 abaixo, v-se os grupos de hosts e
seus servios em forma de grid.
Figura 10 Tela de grupos de hosts e seus servios
Nas Figuras 11 e 12 abaixo, v-se todos os dispositivos com seus respectivos

status e como foram separados em grupos, indicando a quantidade de servios de cada
um deles.
Figura 11 Tela de status de todos os dispositivos
34
Figura 12 Tela de status dos hosts separados por grupos
A Figura 13 mostra em detalhes o host Servidor Proxy, seu endereo, status, a

quanto tempo o servidor est ativo, datas da ltima e da prxima checagem, tipo de
checagem, entre outras informaes.
Figura 13 Tela de detalhamento do Servidor Proxy
J nas Figura 14 abaixo, podemos verificar o histrico de notificaes enviadas pelo

Nagios.
Figura 14 Tela do histrico das notificaes enviadas
4.5
Criando Windows Script Files personalizados.
Usando-se os contadores de performance do Windows, possvel criar arquivos de

script personalizados, que buscam os valores desses contadores e podem ser acessveis
via NRPE. Abaixo, exibido um exemplo do script check_arqpag.wsf que checa o
35
tamanho do arquivo de paginao, alarmando se o valor de uso coletado for superior a

70% do valor total do arquivo de paginao, retornando um status vlido para o Nagios.
' check_arqpag.wsf
' Spk - cristiano@indigena.com.br - Moinhos de Trigo Indigena S.A. - MOTRISA
' Data da ltima modificao: 08/09/08
<job>
<runtime>
<description>
Mostra a quantidade percentual do arquivo de paginao. Alarmante quando estiver acima de 70% de uso.
</description>
<named
name="h"
helpstring="Help"
type="simple"
required="false"
/>
<named
name="w"
helpstring="Warning watermark (Integer)"
type="string"
required="true"
/>
<named
name="c"
helpstring="Critical watermark (Integer)"
type="string"
required="true"
/>
<example>
Example: check_arqpag.wsf /w:65 /c:70
</example>
</runtime>
<script language="VBScript">
If Wscript.Arguments.Named.Exists("h")
Or
Not
Wscript.Arguments.Named.Exists("w")
Or
Not
Wscript.Arguments.Named.Exists("c") Or (Wscript.Arguments.Named("w") >= Wscript.Arguments.Named("c"))
Then
Wscript.Arguments.ShowUsage()
Wscript.Quit(0)
End If
' Constantes e variaveis
Const intOK = 0
Const intWarning = 1
Const intCritical = 2
Const intUnknown = 3
' Script para retornar o valor do uso do arquivo de paginacao
strComputer = "."
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")
' Coletor do objeto Arquivo de paginao _total
Set colArquivoPaginacao = objWMIService.ExecQuery _
("Select * from Win32_PerfFormattedData_PerfOS_PagingFile " _
& "Where Name = '_Total'")
' Seta variavel intValor com valor do percentual do arquivo de paginacao
For Each objItem in colArquivoPaginacao
intValor = objItem.PercentUsage
Next
If intValor > CInt(Wscript.Arguments.Named("c")) Then
Wscript.Echo "Percentual do Arquivo de Paginacao CRITICO = " & Int(intValor) & "%"
Wscript.Quit(intCritical)
End if
If intValor > CInt(Wscript.Arguments.Named("w")) Then
Wscript.Echo "Percentual do Arquivo de Paginacao ALERTA = " & Int(intValor) & "%"
36
Wscript.Quit(intWarning)
End if
Wscript.Echo "Percentual do arquivo de paginacao NORMAL = " & Int(intValor) & "%"
Wscript.Quit(intOK)
</script>
</job>
Este
script
teve
a
linha
command[check_arqpag]=c:\windows\system\cscript.exe
////NoLogo
//T:10
c:\nrpe_nt\check_arqpag.wsf
/w:65
/c:70
adicionada
no
arquivo
C:\nrpe_nt\bin\nrpe.cfg da estao Windows e no arquivo services.cfg do servidor
Nagios, a diretiva check_command teve seu valor como check_nrpe!check_arqpag.
4.6
Criando plugins personalizados
No servidor Nagios tambm possvel criar plugins personalizados, que buscam os

valores da MIB via SNMP e retornam os clculos desejados. Abaixo, exibido um
exemplo do script check_errorrate_v3 que checa a taxa de erros dos pacotes de uma
interface especificada, retornando um status vlido para o Nagios.
#!/bin/sh
# Autor
: Spk <cgborges@gmail.com>
# Date
: 29 Out 2008
# Descrio : Script que checa a taxa de erros dos pacotes na interface ethernet
# Verifica se houve uma entrada
if [ -z "$1" ]; then
echo "utilizao : check_errorrate_v3 <hostname> <seclevel> <user> <authproto> <authpasswd>
<privproto> <privpasswd> <interface> <warn-level> <crit-level>"
echo "example: check_errorrate_v3 192.168.1.1 priv admin MD5 senha8dig DES senha8dig 2 1 2"
echo
exit
fi
# Variveis
SERVER=$1
# Exemplo: 10.0.0.3
SECLEVEL=$2
# Exemplo: priv
USER=$3
# Exemplo: admin
AUTHPROTO=$4
# Exemplo: MD5
AUTHPASSWD=$5
# Exemplo: senha8dig
PRIVPROTO=$6
# Exemplo: DES
PRIVPASSWD=$7
# Exemplo: senha8dig
ETH=$8
# Exemplo: 2,3 (interface number)
WARN=$9
# Exemplo: "1" Warning
CRIT=$10
# Exemplo: "2" Critical
# busca dos valores na mib2
TOTAL=0
# Busca descrio da interface especificada
PLACA=`/usr/bin/snmpget -v 3 -l $SECLEVEL -u $USER -a $AUTHPROTO -A $AUTHPASSWD -x
$PRIVPROTO
-X
$PRIVPASSWD
$SERVER
.iso.org.dod.internet.mgmt.mib2.interfaces.ifTable.ifEntry.ifDescr.$ETH -t 5 |grep $ETH |awk ' { print $4" "$5" "$6 }'`
# Busca valor dos pacotes unicast de entrada da interface
IfInUcastPkts=`/usr/bin/snmpget -v 3 -l $SECLEVEL -u $USER -a $AUTHPROTO -A $AUTHPASSWD
-x
$PRIVPROTO
-X
$PRIVPASSWD
$SERVER
.iso.org.dod.internet.mgmt.mib2.interfaces.ifTable.ifEntry.ifInUcastPkts.$ETH -t 5 |grep $ETH |awk ' { print $4 }'`
# Busca valor dos pacotes unicast de sada da interface
37
IfOutUcastPkts=`/usr/bin/snmpget -v 3 -l $SECLEVEL -u $USER -a $AUTHPROTO -A

$AUTHPASSWD -x $PRIVPROTO -X $PRIVPASSWD $SERVER .iso.org.dod.internet.mgmt.mib2.interfaces.ifTable.ifEntry.ifOutUcastPkts.$ETH -t 5 |grep $ETH |awk ' { print $4 }'`
# Busca valor dos pacotes no unicast de entrada da interface
IfInNUcastPkts=`/usr/bin/snmpget -v 3 -l $SECLEVEL -u $USER -a $AUTHPROTO -A
$AUTHPASSWD -x $PRIVPROTO -X $PRIVPASSWD $SERVER .iso.org.dod.internet.mgmt.mib2.interfaces.ifTable.ifEntry.ifInNUcastPkts.$ETH -t 5 |grep $ETH |awk ' { print $4 }'`
# Busca valor dos pacotes no unicast de sada da interface
IfOutNUcastPkts=`/usr/bin/snmpget -v 3 -l $SECLEVEL -u $USER -a $AUTHPROTO -A
$AUTHPASSWD -x $PRIVPROTO -X $PRIVPASSWD $SERVER .iso.org.dod.internet.mgmt.mib2.interfaces.ifTable.ifEntry.ifOutNUcastPkts.$ETH -t 5 |grep $ETH |awk ' { print $4 }'`
# Busca valor dos pacotes com erros de entrada da interface
IfInErrors=`/usr/bin/snmpget -v 3 -l $SECLEVEL -u $USER -a $AUTHPROTO -A $AUTHPASSWD -x
$PRIVPROTO
-X
$PRIVPASSWD
$SERVER
.iso.org.dod.internet.mgmt.mib2.interfaces.ifTable.ifEntry.ifInErrors.$ETH -t 5 |grep $ETH |awk ' { print $4 }'`
# Busca valor dos pacotes com erros de sada da interface
IfOutErrors=`/usr/bin/snmpget -v 3 -l $SECLEVEL -u $USER -a $AUTHPROTO -A $AUTHPASSWD x
$PRIVPROTO
-X
$PRIVPASSWD
$SERVER
.iso.org.dod.internet.mgmt.mib2.interfaces.ifTable.ifEntry.ifOutErrors.$ETH -t 5 |grep $ETH |awk ' { print $4 }'`
# calcula o total de pacotes transitados na interface
TOTAL=$(($IfInUcastPkts+$IfOutUcastPkts+$IfInNUcastPkts+$IfOutNUcastPkts))
# calcula o total de pacotes com erros
ERRORS=$(($IfInErrors+$IfOutErrors))
# zera a varivel percente
PERCENTE=0
# calcula o percentual de pacotes com erros caso $errors no seja 0
if [ "$ERRORS" > 0 ] ; then
PERCENTE=$(($ERRORS*100/$TOTAL))
fi
# informa ao nagios os valores calculados e retorna um exitstatus
# se a taxa de erros for maior ou igual ao valor critico
if [ $PERCENTE -ge $CRIT ]; then
echo "Percentual de Pacotes com erros em $PLACA CRITICO = $PERCENTE %"
exitstatus=2
# se a taxa de erros for maior ou igual ao warning mas menor que o critico
elif [ $PERCENTE -ge $WARN ] && [ $PERCENTU -lt $CRIT ]; then
echo "Percentual de Pacotes com erros em &PLACA ALERTA = $PERCENTE %"
exitstatus=1
# se a taxa de erros for menor do que o warning
elif [ $PERCENTE -lt $WARN ]; then
echo "Percentual de Pacotes com erros em $PLACA NORMAL = $PERCENTE %"
exitstatus=0
else
echo "Percentual de Pacotes com erros em $PLACA UNKNOWN = $PERCENTE %"
exitstatus=3
fi
exit $exitstatus
4.7
Resultado dos testes
Com o perodo de coleta realizado aps a implantao do Nagios, foi observado que o
trfego em MB inserido na rede, que na primeira coleta teve uma mdia de 48,3MB
dirios trafegados na interface eth0, teve como mdia 127,5 MB dirios no perodo da
segunda coleta, havendo um aumento de trfego de 163,98%. Se considerarmos a
quantidade de pacotes, o acrscimo foi de 117,78%, comparando-se os 228.941,4
pacotes em mdia coletados na primeira medio contra a mdia de 498.588 pacotes
38
dirios do segundo perodo de coleta. O trfego de pacotes deste servidor aps a

implantao do Nagios pode ser classificado como absolutamente satisfatrio, se
considerarmos que sua mdia de trfego diria pode ser comparada a 0,08% do que
trafega na interface LAN do roteador que tem mdia diria de trfego na casa dos
613.448.059 pacotes, ou 0,02% do que trafega na interface eth1 do firewall que tem
mdia de 2.737.904.179 pacotes dirios.
Quanto distribuio de pacotes TCP, UDP e ICMP na rede, percebe-se um
aumento significativo no trfego dos protocolos UDP e ICMP em detrimento do TCP,
conforme pode ser observado na Figura 15 abaixo.
Distribuio de Trfego aps implantao (%)
98,64
100
90
80
70
59,1
60
Regular
50
Com Nagios
34,9
40
30
20
6
1,32
0,04
10
0
TCP
UDP
ICMP
Figura 15 Distribuio de trfego aps implantao
No que tange ao trfego dos protocolos, nota-se que com a implantao do

Nagios no cenrio monitorado, o protocolo de maior trfego foi justamente o SNMP,
como mostra a Figura 16 logo a seguir:
Figura 16 Distribuio do Trfego (%)
39
Concluso
Este artigo procurou apresentar a importncia de uma ferramenta de gerncia num

ambiente corporativo. Caracterizou-se um NMS, as atividades de gerenciamento, as
reas funcionais e arquiteturas de gerncia, os tipos e mtricas de gerenciamento, bem
como uma compilao das melhores prticas de gerncia para ambientes profissionais.
Caracterizou-se tambm o Nagios como uma soluo de gerncia de baixo custo e muito
eficiente, trazendo uma implantao do mesmo num ambiente real, detalhando o cenrio
proposto, os arquivos de configurao da ferramenta, criao de scripts e plugins para
implementao e demais configuraes relevantes para compreenso e detalhamento do
cenrio. Por fim, foi exibido o percentual de trfego que esta ferramenta inseriu na rede
e como este trfego est caracterizado.
O Nagios, uma ferramenta indispensvel para os departamentos de TI atuais
que alm de se preocuparem cada vez mais com pr-atividade e cada vez menos com a
rotineira misso de apagar incndios dirios, tm tambm a crescente preocupao
com o custo-benefcio de suas aplicaes. Pode se adequar a ambientes micros ou
macros, devido simplicidade dos seus arquivos de configurao. Sua modularidade,
permitiu que fossem criados scripts para verificar a taxa de pacotes descartados das
interfaces, erros de pacotes icmp com destino inalcanvel, pacotes IP descartados, entre
outras inmeras medies relevantes no cenrio proposto, atravs do SNMPv3.
Atravs da sua ferramenta NRPE, possibilitou a coleta de valores dos contadores
de desempenho de estaes Windows, executando scripts que permitiram monitorar o
comprimento da fila do processador, a quantidade de pginas por segundo da memria,
a mdia sobre transferncia de disco, entre outras informaes relevantes para a boa
sade dos dispositivos gerenciados. O Nagios gera diversos tipos de relatrios, mapas da
rede e detalha a situao de seus hosts e servios gerenciados. A mdia de trfego
gerado pelo Nagios na rede foi muito pequena, no chegando a 1% do trfego da
interface de rede interna do firewall, por exemplo, e foi caracterizada principalmente
pela insero do SNMP, que representou 58,1% do trfego gerado pelo Nagios.
Sua implementao porm, exige um estudo detalhado do ambiente, pois a
ingerncia sobre determinados recursos bem como informaes escassas para a
implantao, podem resultar numa ferramenta problemtica e que gera informaes no
confiveis, fazendo que o administrador da rede torne-se descuidado. A linha que separa
um NMS que envia muitas informaes sobre dados irrelevantes de outro que envia
informaes relevantes muito tnue, e um bom estudo do cenrio antes e durante a
implantao da ferramenta, bem como uma rotina de testes e coleta de informaes aps
a etapa final, faz-se necessria para o sucesso da implantao.
Por fim, interessante sugerir a continuao desse artigo, num ambiente maior e
com mais dispositivos a serem gerenciados. No prprio Grupo MOTRISA, a insero
das unidades filiais do Nordeste neste cenrio, alterando o tipo de administrao de
centralizada para distribuda, permitiria uma viso melhorada da rede da empresa como
um todo, provendo informaes em tempo real sobre toda a extenso da rede e no
apenas da rede da matriz. Alm disso, na matriz em Porto Alegre, faz-se necessria a
adoo de equipamentos que suportem o protocolo SNMPv3, principalmente nos
roteadores, eliminando os riscos corridos ao executar atividades de gerncia.
40
Referncias Bibliogrficas
Andrade, H.A. (2006) Nagios como Soluo de Monitoramento de Rede. Universidade

Federal de Lavras, Lavras. Monografia exigida para ttulo de especialista da Ps
Graduao Lato Sensu de Administrao em Redes Linux.
Barth, W. (2006) Nagios, System and Network Monitoring. Munique, editora Open
Source Press GmbH.
CISCO ITO (2008) CISCO Internetworking Technology Handbook. Disponvel em
http://www.cisco.com/en/US/docs/internetworking/technology/handbook/ito_doc.html,
acessado em outubro 2008.
Freitas, C.A. Monteiro, J.W.A (2004) Anlise de Protocolos na rea de Gerncia de
Redes (SNMP/RMON). Universidade Federal de Gois, Escola de Engenharia Eltrica e
de Computao, Goinia. Projeto Final de Curso.
Galstad, E. (2007) Nagios Version 3.X Documentation.
Granville, L.Z. (2005) Gerenciamento de Redes TCP/IP. Universidade do Vale do Rio
dos Sinos, So Leopoldo.
Lopes, R.V. Sauv, J.P. Nicolletti, P.S. (2003) Melhores Prticas para a Gerncia de
Redes de Computadores. So Paulo, editora Campus.
Josephsen, D. (2007) Building a Monitoring Infrastructure with Nagios. Boston, editora
Prentice Hall.
Mauro, D. Schmidt, K. (2001) Essential SNMP. Sebastopol, editora OReily.
Microsoft (2008) Ajuda e Suporte. Disponvel em http://support.microsoft.com/
acessado em junho 2008.
MSDN (2008) Microsoft Developer Network Performance Counter Classes. Disponvel
em http://msdn.microsoft.com/en-us/library/aa392738(VS.85).aspx acessado em junho
2008.
Microsoft TechNet SQL (2008) Microsoft SQL Server 2000 RDBMS Performance
Tuning
Guide
for
Data
Warehousing.
Disponvel
em
http://www.microsoft.com/technet/prodtechnol/sql/2000/maintain/rdbmspft.mspx
acessado em julho 2008.
Santos, F.J.J. (2004) Sistema de Gerenciamento de Redes Baseado em Conhecimento.
Universidade Federal de Lavras, Lavras. Monografia exigida para ttulo de especialista
da Ps Graduao Lato Sensu de Administrao em Redes Linux.
Santos, M.T. (2008) Tpicos Avanados em Administrao de Redes e TI. Disponvel
em http://www.ucb.br/prg/professores/maurot/AGR/AGR.htm, acessado em outubro
2008.
Santos, M.T. (2008) Ferramentas e Sistemas de Gerenciamento. Disponvel em
http://www.ucb.br/prg/professores/maurot/AGR/AGR.htm, acessado em outubro 2008.
Turnbull, J. (2006) Pro Nagios 2.0. Nova Yorque, editora Apress.
41

Artigo - NMS

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Artigo - NMS

Caricato da

Copyright:

Formati disponibili

Implantao de um NMS Network Monitoring System

num Ambiente Corporativo

Resumo. O objetivo deste artigo desenvolver um estudo sobre a implantao

So 3:00hs da manh, quando o administrador de uma rede despertado pelo toque do

Ao invs de ter recebido uma ligao as 3:00hs da manh, o administrador da

Um Sistema de Gerenciamento de Redes baseia-se no conceito de que problemas, cedo

NMS bastante oportuno que se cogite tambm a implementao de um sistema

Por que gerenciar?

Para os administradores de redes o fato da rede estar no ar e rodando no o suficiente.

principais podemos citar o alto nvel de manuteno da sade da rede, assegurando

pode fornecer informaes detalhadas sobre a rede aos administradores, de modo

mostra onde esto os gargalos da rede;

uma ferramenta imprescindvel para quem tem contratos de servios em

economiza tempo, dinheiro e traz estabilidade para ambientes complexos;

controla os limites dos canais, o uso, a performance e o trfego, alm de executar

avisa sobre problemas causados por sistemas sobrecarregados, servidores

reas funcionais de gerenciamento

A International Standards Organization (ISO) dividiu as diversas atividades das redes

Gerenciamento de Configurao, Gerenciamento de Segurana e Gerenciamento de

O gerenciamento de falhas corresponde rea funcional que permite que operaes

Gerenciamento de Performance ou Desempenho

O gerenciamento de performance corresponde a um conjunto de funcionalidades que

O gerenciamento de configurao corresponde a um conjunto de funcionalidades que

O gerenciamento de segurana corresponde a um conjunto de funcionalidades

Limiares, valores mximos aceitveis.

O gerenciamento de contabilizao corresponde a um conjunto de funcionalidades que

De um modo geral a arquitetura de um sistema de gerenciamento composta por quatro

Elementos gerenciados (agentes);

Estaes de gerncia (gerentes);

Protocolos de gerenciamento (SNMP);

Base de informaes gerenciais (MIBs).

O modelo de um sistema de gerenciamento exemplificado na Figura 1 abaixo:

Figura 1 - Modelo de Arquitetura de Gerenciamento

A seguir veremos a funo destes elementos dentro da arquitetura de

Os elementos gerenciados so dotados de um software denominado Agente, que o

IOS ou Internetwork Operating System um software com funes de roteamento, switching,

automaticamente, em intervalos previamente determinados, processo esse conhecido

As estaes de gerncia so dotadas de um software denominado Gerente,

Apesar das estaes de gerncia e os elementos gerenciados terem funes especficas e

Get-request: mensagens enviadas pelo gerente aos agentes solicitando

Get-next-request: mensagens enviadas pelo gerente aos agentes

Set-request: mensagens enviadas pelo gerente aos agentes solicitando a

Get-response: mensagens enviadas pelos agentes ao gerente em

Traps: mensagens enviadas pelos agentes ao gerente informando sobre

Apesar do SNMPv1 prever um servio de autenticao que d suporte a vrios

SNMPv3 ter maiores avanos em segurana, tambm tm como desvantagem, o fato de

Nmero de troca de mensagens

Baixo (com get-bulk)

Baixo (com get-bulk)

Base de Informaes Gerenciais

A base de informaes gerenciais um dos fatores mais importantes em um sistema de

Figura 2 Exemplo de Estrutura Hierrquica da MIB

A administrao do sistema de gerenciamento pode ser centralizada, hierrquica ou

O uso de um NMS no ambiente corporativo visa promover o melhor aproveitamento dos

esto mais interessados no quo corretamente essas aplicaes e servios complexos

Caractersticas desejveis de um NMS

Um sistema de monitoramento de rede uma ferramenta complexa e por vezes exige

algum superior ao administrador da rede, e assim sucessivamente at a regularizao

Melhores prticas de monitoramento

Um NMS monitora os elementos crticos de uma rede em nvel de software e hardware,

Para distinguir um sistema de monitoramento eficiente dos demais, precisa-se avaliar o

Processamento local x processamento remoto

Muitos sistemas de monitoramento trabalham com o conceito de plugins, ou seja,

Consideraes sobre o uso de plugins redundantes