Breno Wruck Schneider. Visualização de Dados aplicada ao Gerenciamento de Redes

Transcrição

1 Breno Wruck Schneider Visualização de Dados aplicada ao Gerenciamento de Redes Vitória - ES, Brasil 19 de abril de 2012

2 Breno Wruck Schneider Visualização de Dados aplicada ao Gerenciamento de Redes Monografia apresentada para obtenção do Grau de Bacharel em Ciência da Computação pela Universidade Federal do Espírito Santo. Orientador: Magnos Martinello Co-orientador: Rafael Emerick Zape de Oliveira DEPARTAMENTO DE INFORMÁTICA CENTRO TECNOLÓGICO UNIVERSIDADE FEDERAL DO ESPÍRITO SANTO Vitória - ES, Brasil 19 de abril de 2012

3 Monografia de Projeto Final de Graduação sob o título Visualização de Dados aplicada ao Gerenciamento de Redes, defendida por Breno Wruck Schneider e aprovada em 19 de abril de 2012, em Vitória, Estado do Espírito Santo, pela banca examinadora constituída pelos professores: Prof. Dr. Magnos Martinello Orientador Prof a. Dr a. Roberta Lima Gomes Universidade Federal do Espírito Santo Rafael Emerick Zape de Oliveira Universidade Federal do Espírito Santo

4 Resumo O objetivo deste trabalho é desenvolver uma visualização de dados simples, eficiente e interativa de uma rede de computadores. A motivação deste trabalho surgiu devido a algumas deficiências no modelo já utilizado pelo Ponto de Presença da RNP no Espírito Santo, principalmente na identificação de possíveis problemas nos enlaces dessa rede. Para o desenvolvimento dessa nova visualização, foi utilizada a API Google Chart Tools baseada no modelo Treemap. Para atingir o objetivo, foi desenvolvida uma página web dinâmica e interativa, gerada através de arquivos XML, para obter as informações acerca da rede, arquivos RRD, que possuem informações das métricas dos enlaces em tempo real, e com um arquivo JSON, que foi criado para fazer a interação entre o código java, linguagem usada na leitura dos arquivos XML e RRD, e o código Javascript, linguagem usada pela API Google Chart Tools, que é responsável pela geração do modelo de visualização Treemap.

5 Abstract The goal of this work is to develop a simple, efficient and interactive data visualization of a computer network. The motivation to do it is due to some deficiencies in the model used by the Ponto de Presença da RNP no Espírito Santo, mainly on the identification of possible problems with network links. In order to develop this new visualization, the Google Chart Tools API was used based on the Treemap visualization model. To achieve the objective, a dynamic web page was developed, which was generated through XML files, to obtain information about the computer network, RRD files, that contain information about the metrics, and with a JSON file, which was created to do the communication between the Java code, programming language used to read the XML and RRD files, and the Javascript code, language used by the Google Chart Tools API, which is responsible to generate the Treemap.

6 Dedicatória Dedico este trabalho a todas as pessoas que me ajudaram e estiveram comigo durante os anos de estudo na Universidade Federal do Espirito

7 Agradecimentos Agradeço, primeiramente, ao meu orientador Magnos Martinello e meu coorientador Rafael Emerick Zape de Oliveira que me propuseram este trabalho e me ajudaram sempre que disponíveis. Ao meu irmão e mestre Hugo Wruck Schneider que me deu todas as diretivas e conhecimento para que este trabalho fosse concluido. Ao meu amigo Ygor Kiefer F. de Jesus que me ajudou sempre que possível em diversos passos deste trabalho. Por último, à minha familia, que ao longo de toda a minha caminhada como estudante, esteve comigo.

8 Sumário Lista de Figuras 1 Introdução p Objetivo deste trabalho p Estrutura da monografia p Fundamentação Teórica p Rede de Computadores p Gerenciamento de Redes p Visualização de Dados p Trabalhos Relacionados p Many Eyes p Visualizing Network Data p The Evolution of Privacy on Facebook p Tecnologias utilizadas neste trabalho p XML (Extensible Markup Language) p RRD e RRDtool p Servlet p JSON p Google Chart Tools p Treemap p Visualização de dados aplicada ao gerenciamento de redes p. 30

9 3.1 Panorama POP-ES p Proposta de Solução p Etapas para a solução proposta p O desenvolvimento p Preenchimento de um arquivo de configuração no formato XML... p Leitura de um arquivo configuração no formato XML p Leitura dos arquivos, especificados, no formato RRD p Geração do documento de intercâmbio, no formato JSON p Leitura do documento de intercâmbio, no formato JSON p Geração da visualização final p Solução alternativa p Validação da proposta baseada em testes p Descrição dos testes p Quando vários enlaces se tornam inativos p Quando vários enlaces possuem métricas com valores desconhecidos p Quando há vários enlaces problemáticos p Conclusão e Trabalhos futuros p Trabalhos Futuros p. 56 Referências Bibliográficas p. 58

10 Lista de Figuras 2.1 Visualização de Dados: Exemplos de Visualizações [Illinsky 2010] p Projeto Many Eyes: Exemplos de Visualizações [Viegas et al. 2007]..... p Mapa de Enlaces (Link Map) [Becker, Eick e Wilks 1995] p Mapa de Nós (Node Map) [Becker, Eick e Wilks 1995] p The Evolution of Privacy on Facebook: Timeline Visualization [Mckeon 2010] p Exemplo de um arquivo XML p Exemplo de um arquivo XML contendo um atributo p Páginas Web Dinâmicas [Murach e Steelman 2008] p Estrutura de um Servlet simples que retorna um documento HTML p Exemplo de um arquivo JSON [JSON Examples 2012] p Estruturas presentes num arquivo JSON [JSON Introduction 2012] p Google Chart Tools: exemplos de visualizações p Treemap: US Obesity by State and County (2008) p Panorama: POP-ES [Panorama do Tráfego: POP-ES 2012] p Conclusão dos dois primeiros passos p Conclusão dos três primeiros passos p Conclusão dos quatro primeiros passos p Etapas do Projeto p Inicio do Arquivo de Configuração XML p Forma como é preenchida uma interface no arquivo de configuração XML.. p O arquivo input.properties p Representação dos enlaces (primeiro nível) p. 45

11 3.10 Representação dos enlaces (segundo nível) p Representação dos enlaces (terceiro nível) p Treemap com 2 níveis de profundidade p Dois enlaces inativos ao mesmo tempo p Dois enlaces inativos ao mesmo tempo (corrigido) p Métricas com valores desconhecidos p Métricas com valores desconhecidos (segundo nível) p Muitos enlaces com problema p. 54

12 11 1 Introdução A quantidade de dados e informações coletadas mantidas por organizações e empresas está constantemente crescendo, devido à automatização das transações e avanços na tecnologia de armazenamento. Além disso, vários atributos são registrados, resultando em conjuntos de dados multi-dimensionais [Michailidis 2008]. Para extrair informações úteis de um conjunto de dados grande e estruturado, o primeiro passo é visualizar a sua estrutura, identificando padrões, tendências e relações complexas entre os itens. O objetivo da exploração visual dos dados é produzir uma representação de tal maneira que um ser humano possa ter a visão da estrutura e padrões [Eick e Willis 1993]. Os gráficos são entidades úteis, pois podem representar relações entre conjuntos de objetos. Eles são usados para modelar sistemas complexos (redes de computadores e transportes, layouts de sites, moléculas, etc.) e para visualizar relações (redes sociais, diagramas entidade-relacionamento em sistemas de banco de dados, etc.) Os gráficos são, também, objetos matemáticos muito interessantes, e tem se prestado muita atenção às suas propriedades. As várias formas de se visualizar um gráfico provêm percepções e, frequentemente, relações escondidas. Além disso, padrões interessantes são revelados [Michailidis 2008]. As informações baseadas em gráficos estão presentes no dia a dia de um centro de operação e gerência de redes de computadores. No entanto, estas informações são monitoradas por meio de um amplo conjunto de variáveis que são coletadas e representadas de várias maneiras e geralmente estão distribuídas em múltiplos lugares. Assim, apesar de um gerente de rede dispor de um conjunto refinado de variáveis para monitoramento do estado da rede, o número de variáveis é tão grande, que pode levar ineficiência e confusão à gerência de rede. Logo, é fundamental que estas informações sejam estruturadas e sintetizadas para serem apresentadas em um painel único, de tal modo que o gerente possa encontrar com eficiência e precisão as variáveis relevantes para o diagnóstico do problema. Esse é o problema central que será tratado nesta monografia. Segundo [Pras et al. 2007], apesar da visualização e análise de dados ser um tópico relati-

13 1 Introdução 12 vamente antigo, as técnicas atualmente disponíveis e as interfaces para os operadores de rede não são satisfatórias por algumas razões: As representações topológicas tradicionais, especialmente baseadas em mapas geográficos, não se comportam bem com o crescimento do número de redes e seus elementos Conjuntos de dados de medição e estatísticas geralmente são visualizados de maneira estática. Atualmente, há um suporte muito limitado (quando existe) para explorar os conjuntos de dados de maneira interativa Visualizações de tráfego normalmente focam na visualização de um grande volume de componentes de tráfego e seu fluxo. Isso certamente é útil, porém há um crescente necessidade de extrair e evidenciar o comportamento anormal do tráfego e seus padrões Grande parte das ferramentas existentes são desenvolvidas para análise e visualização offline. Atualmente, há uma crescente necessidade de ferramentas online, próximo à análise e visualizações em tempo real com o objetivo de redução o tempo de detecção e reação

14 1.1 Objetivo deste trabalho Objetivo deste trabalho O objetivo deste trabalho é o desenvolvimento de uma imagem única e interativa que leve em conta todas as métricas envolvidas em uma rede de computadores composta por diversos enlaces, cuja principal função é possibilitar a transferência de informações entre os computadores que estão nessa rede. Sendo assim, ao analisar a representação de um determinado enlace, será possível dizer com certeza se o mesmo está funcionando dentro da faixa máxima estipulada para cada uma das métricas informadas (taxa de erros, número de pacotes enviados, tráfego, etc.). Desta forma, será possível enxergar se há um problema apenas analisando a representação inicial. Vale frisar que o objetivo desse trabalho não é resolver os problemas em si, mas sim informar de forma rápida e simples onde está o problema. Os fatores citados por [Pras et al. 2007] na seção 1 contribuiram significativamente na motivação para a o desenvolvimento desse trabalho. O objetivo citado anteriormente, bem como a proposta de de solução que será explicada em capítulos futuros, foram elaborados levando em consideração todos esses fatores. 1.2 Estrutura da monografia Este trabalho é dividido em capítulos. Além deste capítulo, essa monografia é composta do capítulo de Revisão Teórica, que são os conceitos necessários para total entendimento desse trabalho, bem como alguns trabalhos no campo visualização de dados. O trabalho é apresentado de forma detalhada no capítulo Visualização de Dados aplicada ao gerenciamento de redes. Logo após, há um capítulo contendo os testes de validação. Para finalizar, o último capítulo contém a conclusão e trabalhos futuros.

15 14 2 Fundamentação Teórica Esse capítulo fornece o conhecimento necessário para o entendimento do trabalho. Inicialmente, será explicado o conceito de Visualização de Dados e alguns trabalhos relacionados serão discutidos. Em seguida, serão apresentadas as tecnologias utilizadas no desenvolvimento desse trabalho. 2.1 Rede de Computadores A fusão entre computadores e comunicação tem exercido grande influência na maneira em que sistemas de computadores são organizados. O modelo em que um único computador cobre toda a necessidade computacional da empresa foi substituído por um sistema em que vários computadores estão separados fisicamente mas interconectados entre si para suprir tal necessidade. Esses sistemas são chamados de redes de computadores [Tanenbaum 2003]. Uma rede de computadores também pode significar um grupo de computadores autônomos interconectados por uma única tecnologia. Dois computadores são ditos interconectados se eles são capazes de trocar informação entre si [Tanenbaum 2003]. Um outro propósito de uma rede de computadores é o compartilhamento de recursos. Dessa forma, programas, equipamentos e especialmente a informação estarão disponíveis para qualquer usuário que pertence à rede sem considerar a localização física dos recursos e dos usuários [Tanenbaum 2003]. O uso das redes de computadores vem, a cada dia, se tornando um recurso indispensável em todos os locais onde existe um conjunto de computadores. Com o crescimento da Internet abrangendo todos os ramos de atividade, aumentou ainda mais a necessidade da ligação dos computadores em redes [Mendes 2007]. Segundo [Mendes 2007], há algumas vantanges no uso de redes, como: Compartilhamento de Programas: Os computadores podem acessar programas local-

16 2.1 Rede de Computadores 15 izados no disco rígido de outros computadores, evitando o desperdício de espaço local e padronizando a versão do programa em uso Compartilhamento de acesso à Internet: Mesmo quando se tem apenas um modem para acesso à Internet é possível compartilhar esta conexão na rede. Assim, vários usuários estarão habilitados a acessá-la por meio de uma única conexão No entanto, para que as redes de computadores funcionem corretamente, é preciso ter um nível de tráfego satisfatório e confiável para dados e aplicações e a garantia determinados níveis de desempenho (medidos por métricas) quanto à sua utilização e performance. Dentre as várias métricas definidas para medir o desempenho de uma rede, podemos citar: Tráfego: quantidade de dados, em bits por segundo, transmitida na rede Taxa de descartes (ou perdas): quantidade de pacotes perdidos por segundo em relação ao total de pacotes enviados através da rede Taxa de erros: quantidade de transmissões com erro, por segundo, em relação ao total de transmissões Latência: tempo total, em milissegundos, entre o envio e a recepção de um pacote através da rede Gerenciamento de Redes As redes de computadores precisam ser gerenciadas (ou monitoradas) com o intuito de garantir sua qualidade. Gerenciamento de rede consiste em atividades, métodos, procedimentos e ferramentas que pertencem à operação, administração, manutenção e provisionamento de sistemas em rede [Clemm 2007]. Operação lida com a preservação da rede (e os serviços que ela provê) em estado ativo e funcionando corretamente Administração envolve manter o controle dos recursos e como eles são atribuídos Manutenção consiste em realizar reparos e atualizações na rede, caso necessário Provisionamento diz respeito à configuração de recursos na rede para suportar os serviços

17 2.2 Visualização de Dados 16 Segundo [Kurose e Ross 2009], há alguns cenários em que um gerenciador (ou administrador) de rede pode ser benefiado tendo ferramentas adequadas para o gerenciamento de redes: Detecção de falha de uma interface da rede: uma entidade da rede pode relatar que uma de suas interfaces está inativa. Além disso, um gerenciador de rede que monitora e analisa o tráfego da rede pode detectar futuros problemas em uma interface detectando anomalias no tráfego, por exemplo. Como solução, um componente de hardware dessa interface pode ser trocado antes que o enlace se torne inativo, por exemplo. Monitoramento dos hosts: um gerenciador de rede pode verificar se todos os hosts da rede estão ativos e funcionando corretamente O trabalho descrito nessa monografia visa facilitar o trabalho de responsáveis pelo gerenciamento de redes identificando e informando por meio de imagens o estado da rede com base em suas métricas. Inicialmente, foi estudada a área de Visualização de Dados visando encontrar a melhor forma de representar todas as informações necessárias. 2.2 Visualização de Dados Visualização de dados é o estudo da representação visual dos dados, definidos como informações que podem ser abstraídas de forma esquemática, incluindo atributos ou variáveis das unidades de informação [Friendly 2009]. O principal objetivo de visualização de dados é comunicar a informação de forma clara e eficiente através de gráficos [Friedman 2008]. A chave para o sucesso de qualquer visualização é prover acesso à informação de tal forma que o usuário ganhe conhecimento. Devido à maior importância desse fator, a habilidade de transmitir informação deve ser a orientação primária do design de uma visualização. Uma visualização deve ter um objetivo claro, uma mensagem, ou uma perspectiva particular na informação que é projetada para transmitir. O acesso à essa informação deve ser o mais simples possível, sem sacrificar qualquer complexidade a respeito [Illinsky 2010]. A grande maioria de visualizações de informação é feita completamente em formatos padrão, estilos básicos de apresentação como barras (figura 2.2), linhas, dispersão, gráficos de pizza e fluxogramas. Esses formatos são onipresentes e fornecem pontos de partida convenientes e convencionais. As suas teorias são razoavelmente bem compreendidas tanto por parte do criador da visualização como do leitor [Illinsky 2010].

18 2.2 Visualização de Dados 17 Figura 2.1: Visualização de Dados: Exemplos de Visualizações [Illinsky 2010] Há duas razões principais para usar gráficos no intuito de exibir conjuntos de dados: explorar ou apresentar a informação. A apresentação de dados envolve decidir que informações serão transmitidas e representar o conteúdo de forma apropriada para um determinado público. É necessário pensar acerca de como a representação será interpretada e quando será entendida da forma desejada. Parcelas que são comuns a um tipo de aplicação podem ser incomuns para alguns leitores. Por conta disso, muito cuidado deve ser tomado ao preparar a apresentação mais adequada [Unwin, Chen e Hardle 2008].

19 2.3 Trabalhos Relacionados Trabalhos Relacionados Many Eyes Many Eyes é um site público em que usuários podem enviar dados, criar visualizações interativas e debater sobre os dados e visualizações. O objetivo do site é apoiar o uso visualizações em larga escala promovendo um estilo social de análise de dados em que as visualizações não servem apenas para apresentar a informação, mas também como um meio para estimular o debate entre os usuários [Viegas et al. 2007]. O projeto Many Eyes é inspirado em sites participativos bem conhecidos, tais como o Flickr e o YouTube. As atividades principais do site são envio de dados, construir visualizações e comentar sobre conjuntos de dados ou visualizações [Viegas et al. 2007]. Upload de conjuntos de dados Os usuários enviam informações via formulário HTML (Hypertext Markup Language). O formulário contem uma área de texto, em que o usuário pode colar seu conjunto de dados. A informação pode ser um texto puro, que será interpretada como dado não estruturado, ou uma grade delimitada por tabulação, que será interpretada como uma tabela [Viegas et al. 2007]. Conjunto de Dados Para cada conjunto de dados enviado, é dada uma página. Essa página contém metadados, um trecho do conjunto de dados e um fórum de discussões em que os usuários possam conversar sobre a informação [Viegas et al. 2007]. Visualização de Dados O Many Eyes se baseia no modelo web para que atinja o maior público possível. As visulizações tem existido há mais de uma década, mas elas foram construidas offline e, depois, publicadas separadamente na Internet. Utilizando o Many Eyes, as visualizações podem ser construidas e publicadas utilizando apenas o navegador [Viegas et al. 2007]. O projeto provê mais de uma dúzia de diferentes tipos básicos de visualizações 2.2. O menu inclui um misto de gráficos corporativos padrões (como o gráfico de barras), técnicas acadêmicas bem estabelicidas (Treemap) e alguns componentes experimentais, tais como o gráfico de bolhas [Viegas et al. 2007].

20 2.3 Trabalhos Relacionados 19 O projeto Many Eyes é aberto ao público, o que significa que qualquer usuário pode fazer o cadastro no próprio site e utilizar os recursos que o projeto provê. Figura 2.2: Projeto Many Eyes: Exemplos de Visualizações [Viegas et al. 2007] Visualizing Network Data Visualizing Network Data é um trabalho feito Richard A. Becker, Stephen G. Eick, Allan R. Wilks no ano de O foco desse trabalho é visualizar as informações da rede. O objetivo é entender a informação e não a rede propriamente dita. Em outras palavras, os dados associados com os enlaces (links) e os nós precisam ser entendidos. Para redes de comunicação, perguntas importantes envolvem o tamanho do fluxo, a capacidade dos enlaces, utilização dos enlaces e dos nós e variação com o tempo [Becker, Eick e Wilks 1995]. Segundo [Becker, Eick e Wilks 1995], um desafio ao visualizar as informações da rede é lidar com o volume de dados - redes podem ter centenas ou milhares de nós e enlaces e dados de vários períodos de tempo. Os três métodos usados normalmente para reduzir a quantidade de informação para um tamanho gerenciável são: Para um número grande de enlaces ou nós, agregação Para um número grande de períodos de tempo, aplicar médias Para detecção de mudanças, limiarizar e reportar exceções Os gráficos, particularmente mapas de rede, tem sido reconhecidos como uma ferramenta crucial para análise de dados de rede. No entanto, gráficos, mesmo sendo executados por

21 2.3 Trabalhos Relacionados 20 poderosos sistemas, podem se tornar sobrecarregados e ocupados quando lidam com enormes rede e volumes de dados [Becker, Eick e Wilks 1995]. Nesse trabalho, são apresentadas formas de visualizar (ou representar) redes de computadores. Dentre elas, podemos citar: Mapa de Enlaces (Link Map) Uma forma de exibir informação de enlaces em um mapa é desenhar segmentos de linha entre cada par de nós para os quais há troca de informações. Essa representação exibe a conectividade da rede. Para informar os valores de um enlace, os segmentos podem ser coloridos ou desenhados com largura variável. Levando em conta que a informação do enlace normalmente é direcional, é possível exibir informação em ambas as direções utilizando setas, por exemplo [Becker, Eick e Wilks 1995]. Figura 2.3: Mapa de Enlaces (Link Map) [Becker, Eick e Wilks 1995] Mapa de Nós (Node Map) A ideia incorporada em um mapa de nós é exibir a informação orientada pelo nó mostrando um glifo ou símbolo, como um círculo ou quadrado em cada nó do mapa, com características

22 2.3 Trabalhos Relacionados 21 visuais, tais como tamanho, forma e cor. Além disso, símbolos mais complexos podem ser usados para representar mais de uma estatística simultaneamente. Figura 2.4: Mapa de Nós (Node Map) [Becker, Eick e Wilks 1995] The Evolution of Privacy on Facebook Introdução O Facebook nem sempre gerenciou bem as informações dos usuários. No início, o Facebook restringiu a visibilidade das informações pessoais apenas aos amigos e sua rede (universidade ou escola). Com o passar dos anos, as configurações padrão de privacidade de informações pessoais de um usuário do Facebook se tornaram cada vez mais tolerantes. O Facebook também mudou diversas vezes a forma como as informações pessoais são classificadas, chegando a fazê-lo de uma forma confusa para o usuário. Um grande esforço tem sido feito pelo Facebook para correlacionar, publicar e monetizar seus gráficos sociais: um gigantesco banco de entidades que cobre tudo, desde onde o usuário vive até filme que gosta e pessoas que confia [Mckeon 2010]. Um post feito por Kurt Opsahl na EFF (Electronic Frontier Foundation) dá um breve crono-

23 2.3 Trabalhos Relacionados 22 grama das mudanças nos Termos de Serviço do Facebook até abril de 2010 [Mckeon 2010]. Figura 2.5: The Evolution of Privacy on Facebook: Timeline Visualization [Mckeon 2010] Os Dados Os dados desse gráfico (figura 2.5) foram derivados de uma interpretação acerca dos Termos de Serviço do Facebook no passar dos anos, juntamente com a memória pessoal de Matt Mckeon acerca das configurações padrão de privacidade das classes diferentes de dados pessoais. O tamanho da população provém de estatísticas do Google, a equipe de dados do Facebook e estimativas sensatas de Matt Mckeon [Mckeon 2010].

24 2.4 Tecnologias utilizadas neste trabalho Tecnologias utilizadas neste trabalho XML (Extensible Markup Language) XML é uma linguagem de marcação - usa tags para rotular, categorizar e organizar a informação de uma forma específica. Essa linguagem não é limitada a um conjunto particular de tags - o usuário pode criar seu próprio conjunto de marcações para adaptá-la às necessidades de informações e documentos. A flexibilidade do XML levou à sua ampla utilização em múltiplas formas na troca de dados [L. e Tittel 2005]. Dentre os vários benefícios desta linguagem, há fato de que a informação é automaticamente separada do contexto (apresentação). Um arquivo XML por si só não inclui instruções sobre como a informação será exibida, pois o arquivo apenas define a estrutura da informação [L. e Tittel 2005]. Figura 2.6: Exemplo de um arquivo XML Arquivos XML podem ter atributos, assim como arquivos HTML. Atributos provêem informações adicionais acerca dos elementos e sempre precisam ser citados.

25 2.4 Tecnologias utilizadas neste trabalho 24 Figura 2.7: Exemplo de um arquivo XML contendo um atributo Arquivos XML não são específicos de nenhuma plataforma ou linguagem de programação. Suponha que o usuário queira trocar as informações de um banco de dados através da Internet. Para completar essa tarefa, é necessário um formato de documento que seja Extensível (um formato extensível é aquele que pode ser adaptado ou moldado para aplicações específicas), aberto (bem documentado e disponível em larga escala) e não proprietário (o padrão de notação não é propriedade exclusiva de qualquer pessoa, empresa, ou organização) [L. e Tittel 2005] RRD e RRDtool RRDtool (Round-robin Database Tool) é um software livre desenvolvido por Tobias Oetiker. Este software é projetado para armazenar séries temporais de dados. A cada atualização de dados, um timestamp (tempo exato em que a atualização ocorreu) associado é armazenado. O tempo é sempre expresso em segundos passados desde a data (01/01/1970). Outras bases de dados definem tabelas com colunas e vários outros parâmetros. Essas definições podem ser muito complexas, especialmente em bancos de dados robustos [Patel 2011]. Bancos de dados RRD são usados, primariamente, para monitoramento, tendo uma estrutura muito simples. Os parâmetros que precisam ser definidos são variáveis que armazenam valores e valores arquivados. Como o banco de dados é sensível ao tempo, alguns parâmetros relacionados ao tempo também são definidos [Patel 2011]. A definição de um banco de dados RRD inclui, também, um fornecimento para especificar ações a tomar, na ausência de valores de atualização. Data Source (DS), Heartbeat, Data Source Type (DST), Round Robin Archive (RRA) e Consolidation Function (CF) são algumas terminologias relacionadas a bancos de dados RRD [Patel 2011].

26 2.4 Tecnologias utilizadas neste trabalho Servlet Um Servlet é uma classe da linguagem de programação Java para extender as capacidades de servidores que hospedam aplicações acessadas via requisição-resposta. Embora servlets possam responder a qualquer tipo de requisição, normalmente são usados para extender as aplicações hospedadas por servidores web. Para tais aplicações, a tecnologia Servlet Java define, especificamente, uma classe servlet HTTP [Java Sun: Java Servlet Technology 2012]. Figura 2.8: Páginas Web Dinâmicas [Murach e Steelman 2008] Segundo [Murach e Steelman 2008], quando um servidor web recebe uma requisição para uma página web dinâmica, o servidor transfere a requisição para a aplicação web. Em seguida, a aplicação gera uma resposta que, normalmente, é um arquivo HTML e a retorna para o servidor. Feito isso, o servidor encapsula o documento HTML gerado na resposta HTTP e o envia de volta para o navegador. Figura 2.9: Estrutura de um Servlet simples que retorna um documento HTML Na prática, todos os servlets extendem a classe HttpServlet. Para extender essa classe, o servlet precisa importar os pacotes java.io, javax.servlet e javax.servlet.http. O método doget do Servlet Java substitui o método doget da classe HttpServlet e processa todas as requisições HTTP que usam o método Get. Analogamente, o método dopost do Servlet Java substitui o

27 2.4 Tecnologias utilizadas neste trabalho 26 método dopost da classe HttpServlet e processa todas as requisições HTTP que usam o método Post. Os métodos doget e dopost do Servlet Java usam dois objetos que são passados a eles pelo servidor web: o objeto HttpServletResquest e o objeto HttpServletResponse, respectivamente. O Servlet Java não precisa necessariamente retornar uma página HTML. É possível retornar, por exemplo, um arquivo XML ou JSON (JavaScript Object Notation), usando as devidas bibliotecas Java. O Servlet não precisa saber o que vai acontecer com a resposta que foi gerada. Sua função é apenas realizar o processamento pertinente à requisição que lhe foi enviada JSON JSON (JavaScript Object Notation) é um formato de troca de dados leve. É fácil tanto para os seres humanos lerem e escreverem quanto para máquinas analisarem e gerarem. Ele é baseado em um subconjunto da linguagem de programação Javascript e Standard ECMA- 262, 3 a Edição - Dezembro de JSON é completamente independente de linguagem, mas usa convenções que são familiares aos programadores da família C de linguagens, incluindo C, C++, C#, Java, Javascript, Perl, Python e muitos outros [JSON Introduction 2012]. Segundo [JSON Introduction 2012], JSON é construído em duas estruturas: 1. Uma coleção de pares nome/valor. Em muitas linguagens, isso é interpretado como um objeto, gravação, estrutura, dicionário, tabela hash, lista encadeada ou vetor associativo. 2. Uma lista ordenada de valores. Em muitas linguagens, isso é interpretado como uma lista, vetor ou sequência. Figura 2.10: Exemplo de um arquivo JSON [JSON Examples 2012]

28 2.4 Tecnologias utilizadas neste trabalho 27 Segundo [JSON Introduction 2012], arquivos JSON são compostos das seguintes estruturas: Objeto(Object): um conjunto não ordenado de pares nome/valor. Um objeto inicia com { e termina com }. Cada nome é seguido de e os pares nome/valor são separados por vírgula Vetor (Array): um conjunto ordenado de valores. Um vetor inicia com [ e termina com ]. Os valores são separados por vírgula Valor(Value): Podem ser uma string entre aspas, um número, um valor booleano (verdadeiro ou falso), vazio(null), um objeto ou um vetor Figura 2.11: Estruturas presentes num arquivo JSON [JSON Introduction 2012]

29 2.4 Tecnologias utilizadas neste trabalho Google Chart Tools Google Chart Tools é uma API de Visualização de Dados. Seu código é aberto e de uso gratuito. A ferramenta fornece uma gama de tipos de gráficos prontos para uso e ainda é possível adaptar facilmente o gráfico a um site. Além disso, os gráficos são altamente interativos [Google Chart Tools: Introduction to Using Chart Tools 2012]. Os gráficos são expostos como classes JavaScript e todos eles são preenchidos usando a classe Javascript DataTable, que é comum a todos. Devido à essa propriedade, é muito simples trocar de um gráfico para outro. Para o uso dessa ferramenta não é necessário qualquer instalação ou adição de um plugin em seu navegador [Google Chart Tools: Introduction to Using Chart Tools 2012]. A API provê muitas formas de visualização: de gráficos mais simples como o gráficos de colunas, bolhas e de área a gráficos mais complexos, como o Treemap, a tabela mágica (Magic Table) e gráfico com animação (Motion Chart). Figura 2.12: Google Chart Tools: exemplos de visualizações Treemap O método de visualização Treemap mapeia informações hierarquicas numa imagem retangular bidimensional de uma maneira que preencha o espaço. Todo o espaço disponível para a imagem é utilizado. Além disso, controles interativos permitem que usuários especifiquem a apresentação da informação (mapas de cores, por exemplo) e da estrutura (limite de profundidade, por exemplo). Tais fatores contrastam com os tradicionais métodos estáticos, que geralmente não usam todo o espaço disponivel ou escondem grande quantidade de informação [Shneiderman e Johnson 1993].

30 2.4 Tecnologias utilizadas neste trabalho 29 Segundo [Shneiderman e Johnson 1993], o desenho dos nós dentro de seus retângulos delimitados é totalmente dependente do conteúdo dos nós e podem ser controlados interativamente. Ainda de acordo com [Shneiderman e Johnson 1993], os principais objetivos do design do método de visualização Treemap são: Eficiência do espaço utilizado: O uso do espaço de forma eficiente é essencial ao exibir grandes estruturas de dados Interatividade: Controle da interatividade sobre a apresentação da informação e um feedback em tempo real são essenciais Compreensão: O método de apresentação e seu feedback interativo devem facilitar a rápida extração de informação com baixas cargas cognitivas e baixo esforço Estética: O desenho e o feedback devem ser esteticamente agradáveis Estruturas de informações hierárquicas possuem dois tipos de informação: informação estrutural associada à hierarquia e conteúdo associado a cada nó. Treemaps são capazes de representar tanto a estrutura quanto o conteúdo da hierarquia. Além disso, esse método de visualização fornece uma visão global de toda a hierarquia, tornando mais fácil a navegação através dela [Shneiderman e Johnson 1993]. Figura 2.13: Treemap: US Obesity by State and County (2008)

31 30 3 Visualização de dados aplicada ao gerenciamento de redes Neste capítulo, será explicado detalhadamente o projeto e como ele foi desenvolvido. Porém, antes dessas explicações, serão apresentadas as motivações para o desenvolvimento deste projeto, bem como sua proposta de solução. 3.1 Panorama POP-ES A figura 3.1 representa a topologia da rede composta pelas entidades POP-ES, Universidade Federal do Espirito Santo, Universidade Emescam, entre outras. Para cada enlace, é informado a quantidade de dados transferidos nos dois sentidos numa determinada fatia de tempo, bem como uma barra ao final da imagem indicando uma faixa de cores juntamente com a porcentagem do tráfego máximo que ela representa. Além disso, se a conexão entre duas entidades não estiver funcionando, tal enlace é mostrado na cor cinza. Por trás desse panorama, há gráficos (gerados pelo RRDTool) que informam, para cada enlace, dados como número de pacotes enviados, taxa de erros, número de pacotes perdidos, latência, entre outros.

32 3.2 Proposta de Solução 31 Figura 3.1: Panorama: POP-ES [Panorama do Tráfego: POP-ES 2012] À primeira vista, podemos achar que essa representação informa que toda essa topologia está funcionando perfeitamente. No entanto, vale ressaltar que o padrão de cores informado só leva em consideração a informação de carga do tráfego. Se olharmos para essa visualização global, não é possível saber se todos os enlaces estão tendo muitos ou poucos erros ou se pacotes estão sendo perdidos. Para verificar essas informações, demandaria tempo, pois as métricas citadas acima são informadas através dos gráficos em segundo plano. Para evidenciar a falta de informação nessa representação, vamos supor que um determinado enlace é mostrado na cor verde. Se a taxa de erros estiver muito alta, a representação continuaria verde e, para os olhos do examinador, tudo estaria funcionando corretamente, ou seja, haveria um problema que não seria detectado na primeira análise da figura. Em suma, toda informação que não estiver relacionada à utilização do enlace (tráfego passante) não será visualizada pelo gerenciador de rede. 3.2 Proposta de Solução A proposta de resolução do problema citada na seção e 3.1 e desafios citados por [Pras et al. 2007] na seção 1 é o desenvolvimento de uma página web dinâmica e interativa que contém uma representação gerada em tempo real de todos os enlaces de uma rede de computadores. O objetivo dessa representação é informar qual o estado dos enlaces, baseados em suas métricas, que compôem uma rede de computadores. Por exemplo, se o tráfego do enlace está

33 3.2 Proposta de Solução 32 alto, se há muitos erros, se a latência está alta, etc. Mas como chegar a esse resultado? Essa pergunta será respondida adiante Etapas para a solução proposta Informações das métricas em tempo real As informações das métricas que são usadas no desenvolvimento desse trabalho são advindas de arquivos no formato RRD, fornecidos pela Universidade Federal do Espirito Santo, Brasil. Nesses arquivos, há informações de tráfego, latência, erros e descartes que são atualizadas em tempo real (a cada 5 minutos). Essa atualização não faz parte do escopo do trabalho. Dessa forma, é possível partir do princípio que informações de métricas em tempo real estão armazenadas em arquivos RRD. Busca de uma API de Visualização de Dados O próximo passo para chegar à solução desse projeto foi fazer uma busca na Internet de modo a encontrar uma API de Visualização de Dados. Os fatores para a escolha de uma API em específico foram: 1. Ter código aberto 2. Ser utilizada online 3. Possuir um propósito abrangente quanto às formas de visualização 4. Ser simples de usar Foram analisadas, inicialmente, APIs cujo código é aberto: como InetSoft Style Chart, Google Chart Tools e VisAD. Porém, dentre as analisadas, a API Google Chart Tools foi a que se enquadrou melhor nas quatro características descritas acima. Conforme visto na seção 2.4.5, a API possui muitas formas de visualização de dados e é simples de ser usada, pois não é necessário qualquer instalação e é usada diretamente através de um navegador web. No entanto há uma pequena desvantagem ao usar essa API: ela é dependente de um código em Javascript encontrado na URL " Em todo momento que a API é utilizada, tal código em Javascript é carregado. Note que é possível armazenar uma cópia do tal código em um local de rápido acesso, o que não é aconselhável, pois caso o código original seja atualizado, sua cópia não será.

34 3.2 Proposta de Solução 33 Ao final dos dois passos realizados até o momento, temos a seguinte figura: Figura 3.2: Conclusão dos dois primeiros passos Coleta de dados dos arquivos RRD Ao analisar a figura 3.2, a seguinte pergunta é cabível: como a API Google Chart Tools acessará os dados que precisam ser representados? Para essa pergunta ser respondida, foi feita uma pesquisa sobre como extrair informações de arquivos RRD. A ferramenta RRDTool é própria para lidar com arquivos RRD. Como uma de suas funções, há uma para exportar os arquivos RRD para arquivos XML, chamada de "rrdtool dump". Tendo em vista que muitas linguagens de programação, inclusive Javascript, possuem maneiras para ler arquivos XML, a solução inicial foi exportar os arquivos RRD para arquivos XML e então fazer a leitura do XML pela linguagem Javascript. Para testar o desempenho solução proposta, foi feita exportação, para XML, de aproximadamente 100 arquivos RRD que pertencem a uma rede de computadores real. O tempo decorrido para realizar essa tarefa foi de aproximadamente 3 minutos. Devido a esse fator, essa solução foi imediatamente descartada. Como a solução de exportar os arquivos RRD para XML foi descartada, foi pesquisada uma forma de ler os arquivos RRD de forma direta. No caso, foi verificado se e quais linguagens de programação possuem formas de lidar com arquivos RRD.

35 3.2 Proposta de Solução 34 Como o objetivo do trabalho é desenvolver uma aplicação web, foram pesquisadas linguagens que possuem suporte à aplicações web. Inicialmente foram analisadas formas de leitura através das linguagens Java e Javascript. Durante a pesquisa foram encontradas algumas bibliotecas Java que lidam com arquivos RRD: RRD4J, jrrd e rrdjtool. Alguns outros fatores também contribuíram para a escolha da linguagem Java: portabilidade (pode ser executada em qualquer equipamento que possui o interpretador Java instalado) e de que a linguagem possui bibliotecas que lidam com inúmeros formatos de arquivos. Dentre as três bibliotecas Java que foram analisadas, a RRD4J se destacou pelos seguintes motivos: não necessita da ferramental RRDTool, usa apenas a linguagem Java (ao contrário da rrdjtool), possui várias funções para lidar com arquivos RRD e suporta todas as versões de arquivos RRD (ao contrário da jrrd) [Biblioteca Java: RRD4J 2012]. Novamente, foi feito um teste de desempenho na leitura de arquivos RRD, desta vez utilizando a biblioteca RRD4J. Foram feitas diversas leituras dos mesmos 100 arquivos RRD testados anteriormente. Como resultado, o tempo de resposta foi da ordem de segundos, o que é muito mais eficiente em comparação com a solução recentemente descartada. Como a biblioteca RRD4J é desenvolvida em Java e o objetivo do projeto é uma aplicação web dinâmica, essa aplicação foi desenvolvida utilizando a tecnologia Servlet Java. Em adição à figura 3.2, foi adicionado mais um componente: o Servlet Java. Figura 3.3: Conclusão dos três primeiros passos

36 3.2 Proposta de Solução 35 Definição dos enlaces e métricas que devem ser considerados na representação A forma como os arquivos RRD serão lidos já foi definida. Porém, como listar quais arquivos RRD devem ser lidos? Quais as métricas serão lidas? Qual o nome dos enlaces que pertencem à rede de computadores? Essas informações devem ser listadas pelo gerenciador de rede. Depois de feita essa definição, a aplicação que é responsável pela leitura de arquivos RRD será executada. A proposta, então, é a elaboração de arquivo de configuração, que informa a resposta para todas as perguntas acima. Para a definição do formato do arquivo de configuração, foram analisados os formatos JSON e XML. Segundo [JSON: The Fat-Free Alternative to XML]: JSON não é extensível porque não é necessário. JSON não é um arquivo de linguagem de marcação (XML é), então não é preciso definir tags e atributos para representar a informação JSON é mais simples que XML, pois possui uma gramática muito menor e mapeia melhor as estruturas de dados usadas em linguagens de programação modernas JSON possui formato aberto assim como XML Ambos os formatos são legíveis e úteis para intercâmbio de dados JSON possui formato aberto assim como XML Esses fatores foram levados em consideração na escolha. Porém, os gerenciadores de rede envolvidos no trabalho são familiarizados com arquivos XML, o que influenciou muito para a decisão do formato utilizado. Então, foi escolhido o XML. Como resultado da escolha do formato do arquivo de configuração, foi adicionado mais um componente à estrutura da solução.

37 3.2 Proposta de Solução 36 Figura 3.4: Conclusão dos quatro primeiros passos Comunicação com a API de Visualização de Dados O Servlet Java possui todas as informações que serão consideradas na representação da rede de computadores. A API de visualização de Dados Google Chart Tools é usada via código Javascript. Então, como realizar a comunicação entre o código em Java e o código em Javascript? Novamente, foram analisados os formatos XML e JSON para o intercâmbio dos dados. Na seção anterior, foi decidido que o arquivo de configuração pelo fato dos gerenciadores de rede envolvidos serem familiarizados com arquivos XML. Porém, desta vez, o arquivo não será criado (ou preenchido) manualmente e sim criado através da linguagem Java. Levando em consideração as vantagens citadas anteriormente de arquivos JSON em relação a XML, JSON foi escolhido para ser o formato de arquivo para intercâmbio dos dados. Para a criação do arquivo JSON, foi usada a biblioteca Java org.json. Tal biblioteca é utilizada diretamente através do código Java. Além disso, foram feitos testes de desempenho: foi criado um arquivo JSON contendo informações de métricas de 20 enlaces diferentes. Como resultado, o arquivo JSON foi criado em segundos, o que é satisfatório. Ao final de mais uma etapa, a estrutura final da solução proposta pode ser mostrada:

38 3.2 Proposta de Solução 37 Figura 3.5: Etapas do Projeto

39 3.2 Proposta de Solução 38 Definição do método de Visualização de Dados a ser usado para representar todos os enlaces envolvidos A estrutura da solução proposta foi apresentada. Porém, resta definir, dentre as várias formas de representação de dados fornecidas pela API Google Chart Tools, qual forma é a mais adequada. Para encontrar tal forma visualização de dados, foram considerados alguns fatos: Tendo vista que que uma rede pode ter um número muito grande de enlaces, o espaço para a visualização deve ser aproveitado ao máximo Toda a rede deve ser reprentada na visualização A visualização tem de ser interativa Levando em consideração os fatores acima, a visualização escolhida foi a Treemap. Conforme explicado na seção 2.4.6, todo o espaço disponível para a imagem é utilizado. Esse fator pode contribuir para a escalabilidade da representação. Além disso, a Treemap fornecida pela API Google Chart Tools é interativa: com poucos cliques, é possível navegar na representação. Mas como definir os níveis da Treemap? Sabemos que redes de computadores possuem enlaces. Enlaces possuem métricas. Por fim, métricas possuem valores. Com base nessas informações, foi definida uma Treemap de três níveis. O primeiro nível contém os enlaces que fazem parte da rede de computadores, o segundo as métricas de um enlace específico e o terceiro o valor coletado de uma das métricas específicas. A solução proposta Tendo em base os passos concluídos para atingir a solução como um tudo, é possível definir os seguintes passos para a completude do desenvolvimento do projeto: 1. Preenchimento de um arquivo de configuração no formato XML 2. Leitura de um arquivo de configuração no formato XML 3. Leitura dos arquivos, especificados, no formato RRD 4. Geração do documento de intercâmbio no formato JSON

40 3.3 O desenvolvimento Leitura do documento de intercâmbio no formato JSON 6. Geração da visualização final A figura 3.5 ilustra todo o funcionamento dese trabalho. O detalhamento de cada uma das etapas será apresentado em seguida. 3.3 O desenvolvimento Como consideração inicial, vale ressaltar todos as representações e testes mostrados nesta seção e na seção 4.1 são baseados em valores fictícios. Qualquer semelhança com a realidade é mera coincidência Preenchimento de um arquivo de configuração no formato XML O primeiro passo para o desenvolvimento desse trabalho é o preenchimento de um arquivo de configuração XML. Nesse arquivo, é informado quais são as instituições, os enlaces e as métricas que devem ser consideradas na análise de cada um dos enlaces. Esse arquivo de configuração deve ser preenchido manualmente por um usário apto a fazê-lo (que saiba como é a estrutura e a disposição das informações contidas em tal arquivo). Forma de preenchimento do arquivo de configuração O primeiro campo a ser preenchido é o caminho para a pasta onde estão todos os arquivos no formato RRD (esses arquivos serão lidos futuramente para a coleta dos dados). A tag raiz do XML é chamada de <rrdroot> e o atributo ao qual deve ser atribuído o caminho (absoluto) da pasta onde estão os arquivos RRD é chamado de folder. Para que a visualização final seja gerada de forma correta, todos os arquivos RRD devem estar na mesma pasta. Figura 3.6: Inicio do Arquivo de Configuração XML O próximo passo do preenchimento são as instituições e seus enlaces. O nome da instituição deve ser inserido no atributo name, pertencente à tag <institution>. Cada <institution> possui uma ou mais interfaces. Os dados referentes à(s) interface(s) devem ser inseridos, cada um, na devida tag <interface>. Como atributos de <interface>, temos:

41 3.3 O desenvolvimento 40 name: nome da instituição ligada à instituição inserida na tag <institution> imediatamente acima id: número inteiro único que identifica essa interface max_traffic: tráfego máximo, em bits por segundo, do enlace em questão max_discards: taxa de descartes, por segundo, considerada insatisfatória max_errors: taxa de erros, por segundo, considerada crítica max_ping: latência considerada crítica A existência ou não das quatro últimas tags acima é condicionada à existência da métrica equivalente. Por exemplo, a atributo max_traffic deve ser preenchido obrigatoriamente se a métrica tráfego for considerada. Pertencente a <interface>, há ainda novas tags a serem preenchidas. Tais tags podem ser referentes a: Tráfego: <traffic_in> e/ou <traffic_out> Erro: <errors_in> e/ou <errors_out> Descarte: <discards_in> e/ou <discards_out> Latência: <ping> Para a análise correta das métricas, é necessário que cada uma das interfaces contenha pelo menos uma das tags especificadas acima e o preenchimento do valor máximo equivalente seja feito. Caso não seja necessário a análise de uma determida métrica, ela não deve ser preenchida. A figura 3.7 ilustra um exemplo de como deve ser feito o preenchimento. Figura 3.7: Forma como é preenchida uma interface no arquivo de configuração XML

42 3.3 O desenvolvimento 41 Cada uma das tags que informam as métricas possui o atributo database_name, que é o nome da base de dados cadastrada no arquivo RRD. Por exemplo, o nome da base de dados para tráfego é traffic_in ou traffic_out dependendo do sentido do fluxo de dados. O preenchimento desse atributo é obrigatório, pois um arquivo RRD pode possuir várias métricas. Esse nome preenchido irá informar especificamente qual é a métrica a ser tratada. O conteúdo de cada campo informado através das tags que abordam as métricas desejadas deve ser o nome completo (incluindo a extensão) do arquivo RRD que possui tal informação. Esse arquivo de configuração XML pode ter uma quantidade considerável de instituições e interfaces. Todas elas serão tratadas de forma correta se forem descritas como explicado anteriormente e mostrado nas figuras Leitura de um arquivo configuração no formato XML A partir desse passo, o Servlet Java entrará em execução.para a leitura do arquivo XML em questão, foi usada a biblioteca Java chamada DOM Parser [Biblioteca Java: DOM Parser 2012]. Inicialmente, o Servlet Java não sabe em que local está o arquivo. Para indicar tal local ao Servlet, foi criado um arquivo no formato properties. O caminho, absoluto, onde está o arquivo XML é especificado nesse arquivo, na variável chamada XML_PATH. Caso seja necessário informar uma nova localização do arquivo XML, basta abrir arquivo, que neste trabalho foi chamado de input.properties, alterar o conteúdo dessa variável e reiniciar a aplicação. Figura 3.8: O arquivo input.properties Leitura dos arquivos, especificados, no formato RRD Feita a leitura do arquivo XML, o Servlet Java irá iniciar a leitura dos arquivos RRD informados. Para essa leitura foi usada a biblioteca Java RRD4J. Essa biblioteca segue a mesma lógica e usa as mesmas fontes de dados, tipos de arquivo e definições que a ferramenta RRDTool utiliza [Biblioteca Java: RRD4J 2012]. Para a leitura de cada um dos arquivos RRD, o Servlet Java recebe, como parâmetros, o nome do arquivo a ser lido e o nome da base de dados (especificado no atributo database_name de cada métrica existente no arquivo XML).

43 3.3 O desenvolvimento 42 Cada arquivo RRD é lido conforme o caminho: atributo folder da tag <rrdroot> concatenado ao nome do arquivo descrito dentro da tag de cada métrica. É coletado, então, o valor que representa a média da(s) métrica(s) desejada(s) durante os últimos cinco minutos. Por exemplo, a média do tráfego e da latência nos últimos cinco minutos. Além disso, outros valores são coletados dependendo de cada métrica: <traffic_in> e <traffic_out>: é coletado o valor inserido no atributo max_traffic dentro da tag <interface> <errors_in> e erros_out: é coletado o valor inserido no atributo max_errors dentro da tag <interface> <discards_in> e <discards_out>: é coletado o valor inserido no atributo max_discards dentro da tag <interface> <ping>: é coletado o valor inserido no atributo max_ping dentro da tag <interface> Durante a leitura dos respectivos valores é possível que o arquivo RRD contenha um valor desconhecido para uma determinada métrica, que é representado por NaN (Not a Number). Mas o que isso significa? Durante a coleta de dados para atualização dos arquivos RRD, que não faz parte do escopo desse trabalho, um determinado valor pode não ter sido devidamente coletado. Quando isso acontece, a aplicação que atualiza os arquivos RRD insere NaN pareado com o timestamp da respectiva atualização. O modo como são usados os valores coletados, bem como o tratamento desse possível problema, será explicado na seção Geração do documento de intercâmbio, no formato JSON A API de visualização de dados utilizada no trabalho foi a Google Chart Tools, que é feita na linguagem Javascript. Os valores coletados que serão utilizados na visualização fazem parte do Servlet Java. Portanto, para que a API se comunique com o Servlet Java, o arquivo JSON executa o papel intermediário, ou seja, o Servlet Java irá passar todas as informações necessárias (instituições, interfaces, valores, etc.) através do arquivo JSON. Na seção 2.4.3, foi explicado que um Servlet irá gerar uma resposta para o servidor web. No caso desse trabalho, a resposta é justamente um arquivo JSON. A hierarquia das informações do arquivo JSON em questão é semelhante ao arquivo de configuração XML, porém, algumas informações escritas são diferentes:

44 3.3 O desenvolvimento 43 institutions: name: nome da instituição interfaces: name: nome da instituição ligada à instituição inserida imediatamente acima id: numero inteiro único que identifica a interface status: status da interface attributes: attribute_name: nome da métrica (traffic_in, traffic_out, ping, etc..) value: valor coletado do arquivo RRD max_value: valor máximo para a métrica em questão status: status da métrica OBS: A forma como cada um dos atributos acima será usado nos cálculos para gerar a visualização será explicado na seção Ao final da geração do arquivo JSON, o Servlet Java terminou de executar o seu papel, que é gerar um arquivo JSON no formato mostrado acima. Os próximos passos serão executados por um código em Javascript (incluso no arquivo HTML) Leitura do documento de intercâmbio, no formato JSON O código em Javascript irá ler o arquivo JSON devidamente formatado. Para tal, foi usada a biblioteca Javascript JQuery [Biblioteca Javascript: JQuery 2012]. Como parâmentro de entrada, o trecho de código que irá fazer a leitura acessa o arquivo JSON através de uma URL que, no caso deste trabalho, é a URL raiz seguida de /json. Ao final da leitura, uma variável do código em Javascript irá receber todo o arquivo JSON e será passada para a função que gerará a visualização final.

45 3.3 O desenvolvimento Geração da visualização final Esse é o passo mais importante do projeto. Ao final dele, será exibida a representação gráfica de todas as informações coletadas. Antes de exibir a visualização final será descrito um passo-a-passo de como ela é gerada em cada nível. Cálculo do tamanho da representação no primeiro nível No modo de visualização Treemap, há dois parâmetros (além do nome e do nó pai) para a representação de uma determinada informação, que no caso desse trabalho é a representação de um enlace. O primeiro parâmetro é o tamanho, que é representado por um valor positivo. O segundo parâmetro é a cor, que é representada por um valor negativo ou positivo. No caso desse trabalho, ambos os valores variam apenas entre 0 e 100. Essa seção ira abordar como é feito o cálculo do tamanho. Na seção 3.3.1, foi informado que há quatro métricas que podem ser consideradas: tráfego, erro, descarte e latência. O cálculo é feito da seguinte forma: No arquivo JSON, dentre os atributos da interface, há um vetor attributes, que contém as informações sobre uma métrica (nome, valor, valor máximo e estado). Para cada métrica de uma interface é feita o seguinte cálculo: Size = N i=1 value i 100 ( max_value i N ) Em que Size representa o valor positivo entre 0 e 100 que determina o tamanho da representação do enlace no primeiro nível e N é o número de métricas a ser consideradas no enlace. Nesse caso, quanto maior esse tamanho, maior a média entre as métricas. Cálculo da cor da representação no primeiro nível Para cada métrica que afeta a cor de uma determinada interface, é feito o seguinte cálculo: Color = 100 N i=1 value i 100 ( max_value i N ) Em que Color representa o valor positivo entre 0 e 100 que determina a cor da representação do enlace no primeiro nível. No caso desse trabalho, a escala de cores começa do vermelho, passa pelo amarelo e vai até o verde. Quanto mais próximo de 0, mais vermelho e quanto mais

46 3.3 O desenvolvimento 45 próximo de 100, mais verde. Na representação da cor, quanto mais próximo do vermelho, maior a média entre as métricas. A cor e o tamanho representados no primeiro nível é representado pelo somatório dos números que representam a cor e tamanho no segundo nível. Sendo assim, não é possível estabelecer manualmente um número que representa o tamnho e a cor no primeiro nível. A representação do primeiro nível Figura 3.9: Representação dos enlaces (primeiro nível) A figura 3.9 ilustra um exemplo de visualização do primeiro nível da Treemap. Cada retângulo é a representação de um enlace. Na representação do primeiro nível é possível saber qual o estado do enlace e a média de suas métricas. Na informação sobre o enlace, é escrito seu nome seguido do seu identificador entre colchetes e o seu estado entre chaves. Como estados de interfaces (enlaces), há duas possibilidades: ativo (up) ou inativo (down). Na representação das interfaces na Treemap há o nome do enlace juntamente com seu identificador. Caso o enlace esteja inativo, que na abordagem desse trabalho significa que o tráfego na interface é nulo, a representação desse enlace estará no tamanho máximo e na cor vermelha. Analisando a figura 3.9, é possível enxergar representações em diferentes cores e tamanhos. Porém, essa representação não é suficiente para responder todas as dúvidas. Se a representação

47 3.3 O desenvolvimento 46 do enlace está grande, qual métrica, em específico, está alta? Quais são os valores de cada métrica? A representação do segundo nível A representação do segundo nível informa o estado de cada uma das métricas abordadas no enlace. Ao clicar com o botão esquerdo do mouse na representação de um enlace, o segundo nível da Treemap, referente ao enlace escolhido, será exibido. Nesse nível, para cada uma das métricas, temos a escala de cor. Quanto mais próximo do vermelho, mais a próxima do valor do máximo atribuído a métrica está. A cálculo da representação da cor da métrica é feita da seguinte forma Color = 100 value 100 max_value Em que Color é um valor positivo entre 0 e 100 que representa a cor da representação da métrica do enlace em questão. O tamanho, por sua vez, é feito da seguinte forma: Size = value 100 max_value Em que Size é um valor positivo entre 0 e 100 que representa o tamanho da representação da métrica do enlace em questão. Analisando a figura 3.9, é possivel ver que o enlace Metrovix [7] está amarelado. À primeira vista, não é possível dizer qual métrica está alta ou baixa dentre todas as avaliadas. Analisando a cor e o tamanho da representação no primeiro nível, é possível perceber, apenas, que há algo errado, não exatamente o quê. Por esse motivo foi criado o segundo nível.

48 3.3 O desenvolvimento 47 Figura 3.10: Representação dos enlaces (segundo nível) Analisando, agora, a figura 3.10 é possível descobrir a causa do problema, ou seja, qual(is) métrica(s) é(são) responsável(eis) pela atual má qualidade do enlace. No caso do enlace Metrovix [7], as métricas Traffic In e Errors In estão acima do esperado. O valor NaN (Not a Number) Na seção 3.3.3, foi citada a possibilidade de existir um valor desconhecido para uma determinada métrica. Para o tratamento desse problema, foi criada o atributo status para cada métrica. Se, durante a leitura de um determinado arquivo RRD for encontrada o valor NaN, esse atributo status é preenchido com NaN. Na representação do segundo nível, esse problema é explicitado. No caso, é concatenado à representação da métrica, a expressão {NaN}.Além disso, a cor dessa representação será vermelha. A representação do terceiro nível O terceiro nível foi criado para informar qual foi o valor coletado para cada métrica. Para ser exibido o terceiro nível, basta clicar com o botão esquerdo do mouse na métrica desejada. Nese nível, a cor da representação serão exatamente iguais a da respectiva métrica no segundo nível. Como nesse nível apenas um elemento é exibido, o tamanho é irrelevante.

49 3.3 O desenvolvimento 48 Figura 3.11: Representação dos enlaces (terceiro nível) Solução alternativa Na representação Treemap que foi apresentada anteriormente, o nivel de profunidade é 1, o que significa que a imagem mostrada exibirá um nível de cada vez. Porém, é possível alterar sua profunidade com o objetivo de exibir mais níveis em uma mesma imagem. Como exemplo, a figura 3.12 representa a mesma Treemap explicada anteriormente, porém com dois níveis de profundidade.

50 3.3 O desenvolvimento 49 Figura 3.12: Treemap com 2 níveis de profundidade Como vantagem dessa abordagem: o estado de cada métrica é informado inicialmente, não sendo necessário clicar na representação de um enlace. Porém, quando o nível de profundidade é 1, no primeiro nível é exibido o balanço de cores do segundo nível. Essa informação é perdida na representação com dois níveis de profundidade. Na primeira análise, é complicado dizer qual enlace se encontra em melhor estado. Além disso, quando o número de enlaces e métricas são muito grandes, a imagem pode se tornar visualmente sobrecarregada. Devido às desvantagens citadas, como proposta de solução, foi escolhida a Treemap com apenas 1 nível de profundidade.

51 50 4 Validação da proposta baseada em testes É importante salientar que não é possível testar todas as situações existentes para verificar como será gerada a visualização final. Fazendo diversos testes (para vários enlaces que compõem uma rede de computadores), é possível que ocorra alguma situação não prevista durante o desenvolvimento da nova visualização. Isso significa que alguma alteração, por menor que seja, pode se tornar necessária. Serão informadas algumas situações já encontradas, bem como a solução para elas, caso seja necessário. 4.1 Descrição dos testes Quando vários enlaces se tornam inativos Durante o desenvolvimento do projeto, foi definido que quando um enlace se torna inativo, sua representação terá tamanho máximo e cor mínima (vermelha). Mas se vários enlaces se tornam inativos, o que acontece?

52 4.1 Descrição dos testes 51 Figura 4.1: Dois enlaces inativos ao mesmo tempo Analisando a figura 4.1, é possivel ver que a representação dos enlaces que continuam ativos (em verde) se tornou muito pequena perante o tamanho da representação dos dois enlaces que estão inativos. A solução para o problema foi: a cor e tamanho da representações de enlaces inativos é estática e atribuída manualmente. Nesse caso, ao invés de atribuir o valor máximo para o tamanho, que é 100, foi atribuído um valor menor, não prejudicando, assim, o restante das representações. O valor atribuído para o tamanho de enlaces inativos foi 20, mas sua cor permaneceu no mínimo, que é 0. A nova representação ficou da seguinte forma (figura 4.2):

53 4.1 Descrição dos testes 52 Figura 4.2: Dois enlaces inativos ao mesmo tempo (corrigido) Quando vários enlaces possuem métricas com valores desconhecidos Quando arquivos RRD retornam valores desconhecidos (NaN) para determinadas métricas, foi definido que a representação da métrica seria de tamanho 100, mas no segundo nível. Mas como seria representado o primeiro nível?

54 4.1 Descrição dos testes 53 Figura 4.3: Métricas com valores desconhecidos Analisando a figura 4.3, se vários enlaces possuirem métricas de valores desconhecidos, tais enlaces não geram a omissão dos outros enlaces, que estão em um estado satisfatório. Neste caso, não foi feita nenhuma alteração nos parâmetros de cor e tamanho. A informação explicitando qual a métrica possui um valor desconhecido se encontra no segundo nível da representação (figura 4.4):

55 4.1 Descrição dos testes 54 Figura 4.4: Métricas com valores desconhecidos (segundo nível) Quando há vários enlaces problemáticos Figura 4.5: Muitos enlaces com problema