Desenvolvimento de uma aplicação web de análise de registos de utilização

Desenvolvimento de uma aplicação web de análise de registos de utilização Armindo Eugénio de Sousa Pereira Mestrado integrado em Engenharia de Redes e Sistemas Informáticos do Departamento de Ciência dos Computadores 2013 Orientador Engº Alexandre Gomes, Infoportugal S.A. Coorientador Prof. Doutor Miguel Coimbra, DCC-FCUP InfoAnalytics Todas as correções determinadas pelo júri, e só essas, foram efetuadas. O Presidente do Júri, Porto, ______/______/_________ “Os obstáculos não derrotam, apenas valorizam a batalha dos que nasceram para vencer.” Mick Jagger Agradecimentos Como é natural, não poderia realizar este trabalho sem fazer os devidos agradecimentos que, ao longo deste último ano, partilharam comigo momentos de alegria, tristeza, entusiasmo, desânimo e coragem... Começo por agradecer, indiscutivelmente, ao Professor Miguel Coimbra, que me acompanhou ao longo deste projeto, com o seu empenho e profissionalismo, apoio e critica, ajudando-me a crescer com os seus conselhos e sugestões oportunas. À empresa InfoPortugal S.A pela oportunidade que me foi concedida em trabalhar num ambiente profissional. Aos meus amigos: André Francisco, Pedro Bragança, Hugo Pessegueiro, Nino Rocha, Tiago Melo, José Pedro, André Gaspar, João Graça, José Antunes, Humberto Teixeira, Fátima Sampaio, Vânia Pedrosa e outros amigos que não menciono mas não menos importantes, que de uma forma direta ou indiretamente estiveram envolvidos no meu percurso académico. À minha família, pais e irmãos, por me terem apoiado nos momentos mais difíceis e pelo constante incentivo. À minha querida namorada pela ajuda, paciência e apoio ao longo deste ano. Mesmo que a palavra OBRIGADO signifique muito, não expressará por inteiro o quanto os vossos gestos de carinho foram importante para mim ao longo desta etapa. Atenção e delicadeza fazem-nos perceber quanto algumas pessoas são especiais na forma de ser e como são bem-vindas as suas ações. A todos, muito Obrigado! i Resumo O projeto aqui descrito tem como finalidade o desenvolvimento de uma aplicação web que seja capaz de analisar ficheiros log e surgiu da necessidade da InfoPortugal S.A. criar uma aplicação de análise de fluxo e comportamento dos utilizadores nos seus serviços. Deste modo, é possível obter melhorias dos serviços sem recorrer à divulgação de dados a terceiros, oferecendo um módulo complementar aos websites desenvolvidos pela empresa. A aplicação desenvolvida, com recurso à framework django, foi criada de raíz. A arquitetura de processamento de logs, os algoritmos de processamento de estruturas, o design da aplicação web, entre outros, são módulos criados descritos neste relatório. Assim e tendo em conta o resultado final obtido, a aplicação é capaz de analisar os caminhos mais comuns percorridos num website, identificar as paginas mais acedidas e numero de visitantes numa determinada hora e/ou num intervalo de horas, consultar erros de servidor ou cliente, alguns aspetos da taxa de abandono e por ultimo analisar as palavras mais pesquisadas. ii Abstract The project herein described is intended for developing a web application that is able of analyzing log files, emerging from need of InfoPortugal S.A. to create an application flow analysis and user behavior in their services. This way it’s possible to obtain better services without resorting to the disclosure of information to third parties, offering an additional building block to websites developed by the company. The application, developed using the django framework, was created from scratch. The log processing architecture, the structure processing algorithms, the web application design, among others, are modules created and described in this report. Taking into account the final result, the application is able to analyze the most common paths traversed in a website, identify the pages most commonly accessed and visitor load at a specific time and range of times, consult server errors or client, some aspects of the dropout rate and, finally analyze the most searched words. iii Conteúdo Conteúdo vii Lista de Tabelas viii Lista de Figuras ix 1 Introdução 1 1.1 Motivação .................................... 2 1.2 Enquadramento na empresa ......................... 2 1.3 Objetivos .................................... 3 1.4 Contribuições deste projeto .......................... 4 1.5 Estrutura do relatório .............................. 5 2 Conceitos e Tecnologias 6 2.1 Data Mining ................................... 6 2.1.1 Web Mining ............................... 6 2.1.1.1 Web structure mining .................... 7 2.1.1.2 Web content mining ..................... 7 2.1.1.3 Web usage mining ...................... 7 2.2 Estudos realizados ............................... 7 2.2.1 Principal fluxo ............................. 7 2.2.2 Taxa de rejeição ............................ 8 2.2.3 Pesquisas ................................ 8 2.3 Log Files .................................... 8 2.3.1 Server Log Files ............................ 8 2.3.2 Access Log ............................... 9 iv 2.4 Estruturas de dados .............................. 9 2.4.1 Tries ................................... 9 2.4.2 Hash Tables .............................. 10 2.5 Técnica ..................................... 10 2.5.1 Clustering ................................ 10 2.6 Tecnologias ................................... 10 2.6.1 Python .................................. 10 2.6.2 Framework Django ........................... 11 2.6.3 MySQL ................................. 11 2.6.4 JavaScript ................................ 11 2.6.5 jQuery .................................. 11 2.6.6 AJAX .................................. 12 2.6.7 JSON .................................. 12 2.6.8 Pickle .................................. 12 2.7 Aplicações existentes ............................. 12 3 Planeamento 14 3.1 Levantamento de requisitos .......................... 14 3.2 Interatividade .................................. 15 3.3 Organização e estruturação .......................... 16 4 Arquitetura do processamento de logs 17 4.1 Descrição dos dados log ............................ 17 4.2 Processamento de logs ............................ 19 4.2.1 Filtragem da informação ........................ 21 4.2.1.1 Filtragem de recursos .................... 22 4.2.1.2 Filtragem de web crawlers ................. 22 4.2.1.3 Filtragem por repetição ................... 22 4.2.1.4 Observações ......................... 23 4.3 Estrutura de dados ............................... 23 4.3.1 Principais fluxos ............................ 24 4.3.2 Páginas mais visualizadas numa determinada hora ou intervalo de horas ................................. 26 v 4.3.3 Número de visitantes que acederam ao website num determinado intervalo de horas ........................... 27 4.3.4 Códigos de status HTTP ........................ 28 4.3.5 Taxa de rejeição ............................ 29 4.3.6 Pesquisas ................................ 31 5 Arquitetura do processamento de pedidos 33 5.1 Parâmetros ................................... 34 5.2 Algoritmos .................................... 36 5.2.1 Depth-first search ........................... 36 5.2.2 Principais Fluxos ............................ 36 5.2.3 Páginas mais visualizadas numa determinada hora ou intervalo de horas ................................. 37 5.2.4 Número de visitantes que acederam ao website num determinado intervalo de horas ........................... 38 5.2.5 Códigos de status HTTP ........................ 38 5.2.6 Taxa de rejeição ............................ 39 5.2.7 Palavras Pesquisadas ......................... 39 5.3 Apresentação de resultados .......................... 39 6 Aplicação web 42 6.1 Tecnologias web ................................ 42 6.2 Sistema interativo ............................... 43 6.3 Diagrama sequência do sistema ....................... 43 6.4 Resultados ................................... 44 6.4.1 Fluxo .................................. 45 6.4.2 Visitas .................................. 46 6.4.3 Status .................................. 48 6.4.4 Taxa rejeição .............................. 49 6.4.5 Pesquisas ................................ 50 7 Conclusões 51 7.1 Objetivos realizados .............................. 51 7.2 Trabalho futuro ................................. 52 vi CAPÍTULO 1. INTRODUÇÃO 3 nacionais e internacionais na aquisição e produção de dados georreferenciados, assim como, na conceção, desenvolvimento e instalação de soluções para exploração de conteúdos digitais em plataformas como a web, equipamentos móveis e equipamentos de navegação entre outras. As suas competências e atividades são desenvolvidas de forma transversal desde a fotografia aérea, cartografia, produção de conteúdos editoriais georreferenciados, desenvolvimento de aplicações para a web, mobile e consultadoria em sistemas SIG, dando resposta a diversos desafios e procura do mercado [1]. De modo a continuar a alargar a oferta da empresa, desenvolveu-se este projeto que poderá funcionar como um módulo complementar aos websites desenvolvidos pela empresa. 1.3 Objetivos Este projeto tem como principal objetivo fazer um estudo dos dados de web armazenados em formato de ficheiro log (access log), o tratamento e respetivo processamento dos mesmos levando ao desenvolvimento de uma aplicação web de análise do comportamento do website de apoio ao cidadão e turismo www.escape.expresso.pt. Foi considerado relevante entender o comportamento dos utilizadores em três categorias distintas. Estas categorias permitem entender quais os serviços mais e menos atraentes. Estas são: a forma como os utilizadores encontram o website, as razões que os levam a permanecer e as razões que os levam a abandonar. Com estes estudos torna-se possível entender e melhorar a experiência dos utilizadores nos serviços em campos distintos. Da forma como os utilizadores encontram o website: •Identificar as palavras mais pesquisadas (internas e externas) •Quantificar os visitantes que acedem ao website numa determinada hora e/ou num intervalo horas Das razões que levam os utilizadores a permanecer no website: •Identificar os principais fluxos, ou caminhos mais comuns percorridos pelos utili- CAPÍTULO 1. INTRODUÇÃO 4 zadores nos serviços •Quantificar as páginas mais visualizadas numa determinada hora e/ou num intervalo de horas Das razões que levam os utilizadores a abandonar o website: •Identificar erros de servidor ou cliente (códigos de status Hypertext Tranfer Protocol (HTTP)) •Analisar as páginas que têm maior taxa de rejeição, não produzindo continuidade dos utilizadores nos serviços 1.4 Contribuições deste projeto A Infoportugal S.A dispõe de um elevado número de projetos desenvolvidos em plataformas web. Este projeto veio complementar a Infoportugal S.A numa área nova, na análise de dados de websites. Esta aplicação web possibilitará criar relatórios de análise elaborados, o que permitirá à empresa aplicar em vários projetos, internos ou de outsourcing. A estrutura Model-View-Controller (MVC) foi aplicada de forma a maximizar a reutilização dos módulos implementados. De entre todas as componentes modulares, que serão descritas mais tarde, destacam-se duas principais: Front end (criação de uma aplicação Web/interface com utilizador) foi criado com o intuito de que a sua utilização seja simples, prática, dinâmica e rápida, tornando-a intuitiva e usável na interpretação dos resultados obtidos, sendo estes mostrados em vários gráficos interativos. Back end (responsável pelo suporte ao front end) é composto por vários módulos distintos que têm como objetivo o tratamento dos dados e o respetivo processamento. Para além destas, destacam-se ainda outras, inseridas no contexto do Back end: •Criação de estruturas de dados adequadas para a importação dos dados de ficheiros log. •Criação de regras de filtragem da informação dos ficheiro log CAPÍTULO 1. INTRODUÇÃO 5 •Extração e sumarização da informação presente nos ficheiro log 1.5 Estrutura do relatório O presente relatório de estágio encontra-se organizado em sete capítulos distintos. Na introdução, Capítulo 1, introduz-se o tema do estágio no qual é feita uma breve descrição ao projeto desenvolvido na empresa, o seu respetivo enquadramento, bem como a motivação, finalizando com os principais objetivos a atingir no final do projeto e respetivo contributo deste projeto para a empresa. No Capítulo 2são descritos vários conceitos de forma a que o leitor fique com uma maior perceção sobre o tema e uma breve descrição de algumas tecnologias utilizadas no desenvolvimento do projeto de estágio. No Capítulo 3é descrito o planeamento, identificando os pontos a realizar, tal como as possíveis funcionalidades a desenvolver durante o projeto. No Capítulo 4é descrito todo o processo de desenvolvido, passando pelo processamento de dados e pela criação das estruturas de dados. No Capítulo 5é descrito como os pedidos de consulta da informação são processados. No Capítulo 6é apresentado a aplicação web, e o sistema interativo e os resultados da mesma. No último capítulo, Conclusão, são elaboradas todas apreciações globais do projeto. Referem-se também que os objetivos inicialmente propostos foram concluídos, assim como a exposição de alguns aspetos para o trabalho futuro. Capítulo 2 Conceitos e Tecnologias Durante o estágio foi relevante estudar alguns conceitos para extração/interpretação de dados tais como, Data Mining eWeb Mining e consolidar outros conceitos fundamentais para a realização do projeto. Neste capítulo estes conceitos serão definidos e brevemente explicados, identificando-se também algumas tecnologias relevantes para o projeto. 2.1 Data Mining Data Mining é o processo de extração/exploração de informação útil em grandes quantidades de dados como em base dados, textos, imagens ou web. Tem como principal objetivo a procura de conhecimento a partir de padrões e detetar relacionamentos sistemáticos entre variáveis, para criar novos conjuntos de dados que sejam válidos e compreensíveis [2]. 2.1.1 Web Mining Web mining consiste na aplicação de técnicas de data mining para extração de conhecimento a partir de dados da web [3]. OWeb mining pode ser classificado em três tipos: Web structure mining, Web content mining eWeb usage mining. 6 CAPÍTULO 2. CONCEITOS E TECNOLOGIAS 7 2.1.1.1 Web structure mining Web structure mining é o processo de descoberta de informações sobre a estrutura da web. Estuda o relacionamento entre as páginas da web e permite descobrir conhecimento útil através dos seus hiperlinks [2]. 2.1.1.2 Web content mining Web content mining consiste na descoberta de informação útil ou conhecimento do conteúdo através de documentos web. Estes documentos normalmente contêm vários tipos de dados, tais como, texto, imagem, áudio, vídeo, metadados e hiperlinks [3]. Um exemplo da utilidade desta categoria é classificar automaticamente páginas da web a partir dos seus temas. 2.1.1.3 Web usage mining Web usage mining tem como objetivo extrair informação útil e descoberta de padrões através dos dados gerados pelas transações do cliente-servidor de um servidor web. Os dados de utilização capturam a identidade ou origem dos utilizadores da web e o comportamento de navegação num website [2]. Estes dados são gerados e armazenados automaticamente no servidor através de access logs,referrer logs eagent logs. Este é o tipo de estudo que este projeto pretende levar a cabo. 2.2 Estudos realizados Nesta secção são descritos alguns conceitos relativos aos estudos que foram realizados na implementação. 2.2.1 Principal fluxo Entende-se por principal fluxo no projeto a análise dos caminhos mais frequentes percorridos por um utilizador desde de uma entrada no website até à sua saída. CAPÍTULO 2. CONCEITOS E TECNOLOGIAS 8 2.2.2 Taxa de rejeição A taxa de rejeição representa o número de visitantes que vê apenas uma página durante uma visita ao website. 2.2.3 Pesquisas Consiste no estudo da origem dos utilizadores através de motores de pesquisa, assim como as respetivas palavras-chave que originam o fluxo do tráfego. A origem pode ser interna. Compreender quais as palavras-chaves que conduzem mais visitantes para o website é uma das informações mais valiosas que podemos obter com este estudo pois permite futuramente eliminar ou reestruturar páginas pelas mesmas. 2.3 Log Files Um log file ou ficheiro log é um registo de dados num computador, isto é, um ficheiro onde um sistema computacional grava todos os registos de atividades. 2.3.1 Server Log Files Server log files é um ficheiro log com informação útil que é automaticamente criado e gravado por cada servidor, ou seja, o histórico de atividade do servidor. Um dos exemplos mais comuns é um web server log que mantém um histórico de pedidos das páginas, ou seja, quando um visitante acede a um website, um único pedido pode gerar múltiplas transações para a página solicitada e é gravado tudo o que acontece durante a sua sessão. A maior parte dos servidores web geram estes ficheiros log como um formato estendido em sequência de linhas. Na sua maioria todos os servidores web incorporados geram pelo menos dois tipos de ficheiros, access logs que mostram o que os visitantes acederam e um ficheiro de error log que mostra exceções geralmente fatais. Normalmente os servidores também suportam mais dois tipos de ficheiros log,referrer log que diz como os visitantes encontraram o website, ou seja, o que originou a sua visita e agent log que indica o navegador que eles usaram CAPÍTULO 2. CONCEITOS E TECNOLOGIAS 9 para aceder ao website [4]. 2.3.2 Access Log Access Logs, também conhecidos como Transfer Logs, são uma das mais importantes fontes de informação que podemos obter acerca dos visitantes de um website, pois quando os visitantes acedem ao site o servidor regista toda a comunicação feita entre o servidor e o navegador num ficheiro com vários campos de dados. A informação sobre o pedido pode incluir o endereço de Internet Protocol (IP) do cliente, data e hora, página solicitada, código de status Hypertext Tranfer Protocol (HTTP), bytes transitados. O agente e referência são comummente adicionados. Todos estes dados podem ser combinado num único ficheiro ou separados em logs distintos, como access log,error log ou referrer log. Se forem combinados num único ficheiro as entradas mais recentes são acrescentadas ao final do ficheiro. O método padrão de registar o acesso de servidores pelos navegadores é o Common Log Format. Outro formato usado é o Combined Log Format que é semelhante ao Common Log Format mas com dois campos de dados adicionais, o referrer log e o agent log [5]. 2.4 Estruturas de dados Nesta secção são descritas estruturas de dados elementares que foram utilizadas como base na criação das estruturas utilizadas. 2.4.1 Tries Uma Trie, cujo nome vem de retrieval, também chamada de prefix trie, é uma estrutura de dados do tipo árvore ordenada, em que uma posição na árvore define a chave com a qual o nó está associado, definindo um prefixo através dos nós que compõem o caminho da raiz até ele próprio. É usada para armazenar strings com prefixos comuns. As strings são armazenadas em nós folha [6]. CAPÍTULO 2. CONCEITOS E TECNOLOGIAS 10 2.4.2 Hash Tables Uma hash table é uma estrutura de dados de mapeamento de pares do tipo chavevalor em que existe uma função de mapeamento (função hash) que traduz uma chave em endereços de mapeamento das chaves num array associativo. A função hash fornece uma maneira de atribuição de índices para os dados de entrada de tal forma que os dados podem ser armazenados na posição de um array correspondente ao índice atribuído. As vantagens incluem um conjunto de operações extremamente eficientes para guardar, remover, aceder e verificar a existência de um valor. 2.5 Técnica Nesta secção é descrita uma técnica elementar utilizada. 2.5.1 Clustering Clustering é uma técnica para agrupamento de dados com propriedades em comum. Clustering tem sido uma das técnicas de analise de dados, sendo recorrentemente utilizada em diversas áreas, como por exemplo, medicina, psicologia, biologia, marketing, etc. Nos últimos anos, com o aumento dos documentos online e a expansão da web tornou-se numa técnica muito importante para analise web [2]. 2.6 Tecnologias Nesta secção são descritas algumas tecnologias utilizadas. 2.6.1 Python Python é uma linguagem de programação de alto nível interpretada e orientada a objetos com uma sintaxe limpa e clara. O Python partilha algumas caraterísticas de linguagem de scripts e também caraterísticas de algumas linguagens mais tradicionais. Um dos principais fatores é a sua extensibilidade nos vários recursos como as suas CAPÍTULO 2. CONCEITOS E TECNOLOGIAS 11 próprias bibliotecas padrão e os módulos/frameworks que foram desenvolvidos por programadores terceiros [7]. 2.6.2 Framework Django Django é uma framework de Python para desenvolvimento web de alto nível. O django possibilita que o desenvolvimento de aplicações web seja feito de forma fácil e rápida, proporcionando design prático e eficaz. O django foi criado no sentido de conseguir lidar com os prazos apertados das redações de jornalismo e o os requisitos bastantes rigorosos pelos programadores experientes que o criaram [8]. Utiliza o princípio DRY (Don’t repeat yourself), de modo à máxima reaproveitação de código. 2.6.3 MySQL O MySQL é um sistema de gestão de base de dados open source que utiliza linguagem de consulta estruturada, Structured Query Language (SQL), sendo o SQL uma linguagem de pesquisa declarativa padrão para base de dados relacionais. Com a sua velocidade, estabilidade, fiabilidade, compatibilidade e facilidade de uso torna-se uma das escolhas mais comuns para utilizar na web [9]. 2.6.4 JavaScript JavaScript é uma linguagem de programação que corre em navegadores web do lado do cliente, permitindo assim que sejam executados scripts pelo cliente não havendo necessidade de recorrer a qualquer tipo de software do servidor. Normalmente é o principal responsável pela maior parte da interatividade numa página web [10]. 2.6.5 jQuery É uma biblioteca JavaScript rápida, pequena e cheia de recursos, desenvolvida para simplificar os scripts do lado do cliente. A sintaxe de jQuery foi desenvolvida de forma a tornar mais simples a navegação do CAPÍTULO 2. CONCEITOS E TECNOLOGIAS 12 documento HyperText Markup Language (HTML), manipulação de eventos, criação de animações e desenvolver aplicações Asynchronous JavaScript and XML (AJAX) muito mais simples e fáceis de usar, permitindo também a criação de plugins [11]. 2.6.6 AJAX A sigla significa Asynchronous JavaScript and XML. Permite que as páginas web possam ser atualizadas de forma assíncrona, através da troca de pequenas quantidades de dados com o servidor. Isto é, permite atualizar partes de uma página web, sem a necessidade de recarregar a página inteira. 2.6.7 JSON A sigla significa JavaScript Object Notation (JSON) e é um formato de troca de dados leve, geralmente fácil para as máquinas gerarem e analisarem. É baseado num subconjunto da linguagem de programação JavaScript totalmente independente da linguagem, pois usa as convenções que são familiares a outras linguagens, tais como, C, C++, Pyhton, Java, Perl, entre outras. O JSON é construído sobre duas estruturas principais, sendo elas uma coleção de pares nome/valor e uma lista ordenada de valores [12]. 2.6.8 Pickle Pickle é um módulo Python com um algoritmo para serialização e deserialização de estruturas de objeto. A serialização é uma forma de converter de um dado ou um objeto para uma stream e a deseralização é a ação contrária [13]. 2.7 Aplicações existentes Existe no mercado várias aplicações de analise, como por exemplo, Mozenda [14], Funnel Web Analyzer[15], The Screaming Frog SEO Spider [16] e Google Analytics[17], sendo esta última possivelmente a mais reconhecida. O Google Analytics permite observar/analisar dados de categorias e subcategorias de CAPÍTULO 4. ARQUITETURA DO PROCESSAMENTO DE LOGS 19 podem-se ver os parâmetros, note-se que nem sempre a origem está disponível; 11. ”Mozilla/5.0 (W indowsNT6.1; rv : 6.0) Gecko/20100101 F irefox/19.0” é o useragent que mostra a informação sobre o navegador que o cliente usou para aceder ao website, incluindo o sistema operativo. Este pode conter vários tipos, como nome de robots, spiders, bots e outros mecanismos de indexação (tracking). Note-se que os ficheiros de access log são guardados automaticamente pelo servidor web diariamente. Cada ficheiro log com um tempo aproximado de 24 horas em registos, que normalmente são inicializados em média às 03 horas. 4.2 Processamento de logs Figura 4.1: Arquitetura de processamento de logs Ao longo deste capítulo é descrita a estrutura da implementação da aplicação e a relação que os módulos têm uns com os outros. Adicionalmente, é feita uma associação de cada processo aos módulos correspondentes na figura 4.1. O acesso remoto feito ao servidor onde os logs estão armazenados foi uma funcionalidade adiada, por requisito da aplicação, para uma versão futura. A versão atual CAPÍTULO 4. ARQUITETURA DO PROCESSAMENTO DE LOGS 20 apenas lida com dados locais, mas ficou claro desde o início que havia interesse em adaptar a aplicação para suportar essa funcionalidade. Desta forma, a classe que lida com a origem dos dados (1, Figura 4.1) foi separada da restante lógica da aplicação, para que no futuro esta adaptação seja simples. Os dados são armazenados numa pasta local. Esta pasta é considerada a origem dos dados (repositório de logs) e cada log lá presente será processado apenas uma vez. Foi criado um método para registar o nome de cada log num ficheiro de texto, que por sua vez, é sempre verificado e comparado com o novo log que vai ser lido para ser processado, se nessa lista já constar o nome do log, o ficheiro é ignorado. Para cada ficheiro presente no repositório de logs, o processo anterior procede delegando para scripts específicos. Após carregado o ficheiro log, o mesmo é partido em constituintes semânticas (2, Figura 4.1). A abordagem escolhida passa por separar os vários atributos da informação do log para apenas trabalhar com a informação necessária para cada objetivo proposto. Numa primeira fase são usadas expressões regulares (Figura 4.2), de forma sequencial, linha a linha, com o objetivo de extrair cada atributo da linha de um pedido. Após extraída, esta informação é guardada de forma temporária numa base de dados MySQL (3 e 5, Figura 4.1), cujos campos têm uma correspondência direta com os atributos extraídos (Figura 4.3). Sempre que é detetada uma linha corrupta (não havendo correspondência com o formato Combined Log Format) a mesma é ignorada e o administrador é notificado da ocorrência. (?P<origin >\d+\.\d+\.\d+\.\d+) (?P<identd >-|\w*) (?P<auth>-|[^\[ ]+) \[(?P<accesstime >.*?)\]\s "(?P<method >\w+)(?P<path >[\S]+)(?P<protocol >[^"]+)" (?P<status >\d+) (?P<bytes >-|\d+) ((?P<referrer >"[^"]*")((?P<agent>"[^"]*")((?P<cookie >"[^"]*"))?)?)?\s*\Z Figura 4.2: Código das expressões regulares utilizadas no parse dos logs CAPÍTULO 4. ARQUITETURA DO PROCESSAMENTO DE LOGS 21 CREATE DATABASE escape_log; CREATE TABLE escape_log.log_entry( lid INT UNSIGNED NOT NULL AUTO_INCREMENT, origin CHAR(20) NOT NULL , accesstime TIMESTAMP NOT NULL , auth VARCHAR(50), req_path TEXT , req_query TEXT , status SMALLINT UNSIGNED NOT NULL , ref_path TEXT , ref_query TEXT , protocol VARCHAR(50) NOT NULL, bytes INT UNSIGNED NOT NULL , agent TEXT DEFAULT NULL , method CHAR(15) NOT NULL , PRIMARY KEY(lid) ); Figura 4.3: Descrição da tabela log_entry Apesar de o MySQL ser uma dependência dispensável, a escolha de a manter foi feita de forma a evitar a sobrecarga do CPU com algoritmos de ordenação de enormes quantidades de informação, possivelmente em situações que poderiam comprometer a integridade dos dados. Esta decisão prende-se em especial com o facto de a ferramenta ordenar tais quantidades de informação de forma eficiente e fiável, algo que seria difícil de alcançar com algoritmos ad hoc pouco testados. Este facto torna-se especialmente verdade devido à ordenação se proceder por critérios múltiplos, sendo estes os seguintes, por ordem de relevância: origin, agent, accesstime, req_path. Os dados a serem ordenados são ainda filtrados por extensões dispensáveis (como .jpg, .eot, .txt, etc) e alguns crawlers que não são considerados relevantes para o estudo em questão (4, Figura 4.1). Após a ordenação, o processo completa-se com scripts Python que processam a sequência devolvida e geram as estruturas propostas (6, Figura 4.1), serializam-nas, usando o módulo Pickle do Python, e armazenam-nas (8, Figura 4.1). 4.2.1 Filtragem da informação Antes de iniciar o desenvolvimento da aplicação, tiveram lugar varias reuniões de forma a analisar e discutir alguns conteúdos que não seriam relevantes para a empresa CAPÍTULO 4. ARQUITETURA DO PROCESSAMENTO DE LOGS 22 estudar. Destas reuniões saíram algumas decisões, como por exemplos a exclusão de todos os conteúdos que envolvessem imagens. Desta análise resultou uma eliminação de dados a rondar os 90% face à amostra total. Já durante a implementação foram detetados outros tipos de informações que eram relevantes filtrar, tais como crawlers e casos de repetições de linhas de logs. Estes podiam induzir em erros nos resultados. 4.2.1.1 Filtragem de recursos Mediante o uso de expressões regulares é possível identificar a terminação de um recurso e verificar o tipo de média que o Uniform Resource Identifier (URI) correspondente se refere. Os filtros de extensão (.jpg, .xml, .eot, etc) identificam estes recursos e sinalizam-nos de forma a não serem processados e, consequentemente, excluídos das estruturas. Estes filtros incluem diversos formatos de imagens, ficheiros de texto, ficheiros de configuração, animações flash, entre outros. 4.2.1.2 Filtragem de web crawlers Existiu ainda a necessidade de aplicar filtros baseados na origem do pedido devido a determinados acessos serem efetuados por entidades que tínhamos por objetivo descriminar. Estas entidades, das quais se destacam os web crawlers, introduzem falsos positivos no processamento dos dados. A filtragem dos web crawlers (bots, web spiders, web robots) é criada de uma forma semelhante para a extensões, mas neste caso as expressões regulares utilizadas são filtradas a procurar pelos nomes de todos os web crawler identificados previamente, e verifica se estes existem no user-agent. 4.2.1.3 Filtragem por repetição Um outro filtro criado está relacionado com as linhas de log que são rejeitadas por repetição, isto é, acessos com o mesmo URI várias vezes seguidas em curtos espaços de tempo. Isto pode dever-se a alguns fatores, podendo identificar os principais como o facto de o utilizador atualizar o website enquanto está na mesma página, acrescido CAPÍTULO 4. ARQUITETURA DO PROCESSAMENTO DE LOGS 23 das atualizações que o próprio site faz a cada 10 minutos. Isto leva a que um utilizador que esteja na mesma página, mesmo que não a esteja a utilizar, fique registada nos ficheiros log, como sendo acedida em intervalos 10 minutos. 4.2.1.4 Observações Durante a criação destes filtros de informação, foi também criada uma contagem para cada um deles, assim de tal modo conseguimos ter uma melhor perceção dos filtros e dos resultados dos dados que estão a ser inseridos. Podemos ver na tabela 4.1 os resultados que obtemos como output dos dados inseridos depois da filtragem, tal como, total de dados processados, total de dados aceite e total de dados rejeitados, que englobam os rejeitados por repetição, embora esses sejam também descriminados na tabela. Processados 44,379,749 Aceites 1,235,895 Rejeitados 43,143,854 Rejeitados por repetição 542,160 Tabela 4.1: Output dos filtros logs inseridos do dia 14-04-2013 ao dia 03-06-2013 4.3 Estrutura de dados Uma componente importante do projeto de estágio passou pela criação das estruturas de dados adequadas, pois era necessário que elas fossem sólidas e fiáveis, para que os resultados gerados fossem os corretos. Foi necessário criar uma estrutura individual para cada funcionalidade esperada e também foi criada uma estrutura de IDs que é a mesma para todas as estruturas criadas. Esta estrutura consiste num mapeamento de um ID, um valor numérico gerado de forma sequencial, mapeado a um URI. A informação contida em todas as estruturas encontra-se separada em clusters cujo critério de seleção é o dia (ou ficheiros log) em que os eventos correspondentes aos dados ocorreram. De seguida passamos a CAPÍTULO 4. ARQUITETURA DO PROCESSAMENTO DE LOGS 24 descrever como é que foram criadas as estruturas. 4.3.1 Principais fluxos Para criar a estrutura predeterminou-se que informação seria relevante. Para chegar ao resultado foi preciso usar quatro tipos de atributos de dados: o IP do visitante, user-agent, data e hora da transação e as páginas acedidas. Um novo utilizador é identificado juntamente pelo IP do visitante e o user-agent. Além disso, foi também definido um timeout de 30 minutos, que define um novo utilizador, libertando o par IP e user-agent de qualquer associação prévia a uma sequência de eventos, gerando a identificação de um utilizador novo após este período de inatividade. Com a data e hora da transação (accesstime) obtemos a informação das páginas que o mesmo percorreu do primeiro acesso até ao último, dado que todas as entradas se encontram ordenadas, em primeiro, por este critério. A velocidade de acesso e memória consumida pela estrutura gerada foram fatores ponderados durante a criação da mesma, devido à quantidade de dados que são processados durante a sua geração. Em termos de performance as hash tables cedo se tornaram uma escolha clara. O ID de cada nó é então mapeado a um contador agregado a um nível próximo de outros IDs de nós (na figura 4.4 encontram-se representada esta estrutura, na tabela 4.2 os respetivos IDs). Esta sequência forma uma árvore com qualquer nível de ramificação e profundidade, em que cada ramo corresponde a um nó no caminho percorrido pelos utilizadores. Em concreto, uma trie foi utilizada para representar os caminhos percorridos, em que cada nó representa um prefixo, ou caminho percorrido pelo utilizador dentro do site. O contador, em contrapartida, indica o número de vezes que um mesmo caminho foi percorrido. Os principais fluxos são obtidos através dos valores de contadores mais elevados. Um caminho é dado como terminado a partir do momento em que o timeout referido anteriormente ocorre ou quando outro utilizador surge nas entradas dos logs, o que só é possível porque os dados estão ordenados por IP e access-time, por essa ordem criteriosa. Relativamente ao espaço ocupado pela estrutura, a conversão dos URI em IDs (Tabela 4.2), a par com a serialização nativa do Python, revelou uma melhoria na ordem dos CAPÍTULO 4. ARQUITETURA DO PROCESSAMENTO DE LOGS 25 90% (∼100KB, face aos originais ∼1.5MB) face à implementação original que usava o caminho completo do recurso indicado na representação dos nós. A estrutura é separada em clusters em que o critério de seleção, ou padrão do cluster, é o dia em que o pedido deu entrada. Esta abordagem torna-se eficiente para consultas com o mesmo critério, onde um ou mais dias podem ser escolhidos como parâmetro de seleção. No entanto, esta quebra pode introduzir uma margem de erro que foi considerada marginal, em parte devido à elevada quantidade de dados (amostra) face ao reduzido número de vezes em que esse caso se verifica. Estudos práticos demonstraram que, para os dados existentes, a referida margem de erro se aproximava dos 0.04% (aproximadamente 177,518 entradas) face ao total da amostragem (44,379,749 de entradas). URL IDs / 0 Fluxo: /a 1 /a, /b, /c /b 2 /a, /b, /d /c 3 /, /a /d 4 /, /f /e 5 /e, /b /f 6 Tabela 4.2: Conversão dos URI em IDs Figura 4.4: Estrutura do fluxo CAPÍTULO 4. ARQUITETURA DO PROCESSAMENTO DE LOGS 26 4.3.2 Páginas mais visualizadas numa determinada hora ou intervalo de horas Para esta estrutura foi necessário usar dois tipos de atributos: data e hora da transação (accesstime) e página acedida (req_path). Com esta informação obtemos as páginas visualizadas numa hora ou num intervalo de horas. Em termos de performance optou-se por continuar com hash tables. O ID de cada página é mapeado a um contador que indica o número de vezes que essa página foi visualizada (ver figura 4.5), as páginas mais visualizadas são obtidas pelos valores de contadores mais elevados. Como foi visto na estrutura anterior a conversão dos URI em IDs, contribuiu na melhoria de espaço ocupado por isso optou-se pelo mesmo método nesta estrutura. Adicionalmente, esta estrutura é separada em clusters cujo critério de seleção é a hora em que o pedido deu entrada. Desta forma obtemos uma estrutura eficiente para as consultas, pois podem ser escolhidos parâmetros de seleção de um ou mais dias, seguido de uma ou mais horas. Figura 4.5: Estrutura das páginas visualizadas CAPÍTULO 4. ARQUITETURA DO PROCESSAMENTO DE LOGS 27 4.3.3 Número de visitantes que acederam ao website num determinado intervalo de horas Para criar esta estrutura são considerados como informação relevantes três tipos de atributos de dados: o IP do visitante (origin), user-agent (agent), data e hora da transação. Um novo utilizador é identificado pelos mesmos critérios descritos em 4.3.1. Juntamente com a data e hora da transação (accesstime) é possível obter a informação de quantos utilizadores acederam numa determinada hora. Em termos de performance e memória, foram também mantidos os mesmos critérios e técnicas das estruturas anteriores. De forma semelhante à estrutura descrita em 4.3.2, esta separa os dados em clusters cujo critério de seleção consiste em escolher os atributos consoante a hora em que os pedidos ocorrem (ver Figura 4.6). A informação contida em cada cluster, resume-se a um contador que corresponde ao número de utilizadores que acederam ao site na hora respetiva a cada cluster. Assim, esta tornou-se a estrutura mais pequena (∼1.5KB) de todo conjunto de estruturas implementadas. Figura 4.6: Estrutura do número de visitantes CAPÍTULO 4. ARQUITETURA DO PROCESSAMENTO DE LOGS 28 4.3.4 Códigos de status HTTP Nesta estrutura é considerado o req_path, o dia correspondente ao accesstime e o código HTTP retornado pelo serviço (status) em resposta. O objetivo deste módulo consiste em encontrar as páginas com problemas, ou seja, cujo código de retorno consiste num erro do cliente ou do servidor. Assim apenas são considerados códigos com valor igual ou superior a 4001. Mais uma vez, foram consideradas as mesmas técnicas utilizadas nas estruturas anteriores. Para esta estrutura foram utilizadas hash tables e IDs de nós, que visam obter melhorias em termos de performance e memória utilizada. Acontece que neste caso os clusters são dispensáveis, visto ter sido decidido que não seria relevante que os códigos de erros fossem agrupados por hora. Esta decisão vem do princípio de que os erros ocorridos no servidor não dependem da hora em que o pedido é efetuado, e portanto essa informação torna-se descartável. Assim, a informação que se considera relevante à estrutura é agrupada primeiro por URI, depois por código de retorno (status HTTP), que finalmente se encontra mapeado a um contador (ver figura 4.7). Esse contador é incrementado por cada página encontrada com o valor de retorno correspondente. Figura 4.7: Estrutura códigos de status HTTP 1Os códigos HTTP entre 400 (inclusive) e 500 são considerados erros de cliente e iguais ou superiores a 500 são considerados erros de servidor. CAPÍTULO 5. ARQUITETURA DO PROCESSAMENTO DE PEDIDOS 35 URL Parâmetro Descrição Omissão /query/flow depth Profundidade máxima do caminho a ser considerada. Caminhos mais profundos do que o valor fornecido são truncados. 3 paths Número mínimo de caminhos distintos a considerar. São escolhidos os caminhos mais visitados até que este valor seja atingido, embora o caso em que o peso mínimo dos caminhos escolhidos se repita, este valor poderá ser ultrapassado. 5 /query/status codes Lista de códigos de status HTTP a considerar. Apenas valores neste intervalo serão considerados. n/a count Número de entradas a considerar. Apenas são retornados resultados máximos até que este valor seja atingido. Em caso de o valor mínimo de esses máximos ser repetido, este limite será ultrapassado. Quando este valor é dado como 0 (zero), todos os dados são considerados mas não descriminados nos resultados, sendo apresentado um gráfico com os totais das contagens. 10 /query/time_cluster count Número de ocorrências a considerar. São filtrados valores máximos até que este limite seja atingido. Quando tal acontece e o último valor encontrado se repete, o limite é expandido para todas as repetições. 5 hours Lista de horas a considerar. Horas que não estejam registadas na estrutura são ignoradas. n/a /query/total_visits hours Lista de horas a considerar. Horas que não estejam registadas na estrutura são ignoradas. n/a /query/bounce count Número de entradas a filtrar. Quando o valor mínimo de entre os máximos escolhidos se repete, este limite é estendido. 10 /query/search count Número de entradas a filtrar. Quando o valor mínimo de entre os máximos escolhidos se repete, este limite é estendido. 10 Tabela 5.2: Requisitos de parâmetros descriminados por pedido CAPÍTULO 5. ARQUITETURA DO PROCESSAMENTO DE PEDIDOS 36 5.2 Algoritmos Algoritmos utilizados são geralmente ad hoc, baseados em algoritmos de pesquisa em grafos. 5.2.1 Depth-first search Depth-first search (DFS) é um algoritmo de pesquisa em grafos. Explora um caminho todo até à folha antes de recuar (backtraking) e explorar alternativas. Existe ainda uma variante chamada DFS limitada, do inglês Limited-DFS, que procede da mesma forma com a diferença de não explorar nós com profundidade superior a um limite pré-estabelecido. Podemos ver por exemplo na figura 5.2, após a pesquisa A, depois B, D, a pesquisa recua e tenta outro caminho em B, logo os nós são explorados pela seguinte ordem: A B D E H L M N I O P C F G J K Q. No exemplo vemos que N será encontrado antes de J. Figura 5.2: Exemplo de pesquisa DFS 5.2.2 Principais Fluxos Nesta implementação é utilizado um algoritmo baseado no Limited-DFS em que a profundidade máxima utilizada pelo algoritmo é dada pelos parâmetros passados no CAPÍTULO 5. ARQUITETURA DO PROCESSAMENTO DE PEDIDOS 37 pedido. A cada iteração em largura do algoritmo são escolhidos os nós com maior número de visitas, sendo que essa escolha cria um novo limite superior para a iteração seguinte. Desta forma, cada i-ésima iteração do algoritmo escolhe o i-ésimo máximo da estrutura, adiciona os resultados encontrados a uma lista de máximos e define o limite superior da iteração seguinte. Este limite é inicialmente None, o que indica que na primeira iteração não existe limite superior e, como tal, são escolhidos os nós com número máximo de visitas. Isto processa-se primeiro em profundidade. Assim que o número de nós pesquisados num determinado caminho atinge o limite de profundidade, a pesquisa é interrompida. 5.2.3 Páginas mais visualizadas numa determinada hora ou intervalo de horas Como indicado em 4.3.2, esta estrutura encontra-se dividida em clusters cujo critério de seleção é a hora em que o pedido deu entrada. Do conjunto de clusters disponíveis, é selecionado um subconjunto correspondendo aos dados passados no parâmetro hours. Para cada entrada presente na estrutura, no subconjunto de clusters selecionado, são contabilizados os totais de páginas acedidas, ou seja, é feito o somatório dos contadores presentes na estrutura. Este resultado, no entanto, não é diretamente retornado para o cliente mas, em vez disso, utilizado como auxiliar no cálculo dos nós selecionados. O processo de seleção dos nós procede de forma semelhante ao descrito no subcapítulo anterior. Todas as entradas são adicionadas incondicionalmente enquanto o valor de count não é atingido. A partir daí, há dois casos possíveis: 1. O nó a ser processado já se encontra na lista de resultados – este caso pode acontecer devido a esse nó já ter sido processado em clusters anteriores. Neste caso, a contagem de visitas é meramente adicionada ao resultado já obtido. 2. O nó a ser processado é novo – acontece sempre no primeiro cluster e ocasionalmente nos clusters seguintes. Neste caso é criada uma entrada nova que poderá substituir o menor dos resultados já presentes na estrutura, caso se aplique. Note-se que em ambos os casos o resultado provém sempre do somatório que está CAPÍTULO 5. ARQUITETURA DO PROCESSAMENTO DE PEDIDOS 38 a ser efetuado em simultâneo. No primeiro caso, o valor do resultado é atualizado, enquanto no segundo, o valor é substituído. 5.2.4 Número de visitantes que acederam ao website num determinado intervalo de horas Sendo esta uma das estruturas mais simples descritas, também o algoritmo para a processar o é. O algoritmo consiste em selecionar um subconjunto de clusters indicado pelo parâmetro hours. Existe um complemento a este algoritmo em que os dados são agrupados por dias, em vez de horas. Isto processa-se no cliente, onde os dados do subconjunto dos clusters são somados, discriminando apenas o dia em que os mesmos deram entrada. 5.2.5 Códigos de status HTTP Existem dois algoritmos implementados para este caso. Um dos algoritmos é aplicado quando o parâmetro count é zero e computa os valores totais de códigos de erro, não aplicando filtragem por Uniform Resource Identifier (URI). Ainda assim, o parâmetro codes do pedido é tido em conta, e portanto apenas os códigos de status requisitados pelo cliente são considerados. O algoritmo é bastante linear, consistindo de um mero somatório dos contadores de cada código Hypertext Tranfer Protocol (HTTP) presentes na estrutura. Desta forma, os resultados obtidos consistem de um código HTTP associado a um valor numérico, correspondendo ao total de vezes que o código foi retornado pelo servidor nos dias escolhidos inicialmente como parâmetro. No segundo caso, quando o parâmetro count é maior do que zero, o mesmo algoritmo é aplicado mas, adicionalmente, são coletados os count URI com maior número de erros. Mais uma vez, apenas os erros escolhidos no parâmetro codes são tidos em conta. Esta segunda versão do algoritmo é implementada utilizando uma lista onde são adicionados os resultados. Cada elemento da lista corresponde a um resultado a apresentar. Assim, enquanto o tamanho da lista for menor do que o valor de count, todas as entradas são adicionadas incondicionalmente. Isto garante que, havendo count entradas disponíveis, todas as vagas serão preenchidas. Assim que o valor de count é atingido, o algoritmo comporta-se de forma diferente, passando a incluir os CAPÍTULO 5. ARQUITETURA DO PROCESSAMENTO DE PEDIDOS 39 resultados encontrados apenas se listarem um maior número de erros do que a entrada com menos erros na lista de resultados. Ao substituir o mínimo da lista de resultados a cada iteração, e ao fazê-lo apenas se o candidato a substituí-lo for superior, garantimos que a lista de resultados contém apenas os maiores valores presentes na estrutura original. 5.2.6 Taxa de rejeição Uma das coisas a ter em atenção ao processar esta estrutura passa por distinguir que nós é que são classificados como __all__ e quais não são. Estes nós representam totais do ramo em que se encontram e não devem ser processados como nós normais. Tendo esse facto em conta, o algoritmo implementado é o mesmo que o descrito em 5.2.5, com a exceção de que o zero não é considerado um valor especial de count. Assim, a cada nível processado são filtrados count items, embora o valor de __all__ sirva como otimização para as contagens de cada ramo (totais). Esta otimização torna-se necessária devido ao número dinâmico de browsers e req_queries que podem surgir, aumentando o fator de ramificação da árvore. Isto não se verificava na estrutura descrita anteriormente e a otimização era dispensável. 5.2.7 Palavras Pesquisadas O algoritmo implementado para processar esta estrutura é o mesmo descrito em 5.2.5, com a exceção do zero não ser um valor especial de count. 5.3 Apresentação de resultados As estruturas originais raramente são mantidas. Ao processar a informação é construída uma estrutura nova onde é coletada apenas a informação relevante ao pedido efetuado. Aqui descrevemos o passo seguinte, em que os resultados são enviados para o cliente e processados para um formato infográfico. Inicialmente a estrutura é serializada, utilizando JavaScript Object Notation (JSON) e retornada para o cliente como resposta ao pedido. Cabe então ao cliente a desseria- CAPÍTULO 5. ARQUITETURA DO PROCESSAMENTO DE PEDIDOS 40 lização e conversão dos dados num gráfico informativo. Para tal, a estrutura é primeiramente ajustada num formato compatível com as bibliotecas de infografia utilizadas (D3 [20] e amCharts [21]). Finalmente, cabe às mesmas bibliotecas a apresentação e formatação dos dados nas componentes visuais. A escolha da biblioteca amChart prende-se com a sua extensa e exaustiva documentação [22], apesar do suporte comunitário não ser grande. Esta biblioteca oferece vários tipos de gráficos, incluindo alguns que seriam úteis neste projeto. Figura 5.3: Exemplos de gráficos da biblioteca amChart tendo (da esquerda para a direita) um 3D column chart e um Candlestick chart Figura 5.4: Exemplo do gráfico pie chart com legenda da biblioteca amChart utilizado no projeto A biblioteca D3 oferece uma vasta galeria [23] de exemplos e documentação [24] bastante completa, com algum suporte comunitário [25] [26]. CAPÍTULO 5. ARQUITETURA DO PROCESSAMENTO DE PEDIDOS 41 Figura 5.5: Exemplos de gráficos da biblioteca D3 tendo (da esquerda para a direita) um Collapsible Tree Layout e um Multi-Series Line Chart Figura 5.6: Exemplo do gráfico Collapsible Indented Tree da biblioteca D3 utilizado no projeto A utilização de duas bibliotecas prende-se com a falta de suporte comunitário por parte do amCharts o que, a partir de certo ponto, se tornou necessário e forçou à alteração para uma biblioteca com um suporte maior. Capítulo 6 Aplicação web 6.1 Tecnologias web Existem quatro tecnologias que são importantes destacar neste capítulo: Framework Django do Python, JavaScript, Asynchronous JavaScript and XML (AJAX) e jQuery. Na fase inicial do projeto ficou decidido pela empresa a utilização da Framework Django do Python pois vários projetos da empresa foram desenvolvidos com esta Framework. O JavaScript permitiu uma implementação mais interativa e user-friendly, assim como a formatação dos dados para apresentação ao utilizador final. A utilização de AJAX contribui também de forma significativa para que a experiência do utilizador seja mais fluída e responsiva. Esta tecnologia permite ainda, uma redução na carga da resposta do servidor ao ser delegado para o cliente a formatação e apresentação dos dados. O jQuery é uma conhecida framework para JavaScript muito utilizada como ponte entre o JavaScript e o AJAX. Com ela é retirada ao utilizador a preocupação de grande parte das diferenças entre browsers, oferecendo ainda uma sintaxe simples e dinâmica para grande parte das funcionalidades geralmente utilizadas num cliente web. 42 CAPÍTULO 6. APLICAÇÃO WEB 43 6.2 Sistema interativo A aplicação foi criada com uma interface simples e com poucos elementos para facilitar a interação com todos os aspetos funcionais da página na sua componente visual. Um dos principais objetivos a este nível consistia em permitir que o utilizador alcançasse qualquer objetivo com um número de cliques raramente superior a três. O recurso a técnicas como o AJAX e a delegação de algum processamento para o cliente permitem uma elevada taxa de resposta, oferecendo um elevado desempenho. Os elementos gráficos repetem-se por toda a aplicação. O facto de o grafismo, sempre que possível, se manter idêntico em diferentes funcionalidades, reduz a curva de aprendizagem e mantém uma mais clara interpretação dos mesmos. 6.3 Diagrama sequência do sistema A figura 6.1 apresenta o diagrama de sequência do sistema, representando a comunicação que é feita entre o cliente e o sistema. O primeiro passo no protocolo utilizado consiste em pedir ao servidor o espaço de procura disponível. Aqui, o servidor responde com os dias disponíveis, fator que é calculado consoante os logs que tenham sido processados. Este processo é automático. Num segundo estágio, o utilizador escolhe os dias que pretende consultar e, quando aplicável, o processo repete-se para que sejam consultadas as horas disponíveis. Finalmente, são necessários os parâmetros do pedido que, dentro do espaço de procura disponível, escolhem um subespaço de procura e quais os filtros a aplicar. Mediante o pedido, o servidor responde com os resultados encontrados no subespaço requisitado. CAPÍTULO 6. APLICAÇÃO WEB 44 Figura 6.1: Diagrama de sequência do sistema 6.4 Resultados Este subcapítulo ilustrará, com auxílio de capturas de ecrã da aplicação web, contendo o calendário, o menu e os gráficos interativos de cada resultado, o que a aplicação permite realizar. O calendário e menu são uma das partes centrais da aplicação, pois é onde se centra toda a informação disponível para as consultas. Como se pode ver na figura 6.2, o calendário está definido de segunda a domingo e com a opção de escolha do mês e ano que o utilizador deseja ver, refletindo-se nos meses e anos que estão disponíveis. Por definição a primeira visualização mostra o ano e mês mais recente que existe dados. Na parte inferior do calendário encontram-se os vários botões (Fluxo, Visitas, Status, Taxa Rejeição, Pesquisas) de auxílio às possíveis consultas e um botão de “Limpar” com a funcionalidade de limpar qualquer tipo de seleção que tenha sido efetuada anteriormente. Capítulo 7 Conclusões No início do desenvolvimento deste projeto foi proposto cumprir certos objetivos que foram considerados e, atendendo à dimensão do projeto, considera-se que o trabalho apresenta coerência e especificidade. Não só foram cumpridos os objetivos iniciais como o módulo relativo a erros de servidor consistiu de uma contribuição adicional na implementação. 7.1 Objetivos realizados O objetivo deste projeto de estágio consistia na criação de uma aplicação web de análise de ficheiros access log, pelo que o objetivo foi atingido. De seguida são listadas as principais funcionalidades implementadas: •Consultar os principais fluxos de um utilizador desde que entra no website – Capítulos 4.3.1,5.2.2,6.4.1. •Consultar as páginas mais acedidas numa determinada hora e/ou num intervalo de horas – Capítulos 4.3.2,5.2.3,6.4.2. •Consultar número de visitantes que acedem ao website num determinado hora e/ou num intervalo. – Capítulos 4.3.3,5.2.4,6.4.2. •Consultar erros de servidor ou cliente (códigos de status HTTP) – Capítulos 4.3.4, 5.2.5,6.4.3. 51 CAPÍTULO 7. CONCLUSÕES 52 •Consultar vários aspetos da taxa de rejeição – Capítulos 4.3.5,5.2.6,6.4.4. •Consultar as palavras mais pesquisadas – Capítulos 4.3.6,5.2.7,6.4.5. Para os vários módulos foram utilizados algoritmos e estruturas ad hoc, ambos baseados em alternativas existentes. Assim é mantida a garantia de funcionalidade, assegurada por algoritmos conhecidos, assim como uma elevada performance, conseguida mediante a adaptação dos mesmos e a criação de estruturas específicas aos problemas propostos. 7.2 Trabalho futuro Penso que é um projeto com um grande potencial futuro, por isso podem ainda ser desenvolvidas mais funcionalidades para a aplicação, expandindo o estudo sobre mais aspetos que sejam relevantes para uma melhoria de um website, como por exemplo sobre os comportamentos de utilizadores registados. Existe sempre algum espaço para melhorias em termos de interface. Apesar de o design da aplicação ter sido feito com base nos conhecimentos adquiridos ao longo do curso, outro tipo de estudos poderiam ser realizados com vista a melhoria tanto a nível de aspeto como funcionalidade. O tempo conta aqui como um fator crucial, não tendo havido muitas reuniões com os representantes da empresa com o intuito de discutir e melhorar a aplicação ao nível gráfico. A modularidade da aplicação permite uma fácil adaptação a qualquer uma das questões aqui descritas e a implementação foi desenhada com o intuito de tornar a aplicação versátil a estas alterações. 7.3 Apreciação final Durante o estágio foi possível colocar em prática uma grande parte dos conhecimentos adquiridos durante o curso, o que ajudou a selecionar e/ou identificar alguns métodos para os obstáculos que foram surgindo. Todos os algoritmos e estruturas utilizadas são idênticos ou semelhantes àquelas CAPÍTULO 7. CONCLUSÕES 53 estudadas ao longo do curso, embora as tecnologias utilizadas (Django, jQuery) me tivessem introduzido uma curva de aprendizagem relativamente nova. A consolidação destes conhecimentos têm também um peso grande quer a nível pessoal como profissional Referências [1] InfoPortugal S.A., “Sobre a empresa,” http://www.infoportugal.pt/pt/company/, 2013, [Online; acedido em 20-05-2013]. [2] B. Liu, “Exploring hiperlinks, contents, and usage data,” in Web Data Mining, ser. Data-Centric Systems and Applications. Springer Berlin Heidelberg, 2011. [3] T. Srivastava, P. Desikan, and V. Kumar, “Web mining – concepts, applications and research directions,” in Foundations and Advances in Data Mining, ser. Studies in Fuzziness and Soft Computing, W. Chu and T. Lin, Eds. Springer Berlin Heidelberg, 2005, vol. 180, pp. 275–307. [Online]. Available: http://dx.doi.org/10.1007/11362197_10 [4] Mena, Jesus, Data Mining Your Website. Digital Press, 1999. [5] Apache, “Log Fies,” http://httpd.apache.org/docs/2.2/logs.html, 2013, [Online; acedido em 20-02-2013]. [6] Paul E. Black, “Trie,” http://xlinux.nist.gov/dads/HTML/trie.html, 2013, [Online; acedido em 22-05-2013]. [7] C. M. Allen Downey, Jeffrey Elkner, How to Think Like a Computer Scientist, Learning with Python. First Edition, Green Tea Press, 2002. [8] Django, “Django Documentation,” https://docs.djangoproject.com/en/1.5/, 2013, [Online; acedido em 29-03-2013]. [9] Oracle, “MySQL,” http://www.mysql.com, 2013, [Online; acedido em 29-03-2013]. [10] Web Developers Notes, “JavaScript Tutorial,” http://www.webdevelopersnotes. com/tutorials/javascript/index.php3, 2013, [Online; acedido em 02-04-2013]. 54 REFERÊNCIAS 55 [11] “jQuery,” http://jquery.com/, 2013, [Online; acedido em 02-04-2013]. [12] “Introducing Json,” http://www.json.org/, 2013, [Online; acedido em 02-04-2013]. [13] Pickle, “Python object serialization,” http://docs.python.org/2/library/pickle.html, 2013, [Online; acedido em 29-03-2013]. [14] Mozenda Inc., “The Mozenda Story,” http://www.mozenda.com/about-us, 2013, [Online; acedido em 03-01-2013]. [15] “Funnel Web Analyzer,” http://www.funnelwebcentral.org, 2013, [Online; acedido em 03-01-2013]. [16] Screaming Frog Ltd., “Screaming Frog SEO Spider Tool,” http://www. screamingfrog.co.uk/seo-spider/, 2013, [Online; acedido em 03-01-2013]. [17] Google, “Google Analytics,” http://www.google.com/analytics/, 2013, [Online; acedido em 03-01-2013]. [18] Zoltan Balazs, “A Practical Use of the MVC Pattern,” http://www.codeproject.com/ Articles/17068/A-Practical-Use-of-the-MVC-Pattern, 2013, [Online; acedido em 02-06-2013]. [19] The Django Book, “The MTV or MVC development-pattern,” http://www. djangobook.com/en/2.0/chapter05.html#the-mtv-or-mvc-development-pattern, 2013, [Online; acedido em 02-06-2013]. [20] D3.js, “Data-driven documents,” http://d3js.org/, 2013, [Online; acedido em 01-032013]. [21] “amCharts,” http://www.amcharts.com/, 2013, [Online; acedido em 24-04-2013]. [22] amCharts, “amDocs,” http://docs.amcharts.com/, 2013, [Online; acedido em 2404-2013]. [23] D3, “Gallery,” https://github.com/mbostock/d3/wiki/Gallery, 2013, [Online; acedido em 01-03-2013]. [24] D3, “Documentation,” https://github.com/mbostock/d3/wiki, 2013, [Online; acedido em 01-03-2013]. [25] “D3: Data-Driven Documents,” https://groups.google.com/forum/#!forum/d3-js, REFERÊNCIAS 56 2013, [Online; acedido em 22-04-2013]. [26] “Welcome to the d3.js community,” https://geekli.st/community/d3js, 2013, [Online; acedido em 22-04-2013]. Acrónimos URL Uniform Resource Locator URI Uniform Resource Identifier MVC Model-View-Controller HTTP Hypertext Tranfer Protocol IP Internet Protocol DFS Depth-first search JSON JavaScript Object Notation AJAX Asynchronous JavaScript and XML SQL Structured Query Language HTML HyperText Markup Language 57