OPENAMSH: AGENTE DE MONITORAMENTO DE SERVIÇOS E HARDWARE

Transcrição

1 CENTRO ESTADUAL DE EDUCAÇÃO TECNOLÓGICA PAULA SOUZA FACULDADE DE TECNOLOGIA DE LINS CURSO SUPERIOR DE TECNOLOGIA EM REDES DE COMPUTADORES HENRIQUE RAMON FERNANDEZ BRITES OPENAMSH: AGENTE DE MONITORAMENTO DE SERVIÇOS E HARDWARE LINS/SP 1º SEMESTRE/2011

2 CENTRO ESTADUAL DE EDUCAÇÃO TECNOLÓGICA PAULA SOUZA FACULDADE DE TECNOLOGIA DE LINS CURSO SUPERIOR DE TECNOLOGIA EM REDES DE COMPUTADORES HENRIQUE RAMON FERNANDEZ BRITES OPENAMSH: AGENTE DE MONITORAMENTO DE SERVIÇOS E HARDWARE Trabalho de Conclusão de Curso apresentado à Faculdade de Tecnologia de Lins para obtenção do Título de Tecnólogo em Redes de Computadores. Orientador: Prof. Me. Alexandre Ponce LINS/SP 1º SEMESTRE/2011

3 Brites, Henrique Ramon Fernandez B862 OpenAMSH: agente de monitoramento de serviços e hardware / Henrique Ramon Fernandez Brites. Lins, f.: il. Monografia (Trabalho de Conclusão de Curso de Tecnólogo em Redes de Computadores) Faculdade de Tecnologia de Lins, Orientador: Prof. Me. Alexandre Ponce de Oliveira 1. Monitoramento. 2. Gerenciamento. 3. Redes. I. Oliveira, Alexandre Ponce. II. Faculdade de Tecnologia de Lins. III. Título. CDD Ficha elaboradora pela Biblioteca da Faculdade de Tecnologia de Lins

4

5 Aos meus pais, Maria Aparecida e João. As minhas avós Malvina, in memorian e Dora. A minha namorada Dianila pelo apoio e incentivo.

6 AGRADECIMENTOS Agradeço a meus amigos de sala pelo constante compartilhamento de conhecimento e pelo incentivo nos momentos difíceis. Durante todo trajeto do curso, fomos uma equipe! Agradeço também ao nosso diretor Dr. Luciano S. de Souza, ao então coordenador de curso, professor Me. Rogério P. Alexandre e aos demais envolvidos no esforço para que o curso de Redes de Computadores fosse oferecido no momento em que este fora dado como postergado por um semestre. Agradeço ao professor Me. Alexandre P. de Oliveira pela orientação e paciência durante a elaboração desse trabalho. Agradeço também a dedicação e contribuição dos professores que tive durante a faculdade. Agradeço aos meus amigos de trabalho professor Espec. Guilherme Neto, professor Me. Gilberto Astolfi e professor Dr. Fernando Micali pelas opiniões dadas e pela prontidão e disposição em sanar minhas duvidas. Por fim, agradeço especialmente a minha família e a minha namorada Dianila pela paciência e fundamental apoio durante a elaboração desse trabalho. Obrigado.

7 RESUMO Este trabalho tem como objetivo geral o desenvolvimento de um componente para monitoramento de redes de computadores hardware e serviços na rede de forma centralizada. Dentre os objetivos específicos estão: desenvolver um componente para monitoramento de redes que possa ser integrado a aplicações que necessite desse tipo de tarefa; propor uma arquitetura que possibilite o monitoramento de redes remotas de forma segura e simplificada; desenvolver agentes que sejam de fácil configuração nas máquinas clientes; apresentar as formas de monitoramento mais tradicionais. O corpus é resultado de uma pesquisa e analise das necessidades referentes a monitoramento de ambientes de redes heterogêneos. Focalizou-se, primeiramente, em propor uma arquitetura segura, de fácil configuração e que possibilite o monitoramento de redes fisicamente e logicamente distintas. O desenvolvimento deste trabalho apresenta a implementação de um componente formado por duas partes, agente e gerente, onde o inicio da comunicação se da na parte agente, possibilitando manter toda configuração de monitoramento centralizada na parte gerente, assim como os resultados de verificações e o estado de cada serviço ou recurso monitorado. O componente desenvolvido também tem como característica a necessidade de manter uma única porta de conexão aberta, na parte gerente, para o funcionamento de todo o monitoramento. Palavras-chave: Monitoramento, gerenciamento, redes.

8 ABSTRACT The general objective of this paperwork is to develop a component to monitor computer networks hardware and network services in a centralized manner. Among the specific objectives are: developing a component for network monitoring, which could be integrated to applications that need this kind of task; proposing a monitoring architecture that enables a safe and simplified monitoring for remote networks; developing agents easily set up on clients workstations; presenting more traditional monitoring ways. The corpus is the result of a research and the analysis of the monitoring necessities in heterogeneous network environments. It was focused mainly in proposing a safe architecture, easy to set up and that enables the monitoring of physically and logically different networks. The development shows the implementation of a component formed by two parts, agent and manager, with the communication beginning from the agent, enabling to keep monitoring set up centralized in the manager part, as well as the verification results and each service status or monitored resource. The developed component has as characteristic the necessity of keeping a single connection door opened, in the manager part, in order to maintain the whole monitoring. Keywords: Monitoring, management, networks.

9 LISTA DE ILUSTRAÇÕES Figura 1.1: Camadas do Modelo OSI Figura 1.2: Correspondência de camadas entre os modelos OSI e TCP/IP Figura 2.1: Árvore OID, desde sua raiz Figura 2.2: Tela de status de serviços e recursos monitorados Figura 2.3: Monitoramento direto Figura 2.4: Monitoramento indireto Figura 3.1: Diagrama de componentes Figura 3.2: Diagrama de Dados (MER) Figura 3.3: Diagrama de classes do serviço gerente Figura 3.4: Diagrama de classes do componente agente Figura 3.5: Diagrama de seqüência para do agente Figura 3.6: Diagrama de seqüência para obter configuração do agente Figura 3.7: Diagrama de seqüência para gravação de logs Figura 3.8: Diagrama de atividade do agente Figura 3.9: Diagrama de atividade do Gerente Figura 4.1: Arquitetura OpenAMSH Figura 4.2: Arquitetura de monitoramento convencional Figura 4.3: Arquivo de configuração do Agente Figura 4.4: Informações para configuração do Agente Figura 4.5: Execução de um plugin Figura 4.6: Código referente a identificação do tipo de operação Figura 4.7: Relatório para visualização sumarizada dos resultados Figura 4.8: Relatório para visualização do histórico de verificações

10 LISTA DE QUADROS Quadro 1: Plugins da ferramenta Nagios

11 LISTA DE ABREVIATURAS E SIGLAS ARPA Advanced Research Projects Agency DHCP Dynamic Host Configuration Protocol DNS Domain Name System DoD Department of Defense ERP Enterprise Resource Planning FTP File Transfer Protocol GPL General Public License HTTP Hypertext Transfer Protocol IEEE Institute of Electrical and Electronic Engineers IP Internet Protocol LDAP Lightweight Directory Access Protocol MIB Management Information Base NRPE Nagios Remote Plugin Executor OID Object Identifier POP3 Post Office Protocol RAM Random Access Memory SGBD Sistema Gerenciador de Banco de Dados SMTP Simple Mail Transfer Protocol SPOP3 Secure Post Office Protocol SSH Secure Shell SSL Secure Sockets Layer SSMTP Secure Simple Mail Transfer Protocol TCP Transmission Control Protocol TI Tecnologia da Informação UDP User Datagram Protocol

12 SUMÁRIO INTRODUÇÃO REDES O modelo OSI A camada física A camada de enlace de dados A camada de rede A camada de transporte A camada de sessão A camada de apresentação A camada de aplicação O MODELO TCP/IP A camada Host/rede A camada inter-rede A camada de transporte A camada de aplicação GERENCIAMENTO DE REDES ÁREAS FUNCIONAIS DE GERENCIAMENTO Gerenciamento de falhas Gerenciamento de contabilização Gerenciamento de desempenho Gerenciamento de configuração Gerenciamento de segurança MONITORAÇÃO E CONTROLE DE REDE Monitoração de rede Controle de rede... 27

13 2.3 PROTOCOLOS DE GERENCIAMENTO O protocolo SNMP A FERRAMENTA NAGIOS O Serviço Gerente O Componente Plugin O Componente Agente Monitoramento direto Monitoramento indireto ANÁLISE E PROJETO DE SISTEMA ANÁLISE DE NEGÓCIO Instrução do problema Atores e envolvidos no processo ANÁLISE E DESIGN Diagrama de Implantação (Componentes) Diagrama de Dados (MER) MVC Diagrama de Seqüência Diagrama de Atividade IMPLEMENTAÇÃO TECNOLOGIAS UTILIZADAS O COMPONENTE AGENTE O SERVIÇO GERENTE VISUALIZAÇÃO DOS RESULTADOS CONCLUSÃO ANEXO A TUTORIAL DE INSTALAÇÃO DO OPENAMSH... 56

14 12 INTRODUÇÃO O notável crescimento de componentes e de sua diversificação nas redes de computadores tem feito com que a atividade de gerenciamento de rede se torne cada vez mais importante no setor de Tecnologia da Informação (TI). Os benefícios proporcionados pela integração dos sistemas computacionais em uma empresa, de seguimentos e portes diversos, como meio de distribuir as atividades e tornar recursos acessíveis em uma rede, são hoje triviais nos processos de negócios. (PEREIRA, 2001 apud DIAS, 2008) As redes computacionais corporativas tornaram-se fundamentais para os negócios das empresas que delas fazem uso. Dessa forma, tornou-se necessária a utilização de sistemas de gerenciamento eficientes para que haja garantias de que as informações da corporação estejam sempre acessíveis no local e no momento em que forem necessárias. Dessa forma, sistemas capazes de monitorar uma infraestrutura de TI se tornaram extremamente importantes para a detecção e prevenção de falhas em um ambiente computacional. (DIAS, 2008 apud PEREIRA, 2001) De acordo com as necessidades atuais, anteriormente citadas, e com o objetivo de contribuir para que soluções corporativas se tornem cada vez mais completas, este trabalho tem como objetivo o desenvolvimento de um componente de monitoramento que atenda as necessidades referentes ao monitoramento de infraestrutura de TI e que possibilita sua integração a sistemas de gestão, como os Enterprise Resource Planning (ERP). Esse componente terá como funcionalidade monitorar, de forma centralizada, uma infraestrutura de TI, para realizar o monitoramento dos recursos e serviços

15 13 instalados. As informações sobre o perfil dos computadores (hardware e software) serão armazenadas em uma base de dados, e partir dela, o componente personalizará por computadores quais serão os recursos e serviços a serem monitorados. O componente de monitoramento será separado em três partes, sendo elas os subcomponentes Gerente, Agente e Plugins. A parte Gerente será instalada em um servidor central e terá cadastrado em sua base de dados os serviços e recursos que cada Agente deverá monitorar. A parte Agente ficará instalada nas maquinas que serão monitoradas. Periodicamente, o Agente solicitará ao serviço Gerente o que deve monitorar. Após receber receber as informações do que deve monitorar, ele realizará verificações e coletará informações sobre recursos e serviços instalados através da execução dos Plugins. Para a função de verificação de serviços e recursos, os componente utilizará os plugins de verificações, já prontos, da ferramenta de monitoramento, de código aberto, Nagios. No processo de verificação, toda anormalidade detectada será armazenada em tempo real na mesma base de dados onde os serviços e recursos monitorados estão cadastrados. Com essas informações armazenadas existe a possibilidade de identificar o estado atual de um serviço ou recurso, e também possibilitar a identificação de problemas reincidentes para auxiliar em suas prevenções. Com o uso deste armazenamento, as aplicações que utilizarem o componente de monitoramento desenvolvido nesse trabalho poderão implementar funcionalidades de notificação ao administrador de redes, baseando-se no estado dos serviços contidos na base de dados.

16 14 1 REDES Quando surgiram as primeiras redes computacionais, diversos fabricantes trabalhavam para o desenvolvimento de suas próprias arquiteturas de rede com padrões próprios, sendo estes incompatíveis com os dos demais fabricantes. Devido a falta de um padrão único para desenvolvimento de redes, os usuários da época eram sempre forçados a utilizar produtos de um único fabricante para evitar incompatibilidade entre programas de fabricantes diferentes. (TANEMBAUM, 2003) Criada em 1967 pela organização norte americana Advanced Research Projects Agency (ARPA), a ARPANET foi a primeira rede de computadores geograficamente distribuída. Sua primeira configuração foi montada com quatro nós, sendo três deles universidades e o outro nó um laboratório de pesquisas, ambos situados nos Estados Unidos. Esses quatro nós foram escolhidos pelo fato de todos possuírem contratos com a ARPA e também por possuírem computadores completamente incompatíveis. A escolha inicial de hosts incompatíveis e o rápido crescimento de nós na rede, fez com que os desenvolvedores percebessem que os protocolos utilizados na ARPANET não eram adequados para execução em várias redes. Essa experiência deu origem a pesquisas que culminaram na criação do primeiro modelo de referência, visando facilitar a utilização de hosts heterogêneos na rede. (TANEMBAUM, 2003) 1.1 O MODELO OSI Na década de 1970, surgiu o modelo Open System Interconnection (OSI), que

17 15 dominou a comunicação de dados e literatura de interconexões de redes até a década de 1990, quando o modelo TCP/IP se tornou a arquitetura comercial dominante devido ao fato de ter sido o modelo mais usado e testado na Internet. (FOROUZAN, 2008) Com o objetivo de obter-se uma padronização internacional no desenvolvimento de redes, a International Standards Organization (ISO) deu inicio ao desenvolvimento de uma arquitetura chamada Modelo de Referência para a Interconexão de Sistemas Abertos (Reference Model for Open System Interconnection), mais conhecido como modelo OSI. Esse modelo sugere uma serie de diretrizes para o desenvolvimento de sistemas abertos visando viabilizar a interconexão de redes heterogêneas. O modelo definido pela ISO possui sete camadas, cada uma delas com um conjunto de funções específicas, sendo elas: Camada Física, Camada de Enlace de Dados, Camada de Rede, Camada de Transporte, Camada de Sessão, Camada de Apresentação e a Camada de Aplicação. (MAIA, 2009) A figura 1.1 ilustra a disposição das camadas no modelo. Figura 1.1: Camadas do Modelo OSI. Fonte: (TANEMBAUM, 2003) De acordo com Forouzan (2008), no desenvolvimento do modelo OSI, os projetistas levaram em consideração as transmissões de dados em seus elementos

18 16 mais fundamentais. Desta forma, foram identificadas quais funções de possuíam relações em seu uso e as separaram em grupos, criando assim as camadas. Cada camada define um grupo de funções distintas das funções das outras camadas A camada física A camada física é responsável pela transmissão de bits por meio de um canal de comunicação. A função atribuída a essa camada define que um projeto de rede deverá garantir que, quando enviado um bit 1, o destino deverá recebê-lo como um bit 1, e não como um bit 0. Para que haja essa garantia, as questões comumente consideradas são a voltagem utilizada para representar um bit 1 e um bit 0, quanto tempo que um bit deve durar, a possibilidade da transmissão ser realizada de forma bidirecional simultaneamente, forma de inicialização e encerramento de uma conexão, e também quantos pinos o conector do meio pelo qual os bits serão trafegados terá e qual será a finalidade de cada pino. (TANEMBAUM, 2003) A camada de enlace de dados A camada de enlace tem como função fazer com que um canal de transmissão bruto se transforme em uma transmissão livre de erros para a camada de rede. Para isso, essa camada faz com que o transmissor divida os dados de entrada em quadros de dados e os transmita de forma eqüencial. Se essa troca de informações for confiável, o receptor enviará um quadro de confirmação ao emissor, que então enviará todos os quadros sequencialmente. (TANEMBAUM, 2003) A camada de rede A camada de rede é responsável por controlar a operação da sub-rede,

19 17 determinando como pacotes são roteados da origem até seus destinos, Nessa camada, também são tratados os congestionamentos de pacotes para se evitar gargalos e adaptação dos pacotes para que seja possível a comunicação entre redes heterogêneas. (TANEMBAUM, 2003) A camada de transporte A camada de transporte tem basicamente a função de receber dados da camada acima dela, dividir esses dados em partes menores (pacotes), repassar essas partes à camada de redes e assegurar que todas as partes sejam entregues corretamente ao destino. Essa camada também deve oferecer às camadas acima dela condições para que trabalhem de forma independente a tecnologia de hardware utilizada. Também se atribui a essa camada a função de determinar qual tipo de serviço será fornecido à camada de sessão, e por fim, aos usuários da rede. (TANEMBAUM, 2003) A camada de sessão Essa camada permite que sessões sejam estabelecidas entre usuários de máquinas diferentes. Essas sessões possibilitam determinar o momento em que cada extremidade deve realizar a transmissão de dados, impedir que as extremidades tentem executar a mesma função ao mesmo tempo, e também a sincronização de transmissões longas, permitindo que elas continuem do ponto onde pararam caso alguma falha tenha ocorrido. (FOROUZAN, 2008) A camada de apresentação A camada de apresentação é responsável pela sintaxe e pela semântica de

20 18 toda informação trocada entre dois sistemas. Entre outras responsabilidades específicas dessa camada podem-se citar: a tradução, que é a transformação do fluxo de informações em um formato comum entre as máquinas envolvidas na comunicação; a criptografia, que permite o envio de informações de forma sigilosa, criptografando-as no momento do envio e as descriptografando quando chagada na camada de apresentação do destino; a compactação, que permite reduzir o numero de bits contidos em uma informação no momento de sua transmissão. (FOROUZAN, 2008) A camada de aplicação A camada de aplicação oferece interfaces para que o usuário possa fazer uso da rede. Dentre os serviços oferecidos por essa camada estão: os terminais virtuais de redes, que são uma versão de software que permite a um usuário conectar-se a uma máquina remota simulando um terminal físico; a transferência, Acesso e Gerenciamento de Arquivos(FTAM), que permite ao usuário acessar, gerenciar e recuperar arquivos de uma máquina remota em sua máquina local; os serviços de correio, que fornecem uma base para encaminhamento e armazenamento de e- mails. (FOROUZAN, 2008) 1.2 O MODELO TCP/IP O modelo de referência TCP/IP teve sua primeira definição feita por Vinton Cerf e Robert Kahn, em 1974, em uma publicação da Institute of Electrical and Electronic Engineers (IEEE). Cerf e Kahn são também os desenvolvedores dos protocolos Internet Protocol (IP) e Transmission Control Protocol (TCP), respectivamente, sendo esses os principais protocolos previstos nesse modelo. O TCP/IP foi o modelo de referência implementado na ARPANET e posteriormente na Internet mundial. Sua estrutura é dividida em quatro camadas,

21 sendo elas: Camada Host/rede, Camada Inter-redes, Camada de Transporte e a Camada de Aplicação. (FOROUZAN, 2008) A camada Host/rede O modelo TCP/IP não define nenhum protocolo especifico para a camada física e para a camada de enlace, oferecendo suporte a todos os protocolos-padrão e patenteados. (FOROUZAN, 2008) A camada inter-rede Essa camada integra toda a arquitetura do modelo, permitindo que hosts possam injetar pacotes em qualquer rede e garantindo que eles sejam trafegados de forma independente até o destino, podendo ser o destino uma rede diferente da de origem. Os pacotes trafegados por essa camada podem até mesmo chegar ao destino fora da ordem em que foram enviados, podendo as camadas superiores reorganizá-los, caso o objetivo seja a entrega desses em ordem. (TANEMBAUM, 2003) A camada de inter-redes tem definido um formato de pacote oficial o um protocolo chamado IP. A tarefa desta camada é entregar pacotes IP onde esses são necessários. O roteamento de pacotes e a capacidade de evitar congestionamentos também são tarefas importantes dessa camada. (TANEMBAUM, 2003) No modelo TCP/IP, a camada de inter-redes corresponde a camada de rede do modelo OSI. A correspondência das camadas entre esses modelos são apresentadas na figura 1.2. (TANEMBAUM, 2003)

22 A camada de transporte No modelo TCP/IP, a camada de transporte esta localizada acima da camada de inter-redes e tem como finalidade permitir que um host de origem e um host de destino mantenham uma comunicação, da mesma forma como acontece na camada de transporte do modelo OSI. (TANEMBAUM, 2003) Figura 1.2: Correspondência de camadas entre os modelos OSI e TCP/IP. Fonte: (TANEMBAUM, 2003) Nessa camada foram definidos dois protocolos fim a fim, o TCP e o User Datagram Protocol (UDP). O TCP é um protocolo orientado a conexões que permite a entrega sem erros de um fluxo de bytes. Esse protocolo fragmenta os bytes de entrada em mensagens discretas, passando cada uma delas para a camada interredes. No destino, o processo TCP receptor monta as mensagens recebidas apresentando-as no fluxo de saída. O TCP também proporciona um controle de fluxo, cuidando para que um transmissor rápido não sobrecarregue um receptor mais lento. Já o UDP é um protocolo sem conexão e não-confiável destinado a aplicações que não necessitam de controle de fluxo nem de manutenção da seqüência de mensagens enviadas, como nas transmissões de voz ou de vídeo. (TANEMBAUM, 2003)

23 A camada de aplicação No TCP/IP, as camadas de sessão e apresentação não estão presentes por terem sido consideradas desnecessárias, aparecendo acima da camada de transporte a camada de aplicação. Nesta camada são abordados diversos protocolos de nível mais alto. Dentre os protocolos pertencentes a essa camada citam-se o protocolo de transferência de arquivos (File Transfer Protocol (FTP)), o protocolo de correio eletrônico (Simple Mail Transfer Protocol (SMTP)), o protocolo de configuração dinâmica de hosts (Dynamic Host Configuration Protocol (DHCP)), entre outros. (TANEMBAUM, 2003) O capítulo seguinte apresentará uma breve abordagem sobre gerenciamento de redes, suas áreas funcionais e também sobre o principal protocolo de gerenciamento desenvolvido para o modelo de referencia TCP/IP, o Simple Network Management Protocol (SNMP). Também será apresentada a ferramenta Nagios, da qual esse projeto utilizará um de seus componentes na execução do monitoramento.

24 22 2 GERENCIAMENTO DE REDES Segundo Farrel (2007), gerenciamento de redes se refere às formas de controle, configuração e obtenção de relatórios que são úteis ao administrador que queira saber como está o funcionamento de sua rede. De alguma forma, para todo dispositivo de rede é necessário um gerenciamento, ainda que mínimo. Para Specialski (2011), ainda que pequena e simples, uma rede de computadores necessita de gerenciamento, para garantir que os serviços instalados sempre estarão disponíveis a um nível de desempenho aceitável. Specialski (2011) também diz que a medida que as redes crescem, aumentam a complexidade no gerenciamento, fazendo-se necessário a adoção de ferramentas automatizadas para seu monitoramento e controle. Como justificativa para a adoção de um software de gerencia de redes, alguns dos fatores apresentados por Harnedy(1997) são os seguintes: a) As redes e os recursos de computação distribuídos se tornaram vitais para as organizações. Caso não haja um controle efetivo, o retorno não corresponderá com o requerido pela corporação. b) Com crescimento em termos de componentes, interfaces, usuários, protocolos e fornecedores aumenta-se o risco de perda de controle sobre o que se tem conectado e como os recursos estão sendo utilizados na rede. c) Monitoramento e controle da utilização dos recursos é necessário para garantir que as necessidades dos usuários sejam satisfeitas a custos razoáveis. d) Conforme um recurso vai se tornando mais importante para a organização,

25 maior se torna a necessidade de disponibilidade. O sistema de gerenciamento deve monitorá-lo e garantir esta disponibilidade. 23 A gerência está associada ao controle de atividades e ao monitoramento do uso de recursos da rede. As tarefas básicas da gerência em redes, simplificadamente, são obter informações da rede, tratar estas informações, possibilitando um diagnóstico, e encaminhar as soluções dos problemas. Para cumprir estes objetivos, funções de gerência devem ser embutidas nos diversos componentes de uma rede, possibilitando descobrir, prever e reagir a problemas. (SZTAJNBERG, 1996) 2.1 ÁREAS FUNCIONAIS DE GERENCIAMENTO Além do ponto de vista qualitativo, foi apresentada pela ISO uma divisão funcional das necessidades no processo de gerenciamento. A maioria dos fornecedores de softwares de gerenciamento adotaram essa definição, que divide as áreas funcionais em: gerencia de falhas, contabilização, configuração, desempenho e segurança. (Specialski, 2011) Gerenciamento de falhas Segundo Specialski (2011), uma falha é uma condição anormal cuja recuperação exige ação de gerenciamento. Normalmente, uma operação incorreta ou excesso de erros são as causas de uma falha. Alguns erros podem acontecer ocasionalmente e não serem considerados como um falha. Para um monitoramento completo, é preciso que cada componente essencial seja monitorado individualmente para garantir seu funcionamento. Quando uma falha ocorre, é importante conseguir determinar o componente exato onde a falha ocorreu para que seja possível isolá-lo, realizando as mudanças de configurações necessárias, e reparar o componente restaurando o estado normal da rede. (Specialski, 2011) Os impactos causados por uma falha podem ser minimizados com a utilização de componentes redundantes e rotas de comunicação alternativas, proporcionando

26 24 uma certa tolerância a falhas. (Specialski, 2011) Gerenciamento de contabilização O administrador de redes deve possuir meios para controlar o uso de recursos por usuários. Isso permite ao administrador evitar que um usuário abuse de privilégios de acesso e monopolize o uso da rede. Também é importante que o administrador seja capaz de especificar quais tipos de informações de contabilização devem ser registradas em cada componente da rede, o intervalo de tempo para entrega de relatórios de gerenciamento além dos algoritmos aplicados no cálculo da utilização. (Specialski, 2011) Gerenciamento de desempenho O gerenciamento de desempenho consiste na monitoração das atividades na rede e no controle sobre os recursos por meio de trocas e ajustes. Specialski (2011) define algumas questões como referentes ao gerenciamento de desempenho, sendo elas: a) Qual é o nível de capacidade de utilização? b) O tráfego é excessivo? c) O throughput foi reduzido para níveis aceitáveis? d) Existem gargalos? e) O tempo de resposta esta aumentando? Para tratamento dessas questões, deve-se focalizar um conjunto inicial de componentes a serem monitorados, com o objetivo de estabelecer níveis de desempenho. Nesta tarefa inclui-se associar métricas e valores apropriados para que recursos de redes possam fornecer indicadores de níveis de desempenho diversos. Com as informações armazenadas, e analisadas, o gerente de redes estará mais capacitado para reconhecer situações que indicam degradação do

27 desempenho da rede. Essas informações possibilitam também reconhecer situações de gargalo antes que causem problemas ao usuário final. (Specialski, 2011) Gerenciamento de configuração O gerenciamento de configuração está associado a momento de inicialização da rede e com uma eventual necessidade de desabilitar parte dela ou seu todo. Também se inclui no gerenciamento de configuração as tarefas de manutenção, atualização ou adição de relação entre componente e o status de um componente enquanto operando na rede. (Specialski, 2011) Alguns componentes são capazes de executar diferentes funções em uma rede. Quando definido como um componente deverá ser utilizado, o gerente de configuração poderá definir o software apropriado e os valores para as definições específicas de seu funcionamento. (Specialski, 2011) Specialski (2011) diz que gerente da rede deve ser capaz de identificar os componentes da rede e definir qual a relação de conectividade entre eles. Ele também deve ser capaz de realizar alterações nas configurações em resposta às avaliações de desempenho, recuperações de falhas, problemas de segurança, atualização da rede ou com o objetivo de atender as necessidades dos usuários Gerenciamento de segurança O gerenciamento de segurança é responsável por prover facilidades na proteção de recursos da rede e informações dos usuários. Somente usuários autorizados devem ter acesso a essas facilidades. A política de segurança deve ser efetiva, robusta e o próprio gerenciamento de segurança deve ser seguro. (Specialski, 2011) O gerenciamento de seguranças trata assuntos como: manutenção e distribuição de senhas e informações de controle de acesso; monitoração e controle

28 26 de acesso a rede; analise de logs de seguraça e outros. (Specialski, 2011) 2.2 MONITORAÇÃO E CONTROLE DE REDE De forma simplificada, as funções de gerenciamento de redes podem ser agrupadas em duas categorias: controle de rede e monitoração de rede. O controle de rede pode ser definido como uma atividade de escrita, onde se tem a tarefa de alteração de valores de parâmetros e a execução de determinadas ações. Já a monitoração de rede pode ser considerada uma atividade de leitura, onde estão as tarefas de observação, análise do estado e configuração de seus componentes. (Specialski, 2011) Monitoração de rede Segundo Specialski (2011), a monitoração atua com maior ênfase nas três primeiras áreas funcionais de gerenciamento citadas anteriormente: falhas, desempenho e contabilização. Suas atividades consistem em observar as informações consideradas relevantes ao gerenciamento, que podem ser classificadas em três categorias: Estática, representa a configuração atual e os elementos em suas atuais configurações. Um exemplo é o número e identificação de portas de um roteador; Dinâmica, são as informações relacionadas a eventos ocorridos na rede, como a transmissão de um pacote de dados; Estatística, são informações derivadas de informações dinâmicas, como o número médio de pacotes de dados transmitidos por uma determinada interface de rede. As informações de gerenciamento são coletadas e armazenadas por um agente e repassadas para um ou mais gerentes. Existem duas técnicas utilizadas por agentes e gerentes: polling e event-reporting. (Specialski, 2011) A técnica de polling se caracteriza por uma interação do tipo request/response entre um gerente e um agente. O gerente pode solicitar ao agente que lhe envie diversas informações sobre o componente onde se encontra instalado. O agente

29 27 retornará ao gerente valores existentes em sua Management Information Base (MIB). Já na técnica de event-reporting, a interação parte do agente. Nela o agente gera relatórios periódicos e os envia aos gerentes, que estarão a espera de informações do seu estado atual. (Specialski, 2011) Controle de rede De acordo com Specialski (2011) esta parte do gerenciamento de rede se refere a modificação de parâmetros e a execução de ações em sistemas remotos. O controle de rede atua com maior ênfase nas áreas de gerenciamento de configuração e gerenciamento de segurança. Para a área de configuração, alguns dos itens citados por Specialski (2011) como parte do controle de rede são: a definição da informação de configuração - recursos e atributos dos recursos sujeitos ao gerenciamento; a atribuição e modificação de valores de atributos; a definição e modificação de relacionamentos entre recursos ou componentes da rede; e ainicialização e terminação de operações de rede. Na área de segurança o controle de rede se refere a segurança dos recursos sob gerenciamento, inclusive ao sistema de gerenciamento. Os principais objetivos em termos de segurança, são relativos à confidencialidade, integridade e disponibilidade. (Specialski, 2011) 2.3 PROTOCOLOS DE GERENCIAMENTO Para atender às necessidades de gerenciamento de redes com componentes diversificados, foram criados protocolos. Segundo Nemeth (2007), os protocolos de gerenciamento de redes padronizam o método de investigação de um dispositivo para descobrir sua configuração, saúde e conexões de rede. Eles também permitem que algumas dessas informações possam ser alteradas para que o gerenciamento seja realizado de forma padronizada por meio de diferentes tipos de máquinas em

30 28 um local centralizado O protocolo SNMP O protocolo SNMP passou a ser amplamente utilizado no início da década de 90, quando centenas de empresas lançaram pacotes de gerenciamento o utilizando. Ao mesmo tempo, diversos fabricantes de hardware começaram a colocar um agente SNMP como parte de seu produto. (NEMETH, 2007) O SNMP é um protocolo da camada de aplicação capaz de usar qualquer protocolo de transporte, porém, mais utilizado com o UDP na porta 161, que é obrigatória para concordância com os padrões do SNMP. (FARREL, 2005) O SNMP é um protocolo abstrato, que precisa de um programa servidor, o agente, e de um programa cliente, o gerente, para fazer uso dele. (NEMETH, 2007) Este protocolo define um espaço de nomes hierárquico de dados de administração e uma forma de ler e gravar os dados em cada um dos nós. Ele também define como um agente e um gerente se comunicam e como notificações, denominadas traps, são enviadas às estações de gerenciamento. (NEMETH, 2007) A organização do SNMP No protocolo SNMP os dados são organizados seguindo uma hierarquia padronizada. Nemeth (2007) diz que, pelo menos teoricamente, essa organização forçada permite que o espaço de dados permaneça universal e extensível ao mesmo tempo. Está hierarquia de atribuição de nomes é formada por bases de informação de gerenciamento, chamadas MIB. As MIBs são arquivos de texto que descrevem os objetos gerenciados utilizando a sintaxe Abstract Syntax Notation 1 (ASN.1). Em seu conteúdo estão descrições de variáveis de dados especificas, sendo cada uma identificada através de nomes conhecidos como Object Identifiers (OIDs). (NEMETH,

31 ) Para exemplificar está estrutura hierárquica, Farrel (2005) apresenta a figura 2.1 e cita como exemplo os OIDs pertencentes a Internet, que é de responsabilidade do Derpatment of Defense (DoD) americano. Nesta figura tem-se definido o OID numero 1 para a ISO, o OID numero 3 para Organizações, o OID 6 para o DoD e o OID numero 1 para Internet. Considera-se esta estrutura, todo objeto gerenciado pertencente à Internet na estrutura da MIB terá como inicio de seu OID a numeração Figura 2.1: Árvore OID, desde sua raiz. Fonte: (FARREL, 2005). Existem MIBs para diversos tipos de interfaces e protocolos de hardware. para fornecedores individuais e MIBs para produtos específicos de hardware. Para que essas MIBs sejam úteis. elas precisam ser utilizadas junto a códigos executados nos agentes que fazem a associação entre os espaços de nomes SNMP e o real estado do dispositivo. (NEMETH, 2007)

32 As operações do protocolo SNMP Considerando a existência de uma visão comum dos de gerenciamento através das MIBs, o SNMP provê um mecanismo para que as estações de gerenciamento possam criar, escrever, ler e excluir esses dados. (FARREL, 2005) Apesar de evitarem o uso do termo, o SNMP é um protocolo cliente-servidor. Os agentes de gerenciamento se conectam aos dispositivos gerenciados e emitem requisições. Os dispositivos gerenciados retornam respostas conforme as requisições. (FARREL, 2005) As requisições básicas do SNMP são bastante simples. Elas são GET e SET, utilizadas para ler e escrever em objetos de uma MIB individualmente identificado por seu OID. Porém, não seria uma prática eficiente gerenciar a configuração de um dispositivo remoto trabalhando com um objeto de cada vez. Para essa situação o SNMP permite que o comando GET ou SET leia ou escreva em objetos existentes na mesma linha de uma MIB. Além desses dois comandos, existem os comandos GET-BULK, que permite que em uma única requisição sejam lidas múltiplas linhas de uma MIB, e o comando GET-NEXT que permite que um agente de gerenciamento percorra pela árvore OID para encontrar o próximo objeto de uma linha da MIB. (FARREL, 2005) Para a criação e exclusão de linhas, são utilizadas funções especiais fazendo uso do comando SET e não por meio de mensagens próprias especiais. As linhas de uma MIB possuem um objeto especial denominado Line State (estado da linha), usado para controlar a criação e a exclusão da linha. Quando uma nova linha é criada por uma estação de gerenciamento, é atribuído o valor create ao objeto Line State e caso a linha já exista a operação será descartada. Caso a operação seja bem-sucedida, a estação de gerenciamento preenche os demais objetos da linha criada e altera o valor do objeto Line State para active, assim disponibilizando as informações dos objetos inseridos. (FARREL, 2005) A linha de uma MIB pode ser removida com a atribuição do valor deleted no campo Line State, necessita-se que, previamente, que os processos ou dispositivos correspondentes a ela sejam suspensos e suas informações removidas. (FARREL, 2005)

33 31 Em caso de não-conformidade a limites especificados aos objetos gerenciados, um último comando do protocolo SNMP é utilizado, o TRAP. Este comando emite uma notificação que informa sobre um evento especifico. (FARREL, 2005) 2.4 A FERRAMENTA NAGIOS O Nagios, primeiramente chamado de Netsaint, é uma aplicação de código aberto distribuída sob licença GPL desenvolvida para monitoramento de ambientes de redes computacionais. Originalmente, ele foi desenvolvido para ser executado em sistemas Linux, porém, existem diversos plugins e aplicativos agentes que viabilizam sua utilização para monitoramento das mais diversas plataformas existentes no mercado. (GALSTAD, 2010a) Esta aplicação é capaz de monitorar tanto recursos locais de uma máquina como aplicações e serviços disponibilizados em redes. Entre suas principais características, no monitoramento de recursos, estão o monitoramento de utilização de espaço em disco, carga do processador, usuários logados, entre outros recursos locais de uma maquina. Já no monitoramento de serviços, entre suas principais características estão o monitoramento de serviços como o SMTP, o Post Office Protocol (POP3), o Hypertext Transfer Protocol (HTTP), o Domain Name System (DNS), o DHCP, entre outros. O Nagios também permite a realização de monitoramento através de túneis criptografados Secure Shell (SSH) ou Secure Sockets Layer (SSL). Com base no resultado do monitoramento, o Nagios é capaz de identificar e notificar o administrador de redes quando algum serviço ou recurso apresentar problemas, além de possibilitar a configuração para que problemas sejam solucionados de forma pró-ativa. (GALSTAD, 2010a) O Nagios também possui uma interface web que possibilita a visualização de estatísticas de eventos ocorridos sob monitoramento, além do acompanhamento em tempo real da situação dos serviços e recursos monitorados. (GALSTAD, 2010a) A figura 2.2 apresenta uma das telas de status de serviços e recursos monitorados pela aplicação.

34 32 Figura 2.2: Tela de status de serviços e recursos monitorados. Fonte: (GALSTAD, 2010a). O Nagios é uma aplicação componentizada de forma a facilitar sua escalabilidade, monitoramento heterogêneo e criação de plugins independentes para atender as necessidades do usuário. Seu funcionamento se divide em três componentes: Serviço Gerente, Plugins e Agentes. (GALSTAD, 2010a) O Serviço Gerente O Serviço Gerente é onde as informações obtidas são armazenadas e processadas, gerando resultados legíveis e de fácil interpretação pelo usuário. As informações fornecidas ao Serviço Gerente são provenientes da execução do componente Plugin pelo componente Agente. (GALSTAD, 2010a) O Componente Plugin O componente Plugin consiste em arquivos executáveis; que podem ser arquivos binários, Shell Scripts, scripts em Perl, entre outras linguagens; que quando executados retornam informações sobre o status de um recurso local ou de um serviço disponibilizado em rede. Esses plugins podem ser desenvolvidos sob demanda para atender necessidades específicas de cada usuário. (GALSTAD, 2010c) Os desenvolvedores do Nagios mantêm plugins oficiais para monitoramento dos principais serviços e recursos. A tabela 1 apresenta os principais plugins que

35 33 serão utilizados no OpenAmsh. Quadro 1: Plugins da ferramenta Nagios. Nome do Plugin Descrição do Plugin check_by_ssh check_cluster check_dhcp check_dig check_disk check_dns check_ftp check_http check_ldap check_load check_mysql check_nagios check_nrpe check_nt check_pgsql check_ping check_pop É utilizado para execução de comandos em máquinas remota através de SSH. Verifica a disponibilidade dos nós pertencentes a um cluster de serviços. Testa a disponibilidade de um serviço DHCP em uma rede. Utiliza a ferramenta dig para teste de status do serviço DNS. Verifica a quantidade de espaço em disco que esta sendo utilizada em um sistema de arquivos montado. Utiliza o programa nslookup para obter o endereço IP de uma máquina de um domínio. O Plugin permite a especificação de um servidor DNS opcional. Se nenhum servidor DNS é especificado, o servidor padrão especificado no sistema operacional é utilizado. Testa a conexão com um serviço FTP. Verifica o estado de um serviço HTTP em um host especifico. Testa conexão com serviço LDAP em um host especificado. Verifica a carga atual de processamento de uma máquina. Testa a conexão com o serviço de banco de dados Mysql. Verifica o estado do processo do Nagios na máquina local. Executa plugins verificação em máquinas remotas através do agente NRPE. Coleta informações do agente NSClient++ que roda sistemas operacionais Windows NT/2000/XP/2003 server. Verifica conectividade e estado de um banco de dados PostgreSQL. Verifica a conectividade com um host com o ping, conta pacotes perdidos e retorna o tempo de resposta. Testa a conectividade com um serviço POP3 em um host especificado.

36 34 check_procs Verifica a quantidade de processos que estão em execução em uma maquina. check_radius Verifica se um servidor Radius está aceitando conexões. check_smtp Testa a conectividade com um serviço SMTP em um host especificado. check_snmp Verifica o estado de uma máquina remota e obtém informações dos sistemas através do protocolo SNMP. check_spop Testa a conectividade com um serviço SPOP3 (Secure POP3) em um host especificado. check_ssh Verifica se um serviço SSH está ativo em um host especificado. check_ssmtp Testa a conectividade com um serviço SSMTP (Secure SMTP) em um host especificado. check_swap Verifica a quantidade de memória swap disponível em uma máquina. check_tcp Testa a conexão TCP com um host e porta especificados. check_udp Testa conexão UDP com um host e porta especificados. check_users Verifica a quantidade de usuários logada em uma máquina através de terminal. Fonte: (GALSTAD, 2010c) O Componente Agente O componente Agente é responsável pela execução dos Plugins para verificação de serviços e recursos. Após a execução dos Plugins e obtenção dos resultados, o Agente fornece esses dados ao serviço Gerente que, por sua vez os processará e armazenará. (GALSTAD, 2010b) Os agentes mais populares são o Nagios Remote Plugin Executor - NRPE, agente para execução de plugins em máquinas Unix/Linux remotas; e o NSClient++, agente para execução de plugins em máquinas Windows remotas, sendo apenas o NRPE mantido oficialmente pelos desenvolvedores do Nagios. (GALSTAD, 2010b)

37 Monitoramento direto O monitoramento direto dos recursos e serviços é a forma mais comum de utilização do Nagios. Esse tipo de monitoramento é caracterizado quando um agente, como o NRPE, executa um Plugin com o objetivo de monitorar um recurso ou serviço instalado na mesma máquina onde esta a instalação do agente. A figura 2.3 apresenta um exemplo desse tipo de monitoramento. (GALSTAD, 2010b) Figura 2.3: Monitoramento direto. Fonte: (GALSTAD, 2010b) Monitoramento indireto A utilização de agentes de monitoramento possibilita ao Nagios a realização do monitoramento de serviços não acessíveis pelo serviço gerente. Essa prática é chamada de monitoramento indireto e se caracteriza quando uma máquina acessível pelo serviço Gerente possui uma instalação do serviço Agente. Esse, por sua vez, executa a verificação de serviços instalados em uma maquina não acessível pelo serviço Gerente, fornecendo-lhe as informações sobre esse serviço. A figura 2.4 ilustra esse tipo de monitoramento. (GALSTAD, 2010b) Figura 2.4: Monitoramento indireto. Fonte: (GALSTAD, 2010b).

38 36 3 ANÁLISE E PROJETO DE SISTEMA Neste capítulo serão apresentados os documentos referentes a análise e projeto de sistema, com o objetivo de identificar as necessidades e atores do sistema, e logo após apresentam-se diagramas necessários ao projeto. 3.1 ANÁLISE DE NEGÓCIO Esta seção relata os problemas atuais relativos ao monitoramento dos componentes de uma rede e os atores envolvidos no processo com suas respectivas funcionalidades Instrução do problema Com o aumento do número de componentes em ambientes de redes de computadores, o monitoramento individual de cada componente tornou-se uma tarefa muitas vezes impraticável. As dificuldades impostas por esse cenário aos administradores de redes podem impactar diretamente na segurança e desempenho do ambiente. A utilização de um monitoramento que mantenha as informações de todos os componentes da rede de forma centralizada possibilitaria ao administrador

39 37 identificar falhas em hardware e serviços quase que em tempo real, viabilizando também a execução de reparos antes de uma parada inesperada de um serviço ou recurso Atores e envolvidos no processo Os atores envolvidos no processo são: Operador, Serviço Gerente e Componente Agente. O operador é a pessoa responsável pela manutenção da infraestrutura de TI e tem como responsabilidade configura o serviço Gerente no servidor principal e os componentes Agentes nos computadores que os executarão. No serviço Gerente são centralizadas as informações sobre o monitoramento. Esse serviço tem como responsabilidade manter, em banco de dados, as informações sobre quais serviços e recursos deverão ser monitorados, fornece essas informações ao componente Agente e, posteriormente, armazena os resultados das verificações em banco de dados. O componente Agente é responsável por realizar as verificações nas maquinas monitoradas. Ele buscará no serviço Gerente informações referente aos serviços e recursos que deverá monitorar. Após obter essas informações, o componente Agente realizará as verificações e enviará os resultados obtidos ao serviço Gerente. 3.2 ANÁLISE E DESIGN Nesta seção apresentam-se os principais diagramas relacionados ao desenvolvimento do agente de Monitoramento de Serviços e Hardware (OPENAMSH).

40 Diagrama de Implantação (Componentes) Figura 3.1: Diagrama de componentes. Fonte: Elaborada pelo autor, Diagrama de Dados (MER) Figura 3.2: Diagrama de Dados (MER). Fonte: Elaborada pelo autor, 2011.

41 MVC Figura 3.3: Diagrama de classes do serviço gerente. Fonte: Elaborada pelo autor, 2011.

42 40 Figura 3.4: Diagrama de classes do componente agente. Fonte: Elaborada pelo autor, Diagrama de Seqüência Figura 3.5: Diagrama de seqüência para do agente. Fonte: Elaborada pelo autor, 2011.

43 Figura 3.6: Diagrama de seqüência para obter configuração do agente. Fonte: Elaborada pelo autor,

44 Figura 3.7: Diagrama de seqüência para gravação de logs. Fonte: Elaborada pelo autor,

45 Diagrama de Atividade A figura 3.8 apresenta o fluxo das atividades do componente Agente. Dentre as atividades especificadas estão a solicitação de configuração feita pelo serviço Agente ao serviço Gerente, o monitoramento síncrono realizado periodicamente e o monitoramento assíncrono, realizado caso o componente Agente não consiga estabelecer conexão com o serviço Gerente no momento do envio dos resultados do monitoramento Figura 3.8: Diagrama de atividade do agente. Fonte: Elaborada pelo autor, A figura 3.9 apresenta o fluxo das atividades do serviço Gerente. Ao receber uma requisição do componente Agente, o serviço Gerente identifica o tipo da operação inicializada. Caso a operação seja identificada como GETCONFIG, o serviço Gerente verificará se há verificações cadastradas na base de dados para o Agente e as enviará como resposta ao componente Agente. Caso o serviço Gerente identifique a operação inicializada como PUTLOG ou PUTLOGLOT, o gerente armazenará no banco de dados os resultados de verificações enviados pelo

46 44 componente Agente. Figura 3.9: Diagrama de atividade do Gerente. Fonte: Elaborada pelo autor, O capitulo seguinte descreverá detalhes da implementação dos componentes Agente e Gerente, como o comportamento dos componentes para cada operação e as definições para de como as informações são trafegadas.

47 45 4 IMPLEMENTAÇÃO Neste capítulo são descritas as tecnologias utilizadas no desenvolvimento do projeto e, em seguida, são abordadas as etapas da implementação bem como a explicação sobre o funcionamento dos componentes do sistema. A figura 4.1 ilustra a arquitetura proposta do OpenAMSH, toda comunicação terá inicio no componente Agente, independente de sua localização, que solicita ao serviço Gerente informações referentes ao monitoramente que deverá realizar. Figura 4.1: Arquitetura OpenAMSH. Fonte: Elaborada pelo autor, Na figura 4.2 tem-se a arquitetura utilizada na forma de monitoramento convencional, utilizada pela ferramenta Nagios e pelo protocolo SNMP. Comparada a arquitetura do OpenAMSH, nota-se a diferença na origem da comunicação e ainda

48 a menor necessidade de recursos para realização do monitoramento em redes distintas. 46 Figura 4.2: Arquitetura de monitoramento convencional. Fonte: Elaborada pelo autor, TECNOLOGIAS UTILIZADAS A seguir é apresentada uma breve descrição das tecnologias utilizadas na implementação do projeto: JAVA: É uma linguagem de programação orientada a objetos que, quando criada, teve como principal objetivo a sua execução independendo da plataforma utilizada. Essa linguagem também possui uma extensa biblioteca para utilização e integração a recursos de redes. (JavaFree, 2011) Protocolo HTTP: É um protocolo que permite a servidores Web e browsers enviar e receber dados, trabalhando com requisições e respostas. Este protocolo faz uso de conexões TCP confiáveis.(kurniawan, 2004) Apache Tomcat 7.0: É um servlet/jsp contêiner utilizado para interpretar aplicações escritas em Java para Web. PostgreSQL 9.0: É um Sistema Gerenciador de Banco de Dados (SGBD) objeto-relacional de código aberto. Possui mais de 15 anos de

49 47 desenvolvimento e excelente reputação de confiabilidade, integridade de dados e conformidade a padrões. É possível executá-lo sobre os principais sistemas operacionais, incluindo GNU/Linux, Unix (AIX, BSD, HP-UX, SGI IRIX, Mac OS X, Solaris, Tru64), e MS Windows. (PostgreSQL, 2011) Na implementação deste trabalho também foram utilizados os componentes denominados Plugins, da ferramenta Nagios. Esses componentes estão descritos no capitulo deste trabalho. 4.2 O COMPONENTE AGENTE O componente Agente é responsável pela execução das verificações de estado dos recursos e serviços monitorados. Este componente deve ser instalado nas máquinas a serem monitoradas e ter sua pré-configuração realizada no arquivo openamsh.conf. Este arquivo é de fácil configuração e deve conter: identificação única da máquina onde o Agente está instalado, endereço IP do servidor Gerente, diretório onde os Plugins da ferramenta Nagios estão instalados e a definição de um arquivo para gravação de logs. Essas informações devem estar dispostas em uma única linha, separadas pelo caractere (pipe). A figura 4.1 ilustra como o arquivo openamsh.conf deve ser definido. Figura 4.3: Arquivo de configuração do Agente Fonte: Elaborada pelo autor, O Agente pode interagir com o Gerente através de três tipos de operações, conforme descritas a seguir: GETCONFIG: Operação responsável por obter a configuração de verificações a serem realizadas pelo Agente. Em sua primeira comunicação com o Gerente, o Agente sempre realizará essa operação. PUTLOG: Operação responsável por enviar ao Gerente o resultado de

50 48 uma única verificação realizada pelo Agente. PUTLOGLOT: Operação responsável por enviar ao Gerente os resultados armazenados em arquivo de texto gerados por monitoramento assíncrono. Quando executado pela primeira vez, o Agente inicia uma thread. Essa thread abre uma conexão com o IP definido em seu arquivo de configuração como IP do servidor Gerente e envia ao Gerente sua identificação e o tipo de operação que pretende realizar, neste caso GETCONFIG. Após o envio dessas informações, o Agente recebe do Gerente uma lista com as verificações que deverá realizar. Recebida a lista com as verificações a serem realizadas, o Agente inicia uma nova thread para cada linha desta lista. As informações contidas em cada linha são: identificação única da verificação, nome do arquivo do Plugin que será executado, parâmetros para execução do Plugin e a periodicidade em segundos com que a verificação deve ser executada. A figura 4.2 ilustra a forma como lista de verificações é recebida pelo Agente. Figura 4.4: Informações para configuração do Agente Fonte: Elaborada pelo autor, Configuradas as verificações, são executadas e seus resultados capturados. A execução de um plugin é realizada através do método exec() da classe Runtime do Java, que permite a execução de scripts ou comandos no interpretador de comandos do Sistema Operacional. O resultado de uma verificação é composto por status do serviço ou recurso verificado e por informações referentes a situação do serviço ou recurso no momento da execução da verificação. A figura 4.3 apresenta a execução de um plugin no interpretador de comandos bash do sistema operacional GNU/Linux, seguido do resultado da verificação. Figura 4.5: Execução de um plugin Fonte: Elaborada pelo autor, 2011.

51 49 Essas informações são enviadas através da operação PUTLOG ao serviço Gerente, onde são armazenadas. Caso o Agente não consiga estabelecer conexão com o serviço Gerente no momento em que for enviar o resultado de uma verificação, essas informações são armazenadas no arquivo de log definido no arquivo openamsh.log. Ao realizar a próxima verificação configurada, o Agente tentará novamente estabelecer conexão com o serviço Gerente para enviar o resultado. Caso a conexão seja estabelecida com sucesso, o Agente enviará os resultados contidos no arquivo de log juntamente com o resultado da verificação executada, fazendo uso da operação PUTLOGLOT. Desta forma é possível a realização de monitoramento assíncrono. 4.3 O SERVIÇO GERENTE O serviço Gerente é uma aplicação Web desenvolvida em Java com o objetivo de fornecer aos Agentes suas configurações para realização de verificações. O serviço Gerente também é responsável por armazenar os resultados de cada verificação realizada pelo Agente. Este serviço é executado sob um container servlet, neste trabalho o Tomcat 7.0, e possui um único ponto para entrada e saída de informações o servlet ACTMonitor. Todas as requisições enviadas pelos Agentes são direcionadas para esse servlet. A forma como esse servlet se comporta e responde ao Agente está relacionada ao tipo de operação iniciada pelo Agente: GETCONFIG, PUTLOG ou PUTLOGLOT. Para a operação GETCONFIG, o serviço Gerente identifica o Agente que iniciou a operação através de seu identificador único, consulta em seu banco de dados as verificações cadastradas e envia ao Agente uma lista de configurações como resposta. Para as operações PUTLOG e PUTLOGLOT, o serviço gerente recebe uma lista de resultados de verificações de estado de serviços ou recursos realizadas por um Agente e armazena essas informações em banco de dados. A Figura 4.4

52 apresenta o trecho de código onde o tipo de operação é identificado no servlet ACTMonitor. 50 Figura 4.6: Código referente a identificação do tipo de operação Fonte: Elaborada pelo autor, VISUALIZAÇÃO DOS RESULTADOS Para visualização dos resultados das verificações realizadas pelos agentes, foram criados dois relatórios. O primeiro relatório apresenta de forma sumarizada os Agentes cadastrados, suas verificações, o momento em que a verificação foi executada pela ultima vez e seu último status registrado. A figura 4.5 ilustra este relatório. Figura 4.7: Relatório para visualização sumarizada dos resultados. Fonte: Elaborada pelo autor, O segundo relatório apresenta o histórico de execuções de uma verificação. Este relatório pode ser visualizado com o click no nome de uma das verificações apresentadas no relatório sumarizado. Este relatório contém o momento em que a

53 verificação é executada, status registrado e o resultado da verificação. A figura 4.6 ilustra o relatório de histórico de verificações. 51 Figura 4.8: Relatório para visualização do histórico de verificações. Fonte: Elaborada pelo autor, Esses relatório podem ser acessados através do servlet ACTReport em substituindo o endereço IP pelo endereço IP do servidor onde o serviço gerente está instalado.