universidade do vale do itajaÍ centro de ciÊncias ...siaibib01.univali.br/pdf/artur carlos...
TRANSCRIPT
UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR
CURSO DE CIÊNCIA DA COMPUTAÇÃO
SISTEMA NETUNO: UM PRODUTO CLIENTE/SERVIDOR PARA O MONITORAMENTO REMOTO DE HOSTS NO FORMATO DE SOFTWARE
COMO SERVIÇO
Área de Redes de Computadores
por
Artur Carlos Hertel Sonnenhohl
Fabricio Bortoluzzi, M.Sc. Orientador
Itajaí (SC), junho de 2010
UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR
CURSO DE CIÊNCIA DA COMPUTAÇÃO
SISTEMA NETUNO: UM PRODUTO CLIENTE/SERVIDOR PARA O MONITORAMENTO REMOTO DE HOSTS NO FORMATO DE SOFTWARE
COMO SERVIÇO
Área de Redes de Computadores
por
Artur Carlos Hertel Sonnenhohl 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: Fabricio Bortoluzzi, M.Sc.
Itajaí (SC), junho de 2010
ii
SUMÁRIO
LISTA DE ABREVIATURAS.................................................................. iv
LISTA DE FIGURAS ................................................................................. v
LISTA DE TABELAS .............................................................................. vii
RESUMO .................................................................................................. viii
ABSTRACT ................................................................................................ ix
1 INTRODUÇÃO........................................................................................ 1
1.1 PROBLEMATIZAÇÃO ..................................................................................... 2
1.1.1 Formulação do Problema ................................................................................. 2
1.1.2 Solução Proposta ............................................................................................... 4
1.2 OBJETIVOS ........................................................................................................ 5
1.2.1 Objetivo Geral ................................................................................................... 5
1.2.2 Objetivos Específicos ........................................................................................ 5
1.3 METODOLOGIA ................................................................................................ 6
1.4 ESTRUTURA DO TRABALHO ....................................................................... 7
2 FUNDAMENTAÇÃO TEÓRICA .......................................................... 8
2.1 GERENCIAMENTO DE REDES ..................................................................... 8
2.1.1 SNMP ............................................................................................................... 11
2.1.2 WMI ................................................................................................................... 12
2.2 CHAMADAS DE SISTEMA NO LINUX ....................................................... 18
2.3 SOFTWARE COMO SERVIÇO ..................................................................... 20
2.4 SOFTWARES DE MONITORAMENTO ...................................................... 23
2.4.1 LogMeIn Pro ................................................................................................... 23
2.4.2 Uptrends ........................................................................................................... 25
2.4.3 Comparativo entre sistemas ........................................................................... 29
3 PROJETO .............................................................................................. 30
3.1 ANÁLISE DE REQUISITOS ........................................................................... 30
3.1.1 Cliente............................................................................................................... 30
3.1.2 Servidor ............................................................................................................ 31
3.2 DIAGRAMAS DE CASO DE USO ................................................................. 32
3.2.1 Cliente............................................................................................................... 32
3.2.2 Servidor ............................................................................................................ 36
3.3 DIAGRAMA DE CLASSES ............................................................................. 41
3.3.1 Cliente............................................................................................................... 41
3.3.2 Servidor ............................................................................................................ 41
3.4 DIAGRAMA ENTIDADE-RELACIONAL.................................................... 43
4 DESENVOLVIMENTO ........................................................................ 44
4.1 BANCO DE DADOS ........................................................................................... 44
iii
4.2 HIBERNATE ....................................................................................................... 45
4.3 JAVA SERVER FACES ..................................................................................... 47
4.4 COMUNICAÇÃO ENTRE APLICATIVOS ................................................... 49
4.5 MONITORAMENTO EXTERNO .................................................................... 50
4.6 CONSTRUÇÃO DE GRÁFICOS EM JAVA ................................................. 52
5 APRESENTAÇÃO DO SISTEMA .................................................... 54
5.1 APLICATIVO SERVIDOR ............................................................................... 54
5.2 APLICATIVOS CLIENTE ................................................................................ 57
5.2 TESTES E RESULTADOS ................................................................................ 60
6 CONCLUSÕES .................................................................................... 63
REFERÊNCIAS BIBLIOGRÁFICAS ................................................... 64
iv
LISTA DE ABREVIATURAS
COM Component Object Model CRUD Create, Retrieve, Update and Destroy DCOM Distributed Component Objetct Model DLL Dynamic Link Library DMTF Distributed Management Task Force FCAPS Fault, Configuration, Accounting, Performance and Security GCC GNU Compiler Collection ISAPI Internet Server Application Programming Interface JSF Java Server Faces JSP Java Server Pages MIB Management Information Base MVC Modelo, Visão e Controle NMA Network Management Application NME Network Management Entity ODBC Open Database Connectivity SaaS Software as a Service SNMP Simple Network Management Protocol SO Sistema Operacional SOAP Simple Access Object Protocol SQL Structured Query Language TCC Trabalho de Conclusão de Curso TCO Total Cost of Ownership TI Tecnologia da Informação UNIVALI Universidade do Vale do Itajaí WBEM Web-Based Enterprise Management WMI Windows Management Instrumentation WMIC Windows Management Instrumentation Command-line WQL WMI Query Language XML eXtensible Markup Language
v
LISTA DE FIGURAS
Figura 1. Ambiente típico de rede ........................................................................................................ 3
Figura 2. Ambiente de rede comum em empresas de grande porte ..................................................... 4
Figura 3. Um evento típico do sistema Netuno. ................................................................................... 5
Figura 4. Instância da classe Disk ...................................................................................................... 13
Figura 5. Arquitetura básica de funcionamento do WMI. .................................................................. 15
Figura 6. Um modelo simplificado de consumidor/provedor de eventos. ......................................... 16
Figura 7. Exemplos da utilização da linguagem WQL ...................................................................... 17
Figura 8. Visão superficial de uma chamada de sistema. ................................................................... 18
Figura 9. Transição para o modo kernel. ............................................................................................ 19
Figura 10. Exemplificação das chamadas de sistema resultantes das funções fork e write ............... 20
Figura 11. Painel principal do LogMeIn Pro ...................................................................................... 24
Figura 12. Tela de monitoramento de carga de CPU ......................................................................... 25
Figura 13. Criação de monitoramentos externos ................................................................................ 26
Figura 14. Relatório geral com agrupamento das principais informações ......................................... 27
Figura 15. Criação de alertas customizados ....................................................................................... 28
Figura 16. Diagrama de casos de uso do aplicativo cliente i. ............................................................ 32
Figura 17. Diagrama de casos de uso do aplicativo cliente ii. ........................................................... 32
Figura 18. Tela de login da aplicação cliente. .................................................................................... 33
Figura 19. Tela de erro durante login. ................................................................................................ 34
Figura 20. Diagrama do caso de uso do sistema servidor. ................................................................. 36
Figura 21. Diagrama de classes do aplicativo cliente. ....................................................................... 41
Figura 22. Diagrama de classes da aplicação servidora. .................................................................... 42
Figura 23. Diagrama Entidade-Relacional. ........................................................................................ 43
Figura 24. Interface da ferramenta Enterprise Architect. ................................................................... 44
Figura 25. Interface da ferramenta DBManager. ............................................................................... 45
Figura 26. Comparativo entre consultas com e sem Hibernate. ......................................................... 46
Figura 27. Mapeamento do Hibernate dentro da classe Account. ...................................................... 46
Figura 28. Ferramenta CRUD do NetBeans. ...................................................................................... 48
Figura 29. Estrutura de camadas. ....................................................................................................... 48
Figura 30. Conectando-se a um serviço web através do Visual Studio 2008. ................................... 49
Figura 31. Parte de uma mensagem XML representando uma unidade lógica. ................................. 50
Figura 32. Parte do código da rotina de verificação HTTP. ............................................................... 51
Figura 33. Parte do código da rotina de verificação TCP. ................................................................. 51
Figura 34. Parte do código da rotina de verificação PING. ............................................................... 52
Figura 35. Trecho referente a um gráfico FusionCharts. ................................................................... 53
Figura 36. Gráfico gerado pelo componente FusionCharts. ............................................................... 53
Figura 38. Visualização de hosts que estão sendo monitorados externamente. ................................. 55
Figura 39. Adição de novo host para monitoramento externo. .......................................................... 55
Figura 40. Listagem dos hosts que estão sendo monitorados internamente. ...................................... 56
Figura 41. Download de aplicativo cliente. ........................................................................................ 56
Figura 42. Relatório de monitoramento. ............................................................................................ 57
Figura 43. Instalação do aplicativo cliente para Windows. ................................................................ 58
Figura 44. Serviço do Sistema Netuno no Windows. ........................................................................ 58
Figura 45. Configuração do sistema. .................................................................................................. 59
Figura 46. Instalação e configuração no Linux. ................................................................................. 59
vi
vii
LISTA DE TABELAS
Tabela 1. Tabela comparativa entre os sistemas ................................................................................ 29
viii
RESUMO
Sonnenhohl, Artur. Sistema Netuno: Um produto cliente/servidor para o monitoramento remoto de hosts no formato de software como serviço. Itajaí, 2009. 52f. 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í, 2009. O monitoramento e gerenciamento das redes de computadores e seus recursos são tarefas que não podem ser realizadas somente mediante o esforço humano, são necessárias ferramentas que auxiliem neste monitoramento e gerenciamento. Neste Trabalho de Conclusão de Curso (TCC) é apresentado o projeto e a revisão dos conceitos-base das tecnologias utilizadas para o desenvolvimento do Sistema Netuno, um produto cliente/servidor para o monitoramento de hosts. O sistema propõe uma abordagem diferente dos sistemas atuais de monitoramento de redes, por possuir aplicativos clientes rodando em um ambiente de rede local que se comunicam com a aplicação servidora que roda em um servidor central na Internet. O resultado deste projeto é um sistema de código proprietário baseado no modelo de Software como Serviço (SaaS). Palavras-chave: Gerência de Redes. Monitoramento de Redes. SaaS.
ix
ABSTRACT
The monitoring and management of computer networks and their resources are tasks that can´t be
achieved only through human effort, are necessary tools that aid in monitoring and management. In
this final work is presented the design and a review of the basic concepts of the technologies used in
the development of the system Netuno, a client/server product for host monitoring. The system
proposes a different approach from the current systems of network monitoring, having client
applications running on a local network which communicate with the server application that runs
on a central server on the Internet. The result of this project is a system of proprietary code, based
in the model of Software as a Service (SaaS).
Keywords: Network Management. Network Monitoring. SaaS.
1 INTRODUÇÃO
Passou a ser comum a presença de servidores de rede em empresas de todas as grandezas,
normalmente para armazenamento de arquivos, banco de dados, e-mails e aplicações similares. O
que estas empresas têm em comum é que a disponibilidade destes equipamentos é essencial para
seus negócios, muitas vezes acarretando em grandes prejuízos financeiros quando falham. Stallings
(2005) afirma que as redes e seus recursos tornam-se indispensáveis para as organizações.
Existem diversos produtos para auxiliar as tarefas de monitoramento e preservação dos
canais de comunicação das redes de computadores. Normalmente faz-se necessária a presença do
administrador de redes como profissional capaz de manipular e tirar proveito destes produtos.
Entretanto, de forma análoga a outras tecnologias, a simplificação no uso destes sistemas de
monitoramento pode tornar dispensável a função específica do administrador, notadamente nas
empresas menores.
É com o foco nesta realidade que se propõe o desenvolvimento do Sistema Netuno: um
produto cliente/servidor para o monitoramento de hosts no formato de software como serviço. A
idéia de funcionamento do sistema é a de que cada host a ser monitorado possuirá um cliente
instalado que enviará informações para o servidor de gerenciamento localizado na Internet. No
servidor será possível monitorar os clientes de maneira interna/externa, configurar o envio
automático de alertas e realizar a geração de relatórios através de uma interface web. O sistema terá
como objetivos finais proporcionar uma implementação rápida, fácil e de baixos custos ao cliente.
A execução deste projeto justifica-se como Trabalho de Conclusão de Curso para o Curso de
Ciência da Computação porque trata do desenvolvimento de uma solução computacional que faz
uso de diversas tecnologias, conceitos e teorias relevantes a esta área.
Será empregado o uso de chamadas WMI (Windows Management Instrumentation –
Instrumentação de Gerência do Windows) para coleta de informações de recursos de um
computador rodando o sistema operacional Windows e serão usadas as chamadas de sistema
diretamente ao núcleo para coleta de informações de recursos de computadores que utilizam Linux
ou outra variante do UNIX. O armazenamento das informações de coleta será feito no banco de
dados MySQL e a comunicação entre os clientes e o servidor se dará por web services. A
2
expectativa é agregar os principais conceitos de gerenciamento de redes durante a construção do
sistema.
O produto “Sistema Netuno” será um novo conceito em monitoramento de servidores, por
fugir do conceito de um produto comprado e instalado em um ambiente de rede local que requer um
especialista de redes para o monitoramento e gerenciamento da rede.
1.1 PROBLEMATIZAÇÃO
1.1.1 Formulação do Problema
As ferramentas atuais do mercado para gerenciamento e monitoramento de redes são
complexas e caras de serem instaladas e mantidas. Empresas de pequeno e médio porte muitas
vezes não possuem recursos financeiros disponíveis para mantê-las.
Em instalações típicas de softwares de monitoramento, o software gerente monitora seus
agentes em ambiente de rede local, pois está instalado dentro da mesma infra-estrutura de rede. Este
modelo elimina a possibilidade de monitoramento externo dos serviços que funcionam voltados a
internet, como servidores web e de e-mail. Este ambiente típico pode ser visto na Figura 1, onde os
servidores que possuem o logotipo “N” estão sendo monitorados pelo software gerente através do
servidor monitor.
3
Figura 1. Ambiente típico de rede
Existem outros cenários normalmente vistos somente em empresas de grande porte com
filiais onde o software gerente é instalado nos dois ambientes, e o monitoramento externo pode ser
realizado através da internet, matriz x filial e filial x matriz. Este ambiente pode ser visto na Figura
2.
4
Figura 2. Ambiente de rede comum em empresas de grande porte
Com base nestes cenários, este projeto propõe o desenvolvimento de um produto de fácil
implementação, manutenção que contemple tanto o monitoramento interno e externo para redes de
todos os tamanhos, sendo comercializado sob o modelo SaaS.
1.1.2 Solução Proposta
A solução proposta neste projeto consiste em desenvolver um sistema de monitoramento de
hosts. Os hosts serão monitorados através de aplicativos clientes que enviarão informações a um
servidor central na internet, de onde será realizado o monitoramento. O funcionamento básico de
um evento do sistema pode ser visto Figura 3.
5
Figura 3. Um evento típico do sistema Netuno.
Este modelo centralizador permitirá a realização de monitoramento externo e interno em
redes de todos os tamanhos.
1.2 OBJETIVOS
Os objetivos deste trabalho estão divididos em um objetivo geral e 5 (cinco) objetivos
específicos.
1.2.1 Objetivo Geral
O objetivo deste trabalho é desenvolver o sistema Netuno: um produto cliente/servidor para
o monitoramento remoto de hosts no formato de software como serviço.
1.2.2 Objetivos Específicos
Os objetivos específicos deste trabalho são:
• Consolidar os conhecimentos em gerenciamento de redes. O produto desta etapa é uma
revisão bibliográfica que contempla a fundamentação e a motivação para o
gerenciamento de redes de computadores, seus protocolos, qualidades e deficiências;
6
• Definir os componentes mais importantes para serem monitorados. O produto desta
etapa é uma lista descrevendo os componentes mais importantes e o modo como podem
ser coletados;
• Pesquisar trabalhos e softwares relacionados. O produto desta etapa é uma comparação
entre os atuais trabalhos e softwares e o produto que está para ser desenvolvido. O
objetivo é encontrar diferenciais para justificar este TCC;
• Modelar e construir o sistema. O produto gerado nesta etapa é o software propriamente
dito; e
• Realizar testes e publicar os resultados obtidos. Os produtos desta etapa são o relatório
de testes que será anexado ao TCC e um artigo para ser submetido a eventos da área.
1.3 Metodologia
A metodologia adotada neste Trabalho de Conclusão de Curso (TCC) é dividida em cinco
partes:
• Estudo: Nesta etapa foram realizados estudos e práticas a fim de adquirir os
conhecimentos necessários para a realização deste trabalho. Para o estudo foram
utilizados livros, artigos e internet. Também foram realizados testes com o Visual Studio
e o Dev C++ com o objetivo de familiarizar-se com as tecnologias a serem empregadas.
• Análise: Nesta etapa foi realizada uma pesquisa dos softwares existentes, sendo definida
uma lista dos principais componentes a serem monitorados nos hosts e diferencias ao
Sistema Netuno.
• Modelagem: Nesta etapa foi realizada a modelagem e especificações do Sistema Netuno.
• Desenvolvimento: Nesta etapa serão realizadas as implementações do sistema, com base
nas etapas definidas na modelagem, sendo:
1. Desenvolver aplicativos clientes;
2. Desenvolver aplicativo servidor.
7
• Documentação: Nesta etapa será desenvolvida toda a documentação do sistema, desde a
problematização até as considerações finais e o resultado dos testes. Esta etapa incluirá
também a produção e geração de um artigo científico para submissão a eventos da área.
1.4 Estrutura do trabalho
Este documento está dividido em quatro capítulos. O Capítulo 1, Introdução, apresenta uma
visão inicial sobre o trabalho e seus objetivos. O Capítulo 2, Fundamentação Teórica, apresenta o
resultado da etapa de estudo, com uma revisão bibliográfica dos temas envolvidos no trabalho. O
Capítulo 3, Projeto, apresenta o resultado das etapas de análise e modelagem. O Capítulo 4,
Planejamento do TCC II, apresenta a metodologia, cronograma e análise dos riscos do TCC II.
2 FUNDAMENTAÇÃO TEÓRICA
Neste capítulo é apresentada a revisão bibliográfica sobre os temas deste projeto. A seção
2.1 apresenta uma visão geral sobre Gerenciamento de Redes, expondo seus principais conceitos e
características, assim como as tecnologias de gerenciamento SNMP e WMI. A seção 2.2 descreve
características e o funcionamento de chamadas de sistema em sistemas operacionais Linux. A Seção
2.3 descreve o modelo de software SaaS e finalizando a Seção 2.4 descreve um comparativo entre
sistemas de monitoramento presentes no mercado com a solução proposta.
2.1 Gerenciamento de Redes
As redes de computadores com seus recursos associados e aplicações distribuídas vem
crescendo dentro das organizações, na medida em que este crescimento ocorre, aumenta também a
importância do que elas representam. Conforme Stallings (2005, p. 409) em uma rede de
computadores erros ocorrem, causando grandes impactos ou não. É por este motivo que as
organizações precisam organizar e gerenciar suas redes, tarefa esta que não pode ser feita somente
pelo esforço humano sem o auxílio de ferramentas automatizadas de gerenciamento de rede.
Para uma boa gerencia de redes é necessário que se tenha um entendimento claro dos seus
requisitos. Stallings (2005, p. 410) relata que a ISO (International Organization for Standardization
– Organização Internacional para Padronização) propõe o modelo FCAPS (Fault, Configuration,
Accounting, Performance and Security – Falha, Configuração, Contabilidade, Performance e
Segurança) que é composto por cinco categorias:
1. Gerenciamento de falhas: Recursos que permitem a detecção, isolamento e correção da
operação anormal do ambiente. O gerenciamento de falhas consiste na tomada rápida de
ações, sempre seguindo uma sequência lógica: determinar onde está a falha, isolar o
restante da rede da falha de modo que a rede continue operando, re-configurar ou
modificar a rede de modo que minimize o impacto de operar sem o(s) componente(s)
falhos e reparar ou substituir os componentes falhos para restaurar a rede ao seu estado
inicial;
2. Gerenciamento de contabilidade: Baseia-se no gerenciamento da utilização dos recursos
da rede, podendo ser realizado por usuário ou classe de usuários. Este gerenciamento é
importante, pois permite ao gerente de redes visualizar os usuários que estejam abusando
9
dos seus privilégios de acesso e sobrecarregando a rede à custa dos outros usuários e
também permite que o gerente de redes consiga realizar um melhor planejamento de
crescimento da rede;
3. Gerenciamento de configuração e de nome: É o gerenciamento dos recursos que
controlam, identificam, coletam e fornecem dados para objetos gerenciados, com o
objetivo de ajudar a proporcionar uma operação continua dos serviços de interconexão.
As redes de comunicação de dados são formadas por componentes individuais e
subsistemas lógicos que podem ser configurados para realizar muitas aplicações
diferentes, podendo o mesmo sistema ser configurado para agir como um roteador e/ou
como um nó de sistema final. Faz parte do gerenciamento de configuração a
preocupação com uma correta inicialização e desligamento de rede lógica, e também
manter, acrescentar e atualizar todas as relações entre componentes durante a operação
da rede;
4. Gerenciamento de desempenho: Gerencia responsável por avaliar o comportamento dos
objetos gerenciados e a eficácia das atividades de comunicação. É o gerenciamento de
desempenho que visa garantir que a rede proporcione um bom desempenho as aplicações
que rodam nela. A ISO divide esta área em dois sub-grupos: monitoramento e controle;
Monitoramento refere-se aos mecanismos para obter leitura de estado a respeito dos
componentes da rede, como o tráfego e a temperatura de um dispositivo, por exemplo. Já
controle refere-se as possibilidades de tomada de decisão mediante as leituras obtidas do
grupo de monitoramento; e
5. Gerenciamento de segurança: O gerenciamento de segurança concentra-se na geração,
distribuição e armazenamento de chaves de criptografia. O gerenciamento de segurança
está diretamente envolvido com o monitoramento e o controle de acesso às redes de
computadores e a todas as informações de gerenciamento de rede obtidas dos nós da
rede. Os registros de auditoria (logs) é considerada uma das mais importantes
ferramentas do gerenciamento de segurança.
Na medida em que as redes tornam-se mais complexas as ferramentas para gerenciá-las
ficam mais complexas também. Conforme Stallings (2005, p. 410) para um bom gerenciamento é
necessário um conjunto completo de ferramentas de coleta e controle de dados integrados ao
hardware e software – os sistemas de gerenciamento de rede.
10
Um Sistema de Gerenciamento de Rede (NMS – Network Management System) é um
conjunto de ferramentas de monitoramento e controle integrado, onde:
• Através de uma única interface de administração amigável é possível realizar a
maioria ou todas as tarefas de gerenciamento de redes; e
• O gerenciamento necessita de uma quantia mínima de equipamentos, onde a maior
parte do hardware e software necessário para o gerenciamento de rede esteja
incorporado no equipamento existente do usuário.
O sistema de gerenciamento monitora e controla a rede em toda sua abrangência, como uma
arquitetura unificada com endereços e rótulos atribuídos a cada ponto. Conforme Stallings (2005, p.
413) o gerenciamento de redes ainda pode ser divido em dois tipos de aplicações: um NMA
(Network Management Application – Aplicação de Gerenciamento de Rede) e os NMEs (Network
Management Entity – Entidade de Gerenciamento de Rede), onde o NMA é o sistema gerente e os
NMEs são os sistemas gerenciados, ou agentes.
Os NMEs têm como função a coleta de estatísticas sobre a comunicação e atividades
relacionadas à rede e devem permitir a execução de comandos que:
1. Transmitam estatísticas coletadas para o NMA da rede;
2. Alterem um parâmetro, por exemplo, um temporizador usado em um protocolo de
transporte;
3. Forneçam informações de estado, por exemplo, valores de parâmetro e enlaces
ativos;
4. Gerenciem tráfego artificial para realização de testes; e
5. Enviem mensagens quando as condições locais sofrerem uma alteração importante.
Em toda rede pelo menos um host deve ser designado como o host controlador da rede. Este
host deverá possuir o software NMA. Os softwares NMA incluem uma interface de operador para
permitir que usuários autorizados gerenciem a rede, o software por sua vez responde a estes
comandos exibindo informações da situação atual da rede e/ou emitindo comandos aos NMEs por
toda a rede.
11
A comunicação entre NMA e NMEs requer um protocolo dedicado a esta finalidade.
Atualmente duas opções são mais empregadas. Redes baseadas em servidores UNIX geralmente
empregam o SNMP (Simple Network Management Protocol – Protocolo Simples para a Gerência
de Redes). Redes baseadas no ambiente Microsoft podem empregar o WMI para obter informações
mais detalhadas.
2.1.1 SNMP
O protocolo padrão SNMP foi desenvolvido para servir de ferramenta de gerenciamento
para redes TCP/IP. Conforme Stallings (2005, p. 414) o termo protocolo de gerenciamento de rede
simples é usado para se referir a uma coleção de especificações para gerenciamento de rede que
incluem: o protocolo propriamente dito, a definição de um banco de dados e conceitos associados.
Conforme Stallings (2005, p. 414), o modelo do gerenciamento de rede utilizado pelo
SNMP inclui os seguintes elementos-chaves:
1. Estações de gerenciamento: Normalmente são dispositivos independentes, podendo
ser uma capacidade implementada em um sistema compartilhado. A estação de
gerenciamento age como a interface entra o gerente de rede humano e o sistema de
gerenciamento de rede;
2. Agente de gerenciamento: As principais plataformas como os hosts, switches e
roteadores principais podem ser equipadas com agentes de gerenciamento o que
permite que elas possam ser gerenciadas por uma estação de gerenciamento,
respondendo a requisições de informações e também fornecendo as estações de
gerenciamento informações importantes, porém não solicitadas em casos de falhas,
por exemplo; e
3. MIB (Management Information Base – Base de Informações de Gerenciamento):
Cada recurso da rede que precisa ser gerenciado é representado como um objeto, a
coleção destes objetos é que formam a MIB.
O protocolo SNMP não será empregado por um motivo fundamental: seu uso requer
instalação de uma implementação de agente. Forçar a instalação deste agente em funcionamento
paralelo ou em substituição ao agente Netuno obrigaria o usuário a realizar tarefas como a de
configuração de acesso. Isto incluiria a necessidade de definição de um nome de comunidade ou
12
ajustes de controle de acesso, dependendo da versão implementada. Normalmente a configuração
do agente padronizado de SNMP é feita através da livre edição de arquivos de texto. Ficaria
impossível avaliar todas as condições de erros de configuração capazes de levar a inoperância do
agente e frustração do usuário na tentativa de uso do Netuno.
O monitoramento será então realizado da seguinte forma: em sistemas operacionais
Windows as informações serão coletadas através de um agente próprio capaz de interagir com a
interface WMI do Windows. Nos sistemas operacionais Linux, este mesmo agente consultará o
sistema operacional diretamente, através do uso de chamadas ao sistema.
2.1.2 WMI
A DMTF (Distributed Management Task Force – Força Tarefa de Gerenciamento
Distribuído) viu a necessidade de um modelo padrão para o gerenciamento de sistemas
computacionais distribuídos. Esta necessidade deu origem ao WBEM (Web-Based Enterprise
Management – Gerenciamento Empresarial baseado em Web). O WBEM é composto por uma série
de tecnologias de gerenciamento, e apesar do nome ser muito associativo a web o modelo pode ser
implementado sob qualquer plataforma.
A Microsoft foi uma das empresas participantes do grupo de companhias que desenvolveu o
WBEM, o que fez com que ela adquirisse experiência suficiente para desenvolver sua própria
implementação do WBEM, o WMI.
O WMI é a tecnologia desenvolvida pela Microsoft, que conforme Tunstall e Cole (2002, p.
17) provê um gerenciamento unificado de hardware e software, facilitando o desenvolvimento de
aplicações de gerenciamento para sistemas operacionais Windows. A primeira aparição do WMI foi
para o Windows 2000, que veio com suporte nativo a tecnologia, sendo que pouco tempo depois a
Microsoft disponibilizou o WMI através de pacotes adicionais para o Windows 98 e o Windows
NT4. Hoje todos novos produtos da Microsoft vêm com suporte nativo à tecnologia.
O WMI, assim como o WBEM, utiliza-se do modelo CIM (Common Information Model –
Modelo Comum de Informações) para o armazenamento das informações. Este modelo conforme
Tunstall e Cole (2002, p. 28) representa uma maneira de armazenamento de todas as informações
gerenciais, tornando-as acessíveis por todos os aplicativos compatíveis com o padrão da tecnologia.
13
O CIM foi projetado baseado nos paradigmas de orientação a objetos, o que permite que ele
seja estendido, fazendo com que diferentes fabricantes de hardware e software possam adicionar
novas funcionalidades ao modelo. Quando se diz que o CIM é orientado a objeto, significa que ele
possui uma organização interna separada em classes, métodos e propriedades, todos devidamente
categorizados como placas de rede, discos rígidos, usuários e assim por diante. Como exemplo
observa-se a Figura 4, onde a classe Disk herda atributos padrões da classe HardwareDevice e por
fim é instanciada.
Super classe
Class HardwareDevice { sint32 DeviceId; } Classe extendida
Class Disk : HardwareDevice { sint32 Size; string Make; string Model; } Instância/objeto da classe Disk
Class Disk { DeviceId = 3FHED1; Size = 1200000; Make = Fujitsu; Model = FastBack; }
Figura 4. Instância da classe Disk
Fonte: Adaptado de Tunstall e Cole (2002, p. 9)
A Microsoft buscou seguir os padrões do WBEM durante o desenvolvimento do WMI, mas
também criou diferenciais a sua tecnologia. Como exemplo pode citar-se a ferramenta
administrativa WMIC (Windows Management Instrumentation Command-line – Linha de comando
da Instrumentação de Gerencia do Windows), que transforma objetos CIM para o formato XML,
que é o formato proposto pelo DMTF para o transporte de arquivos CIM.
A comunicação entre os vários componentes da arquitetura do WMI dá-se através dos
componentes COM/DCOM (Component Object Model/Distributed Component Object Model –
Modelo de Objeto de Componente/Modelo de Objeto de Componente Distribuído) da Microsoft.
Conforme Tunstall e Cole (2002, p. 80) o desenvolvimento de softwares capazes de se comunicar
com o WMI, estão divididos em duas categorias:
14
• Aplicativos de gerenciamento: Aqueles que buscam e alteram informações já
presentes no sistema através de recursos já suportados pelo WMI; e
• Aplicativos provedores: Aqueles que permitem ao WMI fornecer suporte de
gerenciamento a novos dispositivos de hardware e software.
A arquitetura básica de comunicação do WMI conforme Tunstall e Cole (2002, p. 81) pode
ser dividida em três principais camadas:
• Consumidores de Dados: São todas as aplicações que buscam as informações através
da interface do WMI. Um bom exemplo é um software para gerenciamento de
estações;
• Infra-Estrutura de Gerenciamento: É a camada intermediária, é nesta camada onde
ocorre o gerenciamento das transações do WMI. O gerenciamento destas transações
é feito por um serviço padrão do Windows chamado Windows Management Service
(Serviço de Gerenciamento do Windows) o winmgmt.exe. Este serviço quando
requisitado identifica se as informações desejadas são estáticas ou dinâmicas, caso
sejam estáticas ele acessa o repositório de dados CIM em busca das mesmas, caso
sejam dinâmicas ele as busca através dos Provedores de Dados; e
• Provedores de Dados: Eles podem ser executados como aplicativos standalone,
serviços do Windows ou como DLLs (Dynamic Link Library – Biblioteca de Link
Dinâmico). São extensões que fornecem ao WMI a possibilidade de acesso a
informações em tempo real de recursos do sistema como: unidade de CD-ROM
aberta, bits trafegando pela placa de rede, usuário ativo, entre outros.
O funcionamento destas três principais camadas da arquitetura básica pode ser visto na
Figura 5.
15
Figura 5. Arquitetura básica de funcionamento do WMI.
Fonte: Adaptado de Tunstall e Cole (2002, p. 81)
Além destas três camadas principais, existem ainda os provedores de eventos e os
consumidores de eventos. Que podem ser definidos da seguinte forma:
• Consumidores de eventos: Registram-se no repositório CIM para o recebimento de
notificações sobre determinados tipos de eventos, como disco cheio, falha na leitura
de memória, entre outros; e
• Provedores de eventos: Monitoram a ocorrência de eventos específicos e enviam
notificações ao Serviço de Gerenciamento do Windows quando ocorrem. Quando o
Serviço de Gerenciamento do Windows recebe estas notificações ele verifica se
16
existe algum consumidor registrado para aquele tipo de evento e as envia ao
consumidor registrado.
Os consumidores de eventos podem ainda ser divididos em dois tipos:
• Consumidores Temporários: São consumidores que recebem notificações somente
quando estão ativos. As informações destes consumidores ficam salvas somente na
memória e quando o sistema é reiniciado as informações são perdidas. Como
exemplo pode-se citar uma aplicação que precise saber do espaço em disco somente
na hora que ela for executar, sem a necessidade de estar recebendo esta informação o
tempo todo; e
• Consumidores Permanentes: São consumidores que recebem notificações enquanto
estiverem registrados, em casos do consumidor estar inativo o WMI tenta ativá-lo
antes de disparar o a notificação, um exemplo seria um software como o
desfragmentador de discos.
Os provedores de eventos e seus consumidores trabalham de maneira assíncrona, ou seja, a
comunicação entre provedores e consumidores ocorre somente quando um evento é disparado. O
funcionamento dos consumidores e provedores de eventos pode ser visto na Figura 6.
Figura 6. Um modelo simplificado de consumidor/provedor de eventos.
Fonte: Adaptado de Tunstall e Cole (2002, p. 88)
17
No WMI existem três tipos de eventos:
1. Eventos Intrínsecos: São eventos gerados quando ocorrem alterações nos dados do
WMI, como alteração do nome do computador;
2. Eventos Extrínsecos: Eventos gerados por sistemas externos ao WMI, como alertas
SNMP capturados pelo WMI; e
3. Eventos de Timer: Eventos pré-programados para ocorrerem em determinado horário
ou em determinado períodos de tempo.
Conforme Tunstall e Cole (2002, p. 98) todas as ações realizadas sobre o WMI como
registro no repositório CIM, consulta de informações, entre outras, são realizadas através de uma
linguagem própria do WMI, a WQL (WMI Query Language – Linguagem de Consulta WMI) que é
muito parecida com o SQL (Structured Query Language – Linguagem de Consulta Estruturada). Na
Figura 7 podem ser vistos alguns exemplos de consultas utilizando-se a WQL.
1 SELECT * FROM Win32_LogicalDisk WHERE FileSystem = "FAT"
2 SELECT * FROM Win32_LogicalDisk WHERE FreeSpace < 120000
Figura 7. Exemplos da utilização da linguagem WQL
Fonte: Adaptado de Tunstall e Cole (2002, p. 98)
A primeira consulta irá retornar os drivers lógicos do sistema do tipo FAT, a segunda
consulta irá retornar os drivers lógicos do sistema com espaço em disco inferior a 120000 Bytes.
Estas duas simples consultas exemplificam a facilidade de uso e o poder do WMI com a sua
linguagem WQL.
O WMI é uma tecnologia muito flexível e bem estrutura, que possibilita aos administradores
de rede e desenvolvedores tirarem o máximo de recursos do seu sistema. É também compatível com
várias linguagens de programação entre elas as mais comuns como Java, C++, C#, VB entre outras,
além de oferecer suporte a acessos indiretos através de conexões ODBC (Open Database
Connectivity), ActiveX e ISAPI (Internet Server Application Programming Interface).
18
Por ser uma tecnologia proprietária da Microsoft o WMI está disponível somente para
sistemas que atuam na plataforma Windows. Em sistemas operacionas como o Linux uma
alternativa para a obtenção de resultados similares, porém de maneira mais complexa são as
chamadas de sistema. Conforme Jones (2007) elas são a interface entre as aplicações e os serviços
que o kernel provê.
2.2 Chamadas de Sistema no Linux
Chamada de sistema, do inglês system call ou syscall, conforme Love (2007, p. 21) é toda
chamada realizada ao kernel através de interrupções de software (processos) vindas do espaço do
usuário. Para que se possa entender as chamadas de sistema é primeiramente necessário a
compreensão dos principais espaços do Linux sendo estes:
1. Espaço do usuário: É a área do SO (Sistema Operacional) onde rodam as aplicações
do usuário. Por exemplo navegadores web, editores de texto, jogos entre outros.
2. Espaço do Kernel: É onde ocorre todo o gerenciamento dos recursos do computador,
alocação de memória, gravação em disco, leitura de arquivos, transmissão de dados,
entre outros.
As chamadas de sistema ocorrem quando os aplicativos do espaço do usuário precisam
realizar funções do espaço do kernel como salvar um documento de texto no disco rígido por
exemplo. No exemplo da Figura 8 de forma superficial visualiza-se o fluxo da requisição de um
download por um navegador web, e a realização da chamada de sistema para gravação deste
arquivo em disco.
Figura 8. Visão superficial de uma chamada de sistema.
O motivo da existência das chamadas de sistema é o fornecimento de uma interface segura
de acesso aos serviços oferecidos pelo kernel, garantindo assim um bom funcionamento e
estabilidade do SO. As chamadas de sistema evitam que as aplicações tenham que acessar os
recursos do computador diretamente e de diferentes maneiras sem qualquer tipo de controle.
19
Conforme Love (2005, p. 23) para facilitar o desenvolvimento de aplicações que realizam
chamadas de sistema existe uma biblioteca da linguagem C chamada de libc, esta biblioteca nos
sistemas Linux mais atuais é fornecida como glibc (GNU libc). A glibc funciona como um tradutor
de comandos, traduzindo comandos simples do código fonte da aplicação em chamadas de sistema
complexas.
A gblic faz parte do coração do Linux, praticamente todo o código fonte do Linux está
baseado nesta biblioteca e mesmo programando em outras linguagens é bem provável que a glibc
esteja sendo usada. O compilador normalmente utilizado para a compilação de aplicações em C no
Linux é o gcc (GNU Compiler Collection – Coleção de Compiladores GNU).
Ao invocar uma chamada de sistema, conforme Bovet e Cesati (2005, p. 399) o CPU entra
no modo kernel e inicia a execução da função correspondente. Na Figura 9 pode-se observar o
processo de transição para o modo kernel durante a realização de uma chamada de sistema.
Figura 9. Transição para o modo kernel.
Como o kernel possui muitas chamadas de sistema, as chamadas são todas realizadas através
da passagem de um número como parâmetro ao kernel, que então identifica a chamada desejada
através deste número. O kernel utiliza-se de uma tabela de despachos de chamadas de sistema a
20
tabela sys_call_table onde ele possui entradas de todas as chamadas de sistema. É através desta
tabela que ele realiza a associação do número informado como parâmetro com a chamada de
sistema desejada.
Os parâmetros informados as rotinas de chamadas de sistema e a chamada propriamente dita
ocorrem através das funções syscallN onde N indica o número de parâmetros que varia de 0 a 6.
Logo estas chamadas vão de _syscall0 até _syscall6, onde o número de parâmetros é sempre 2 +
2xN. Os parâmetros sempre são informados em pares, pois a primeira parte identifica o tipo do
parâmetro e a segunda parte o nome. Por exemplo, as funções fork e write gerariam as respectivas
chamadas de sistema conforme a Figura 10.
fork()
_syscall0(int,fork)
write(int fd, const char * buf, unsigned int count)
_syscall3(int,write,int,fd,const char *,buf,unsigned int,count)
Figura 10. Exemplificação das chamadas de sistema resultantes das funções fork e write
Fonte: Adaptado de Bovet e Cesati (2007, p. 418)
Mesmo possuindo diferentes tipos de chamadas de sistema em diferentes arquiteturas o
Linux possui uma quantidade de chamadas de sistema bem enxuta se comparado ao Windows. O
desenvolvimento de aplicações que realizam chamadas de sistema podem ser um pouco complexas,
porém sua correta utilização permite que sejam executadas quaisquer ações e obtidas quaisquer
informações sobre o SO.
O Sistema Netuno pretende ser mais do que as consultas WMI e as chamadas de sistema. O
verdadeiro diferencial do sistema está na sua facilidade de implementação em ambientes Windows
e Linux e no seu modelo de negócios que é baseado em SaaS (Software as a Service – Software
como Serviço) que permite que o cliente obtenha uma redução de custos bem significativa.
2.3 Software como Serviço
SaaS é um conceito computacional onde o software passa a ser vendido como um serviço e
não mais através do modelo de licenças. Neste modelo o software é disponibilizado em um
servidor na internet centralizando assim todo o seu gerenciamento. Conforme Greschler e Magan
21
(2002, p. 317) o SaaS lembra os tempos antigos onde o ambiente de TI (Tecnologia da Informação)
era todo centralizado em mainframes.
Conforme Greschler e Magan (2002, p. 317) o SaaS oferece as empresas um modo mais
flexível de gerenciamento das aplicações e reduz os custos de TCO (Total Cost of Ownership –
Custo Total de Propriedade). O TCO de uma empresa com a área de TI é muito mais do que o
investimento inicial em hardware e software, a maior porção é representada pelo custo de pessoas
para desenvolvimento, aquisição, controle e suporte as aplicações.
O SaaS permite que o cliente pague somente pelo uso do software, geralmente uma
mensalidade por usuário, e elimina todos os outros custos para o cliente. Com o SaaS a única
preocupação do cliente passa ser a de possuir um computador com acesso a internet.
A aceitação do SaaS vem crescendo no mercado, e conforme Greschler e Magan (2002, p.
318) as cinco principais dificuldades de diferentes pontos de vista do modelo de software
convencional que alavancam este crescimento são:
• Dificuldade dos usuários em gerenciar software como produto: Os usuários quando
possuem os softwares instalados em seus computadores acabam muitas vezes
realizando operações incorretas no equipamento, afetando sua produtividade,
gerando custos e consumindo tempo do departamento de TI local;
• Dificuldade da TI em gerenciar software como produto: O departamento de TI tem
de manter uma equipe para preocupar-se com tarefas como: baixar as últimas
versões, manter todas as máquinas atualizadas, comprar e gerenciar licenças,
atualização de hardware entre outros. Este gerenciamento custa muito caro e faz com
que a TI desvie o seu foco de um gerenciamento totalmente voltado aos negócios;
• Dificuldades sentidas pelas empresas desenvolvedoras de software: As empresas
desenvolvedoras possuem elevados custos para manter versões atualizadas do seu
software em todos os seus clientes, perdem também muito dinheiro com a pirataria e
possuem uma receita pouco previsível; e
• Mudanças nas tecnologias: O departamento de TI sempre tem que estar em busca de
inovações tecnológicas de seus equipamentos para que suportem o aumento da
demanda.
22
• Crescimento das empresas desenvolvedoras de aplicações web: A popularização do
desenvolvimento das aplicações web incentiva o crescimento do modelo SaaS que
opera neste ambiente.
No seu sentido mais puro o SaaS pode ser comparado como um bem útil como o telefone,
água ou energia elétrica. Constante, consistente e com gerenciamento central (Greschler; Magan,
2002, p. 318).
O SaaS garante que todos usuários finais sempre tenham a última versão do software sem a
necessidade de atualização em cada máquina. Esta facilidade liberta as empresas de uma equipe de
TI focada no suporte de aplicações, permitindo também que o departamento de TI seja
redirecionado sem grandes perdas em investimentos. Para os desenvolvedores o SaaS permite que
eles tenham uma receita mais previsível bem como redução dos custos para a correção de falhas
sistêmicas.
O primeiro sinal da indústria de SaaS conforme Greschler e Magan (2002, p. 319), começou
em 1998 com o surgimento de empresas desenvolvedoras de softwares web. Nesta época foram
construídos data centers gigantes e a promessa aos clientes era o outsourcing total de TI. Porém
conforme Greschler e Magan (2002, p. 319) surgiram dificuldades que fizeram com que o modelo
não obtivesse sucesso na época, sendo estas:
• Aplicações não são dados: No inicio as empresas fornecedoras de aplicações pela
internet imaginavam que fornecer uma aplicação web seria como enviar somente
HML, vídeou ou áudio, esqueceram de considerar uso do processamento, memória,
conflito de aplicações etc. Foi neste momento que eles perceberam que os recursos
de hardware teriam que ser muito maiores para dar conta da demanda;
• Compartilhamento de dados: Os clientes da época gostaram da idéia de outsourcing
de infra-estrutura, mas não gostaram da idéia de seus dados ficarem no mesmo local
que os dados de empresas concorrentes;
• Sem solução off-line: Muitos executivos precisavam acessar o sistema e os dados da
empresa de variados locais como aeroportos, outras cidades etc. A internet era muito
limitada na época e foram encontradas diversas dificuldades por este motivo; e
23
• Escalabilidade: Na época não existiam métodos de se fazerem ferramentas escaláveis
que suportassem milhares de usuários conectados ao mesmo tempo, sendo que eles
conseguiam apenas associar um servidor para cada empresa o que limitava a
capacidade máxima de usuários.
Juntamente com o avanço tecnológico como a velocidade da internet, virtualização de
servidores, cloud computing (computação em nuvem) entre outros, o SaaS vem crescendo e
ganhando espaço dentro das organizações superando assim as dificuldades encontradas no passado.
O modelo de SaaS foi adotado para este projeto por ser bem compatível com os objetivos do
Sistema Netuno, que é oferecer serviços de monitoramento através de um gerenciamento central na
web a baixos custos e com características de fácil implementação.
2.4 Softwares de Monitoramento
Os sistemas analisados são ferramentas mundialmente conhecidas e com características
similares a solução proposta. Primeiramente na Seção 2.4.1 serão apresentados os recursos de
monitoramento interno da ferramenta LogMeIn Pro uma ferramenta focada no gerenciamento
remoto de hosts, na Seção 2.4.2 a ferramenta Uptrends uma ferramenta especializada na realização
de monitoramento externo e na Seção 2.4.3 será realizado um comparativo entre as ferramentas
citadas com a solução proposta.
2.4.1 LogMeIn Pro
O LogMeIn Pro (http://www.logmein.com) é uma ferramenta desenvolvida pela LogMeIn
Inc. uma empresa norte-americana, com sede em Boston, MA. A ferramenta tem como principal
objetivo o gerenciamento e o monitoramento de hosts, utilizada mundialmente em larga escala
gerenciando e monitorando mais de setenta milhões de hosts.
A ferramenta funciona como um aplicativo cliente/servidor suportando hosts que rodam na
plataforma Windows, necessitando a instalação de aplicativos clientes nesses hosts. O
gerenciamento e monitoramento dos hosts são feitos através da internet em um painel central
fornecido pela empresa desenvolvedora.
24
O painel possui uma interface bem interativa toda desenvolvida em Ajax (Asynchronous
Javascript and XML) eliminando as atualizações de tela do navegador o que proporciona uma ótima
experiência ao usuário. A principal tela do painel pode ser visto na Figura 11.
Figura 11. Painel principal do LogMeIn Pro
Fonte: LogMeIn Pro
O LogMeIn Pro permite um monitoramento interno detalhado dos recursos do host como
carga de CPU, memória, discos rígidos, rede entre outros recursos todos em tempo real. Na Figura
12 pode ser visto uma tela do monitoramento em tempo real da carga do processador.
25
Figura 12. Tela de monitoramento de carga de CPU
Fonte: LogMeIn Pro
O LogMeIn Pro permite um rápido monitoramento e gerenciamento dos recursos do
computador, apesar da principal função da ferramenta ser o controle remoto do computador os
recursos de monitoramento são bem completos.
2.4.2 Uptrends
A ferramenta Uptrends (htp:://www.uptrends.com) é uma ferramenta de monitoramento
externo com mais de 4.500 clientes ao redor do mundo distribuídos em 23 países. O sistema é bem
completo para a realização de monitoramento externo suportando o monitoramento de vários países
distintos e de vários tipos de serviços.
O sistema é executado através do site da empresa desenvolvedora não necessitando qualquer
tipo de instalação por parte do cliente. O sistema suporta a criação de vários tipos de monitoramento
externo como de http, ping, conexão direta, web services com parâmetros bem específicos de
timeout, freqüência, limites de performance, simulação de browsers etc. A tela de criação de
monitoramentos externos pode ser observada na Figura 13.
26
Figura 13. Criação de monitoramentos externos
Fonte: Uptrends
O sistema oferece a opção de relatórios bem detalhados por períodos de até dois anos, todos
podendo ser exportados para Excel, PDF ou enviados por e-mail. A tela de um relatório geral com o
agrupamento das principais informações pode ser visto na Figura 14.
27
Figura 14. Relatório geral com agrupamento das principais informações
Fonte: Uptrends
Em caso de falhas no serviço monitorado a ferramenta da Uptrends possui um amplo suporte
a diversos tipos de alertas sendo eles E-mail, SMS, MSN e RSS com opções de customização de
mensagem, período de erro até avisar, grupo de contatos entre outros. A tela de criação de um alerta
customizado pode ser vista na Figura 15.
28
Figura 15. Criação de alertas customizados
Fonte: Uptrends
A ferramenta também possui alguns recursos bem únicos como realizar captura de telas das
páginas web com falhas e enviar ao administrador do site. Em uma visão geral a ferramenta atende
boa parte das necessidades de monitoramento externo da maioria das empresas.
29
2.4.3 Comparativo entre sistemas
Nesta seção serão apresentados comparativos entre os sistemas analisados e a solução
proposta. As comparações foram realizadas por itens e podem ser vistas na Tabela 1.
Tabela 1. Tabela comparativa entre os sistemas
Item LogMeIn Uptrends Netuno
Dificuldade de instalação Fácil Sem Instalação Fácil
Monitoramento Interno SIM NÃO SIM
Monitoramento Externo NÃO SIM SIM
Relatórios de desempenho NÃO SIM SIM
Notificação ao cliente SIM SIM SIM
Requisitos Internet
Windows
Internet Internet
Windows/Linux
Porte Clientes P/M/G P/M/G P/M
Valor 1 host / $12,20 / mês 5 urls / $4,99 / mês -
Ambas as ferramentas estudadas LogMeIn e Uptrends possuem características diferentes na
área de monitoramento. A ferramenta Netuno irá buscar tornar-se uma melhor alternativa para
realização de monitoramento interno e externo em uma mesma aplicação buscando possuir
características de monitoramento das duas outras ferramentas.
3 PROJETO
Este Capítulo tem por objetivo apresentar o projeto e a modelagem da solução proposta
conforme apresentado na Seção 1.1. A Seção 3.1 apresenta os requisitos definidos no projeto do
sistema Netuno. A Seção 3.2 apresenta os diagramas de caso de uso do projeto. A Seção 3.3
apresenta os diagramas de classe e na Seção 3.4 são apresentados os diagramas de entidade-
relacional.
3.1 Análise de Requisitos
Os requisitos funcionais e não funcionais da aplicação cliente e servidora foram
especificados separadamente nas Seções 3.1.1 e 3.1.2 respectivamente.
3.1.1 Cliente
A aplicação cliente será responsável por coletar as informações dos hosts e informá-las a
aplicação servidora. Os requisitos funcionais são:
• RF01: O cliente deverá coletar informações de recursos do host, sendo elas:
1. Carga de processamento em porcentagem e carga de processamento por
número de processos ou threads em estado de execução;
2. Quantidade de espaço livre e ocupado em valores totais e porcentuais por
partição ou arranjo de partições;
3. Quantidade de memória física instalada, ocupada pelo sistema operacional,
ocupada pelos processos e livre em valores totais e porcentuais; e
4. Quantidade de processos nos diversos estados possíveis: em execução,
bloqueado por chamada ao sistema, dormindo ou zumbi.
• RF02: O cliente deverá sincronizar as informações com a aplicação servidora
repetidamente por tempos pré-definidos e ajustáveis.
31
Os requisitos não funcionais identificados são:
• RNF01: O cliente deve ser desenvolvido utilizando a linguagem de programação
C++;
• RNF02: O cliente possuirá duas versões. Uma para sistemas operacionais Windows e
outra para sistemas Linux; e
• RNF03: O cliente será concebido como software proprietário.
3.1.2 Servidor
A aplicação servidora será responsável por receber e tratar as informações recebidas pelo
cliente armazenando-as em um banco de dados, disponibilizando-as através de uma interface web
para o administrador dos servidores. Os requisitos funcionais são:
• RF01: A interface deverá permitir o cadastro de contas;
• RF02: A interface deverá permitir o cadastro de monitoramento externo de portas;
• RF03: A interface deverá exibir todos os hosts e o estado de seus recursos
monitorados internos e externos;
• RF04: A interface deverá exibir um relatório de anomalias apresentadas no host;
• RF05: A interface deverá permitir a exclusão de um host; e
• RF06: O sistema deverá enviar um alerta por e-mail em caso de anomalias
apresentadas no host.
Os requisitos não funcionais identificados são:
• RNF01: A linguagem utilizada para o desenvolvimento deverá ser a JSP (Java Server
Pages – Páginas Servidoras Java); e
• RNF02: O sistema de gerenciamento de banco de dados que será utilizado é o
MySQL;
32
3.2 Diagramas de Caso de Uso
Os diagramas de caso de uso da aplicação cliente e servidora foram especificados
separadamente nas Seções 3.2.1 e 3.2.2 respectivamente.
3.2.1 Cliente
O diagrama de caso de uso construído para a aplicação cliente foi dividido em duas partes,
onde na primeira são exibidas as ações do usuário sobre o sistema cliente conforme a Figura 16 e na
segunda são exibidas as ações do sistema cliente sobre a aplicação servidora para melhor
entendimento do funcionamento interno do sistema cliente, conforme Figura 17.
Figura 16. Diagrama de casos de uso do aplicativo cliente i.
Figura 17. Diagrama de casos de uso do aplicativo cliente ii.
33
3.2.1.1 UC01 – Efetuar Login
Este caso de uso é responsável pela autenticação do usuário no aplicativo cliente.
Condições
• Pré-condição: Ter uma conta já cadastrada; e
• Pós-condição: Uma conta está autenticada no sistema.
Cenários
Faz o login {Principal}
1. Ao iniciar o sistema usuário informa seu nome de usuário e senha na tela de login,
conforme Figura 18;
2. Sistema verifica se usuário e senha estão corretos; e
3. O sistema fecha a tela de login e permanece rodando em background.
Figura 18. Tela de login da aplicação cliente.
Usuário e/ou senha inválidos {Exceção}
Caso na etapa dois, o usuário e/ou senha estiverem inválidos.
2.1. O sistema deverá exibir a mensagem “usuário e/ou senha inválido(s)”, conforme
Figura 19.
34
Figura 19. Tela de erro durante login.
3.2.1.2 UC02 – Cadastrar Host
Este caso de uso é responsável pelo cadastramento do host no servidor.
Condições
• Pré-condição: Aplicação cliente estar autenticada na aplicação servidora; e
• Pós-condição: Um host está cadastrado.
Cenários
Cadastra o host {Principal}
1. Ao iniciar o sistema a aplicação verifica se o host atual já está cadastrado, caso não
esteja o sistema cadastra o host atual com um nome de identificação único.
Host já cadastrado {Exceção}
Caso na etapa um, o host já esteja cadastrado na aplicação servidor.
1.1 Sistema ignora cadastro de host.
3.2.1.3 UC03 – Sincronizar Configurações
Este caso de uso é responsável por sincronizar as configurações especificadas para o host
pela aplicação servidora.
Condições
• Pré-condição: Aplicação cliente estar autenticada na aplicação servidora;
35
• Pré-condição: Ser um host já cadastrado no sistema; e
• Pós-condição: Configurações sincronizadas.
Cenários
Sincronizar configurações {Principal}
1. Ao iniciar o sistema a aplicação verifica se o host atual já está cadastrado, caso não
esteja o sistema cadastra o host atual com um nome de identificação único.
3.2.1.4 UC04 – Coletar Dados
Este caso de uso é responsável por monitorar os recursos do host, coletando estas
informações e armazenando as em memória.
Condições
• Pré-condição: Ter uma conta autenticada no sistema;
• Pré-condição: Ser um host já cadastrado no sistema; e
• Pós-condição: Dados coletados.
Cenários
Coletar Dados {Principal}
1. O sistema dispara a função de coleta de dados automaticamente em períodos pré-
definidos, estes dados são armazenados em memória, e ficam aguardando o envio.
3.2.1.5 UC05 – Enviar Dados Coletados
Este caso de uso é responsável pelo envio dos dados coletados.
Condições
• Pré-condição: Ter uma conta autenticada no sistema;
• Pré-condição: Ser um host já cadastrado no sistema;
36
• Pré-condição: Dados já terem sido coletados; e
• Pós-condição: Dados coletados enviados.
Cenários
Enviar Dados Coletados {Principal}
1. O sistema dispara a função de envio dos dados coletados automaticamente, estes
dados são buscados em memória e depois de enviados são apagados da memória.
3.2.2 Servidor
O diagrama de caso de uso para a aplicação servidora é exibido na Figura 15.
Figura 20. Diagrama do caso de uso do sistema servidor.
37
3.2.2.1 UC01 – Cadastrar Conta
Este caso de uso é responsável pela criação de uma conta para um novo usuário do sistema.
Condições
• Pós-condição: Uma conta está criada no sistema.
Cenários
Criar conta {Principal}
1. Usuário preenche o formulário de cadastro com informações como nome completo,
e-mail e senha;
2. Sistema verifica se e-mail está disponível para cadastro;
3. Sistema envia e-mail com link para o usuário para confirmar o cadastro; e
4. Usuário clica no link para ativação da conta, o qual redireciona o usuário já
autenticado para a página de seu painel de controle.
E-mail já cadastrado {Exceção}
Se o endereço de email já existir.
2.1 O sistema deverá exibir a mensagem “e-mail já cadastrado, clique aqui para enviar
sua senha por e-mail”.
3.2.2.2 UC02 – Efetuar Login
Este caso de uso é responsável pela autenticação do usuário na interface de gerenciamento
da aplicação servidora.
Condições
• Pré-condição: Uma conta estar criada no sistema e ativa no sistema.
• Pós-condição: Usuário autenticado.
38
Cenários
Criar conta {Principal}
1. Usuário informa seu e-mail e sua senha;
2. Sistema verifica se e-mail e senha estão corretos; e
3. Sistema autentica o usuário e o redireciona para a tela de visualização de hosts.
E-mail e/ou senha inválidos {Exceção}
Caso na etapa dois o e-mail e/ou senha sejam inválidos.
1.1 O sistema deverá exibir a mensagem “Não foi possível autenticar-se. Verifique se o
e-mail e senha estão digitados corretamente”.
3.2.2.3 UC03 – Visualização dos Hosts
Este caso de uso é responsável pela visualização dos hosts da conta autenticada.
Condições
• Pré-condição: Estar autenticado no sistema.
• Pós-condição: Visualização dos hosts.
Cenários
Visualizar Hosts {Principal}
1. Usuário seleciona a opção “visualizar hosts” do menu; e
2. O sistema exibirá todos os hosts da conta.
3.2.2.4 UC04 – Visualização dos Recursos Monitorados do Host
Este caso de uso é responsável pela visualização dos recursos que estão sendo monitorados
em determinado host.
39
Condições
• Pré-condição: Estar autenticado no sistema;
• Pré-condição: Estar na tela de visualização de hosts; e
• Pós-condição: Visualização dos recursos do host.
Cenários
Visualização dos Recursos do Host {Principal}
1. Usuário clica sobre determinado host na tela de visualização de hosts; e
2. O sistema exibirá todos os recursos que estão sendo monitorados do host
selecionado.
3.2.2.5 UC05 – Cadastro de Monitoramento de Portas por Host
Este caso de uso é responsável pelo cadastro de monitoramento de portas externo para
determinado host.
Condições
• Pré-condição: Estar autenticado no sistema;
• Pré-condição: Estar na tela de visualização de recursos do host; e
• Pós-condição: Adição de nova porta para monitoramento.
Cenários
Cadastro de Monitoramento de Portas {Principal}
1. Usuário clica em criar nova regra de monitoramento;
2. Usuário após realização da regra clica em salvar; e
3. Sistema retorna para a interface de visualização de recursos monitorados do host.
40
3.2.2.6 UC06 – Visualização de relatórios
Este caso de uso é responsável pela exibição de relatórios para o usuário.
Condições
• Pré-condição: Estar autenticado no sistema; e
• Pós-condição: Visualização do relatório selecionado.
Cenários
Visualização de Relatórios {Principal}
1. Usuário seleciona a opção “relatórios” do menu;
2. Sistema exibirá todos os relatórios disponíveis para visualização;
3. Usuário seleciona relatório desejado para visualização; e
4. Sistema exibe relatório selecionado pelo usuário.
3.2.2.7 UC07 – Exclusão de Host
Este caso de uso é responsável pela exclusão de hosts.
Condições
• Pré-condição: Estar autenticado no sistema;
• Pré-condição: Estar na tela de visualização de hosts; e
• Pós-condição: Exclusão do host selecionado.
Cenários
Exclusão de Host {Principal}
1. Usuário seleciona os hosts que deseja excluir;
2. Usuário clica no botão excluir; e
41
3. Sistema excluirá os hosts selecionados.
3.3 Diagrama de Classes
O diagrama de classes da aplicação cliente e servidora foi especificado separadamente nas
Seções 3.3.1 e 3.3.2 respectivamente.
3.3.1 Cliente
Na Figura 21 observa-se o diagrama de classes da aplicação cliente.
Figura 21. Diagrama de classes do aplicativo cliente.
A descrição de cada classe é exibida a seguir:
• Host: Esta classe corresponde ao host;
• Process: Esta classe corresponde a um processo do host; e
• LogicalDisk: Esta classe corresponde a um disco lógico do host.
3.3.2 Servidor
Na Figura 22 observa-se o diagrama de classe da aplicação servidora.
42
Figura 22. Diagrama de classes da aplicação servidora.
A descrição de cada classe é exibida a seguir:
• SysCore: Esta classe correspondente as principais rotinas do sistema rotinas do
sistema;
• WebListener: Esta classe corresponde ao serviço web de comunicação com os hosts;
• Account: Esta classe corresponde a uma conta do sistema;
• Host: Esta classe representa o host;
• Process: Esta classe representa um processo de um host;
• LogicalDisk: Esta classe representa um disco lógico de um host;
43
• ExternalMonitor: Esta classe corresponde a uma porta registrada para monitoramento
externo de determinado host; e
• Anomaly: Esta classe corresponde a uma anomalia do host.
3.4 Diagrama Entidade-Relacional
Diagrama entidade relacional da aplicação servidora pode ser visto na Figura 23.
Figura 23. Diagrama Entidade-Relacional.
44
4 DESENVOLVIMENTO
Neste capítulo são apresentados os resultados alcançados durante a fase de desenvolvimento
do sistema, abordando os principais recursos e ferramentas utilizadas.
4.1 Banco de Dados
Conforme o projeto do software, o banco de dados utilizado foi o MySQL Server 5.1.
Durante o desenvolvimento do sistema e seus diversos módulos foram necessárias algumas
alterações no modelo entidade relacional inicialmente proposto, estas alterações podem ser vistas na
seção 3.4.
O modelo entidade relacional de banco de dados seguiu o padrão do sistema e foi todo
modelado na ferramenta Enterprise Architect 7.5 (SPARX SYSTEMS, 2010), a ferramenta possui
inúmeros recursos e permite a criação de diversas entidades e relacionamentos. A interface da
ferramenta pode ser vista na Figura 24, conforme o fabricante além dos recursos utilizados para o
desenvolvimento deste projeto a ferramenta ainda possuiu um forte controle de versão de software,
permitindo a criação e distribuição de tarefas em grandes projetos.
Figura 24. Interface da ferramenta Enterprise Architect.
Observa-se na interface da ferramenta, ao lado esquerdo a paleta de itens que foram
utilizados para a modelagem do banco, e no lado direito toda a estrutura do projeto.
45
A manutenção do banco de dados foi realizada através da ferramenta DBManager 3.2.4
(DBTOOLS SOFTWARE, 2005), os principais recursos utilizados nesta ferramenta foram a
execução de consultas e o construtor de tabelas. A interface básica da ferramenta pode ser vista na
Figura 25.
Figura 25. Interface da ferramenta DBManager.
Ao lado esquerdo da ferramenta são exibidas as conexões a banco de dados em um
determinado servidor, o usuário tem a opção de se conectar a mais de um servidor e a mais de um
banco de dados, na parte direita da tela são realizadas as rotinas de visualização de dados, execução
de consulta, manutenção de tabelas entre outras.
Na programação do sistema a conexão ao banco de dados não foi realizada de maneira direta
simplesmente através de um driver de conexão, no entanto foi utilizado um framework específico
chamado Hibernate.
4.2 Hibernate
O Hibernate, conforme King (2010), é um framework criado para melhorar a persistência de
dados reduzindo sua complexidade e agregar novos recursos. Neste projeto foi utilizada a última
versão do Hibernate 3.
Com a utilização do Hibernate as consultas realizadas ao banco de dados são construídas em
uma linguagem própria o HQL (Hibernate Query Language – Linguagem de Consulta Hibernate) o
que permite que o sistema possa rodar sob qualquer banco de dados relacional sem a necessidade de
46
que parte do código seja reescrito. Um comparativo entre consultas utilizando HQL (1) e SQL (2)
podem ser vistas na Figura 26, esta consulta é utilizada no módulo de monitoramento externo e a
consulta em SQL foi somente construída para exemplificação da diferença.
1 Query q = em.createQuery("select object(o) from Externalmonitor as o");
q.setMaxResults(max);
q.setFirstResult(first);
2 String SQL = “select * from externalmonitor limit “ + max + “ offset “ +
first;
Figura 26. Comparativo entre consultas com e sem Hibernate.
Para a utilização do Hibernate no projeto foi necessária além da importação das respectivas
bibliotecas, o mapeamento dos relacionamentos dos campos do banco de dados dentro das classes
Java, na Figura 27 podem ser vistos os mapeamentos realizados para a classe Account do Sistema
Netuno.
Figura 27. Mapeamento do Hibernate dentro da classe Account.
47
A utilização do Hibernate exige um pouco mais do desenvolvedor no início do sistema, mas,
conforme a programação evolui, surgem os ganhos com velocidade na manutenção do código.
Neste projeto o Hibernate foi implementado de maneira integrada ao framework JSF (Java
Server Faces) sob um modelo de camadas MVC (Modelo, Visão, Controle).
4.3 Java Server Faces
O JSF 2.0 foi o framework utilizado para o desenvolvimento das principais rotinas de
frontend e backend do sistema, este framework somente é compatível com a linguagem Java e foi
escolhido por ser confiável e oferecer uma boa manutenção de código.
A utilização da ferramenta NetBeans 6.8 (NETBEANS.ORG, 2010) juntamente com o
framework JSF foi um ponto crucial para o desenvolvimento deste sistema, pois sem a utilização de
ambos o período para o desenvolvimento de um sistema desta complexidade seria curto.
As rotinas básicas do sistema como criação, edição, visualização e exclusão foram geradas
através de uma ferramenta CRUD integrada ao NetBeans. Ferramentas CRUD (Create, Update,
Retrieve, Destroy – Criar, Atualizar, Buscar, Excluir) auxiliam muito na geração de código e
deixam a cargo do desenvolvedor as customizações e o desenvolvimento das regras de negócio. A
tela para geração de código da ferramenta CRUD do NetBeans pode ser vista na Figura 28.
48
Figura 28. Ferramenta CRUD do NetBeans.
A estrutura do código JSF gerado adota os padrões do modelo MVC que separa o código em
três camadas, juntando-se ao Hibernate obtém-se uma quarta camada a de banco de dados, a
estrutura básica gerada pode ser vista na Figura 29.
Modelo
Visão
Controle
Hibernate
Figura 29. Estrutura de camadas.
49
4.4 Comunicação entre aplicativos
Neste projeto a comunicação entre os aplicativos clientes e servidores foi realizada através
da construção de um Web Service (Serviço Web) e o protocolo adotado foi o SOAP (Simple Object
Access Protocol – Protocolo Simples de Acesso a Objeto).
O serviço web roda na aplicação servidora e foi desenvolvido em Java juntamente com os
demais módulos, o mesmo foi construído utilizando-se apenas as bibliotecas nativas do Java, sem a
necessidade de nenhum framework ou biblioteca adicional.
As rotinas de comunicação com o serviço web por parte dos clientes foi desenvolvida de
forma específica para Windows e Linux apesar de ambos terem sido desenvolvidos em C++, devido
a incompatibilidade dos sistemas.
O desenvolvimento do aplicativo cliente para Windows foi menos complexo, pois a criação
da rotina de comunicação ao serviço web dentro do Visual Studio 2008 com o framework .NET 2.0
foi mais simples devido aos inúmeros recursos oferecidos pela ferramenta e pelo framework. A
Figura 30 ilustra uma das facilidades do Visual Studio, que é a conexão a um serviço web, onde é
somente necessário digitar o endereço web.
Figura 30. Conectando-se a um serviço web através do Visual Studio 2008.
No aplicativo cliente para Linux o estabelecimento desta conexão foi mais complexo,
primeiramente por não ter sido encontrada um IDE de desenvolvimento para Linux tão integrado
50
quanto o Visual Studio 2008, no entanto foi utilizada uma biblioteca open-source na linguagem
C++ chamada gSoap, a versão utilizada desta biblioteca para o desenvolvimento do aplicativo
cliente Linux foi a 2.1.6.
As informações enviadas pelos aplicativos clientes foram padronizadas, onde qualquer troca
de informação entre os sistemas ocorre através do envio de textos formatos em XML (eXtensible
Markup Language – Linguagem de Marcação Extensível). Na Figura 31 pode ser visto parte de
uma mensagem XML enviada com informações da unidade lógica de um host.
<disk><free>10505396</free><total>20956760</total><name>C:</name></disk>
Figura 31. Parte de uma mensagem XML representando uma unidade lógica.
4.5 Monitoramento Externo
As rotinas de monitoramento externo do sistema são HTTP, TCP e ICMP cada uma das
rotinas exige um código específico para verificação. A rotina HTTP realiza uma requisição web do
tipo GET ao servidor de destino e análise os cabeçalhos de resposta caso encontre o código “200
OK” significa que a página pode ser aberta com sucesso, parte deste código pode ser visto na Figura
32.
51
Figura 32. Parte do código da rotina de verificação HTTP.
A rotina de verificação TCP tenta abrir uma conexão com a porta de destino informada, caso
ocorra um timeout de conexão a parta é considerada fechada, caso seja estabelecida uma conexão a
mesma é automaticamente fechada e a porta considerada ativa. A parte de conexão da rotina pode
ser vista na Figura 33.
Figura 33. Parte do código da rotina de verificação TCP.
52
O desenvolvimento do monitoramento via PING não foi possível da mesma forma que as
demais rotinas, onde tudo é feito dentro da programação. Foi necessário realizar a chamada ao
programa PING do sistema operacional e interpretar os resultados, surgiu esta necessidade pois a
linguagem Java por rodar dentro de uma máquina virtual não implementa chamadas de TCP de
baixo nível como o envio de pacotes ICMP.
Figura 34. Parte do código da rotina de verificação PING.
Todas as verificações realizadas são feitas através de threads onde estas são controladas por
um processo pai. A utilização desta técnica permite que a verificação ocorra nos tempos pré-
determinados pelo usuário, pois após a primeira verificação a thread entra em modo de hibernação e
somente acorda para fazer a próxima verificação após o período de intervalo definido pelo usuário
no painel do aplicativo servidor.
4.6 Construção de gráficos em Java
Para o enriquecimento dos relatórios do sistema, foram construídos gráficos dinâmicos em
Flash. A construção destes gráficos requereu a utilização do FusionCharts (FUSIONCHARTS,
2009) que é um componente que permite a geração de gráficos através da passagem de parâmetros
em XML.
A utilização deste componente de maneira integrada com o framework JSF requereu a
utilização de uma taglib específica, taglibs são tags customizadas que podem ser utilizadas dentro
do código de uma página JSF. O código para utilização dos gráficos através da taglib dentro de uma
página JSF pode ser visto na Figura 35.
53
<fc:render xml="#{reportController.xml}" color="green" chartId="SimpleChart"
filename="/WebApplication1/resources/fusioncharts/Charts/FCF_Area2D.swf"
width="700" height="300">
</fc:render>
Figura 35. Trecho referente a um gráfico FusionCharts.
Observa-se na taglib a passagem do parâmetro XML que é onde são passados os dados para
a geração do gráfico conforme a Figura 36.
Figura 36. Gráfico gerado pelo componente FusionCharts.
O componente é bastante dinâmico, neste projeto foi utilizada uma versão gratuita do
componente, porém ele também pode ser comprado o que disponibiliza novos recursos e tipos de
gráficos.
54
5 APRESENTAÇÃO DO SISTEMA
Os módulos desenvolvidos são apresentados e descritos neste capítulo, tendo em vista as
principais regras de negócios definidas.
5.1 Aplicativo Servidor
A aplicação servidora é a principal interface do usuário com o sistema, para que o usuário
possa iniciar o monitoramento seja ele externo ou interno o primeiro passo a ser tomado é a criação
de uma conta (RF 1). Para iniciar-se o cadastro de uma conta deve-se clicar no link “Create
Account”, quando clicada esta opção o sistema abre uma tela de cadastro de contas conforme a
Figura 37.
Figura 37. Tela para cadastro de conta.
Após a criação da conta o usuário já está hábil para iniciar o monitoramento, logo após
entrar no sistema o usuário é direcionado para a aba “External Monitoring” onde visualizará os itens
que estão sendo monitorados externamente conforme a Figura 38.
55
Figura 38. Visualização de hosts que estão sendo monitorados externamente.
Esta tela centraliza todas as opções de monitoramento externo, nela é possível a visualização
do status dos hosts além da adição (RF 2), exclusão (RF 5), edição e geração de relatórios (RF 4)
para qualquer host.
A adição de um novo host a ser monitorado externamente é simples, basta o usuário clicar
no botão “Add External Monitor” e preencher os campos da tela, conforme Figura 39.
Figura 39. Adição de novo host para monitoramento externo.
Durante a adição de um novo host o campo “Port” só é preenchido quando o modelo de
monitoramento selecionado for igual a TCP, caso contrário não é necessário o preenchimento do
mesmo. O campo “Interval” é quem define o intervalo em minutos entre as verificações realizadas
pelo servidor, após o cadastramento o monitoramento é iniciado automaticamente sem a
necessidade de qualquer outra interação por parte do usuário.
Na aba de monitoramento interno o usuário encontra uma tela que contém todas as
informações monitoradas do host de maneira bem atrativa ao usuário, como utilização de CPU,
56
memória e unidades lógicas as informações mais detalhadas como todos os processos rodando no
host e suas respectivas cargas de memória e CPU podem ser vistas clicando-se na lupa, a tela pode
ser vista na Figura 40.
Figura 40. Listagem dos hosts que estão sendo monitorados internamente.
A adição de um novo host para monitoramento interno requer o download de um aplicativo
cliente, existem duas opções de aplicativos uma para Windows e outra pra Linux o download das
mesmas é realizado através do clique nos seus respectivos ícones conforme a Figura 41.
Figura 41. Download de aplicativo cliente.
A geração de relatórios tanto para hosts que estão sendo monitorados internamente e
externamente é realizada com um simples clique no ícone de gráfico de pizza, após isto o sistema
redireciona o usuário para a aba de relatórios com os parâmetros pré-definidos.
Na tela de relatórios são exibidas todas as anomalias que ocorreram para o host dentro do
período de data especificada pelo usuário assim como o gráfico de uptime do host. Na Figura 42
pode ser visto o relatório de monitoramento de um determinado host em um período de data
específico.
57
Figura 42. Relatório de monitoramento.
A aplicação servidora tem o dever de alertar o usuário em caso de qualquer anomalia que
venha a ocorrer em um dos hosts, este alerta é realizado através de um e-mail durante a detecção da
mesma informando ao usuário qual host está com problema e com qual tipo de problema.
5.2 Aplicativos Cliente
Os aplicativos cliente somente coletam os dados do host e enviam à aplicação servidora, a
única necessidade de interação do usuário com os aplicativos clientes é durante a instalação e
configuração dos mesmos. Após realizadas estas duas etapas o aplicativo cliente permanece
rodando em background como um serviço sem a necessidade de qualquer interação por parte do
usuário.
58
A instalação do aplicativo cliente para Windows possui uma interface gráfica bem simples
que é onde o usuário apenas define o diretório para instalação do sistema. Esta interface pode ser
vista na Figura 43.
Figura 43. Instalação do aplicativo cliente para Windows.
Após a etapa de instalação, serão gerados dois executáveis na pasta de destino netuno-
service.exe e netuno.exe. O aplicativo netuno-service.exe é correspondente ao serviço que roda em
background coletando os dados e enviando ao servidor, este pode ser visto na Figura 44, e o
aplicativo netuno.exe corresponde a interface de configuração do sistema que pode ser vista na
Figura 45.
Figura 44. Serviço do Sistema Netuno no Windows.
59
A primeira vez após a instalação é necessário que o usuário rode o aplicativo netuno.exe
para iniciar a etapa de configuração, para a configuração é somente necessário o preenchimento do
e-mail, senha e nome do host desejado conforme a Figura 45.
Figura 45. Configuração do sistema.
A etapa de configuração é necessário somente após a instalação do sistema onde o usuário
deverá executar o aplicativo netuno.exe e preencher os campos e-mail, senha e o nome do host
desejado.
O aplicativo cliente em Linux não possui interface gráfica como o aplicativo Windows, sua
interface é puramente em texto, a instalação é simples após descompactado o cliente devem ser
executados os seguintes comandos dentro da pasta de instalação.
1
2
3
4
5
6
cd /install_dir/netuno/
chmod 777 netuno
./netuno config
Nesta etapa serão informados email, senha e nome desejado para o host e será
gerado um arquivo de configuração.
Configurar o startup do aplicativo junto com o boot do sistema
echo “/install_dir/netuno/netuno” >> /etc/rc.local
./netuno
Figura 46. Instalação e configuração no Linux.
60
Após realizadas as etapas de instalação e configuração dos aplicativos clientes, não são mais
necessárias ações por parte do usuário junto aos aplicativos e o hosts configurados já estão sendo
monitorados e encontram-se disponíveis no painel da aplicação servidora.
5.2 Testes e Resultados
Após concluída a implementação da ferramenta, foram iniciados os testes a fim de
identificar falhas e melhorias nos processos envolvidos.
Os testes foram conduzidos em duas etapas, na primeira etapa foram realizados os testes de
monitoramento externo e na segunda os testes de monitoramento interno.
Foi criado um ambiente virtual de testes dentro de um mesmo computador através da
utilização de máquinas virtuais. Foram instaladas duas máquinas virtuais, uma com Windows 2003
e outra com a distribuição Linux CentOS ambas com 512 MB de memória e 5 GB de espaço em
disco.
Em cada uma das máquinas virtuais foi instalado um servidor HTTP e um servidor FTP,
foram escolhidas estas duas aplicações por serem as mais comuns e também pelas duas permitirem
que sejam realizados monitoramento HTTP e TCP respectivamente, o firewall em ambas as
máquinas virtuais foi desativado para permitir que a máquina pudesse responder a pacotes ICMP.
Nas máquinas virtuais foram também instalados seus respectivos aplicativos clientes para
permitir o monitoramento interno dos hosts, de recursos como CPU, Memória, Discos e Processos.
Os intervalos de tempo entre as verificações externas e internas foram definidos em um minuto, ou
seja, a cada minuto serão realizadas as devidas verificações e em caso de falhas o aplicativo
servidor deverá alertar o usuário através de um e-mail.
Após as duas máquinas instaladas e configuradas os itens que estarão sendo monitorados
nestes ambientes podem ser vistos na Tabela 2.
61
Tabela 2. Itens monitorados.
Host Windows 2003 Linux CentOS
Host Ativo SIM SIM
CPU SIM SIM
Memória SIM SIM
Unidades Lógicas SIM SIM
HTTP SIM SIM
TCP SIM SIM
PING SIM SIM
Intervalos de monitoramento 1 minuto 1 minuto
Pode-se visualizar através desta tabela que existem sete itens sendo monitorados, onde os
quatro primeiros correspondem ao monitoramento interno e os três últimos ao monitoramento
externo.
Todos os testes foram executados de maneira idêntica nas duas máquinas a fim de garantir
que a aplicação se comporte da mesma maneira nos dois ambientes propostos por este projeto.
Abaixo seguem os testes realizados:
1. Simulação de alto consumo de CPU. Foram executados diversos programas em ambos
os ambientes a fim de elevar o consumo de CPU acima de 95%.
2. Simulação de alto consumo de memória. Foram abertos vários programas ao mesmo
tempo a fim de esgotar a memória física disponível no sistema.
3. Simulação de disco cheio. Foi simulado o enchimento do disco através da duplicação de
arquivos dentro do HD.
4. Simulação de falha no serviço HTTP. Esta falha foi simulada através do desligamento do
servidor web.
5. Simulação de falhas do tipo TCP e ICMP. O firewall foi ativado com regras de bloqueio
para a porta 21 e para pacotes ICMP.
62
6. Simulação de host inativo. Para a simulação deste erro a máquina foi desligada.
Em todas as falhas ocorridas o sistema alertou o usuário corretamente, em algumas falhas
simuladas como as de o firewall ser ligado com regras específicas e a máquina ser desligada. Foi
enviado mais de um e-mail alertando o usuário da falha, isto porque em um ambiente real o usuário
pode estar monitorando somente um dos serviços e também porque a associação dos itens
monitorados externamente não é associada com o monitoramento interno, eles funcionam
paralelamente.
Durante a etapa de testes foi verificado que os alertas não podem ser disparados após a
primeira falha ou pelo tempo passar um pouco de um minuto, pois às vezes ocorrem atrasos nas
verificações de poucos segundos o que gera uma massa de e-mails desnecessária e inválida em
muitos casos, esta situação foi contornada dando-se um tempo extra de atraso antes do envio do
alerta.
De maneira geral os testes ocorreram conforme o previsto e a ferramenta mostrou-se
eficiente ao alertar o usuário em caso de falhas, porém alguns itens tiveram que ser reprogramados a
fim de tornar o sistema mais estável, principalmente com relação as rotinas de monitoramento
externo.
63
6 CONCLUSÕES
Este trabalho teve como objetivo desenvolver uma ferramenta de monitoramento remoto de
hosts que possa vir a ser comercializa no modelo de Software como Serviço.
A primeira fase deste projeto consistiu em um estudo de ferramentas de monitoramento
similares e das tecnologias que vieram a ser empregadas para a coleta das informações (Capítulo 2).
A segunda parte do projeto (Capítulo 3) consistiu em apresentar as regras de negócio, diagramas de
classe, diagrama entidade-relacional e a análise dos requisitos funcionais e não-funcionais para o
desenvolvimento do sistema.
Durante o processo de desenvolvimento do sistema foram necessárias algumas alterações no
projeto principalmente no modelo entidade-relacional. Algumas tecnologias escolhidas durante a
implementação tiveram que ser estudadas como o JSF e o Hibernate, as mesmas foram escolhidas
pelo fato de buscar-se empregar as melhores técnicas possíveis para que possa dar-se continuidade
ao desenvolvimento do sistema.
Do objetivo proposto para este projeto, o desenvolvimento de um software para
monitoramento que pudesse ser comercializado no modelo de SaaS, acredita-se que a ferramenta
tenha potencial para atingir o mercado de pequenas empresas, principalmente devido a facilidade de
uso da ferramenta. Mercados de médias e grandes empresas são inalcançáveis devido as limitações
da ferramenta se comparadas a outras ferramentas presentes no mercado.
Como trabalhos futuros algumas sugestões seriam: 1) o suporte a SNMP por parte dos
clientes para que eles possam monitorar todos os recursos da rede como impressoras, roteadores,
switches e enviar as informações ao servidor; 2) funcionalidades de acesso remoto através do
próprio painel da aplicação servidora; 3) na parte de monitoramento externo adicionar
funcionalidades de testes de sobrecarga, com simuladores de múltiplas conexões ao mesmo tempo
entre outros e 4) permitir que os aplicativos clientes coletem logs de outras aplicações como
servidores web, e-mail, arquivos e outros.
REFERÊNCIAS BIBLIOGRÁFICAS
BOVET, D.; CESATI M. Understanding the linux kernel 3rd edition. Sebastopol: O´ Reilly Media Inc, 2005. COMER, D. Redes de computadores e internet. Porto Alegre: Bookman, 2007. FSU COMPUTER SCIENCE. gSOAP: SOAP C++ Web Services. Disponível em: <http://www.cs.fsu.edu/~engelen/soap.html>. Acesso em 15 abr. 2010. GRESCHLER, D.; MANGAN, T. Networking lessons in delivering ‘Software as a Service’ – Part I. International Journal of Network Management. California: John Wiley & Sons, Ltd. 2002. Disponível em: <http://www.acm.org> Acesso em: 20 out. 2009. JONES, M. Kernel command using linux system calls. 2007. Disponível em: <http://www.ibm.com/developerworks/linux/library/l-system-calls/#N10241> Acesso em: 15 out. 2009. KING, G. History – Hibernate – Jboss Community. 2010. Disponível em: <http://www.hibernate.org/about/history.html>. Acesso em 05 mai. 2010.
LOGMEIN. Quem somos. 2009. Disponível em: <https://secure.logmein.com/BR/about/aboutus.aspx>. Acesso em 01 dez. 2009. UPTRENDS. About us. 2009. Disponível em: < http://uptrends.com/html/en/aboutus.html>. Acesso em 01 dez. 2009. LOVE, R. Linux system programming. Sebastopol: O´ Reilly Media Inc, 2005. STALLINGS, W. Redes e sistemas de comunicação de dados. Rio de Janeiro: Elsevier, 2005. SUN. JavaServer Faces Technology – The Java EE 5 Tutorial. 2010. Disponível em: <http://java.sun.com/javaee/5/docs/tutorial/doc/bnaph.html>. Acesso em 08 mai. 2010. SUN. Overview of SOAP. 2010. Disponível em: <http://java.sun.com/developer/technicalArticles/xml/webservices/>. Acesso em 02 mai. 2010. TUNSTALL, D.; COLE, G. Developing WMI solutions. Boston: Addison-Wesley Professional, 2002.