UNIVERSIDADE DO VALE DO ITAJAÍ
CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR
CURSO DE CIÊNCIA DA COMPUTAÇÃO
OCTOPUS: FERRAMENTA DE CÓDIGO ABERTO PARA GERAÇÃO
DE RELATÓRIOS PARA O SERVIDOR PROXY SQUID
por
Matheus Weber da Conceição
Itajaí (SC), novembro de 2012
UNIVERSIDADE DO VALE DO ITAJAÍ
CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR
CURSO DE CIÊNCIA DA COMPUTAÇÃO
OCTOPUS: FERRAMENTA DE CÓDIGO ABERTO PARA GERAÇÃO
DE RELATÓRIOS PARA O SERVIDOR PROXY SQUID
Área de Ciência da Computação
por
Matheus Weber da Conceição
Relatório apresentado à Banca Examinadora
do Trabalho Técnico-científico de Conclusão
do Curso de Ciência da Computação para
análise e aprovação.
Orientador: Fabrício Bortoluzzi, M.Sc.
Itajaí (SC), novembro de 2012
Aos meus pais.
AGRADECIMENTOS
Agradeço primeiramente aos meus pais pelo grande apoio e suporte nessa etapa da
minha vida.
Agradeço também aos amigos que foram feitos durante o curso possibilitando uma
grande troca de conhecimento e apoio necessário, em especial aos amigos Alexandre Corsi,
Elcio Arthur Cardoso, Paulo Eduardo Krieger e Marcus Simas.
Agradeço também a todos os docentes que participaram da minha evolução de
conhecimento, em especial ao Fabricio Bortoluzzi pelo apoio e orientação necessária no
desenvolvimento deste trabalho.
Obrigado.
“No pain, no gain.”
RESUMO
CONCEIÇÃO, Matheus W. Octopus: ferramenta de código aberto para geração de
relatórios para o servidor proxy Squid. Itajaí, 2012. 84. Trabalho Técnico-científico 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í, 2012.
A partir do momento em que o acesso à Internet em uma organização se torna um recurso
crítico, de alta dependência, faz-se necessário o uso de ferramentas de monitoramento por
parte dos gestores para auxiliá-los nas tomadas de decisões no que tange a definição de
políticas de uso da Internet a fim de evitar abusos. A otimização do uso deste recurso de
comunicação e a identificação do perfil de uso do protocolo de navegação web, gera uma boa
fundamentação para as decisões futuras. Para isso, é importante que a ferramenta de
monitoramento seja de fácil e ágil utilização, sendo flexível na busca e na visualização das
informações desejadas. Este trabalho projetou e implementou o Octopus: ferramenta de
código aberto para a geração de relatórios para o servidor proxy Squid. Com este fim, foi
realizado um trabalho de pesquisa para fundamentar a teoria necessária e definir as
tecnologias a serem utilizadas. Em seguida, foi elaborado o projeto de engenharia de software
da ferramenta, levantando requisitos necessários, diagramas de modelo de classes, diagramas
de casos de uso e a estrutura do banco de dados. Em seguida, realizou-se a etapa de
implementação da ferramenta com base no projeto realizado. No fim do processo de
desenvolvimento, realizou-se uma validação da ferramenta com alguns arquivos de registro de
acessos do Squid coletados anteriormente, atestando-se então a conformidade da ferramenta
com o projeto.
Palavras-chave: Gerência de Redes. Proxy. Squid.
ABSTRACT
When the Internet access of a company became critical, it is necessary that the company
leaders consider the use of monitoring tools to help them to take the best decision in terms of
Internet use policy to avoid abuse from users. Optimizing the use of that valuable
communication resource and identifying the web use profile, should result in a wide
background knowledge for future decisions. Then, is important to use a monitoring tool that
is easy, fast and flexible in data searching and in the visualization of the information. This
work have designed and developed the Octopus, an open source reports generator tool for
Squid proxy server. With this aim, a literature search was first done to get all the necessary
theory background, which was followed by the definition of the technology that was used in
the tool specification step. Then, the software engineering project of the tool was elaborated
and all the requirements, class diagrams, use case diagrams and database models were
obtained. In the next stage of the work, the tool was implemented in the bases of the
engineering project, followed by the validation stage, which allowed the validation of the tool
with some previously collected Squid access data files, which attested the conformity of the
tool with the project specifications.
Keywords: Network Management. Proxy. Squid.
LISTA DE FIGURAS
Figura 1. Hierarquia das camadas da Gerência de Rede...........................................................18
Figura 2. Funcionamento de um servidor proxy.......................................................................19
Figura 3. Funcionamento do servidor proxy Squid em uma rede.............................................21
Figura 4. Metáfora visual para visualização dos dados de acessos do Squid...........................26
Figura 5. Captura de tela da ferramenta SARG na página inicial de relatórios........................30
Figura 6. Captura de tela da ferramenta SARG no relatório de um usuário.............................31
Figura 7. Captura de tela da ferramenta Calamaris no início do relatório................................33
Figura 8. Captura de tela da ferramenta Free-SA na tela de escolha dos períodos de tempo
disponíveis ..............................................................................................................................35
Figura 9. Captura de tela da ferramenta Free-SA com os tipos de relatórios gerados..............35
Figura 10. Captura de tela da ferramenta Free-SA na página de relatório de domínios
acessados de um usuário...........................................................................................................36
Figura 11. Captura de tela da ferramenta Redline Internet Access Monitor.............................38
Figura 12. Captura de tela da ferramenta Redline Internet Access Monitor com o relatório de
uso diário exportado em HTML................................................................................................39
Figura 13. Captura de tela da ferramenta Firewall Analyzer na página inicial do relatório.....40
Figura 14. Captura de tela da ferramenta Firewall Analyzer na página de relatório de um
usuário
..............................................................................................................................41
Figura 15. Captura de tela da ferramenta Sawmill na página inicial........................................43
Figura 16. Captura de tela da ferramenta Sawmill na tela de relatório de acessos...................44
Figura 17. Diagrama do modelo de casos de uso......................................................................49
Figura 18. Diagrama do modelo de classes do módulo coletor................................................51
Figura 19. Diagrama de modelo de classes do módulo interface de visualização....................52
Figura 20. Diagrama modelo entidade relacionamento (modelo ER).......................................53
Figura 21. Protótipo de tela do relatório bidimensional............................................................54
Figura 22. Protótipo de tela do relatório tridimensional...........................................................55
Figura 23. Classe “SquidAccessLogRequest” do módulo coletor............................................56
Figura 24. Classe "SquidLogFile" do módulo coletor (método "parse" recolhido)..................56
Figura 25. Captura de tela do formulário de autenticação do sistema......................................59
Figura 26. Captura de tela do relatório bidimensional com destaque para os parâmetros........60
Figura 27. Captura de tela do relatório bidimensional com destaque ao relatório....................61
Figura 28. Captura de tela do relatório tridimensional com destaque para os parâmetros.......62
Figura 29. Captura de tela do relatório tridimensional com destaque para o relatório
tridimensional............................................................................................................................63
Figura 30. Captura de tela da listagem de usuários...................................................................64
Figura 31. Captura da tela inicial da ferramenta juntamente com a listagem de consultas salvas
65
Figura 32. Captura de tela no número total de resultados no banco de dados..........................67
Figura 33. Teste 2 - Parâmetros do relatório bidimensional.....................................................68
Figura 34. Teste 2 - Relatório bidimensional de acessos de um usuário específico.................69
Figura 35. Teste 3 - Parâmetros do relatório tridimensional.....................................................70
Figura 36. Teste 3 - Relatório dos maiores arquivos baixados.................................................71
LISTA DE QUADROS
Quadro 1. Exemplo de arquivo com um registro de acesso do Squid......................................22
Quadro 2. Comparativo de ferramentas similares.....................................................................29
Quadro 3. Resultado da execução do módulo coletor...............................................................66
LISTA DE ABREVIATURAS E SIGLAS
ACL
DDL
DML
DRL
ER
HTML
HTTP
IP
LDAP
OLAP
OSI
PHP
SARG
SGBD
SQL
TCP
TTC
UML
UNIVALI
URI
URL
W3C
Access Control List
Data Definition Language
Data Manipulation Language
Data Representation Language
Entity-relationship
HyperText Markup Language
HyperText Transfer Protocol
Internet Protocol
Lightweight Directory Access Protocol
Online Analytical Processing
Open Systems Interconnection
PHP: Hypertext Preprocessor
Squid Analysis Report Generator
Sistema de Gerenciamento de Banco de Dados
Structured Query Language
Transmission Control Protocol
Trabalho Técnico-científico de Conclusão de Curso
Unified Modeling Language
Universidade do Vale do Itajaí
Uniform Resource Identifier
Uniform Resource Locator
World Wide Web Consortium
SUMÁRIO
1 INTRODUÇÃO.............................................................................xii
1.1 PROBLEMATIZAÇÃO..........................................................................XIV
1.1.1 Formulação do Problema......................................................................xiv
1.1.2 Solução Proposta....................................................................................xiv
1.2 OBJETIVOS.............................................................................................XIV
1.2.1 Objetivo Geral........................................................................................xiv
1.2.2 Objetivos Específicos...............................................................................xv
1.3 METODOLOGIA......................................................................................XV
1.4 ESTRUTURA DO TRABALHO............................................................XVI
2 FUNDAMENTAÇÃO TEÓRICA...............................................17
2.1 GERÊNCIA DE REDES.............................................................................17
2.2 PROXY.........................................................................................................19
2.3 SQUID..........................................................................................................20
2.3.1 Registro das informações de acessos......................................................21
2.3.2 Fonte do registro de informações de acesso..........................................24
2.4 OLAP (ONLINE ANALYTICAL PROCESSING)..................................25
2.5 POSTGRESQL............................................................................................27
2.6 FERRAMENTAS SIMILARES.................................................................28
2.6.1 SARG........................................................................................................30
2.6.2 Calamaris.................................................................................................32
2.6.3 Free-SA.....................................................................................................34
2.6.4 Redline Internet Access Monitor...........................................................37
2.6.5 Firewall Analyzer....................................................................................40
2.6.6 Sawmill.....................................................................................................42
3 DESENVOLVIMENTO...............................................................46
3.1 MODELAGEM DO SOFTWARE.............................................................46
3.1.1 Levantamento de requisitos....................................................................47
3.1.2 Modelo de casos de uso............................................................................48
3.1.3 Modelo de classes.....................................................................................50
3.1.4 Diagrama entidade relacionamento (modelo ER)................................52
3.1.5 Protótipo de tela.......................................................................................53
3.2 IMPLEMENTAÇÃO DA FERRAMENTA..............................................55
3.2.1 Implementação do módulo coletor.........................................................56
3.2.2 Implementação do módulo de interface de visualização......................57
3.3 TESTES FINAIS DA FERRAMENTA.....................................................65
3.3.1 Teste 1: Número requisições coletadas..................................................65
3.3.2 Teste 2: Verificar os sites acessados por um endereço IP (usuário)
durante um período de tempo..........................................................................67
3.3.3 Teste 3: Verificar os maiores arquivos baixados..................................69
4 CONCLUSÕES.............................................................................72
4.1 TRABALHOS FUTUROS..........................................................................73
1 INTRODUÇÃO
Segundo Ricci e Mendonça (2006), cada vez mais o acesso à Internet em uma
organização se torna um recurso crítico, mais acessado e evidente. Com isso, adquire-se
inúmeros benefícios, como por exemplo a informação em tempo real, comunicação mundial a
baixo custo, possibilidade de contatos comerciais com o mundo todo. Porém, juntamente aos
benefícios, traz-se também os riscos às organizações. Riscos estes que podem variar da
segurança da informação, à produtividade dos funcionários.
Em uma das frentes de risco mencionadas anteriormente, o autor sugere a aplicação de
uma ferramenta de auditoria de tráfego web, sendo no caso, um servidor proxy web, mais
especificamente, o Squid. Podendo com isto, aplicar políticas de rede, como o bloqueio de
algumas páginas, além é claro de realizar o monitoramento dos acessos. Dessa maneira podese diminuir os abusos e otimizar este recurso de comunicação.
“O conceito de Proxy refere-se a um software que atua como gateway de aplicação
entre o cliente e o serviço a ser acessado, interpretando as requisições e repassando-as ao
servidor de destino.” (RICCI; MENDONÇA, 2006, p. 1).
Wessels (2004) comenta que o Squid é um servidor proxy do tipo web de código
aberto bastante popular, que também oferece funcionalidade de cache de conteúdo. Wessels
(2004) ressalta alguns usos do Squid:
•
Economizar banda do provedor de Internet enquanto se navega na web;
•
Diminuir o tempo que uma página leva para carregar;
•
Coletar estatísticas sobre o tráfego web da rede;
•
Bloquear o acesso de usuários à sites inapropriados conforme a política de uso da
empresa;
•
Garantir que apenas usuários autorizados possam navegar na Internet.
Na tentativa de melhorar a visualização das informações, pode-se utilizar o conceito
de OLAP (Online Analytical Processing). Segundo Thomsen (2002), OLAP define-se como
sendo um sistema de informação multidimensional. O conceito é associado à noção de
múltiplas dimensões hierárquicas que podem ser utilizados por todos para a obtenção de
informações, como o próprio autor relata, desde em uma escala atômica (informação mais
detalhada), como também em uma escala galáctica (informação menos detalhada). Ou seja, a
visão das informações se dá em um mundo multidimensional e com diversos níveis.
Com isso, este trabalho tem a pretensão de formalizar o desenvolvimento do Octopus:
ferramenta de código aberto para a geração de relatório do servidor proxy Squid.
1.1 PROBLEMATIZAÇÃO
A problematização do trabalho será discutida nas próximas duas subseções, que
abordarão a formulação do problema e a solução proposta desenvolvida.
1.1.1 FORMULAÇÃO DO PROBLEMA
No cenário de softwares de código-fonte aberto, há uma grande carência de
ferramentas modernas voltadas à auditoria da navegação web dos usuários através de um
servidor proxy Squid. Este problema se evidencia em cenários de redes menores, como uma
empresa de pequeno ou médio porte, onde a necessidade de auditoria da navegação web
existe, porém o orçamento disponível não é suficiente para justificar a adoção de uma
ferramenta proprietário de alto custo.
1.1.2 SOLUÇÃO PROPOSTA
Este TTC desenvolveu um software que tem por finalidade permitir ao gestor da rede
visualizar detalhes de uso do tráfego web, podendo identificar os perfis de uso da rede por
parte dos funcionários e então melhorar a fundamentação de tomadas de decisões estratégicas,
como por exemplo, o fornecedor de Internet, a largura de banda contratada para a Internet, as
políticas de uso da rede, bem como a detecção de mau uso da Internet por parte dos usuários.
Para ser possível o fornecimento destes dados, a ferramenta tem por finalidade gerar
relatórios dinâmicos contendo diversas informações de acesso à sites capturadas do servidor
proxy Squid. Além disso, os relatórios contarão com diversos filtros para facilitar a
visualização da informação.
1.2 OBJETIVOS
Os objetivos deste Trabalho Técnico-científico de Conclusão de Curso estão separados
em um objetivo geral e seis objetivos específicos.
1.2.1 OBJETIVO GERAL
O objetivo geral é fundamentar e desenvolver o Octopus: sistema de análise e
auditoria do servidor proxy Squid.
1.2.2 OBJETIVOS ESPECÍFICOS
Os objetivos específicos são:
•
Fundamentar a gerência de redes em geral e o recurso de proxy em específico;
•
Especificar os objetos de análise e auditoria desejados para o Octopus;
•
Modelar o Octopus;
•
Desenvolver o Octopus;
•
Testar e aferir o funcionamento do Octopus em um conjunto de logs do Squid,
comparando-o com o SARG; e
•
Documentar e divulgar este TTC.
1.3 METODOLOGIA
Este trabalho utilizou-se de uma metodologia baseada nos seguintes itens:
•
Fundamentação: nesta etapa foi realizado um estudo de toda a fundamentação
teórica necessária para desenvolver o trabalho, foi utilizada principalmente fontes
de livros;
•
Especificação: nesta etapa foi levantado os requisitos dos objetos de análise e
recursos desejados para a ferramenta proposta;
•
Modelagem: nesta etapa foi realizada toda a modelagem do projeto de engenharia
de software da ferramenta proposta utilizando como metodologia de modelagem a
UML (Unified Modeling Language);
•
Implementação: etapa onde o software de fato foi implementado, tendo como base
as especificações e modelagem;
•
Testes: etapa que trabalha junto com a etapa de implementação, pois basicamente
responde pelos testes realizados a cada parte da implementação;
•
Validação final: ao final da implementação do software, foi executada uma
validação final do software utilizando-se diversos arquivos de registro de acessos
do Squid que foram coletados; e
•
Texto: etapa onde documentou-se as etapas anteriores no documento do TTC e a
finalização geral do texto.
1.4 ESTRUTURA DO TRABALHO
Este documento está estruturado em quatro capítulos. O Capítulo 1, Introdução,
apresentou uma visão geral do trabalho. No Capítulo 2, Fundamentação Teórica, é
apresentada uma revisão bibliográfica e uma análise sobre os aspectos da Gerência de Redes,
além disso, será explicado o conceito de servidor Proxy. Neste capítulo também é feita uma
descrição do servidor proxy Squid onde é apresentado o seu funcionamento básico e
características. Além disso, o conceito de OLAP também foi explorado. Em seguida, são
apresentadas as ferramentas similares à ferramenta desenvolvida.
O Capítulo 3 apresenta o projeto da ferramenta desenvolvida, incluindo sua
especificação e a sua modelagem UML. O capítulo também discute a implementação dos
módulos da ferramenta além de no final apresentar os testes finais de conformidade da
ferramenta com o que foi proposto.
Concluindo, no Capítulo 4, apresentam-se a conclusão do trabalho, onde são
abordados principalmente os resultados alcançados, considerações gerais e os trabalhos
futuros.
17
2 FUNDAMENTAÇÃO TEÓRICA
Neste capítulo, é apresentada uma revisão bibliográfica e uma análise sobre os
aspectos da Gerência de Redes, tais como a sua definição e algumas das suas subdivisões.
Além disso, será revisado o conceito de servidor Proxy, onde será descrito seu
funcionamento. Neste capítulo também é feita uma descrição do servidor proxy Squid onde
apresenta-se suas características. Em seguida, explora-se o conceito de OLAP, útil na
elaboração dos relatórios da ferramenta. No final do capítulo, apresenta-se uma comparação
das ferramentas similares à ferramenta projetada e implementada neste trabalho.
2.1 GERÊNCIA DE REDES
Segundo McCabe (2007), A gerência de redes consiste no conjunto de ações para
controlar, planejar, alocar, implantar, coordenar e monitorar recursos de uma rede. Uma
gerência de rede adequada é fundamental para o sucesso de qualquer rede.
Para Kurose e Keith (2006), uma rede é composta por diversos ativos complexos
(hardware e software), sejam eles componentes físicos, enlaces, protocolos e outros, que
interagem entre si. Todos esses componentes demandam uma organização e uma gerência
para seu correto funcionamento. Até porque, como menciona McCabe (2007), hoje e no
futuro, redes constituem um recurso em que sua integridade é crítica e deve ser mensurada e
verificada.
Segundo Lopes, Sauve e Nicolletti (2003), o objetivo da gerência de redes é monitorar
e controlar os elementos da rede (sejam eles físicos ou lógicos), garantindo um certo nível de
qualidade de serviço. Para o cumprimento desta tarefa, os gerentes de redes são geralmente
auxiliados por um sistema de gerência de redes. Um sistema de gerência de rede pode ser
definido como uma coleção de ferramentas integradas para a monitoração e controle da rede .
Pode-se comparar essa questão com uma usina de geração de energia elétrica (de
modo geral), onde há um sistema complexo com diversos componentes integrados entre si e
que devem ser monitorados, gerenciados e controlados por um administrador em uma sala de
controle, onde há mostradores, medidores e lâmpadas monitorando o estado (temperatura,
pressão, vazão) de válvulas, tubulações, vasos, entre outros. Esses dispositivos permitem que
o operador monitore os muitos componentes da planta e permite reagir reativamente aos
alertas de problemas iminentes. (KUROSE; KEITH, 2006).
18
A sala de monitoramento e controle de uma rede, segundo Kusore e Keith (2006), é
comumente chamada de NOC (Network operations center – Centro de operações de rede). É o
local onde é tomado conta da parte de operações da gerência de rede, é onde é feito todo o
monitoramento e controle de uma rede.
McCabe (2007) separa a gerência de redes em múltiplas camadas, como demonstrado
na Figura 1 e descrito abaixo:
•
Camada de gerência de negócio: Gerência dos aspectos de negócio de uma rede –
por exemplo, gerência dos orçamentos e recursos, planejamento e políticas;
•
Camada de gerência de serviço: Gerência dos serviços oferecidos aos usuários –
por exemplo, gerência de largura de banda, armazenamento de dados,
disponibilidade de aplicações;
•
Camada de gerência de rede: Gerência de todos os ativos de redes em toda a rede;
•
Camada de gerência de ativos de rede: Gerência de uma coleção de ativos de rede
similares – por exemplo, roteadores de acesso, switchs de distribuição;
•
Camada de gerência de dispositivo: Gerência individual de um ativo de rede –
por exemplo, um único roteador, switch, hub.
Figura 1. Hierarquia das camadas da Gerência de Rede
Fonte: Adaptado de McCabe (2007).
19
Essa estrutura de camadas apresentadas na Figura 1, consiste na camada mais abstrata
no topo da hierarquia (camada de gerência de negócio) e a mais específica (camada de
gerência de dispositivo) está no final.
As duas primeiras camadas (gerência de negócio e gerência de serviço), serão as
principais camadas abordadas para este trabalho, já que a aplicação a ser desenvolvida neste
trabalho será um proxy que visa permitir que se audite as políticas de rede determinadas
(camada de gerência de negócios) para o serviço de navegação web (camada de gerência de
serviço). Além disso, também permite coletar o padrão de comportamento da navegação web
assim fundamentando melhor as estratégias futuras de melhoramento da rede.
2.2 PROXY
Segundo Ricci e Mendonça (2006), o servidor proxy pode ser definido como um
software que atua como gateway de aplicação entre o cliente e o serviço que é acessado, como
exemplificado na Figura 2.
Figura 2. Funcionamento de um servidor proxy
Como apresentado na Figura 2, o servidor proxy intercepta as requisições do cliente
enviadas ao servidor, as interpreta e então repassa as requisições ao servidor de destino
responsável pelo serviço a ser acessado, realizando o mesmo procedimento com a resposta.
Aprofundando-se mais no servidor proxy, Ricci e Mendonça (2006) ressaltam que o
servidor proxy é capaz de analisar os pacotes de rede na camada de aplicação, ou camada 7,
do modelo OSI (Open Systems Interconnection). Dessa forma é possível oferecer uma grande
flexibilidade pois permite que o tráfego de dados de um serviço possa ser analisado e assim
permitindo diversos tipos de ações, como por exemplo a aplicação de filtros de bloqueio, ou
então o registro dos dados trafegados (para fins estatísticos e/ou de monitoramento, por
exemplo).
20
O foco deste TTC é dado a um servidor proxy para o protocolo HTTP (Hypertext
Transfer Protocol), ou seja, tráfego web, mais especificamente o servidor proxy Squid.
2.3 SQUID
O Squid é um servidor proxy de código-fonte aberto onde seu projeto iniciou-se em
1996 e utilizou-se como base o código-fonte do software Harvest cache project (WESSELS,
2004).
Wessels (2004) ressalta ainda que o Squid é um servidor proxy bastante popular e
oferece também a funcionalidade de cache de conteúdo. Wessels (2004) destaca alguns dos
principais usos do Squid:
•
Economizar banda do provedor de Internet enquanto se navega na web;
•
Diminuir o tempo que uma página leva para carregar;
•
Coletar estatísticas sobre o tráfego web da rede;
•
Bloquear o acesso dos usuários à páginas inapropriadas conforme a política de
uso da empresa;
•
Garantir que apenas usuários autorizados possam navegar na Internet.
O fluxo básico do tráfego da rede passando pelo Squid descrito por Wessels (2004) é
exemplificado na Figura 3.
21
Figura 3. Funcionamento do servidor proxy Squid em uma rede
O autor descreve o fluxo básico de intermediação do Squid nas transações web da
seguinte maneira: o Squid aceita uma conexão do cliente, processa a requisição e encaminha a
requisição para o servidor de destino original.
Durante esse processo, segundo Wessels (2004), uma requisição pode ter suas
informações salvas em um arquivo de registro de acessos, assim como a requisição pode
também ser rejeitada ou até mesmo modificada antes do encaminhamento para o servidor de
destino original.
O servidor proxy Squid é o software foco deste TTC. A ferramenta produto deste TTC
extrairá do Squid as requisições de acesso de usuários aos sites e suas informações.
2.3.1 REGISTRO DAS INFORMAÇÕES DE ACESSOS
Segundo Wessels (2004), o Squid armazena as informações chaves de acesso dos
usuários aos sites em um arquivo chamado “access.log”. Esse arquivo é baseado por linhas,
ou seja, cada linha corresponde à uma requisição HTTP de um cliente.
O autor explica que o formato padrão do arquivo de registro de acessos do Squid
consiste em dez campos. A cada requisição feita por um cliente à um servidor, é armazenada
no arquivo “access.log” uma linha contendo dez campos com as informações chave a respeito
da conexão.
22
Pode-se ver no Quadro 1 um arquivo de exemplo com quatro requisições. Nas linhas
longas, foram inseridas uma ou mais quebras de linhas de acordo com a necessidade, e o
início das linhas cortadas foram recuadas.
1066037222.011
34173
166.181.33.71
TCP_MISS/200
559
GET
http://coursesites.blackboard.com/service/collab/../1090/
DIRECT/216.200.107.101
application/octet-stream
-
Quadro 1. Exemplo de arquivo com um registro de acesso do Squid
Como observado, tem-se uma linha representando cada requisição. A linha é divida
em dez campos que contém os principais atributos da respectiva requisição, conforme
descreve Wessels (2004), estes atributos são listados como:
•
timestamp;
•
response time;
•
client address;
•
result/status codes;
•
transfer size;
•
request method;
•
URI;
•
client identity;
•
peering code/peerhost; e
•
content type.
Estes atributos são descritos por Wessels (2004) nas subseções a seguir.
23
Atributo “timestamp”
Este atributo expressa a data e hora da finalização da requisição no formato timestamp,
ou seja, representa o número de segundos desde o surgimento do Unix (01/01/1970 00:00:00
UTC) juntamente com os milissegundos, representado pelos três últimos números após o
ponto, exemplo: “1066037222.011”.
Atributo “response time”
Atributo que representa o tempo total de duração, em milissegundos, de
processamento de uma determinada transação HTTP. O contador é iniciado quando o Squid
recebe a requisição HTTP e é congelado quando a requisição é entregada completamente.
Atributo “client address”
Atributo que representa o endereço IP (Internet Protocol) do cliente.
Atributo “result/status codes”
Este campo consiste em dois atributos divididos por uma barra (caractere “/”). O
primeiro atributo determina o protocolo e o resultado da transação (exemplo: “TCP_HIT”,
“TCP_MISS”). O segundo atributo corresponde ao código de resposta da requisição HTTP
(exemplo, “200” para sucesso, “404” para arquivo não encontrado).
Atributo “transfer size”
Atributo que indica o número de bytes transferidos para o cliente. De maneira mais
específica, é o valor em bytes que o Squid informa à pilha TCP/IP (Transmission Control
Protocol / Internet Protocol) para o envio ao cliente.
Atributo “request method”
Atributo que representa o método HTTP da requisição (exemplo, “GET”, “POST”).
Atributo “URI”
Atributo
que
indica
o
endereço
web
da
requisição
“http://www.squid-cache.org/intro/who.html”, “http://www.univali.br”).
HTTP
(exemplo,
24
Atributo “client identity”
Atributo que indica o nome de usuário quando o recurso de autenticação de usuários
está ativado no Squid, caso contrário é utilizado um traço (caractere “-”).
Atributo “peering code/peerhost”
Campo que apresenta dois atributos divididos por uma barra (caractere “/”). Estes
atributos só tem relevância quando o conteúdo a ser buscado não foi encontrado no cache
local, então o conteúdo é buscado em outro servidor proxy irmão (caso exista), ou então
diretamente do servidor de origem. Caso o conteúdo tenha sido buscado no cache local, o
campo em questão apresentará seu conteúdo como “NONE/-”.
O primeiro atributo indica como o servidor com o conteúdo foi buscado (exemplo,
“DIRECT”, indicando que o conteúdo foi buscado diretamente do servidor de origem). Já o
segundo atributo indica o endereço IP do servidor onde foi buscado o conteúdo.
Atributo “content type”
Atributo que representa o tipo de conteúdo que foi buscado. Esta informação é obtida
pelo Squid obtendo-se o valor do atributo “Content-Type” do cabeçalho HTTP da requisição,
caso este atributo do cabeçalho não seja encontrado, o Squid utilizará um hífen (caractere “-”)
no campo em questão.
2.3.2 FONTE DO REGISTRO DE INFORMAÇÕES DE ACESSO
Foi utilizada uma base de registros de acessos do Squid obtidos em uma instalação
deste proxy na empresa onde o autor trabalha. Trata-se de uma leitura dos últimos meses de
acessos à Internet contendo o uso diverso por aproximadamente cinquenta pessoas, sendo as
mesmas de diversos setores da empresa, como diretoria, comercial, suporte, infraestrutura,
desenvolvimento, qualidade, recursos humanos e financeiro.
Os dados específicos capazes de identificar usuários de forma única foram mascarados
com representações equivalentes dos mesmos, assim protegendo a privacidade dos usuários.
25
2.4 OLAP (ONLINE ANALYTICAL PROCESSING)
Thomsen
(2002) define
OLAP
como
sendo um sistema
de informação
multidimensional. O autor associa o conceito de OLAP à noção de múltiplas dimensões
hierárquicas que podem ser utilizados por todos para a obtenção de informações, desde em
uma escala atômica (informação mais detalhada), como também em uma escala galáctica
(informação menos detalhada). Ou seja, a visão das informações se dá em um mundo
multidimensional e com diversos níveis.
O autor ainda aponta que o termo OLAP possui várias abordagens já que seus
elementos são manifestáveis em diversas camadas de tecnologia, que vão desde o
armazenamento e acesso até camadas de linguagem. Pode-se então discutir sobre conceitos
OLAP, linguagens OLAP, camadas de produto OLAP e produtos OLAP completos.
Os conceitos de OLAP, ainda segundo o autor, agregam as noções de múltiplas
dimensões, níveis e escalas. Nas linguagens OLAP, onde inclui-se linguagens formais como
DDL (Data Definition Language), DML (Data Manipulation Language), DRL (Data
Representation Language) e seus analisadores associados são utilizados para qualquer
modelagem descritiva transacional ou de suporte à tomada de decisão. As camadas de produto
do OLAP residem-se normalmente em cima de banco de dados relacionais, onde a partir de
determinadas combinações, geram SQL (Structured Query Language) como saída. Nesta
questão, o banco de dados fica responsável pelo armazenamento e o acesso aos dados. Já os
produtos OLAP completos que incluem métodos de acesso e armazenamento, são otimizados
para cálculos rápidos e acesso a dados, assim usando-se principalmente para modelagem
descritiva de dados.
Thomsen (2002) exemplifica o uso do formato de visualização de dados bidimensional
como sendo útil para qualquer tipo de controle, por exemplo, horas de funcionários, custo por
departamento. Neste caso, a variável de dimensão são dispostas nas colunas (horas
trabalhadas, horas extras) e outra dimensão identificadora (também conhecida como chave ou
localizadora) de funcionários que estarão dispostos nas linhas.
Em cima disso, pode-se adicionar uma terceira dimensão, que é chamada de produto.
Consequentemente, a visualização dos dados acaba se tornando um cubo. Aplicando-se esse
26
conceito à realidade proposta neste TTC em questão, pôde-se observar na Figura 4 a metáfora
visual do que seriam os dados apresentados para o usuário.
Figura 4. Metáfora visual para visualização dos dados de acessos do Squid
Fonte: Adaptado de Thomsen (2002).
Pode-se observar então na Figura 4 as três dimensões juntas formando um cubo, sendo
a primeira dimensão atribuiu-se variáveis que representam alguns dos atributos do registro de
acessos do Squid. Na segunda dimensão atribuiu-se os produtos, que no caso em questão está
utilizando-se do atributo de endereço IP do usuário da rede. Na terceira dimensão atribuiu-se
o tempo, que no caso em questão está agrupado em meses.
No entanto, o autor ressalta que devido a limitação da tela do computador – a tela do
computador é bidimensional – é necessário adaptar a forma de apresentar as informações na
tela. Devido a esta limitação, divide-se o cubo em fatias, onde cada fatia será uma página
(uma dimensão) e então dentro de cada página aparecerá mais duas dimensões com as
informações de acordo com a dimensão da página.
Dessa forma, o usuário que utilizará a ferramenta desenvolvida neste TTC poderá
definir os atributos coletados do registro de acessos do Squid em relatórios de duas ou três
dimensões.
27
2.5 POSTGRESQL
Riggs e Krosing (2010) descrevem o PostgreSQL como um avançado servidor de
banco de dados SQL de código-fonte aberto, disponível em uma grande gama de plataformas.
Além disso, o PostgreSQL é conhecido por ser um banco de dados que apresenta alta
disponibilidade, requisitando pouca manutenção e resultando em um baixo custo total de
propriedade.
O autor menciona ainda que o PostgreSQL possui uma grande gama de recursos
avançados que foram desenvolvidos ao longo de vinte anos de desenvolvimento contínuo. O
PostgreSQL foi originalmente desenvolvido pelo grupo de pesquisa em banco de dados da
Universidade da Califórnia e agora é desenvolvido por um grande time de colaboradores.
Muito desse colaboradores possuem trabalhos em tempo integral relacionados aos
PostgreSQL, trabalhando como desenvolvedores, designers, administradores de banco de
dados e instrutores. O autor destaca as principais funcionalidades:
•
Excelente compatibilidade com os padrões SQL (compatibilidade até o padrão
SQL 2008);
•
Arquitetura cliente-servidor;
•
Arquitetura desenhada para alta concorrência;
•
Altamente configurável e extensível; e
•
Excelente escalabilidade e performance com diversos recursos de tunning.
Os recursos apresentados anteriormente e também a familiaridade do autor deste TTC
com a ferramenta, fizeram do PostgreSQL como sendo o banco de dados escolhido para o
desenvolvimento deste TTC.
28
2.6 FERRAMENTAS SIMILARES
Optou-se por utilizar como fonte principal de busca de ferramentas similares a página
de sugestões de analisadores de registro de acessos do site oficial do Squid1. A partir desta
página, foram escolhidas as ferramentas mais citadas em listas de discussões e fóruns. Foram
escolhidas ao todo seis ferramentas, sendo três comerciais e três de código-fonte aberto, como
podemos ver em seguida:
•
SARG;
•
Calamaris;
•
Free-SA;
•
Redline Internet Access Monitor;
•
Firewall Analyzer; e
•
Sawmill.
Será realizada uma análise das ferramentas similares escolhidas para poder efetuar um
comparativo mais preciso com a ferramenta proposta para este trabalho. Diante disso, definiuse as seguintes métricas de análise:
•
Interface web;
•
Relatórios dinâmicos;
•
Controle de acesso à interface; e
•
Aplicação de conceitos OLAP.
Pode-se verificar a seguir, no Quadro 2, o resumo do comparativo, sendo que na
última linha encontra-se a ferramenta desenvolvida neste TTC (chamada Octopus). Nas
subseções subsequentes encontram-se as analises de cada ferramenta.
1
Endereço web: http://www.squid-cache.org/Misc/log-analysis.html
29
Quadro 2. Comparativo de ferramentas similares
Nome da
ferramenta
Interface web
Relatórios
dinâmicos
Controle de
Conceitos OLAP
acesso à interface
SARG
Atende
Não atende
completamente
Não atende
Análise
bidimensional
Calamaris
Atende
Não atende
completamente
Não atende
Não atende
Free-SA
Atende
Não atende
completamente
Não atende
Análise
bidimensional
Redline Internet
Access Monitor
Atende
parcialmente
Não atende
Análise
bidimensional
Firewall
Analyzer
Atende
Atende
completamente completamente
Atende
completamente
Análise
bidimensional
Sawmill
Atende
Atende
completamente completamente
Atende
completamente
Análise
bidimensional
Octopus
Atende
Atende
completamente completamente
Atende
completamente
Análise
tridimensional
Não atende
Como pode ser visto no Quadro 2, o Octopus (ferramenta desenvolvida neste TTC)
visa ser uma ferramenta flexível e simples de se utilizar. Para tanto, a ferramenta foi
implementada sob plataforma web, ou seja, é executada em um servidor web, fazendo com
que a ferramenta possa ser utilizada usando-se de um navegador web a partir de qualquer
computador na rede. Todas as ferramentas similares anteriormente apresentadas (com exceção
da Redline Internet Access Monitor) são ferramentas de plataforma web.
A característica de relatórios dinâmicos, se fez presente em apenas duas das
ferramentas similares apresentadas, ambas comerciais. Esse característica está presente
também na ferramenta Octopus.
A funcionalidade de controle de acessos de usuários à ferramenta só está presente em
duas ferramentas (ambas comerciais). Essa funcionalidade também está presente na
ferramenta Octopus.
Na questão de aplicação dos conceitos OLAP é onde a ferramenta proposta neste
trabalho se diferenciou das demais. Nas ferramentas similares, foram encontrados alguns
pontos que podem lembrar algum conceito OLAP, porém não de forma marcante. Porém, para
o Octopus, foi realizada uma fundamentação dos conceitos de OLAP para a aplicação do
mesmo na ferramenta.
30
2.6.1 SARG
Segundo Gangitano (2010), SARG (Squid Analysis Report Generator), é uma
ferramenta que analisa os registros de acesso de um proxy e permite que se visualize quais
sites os usuários estão navegando. O SARG suporta coletar os registros de acessos do Squid
(escopo deste TTC) e também do Microsoft ISA. O relatório gerado é em HTML (HyperText
Markup Language) e os arquivos HTML gerados são armazenados em um local definido na
configuração da ferramenta.
Figura 5. Captura de tela da ferramenta SARG na página inicial de
relatórios
Na Figura 5 pode-se observar a tela inicial do relatório do SARG. Na primeira tela em
questão, o SARG mostrará os períodos onde o SARG gerou os relatórios de acesso. No caso
da captura de tela em questão, existe apenas um período gerado, e o mesmo corresponde ao
intervalo de 06/06/2004 até 13/09/2004.
31
Figura 6. Captura de tela da ferramenta SARG no relatório de um usuário
Na Figura 6 tem-se a tela de relatório de um usuário em específico onde é listado os
domínios das páginas acessadas pelo mesmo e também alguns atributos relacionados à página
acessada (por exemplo, a soma dos tamanhos das requisições).
Pôde-se constatar após a análise da ferramenta utilizando como base as métricas
definidas na Seção 2.6:
•
Interface web;
◦ Resultado: Atende completamente;
◦ Motivo: Sempre que o SARG é executado, o mesmo gera diversos arquivos do
tipo HTML com os relatórios do último período não processado, e estes HTML
são acessados via servidor web;
•
Relatórios dinâmicos;
◦ Resultado: Não atende;
◦ Motivo: O mesmo gera os relatórios de estaticamente porque o SARG é
executado no servidor e então o mesmo gera arquivos HTML estáticos com os
relatórios já processados;
32
•
Controle de acesso à interface;
◦ Resultado: Não atende;
◦ Motivo: A ferramenta não possui qualquer tipo de funcionalidade nativa de
controle de acesso para visualização dos relatórios;
•
Aplicação de conceitos OLAP;
◦ Resultado: Análise bidimensional;
◦ Motivo: A ferramenta apresenta um conceito bidimensional básico.
2.6.2 CALAMARIS
Segundo Beermann (2007), o Calamaris é uma ferramenta escrita em Perl, que gera
um relatório a partir da análise do arquivo de registros de acessos de usuários em diversos
servidores proxy, que são eles:
•
Squid (escopo deste TTC);
•
NetCache;
•
Inktomi Traffic Server;
•
Oops! proxy server;
•
Novell Internet Caching System;
•
Compaq Tasksmar; e
•
Netscape/iplanet Web Proxy Server.
Segundo ainda o autor, o Calamaris oferece a possibilidade de geração do relatório
tanto em formato de texto puro como também em formato HTML. A ferramenta é chamada e
então realiza uma análise do arquivo de registro de acessos do Squid gerando um relatório do
período de acessos que consta no arquivo.
33
Figura 7. Captura de tela da ferramenta Calamaris no início do relatório
A Figura 7 refere-se ao início do relatório onde encontra-se um sumário das
estatísticas geradas pela ferramenta. As estatísticas apresentadas no relatório são estáticas,
sendo que foram geradas quando o HTML foi gerado. Além disso pode-se notar que as
estatísticas apresentadas são focadas principalmente ao administrador do servidor proxy, pois
apresentam métricas mais técnicas acerca do perfil de tráfego de dados.
Após a análise da ferramenta utilizando como base as métricas definidas na Seção 2.6,
pôde-se constatar:
•
Interface web;
◦ Resultado: Atende completamente;
34
◦ Motivo: A ferramenta possui a opção de geração de relatórios em formato
HTML, onde os mesmos são colocados em um servidor web para o acesso
externo;
•
Relatórios dinâmicos;
◦ Resultado: Não atende;
◦ Motivo: O relatório, em formato HTML, é gerado apenas quando a ferramenta
é executada, onde é gerado um relatório estático dos dados processados;
•
Controle de acesso à interface;
◦ Resultado: Não atende;
◦ Motivo: A ferramenta não possui qualquer tipo de funcionalidade nativa de
controle de acesso para visualização dos relatórios;
•
Aplicação de conceitos OLAP;
◦ Resultado: Não atende;
◦ Motivo: A ferramenta gera relatórios que não apresentam conceitos OLAP.
2.6.3 FREE-SA
Segundo Free-SA (2012), o Free-SA é uma ferramenta para análise de registro de
acessos do Squid bastante similar ao SARG. Entre suas principais diferenças em relação ao
SARG é sua maior performance, maior variedade de relatórios e um maior suporte aos
padrões HTML da W3C (World Wide Web Consortium) nos relatórios gerados no formato
HTML.
35
Figura 8. Captura de tela da ferramenta Free-SA na tela de escolha dos
períodos de tempo disponíveis
A Figura 8 demonstra a tela inicial da ferramenta com os períodos de tempo que
tiveram seus relatórios gerados. Como pode-se perceber, essa ferramenta funciona de forma
similar ao SARG no que tange aos relatórios serem gerados de forma estática.
Figura 9. Captura de tela da ferramenta FreeSA com os tipos de relatórios gerados
A Figura 9 demonstra a tela após a seleção de um período de relatórios apresentado na
Figura 8. Nesta tela, pode-se observar os tipos de relatórios que foram gerados pela
ferramenta dentro do período de tempo gerado e selecionado anteriormente. Pode-se
confirmar o número maior de tipos de relatórios em relação ao SARG.
36
Figura 10. Captura de tela da ferramenta Free-SA na
página de relatório de domínios acessados de um
usuário
Na Figura 10 apresenta-se um relatório gerado com a listagem de domínios acessados
por um usuário específico e mais alguns atributos relacionados.
Após a análise da ferramenta utilizando como base as métricas definidas na Seção 2.6,
pôde-se constatar:
•
Interface web;
◦ Resultado: Atende completamente;
◦ Motivo: A ferramenta gera seus relatórios em formato HTML, onde os mesmos
são colocados em um servidor web para o acesso externo;
•
Relatórios dinâmicos;
◦ Resultado: Não atende;
37
◦ Motivo: O relatório, em formato HTML, é gerado apenas quando a ferramenta
é executada, onde são gerados os relatórios estático de acordo com o período
não processado;
•
Controle de acesso à interface;
◦ Resultado: Não atende;
◦ Motivo: A ferramenta não possui qualquer tipo de funcionalidade nativa de
controle de acesso para visualização dos relatórios;
•
Aplicação de conceitos OLAP;
◦ Resultado: Análise bidimensional;
◦ Motivo: A ferramente apresenta estatísticas fixas que não exploram os
conceitos multidimensionais, apenas bidimensionais.
2.6.4 REDLINE INTERNET ACCESS MONITOR
Segundo Redline (2012), o Redline Internet Access Monitor é uma ferramenta
comercial para monitorar a eficiência do uso da banda de Internet por parte dos funcionários
de uma empresa. A ferramenta permite a visualização de quais usuários estão utilizando mais
a Internet, o que cada usuário está acessando além também de observar quanto tempo que o
usuário gasta na navegação. Além disso a ferramenta suporta diversos servidores proxy,
dentre eles o Squid, foco deste TTC. Na Figura 11 tem-se uma visão geral de uma das telas de
relatórios da ferramenta, mais especificamente, a tela de relatórios de acesso a sites dos
usuários.
38
Figura 11. Captura de tela da ferramenta Redline Internet Access Monitor
Como pôde-se notar na Figura 11, a ferramenta funciona sob plataforma desktop, ou
seja, é um aplicativo que possui um executável e o mesmo é aberto no próprio computador do
usuário onde deseja-se visualizar os acessos. Apesar disso, a ferramenta possui uma opção de
exportar um determinado relatório para o formato HTML, pode-se ver o resultado na Figura
12.
39
Figura 12. Captura de tela da ferramenta Redline Internet Access Monitor com o
relatório de uso diário exportado em HTML
Pode-se notar, na Figura 12, que o relatório exportado em HTML é simples é referente
a um relatório específico com atributos específicos que foram definidos dentro dos software.
Após a análise da ferramenta utilizando como base as métricas definidas na Seção 2.6,
pôde-se constatar:
•
Interface web;
◦ Resultado: Atende parcialmente;
◦ Motivo: A ferramenta é executada em plataforma desktop, o que acaba fazendo
necessário a instalação do mesmo em cada computador onde se acessará os
relatórios dos acessos do Squid;
•
Relatórios dinâmicos;
◦ Resultado: Atende completamente;
◦ Motivo: A ferramenta dispõem de diversas opções para a geração dos relatórios
utilizando-se diversos atributos e filtros;
•
Controle de acesso à interface;
40
◦ Resultado: Não atende;
◦ Motivo: A ferramenta não possui qualquer tipo de funcionalidade nativa de
controle de acesso para visualização dos relatórios;
•
Aplicação de conceitos OLAP;
◦ Resultado: Análise bidimensional;
◦ Motivo: A ferramenta apresenta levemente relatórios com conceito
bidimensional.
2.6.5 FIREWALL ANALYZER
Segundo ManageEngine (2012), o Firewall Analyzer é uma ferramenta de gerência de
rede para análise de logs de dispositivos de segurança de redes. A ferramenta é útil para
analisar os logs dos firewalls da rede, possibilitando assim a detecção de falhas de segurança
como tráfego de vírus, ataques, entre outros. Além disso, também é possível analisar outros
itens, como o uso da banda de rede, possibilitando identificar o perfil de uso do tráfego da
rede, além também de monitorar a navegação web de usuários da rede. Na Figura 13 tem-se a
tela inicial da ferramenta na página inicial de relatórios do Squid.
Figura 13. Captura de tela da ferramenta Firewall Analyzer na página inicial do
relatório
41
A captura de tela da Figura 13, apresenta no centro alguns gráficos básico de
utilização do Squid. Além disso, também é apresentado no menu localizado na parte esquerda
e no topo da tela outras opções para visualização dos demais relatórios. É fornecido também
opções para a geração de relatórios personalizando, disponibilizando filtros e restrição de
períodos. A ferramenta também permite a geração de um relatório de acesso geral de um
usuário, como apresentado na Figura 14.
Figura 14. Captura de tela da ferramenta Firewall Analyzer na página de relatório
de um usuário
Na Figura 14 pode-se observar a página de relatório de acesso da máquina de um
usuário da rede. Pode-se perceber também que o relatório em questão faz um apanhado das
principais estatísticas refentes ao dados de navegação do usuário. No menu da esquerda, é
oferecido outras opções de relatório com informações mais específicas acerca de cada tipo de
estatística.
42
Após a análise da ferramenta utilizando como base as métricas definidas na Seção 2.6,
pôde-se constatar:
•
Interface web;
◦ Resultado: Atende completamente;
◦ Motivo: A ferramenta é executada em um servidor web, permitindo assim que
a mesma possa ser acessada de qualquer máquina com navegador web;
•
Relatórios dinâmicos;
◦ Resultado: Atende completamente;
◦ Motivo: A ferramenta dispõem de diversas opções para a geração dos relatórios
utilizando diversos atributos e filtros;
•
Controle de acesso à interface;
◦ Resultado: Atende completamente;
◦ Motivo: A ferramenta dispõe da possibilidade de criação de usuários no
sistema para controle de acesso aos relatórios;
•
Aplicação de conceitos OLAP;
◦ Resultado: Análise bidimensional;
◦ Motivo: A ferramenta apresenta alguns conceitos de OLAP, principalmente no
que diz respeito ao conceito bidimensional.
2.6.6 SAWMILL
Segundo Sawmill (2012), o Sawmill é uma ferramenta para análise de logs que roda
nas principais plataformas. O mesmo suporta o processamento de diversos tipos de dados,
dentre eles o arquivo de registro de acessos do Squid. Pode-se observar na Figura 15 a tela
inicial da ferramenta.
43
Figura 15. Captura de tela da ferramenta Sawmill na página inicial
Na tela inicial da ferramenta, Figura 15, observa-se que o Sawmill é uma ferramenta
que dispõe de interface web, ou seja, o mesmo é executado em plataforma web, sendo
executado em um servidor web. Dessa maneira, pode-se acessar a ferramenta de qualquer
máquina da rede. Ainda na Figura 15, tem-se algumas estatísticas gerais e então é apresentado
no menu da esquerda diversos relatórios que são gerados em tempo real. Por exemplo, o
relatório de URLs acessadas pode ser visualizado na Figura 16.
44
Figura 16. Captura de tela da ferramenta Sawmill na tela de relatório de acessos
Na Figura 16 podemos observar o relatório com a listagem de acessos com alguns
atributos, como por exemplo, o endereço IP do cliente, usuário do cliente e o tipo do conteúdo
acessado. Para o aprimoramento da visualização das informações do relatório, pode-se utilizar
também as opções de filtros de atributos e de períodos de tempo disponíveis no menu
superior.
Após a análise da ferramenta utilizando como base as métricas definidas na Seção 2.6,
pôde-se constatar:
•
Interface web;
◦ Resultado: Atende completamente;
◦ Motivo: A ferramenta é executada em um servidor web, permitindo assim que
a mesma possa ser acessada de qualquer máquina com um navegador web;
•
Relatórios dinâmicos;
◦ Resultado: Atende completamente;
45
◦ Motivo: A ferramenta dispõem de diversas opções para a geração dos relatórios
permitindo a personalização dos mesmos com filtros de períodos de tempo e
atributos;
•
Controle de acesso à interface;
◦ Resultado: Atende completamente;
◦ Motivo: A ferramenta dispõe da possibilidade de criação de usuários no
sistema para controle de acesso aos relatórios;
•
Aplicação de conceitos OLAP;
◦ Resultado: Análise bidimensional;
◦ Motivo: A ferramenta apresenta alguns conceitos de OLAP aplicados, como
relatórios bidimensionais.
46
3 DESENVOLVIMENTO
Neste capítulo são documentados o projeto do software desenvolvido bem como sua
implementação e validação. Primeiramente será apresentada a modelagem do software, com
utilização da UML, onde será apresentado diversos itens como o levantamento de requisitos,
modelos de classes, modelos de casos de uso e modelo do banco de dados. Segundo Pedrycz e
Peters (2001), nesta etapa é feita a descrição das principais funcionalidades de um software,
bem como seu fluxo, comportamento e atributos. Basicamente é fornecido a estrutura básica
para o desenvolvimento de um software.
Após a etapa de modelagem, será apresentada a etapa do trabalho que contempla a
implementação da ferramenta, que por sua vez é composta por dois módulos cuja
implementação é demonstrada na Seção 3.2. Subsequentemente será apresentado o processo
de validação da ferramenta com a finalidade de atestar o atendimento aos objetivos deste
trabalho.
3.1 MODELAGEM DO SOFTWARE
O software foi divido basicamente em dois módulos. O módulo coletor, que faz a
leitura dos dados gerados pelo servidor proxy Squid e os salva em um banco de dados, e o
módulo interface de visualização, que fornecerá a interface para geração de relatórios.
Serão apresentados os seguintes artefatos:
•
Levantamento de requisitos;
◦ Um diagrama de regras de negócio;
◦ Um diagrama de requisitos funcionais;
◦ Um diagrama de requisitos não funcionais;
•
Dois diagramas de modelo de classes;
•
Um diagrama de modelo de casos de uso;
•
Um diagrama entidade relacionamento – conhecido também como modelo ER
(Entity-relationship) – do banco de dados; e
•
Dois protótipos de tela.
47
3.1.1 LEVANTAMENTO DE REQUISITOS
O levantamento de requisitos do projeto será constituído pelos requisitos funcionais,
requisitos não funcionais e as regras de negócio. Os mesmos serão listados nas subseções não
numeradas a seguir.
Requisitos funcionais
Baseando-se nas funcionalidades esperadas, foi identificado os seguintes requisitos
funcionais:
•
RF01: O usuário poderá se autenticar no sistema;
•
RF02: O administrador poderá criar, editar e excluir outros usuários;
•
RF03: O usuário do sistema poderá acessar o relatório tridimensional;
•
RF04: O usuário do sistema poderá acessar o relatório bidimensional;
•
RF05: O relatório tridimensional deverá permitir a escolha de um período de
tempo, atributos visíveis, ordenação, filtros de atributos e a definição do atributo
da terceira dimensão;
•
RF06: O relatório bidimensional deverá permitira escolha de um período de
tempo, atributos visíveis, ordenação e filtros de atributos;
•
RF07: O administrador poderá definir se outro usuário é administrador ou não; e
•
RF08: O usuário poderá alterar sua senha.
Requisitos não funcionais
Foram definidos os seguintes requisitos não funcionais:
•
RNF01: A senha dos usuários do sistema deve ser armazenada de forma
criptografada em hash MD5 no banco de dados;
•
RNF02: Somente usuários autenticados podem acessar o sistema;
•
RNF03: Qualquer página do sistema deverá ser carregada em no máximo 5
segundos em condições normais de rede, com o servidor de relatório e banco de
48
dados com um hardware de no mínimo um processador Intel Core 2 Duo 2,13Ghz,
com 3 GB de memória e disco de armazenamento padrão SATAII e o banco de
dados contendo 1 milhão de registros de acessos;
•
RNF04: A interface de visualização de relatórios deverá funcionar nos
navegadores Mozilla Firefox 12, Google Chrome 18 e Microsoft Internet Explorer
8;
•
RNF05: O módulo coletor será implementado utilizando-se a linguagem de
programação Python;
•
RNF06: O módulo de interface de visualização será desenvolvido na linguagem
PHP utilizando-se o framework Symfony; e
•
RNF07: O SGBD (Sistema de Gerenciamento de Banco de Dados) usado será o
PostgreSQL.
Regras de negócio
Foram identificadas as seguintes regras de negócio no sistema:
•
RN01: Somente os usuários autorizados a monitorar os dados de navegação podem
acessar o sistema; e
•
RN02: O servidor proxy utilizado é o Squid.
3.1.2 MODELO DE CASOS DE USO
Os casos de uso são úteis para modelar as funcionalidades que os usuários utilizarão
no sistema, ou seja, é possível ter uma visão geral dos recursos que serão oferecidos pelo
software proposto. (PENDER, 2004).
É apresentado a seguir, na Figura 17, o diagrama dos casos de uso descrevendo os
recursos da ferramenta proposta neste trabalho. A visão detalhada de cada caso de uso é
apresentada no APÊNDICE A..
49
Figura 17. Diagrama do modelo de casos de uso
Na Figura 17 observa-se seis casos de uso referentes ao projeto do módulo de interface
de visualização. Tem-se dois perfis específicos de usuários, o “Gestor” e o “Administrador”.
O perfil “Gestor” refere-se aos gestores da determinada empresa que teriam acesso ao painel
de visualização de relatórios. Já o perfil “Administrador” refere-se ao administrador da
ferramenta que terá a tarefa de gerir os usuários autorizados a visualizarem os relatórios. Cada
um dos dois perfis possui seu ator com mesmo nome. Além disso, existe outro ator que
representa os dois atores especializados citados anteriormente, utilizado para os casos de uso
que podem ser realizados tanto pelo ator “Gestor” e o ator “Administrador”.
A gestão de usuários conta com quatro casos de uso (UC01.01 ao UC01.04). O
primeiro caso de uso, identificado como UC01.01, refere-se ao processo de autenticação do
sistema (obrigatório para poder acessar qualquer parte da ferramenta). O segundo caso de uso
é identificado como UC01.02 e diz respeito ao processo de alteração de senha do usuário
atualmente autenticado. O terceiro caso de uso é identificado como UC01.03 e diz respeito ao
processo de criação, edição e exclusão de usuários, que é executado apenas pelo perfil
“Administrador”. O quarto caso de uso é identificado como UC01.04 e diz respeito ao
50
processo de definição, por parte do perfil “Administrador”, se um usuário fará parte do perfil
“Administrador” ou não.
A geração de relatórios conta com dois casos de uso (UC01.05 e UC01.06). O
primeiro caso de uso, identificado como UC01.05, diz respeito à geração de relatório
bidimensionais, juntamente com suas opções de filtragem e ordenação. O segundo caso de uso
é identificado como UC01.06 e diz respeito à geração de relatórios tridimensionais,
juntamente com a aplicação de alguns conceitos OLAP, seleção de pivôs e outras opções de
filtragem e ordenação.
3.1.3 MODELO DE CLASSES
Na seção em questão, foi apresentado um diagrama de classes de domínio para o
módulo coletor, Figura 18, e outro diagrama de classes de domínio para o módulo interface de
visualização, Figura 19.
As classes descritas nos diagramas apresentam sua identificação, principais atributos e
principais métodos. A visão detalhada dos modelos de classes dos diagramas está no
APÊNDICE B..
51
Módulo coletor
Figura 18. Diagrama do modelo de classes do módulo coletor
A Figura 18 apresenta o diagrama o diagrama de modelo de classes do módulo coletor.
Nela pode-se observar a presença de duas classes, sendo que a primeira chama-se
“SquidLogFile” que representa o arquivo com os registros de acessos do Squid, sendo que a
mesma possui um atributo com a localização do arquivo dentro do sistema de arquivos local
além de um método principal utilizado para iniciar o processamento do arquivo. Já segunda
classe, chama-se “SquidAccessLogRequest”, que representa cada registro do arquivo de
registros de acessos do Squid, sendo que seus atributos estão fundamentados na Subseção
2.3.1.
52
Módulo interface de visualização
Figura 19. Diagrama de modelo de classes do módulo interface de visualização
A Figura 19 apresenta o diagrama de modelo de classes do módulo interface de
visualização. Pode-se observar a presença de duas classes. A primeira classe chama-se “User”
e representa o cadastro de usuários autorizados a acessar a ferramenta Octopus, juntamente
com alguns atributos como o nome completo, senha, e-mail e se possui direitos
administrativos. Já a segunda classe, representa cada registro de acesso do Squid que está
armazenado no banco de dados, seus atributos estão fundamentados na Subseção 2.3.1.
3.1.4 DIAGRAMA ENTIDADE RELACIONAMENTO (MODELO ER)
O software utiliza o SGBD PostgreSQL para armazenar todo os registros de acessos
(alimentado pelo módulo coletor e acessado/visualizado pelo módulo interface de
visualização). Além disso, será armazenado também o cadastro de usuários que podem
acessar o módulo interface de visualização para a geração de relatórios, como pode ser visto
no diagrama na Figura 20.
53
Figura 20. Diagrama modelo entidade relacionamento (modelo ER)
No diagrama em questão, na Figura 20, é mostrado o modelo ER do banco de dados.
O banco de dados será composto por duas tabelas, sendo a primeira chamada “user”,
responsável por armazenar o cadastro de usuários que terão acesso autorizado para utilizar a
ferramenta. Esta tabela armazenará as informações de nome completo, senha, e-mail e se o
usuário possui direitos administrativos na ferramenta. Já a tabela “squid_access_log_request”,
ficará responsável por armazenar cada requisição que o Squid registrar em seu arquivo de
registros de acessos utilizando os atributos disponíveis pelo mesmo, fundamentados na
Subseção 2.3.1.
No APÊNDICE C. é apresentado a visão detalhada do modelo.
3.1.5 PROTÓTIPO DE TELA
Para melhorar o entendimento sobre os relatórios da ferramenta Octopus, optou-se por
elaborar dois protótipos de tela demonstrados na Figura 21 e Figura 22. Os protótipos foram
desenhados utilizando a ferramenta Balsamiq Mockups.
54
Figura 21. Protótipo de tela do relatório bidimensional
Na Figura 21 podemos visualizar um relatório bidimensional onde tem-se na parte
superior um filtro de período de tempo, seleção de campo visíveis e uma tabela com as
informações de acesso de acordo com a configuração selecionada pelo usuário.
55
Figura 22. Protótipo de tela do relatório tridimensional
Na Figura 22 tem-se o protótipo de tela do relatório tridimensional, onde pode-se
observar na parte superior, o filtro de período de tempo por data e hora, além também da
seleção de campos visíveis que permite o usuário escolher a quantidade de atributos que
deseja visualizar. Já na parte central do relatório, observa-se a tabela com as informações de
acesso, onde junto com a tabela, na parte superior, tem-se as abas que referem-se ao atributo
de usuário autenticado do Squid. Dessa maneira, as abas funcionam como as fatias do cubo de
informações presentes na tela, sendo assim, tem-se a terceira dimensão.
3.2 IMPLEMENTAÇÃO DA FERRAMENTA
A implementação da ferramenta proposta foi divida em duas partes, ou ainda, em dois
módulos: (i) Implementação do módulo coletor, responsável pela coleta das informações
brutas do servidor proxy Squid onde serão salvar em um banco de dados; (ii) Implementação
do módulo de interface de visualização, responsável pela interface de geração de relatórios.
56
3.2.1 IMPLEMENTAÇÃO DO MÓDULO COLETOR
O módulo coletor foi desenvolvido na linguagem de programação Python. Utilizou-se
duas classes principais conforme especificado na subseção 3.1.3.
Figura 23. Classe “SquidAccessLogRequest” do
módulo coletor
A Figura 23 demonstra a classe “SquidAccessLogRequest”, onde pode-se observar os
seus atributos. Cada atributo da classe em questão se refere ao seu respectivo campo contido
em um linha do arquivo de registro de acessos do Squid – que por sua vez, representa uma
requisição de um usuário da rede.
Figura 24. Classe "SquidLogFile" do módulo coletor
(método "parse" recolhido)
57
Na Figura 24, pode-se observar a classe “SquidLogFile”, que representa o arquivo de
registro de acessos do Squid. Na classe em questão, tem-se um construtor que definirá a
localização do arquivo de registro de acessos do Squid ao se realizar o instanciamento do
objeto. Além disso, tem-se o método “clean”que realiza a limpeza do arquivo de registro de
acessos do Squid. Tem-se também o método “parse”, onde será realizado o processamento do
arquivo de registro de acessos do Squid. O método “parse” realiza primeiramente a leitura do
arquivo de registro de acessos do Squid, sendo que após o término, é realizada a limpeza do
arquivo. Logo após essa etapa, é realizada então um laço que percorre todos os acessos
registrados no arquivo criando os objetos correspondentes a todos os registros, juntamente
com suas informações recolhidas de cada campo do arquivo de registro de acessos do Squid.
Após todo esse processo, ao final da execução do módulo em questão, os objetos serão
persistidos em banco de dados.
3.2.2 IMPLEMENTAÇÃO DO MÓDULO DE INTERFACE DE
VISUALIZAÇÃO
O módulo de interface de visualização foi desenvolvido utilizando-se a linguagem de
programação web PHP, juntamente com o framework Symfony versão 2.2. Além disso,
utilizou-se um framework de interfaces HTML chamado Twitter Bootstrap. Com o mesmo,
foi possível criar e manipular a interface das páginas de maneira fácil e com alguns estilos pré
definidos.
Para a melhor organização da implementação, foram criados três bundles (ou pacotes):
•
OctopusFrontendBundle: Pacote que contém a entidade referente aos registros de
acessos do Squid (camada de modelo), bem como as camadas de controle e de
visão de toda a ferramenta, com exceção da seção de autenticação de usuários da
ferramenta;
•
OctopusSecurityBundle: Pacote que conterá a camada de controle e de visão
referente a seção de autenticação de usuários da ferramenta; e
•
OctopusUserBundle: Pacote que conterá a camada de modelo de usuário, ou seja,
conterá a entidade que representa um usuário na ferramenta.
58
Entidades
Na camada de modelo da implementação, conforme a especificação elaborada na
Seção 3.1, foram criadas duas classes, juntamente com as suas respectivas anotações
referentes ao seu mapeamento para persistência no banco de dados. A primeira classe, é a
“SquidAccessLogRequest”, criada dentro do pacote “OctopusFrontendBundle”. A classe em
questão conterá as informações que constituirão cada registro de acesso ao Squid.
A segunda classe de modelo criada, é a classe “User”, criada dentro do pacote
“OctopusUserBundle”, que representa o usuário que irá utilizar a ferramenta para a
visualização dos relatórios. A classe em questão, conterá as informações que constituirá a
entidade de representação de um usuário da ferramenta.
Autenticação
O Symfony tornou a implementação da autenticação uma tarefa simples de executar.
Foi necessário editar o arquivo “app/config/security.yml” e definir algumas configurações:
•
Algoritmo de criptografia de senha: MD5;
•
Entidade de usuário: “Octopus\UserBundle\Entity\User”;
•
Credenciais de autorização;
◦ “ROLE_USER”: Credencial de usuário normal;
◦ “ROLE_ADMIN”: Credencial de administrador;
•
Área segura: Definiu-se que o sistema inteiro necessitará de autenticação (com
exceção da página de autenticação), sendo que ao acessar as páginas protegidas
sem possuir a credencial necessária ou sem estar autenticado, a página será
redirecionada para o formulário de autenticação.
59
Figura 25. Captura de tela do formulário de autenticação do sistema
A Figura 25 demonstra a tela de autenticação do sistema com os campos de e-mail e
“Password” (senha), onde após inseridas as informações corretas de e-mail e senha, o acesso à
ferramenta será concedido.
Relatório bidimensional
A tela de relatórios bidimensionais gera um relatório em uma tabela onde os dados são
mostrados em duas dimensões. A tela é demonstrada na Figura 26 e na Figura 27.
60
Figura 26. Captura de tela do relatório bidimensional com destaque para os parâmetros
A Figura 26 demonstra a tela do relatório bidimensional com os parâmetros para
configuração do relatório. Da esquerda para a direita, observa-se primeiramente a seleção do
intervalo de data e hora para o relatório, “Date & Time range”. Após o mesmo, tem-se a
seleção das colunas a serem exibidas no relatório, subsequentemente observa-se o “Column
filter” que permite filtrar uma determinada coluna por um determinado padrão de texto ou
números a ser informado no campo “Filter text”. Por último, o “Order by” permite selecionar
o campo a ser utilizado para ordenação e sua orientação, ascendente “ASC” ou descendente
“DESC”. Além disso, há o botão “Save current query” que fornece a possibilidade de salvar a
consulta em questão para um fácil acesso posterior. A tabela com o relatório se encontra mais
abaixo na página, onde há o título “Result”, como observa-se na Figura 27.
61
Figura 27. Captura de tela do relatório bidimensional com destaque ao relatório
Na Figura 27 observa-se o relatório bidimensional que localiza-se na mesma da Figura
26, porém abaixo no título “Result” citado anteriormente. Pode-se observar que ao lado do
título “Result” existe alguns dados referentes à quantidade dos dados que estão sendo
visualizados na página atual e o total encontrado. Mais abaixo observa-se as informações
sobre o número da página de resultados atuais acompanhado do total de páginas de resultado.
Ao lado direito e esquerdo tem-se os botões “Previous page” (para ir à página anterior) e
“Next page” (para ir à próxima página). Mais abaixo se observa o relatório de fato, gerado de
acordo com os parâmetros de configuração demonstrados na Figura 26.
Já a lógica de criação do relatório localiza-se na ação “twoDimensional” dentro da
classe controle “ReportController” no pacote “OctopusFrontendBundle”.
62
Relatório tridimensional
A tela de relatórios tridimensionais gera um relatório utilizando-se de uma estrutura
tabular, porém utilizando dois pivôs na parte da esquerda que representarão duas das três
dimensões, sendo que a terceira dimensão, as das medidas, ficará na parte da direita. Na
implementação da tela em questão, a camada da visão foi implementada no arquivo
“threeDimensional.html.twig”. A tela é demonstrada na Figura 28 e na Figura 29.
Figura 28. Captura de tela do relatório tridimensional com destaque para os parâmetros
Na Figura 28 observa-se a parte superior da tela de relatórios tridimensionais. Na parte
da tela em questão, pode-se selecionar o intervalo de data e hora referente à fatia do cubo que
se deseja visualizar. Ao lado, tem-se a seleção de medidas a serem visualizadas na parte da
direita no relatório demonstrado na Figura 29. A direita tem-se outro parâmetro para seleção,
que é a dos pivôs, onde seleciona-se os campos que serão utilizados como dimensões e
estarão localizados na parte esquerda do relatório demonstrado na Figura 29. Juntamente com
63
os parâmetros de seleção de pivôs, estão os respectivos parâmetros de ordenação “ASC”
(ascendente) e “DESC” (descendente). Além disso, há o botão “Save current query” que
fornece a possibilidade de salvar a consulta em questão para um fácil acesso posterior.
Figura 29. Captura de tela do relatório tridimensional com destaque para o relatório
tridimensional
Observa-se na Figura 29 a parte inferior da tela de relatório tridimensionais,
localização de fato do relatório. Semelhantemente ao relatório bidimensional, no topo
apresenta-se algumas informações referentes aos resultados exibidos além de informar o
número da página atual e o total de páginas juntamente com os botões de navegação entre as
páginas de resultados. Pode-se ainda destacar, na Figura 29, a metáfora das três dimensões
que são representadas. Como mencionado anteriormente, tem-se na direita as “Measures”
(medidas, ou métricas) que representam uma dimensão. Já na esquerda, tem-se os dois pivôs
que representam mais duas dimensões. Pode-se notar também que é possível clicar sobre os
valores apresentados nas duas colunas de pivôs, fazendo com que seja apresentado uma fatia
de resultados de acordo com o valor clicado.
Já a lógica de criação do relatório localiza-se na ação “threeDimensional” dentro da
classe controle “ReportController” no pacote “OctopusFrontendBundle”.
64
Gerenciamento de usuários
A ferramenta permite que um usuário troque sua senha, permite que um administrador
crie um novo usuário, permite que o administrador visualize as contas existentes além de
permitir que o administrador edite e exclua outro usuário.
Figura 30. Captura de tela da listagem de usuários
Observa-se na Figura 30 a tela administrativa de listagem de usuários, onde na parte
superior, é fornecido um botão para realizar a criação de novos usuários para a ferramenta. Na
listagem de usuários, observa-se os diversos dados que compõem um usuário da ferramenta,
sendo que na coluna da direita, é apresentado duas ações para cada usuário, “Edit” (editar um
usuário) e “Remove” (remover um usuário).
Consultas salvas
Como citado anteriormente, o usuário da ferramenta poderá salvar as consultas ao
relatório bidimensional e ao relatório tridimensional para facilitação do acesso posterior. As
consultas salvas, estarão disponíveis na página inicial da aplicação como demonstrado na
Figura 31.
65
Figura 31. Captura da tela inicial da ferramenta juntamente com a listagem de consultas salvas
Na Figura 31, pode-se observar a tela inicial da ferramenta, sendo que na parte inferior
da tela, encontra-se a listagem das consultas salvas, juntamente com uma opção de remover as
mesmas.
3.3 TESTES FINAIS DA FERRAMENTA
A fim de validar o funcionamento da ferramenta, foram realizados alguns testes finais
no mesmo. Para cada teste, serão definidos os seus parâmetros seguidos pela descrição da
execução do teste juntamente com a aferição do resultado esperado.
3.3.1 TESTE 1: NÚMERO REQUISIÇÕES COLETADAS
Para o teste em questão, foram definidos os seguintes parâmetros:
•
Base de dados: Arquivo de registro de acessos do Squid com cindo mil linhas de
acessos variados;
66
•
Descrição do teste: Realizar a importação de um arquivo de registros de acessos
utilizando o módulo coletor e então aferir o número total de registros importados
através de uma pesquisa sem filtros na interface de visualização de relatórios; e
•
Resultado esperado: Relatório com resultado total de cinco mil registros.
Executou-se o módulo coletor, o mesmo leu o arquivo e converteu para o banco de
dados todos os registros sem apresentar nenhum erro, como demonstrado no Quadro 3.
:: Starting @ 2012-11-01 18:05:40.858041 ::
Connecting do database...
Opening access log file...
Found 5000 Squid access requests.
Parsing log file...
Saving to database...
Closing database connection...
:: Finished @ 2012-11-01 18:06:40.611274 ::
No Quadro 3, observa-se a saída do comando de execução do módulo coletor. Nota-se
que o tempo total de sua execução foi de cerca de um minuto.
Com a importação realizada, pôde-se observar no módulo de interface de visualização
os dados populados correspondendo com os dados contidos no arquivo de registro de acessos
do Squid. Em ambos os relatórios (bidimensional e tridimensional) ao se utilizar um
abrangente filtro de data (com intenção de englobar todos os registros que foram lidos do
arquivo de registro de acessos do Squid) o número total de resultados encontrados pode-se
observar na Figura 32.
67
Figura 32. Captura de tela no número total de resultados no banco de dados
Na Figura 32 pode-se visualizar a comprovação do sucesso deste teste, pois ao lado do
título “Result” tem-se as estatísticas de resultados informando que o total de resultados é
cinco mil, coincidindo com o resultado esperado deste teste.
3.3.2 TESTE 2: VERIFICAR OS SITES ACESSADOS POR UM
ENDEREÇO IP (USUÁRIO) DURANTE UM PERÍODO DE TEMPO
Para o teste em questão, utilizou-se uma base de dados com um dia inteiro de
utilização do servidor proxy na empresa em que o autor trabalha.
Para o teste em questão, foram definidos os seguintes parâmetros:
•
Base de dados: Utilização do servidor proxy na empresa que o autor trabalha no
dia cinco de setembro de dois mil e doze;
•
Descrição do teste: Acessar o relatório bidimensional e realizar um filtro pelo
endereço IP “192.168.1.199” no período de tempo entre as 8h e 17h48min do dia
cinco de setembro de dois mil e doze; e
•
Resultado esperado: 250 páginas de resultados e 24.906 registros encontrados.
68
O teste foi executado acessando-se a opção “Two dimensional report” (relatório
bidimensional) juntamente com a definição de alguns parâmetros como demonstrado na
Figura 33.
Figura 33. Teste 2 - Parâmetros do relatório bidimensional
Na Figura 33, pode-se observar a definição do intervalo de data e hora a serem
buscados, colunas a serem visualizadas, o filtro ao endereço IP do usuário e a ordenação das
requisições. Ao pressionar o botão “Apply filter”, será gerado o relatório apresentado na
Figura 34.
69
Figura 34. Teste 2 - Relatório bidimensional de acessos de um usuário específico
Na Figura 34 pode-se observar o relatório de fato gerado a partir dos parâmetros
definidos. Pode-se observar que foi encontrado um total de 24.906 registros organizados em
250 páginas, o que coincide com o resultado esperado para o teste.
3.3.3 TESTE 3: VERIFICAR OS MAIORES ARQUIVOS BAIXADOS
Para o teste em questão, foram definidos os seguintes parâmetros:
•
Base de dados: Acessos do dia cinco de setembro de dois mil e doze;
•
Descrição do teste: O teste consiste em constatar quais foram as maiores
requisições efetuadas (seja download direto, vídeos sob-demanda, entre outros); e
•
Resultado esperado: requisição realizada as 13h06min52s com tamanho
470.268.237 bytes e proveniente do endereço IP 192.168.1.199.
70
O teste foi executado acessando-se a opção a opção “Three dimensional report”
(relatório tridimensional) juntamente com a definição de alguns parâmetros como
demonstrado na Figura 35.
Figura 35. Teste 3 - Parâmetros do relatório tridimensional
Na Figura 35 pode-se observar primeira a escolha da fatia do cubo correspondente a
data de pesquisa, que foi definida para o dia cinco de setembro do ano de dois mil e doze e
dentro do intervalo de horário de trabalho (das 8h até 17h 48min). Foram selecionadas três
medidas, data e hora, endereço acessado e o tipo de conteúdo. Nenhum filtro de texto foi
aplicado. Além disso, foram selecionados dois pivôs. O primeiro pivô, é refere-se ao tamanho
da requisição e terá ordenação descendente, ou seja, do maior para o menor. O segundo pivô,
refere-se ao endereço IP do usuário que acessou o endereço e utilizará ordenação ascendente,
ou seja, do menor para o maior. Após clicar em “Generate report”, será gerado o relatório
apresentado na Erro: Origem da referência não encontrada.
71
Figura 36. Teste 3 - Relatório dos maiores arquivos baixados
Na Erro: Origem da referência não encontrada pode-se observar o relatório gerado. No
primeiro pivô da esquerda observa-se a coluna referente ao tamanho da requisição, já o
segundo pivô, corresponde ao endereço IP do usuário da requisição. Na primeira linha de
resultado, pode-se observar a requisição de maior tamanho, que possui o tamanho de
470.268.237 bytes (ou aproximadamente 450 Megabytes). Na requisição em questão, pode-se
observar que o mesmo trata-se de um vídeo visto no site YouTube que foi visualizado pelo
usuário de IP “192.168.1.199”..
72
4 CONCLUSÕES
Este trabalho consistiu em projetar e implementar uma ferramenta de código aberto
para a geração de relatórios para o servidor proxy Squid com aplicabilidade de alguns
conceitos de OLAP. A motivação do projeto se deu principalmente ao fato da dificuldade em
encontrar ferramentas de código aberto que forneçam interfaces intuitivas com altas curvas de
aprendizagem por parte dos usuários comuns, interfaces com flexibilidade na busca de
informações específicas, seja qual for o período de tempo escolhido, relatórios que permitam
controlar as informações a serem visualizadas conforme a necessidade,. quantidade de
informações exibidas além também de um controle de acesso de usuário à interface de
visualização das informações.
Foi elaborada a fundamentação teórica dos conceitos referentes a este trabalho, além
também de estudar o conceito de OLAP que serviu como base principalmente para a
funcionalidade de geração de relatório tridimensional desenvolvida neste trabalho. Terminada
esta etapa, elaborou-se o projeto de engenharia de software com todos os requisitos
levantados, onde gerou-se requisitos funcionais, requisitos não funcionais e regras de negócio,
além também da confecção dos modelos de casos de uso, modelos de classe, modelo de banco
de dados e protótipos de tela de baixa fidelidade das telas de relatórios bidimensionais e
tridimensionais. Com isso, foi possível guiar a implementação da ferramenta.
A etapa de implementação da ferramenta transcorreu sem maiores imprevistos. O
framework Symfony se mostrou uma ferramenta útil para o desenvolvimento de aplicações do
perfil da ferramenta Octopus. A implementação da ferramenta se deu de forma organizada
devida a forma do Symfony trabalhar com as divisões de camadas. Após o final da
implementação, os testes finais ocorreram sem problemas e atestaram o cumprimento dos
objetivos propostos.
Com a utilização da ferramenta Octopus, espera-se resolver a maioria dos problemas
que serviram de motivação para a elaboração deste trabalho. Pôde-se observar a melhoria na
interface e nas possibilidades de geração de relatórios, não ficando mais presos a modelos
estáticos como os da ferramenta SARG. Isto permite que se chegue de uma maneira muito
mais rápida e precisa à informação.
73
A ferramenta Octopus se transformará em um projeto público, onde contará com seu
código-fonte disponível na Internet e presente em um serviço de desenvolvimento
colaborativo, permitindo alavancar a evolução e a utilização da ferramenta.
4.1 TRABALHOS FUTUROS
Durante todo o projeto de desenvolvimento da ferramenta Octopus, foram
identificadas diversas funcionalidades que por estarem fora do escopo deste projeto, as
mesmas não foram incluídas, porém são funcionalidades interessantes para a evolução da
ferramenta tornando-a uma ferramenta mais completa e madura para ser adotada.
A fim de tornar a ferramenta mais completa no que tange à integração com o Squid,
mostra-se interessante a exibição de um módulo na ferramenta que explore as métricas de
funcionamento e estatísticas do servidor Squid. Ou seja, seriam informações de cunho mais
técnico, podendo-se assim visualizar informações de consumo de processamento, memória,
entrada e saída, configuração, requisições por segundo, eficiência do cache, entre outros.
Outro recurso interessante principalmente em meios corporativos, é a integração do
sistema de autenticação de usuários com o serviço de diretórios LDAP (Lightweight Directory
Access Protocol), permitindo assim o acesso da ferramenta a base de dados centralizada de
usuários de uma determinada empresa, facilitando o gerenciamento de usuários.
74
REFERÊNCIAS
BEERMANN, Cord. Calamaris. 2007. Disponível: <http://cord.de/tools/squid/calamaris/>.
Acesso em 4 jul. 2012.
FREE-SA. Free-SA: Description. 2012. Disponível: <http://sourceforge.net/projects/freesa/>. Acesso em 4 jul. 2012.
GANGITANO, Luigi. SARG. 2010. Disponível: <http://sarg.sourceforge.net/sarg.1.html>.
Acesso em 4 jul. 2012.
KUROSE, James F.; ROSS, Keith W. Redes de computadores e a Internet: Uma
abordagem top-down. 3 ed. São Paulo: Pearson Addison Wesley, 2006.
LOPES, Raquel V.; SAUVÉ, Jacques P.; NICOLLETTI, Pedro S. Melhores Práticas para
Gerência de Redes de Computadores. Rio de Janeiro: Editora Campus, 2003.
MANAGEENGINE. Firewall Analyzer: Firewall Log Analysis Software. 2012. Disponível:
<http://www.manageengine.com/products/firewall/>. Acesso em 4 jul. 2012.
MCCABE, James D. Network Analysis, Architecture, and Design. 3 ed. Burlington:
Morgan Kaufmann Publishers, 2007.
PEDRYCZ, Witold; PETERS, James F. Engenharia de software: teoria e prática. Rio de
Janeiro: Elsevier, 2001.
PENDER, Tom. UML, a bíblia. Rio de Janeiro: Elsevier, 2004.
REDLINE. Redline Software: Internet Access Monitor. 2012. Disponível:
<http://www.redline-software.com/eng/products/iam/>. Acesso em 4 jul. 2012.
RICCI, Bruno; MENDONÇA, Nelson. Squid – Solução Definitiva. Rio de Janeiro: Ciência
Moderna, 2006.
RIGGS, Simon; KROSING, Hannu. PostgreSQL 9 Administration Cookbook.
Birmingham: Packt Publishing, 2010.
SAWMILL. Sawmill: Features. 2012. Disponível: <http://www.sawmill.net/features.html>.
Acesso em 4 jul. 2012.
THOMSEN, Erik. OLAP Solutions: building multidimensional information systems. New
York: John Wiley & Sons, 2002.
WESSELS, Duane. Squid: The Definitive Guide. Sebastopol: O'Reilly, 2004.
75
GLOSSÁRIO
Código aberto
É um termo que refere-se também ao software livre. Basicamente
define o termo de liberdade de um software, onde respeita-se as quatro
liberdades definidas pela Free Software Foundation.
Framework
Abstração que une códigos comuns provendo uma funcionalidade
genérica.
Hash
Sequencia de bits gerados através de um algoritmo de dispersão. Essa
sequencia busca identificar um arquivo ou informação de forma única.
MD5
Algoritmo de hash de 128 bits unidirecional desenvolvido pela RSA
Data Security, Inc. É muito utilizado para verificação de integridade e
também para proteção de informações de autenticação.
PHP
Linguagem interpretada projetada para aplicações web.
PostgreSQL
Sistema de gerenciador de banco de dados objeto relacional de
código-fonte aberto.
Python
Linguagem de programação interpretada, imperativa e orientada a
objetos.
76
APÊNDICE A. DETALHAMENTO DOS MODELOS DE CASOS
DE USO
A.1 UC01.01 – REALIZAR LOGIN
Permite que o usuário tenha acesso ao sistema, através do fornecimento do e-mail e da
senha.
Requisitos
•
RF01: O usuário poderá se autenticar no sistema;
•
RN01: Somente os usuários autorizados a monitorar os dados de navegação podem
acessar o sistema.
Condições
•
Pré-condição: O usuário não deverá estar autenticado no sistema;
•
Pós-condição: O usuário estará autenticado no sistema.
A.2 UC01.02 – ALTERAR SENHA
Permite ao usuário alterar sua senha através do fornecimento da senha nova.
Requisitos
•
RF08: O usuário poderá alterar sua senha;
•
RNF01: A senha dos usuários do sistema deve ser armazenada de forma
criptografada em hash MD5 no banco de dados.
Condições
•
Pré-condição: O usuário deverá estar autenticado no sistema;
•
Pós-condição: O usuário terá uma nova senha para se autenticar no sistema.
77
A.3 UC01.03 – CRIAR, EDITAR E EXCLUIR USUÁRIO
Permite ao administrador criar, editar informações ou excluir um usuário do sistema.
Requisitos
•
RF02: O administrador poderá criar, editar e excluir outros usuários.
Condições
•
Pré-condição: O administrador deverá estar autenticado no sistema;
•
Pós-condição: As alterações na base de usuários serão aplicadas.
A.4 UC01.04 – DEFINIR OUTRO USUÁRIO COMO ADMINISTRADOR
OU NÃO
Permite ao administrador definir se outro usuário será administrador ou não.
Requisitos
•
RF07: O administrador poderá definir se outro usuário é administrador ou não.
Condições
•
Pré-condição: O administrador deverá estar autenticado no sistema;
•
Pós-condição: O usuário será administrador ou não.
A.5 UC01.05 – GERAR RELATÓRIO BIDIMENSIONAL
Permite ao usuário gerar relatórios bidimensionais podendo-se personalizar a escolha
de um período de tempo, atributos visíveis, ordenação e filtros de atributos.
Requisitos
•
RF04: O usuário do sistema poderá acessar o relatório bidimensional;
78
•
RF06: O relatório bidimensional deverá permitira escolha de um período de
tempo, atributos visíveis, ordenação e filtros de atributos.
Condições
•
Pré-condição: O usuário deverá estar autenticado no sistema;
•
Pós-condição: Gerado o relatório bidimensional.
A.6 UC01.06 – GERAR RELATÓRIO TRIDIMENSIONAL
Permite ao usuário gerar um relatório tridimensional podendo-se personalizar o
período de tempo, atributos visíveis, ordenação, filtros de atributos e a definição do atributo
da terceira dimensão.
Requisitos
•
RF03: O usuário do sistema poderá acessar o relatório tridimensional;
•
RF05: O relatório tridimensional deverá permitir a escolha de um período de
tempo, atributos visíveis, ordenação, filtros de atributos e a definição do atributo
da terceira dimensão.
Condições
•
Pré-condição: O usuário deverá estar autenticado no sistema;
•
Pós-condição: Gerado o relatório tridimensional.
79
APÊNDICE B. DETALHAMENTO DOS MODELOS DE
CLASSES
A seguir será apresentado as classes, e sua descrição, do módulo coletor e do módulo
interface de visualização.
B.1. Classes do módulo coletor
•
SquidLogFile: Classe que representa os arquivos com as informações de acesso do
servidor proxy Squid;
•
SquidAccessLogRequest: Classe que representa cada registro (linha) no arquivo de
informações de acesso do servidor proxy Squid, ou seja, cada acesso feito pelos
usuários será representado por um objeto da classe.
B.2. Classes do módulo interface de visualização
•
User: Classe que representa os usuários que acessam o sistema de relatórios;
•
SquidAccessLogRequest: Classe que representa cada registro de acesso no
servidor proxy Squid, registros esses que estão localizados no banco de dados. Ou
seja, cada objeto da classe, representa um acesso.
80
APÊNDICE C. DETALHAMENTO DO MODELO ENTIDADE
RELACIONAMENTO (MODELO ER)
C.1. Tabela “user”
Tabela para o armazenamento do cadastro de usuários que acessam o módulo interface
de visualização.
Atributos:
•
id;
◦ Tipo: INT;
◦ Descrição: código do usuário;
•
given_name;
◦ Tipo: VARCHAR(255);
◦ Descrição: primeiro nome;
•
surname;
◦ Tipo: VARCHAR(255);
◦ Descrição: sobrenome;
•
password;
◦ Tipo: CHAR(32);
◦ Descrição: senha do usuário criptografada com hash MD5;
•
is_admin;
◦ Tipo: BOOLEAN;
◦ Descrição: define se o usuário é administrador ou não;
•
e-mail;
◦ Tipo: VARCHAR(255);
◦ Descrição: endereço de e-mail.
81
C.2. Tabela “squid_access_log_request”
Tabela para o armazenamento dos dados de acesso coletados pelo módulo coletor.
Atributos:
•
id;
◦ Tipo: INT;
◦ Descrição: código identificador do registro de acesso;
•
timestamp;
◦ Tipo: timestamp;
◦ Descrição: Data e hora do acesso;
•
response_time;
◦ Tipo: INT;
◦ Descrição: tempo de duração da requisição;
•
client_adress;
◦ Tipo: VARCHAR(255);
◦ Descrição: endereço IP do cliente que está acessando algum site;
•
result;
◦ Tipo: VARCHAR(50);
◦ Descrição: resultado do cache (se veio do cache local ou do destino original);
•
status_code;
◦ Tipo: INT;
◦ Descrição: Código HTTP de retorno;
•
size;
82
◦ Tipo: INT;
◦ Descrição: tamanho da requisição pedida;
•
request_method;
◦ Tipo: VARCHAR(10);
◦ Descrição: método HTTP usado;
•
uri;
◦ Tipo: TEXT;
◦ Descrição: o endereço web acessado;
•
user;
◦ Tipo: VARCHAR(255);
◦ Descrição: Nome de usuário, para o caso de a autenticação estiver ativada no
Squid;
•
peering_code;
◦ Tipo: VARCHAR(100);
◦ Descrição: código informando como o servidor com o conteúdo foi alcançado;
•
peering_host;
◦ Tipo: VARCHAR(50);
◦ Descrição: IP do servidor que forneceu o conteúdo;
•
content_type;
◦ Tipo: VARCHAR(255);
◦ Descrição: content-type da resposta.