Artigo - NMS

1

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 [email protected], [email protected]

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.

1 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.

2

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.

2 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

3

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

4

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,

5

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.

1 Limiares, valores mximos aceitveis.

6

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.

7

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

8

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

4 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).

9

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

SNMPv1 SNMPv2 SNMPv3

Nmero de troca de mensagens Elevado Baixo (com get-bulk) Baixo (com get-bulk) Suporte a gerenciamento distribudo

Inexistente Difcil Difcil

Aspectos de segurana

Baixa Baixa Alta

2.4.4 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

10

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

11

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.

12

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.

13

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

7 Programas maliciosos como virus, trojans, backdoors, rootkits, etc.

14

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:

8 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.

Estatstica das Plataformas onde o Nagios foi Implantado

28%

20%11%

9%

8%

6%

4%3% 3%

3% 2% 1% 2%

RedhatDebianSuseFedoraFreeBSDLinux (Outros)SolarisGentooMandrakeOutrosSlackwareOpenBSDTodos os outros

Figura 3 Estatstica das plataformas onde o Nagios foi Implantado

15

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.

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

Tipos de Empresas que usam o Nagios

15%

16%

9%8%6%5%

5%4%

4%3%

3%3%

19%

ISPConsultoria (TI)No especificadoOutrosTelecomunicaesGovernoSade / MedicinaEducao SuperiorEducao / TreinamentoManufatura (Geral)ASPBancos / FinanasTodos os outros

16

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,

17

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.

3 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

9 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.

18

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

19

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. 6 6 254 14

Hosts em Uso 3 2 14 4

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

20

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

21

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 SNMP Nagios

Radio (200.143.84.1) PING X DNS1 (200.143.84.2) DNS X DNS2 (200.143.84.3) DNS X

MAIL/WEB (200.143.84.32) POP X SMTP X

HTTP X

ROUTER (10.51.2.6/29) PING X HTTPS X

Taxa de pacotes descartados na interface X

Taxa de erros nos pacotes de entrada e sada da interface X

Quantidade de pacotes icmp da interface X Taxa de pacotes icmp com erros X

Taxa de pacotes icmp com destino inalcanvel X

Taxa de pacotes IP descartados X

Taxa de pacotes IP com erros de endereamento X

Taxa de pacotes IP com protocolos desconhecidos X

Taxa de pacotes IP sem rota X

Taxa de pacotes IP com erros de remontagem X

Taxa de pacotes IP com erros de fragmentao X

FIREWALL (10.51.1.1/29) PING X USERS X

DISCO "/" X

LOAD X

SSH X

Taxa de pacotes descartados na interface eth1 X



Taxa de erros nos pacotes de entrada e sada da eth1 X



22

Taxa de pacotes icmp com erros X

Taxa de pacotes icmp com destino inalcanvel X


Taxa de pacotes IP com erros de cabealho X






Taxa de falhas nas tentativas de conexo TCP X

PROXY (10.51.1.3/29) PING X PROCS X

USERS X

DISCO "/" X

Disco "/usr" X

Disco "/var" X

LOAD X

HTTPS X

SSH X


Taxa de erros nos pacotes de entrada e sada na interface X









NAGIOS (10.51.1.3/29) PING X PROCS X

USERS X

DISCO "/" X

DISCO "/var" X

DISCO "/usr" X

LOAD X

HTTPS X

SSH X


23



APLICAO (10.51.1.4/29) PING X PROCS X

USERS X

DISCO "/" X

LOAD X





ROUTER_WIFI (10.51.10.14/24) PING X BACKUP (10.51.10.15/24) PING X

FTP X

DISCO C: X

Tempo de CPU X

RAM X

Processo Explorer X

Processo AVG X

Processo AVG Update X

Processo AVG Firewall X

Quantidade de processos rodando X Memria Disponvel X

Gargalo de memria X

Quantidade de pginas por segundo X Quantidade de falhas de pool no paginvel X Quantidade de pginas de pool paginado X

Quantidade em MB de pool no paginado usado pelo servidor X

Comprimento da fila de processador X

Media de Disco sobre transferncia X

Tempo de fila de disco X

Quantidade de Bytes por segundo X Quantidade de comandos atuais no redirector X Taxa de pacotes descartados na interface X





24






IPFRAGFAILS X

TCPFAILATTEMPTS X

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.

25

4 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 net-snmp-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.

26

- 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 //NoLogo //T:10 c:\nrpe_nt\check_ram.wsf /w:20 /c:10

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

27

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.

28

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 perodo define timeperiod{ timeperiod_name workhours alias Horas de trabalho monday 08:00-17:45 tuesday 08:00-17:45 wednesday 08:00-17:45 thursday 08:00-17:45 friday 08:00-17:45 }

29

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_name check_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 nagiosadmin

use generic-contact alias Cristiano email [email protected] }

30

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 admins alias Nagios Administrators members 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 servlinux use generic-host check_period 24x7 check_interval 5 retry_interval 1 max_check_attempts 10 check_command check-host-alive notification_period workhours notification_interval 120 notification_options d,u,r contact_groups admins hostgroups linux-servers register 0 } define host{ use servlinux host_name proxy alias Servidor Proxy address 10.51.1.2 parents 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.

31

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 local-service host_name Proxy service_description Particao /var

is_volatile 0 check_period 24x7 max_check_attempts 3 normal_check_interval 5 retry_check_interval 1 contact_groups admins notification_interval 300 notification_options w,u,c,r check_command 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

Observaes

HTTP $USER1$/check_http -I $HOSTADDRESS$ $ARG1$

check_http

HTTPS $USER1$/check_http --ssl -H $HOSTADDRESS$ -a $ARG1$

check_https!nagios:nagios

Este servio usa SSL, e exige usurio e senha vlidos no servidor como parmetro

SSH $USER1$/check_ssh $ARG1$ $HOSTADDRESS$

check_ssh

PING $USER1$/check_ping -H $HOSTADDRESS$ -w $ARG1$ -c $ARG2$ -p 5

check_ping!100.0,20%!500.0,60%

32

POP $USER1$/check_pop -H $HOSTADDRESS$ $ARG1$

check_pop

SMTP $USER1$/check_smtp -H $HOSTADDRESS$ -U $ARG1$ -P $ARG2$

check_smtp!mailweb!contato!nagios

Para este servio tambm foi utilizada uma conta de e-mail vlida no servidor

DNS $USER1$/check_dns -H www.terra.com.br -s $ARG1$

check_dns!dns1 Neste servio, a pgina do Terra foi utilizada para testar o DNS

Exemplos de servios monitorados no Windows com NRPE

Tempo de CPU

$USER1$/check_nrpe -H $HOSTADDRESS$ -c $ARG1$

check_nrpe!check_cputime

Espao no Disco C


check_nrpe!check_disk_c

Testar processo AVG


check_nrpe!check_process_avg

Quantidade de Processos


check_nrpe!check_qtd_procs

Exemplos de servios monitorados utilizando scripts personalizados

Quantidade de pacotes descartados

$USER1$/check_pktdiscard $HOSTADDRESS$ $ARG1$ $ARG2$ $ARG3$ $ARG4$

check_pktdiscard!public!2!1!2

SNMPv1

Quantidade de pacotes descartados

$USER1$/check_pktdiscard_v3 $HOSTADDRESS$ $ARG1$ $ARG2$ $ARG3$ $ARG4$ $ARG5$ $ARG6$ $ARG7$ $ARG8$ $ARG9$

check_pktdiscard_v3!priv!nagios!

MD5!senha8dig!DES!senha8dig!2!1!2

SNMPv3

Quantidade de pacotes icmp com erros

$USER1$/check_icmperrors $HOSTADDRESS$ $ARG1$ $ARG2$ $ARG3$

check_icmperrors!public!1!2

SNMPv1

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!

MD5!senha8dig!DES!senha8dig!2!1!2

SNMPv3

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

33

$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 linux icon_image ubuntu40.jpg icon_image_alt linux vrml_image ubuntu40.jpg statusmap_image ubuntu40.jpg gd2_image ubuntu40.jpg register 0 } define hostextinfo{ use linux host_name proxy

} 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,

34

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

35

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

36

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 - [email protected] - Moinhos de Trigo Indigena S.A. - MOTRISA ' Data da ltima modificao: 08/09/08 Mostra a quantidade percentual do arquivo de paginao. Alarmante quando estiver acima de 70% de uso. Example: check_arqpag.wsf /w:65 /c:70 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) & "%"

37

Wscript.Quit(intWarning) End if Wscript.Echo "Percentual do arquivo de paginacao NORMAL = " & Int(intValor) & "%" Wscript.Quit(intOK)

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 # Date : 29 Out 2008 # Descrio : Script que checa a taxa de erros dos pacotes na interface ethernet # Verifica se houve u

Documents

Artigo - NMS