UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR CURSO DE CIÊNCIA DA COMPUTAÇÃO

Transcrição

1 UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR CURSO DE CIÊNCIA DA COMPUTAÇÃO UNMS: PLATAFORMA UNIFICADA PARA O GERENCIAMENTO DE REDES Área de Redes de Computadores por Axel Krieger Neto Fabrício Bortoluzzi, M.Sc. Orientador Itajaí (SC), fevereiro de 2009

2 UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR CURSO DE CIÊNCIA DA COMPUTAÇÃO UNMS: PLATAFORMA UNIFICADA PARA O GERENCIAMENTO DE REDES Área de Redes de Computadores por Axel Krieger Neto Relatório apresentado à Banca Examinadora do Trabalho de Conclusão do Curso de Ciência da Computação para análise e aprovação. Orientador: Fabrício Bortoluzzi, M.Sc. Itajaí (SC), fevereiro de 2009

3 AGRADECIMENTOS Agradeço a: Meu pai por seu apoio e compreensão, essenciais para a conclusão deste curso. Minha mãe pelo grande incentivo dado durante toda a vida estudantil. Orientador Fabrício Bortoluzzi que foi bastante requisitado por sugestões e criticas durante todo o projeto. Ademir Goulart professor que me demonstrou pela primeira vez, o funcionamento de softwares de gerência de redes e que despertou a curiosidade sobre o assunto. Francis Benito Odisi por autorizar a utilização de componentes de desenvolvimento gráfico e de acesso a banco de dados, ambos de sua autoria. Todos os colegas do curso de Ciência da Computação sem os quais muitos conhecimentos deixariam de ser aprendidos. ii

4 SUMÁRIO LISTA DE ABREVIATURAS...v LISTA DE FIGURAS...vi LISTA DE TABELAS...viii RESUMO...ix ABSTRACT...x 1 INTRODUÇÃO PROBLEMATIZAÇÃO Formulação do Problema Solução Proposta OBJETIVOS Objetivo Geral Objetivos Específicos METODOLOGIA ESTRUTURA DO TRABALHO FUNDAMENTAÇÃO TEÓRICA NET FRAMEWORK E PROJETO MONO NET Framework Projeto Mono MODELOS, ARQUITETURAS E PROTOCOLOS DE GERÊNCIA Conceitos FCAPS: Fault, Configuration, Accounting, Performance and Security CMIP/CMISE SNMP SOFTWARES DE MONITORAMENTO Nagios Cacti Tabela comparativa de softwares de gerência de redes PROJETO REQUISITOS FUNCIONAIS, NÃO FUNCIONAIS E REGRAS DE NEGÓCIO Motor Interface com o usuário DIAGRAMAS DE CASO DE USO Motor Interface com o usuário DIAGRAMAS DE CLASSE Motor iii

5 3.3.2 Interface DIAGRAMA ENTIDADE-RELACIONAL Desenvolvimento CLASSE DE MANIPULAÇÃO DE DADOS DO PROTOCOLO SNMP Padrão TLV Codificação/Decodificação BER A biblioteca de classes resultante O MOTOR DO UNMS Checando através de ICMP Checando serviços Checando os OIDs DESENVOLVIMENTO DA INTERFACE Construção de gráficos na plataforma.net Exibindo hosts no Google Earth Desenvolvimento da auto-descoberta de dispositivos TESTES DO UNMS Processo de testes da biblioteca de acesso SNMP Testes da ferramenta CONCLUSÕES...83 REFERÊNCIAS BIBLIOGRÁFICAS...85 iv

6 LISTA DE ABREVIATURAS API ASN.1 BCL BER CLR CMIP CMIS CMISE CMOT EGP FCAPS GPL ICMP IETF IL ISO ITU ITU-T JIT LPP MIB NGWS NMS OID OSI PDU RFC SGBD SMI SNMP TCC TLV TMN UNIVALI UNMS XML Application Programming Interface Abstract Syntax Notation One Base Class Library Basic Encoding Rules Common Language Runtime Common Management Interface Protocol Common Management Information Service Common Management Information Service Element Common Management over TCP/IP Exterior Gateway Protocol Fault, Configuration, Accounting, Performance and Security General Public License Internet Control Message Protocol Internet Engineering Task Force Intermediate Language International Standards Organization International Telecommunication Union ITU Telecommunication Standardization Sector Just in Time Compilation Lightweight Presentation Protocol Management Information Base Next Generation Windows Services Network Management System Object Identifier Open Systems Interconnection Protocol Data Unit Release For Comments Sistema Gerenciador de Banco de Dados Structure of Managed Information Simple Network Management Protocol Trabalho de Conclusão de Curso Type, Length and Value Telecommunications Management Networks Universidade do Vale do Itajaí Unified Network Management System Extensible Markup Language v

7 LISTA DE FIGURAS Figura 1. A Arquitetura.NET....8 Figura 2. Tratamento de arquivos para sistemas multi-plataforma...9 Figura 3. GTK# no Linux Figura 4. GTK# no Windows...10 Figura 5. Código fonte para detecção de plataforma...11 Figura 6. Resultado da detecção do sistema operacional no Linux Figura 7. Resultado da detecção do sistema operacional no Windows XP...11 Figura 8. Status do desenvolvimento do namespace System Figura 9. MIB do ambiente de gerenciamento Internet...13 Figura 10. Sistema de gerenciamento baseado em CMIP/CMIS...16 Figura 11. Relação entre o NMS e o Agente Figura 12. A árvore de objetos da SMIv Figura 13. Primeiras linhas de uma MIB...20 Figura 14. Formato da declaração de objetos gerenciáveis Figura 15. Definição de objetos gerenciáveis Figura 16. Definição da Sequence IfEntry...22 Figura 17. SMIv2 e novos ramos Figura 18. Definição de objetos gerenciáveis na SMIv Figura 19. MIB-II...25 Figura 20. Tela inicial do Nagios...30 Figura 21. Detalhes dos hosts Figura 22. Detalhes dos serviços...32 Figura 23. Recurso Mapa da Rede...33 Figura 24. Tela inicial do Cacti...34 Figura 25. Cadastro e/ou alteração de um dispositivo de rede no Cacti...37 Figura 26. Visualizando gráficos no Cacti...38 Figura 27. Exemplo de uso Figura 28. Modelo em camadas Figura 29. Diagrama de casos de uso do Motor...44 Figura 30. Diagrama de casos de uso da interface Figura 31. Interface de login...46 Figura 32. Interface principal do cadastro de hosts...48 Figura 33. Interface de configuração de monitoramento...49 Figura 34. Interface de cadastro de serviços...51 Figura 35. Interface de cadastro de usuários...52 Figura 36. Interface de visualização de estados de hosts Figura 37. Interface de visualização de estados dos serviços dos hosts...54 Figura 38. Interface de visualização da topologia da rede...55 Figura 39. Interface para a chamada da visualização de hosts no Google Earth Figura 40. Visualização de gráficos Figura 41. Visualização de eventos...58 Figura 42. Detectando hosts...60 Figura 43. Diagrama de classes do motor...61 Figura 44. Diagrama Entidade-Relacional...63 Figura 45. Formato de desenvolvimento Figura 46. Datagrama SNMP...66 vi

8 Figura 47. Espaço community do SNMP Figura 48. Valor binário de sete em sete bits...68 Figura 49. Resultado da codificação BER...68 Figura 50. Métodos da classe de codificação/decodificação BER...68 Figura 51. Métodos da classe de Snmp Figura 52. Métodos e atributos da classe SnmpData...70 Figura 53. Métodos da classe ICMP Figura 54. Exemplo de uso para o.net Charting e seu logotipo Figura 55..Net Charting no Visual Studio Figura 56..Net Charting e gráfico de barras...75 Figura 57. Exemplo de uso do.net Charting...75 Figura 58. Exemplo de KML Figura 59. Google Earth exibindo os hosts...78 Figura 60. Wireshark detectando os datagramas SNMP Figura 61. Comparando o datagrama correto (linha superior) e o incorreto (linha inferior)...80 Figura 62. O gráfico construído corretamente para medir a carga de processamento de um host vii

9 LISTA DE TABELAS Tabela 1. Tipos de dados SMIv Tabela 2. Novos tipos de dados da SMIv Tabela 3. Aprimoramentos na definição de objetos...23 Tabela 4. Novos termos...24 Tabela 5. Explicação dos ramos da MIB-II...25 Tabela 6. Tipos de traps...27 Tabela 7. Lista dos principais plugins do Nagios...28 Tabela 8. Arquivos padrões de configuração do Nagios...29 Tabela 9. Tabela comparativa de softwares de gerência de redes...39 Tabela 10. Bibliotecas SNMP pesquisadas...66 Tabela 11. Tipos de dado do protocolo SNMP utilizado no padrão TLV...67 Tabela 12. Dados sobre o segundo teste...81 viii

10 RESUMO KRIEGER NETO, Axel. UNMS: Plataforma Unificada para Gerenciamento de Redes. Itajaí, f. Trabalho de Conclusão de Curso (Graduação em Ciência da Computação) Centro de Ciências Tecnológicas da Terra e do Mar, Universidade do Vale do Itajaí, Itajaí, Com a expansão das redes de computadores, tornou-se necessária a utilização de softwares que monitorem seus recursos. A necessidade de gerenciamento otimizado resultou em vários padrões, arquiteturas e protocolos de gerência além de softwares de monitoramento de estados e grafadores. Neste trabalho é demonstrado o processo de desenvolvimento do UNMS, um software de monitoramento de redes construído para a plataforma.net e que une estes dois principais recursos. O estudo e compreensão do SNMP no nível de seus datagramas durante este processo bem como as regras básicas de codificação e o TLV foram documentados neste TCC. O resultado deste processo é um software de código aberto, com um motor que se torna multi-plataforma se utilizado junto com o projeto Mono. Palavras-chave: Gerência de Redes. Monitoramento de Redes. NMS. Plataforma.NET. SNMP. TLV. Regras básicas de codificação. Projeto Mono. ix

11 ABSTRACT Expansion of computer networks has made it necessary to use software to monitor netwoirking resources. The need for optimal management resulted in several standards, architectures and protocols in addition to the monitoring softwares of state diagrams and graphers. This work demonstrates the development process of UNMS, a network monitoring software built for the.net plataform and that unites those two main resources. The study and understanding at datagram level of SNMP during this process such as the basic encoding rules and TLV were documented in this paper. The result of this process is an open-source software, with a multi-plataform engine using Mono Project. Keywords: Network Management. Network Monitoring. NMS..NET Plataform. SNMP. TLV. Baisc Encoding Rules. Mono Project. x

12 1 INTRODUÇÃO As redes de computadores se tornaram presentes na maioria das organizações modernas. Poucas áreas, em um período tão curto, apresentaram tantas revoluções tecnológicas quanto as Redes de Computadores (TANENBAUM, 2003). O uso e a dependência da Internet como instrumento de agilidade para os negócios faz com que as Redes de Computadores sejam altamente utilizadas. O número de sistemas que necessitam desta tecnologia vem aumentando significativamente, tornando necessária a existência de rotinas que monitoram os diversos equipamentos que compõem a rede, como roteadores, switches, access points, computadores, etc., garantindo que os dispositivos não estejam apenas funcionando, mas também operando de forma otimizada. Para este propósito, foram criados protocolos de gerência de redes como o SNMP (Simple Network Management Protocol Protocolo Simples de Gerência de Redes) e o CMIP (Common Management Information Protocol Protocolo de Gerência de Informações Comuns). O processo de monitoramento é considerado uma parte do processo de gerenciamento de rede. Gerenciamento de rede inclui o oferecimento, a integração e a coordenação de hardware, software e humanos, para monitorar, testar, consultar, configurar, analisar, avaliar e controlar os recursos da rede, e de elementos, para satisfazer às exigências operacionais, de desempenho e de qualidade de serviço em tempo real a um custo razoável (SAYDAM, 1996). O protocolo SNMP é o padrão de facto para a obtenção de tais indicadores (MAURO; SCHMIDT, 2001, tradução nossa) sendo, portanto, o protocolo adotado para a construção do UNMS. A tarefa de se encontrar um único software que trate todas as necessidades de gerenciamento não é trivial e geralmente frustra o administrador, já que dificilmente se encontra algum software que, ao mesmo tempo em que monitora os recursos, faz gráficos de carga e produz alertas. Além disso, os softwares de gerenciamento costumam ser de difícil configuração, já que a maioria é configurada através de arquivos de texto, que em muitos casos são muito complexos. Também existem os softwares de difícil utilização, obrigando o administrador da rede a estudar dezenas de linhas de comando para se extrair um mínimo de informação. Atualmente, existem vários softwares que monitoram a rede em utilização, como por exemplo, o Nagios (NAGIOS, 2008) e o Cacti (CACTI, 2008). Vários administradores de rede

13 utilizam os dois em conjunto. O Nagios monitora os recursos da rede e emite alertas mediante estados indesejados. Já o Cacti grafa a carga e/ou utilização de recursos. Neste cenário, ocorre a dificuldade de configurar, já que ambos são manipulados em ambientes distintos, fazendo-se necessário o cadastro dos equipamentos duas vezes, ou mais, se o administrador considerar necessárias outras ferramentas de apoio à gestão da infra-estrutura, gerando redundância de dados entre outros problemas. Neste trabalho, é demonstrada a construção de um software chamado UNMS (Unified Network Management System Sistema de Gerenciamento de Redes Unificado), cujo objetivo é de tratar a dependência de mais de um software de gerencia de redes evitando as redundâncias descritas. Destaca-se o estudo em mais baixo nível do protocolo SNMP. Isto foi necessário devido a falta de bibliotecas nativas do.net que tratam deste protocolo. 1.1 PROBLEMATIZAÇÃO A problematização do presente trabalho será abordada através da: Formulação do problema; e Solução Proposta Formulação do Problema Pode-se considerar que existe, atualmente, uma grande dependência da Internet como ferramenta do dia-a-dia, resultando em um alto grau de uso de redes de computadores. Devido a este crescimento, houve a necessidade da criação de sistemas que monitoram e gerenciam todos os dispositivos de rede. Os sistemas atuais que monitoram a rede foram criados para solucionar parte dos problemas. Uns simplesmente monitoram os estados dos hosts, emitindo alertas ou apenas exibindo informações sobre eles. Outros ainda exibem informações de serviços de rede como um servidor Web por exemplo. Ainda existem sistemas que constroem gráficos de utilização de recursos, que permitem ao administrador de rede, visualizar as informações de um modo mais fácil e amigável, podendo resultar em tomadas de decisão mais eficientes e corretas. 2

14 Devido a existência de vários tipos de sistemas de monitoramento de redes, existe também a necessidade de possuir mais de um, com a finalidade de garantir um alto grau de controle sobre a rede. Ao utilizar vários sistemas de monitoramento o administrador da rede é forçado a configurar cada um individualmente, podendo resultar em inconsistências. Além disso, existem casos em que sistema é de difícil utilização, sendo apenas executado usando linhas de comando na maioria das vezes bastante extensas. Outros ainda são de difícil configuração, sendo ajustados por vários arquivos de texto, obrigando o administrador a estudá-los exaustivamente antes que consiga algum tipo de resultado. Analisando pelo lado do desenvolvedor de softwares, existe também uma ausência de bibliotecas de classes, que fazem com que a utilização do protocolo SNMP seja mais simples. A existência de bibliotecas que atinjam esta necessidade fará com que o desenvolvedor se preocupa mais com a lógica de negócio e reduzindo o tempo de construção de softwares Solução Proposta Neste trabalho foi construída uma ferramenta de gerência de redes de computadores que é fácil de utilizar, configurar e instalar. Além disto, o motor desta ferramenta é compatível com vários sistemas operacionais diferentes. O envio de alertas da ferramenta é limitado à exibição destes na tela e ao envio de s. A solução sanou problemas das soluções similares analisadas. As soluções de monitoramento estudadas foram o Nagios (NAGIOS, 2008) e Cacti (CACTI, 2008). O motor do UNMS foi construído utilizando o projeto Mono, uma implementação de código aberto da plataforma.net, que permite aos programadores criarem e executarem aplicações em vários sistemas operacionais como Linux, Mac OS X e o Windows. A linguagem que foi adotada para a construção da ferramenta é a C# e o SGBD (Sistema de Gerenciamento de Banco de Dados) será o PostgreSQL. Já a interface foi construída ignorando aspectos de compatibilidade com o projeto Mono. Buscando facilitar a utilização do SNMP na plataforma.net bem como o correto funcionamento do motor, foi construído uma biblioteca de classes própria. Esta contém uma classe principal que manipula as informações do protocolo através de métodos estáticos, tornando seu uso direto e objetivo. 3

15 1.2 OBJETIVOS específicos. Os objetivos do trabalho são compostos pelo objetivo geral e por cinco objetivos Objetivo Geral O objetivo geral deste trabalho é especificar e produzir um software de gerência para redes de computadores com interface gráfica local que contemple as tarefas de mapas de estado e grafagem de objetos, endereçando as principais dificuldades encontradas no uso dos softwares de mesmo propósito disponíveis para uso Objetivos Específicos Os objetivos específicos deste projeto de pesquisa são: Listar as principais características de softwares de gerência de redes de código aberto; Compreender a especificação.net implementada através do projeto de código-fonte aberto Mono; Especificar e construir o UNMS; Testar e validar o comportamento do UNMS aplicando-o em uma infra-estrutura de rede; e Documentar o desenvolvimento e os resultados do sistema. 1.3 Metodologia A realização da primeira parte do trabalho de conclusão de curso seguiu duas etapas principais: estudo e projeto. A primeira parte do trabalho teve como objeto de estudo a plataforma.net e o projeto Mono. Além disso, foram estudadas as arquiteturas, protocolos e conceitos relacionados à gerência de redes, necessários para compreender como construir a solução proposta. Também, foram estudados outros aplicativos de gerência de redes, através dos quais foi possível enumerar vários recursos interessantes. Todos os estudos foram realizados utilizando a Internet e livros, e os resultados foram descritos na seção de Fundamentação Teórica. 4

16 A etapa de projeto teve como objetivo modelar o sistema através da construção de diagramas de caso de uso, classe e entidade-relacional. Os recursos mais importantes enumerados, ainda na etapa anterior, foram considerados na elaboração do projeto. A etapa de desenvolvimento foi a que englobou a criação das bibliotecas básicas e a construção do motor e da interface. Além disso, foram realizados estudos adicionais e mais aprofundados, necessários para a construção de alguns recursos. 1.4 Estrutura do trabalho A estrutura deste trabalho é composta por quatro seções principais: Introdução, Fundamentação Teórica, Projeto, Desenvolvimento e Conclusão. A Introdução aborda o trabalho como um todo, explicando o problema, mostrando os objetivos a serem alcançados e a solução proposta. A seção de Fundamentação Teórica aborda os assuntos necessários para construir a solução proposta. São demonstradas as principais arquiteturas e conceitos existentes na área de gerência de redes bem como a plataforma em que se deseja programar a solução, o Mono, traçando um comparativo simplificado entre este e a implementação de referência da Microsoft. A terceira seção aborda o projeto de software, que descreve os requisitos funcionais, requisitos não funcionais e as regras de negócio. Os diagramas do projeto escolhidos para esta solução são exibidos e explicados, bem como a importância de contemplá-los em um projeto de software. A seção de Desenvolvimento aborda os principais aspectos a serem descritos durante a construção de toda a solução proposta. A criação de bibliotecas, estudos mais aprofundados e testes são documentados nesta sessão. A última etapa exibe as conclusões tiradas sobre este trabalho de conclusão de curso. 5

17 2 FUNDAMENTAÇÃO TEÓRICA A fundamentação teórica deste trabalho irá abordar os seguintes temas: (i).net Framework e Projeto Mono; (ii) protocolos, arquiteturas e conceitos de gerência de redes; (iii) protocolo de gerência de rede SNMP; (iv) descrição das ferramentas de monitoramento de código aberto. 2.1.NET Framework e Projeto Mono Nas seções seguintes, serão exibidos os estudos do.net Framework e uma implementação alternativa e de código aberto, o Projeto Mono NET Framework.NET é a plataforma criada pela Microsoft no final dos anos 90 utilizando o nome NGWS (Next Generation Windows Services Nova Geração de Serviços Windows), entretanto, foi no ano 2000 que a Microsoft liberou a primeira versão beta do.net 1.0. O.NET fornece uma nova API (Application Programming Interface Interface de Programação de Aplicativos), com novas funcionalidades, novas ferramentas para a construção de aplicações para o Microsoft Windows e Web, novos componentes e novos serviços (TEMPLEMAN; VITTER, 2002, tradução nossa). Uma nova API se tornou necessária para aplicações Windows, pelo fato de que sua API foi escrita em C e cresceu com o passar dos anos. Atualmente, a API do Windows possui milhares de rotinas e vários problemas, já que os novos recursos da API foram adicionados pouco a pouco e com pouca organização. O fato de que a API do Windows seja construída em C acaba dificultando o desenvolvimento em outras linguagens, inclusive em linguagens mais modernas orientadas a objetos (IBIDEM). Várias linguagens podem ser utilizadas para se desenvolver na plataforma.net, entres as quais o C#, Visual Basic.NET e J# se destacam. As aplicações desenvolvidas com essas linguagens são compiladas para o IL (Intermediate Language Linguagem Intermediária), que se assemelha ao bytecode do Java. Isto significa que ao se desenvolver usando Visual Basic.NET, C# ou qualquer outra linguagem suportada, a aplicação será compilada para a mesma linguagem, a IL. Com a aplicação já compilada para a IL, é necessário um mecanismo para executá-la. Este mecanismo é o CLR (Common Language Runtime - Linguagem Comum de Tempo de Execução).

18 O CLR dispõe de vários recursos como, JIT (Just in Time Compilation Compilação em tempo de execução), responsável por traduzir o IL em código nativo, Garbage Collection (coleta de lixo), políticas de segurança e serviços de depuração. Com estes recursos, o CLR se situa entre o sistema operacional e a aplicação, provendo a segurança e controlando o acesso à memória, permitindo acesso transparente aos serviços do sistema operacional. A plataforma.net possui sua própria biblioteca de classes (BCL - Base Class Library). Conforme Templeman e Viter (2002, tradução nossa), a BCL não é especifica para uma única linguagem, podendo ser utilizada por qualquer linguagem que será compilada para a IL. Além disso, a BCL é orientada à objetos, disponibilizando suas funcionalidades através de um grande número de classes organizadas em vários namespaces 1. A BCL fornece ao desenvolvedor os seguintes itens: Definição de tipos básicos como int, char, entre outros. Tipos de coleção genéricos como vetores, listas, pilhas, tabelas hash, enumeradores e filas. As classes podem definir suas exceções usando a BCL, sendo possível gerar uma exceção usando C# e tratá-la usando VB.NET. Classes para tratamento do console, arquivos, entrada e saída, sockets, etc. Classes para desenvolver interfaces gráficas, desenhos em duas dimensões, tratamento de imagens e impressão. Serialização de objetos, um modo de salvar os objetos que estão na memória em um arquivo XML ou binário. Também possibilita carregar os objetos de um arquivo. Classes que implementam e gerenciam segurança. Classes para construção de aplicações distribuídas e sistemas Web. Classes para lidar com XML. Utilização de recursos do Sistema Operacional como threads (processos), timers, etc. 1 Namespaces são utilizados para organizar classes. 7

19 O recurso de compilação Just in Time da arquitetura.net permite que o código IL seja portável e eficiente. A eficiência é garantida quando o código IL é compilado para o código nativo em tempo de execução. Neste modo, a compilação ocorre quando o método é executado pela primeira vez, e nas suas execuções seguintes, ele já executará o código nativo. Outro modo de funcionamento do JIT é a compilação em tempo de instalação. Além disso, segundo Templeman e Vitter (2002, tradução nossa), a plataforma.net será portável assim que a IL seja suportada em outros sistemas operacionais. O recurso de Garbage Collection (coleta de lixo), é um recurso bastante útil presente na plataforma.net. Ele elimina problemas presentes em linguagens como o C, na qual os programadores tem que desalocar manualmente a memória. O gerenciamento manual de memória pode gerar grandes problemas. Caso o programador esqueça de desalocar a memória ou a desaloque mais de uma vez, o programa poderá gerar erros. (TEMPLEMAN; VITTER, 2002, tradução nossa). A disposição dos itens da arquitetura.net são exibidos na Figura 1. Figura 1. A Arquitetura.NET. Fonte: Templeman e Vitter (2002). Uma alternativa aos desenvolvedores.net é o projeto de código aberto Mono. Ele suporta praticamente as mesmas linguagens que o.net Framework suporta e, pode ser executado em vários Sistemas Operacionais baseados em Unix, além de Mac OS X e o próprio Windows. 8

20 2.1.2 Projeto Mono Mono é uma implementação multi-plataforma e de código aberto do.net Framework. Neste projeto, o principal compilador é destinado à linguagem C#, já que esta foi desenvolvida especialmente pela Microsoft no.net Framework. Entretanto, conforme Bornstein e Dumbill (2004, tradução nossa), existem compiladores para o Mono com outras linguagens como Java, C, Basic e Cobol. A CLR (Common Language Runtime - Linguagem Comum de Tempo de Execução) faz parte do projeto, garantindo que a aplicação rode de modo seguro, evitando travamentos, desperdícios de memória e garantindo um alto desempenho. As vantagens do Just In Time Compiler já mencionadas, também estão presentes no projeto Mono. Assim como na plataforma.net, no Mono uma aplicação é compilada para a IL (Intermediate Language Linguagem Intermediária). Isto garante a portabilidade da aplicação, já que o Mono pode ser instalado nos sistemas operacionais Linux, Solaris, Mac OS X, Windows e Unix (MONO, 2008, tradução nossa). Para executar o mesmo software em sistemas operacionais diferentes, algumas práticas devem ser adotadas, já que nem todos eles foram criados da mesma forma (BORNSTEIN; DUMBILL, 2004 tradução nossa). A primeira delas trata da diferença no caractere separador de diretórios quando se está trabalhando com arquivos. A Figura 2 demonstra estas diferenças. String directory = tmp ; String filename = thefile ; //Modo incorreto String filepath = directory + / + filename; //Modo correto 1 String filepath = System.IO.Path.Combine(directory, filename); //Modo correto 2 String filepath = directory + System.IO.Path.DirectorySeparatorChar + filename; Figura 2. Tratamento de arquivos para sistemas multi-plataforma. Fonte: Adaptado de Bornstein e Dumbill (2004). No mesmo contexto de arquivos, ainda existem problemas ao se trabalhar com o diretório raiz. No sistema operacional linux, existe apenas um diretório raiz o /. No Windows, podem existir vários diretórios sendo diferenciados por letras (C:\, D:\,...). Para contornar este problema, pode-se utilizar o método System.IO.Directory.GetLogicalDrives(), que retornará uma ou mais Strings contendo os 9

21 diretórios raízes do sistema operacional. Além disto, deve-se ressaltar que alguns sistemas operacionais são sensíveis à caixa (como o Linux) e outros não (como o Windows). Outro problema é a definição de qual módulo de interface gráfica (GUI) utilizar. Para o Mono, pode-se utilizar os módulos GTK#, Qt#, System.Windows.Forms entre outros. Cada um deles é recomendado para diferentes sistemas operacionais e/ou ambientes gráficos. O GTK# é principalmente destinado para ser utilizado no Gnome além de ter boa compatibilidade com o Windows de 32 bits, demonstrado pelas Figura 3 e Figura 4 (SCHÖNIG; GESCHWINDE, 2003, tradução nossa). Já o System.Windows.Forms é o mais recomendável para o uso no Windows, e é compatível com as versões x86 do linux (BORNSTEIN; DUMBILL, 2004, tradução nossa). Figura 3. GTK# no Linux. Figura 4. GTK# no Windows. Outro ponto crítico é quando se trata das configurações de cada aplicação desenvolvida. Em aplicativos para Windows, na maioria das vezes, as aplicações guardam suas configurações no registro, não presente em outros sistemas operacionais. Portanto, não se pode desenvolver 10

22 aplicações que utilizam o registro do Windows, caso o objetivo a ser alcançado seja a portabilidade do aplicativo (IBIDEM). Existem outros tipos de compatibilidades e para lidar com elas faz-se necessário uma codificação específica para cada plataforma. A detecção de diferentes plataformas através do código fonte é demonstrada pela Figura 5. Utilizando o atributo VersionString, é possível utilizar if ou switch-case para separar códigos de diferentes sistemas operacionais. using System; using System.Diagnostics; namespace sodetection { class MainClass { public static void Main(string[] args) { OperatingSystem os = Environment.OSVersion; Console.WriteLine(os.VersionString); } } } Figura 5. Código fonte para detecção de plataforma. Fonte: Adaptado de Bornstein e Dumbill (2004). Os resultados da execução do código da Figura 5 são exibidos pelas Figura 6 para o sistema operacional Linux e Figura 7 para o Windows XP Service Pack 3. Figura 6. Resultado da detecção do sistema operacional no Linux. Figura 7. Resultado da detecção do sistema operacional no Windows XP. 11

23 Mono é uma boa alternativa para os desenvolvedores, entretanto, ele não possui todas as classes do.net Framework disponíveis. A Figura 8 mostra os estados das partes do namespace System, o maior e mais utilizado. Figura 8. Status do desenvolvimento do namespace System. Fonte: Mono (2008). 2.2 Modelos, arquiteturas e protocolos de gerência Atualmente existem várias arquiteturas, modelos e protocolos de monitoramento de redes propostos por várias organizações em todo o mundo. Uns são utilizados em larga escala enquanto outros não passam de conceitos. As arquiteturas, modelos e protocolos de gerência direcionados às redes de dados serão mostrados nos sub-tópicos seguintes Conceitos O ambiente de gerenciamento OSI (Open Systems Interconnection Interconexão de Sistemas Abertos) de redes possui os conceitos de Gerente, Agentes e Objetos Gerenciados. O Gerente possui a capacidade de receber notificações, informações e realizar ações de controle sobre 12

24 os Objetos Gerenciados. Um objeto gerenciável é qualquer recurso que está sujeito a ações de gerenciamento, como uma conexão, uma interface de rede ethernet ou uma porta de roteador, etc. O Agente executa operações de gerenciamento sobre os objetos gerenciados, como desligar a interface 11 do switch ou solicitar a quantidade de octetos que trafegaram na referida porta. Neste ambiente, aplica-se o protocolo CMIP (TAROUCO et al, 1993). No ambiente de gerenciamento das redes interligadas à Internet, aplica-se o protocolo SNMP (Simple Network Management Protocol Protocolo Simples de Gerencia de Redes). Este ambiente é bastante semelhante ao de gerenciamento OSI, pois a maioria dos conceitos abordados é comum a ambos. Entretanto, a organização da árvore de objetos gerenciados é diferente (IBIDEM). A MIB (Managed Information Base Base de Informações Gerenciais) é um conjunto de objetos gerenciados. Seu conceito é empregado tanto no padrão OSI quanto no Internet (IBIDEM). A organização de objetos na MIB é feita seguindo um conjunto de regras definidos na SMI (Structure of Managed Information Estrutura de Informações Gerenciais). O acesso aos dados dos objetos é feito utilizando a notação ISO ASN.1 (Abstract Syntax Notation, One- Notação de Sintaxe Abstrata, Um). Para identificar um objeto, utiliza-se o OID (Object Identifier Identificador de Objeto) que são números separados por pontos. A Figura 9 ilustra o início da árvore do ambiente de gerenciamento Internet (MAURO; SCHMIDT, 2001, tradução nossa). Figura 9. MIB do ambiente de gerenciamento Internet. Fonte: Adaptado de TAROUCO et al (1993) e MAURO e SCHMIDT (2001). 13

25 Para o Objeto Management, o OID resultante seria Todo objeto gerenciável deste modelo iniciará com o identificador exemplificado. Segundo Mauro e Schmidt (2001, tradução nossa), O Nó Raiz não possui qualquer nome ou número. A descrição da SMI Internet será aprofundada adiante. Neste sub-seção, foram explicados os conceitos necessários para o entendimento dos subseções seguintes FCAPS: Fault, Configuration, Accounting, Performance and Security FCAPS é um modelo de gerência de redes definido por ITU-T que era direcionado a área de telecomunicações. A ISO (International Standards Organization Organização de Padrões Internacionais) foi a entidade responsável por aplicar a FCAPS em redes de dados. Este modelo divide a gerência em cinco áreas funcionais (NETWORKDICTIONARY, 2008a, tradução nossa): Fault Management (gerência de falhas): serve para detectar, criar registros, notificar os usuários e até consertar possíveis erros fazendo com que a rede continue funcionando. Ao ocorrer um erro, uma mensagem o gerente de rede pode ser avisado, através de um protocolo de gerência de redes como o SNMP. Configuration Management (gerência de configurações): serve para monitorar a rede, as configurações do sistema, além das várias versões de hardware e software. A importância deste item aumenta conforme o tamanho da rede. Accouting Management (gerência de contas): a medição da utilização da rede pode ser monitorada de forma individual ou por grupo. Além disto, pode-se detectar se a rede está sendo utilizada para o propósito correto. Alguns dos itens que podem ser monitorados são: uso de CPU, link e disco. Para este propósito, um protocolo bastante utilizado é o RADIUS. Performance Management (gerência de desempenho): as variáveis que compõem a medição do desempenho de uma rede são a vazão (throughput) da rede, os tempos de resposta e a taxa de utilização da rede. Este item trata justamente desta medição. Security Management (gerência de segurança): este item trata da segurança da rede, garantindo que as informações que trafegam nela sejam acessadas apenas por pessoas autorizadas, além de evitar que a rede sofra algum tipo de ataque. 14

26 O modelo FCAPS é uma extensão de um framework conceitual de gerencia de redes chamado TMN (Telecommunications Management Networks Gerência de Redes de Telecomunicações), no qual também se identificam as mesmas cinco áreas de funcionais de gerenciamento, com pequenas alterações (IBIDEM). O objetivo do TMN é:...prover uma estrutura organizada para interconectar vários tipos de Sistemas de Suporte à Operação e equipamentos de telecomunicações para a troca de informações de gerenciamento de interfaces padronizadas que incluem a definição de protocolos e mensagens (TAROUCO et al, 1993). O FCAPS define várias regras que abordam os principais aspectos da gerência de redes. Outra abordagem que mescla diversos aspectos das práticas de gerência apresentadas é o CMIP CMIP/CMISE CMIP (Common Management Information Protocol Protocolo de Gerência de Informações Comuns) que é um protocolo da ISO (International Standards Organization Organização Internacional de Padrões) e é utilizado em conjunto com o CMIS (Common Management Information Services Serviço de Gerência de Informações Comuns). Este padrão em conjunto com o padrão SNMP são os mais importantes (Networkdictionary, 2008a, tradução nossa). Conforme Kurose e Ross (2007), o CMIP foi projetado para ser independente de produtos ou fabricantes específicos e inicialmente era concorrente do protocolo SNMP. Tanto CMIP quanto CMISE também são utilizados na arquitetura CMOT (Common Management over TCP/IP Gerenciamento comum sobre TCP/IP) (TAROUCO et al, 1993) ou (CMIP over TCP/IP CMIP sobre TCP/IP) (MILLER, 1997, tradução nossa). O CMOT é baseado na estrutura de gerenciamento OSI e nos modelos, serviços e protocolos desenvolvidos pela OSI para gerenciamento de redes (TAROUCO et al, 1993). Conforme o Networkdictionary (2008b, tradução nossa), o CMIS define um sistema de gerência de redes, já o CMIP supre a necessidade da existência de uma interface que provê funções que podem ser utilizadas tanto por protocolos de gerência de redes que estão conformes com a ISO e até por protocolos customizados. CMIP utiliza o mecanismo de transporte orientado à conexão já que utiliza o protocolo TCP. Isto pode ser considerado uma desvantagem, já que se um dispositivo de rede estiver com 15

27 problemas, o software de gerência só poderá receber dados do dispositivo após efetuar uma conexão com este. Apesar disso, este protocolo possui embutido um sistema de segurança que suporta controle de acesso, autorização e gravação de registros. Quando aplicado na arquitetura CMOT, o CMIP pode ser utilizado com o protocolo LPP (Lightweight Presentation Protocol Protocolo de Apresentação Simples). Neste caso, devido o uso do LPP, o CMIP poderá rodar tanto no protocolo TCP quanto no UDP, conforme em Tarouco et al (1993): O CMOT deixa a escolha de TCP ou UDP para a aplicação de gerenciamento. Os sistemas dentro de um ambiente de LAN (Local Area Network Rede local) são melhor servidos pela escolha do UDP, enquanto os sistemas em um ambiente WAN (Wide Area Network Rede de longa distância) deveriam escolher TCP. O protocolo CMIP de modo algum especifica o software de gerenciamento, apenas define como será a comunicação entre agentes e o software (Networkdictionary, 2008b, tradução nossa). Este esquema de comunicação é mostrado na Figura 10. Figura 10. Sistema de gerenciamento baseado em CMIP/CMIS. Fonte: Adaptado de Networkdictionary (2008b). Conforme Networkdictionary (2008b, tradução nossa), o CMIP possui vantagens quando comparado ao SNMP: 16

28 CMIP além de obter informações, pode realizar tarefas, o que é impossível no SNMP. Possui segurança embutida. Provê recursos poderosos que permitem aplicações gerenciais de realizarem mais tarefas com uma única requisição. Em redes em condições incomuns, ele gerará relatórios melhores. O acesso de informações gerenciais em objetos gerenciáveis é feito através do CMISE (Common Management Information Service Element Elemento do Serviço de Gerência de Informações Comuns), o qual utiliza o CMIP para requisitar informações (TAROUCO et al, 1993). Por último, é revisado o SNMP, protocolo para a gerência que se consolidou com o advento da Internet SNMP O SNMP (Simple Network Management Protocol Protocolo Simples para o Gerenciamento de Redes) é um protocolo de gerência de redes. Foi introduzido em 1988 para suprir uma necessidade crescente de gerenciamento de dispositivos que utilizam o protocolo IP (Internet Protocol) como roteadores, switches, modems, access points, etc. Seu coração é um conjunto simples de operações que permite aos softwares de gerência relatarem os dados de dispositivos de rede suportados. Por exemplo, pode-se utilizar SNMP para desligar uma interface de um roteador ou checar a velocidade da interface Ethernet. SNMP pode ainda monitorar a temperatura de um switch e até gerar um alerta se esta ficar muito alta (MAURO; SCHMIDT, 2001, tradução nossa). Existem atualmente três versões do protocolo SNMP (IBIDEM): SNMP versão 1 (SNMPv1): é a versão definida pelo RFC 1157 (RFC 1157, 1989), padrão da IETF (Internet Engineering Task Force Força Tarefa de Engenharia da Internet). A segurança desta versão é baseada em comunidades, que nada mais são do que senhas. Pode-se definir uma comunidade com acessos de somente leitura para acessar apenas informações ou leitura e escrita que podem alterar configurações. Uma terceira comunidade é chamada de trap. SNMP versão 2 (SNMPv2): esta versão é chamada tecnicamente de SNMPv2c. É definida pelos RFC 1905 (RFC 1905, 1996), RFC 1906 (RFC 1906, 1996) e RFC

29 (RFC 1907, 1996). Segundo a IETF, ainda encontra-se em estado experimental, entretanto, alguns fabricantes de equipamentos de rede já estão disponibilizando equipamentos de rede com suporte desta versão. SNMP versão 3 (SNMPv3): ainda em estado experimental, a SNMPv3 terá vários recursos novos como uma autenticação mais segura e comunicação privada entre entidades gerenciadas. A versão é definida pelos RFC da versão 2 e os RFC 2571 (RFC 2571, 1999), RFC 2572 (RFC 2572, 1999), RFC 2573 (RFC 2573, 1999), RFC 2574 (RFC 2574, 1999) e RFC 2575 (RFC 2575, 1999). O protocolo SNMP não é orientado a conexões como o CMIP, já que utiliza o protocolo UDP (User Datagram Protocol Protocolo de Datagrama do Usuário). Isto significa que o SNMP possui um desempenho superior, já que não existe um overhead (sobrecarga) da conexão. Além disso, o UDP não possui timeouts, este é programado diretamente no software de gerenciamento Gerenciadores e Agentes O protocolo SNMP aplica os conceitos de gerente e agente (MILLER, 1997, tradução nossa). O Gerenciador, também conhecido como NMS (Network Management Station Estação de Gerenciamento da Rede) se comunica com os agentes através de requisições chamadas polling (teste e resposta). O Agente pode alertar o NMS quando utiliza os traps, que funcionam como gatilhos que são disparados caso alguma condição seja alcançada (MAURO; SCHMIDT, 2001, tradução nossa). A Figura 11 mostra a relação entre o NMS e o Agente. Apesar de que a figura demonstre ações de forma separada, o NMS pode realizar o polling e receber traps ao mesmo tempo. Figura 11. Relação entre o NMS e o Agente. Fonte: Adaptado de Mauro e Schmidt (2001). 18

30 Assim como os agentes e o NMS, o conhecimento sobre a SMI e suas versões é primordial para o entendimento do protocolo SNMP SMIv1 Cada versão do protocolo SNMP possui uma versão de SMI. Na SMI versão 1, a definição de Objetos Gerenciáveis é composta por três itens: 1. Nome: é o que identifica o objeto gerenciável. Este item pode ser um nome ou o OID (Object Identifier). 2. Tipo e sintaxe: O tipo do objeto é definido usando a sintaxe ASN.1. É um modo de definir como os dados serão transmitidos entre gerenciadores e agentes. Os tipos de objetos são parecidos com os da linguagem C. A Tabela 1 exibe os principais tipos. 3. Encoding (Codificação): Uma instância de um objeto gerenciado é codificada numa string de octetos usando BER (Basic Encoding Rules Regras Básicas de Codificação). Tabela 1. Tipos de dados SMIv1 Tipo de dado Integer Octect String Descrição É um número inteiro de 32 bits, bastante utilizado para dados enumerados. Para enumeração, o 0 não é considerado. É uma string (seqüência de caracteres) de octetos, usado para transmissão de texto ou identificação física de uma interface de rede. Counter É um valor de 32 bits com o valor mínimo zero e o máximo igual a Quando o valor máximo é atingido, ele volta para zero e recomeça. É utilizado para contagem de qualquer item, como quantidade de erros numa interface de redes ou octetos que trafegaram nesta interface. É um valor que sofre incrementação, sendo que uma decrementação ocorre apenas em casos de erros. Quando o agente é reiniciado, os dados do tipo Counter recebem zero. Object Identifier Sequence Sequence of IP Address O OID é definido por números decimais separados por pontos. Define uma lista de vários tipos de dados com sintaxe ASN.1, parecendo uma tabela. Define um objeto gerenciável feito com o tipo Sequence. É um valor de 32 bits que representa um IP versão 4. Ambas as SMIv1 e SMIv2 não possuem suporte ao IP versão 6. Gauge É um valor de 32 bits com o valor mínimo zero e o máximo igual a Diferente do Counter, este tipo pode decrementar normalmente. A velocidade de uma interface de um roteador é medida com Gauge. TimeTicks É um valor de 32 bits com o valor mínimo zero e o máximo igual a Este tipo mede o tempo em centenas de segundos. O uptime (tempo ligado) de um dispositivo é medido com este tipo. Fonte: Adaptado de Mauro e Schmidt (2001). 19

31 Como já mencionado, os objetos gerenciáveis estão dispostos na SMI numa estrutura em árvore. É através desta árvore que se define o Object Identifier (identificador do objeto). A árvore SMI com suas partes mais importantes é demonstrada na Figura 12. Figura 12. A árvore de objetos da SMIv1. Fonte: Adaptado de Mauro e Schmidt (2001) MIB do SMIv1 Uma MIB é definida usando a sintaxe ASN.1. Conforme Mauro e Schmidt (2001), É muito importante que se saiba ler e entender uma MIB já que em alguns casos pode ser necessário implantar uma ou parte dela. Na Figura 13 é demonstrado o código de uma versão de uma MIB. Os comentários são iniciados por --. RFC1213-MIB DEFINITIONS ::= BEGIN IMPORTS mgmt, NetworkAddress, IpAddress, Counter, Gauge, TimeTicks FROM RFC1155-SMI OBJECT-TYPE FROM RFC 1212; mib-2 OBJECT IDENTIFIER ::= { mgmt 1 } Figura 13. Primeiras linhas de uma MIB. Fonte: Mauro e Schmidt (2001). As primeiras linhas de uma MIB foram apresentadas na Figura 13. Na primeira linha, define-se o nome da MIB, que no caso é RFC1213-MIB (RFC ). A sessão IMPORTS, permite que sejam importados tipos de dados e OIDs de outras MIBs. No caso acima, foram importados tipos de dados da RFC 1155 (RFC 1155, 1990) SMI (SMIv1), que incluem: 20

32 mgmt; NetworkAddress; IpAddress; Counter; Gauge; e TimeTicks. Além disso, foi importado o Object Type RFC 1212 (RFC 1212, 1991), o qual define a maneira de como a MIB foi escrita. A última linha da Figura 13 define o início dos OIDs dos objetos gerenciáveis. Por ser mgmt, o OID equivalente é Após a sessão de IMPORTS, parte-se então para a definição dos objetos gerenciáveis (IBIDEM), que seguem o formato demonstrado pela Figura 14. <nome> OBJECT-TYPE SYNTAX <tipo de dado> ACCESS <pode ser read-only, read-write, write-only, ou not-accessible> STATUS <mandatory, optional, ou obsolete> DESCRIPTION "Descrição textual do objeto gerenciável." ::= { <Um OID único do objeto gerenciável.> } Figura 14. Formato da declaração de objetos gerenciáveis. Fonte: Mauro e Schmidt (2001). Para exemplificar a definição de objetos gerenciáveis, utilizou-se o iftable, que nada mais é que uma lista de interfaces de rede num dispositivo gerenciável. iftable OBJECT-TYPE SYNTAX SEQUENCE OF IfEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "A list of interface entries. The number of entries is given by the value of ifnumber." ::= { interfaces 2 } Figura 15. Definição de objetos gerenciáveis. Fonte: Mauro e Schmidt (2001). A sintaxe deste objeto é SEQUENCE OF IfEntry, que é uma tabela que possui colunas que são definidas pela IfEntry. O objeto está marcado como inacessível, portanto, não é possível fazer com que o agente consulte este objeto. Seu status é mandatory (obrigatório) significando que o agente precisa implementar este objeto para ser compatível com os padrões da especificação MIB- 21

33 II. O campo Description (descrição) descreve o que é este objeto. Na última linha da Figura 15, define-se o OID, que é ou iso.org.dod.internet.mgmt.interfaces.2. Na Figura 16, é demonstrado um trecho da definição da Sequence IfEntry. IfEntry ::= SEQUENCE { ifindex INTEGER, ifdescr DisplayString, iftype INTEGER, ifmtu INTEGER, (...) ifspecific OBJECT IDENTIFIER } Figura 16. Definição da Sequence IfEntry. Fonte: Mauro e Schmidt (2001). Na definição da Sequence nota-se que seu nome começa com letra maiúscula, diferente de quando se define um objeto gerenciável. Como uma Sequence se parece com uma tabela, nesta esperamos encontrar todos os tipos descritos em sua definição. A adição de novos registros também pode ser feita pelo NMS (MAURO; SCHMIDT, 2001, tradução nossa) SMIv2 e sua MIB A SMIv2 adiciona novos itens à arvore de objetos gerenciáveis além de mais tipos de dados. A principal novidade é o ramo snmpv2, que possui o OID A Figura 17 exibe a SMIv2. Figura 17. SMIv2 e novos ramos. Fonte: Mauro e Schmidt (2001). 22

34 Os novos tipos de dados incluídos na SMIv2 estão na Tabela 2. Tabela 2. Novos tipos de dados da SMIv2 Tipo de dado Descrição Integer32 Mesmo que Integer (inteiro). Counter32 Mesmo que Counter (contador). Gauge32 Mesmo que Gauge. Unsigned32 Representa um valor decimal que vai de 0 até Counter64 Similar ao Counter32, entretanto seu valor máximo é Sendo seu valor máximo bem alto, este tipo se torna ideal para contadores que podem ser reiniciados antes do tempo desejado. BITS Uma enumeração de bits não negativos. Fonte: Adaptado de Mauro e Schmidt (2001). Na SMIv2 também houve mudanças na especificação dos objetos gerenciáveis através da adição de novos campos adicionais. Estes campos permitem que os objetos sejam descritos de melhor maneira. A nova estrutura de descrição de objetos segue o modelo exibido na Figura 18. <nome> OBJECT-TYPE SYNTAX <tipo de dado> UnitsParts <Opcional, veja descrição na Tabela 3> MAX-ACCESS <Opcional> STATUS <Ver descrição na Tabela 3> DESCRIPTION "Descrição textual deste objeto gerenciável." AUGMENTS { <nome da tabela> } ::= { <O OID que representa este objeto.> } Figura 18. Definição de objetos gerenciáveis na SMIv2. Fonte: Mauro e Schmidt (2001). Cada trecho dos aprimoramentos demonstrados na Figura 18, é descrito na Tabela 3. Tabela 3. Aprimoramentos na definição de objetos. Aprimoramento UnitsParts MAX-ACCESS STATUS Descrição Uma descrição textual da unidade usada (segundos, milisegundos). É um aprimoramento do ACCESS da SMIv1 (que também pode ser utilizado nesta versão). A diferença, são os novos valores suportados: read-only (somente leitura), read-write (leitura e escrita), read-create (leitura e criação), not-accessible (não acessível) e accessible-for-notify (acessível para notificação). Esta clausula foi extendida para permitir os valores current, obsolete e deprecated. O valor current tem o mesmo significado que mandatory da SMIv1. 23

35 Augments Fonte: Adaptado de Mauro e Schmidt (2001). É utilizado em casos em que é importante adicionar uma ou mais colunas novas a uma tabela. Esta clausula necessita que seja especificado o nome da tabela que terá colunas adicionadas. Na SMIv2 também são introduzidos novas convenções textuais, termos que fazem com que o objeto gerenciável seja declarado de um modo mais abstrato. Os novos termos são definidos na RFC 2579 (RFC 2579, 1999). A Tabela 4 apresenta esses termos. Tabela 4. Novos termos Convenção Textual Descrição DisplayString É uma seqüência de caracteres NVT ASCII, e não pode ultrapassar 255 caracteres. PhysAddress Endereço físico ou da camada de enlace representado por uma cadeia de octetos. MacAddress É o endereço MAC da interface de rede, definido por seis octetos, sendo que o bit menos significante é o primeiro. TruthValue É um tipo booleano que recebe true (verdadeiro) ou false (falso). TestAndIncr Utilizado para evitar problemas quando duas estações de gerenciamento modificam um único valor ao mesmo tempo. AutonomousType É um OID utilizado para definir um novo ramo na árvore da MIB. VariablePointer É um ponteiro para uma instância qualquer de um objeto gerenciável. Este ponteiro contém o OID da instância. RowPointer É um ponteiro para uma tupla de uma tabela. RowStatus Usado para gerenciar a inserção e exclusão de tuplas numa tabela, garantindo a integridade desta tabela. RowStatus pode receber os valores active(1)(ativo), notinservice(2)(fora de serviço), notready(3)(fora de prontidão), createandgo(4)(criar e continuar), createandwait(5)(criar e esperar) e destroy(6)(destruir). TimeStamp Mede o tempo que passou desde que o dispositivo foi ligado até o momento de alguma ocorrência. TimeInterval Mede um período de tempo em centenas de segundos, podendo receber valores de 0 até DateAndTime É um Octect String utilizado para representar a data e o horário. StorageType Define o tipo de memória que o agente está utilizando. Os valores possíveis são other(1), volatile(2), nonvolatile(3), permanent(4) e readonly(5). TDomain Fornece o tipo de serviço de transporte. TAddress Fornece o endereço do tipo de transporte. Seu tamanho pode ser de 1 até 255 octetos. Fonte: Adaptado de Mauro e Schmidt (2001). 24

36 MIB-II MIB-II é um importante grupo de gerenciamento, porque todos os dispositivos que suportam SNMP também suportam este grupo (MAURO; SCHMIDT, 2001, tradução nossa). MIB-II é um ramo da árvore SMI, o qual deriva do nó mgmt(2). A Figura 19 demonstra graficamente o ramo MIB-II. Figura 19. MIB-II. Fonte: Adaptado de Mauro e Schmidt (2001). A Tabela 5 explica brevemente cada item desta sub-árvore. Tabela 5. Explicação dos ramos da MIB-II Ramo OID Descrição System Alguns dos itens mais importantes deste são o uptime do sistema, contato do administrador e o nome do sistema. Interfaces Possui informações sobre o estado de cada interface de rede como, octetos enviados, octetos recebidos, se está ligada ou desligada, etc. At Este ramo só existe para manter a compatibilidade com versões mais antigas de algumas aplicações. Este ramo trata de tradução de endereços. Ip Possui várias informações sobre vários aspectos do protocolo IP, incluindo roteamento. Icmp Possui informações sobre o ICMP, como erros e descarte de pacotes. Tcp Rastreia, entre outros itens, o estado de uma conexão TCP. Udp Com ele é possível construir estatísticas sobre o protocolo UDP, contendo informações como a quantidade de pacotes que entraram e saíram. Egp Possui dados sobre o protocolo EGP (Exterior Gateway Protocol Protocolo de gateway externo). 25

37 transmission Este ramo é raramente utilizado, sendo que é utilizado em MIBs de dispositivos mais específicos. Snmp Possui dados sobre o protocolo SNMP no dispositivo que está sendo gerenciado, como a quantidade de pacotes SNMP enviados e recebidos, traps, etc. Fonte: Adaptado de Mauro e Schmidt (2001) Operações do protocolo SNMP No protocolo SNMP e em suas versões, existem as seguintes operações ou PDU s (Protocol Data Unit Unidade de Dados do Protocolo) (MILLER, 1997, tradução nossa): get, get-next, getbulk, set, get-response, trap, notification, inform, report (MAURO; SCHMIDT, 2001, tradução nossa). Algumas das principais operações são descritas a seguir. Operação get Esta operação é iniciada apenas pelo NMS e ocorre quando este necessita de alguma informação do dispositivo que está sendo gerenciado. Ao fazer a requisição o OID do objeto é passado como um parâmetro. Em casos em que o dispositivo está com sobrecarga de processamento, é possível que o dispositivo descarte o pacote (MAURO; SCHMIDT, 2001, tradução nossa). Esta operação está disponível em todas as versões do SNMP. A resposta do agente é adquirida utilizando a operação get-response (MILLER, 1997, tradução nossa). Operação get-next Esta operação tem o seu funcionamento semelhante ao da operação get. Entretanto, esta operação é utilizada para receber um grupo de informações. A operação get-next navega na árvore utilizando a técnica top-down (MAURO; SCHMIDT, 2001, tradução nossa). Operação get-bulk Esta operação está disponível apenas nas versões 2 e 3 do SNMP (IBIDEM). get-bulk permite que o NMS requisite um grande número de dados de um objeto gerenciável. É uma operação que também se assemelha a operação get. Entretanto, a operação get gera erros ao requisitar um grande número de dados em casos em que o dispositivo esteja muito ocupado. Mas no caso do get-bulk, segundo MILLER (1997, tradução nossa) e MAURO e SCHMIDT (2001, tradução nossa), a operação evita este erro, retornando dados incompletos. 26

38 Operação set A operação set está disponível em todas as versões do SNMP. Esta é utilizada para alterar o valor de um objeto gerenciável ou criar uma nova tupla em uma tabela, dependendo é claro, das permissões (MILLER, 1997, tradução nossa). Traps Trap é a maneira utilizada pelo agente de comunicar o NMS de um evento ocorrido. O agente possui configurado quem é o destinatário destas traps, sendo que geralmente é configurado o IP do NMS (MAURO; SCHMIDT, 2001, tradução nossa). Existem seis tipos genéricos de traps, conforme a Tabela 6. Tabela 6. Tipos de traps Tipo coldstart(0) warmstart(1) linkdown(2) linkup(3) authenticationfailure(4) egpneighborloss(5) enterprisespecific(6) Fonte: Adaptado de Mauro e Schmidt (2001). Descrição Indica que o agente foi reiniciado. Todos os objetos gerenciáveis do tipo Counter e Gauge são zerados. Indica que o agente se reiniciou. Neste caso nenhum objeto gerenciável é alterado. É enviado caso alguma interface do dispositivo foi desconectada ou desligada. É enviado caso alguma interface do dispositivo foi conectada ou ligou. Indica que alguém tentou fazer alguma requisição ao agente e ele negou devido a uma falha de autenticação. Indica a perda de conexão com um vizinho que utiliza o protocolo EGP. Esta trap é configurada ou especificada de acordo com o fabricante do dispositivo. Nestes casos, o NMS necessita decodificar a trap. 2.3 Softwares de monitoramento Os sistemas de monitoramento descritos nesta seção servirão como fonte de requisitos para a construção de um novo sistema. Os softwares escolhidos são: Nagios (NAGIOS, 2008) e Cacti (CACTI, 2008), que são bastante utilizados atualmente Nagios Nagios (NAGIOS, 2008) é um software de monitoramento de hosts e de serviços, construído para informar o administrador de problemas antes que estes sejam detectados pelo usuário final. Foi 27

39 desenvolvido inicialmente para rodar em Linux, mas atualmente ele roda em qualquer sistema baseado em Unix. Para realizar os mais diversos tipos de monitoramento, Nagios faz uso de plugins, que são específicos para cada tipo de monitoramento. O daemon (espécie de serviço) do Nagios ativa estes plugins para que eles coletem as informações necessárias e assim as retorna para ele. O Nagios utiliza plugins para realizar o monitoramento sendo, portanto, um software bastante flexível, já que o administrador pode construir facilmente plugins específicos para um dado tipo de aplicação. Aplicações já conhecidas e bastante utilizadas já possuem plugins construídos (BURGESS, 2005, tradução nossa). A Tabela 7 possui uma lista dos principais plugins. Tabela 7. Lista dos principais plugins do Nagios Plugin check_http check_dns check_dhcp check_disk check_dummy check_imap check_mysql check_mysql_query check_nntp check_procs Descrição Este plugin testa os serviços de HTTP (Hypertext Transfer Protocol Protocolo de transferência de hipertexto) em um host específico. Ele suporta o HTTP assim como o HTTPS (Hypertext Transfer Protocol Secure Protocolo de transferência de hipertexto seguro). Além disto, ele pode consultar redirecionamentos, buscar por expressões regulares, medir o tempo de conexão e verificar se algum certificado está para expirar. Este faz uso do software nslookup (já disponível em grande parte dos Sistemas Operacionais) para verificar se o servidor DNS (Domain Name Server Servidor de Nomes de Domínios) especificado pode traduzir o domínio para um endereço IP. Utilizado para testar a disponibilidade de um dado servidor DHCP (Dynamic Host Configuration Protocol Protocolo de Configuração Dinâmica de Hosts). Utilizado para verificar a quantidade de espaço em disco disponível. Ele pode gerar um alerta caso o valor crítico (configurável) seja alcançado. Ao invés de verificar o estado de um serviço, este plugin retorna valores estipulados pelo administrador. Faz a verificação de uma conexão IMAP (Internet Message Access Protocol Protocolo de Acesso para Mensagens da Internet). Faz um teste de conexão com um banco de dados MySQL. Um plugin para teste de banco de dados MySQL mais elaborado. Este executa uma consulta no banco de dados, e o valor retornado é comparado com o valor aceitável configurado, podendo emitir alertas caso o valor aceitável seja ultrapassado. Faz um teste de conexão com um host que possui NNTP (Network News Transfer Protocol Protocolo de Transferência de Notícias pela Rede). Faz uma checagem de todos os processos em um host e pode gerar avisos e alertas críticos caso alguma métrica esteja fora dos parâmetros configurados. 28

40 check_ping check_smtp Faz o uso de ICMP (Internet Control Message Protocol Protocol de Mensagens de Controle da Internet) para construir estatísticas de conexão com um determinado host. Este plugin simplesmente tentará abrir uma conexão com um servidor SMTP (Simple Mail Transfer Protocol - Protocolo de Simples Transferência de s). check_tcp Faz um teste de uma conexão de TCP (Transfer Control Protocol Protocolo de Controle de Transferência) qualquer com um determinado host. check_udp check_nt Semelhante ao check_tcp, mas testa com o protocolo UDP (User Datagram Protocol Protocolo Livre de Datagrama). Este plugin coleta uma informação específica do serviço NSClient rodando em hosts que estão rodando com Windows NT/2000/XP/2003. A informação que se deseja é um parâmetro a ser passado. Com os plugins necessários instalados, pode-se então iniciar o monitoramento. É possível instalar o Nagios já pré-configurado, de modo que ele já monitore a máquina em que está rodando e o seu gateway. Nagios é configurado utilizando arquivos texto, e os arquivos padrões são exibidos na Tabela 8. Tabela 8. Arquivos padrões de configuração do Nagios Arquivo nagios.cfg checkcommands.cfg misccommands.cfg timeperiods.cfg cgi.cfg contacts.cfg contactgroups.cfg hosts.cfg hostgroups.cfg Descrição Contém configurações básicas como formato da data e hora. Por padrão, este arquivo já vem configurado corretamente, bastando alteração de poucos parâmetros. Neste arquivo existem informações sobre os plugins e como eles serão utilizados. É o arquivo que contém diversos tipos de comandos que podem ser executados, incluindo a configuração do comando de envio de alertas (por celular, , etc). Neste arquivo é especificado quando o Nagios executará as verificações. Contém as permissões dos usuários que acessarão as informações do Nagios. Este arquivo contém as definições de contatos para alertas e avisos. Neste arquivo é possível construir grupos, especificando quais os contatos fazem partes de cada grupo. Este arquivo possui a lista e o modo de como os hosts serão monitorados. Neste arquivo, cada host pode possuir especificado um endereço IP, um apelido, o seu nome, os comandos de checagem, etc. Neste arquivo é possível construir grupos de hosts, facilitando o monitoramento. Com o Nagios configurado, pode-se então verificar os dados coletados. Para isto, basta acessar a página do Nagios, que possui um endereço configurado na instalação, fornecendo o 29

41 usuário e senha, também configurados no processo de instalação. A Figura 20 mostra a tela inicial do Nagios. Figura 20. Tela inicial do Nagios. Fonte: Nagios (2008). 30

42 Para visualizar o estado dos serviços, seleciona-se a opção Service Details (Detalhes dos Serviços). A tela que surgirá apresenta os hosts com seus respectivos serviços e estados. Além disso, é exibida uma descrição detalhada do estado do serviço. A Figura 21 demonstra esta tela. Figura 21. Detalhes dos hosts. Fonte: Nagios (2008). 31

43 Para visualizar o estado dos hosts, é acessada a opção Host Detail (Detalhe do Host). Nesta tela são exibidos todos os hosts com o respectivo estado e informações. A Figura 22 demonstra esta tela. Figura 22. Detalhes dos serviços. Fonte: Nagios (2008). Outro recurso interessante do Nagios é a exibição do Mapa da Rede (Network Map). Ele consiste em exibir a topologia da rede graficamente, mostrando os computadores, roteadores, entre outros hosts. Além disso, ele pode exibir qual Sistema Operacional o host está rodando, caso este esteja especificado no arquivo hosts.cfg. A Figura 23 demonstra este recurso. 32

44 Figura 23. Recurso Mapa da Rede. Fonte: Nagios (2008). O Nagios possui vários recursos poderosos, entretanto, ele não possui nenhuma forma de construção de gráficos. Grande parte dos administradores de rede vem adotando o Cacti como um software adicional para a produção destes gráficos Cacti Cacti (CACTI, 2008) é uma interface completa para o RRDtool (Round Robin Database Tool Ferramenta para Bancos de Dados Round Robin), coletando todas as informações necessárias para construir gráficos e as gravando em uma base no banco de dados MySQL. Ele é totalmente construído com a linguagem PHP. As configurações são todas feitas na interface Web do Cacti e estas são também armazenadas no banco de dados MySQL. 33

45 O RRDtool é um padrão industrial OpenSource (código aberto) de alto desempenho para armazenamento de informações e gráficos que representam dados temporais. Esta ferramenta pode ser utilizada em conjunto com as linguagens PHP, Python, Perl, Ruby e TCL (OETIKER, 2008, tradução nossa). Para iniciar o uso do Cacti, basta acessar a URL na qual ele se encontra. Deve-se fornecer o usuário admin e a senha admin, sendo que a senha deve ser alterada no primeiro acesso. A tela inicial é demonstrada na Figura 24. Figura 24. Tela inicial do Cacti. Fonte: Cacti (2008). Na parte superior da tela, o Cacti apresenta duas opções: console (gerência de configurações) e graphs (gráficos). A tela inicial iniciará com a opção console já selecionada, e nesta opção é possível cadastrar, alterar ou excluir algum dispositivo e/ou gráfico. 34

46 A tela de cadastro e alteração de dispositivos de rede do Cacti é demonstrada na Figura 25. Os campos a serem preenchidos são descritos a seguir, sendo que parte deles já é preenchida com valores padrão. Description (descrição): deve ser preenchido com alguma informação útil sobre o dispositivo. Hostname (nome do host): deve ser preenchido com o nome do dispositivo de rede ou seu endereço IP. Host Template (modelo do host): deve-se selecionar em qual modelo o host se enquadra. Os modelos já incluídos no Cacti são: Cisco Router (Roteador da marca Cisco), Generic SNMP-enabled Host (Host genérico com SNMP ativo), Karlnet Wireless Bridge (Ponte de rede sem-fio da marca Karlnet), Local Linux Machine (Máquina Local com sistema operacional Linux), Netware 4/5 Server (Servidor Netware versão 4 ou 5), ucd/net SNMP Host, Windows 2000/XP Host. Notes (notas): neste campo é possível cadastrar informações sobre o dispositivo já que é um campo bastante grande. Disable Host (inativar host): este campo é selecionado caso deseja-se que o dispositivo não seja verificado pelo Cacti. Downed Device Detection (Detecção de dispositivos desconectados/desligados): o modo de como é feita a detecção do dispositivo na rede. Pode ser selecionado por Ping ou desativar a detecção. Ping Method (método do ping): é o modo de como o ping será executado caso a opção Downed Device Detection esteja marcada como ping. Pode-se executar o ICMP Ping, TCP Ping e UDP Ping. Ping Port (porta para o ping): seleciona-se a porta para a qual o ping irá disparar. Somente em casos de TCP Ping e UDP Ping. Ping timeout (tempo limite para resposta do ping): a métrica deste campo é em milisegundos. Ping Retry Count (número de tentativas de ping): é informada a quantidade máxima de vezes em que é tentada a realização do ping. 35

47 SNMP Version (versão SNMP): neste campo pode-se selecionar entre as versões 1, 2 ou 3 do protocolo SNMP. Dependendo da versão selecionada, os campos seguintes se alteram. Para exemplificar, foi selecionada a versão 2. SNMP Community (Comunidade SNMP): é preenchido o nome da comunidade SNMP que foi configurada no agente do dispositivo. Já que o Cacti apenas coleta informações dos dispositivos, uma comunidade com privilégios de apenas leitura é o suficiente. SNMP port (porta do SNMP): este campo é preenchido o número da porta em que o agente SNMP do dispositivo está escutando. SNMP timeout (tempo limite do SNMP): preenchido com o tempo máximo de espera pela resposta de uma requisição SNMP. O valor é em mili-segundos. Maximum OID s per Get Request (quantidade máxima de OIDs por requisição): é informada a quantidade máxima de OIDs que uma operação SNMP do tipo get pode retornar. 36

48 Figura 25. Cadastro e/ou alteração de um dispositivo de rede no Cacti. Fonte: Cacti (2008). Depois de preenchidos os campos, basta acionar o botão Create (criar) e o dispositivo é cadastrado no banco de dados e então passa a ser monitorado. Para visualizar os gráficos gerados pelo Cacti, basta selecionar a opção graphs no topo da tela. A Figura 26 mostra esta visualização, exibindo apenas um gráfico, entretanto basta utilizar a rolagem para mostrar os outros gráficos. No topo da tela existe um modo de montar o gráfico de acordo com um período especificado. Inicialmente, o Cacti já preenche esses valores que exibem os gráficos com base em dados das últimas 24 horas. No lado esquerdo da tela, é possível selecionar o 37

49 dispositivo que se deseja visualizar os gráficos (neste caso existe apenas um). Abaixo de cada gráfico, o Cacti apresenta estatísticas. Figura 26. Visualizando gráficos no Cacti. Fonte: Cacti (2008). Com o Cacti e o Nagios analisados, parte-se então para a criação de uma tabela com os recursos destes softwares, contendo o que a solução proposta também irá possuir Tabela comparativa de softwares de gerência de redes Na Tabela 9, é exibida uma tabela comparativa, mostrando os recursos mais importantes disponíveis em cada um dos softwares de gerência de redes estudados e os recursos que foram implementados na solução proposta. 38

50 Tabela 9. Tabela comparativa de softwares de gerência de redes Recurso Nagios Cacti Solução Proposta Exibe o estado de Sim Não Sim hosts Exibe o estado de Sim Não Sim serviços Construção de gráficos Não Sim Sim de uso de hosts e serviços Exibe a topologia da Sim Não Sim rede Exibe os hosts Não Não Sim distribuídos geograficamente Suporte ao SNMP Sim Sim Sim Suporte ao CMIP Não Não Não Plataforma Web Web Desktop Alerta por ,... Não possui 39

51 3 PROJETO Nesta sessão estão descritas as modelagens das duas aplicações propostas: Motor e Interface do usuário. A modelagem utilizará a UML (Unified Modeling Language Linguagem de Modelagem Unificada), pois de acordo com Alhir (1998, tradução nossa), é uma linguagem de modelagem visual pronta para usar extensível, simples, escalável, independente de linguagem e de processo de desenvolvimento. O produto final gerado por este trabalho é formado de um motor de coleta e interpretação dos dados de estado dos hosts monitorados e por uma interface gráfica que processa e exibe as informações em um formato adequando para o administrador da rede de computadores. Um exemplo do funcionamento da solução é exibido pela Figura 27. Dependendo da infra-estrutura da rede, é possível rodar a interface no mesmo computador que está rodando o motor. Figura 27. Exemplo de uso. Já o modelo em camadas é exibido Figura 28.

52 Figura 28. Modelo em camadas. Host é qualquer dispositivo de rede gerenciável por SNMP. Ele normalmente executa dentro de um sistema operacional (ex: Microsoft Windows, GNU/Linux, Cisco IOS) ou ainda em firmwares 2 que implementam o protocolo. Motor implementa o software de tratamento de eventos propriamente dito. As principais funções do motor do UNMS são: gravar ocorrências (log), enviar alertas, realizar o polling, além de diversas outras menos perceptíveis pelos demais elementos. Já a Interface oferece interação do motor com o ser humano. Nela estão contempladas todas as rotinas de manipulação do motor, tais como cadastros, eventos, relatórios, gráficos e outros. 3.1 Requisitos Funcionais, Não Funcionais e Regras de Negócio A descrição dos Requisitos Funcionais, Não Funcionais e as Regras de Negócio são primordiais para a construção de qualquer software, pois descrevem o que e como será criado. Motor e interface são descritos separadamente. 2 Software embutido em aparelhos eletrônicos, tais como modems, roteadores e switches, entre outros. 41

53 3.1.1 Motor O motor será a aplicação responsável por coletar as informações dos hosts e serviços da rede e armazená-las. Os requisitos funcionais identificados estão descritos a seguir: RF01: O motor deve coletar as informações disponíveis de um host através do protocolo SNMP. RF02: O motor deve gravar as informações coletadas num banco de dados. RF03: O motor deve realizar monitoramento por ICMP Echo/Reply em todos os hosts cadastrados. RF04: O motor deve possuir um mecanismo de auto-detecção de hosts na LAN. Os requisitos não funcionais identificados estão a seguir. A categorização dos itens está entre parênteses. RNF01: O motor deve ser construído utilizando a linguagem de programação C#. (implementação) RNF02: O motor deve utilizar o SGDB PostgreSQL 8.2. (implementação) RNF03: O motor deverá ser construído utilizando a plataforma Mono. (implementação) RNF04: O motor deve ser compatível com as versões 1 e 2 do protocolo SNMP. (conformidade) RNF05: O motor não deverá apresentar interface gráfica. (usabilidade) RNF06: O motor será concebido como software livre, licenciado nos termos da licença GPLv2 (General Public License 2- Licença Pública Geral) (GNU, 2008). As regras de negócio identificadas estão a seguir: RN01: Caso não haja configurações avançadas de um dado host, o motor irá monitorá-lo com o uso ICMP-ECHO / ICMP-REPLY. 42

54 RN02: O motor não trata da configuração de traps nos dispositivos de rede Interface com o usuário A interface com o usuário será a aplicação responsável por exibir os dados coletados na tela bem como permitir a configuração do sistema. Os requisitos funcionais identificados são os seguintes: RF01: A interface deve permitir o cadastro de hosts. RF02: A interface deve permitir o cadastro de serviços que serão monitorados. RF03: A interface deve exibir a localização dos hosts cadastrados utilizando o mecanismo do Google Earth. RF04: A interface deve exibir uma tela de monitoramento que liste todos os hosts e seu estado. RF05: A interface deve exibir uma tela de monitoramento que liste todos os serviços por host com o respectivo estado e descrição. RF06: A interface deve permitir o cadastro de usuários. RF07: A interface deve exibir a topologia da rede. RF08: A interface deve exibir registros de eventos (logs). RF09: A interface deve exibir graficamente, o histórico da taxa de uso dos itens selecionados de cada host. RF10: O sistema deve permitir que o usuário cadastre grupos de hosts. RF11: A interface deve permitir ao usuário iniciar o recurso de auto-detecção da rede o qual se encontra no motor. RF12: A interface deve permitir a visualização do histórico de eventos de um host. Os requisitos não funcionais identificados para a construção do software estão listados abaixo. As categorias de cada requisito estão entre parênteses. 43

55 RNF01: A interface deve ser desenvolvida utilizando a linguagem de programação Visual C#. (implementação) RNF02: O Sistema de Gerenciamento de Banco de Dados que será utilizado é o PostgreSQL. (implementação) RNF03: A interface será concebida como software livre, licenciado nos termos da licença GPLv2 (General Public License 2- Licença Pública Geral) (GNU, 2008). As regras de negócio identificadas são as seguintes: RN01: Cada serviço cadastrado deve estar com relacionado com um host previamente cadastrado. RN02: Cada item que está sendo grafado deve estar relacionado com um host previamente cadastrado. 3.2 Diagramas de Caso de Uso Os diagramas de caso de uso são importantes no projeto de qualquer sistema, pois de acordo com Alhir (1998, tradução nossa), eles contêm os atores que representam os usuários do sistema, incluindo os usuários humanos e outros sistemas, além de representar as funcionalidades ou serviços providos pelo sistema para o usuário Motor O diagrama de caso de uso construído para o Motor da aplicação é exibido na Figura 29. Figura 29. Diagrama de casos de uso do Motor. 44

56 3.2.2 Interface com o usuário Já os diagramas de caso de uso para a interface são exibidos na Figura 30. Figura 30. Diagrama de casos de uso da interface. A descrição dos casos de uso da interface é feita a seguir UC01 Efetuar login Este caso de é responsável por efetuar o login no sistema. Relações RF06: A interface deve permitir o cadastro de usuários. Condições Pré-condição: Ter um usuário já cadastrado. Pós-condição: Um usuário está autenticado no sistema. Cenários Faz o login {Principal} 45

57 1. Ao abrir o sistema, o usuário informa o seu nome de usuário e a senha (Figura 31). 2. Sistema verifica se o usuário e senha estão corretos. 3. O sistema fecha a tela de login e abre a tela principal. Usuário e/ou senha inválidos {Exceção} Se no passo 2 o usuário e/ou senha estiverem errados ou usuário não existe 2.1. O sistema exibe uma tela com a mensagem Usuário e/ou senha inválidos Figura 31. Interface de login UC02 Cadastra um host Este caso de uso trata do cadastramento de hosts no sistema. Relações RF01: A interface deve permitir o cadastro de hosts. RF10: O sistema deve permitir que o usuário cadastre grupos de hosts. Condições Pré-condição: Um usuário autenticado no sistema. Pré-condição: Um tipo de host deve estar cadastrado. Pré-condição: Um grupo de host deve estar cadastrado. Pós-condição: Um host está cadastrado. Pós-condição: O host cadastrado, se ativo, começa a ser monitorado. 46

58 Cenários Cadastra o host {Principal} 1. O usuário abre a interface de cadastro de hosts (Figura 32). 2. O usuário informa os dados do novo host. 3. O usuário clica em Salvar, ou no botão com um ícone de disquete. Altera um host {Alternativo} Se no passo 2 o usuário quiser alterar um host: 2.1. O usuário clica no ícone de lupa na parte superior e seleciona o host a ser alterado O usuário altera os dados do host O usuário clica em salvar. Exlcui um host {Alternativo} Se no passo 2 o usuário quiser excluir um host: 2.1. O usuário clica no ícone de lupa na parte superior e seleciona o host a ser alterado O usuário clica em Excluir ou no botão com um desenho de X Uma janela é exibida pedindo a confirmação da exclusão. 47

59 Figura 32. Interface principal do cadastro de hosts. 48

60 Altera a Forma de Monitoramento {Alternativo} Se no passo 2 o usuário quiser alterar ou configurar um modo de monitoramento diferente: 2.1. O usuário clica no botão Monitoramento O usuário altera os dados na interface que irá surgir conforme necessário (Figura 33) O usuário clica em OK. Figura 33. Interface de configuração de monitoramento UC03 Cadastra um serviço Este caso de uso trata do cadastro de serviços que podem ser monitorados. Relações RF02: A interface deve permitir o cadastro de serviços que serão monitorados. Condições Pré-condição: Um host deve estar cadastrado. Pós-condição: Um serviço está cadastrado. Cenários 49

61 Cadastra o Serviço {Principal} 1. O usuário abre a interface de cadastro de hosts e clica em Serviços (Figura 34). 2. O usuário preenche os dados sobre o serviço. 3. O usuário clica em Salvar. Altera um serviço {Alternativo} Se no passo 2 o usuário quiser alterar um serviço: 2.1. O usuário seleciona o serviço na lista O usuário altera os dados do serviço conforme necessário (Figura 34) O usuário clica em Salvar Caso as operações na janela foram finalizadas, o usuário clica em OK. Exclui um serviço {Alternativo} Se no passo 2 o usuário quiser excluir um serviço: 2.1. O usuário seleciona o serviço na lista O usuário clica em Remover Caso as operações na janela foram finalizadas, o usuário clica em OK. 50

62 Figura 34. Interface de cadastro de serviços UC04 Cadastra um usuário Este caso de uso trata do cadastro de um usuário que poderá utilizar o sistema de monitoramento. Relações RF06: A interface deve permitir o cadastro de usuários. Condições Pré-condição: Um usuário autenticado no sistema. Pós-condição: Um novo usuário foi cadastrado, alterado ou excluído no sistema. Cenários Cadastra o usuário {Principal} 1. O usuário abre a interface de cadastro de usuários (Figura 35). 2. O usuário informa os dados do novo usuário. 3. O usuário clica em Salvar. 51

63 Altera um usuário {Alternativo} Se no passo 2 o usuário quiser alterar os dados de um usuário: 2.1. O usuário faz uma busca clicando no botão com desenho de uma lupa O usuário seleciona o usuário a ser alterado O usuário altera os dados do usuário selecionado O usuário clica em Salvar. Exclui um usuário {Alternativo} Se no passo 2 o usuário quiser alterar os dados de um usuário: 2.1 O usuário faz uma busca clicando no botão com desenho de uma lupa O usuário seleciona o usuário a ser excluído O usuário clica em Excluir Uma janela é exibida pedindo a confirmação da exclusão. Figura 35. Interface de cadastro de usuários UC05 Visualiza o estado dos hosts Este caso de uso corresponde à visualização dos estados dos hosts cadastrados. 52

64 Relações RF04: A interface deve exibir uma tela de monitoramento que liste todos os hosts e Condições seu estado atual. Pré-condição: O usuário deve estar autenticado no sistema. Pré-condição: Um host deve estar cadastrado no sistema. Cenários Visualização de Estados de Hosts{Principal} 1. O usuário abre a interface de visualização de estados de hosts (Figura 36). 2. O usuário pode selecionar o Grupo ou tipo de hosts para filtrar quais hosts devem ser exibidos na lista. Figura 36. Interface de visualização de estados de hosts UC06 Visualiza os estados dos serviços dos hosts Este caso de uso corresponde à visualização dos estados dos serviços de hosts cadastrados. 53

65 Relações RF05: A interface deve exibir uma tela de monitoramento que liste todos os serviços Condições por host com o respectivo estado e descrição. Pré-condição: O usuário deve estar autenticado no sistema. Pré-condição: Um host deve estar cadastrado no sistema. Pré-condição: Um serviço deve estar cadastrado. Cenários Visualização de Estados de Serviços dos Hosts {Principal} 1. O usuário abre a interface de visualização de estados de hosts (Figura 37). 2. O usuário pode selecionar o Grupo de hosts para filtrar quais serviços dos hosts devem ser exibidos na lista. Figura 37. Interface de visualização de estados dos serviços dos hosts. 54

66 UC07 Visualiza a topologia lógica da rede Este caso de uso corresponde à visualização da topologia lógica da rede. Relações RF07: A interface deve exibir a topologia lógica da rede. Condições Pré-condição: O usuário deve estar autenticado no sistema. Pré-condição: Um host deve estar cadastrado no sistema. Cenários Visualização da Topologia Lógica da Rede {Principal} 1. O usuário abre a interface de visualização da topologia lógica da rede (Figura 38). Figura 38. Interface de visualização da topologia da rede. 55

67 UC08 - Visualiza os hosts geograficamente no Google Earth Earth. Este caso de uso corresponde à visualização dos hosts utilizando o mecanismo do Google Relações RF03: A interface deve exibir a localização dos hosts cadastrados utilizando o Condições mecanismo do Google Earth. Pré-condição: O usuário deve estar autenticado no sistema. Pré-condição: Um host deve estar cadastrado no sistema. Cenários Visualização geográfica de hosts {Principal} 1. O usuário abre a interface de visualização do posicionamento geográfico dos hosts (Figura 39). 2. O software Google Earth, se instalado, irá exibir os hosts cadastrados. Figura 39. Interface para a chamada da visualização de hosts no Google Earth. 56

68 UC10 Visualiza gráficos de uso Este caso de uso corresponde a visualização de gráficos de utilização e/ou carga de recursos dos hosts. Relações RF09: A interface deve exibir graficamente, o histórico da taxa de uso dos itens Condições selecionados de cada host. Pré-condição: O usuário deve estar autenticado no sistema. Pré-condição: Um host deve estar cadastrado no sistema. Cenários Visualização de gráficos {Principal} 1. O usuário abre a tela de exibição de gráficos (Figura 40). 2. O usuário seleciona qual host, monitor e o período de visualização. 3. O usuário clica no botão Visualizar. Figura 40. Visualização de gráficos. 57

69 UC11 Visualiza registros de eventos Este caso de uso corresponde a visualização de registros (logs). Relações RF08: A interface deve exibir registros de eventos (logs). Condições Pré-condição: O usuário deve estar autenticado no sistema. Cenários Visualização de registro de eventos {Principal} 1. O usuário abre a tela de exibição de eventos (Figura 41). Figura 41. Visualização de eventos. 58

70 UC12 Cadastro automático de hosts Este caso de uso corresponde a auto-detecção de hosts na rede. Relações RF11: A interface deve permitir ao usuário iniciar o recurso de auto-detecção da rede. Condições Pré-condição: O usuário deve estar autenticado no sistema. Pós-condição: Um ou mais hosts foram adicionados no sistema. Cenários Detecção de hosts {Principal} 1. O usuário abre a tela de detecção de hosts (Figura 42). 2. O usuário seleciona o método de detecção. 3. O usuário clica em Iniciar. 4. Uma barra de progresso indica o andamento da detecção. 5. Ao final do processo, o usuário selecione os hosts a serem adicionados e clica em salvar. 59

71 Figura 42. Detectando hosts. 3.3 Diagramas de Classe De acordo com Booch, Rumbaugh e Jacobson (2005, tradução nossa), Os diagramas de classes são os diagramas encontrados com maior freqüência na modelagem de sistemas orientados a objetos. Um diagrama de classes mostra um conjunto de classes, interfaces e colaborações e seus relacionamentos. As classes, de acordo com Alhir (1998, tradução nossa), são entidades que possuem atributos, operações e associações. As associações representam o relacionamento entre duas ou mais classes que possuem em comum, algumas características. Para o correto entendimento do funcionamento e construção dos módulos, os diagramas de classes são exibidos nas sessões seguintes. 60

72 3.3.1 Motor A Figura 43 exibe o diagrama de classes do motor. Figura 43. Diagrama de classes do motor. A descrição de cada classe é exibida a seguir: Host: Esta classe corresponde a um host; HostService: Esta classe corresponde a um serviço que se encontra num host; ServiceType: Esta classe representa um tipo de serviço; DateTimePeriod: É uma classe simples que possui dois atributos que definem um intervalo de tempo. Ela está ligada à classe Host, pois define quais intervalos de tempo este não será monitorado; HostData: Classe que guarda qualquer tipo de dado relacionado à um host. Normalmente será preenchida por dados da MIB do host; Trap: Classe representa uma trap recebida pelo motor. Esta ligada a um Host pois este pode possuir várias traps; Group: Representa um grupo de hosts; User: corresponde à um usuário do sistema; 61

73 StateAlert: classe que contém dados sobre em qual situação pode se emitir um alerta devido uma trap; MonitoringType: é um enumerator que identifica qual é o tipo de monitoramento de um host; e Engine: classe responsável por todas as operações do motor Interface O diagrama de classes da interface é semelhante ao diagrama do motor, sendo que apenas a classe Engine não está presente. 62

74 3.4 Diagrama Entidade-Relacional O diagrama entidade-relacional, apesar de não ser padrão UML, ele é importante, pois define a estrutura do banco de dados. O diagrama resultante para este projeto é exibido pela Figura 44. Figura 44. Diagrama Entidade-Relacional. 63

75 4 DESENVOLVIMENTO A programação do UNMS empregou as seguintes ferramentas: Microsoft Visual Studio 2005 Banco de dados PostgreSQL 8.3 pgadmin III MonoDevelop 1.0 Ao utilizar o Visual Studio 2005 (VISUALSTUDIO, 2008) com a linguagem de programação C#, foi utilizada uma biblioteca de conexão com o banco de dados que visa facilitar o uso do npgsql (POSTGRESQL, 2008). A utilização de ODBC foi descartada pelo fato de oferecer desempenho inferior se comparado com uma conexão direta com o banco de dados. Foi utilizado o padrão DAO (Data Access Object) de desenvolvimento. Este padrão permite que ocorra a separação da lógica de negócio da parte que faz o tratamento do acesso aos dados persistidos (BUSHMANN; HENNEY; SCHMIDT, 2007, tradução nossa). Com base neste padrão, uma maneira um pouco diferente de desenvolvimento foi adotada. Para garantir uma boa modularidade, optou-se por desenvolver estes itens da seguinte forma: 1. Um Project que possui as classes entidade (beans) e persistência; 2. Um Project que possui as classes de visão. A Figura 45 demonstra no Visual Studio como foi abordado o padrão de desenvolvimento DAO. O Project Hosts apresenta, entre outros, a classe Bean (Host) e a classe DAO (HostDAO). 64

76 Figura 45. Formato de desenvolvimento. Portanto, para cada entidade do sistema, haverá dois Projects em uma Solution do Visual Studio. Isto garante que implementações e correções futuras sejam facilitadas. Além disso, este formato permite que tanto o motor quanto a interface utilizem os mesmos Projects de beans e DAO. Além disso, o HostDAO foi utilizado para acesso a bases SNMP no host. Antes de aprofundar o desenvolvimento dos recursos mais importantes do motor e da interface, é necessário entender o processo da criação da Classe de manipulação de dados do protocolo SNMP. 4.1 Classe de manipulação de dados do protocolo SNMP Para desenvolver um software que possa se comunicar através de SNMP com os dispositivos de rede, foi necessário pesquisar bibliotecas que fornecessem os recursos necessários para isto, já que o.net Framework não possui tal recurso. Entretanto, com o objetivo de adquirir um conhecimento mais aprofundado sobre o assunto, foi decidido que uma biblioteca própria fosse construída, resultando em mais assuntos a serem revisados. O estudo bibliotecas já existentes ajudaram a compreender melhor o protocolo. A lista de bibliotecas estudadas é exibida pela Tabela

77 Tabela 10. Bibliotecas SNMP pesquisadas Biblioteca An SNMP Library for.net Framework (CROWE, 2005) SNMP Library (CODEPROJECT, 2008) Descrição Esta biblioteca é bastante completa, mas complexa. Possui métodos de tradução de OIDs para descrição e vice-versa. Possui métodos simples de utilização. Por outro lado, necessita de instância de alguns objetos que a torna confusa. Além disso, ela é carente em alguns recursos que são necessários para este projeto. Para construir uma biblioteca de acessos SNMP, inicialmente foram necessários estudos sobre o funcionamento de mais baixo nível do protocolo. O entendimento da estrutura do datagrama SNMP, exibida pela Figura 46, foi primordial para a construção da biblioteca. Figura 46. Datagrama SNMP. Fonte: Adaptado de Bruey (2008). Conforme o estudo e o desenvolvimento ocorriam através de observações no diagrama, o padrão TLV (Type, Length, Value Tipo, Tamanho e Valor) e a codificação BER (Basic Encoding Rules Regras de Básicas de Codificação) foram descobertos: Padrão TLV Um datagrama SNMP tem sua estrutura básica construída utilizando o padrão TLV (Type, Length, Value Tipo, Tamanho e Valor) (JAMHOUR, 2008). O pacote é extremamente organizado através deste padrão, de modo que cada parte e sub-parte são separadas, especificadas e dimensionadas de acordo com o valor e tipo. A Figura 47 demonstra o campo community de um datagrama SNMP. Na Figura 46 (Datagrama SNMP), ele seria inserido inteiramente no local correspondente, seguindo este padrão. Figura 47. Espaço community do SNMP. 66

78 O campo tipo é um valor numérico que corresponde a um tipo de dado disponível no ASN.1 (IBIDEM). A lista de tipos de dados e seu valor numérico são demonstrados na Tabela 11. Tabela 11. Tipos de dado do protocolo SNMP utilizado no padrão TLV. Identificador Valor Boolean 0x01 Integer 0x02 UInt32 0x47 BitString 0x03 OctetString 0x04 ObjectIdentifier 0x06 Null 0x05 Sequence 0x30 Counter32 0x41 Counter64 0x46 Gauge 0x42 TimeTicks 0x43 IPAddress 0x40 Opaque 0x44 NetAddress 0x45 Fonte: Adaptado de CodeProject (2008). O campo tamanho é um valor numérico de significa a quantidade de bytes que o campo valor possui Codificação/Decodificação BER A codificação/decodificação BER (Basic Encoding Rules Regras Básicas de Codificação) é o sistema adotado para codificação dos dados para transferência do datagrama SNMP pela rede (JAMHOUR, 2008). O BER aplicado ao SNMP é utilizado em casos em que certamente algum valor ocupará mais de um byte. Seu funcionamento consiste em marcar com 1 o bit mais à esquerda de um byte para indicar que existe mais bytes a serem lidos para a decodificação da mensagem. Caso o bit mais à esquerda do byte seja 0, quer dizer que este é o último byte a ser lido. Para exemplificar, um OID deverá ser convertido em um vetor de bytes, para que ele seja incorporado ao pacote SNMP. O OID utilizado é O valor 1756 é o ponto em que será necessário aplicar a codificação. 67

79 Inicialmente, converte-se 1756 para binário: (para facilitar a leitura, em hexadecimal, o seu valor é 0x6DC). A seguir, é necessário separar o valor de sete em sete bits, conforme a Figura Figura 48. Valor binário de sete em sete bits. A seguir, os valores separados devem ser completados para todos terem oito bits. Ao serem completados, são marcados os bits mais a esquerda conforme a regra de codificação BER. O resultado é exibido na Figura 49. Os valores grifados são os bits de indicação Figura 49. Resultado da codificação BER A biblioteca de classes resultante As pesquisas realizadas bem como a compreensão dos novos conceitos resultaram na biblioteca de acesso a dados do protocolo SNMP, batizada de libsnmp. Esta possui enumerators, classes com métodos de codificação/decodificação BER e classe com métodos para manipulação de dados do SNMP. A classe de codificação BER possui apenas dois métodos, exibidos pela Figura 50. Ambos os métodos trabalham com um vetor de bytes (byte[]) e um valor inteiro de 32 bits sem sinal (UInt32). Public static byte[] Encode(UInt32 source); Public static UInt32 Decode(byte[] source); Figura 50. Métodos da classe de codificação/decodificação BER A principal classe desta biblioteca é a Snmp. Esta possui métodos estáticos, responsáveis por consultar os objetos gerenciáveis de dispositivos de rede e retornar os resultados. Além disto, existem também outros métodos que auxiliam no desenvolvimento. A Figura 51 exibe a lista de métodos públicos existentes. 68

80 Public static SnmpData Request(SnmpVersion ver, string community, SnmpOp op, string oid, string host); public static SnmpData RequestTextual(SnmpVersion ver, string community, SnmpOp op, string textualdesc, string host); public static SnmpDataList RequestWalk(SnmpVersion ver, string community, string startoid, string host); public static string TranslateToDescr(string oid); public static string TranslateToOid(string textualdescr); public static string GetDeviceDescription(DeviceType dt, int deviceindex, string host, string community); Figura 51. Métodos da classe de Snmp. O método Request é o método responsável por realizar uma operação sobre algum valor correspondente ao OID informado. O tipo da operação é passada por parâmetro através de um enumerator. A versão do protocolo também é selecionada por um enumerator. O método RequestTextual é semelhante ao Request, mas a operação é realizada passando a descrição textual do OID. Dentro do método ocorre uma operação de tradução da descrição em um OID, já que em um pacote SNMP não suporta operações utilizando-se a descrição textual. O RequestWalk utiliza-se de uma operação do SNMP, o get-next. Através disto, é possível navegar na árvore de OIDs e resgatar vários dados através de um único método. A operação getnext não possui critério de parada, ou seja, é necessário um controle no próprio método de requisição. Para isto, utilizou-se um laço infinito que realizaria um break caso o próximo OID não comece com OID fornecido como parâmetro. Isto foi possível através do método String.StartsWith(). Os métodos TranslateToDescr e TranslateToOid são os responsáveis pela conversão de um OID para sua descrição e vice-versa. Esta operação é possível, pois existe uma tabela em memória que possui os principais OIDs e suas respectivas descrições. O método GetDeviceDescription é utilizado principalmente para consultar qual o nome de um dispositivo de rede ou disco, baseado em uma análise simples do OID passado por parâmetro. O conceito de TLV não exige uma classe ou métodos para seu tratamento. Isto ocorre pelo fato de que este conceito seja utilizado diretamente na construção e decodificação do pacote SNMP. Portanto, o TLV está embutido em todos os métodos do tipo Request presentes na libsnmp. 69

81 Cada método do Request retorna um tipo SnmpData ou um SnmpDataList. O SnmpDataList é uma lista de SnmpData que contém métodos de exibição de dados para o console, métodos de adição diferenciados e de consulta. A definição da classe SnmpData é exibida pela Figura 52. public SnmpDataType Type; public object Value; public string Oid; public string Description; public string DescriptionWithIndex; public override string ToString(); Figura 52. Métodos e atributos da classe SnmpData. Um SnmpDataType é selecionado em um enumerator conforme o pacote de resposta de algum Request. O atributo Value possui o valor recebido pela resposta e é do tipo object, pois este tipo pode guardar qualquer tipo de informação, podendo ser um tipo básico como int ou uma String por exemplo. Description e DecriptionWithIndex retornam uma descrição do dado, de acordo com a tabela em memória previamente citada. O método ToString() foi construído para que o objeto SnmpData possa ser exibido de maneira mais clara. Nesta mesma biblioteca, existe uma classe privada chamada mib2. Esta contém um objeto DataTable no qual é possível carregar dados em memória e realizar SELECT, como se fosse num banco de dados que suporte SQL. Neste objeto, existem vários registros que representam os OIDs e suas descrições textuais. O objetivo desta classe, portanto, é de possibilitar traduções de OIDs para sua descrição e vice-versa. 4.2 O motor do UNMS O motor do UNMS é o responsável pela realização de todas as verificações de hosts e serviços cadastrados. Sua estrutura é composta por dois mecanismos: Mecanismo de escalonamento; e Mecanismo de verificação de hosts e serviços. O mecanismo de escalonamento se assemelha ao escalonador de processos de um Sistema Operacional. No caso do UNMS, o objetivo é verificar quais hosts serão checados na próxima iteração de verificações do motor. A cada chamada desse mecanismo, o tempo que falta para a 70

82 próxima checagem é recalculado levando-se em conta o tempo atual e o tempo da última verificação. Os hosts selecionados são adicionados na lista de hosts a serem checados. O mecanismo de verificação de hosts e serviços é acionado pelo método Start(). Sua primeira ação é escalonar os hosts, verificando quais devem ser checados. No motor, segue-se a seguinte ordem de verificação: 1. Teste de host através do ICMP Echo/Reply (Ping); 2. Checagem de serviços; e 3. Verificação dos OIDs através de SNMP. A cada verificação realizada, os dados de cada item verificado são atualizados para visualização através da interface. O motor foi todo construído e testado no Visual Studio da Microsoft. Entretanto, devido este ser construído como aplicação console, sua compatibilidade com o Mono não foi comprometida Checando através de ICMP O protocolo ICMP é outro caso em que o.net Framework não fornece os métodos necessários. Para realizar operações com ICMP, foi utilizada a biblioteca Advanced Ping Program (JAVA2S, 2008). Esta biblioteca foi de grande utilidade, mas por outro lado foram necessárias implementações e adaptações. O objetivo foi de padronizar e facilitar o uso da biblioteca. Para as alterações, o sniffer WireShark (WIRESHARK, 2008) foi bastante utilizado. O resultado final foi uma classe que possui cinco métodos públicos, exibidos pela Figura 53. public static List<IPAddress> BroacastICMP(string broadcastip); public static int Ping(string ipaddress); public static int PingHostName(string hostname); public static List<IPAddress> TraceRoute(string targeipaddress, int hops); public static List<IPAddress> TraceRouteHostName(string targehostname, int hops); Figura 53. Métodos da classe ICMP. O método BroadcastICMP retorna a lista de IPs que responderam ao ICMP Echo disparado para um endereço de broadcast. Ping retorna um inteiro com o tempo de resposta de um host em 71

83 milissegundos. O PingHostName funciona como o método Ping, mas passando um nome de host. Os métodos TraceRoute e TraceRouteHostName retornam uma lista de IPs que fazem parte da rota até o host informado, sendo que o número máximo de passos é informado como parâmetro. A verificação por ICMP ocorre em todos os hosts escalonados para uma determinada iteração, independente do seu tipo de monitoramento. Neste caso, os hosts são atualizados quanto ao resultado obtido pelo ICMP Echo/Reply e em casos de problema, um registro é criado no log Checando serviços Este recurso do motor é o responsável pela verificação de serviços de um determinado host de uma porta TCP. Para sua checagem, foi elaborado um método que recebe o nome do host e a porta, retornando um valor em milissegundos correspondente ao tempo de resposta do serviço. Inicialmente, é armazenado o horário de início da verificação. Então, um Socket TCP é instanciado com o objetivo de se conectar a porta do host informado. Após a conexão, já ocorre a desconexão e o cálculo do tempo que a operação levou é retornado. Caso ocorra um erro de conexão é retornado o valor O tempo limite para verificação de cada porta é de 1 segundo (ou 1000 milissegundos). O sistema de registro de eventos para os serviços é igual ao processo de verificação por ICMP. O tempo de resposta da última medição é armazenado e em casos de erro um registro no log é adicionado Checando os OIDs Cada OID cadastrado para um host é verificado a cada iteração para qual o host foi escalonado. Para a checagem, foi utilizado o método Snmp.Request, disponível na biblioteca construída durante o TCC-2. Diferente dos outros dois métodos de verificação, o sistema de verificação SNMP armazena os dados adicionando-os na tabela e não alterando os já existentes. Isto é necessário para a criação dos gráficos. Por outro lado, segue a mesma regra em que caso algum erro seja encontrado, um registro é criado na tabela de log. 72

84 4.3 Desenvolvimento da Interface A interface do UNMS é a responsável pela exibição dos dados registrados pelo motor de uma maneira amigável ao usuário. Em sua construção, foi proposto um sistema multi-plataforma e o Gtk# seria o sistema de interface gráfica a ser utilizado. Com o MonoDevelop (MONODEVELOP, 2008), é possível construir aplicações multiplataforma para a plataforma.net com interface gráfica Gtk# e outras. Esta ferramenta é relativamente nova, e a ausência de recursos como break-points, watches entre outros, se tornou um fator decisivo. O resultado foi o abandono desta ferramenta durante o desenvolvimento da interface e o Visual Studio da Microsoft foi utilizado. Espera-se, que com o avanço do projeto Mono, ferramentas gratuitas como o MonoDevelop se tornem mais completas. Como o UNMS foi construído de forma modular, seria possível reutilizar as DLLs construídas no desenvolvimento de uma interface multi-plataforma. Todas as telas de cadastro do sistema foram construídas utilizando a herança de formulários. Este recurso está disponível no Windows Forms e busca o reaproveitamento do código. Isto ocorre ao construir uma interface básica e seus métodos e então criar um novo Form o qual irá herdar desta interface. O resultado no sistema são interfaces padronizadas e com uma lista pronta de todos os métodos a serem implementados. Os componentes do Form pai são exibidos na interface de desenvolvimento em um modo de somente leitura. 73

85 4.3.1 Construção de gráficos na plataforma.net Para a construção de gráficos em.net, foi necessário a utilização de uma biblioteca não pertencente ao.net Framework. Para este TCC, foi utilizado o.net Charting (DOTNETCHARTING, 2008), um componente pago. Apesar disso, ele pode ser utilizado gratuitamente. Sem o licenciamento, ele exibe um logotipo no gráfico, conforme a Figura 54. Figura 54. Exemplo de uso para o.net Charting e seu logotipo..net Charting é integrado com o Microsoft Visual Studio através de sua adição na lista de componentes, conforme a Figura 55. Figura 55..Net Charting no Visual Studio. O componente é utilizado ao arrastá-lo ao formulário Windows. Seu posicionamento e dimensões são ajustados, e então se codifica o gráfico. É possível também, utilizá-lo na construção 74

86 de páginas em ASP.NET. No Windows, as escalas são ajustadas conforme as dimensões do formulário sem necessidade da criação de código adicional. A seguir, na Figura 56, é exibido um exemplo de gráfico de barras construído com o.net Charting. Figura 56..Net Charting e gráfico de barras. No UNMS, os gráficos são de linha. A Figura 57 apresenta um trecho de codificação comentado, exemplificando o uso do.net Charting. chart1.series = new Series(); //Inicia nova série chart1.type = ChartType.Scatter; //O gráfico é de linha chart1.seriescollection.clear(); //A coleção de Series é apagada chart1.title = String.Empty; //O título do gráfico é branco chart1.titlebox = new Box(); //Re-inicia a caixa do título do gráfico chart1.xaxis.scale = dotnetcharting.winforms.scale.time; //A escala do eixo X é por tempo chart1.xaxis.timeinterval = TimeInterval.Minute; //A escala é em minutos chart1.xaxis.formatstring = "HH:mm"; //O formato de exibição de dados do eixo X é Horas:Minutos chart1.xaxis.name = "Tempo"; //O título para o eixo X é tempo chart1.yaxis.name = "% Carga"; //O título do eixo Y é % Carga //Inserindo valores no gráfico Element el; //Declaro um elemento no gráfico //Laço de repetição que possui um objetos que contêm uma data e um Double foreach (KeyValuePair<DateTime, Double> kvp in ls) { el = new Element(); //Instância de um novo elemento el.yvalue = kvp.value; el.xdatetime = kvp.key; chart1.series.addelements(el); //Insere o novo elemento no gráfico } chart1.seriescollection.add(); //Insere a coleção de dados no gráfico chart1.seriescollection[0].defaultelement.color = Color.Green; //A linha do gráfico é verde //Não é desejado que cada valor possua um marcador individual chart1.seriescollection[0].defaultelement.marker.visible = false; Figura 57. Exemplo de uso do.net Charting. 75