GT-IMAV Manual da Aplicação. Versão 1.12

Transcrição

1 GT-IMAV Manual da Aplicação Versão 1.12

2 Identificação do Documento Projeto GT-IMAV Grupo de Trabalho em Instrumentação e Monitoração para Aplicações de Vídeo Cliente RNP Coordenador do projeto Regina Melo Silveira Controle de Versões Data Versão Responsável Alterações 10/06/ Lucas Chigami Versão Inicial 12/06/ Hélcio M. Pimentel Complementação 13/06/ Reinaldo Matushima Complementação e Revisão 24/09/ Hélcio M. Pimentel Atualização 24/09/ Lucas Chigami Complementação e Revisão 25/09/ Hélcio M. Pimentel Correções e Complementações 25/09/ Lucas Chigami Complementação e Revisão 29/09/ Reinaldo Matushima Revisão e complementação 30/09/ Lucas Chigami Complementação imagens 30/09/ Reinaldo Matushima Revisão 2

3 Sumário Lista de Figuras Introdução Público Alvo Documentos relacionados Organização do documento Visão Geral Modelo de Dados Base transacional Base dimensional Módulos de Monitoração das aplicações Módulo de Monitoração de Eventos do Player Módulo de Monitoração dos Eventos de página Módulo de Monitoramento do Servidor de Vídeo Módulo de Monitoramento do Transmissor de Vídeo Módulo de Análise - Gráficos e Relatórios Módulo de Gerenciamento de Aplicações Integração / Desenvolvimento Módulo de Monitoração do Player Módulo de Monitoração da Aplicação Web Instalação Agentes de Monitoramento de Eventos Instalação dos Agentes de Monitoramento e do Componente RESTful Monitor Bridge Configuração dos Agentes de Monitoramento do Servidor e Transmissor Configuração do protocolo SNMP Configuração do componente RESTful Monitor Bridge

4 4.2. Coletor Configuração do Coletor Módulo de Gerenciamento Pentaho Utilização das ferramentas de Relatório Pentaho BI Server Módulo Kettle Considerações Anexo I - Monitoramento por serviço SNMP de JDVoD e JDLive Coleta de Informações de Transmissão de Vídeo Coleta de Informações de Máquina Referências

5 Lista de Figuras Figura 1 Piloto fase 1 - Integração LMS... 6 Figura 2 Piloto fase 2 Integração Video@RNP... 7 Figura 3 Componentes do serviço de monitoração Figura 4 - Base de dados transacional Tabelas para armazenamento dos dados coletados Figura 5 - Base de dados transacional Tabelas para gerenciamento de aplicações monitoradas Figura 6 - Base de dados dimensional Dimensões básicas Figura 7 - Base de dados dimensional Relação entre dimensões Figura 8 - Base de dados dimensional Tabelas Fato Figura 9 - Tela de Relatórios Figura 10 - Tela do Pentaho Report Design Figura 11 - Módulo de Gerenciamento Clientes e aplicações Figura 12 - Módulo de Gerenciamento - Parâmetros de uma aplicação Figura 13 - Diagrama da arquitetura dos agentes de coleta dos dados de máquina e transmissor Figura 14 - Tela do sistema de gerenciamento Figura 15 - Tela de administração Pentaho Figura 16 - Tela de Exemplo da Interface WEB Figura 17 - Tela Principal Pentaho Figura 18 - Tela de edição Figura 19 - Tela da ferramenta Kettle

6 1. Introdução O projeto GT-IMAV elaborou um conjunto de mecanismos e ferramentas que permitem monitorar e mensurar diferentes parâmetros para que seja possível ter uma a visão clara sobre a efetividade do consumo de vídeo, assim como estimar o chamado viewer engagement. Na primeira fase do projeto, as ferramentas desenvolvidas foram avaliadas dentro de um cenário de utilização do vídeo como um instrumento para o ensino/aprendizado. Para tal, foi realizada uma integração do serviço junto a uma ferramenta de Learning Management System (LMS) da USP. Neste primeiro piloto, testes foram realizados junto a grupos de alunos de forma a avaliar, fazendo uso do serviço, a efetividade do vídeo como material de apoio ao ensino. A Figura 1 apresenta uma ilustração simplificada da avaliação efetuada na primeira fase do projeto. Basicamente, a partir de alguns cenários controlados, foi feito um comparativo de absorção de conteúdo por parte das turmas (turma que teve acesso aos vídeos e turma de controle que não teve acesso ao ambiente). Figura 1 Piloto fase 1 - Integração LMS Na segunda fase do projeto, focou-se na evolução das ferramentas desenvolvidas, trabalhando melhor a escalabilidade da solução e incorporando mecanismos de controle e ferramentas de gerenciamento para apoio à administração do serviço. Para validar o serviço proposto dentro de um cenário de uso da RNP, o piloto consistiu em integrar o serviço de monitoração desenvolvido ao serviço de vídeo da RNP, o Video@RNP. Para tal, os módulos de monitoração desenvolvidos foram integrados ao diferentes elementos que compõem a plataforma de vídeo da RNP, a saber, (1) portal de vídeo, para avaliar o comportamento de acesso ao vídeo 6

7 e (2) servidores e (3) transmissores, de forma a avaliar o uso da infraestrutura de distribuição de vídeo, permitindo cruzar assim informações de consumo dos usuários com informações de demanda de uso infraestrutura, possibilitando avaliar de forma mais ampla o serviço de vídeo. A Figura 2 ilustra a integração realizada. Figura 2 Piloto fase 2 Integração Video@RNP Este documento visa apresentar os principais passos para instalação do serviço desenvolvido. Nele são apresentados os passos necessários para a instalação dos diferentes módulos que compõem o serviço de monitoração Público Alvo Este documento destina-se tanto às pessoas que são responsáveis pelo gerenciamento dos conteúdos, para uma visão da sua aceitação, como administradores responsáveis pela operação da infraestrutura utilizada 7

8 pelo sistema de transmissão de vídeo, para uma visão de uso de recursos, além dos desenvolvedores das aplicações que desejem utilizar as ferramentas de monitoramento, instrumentando suas aplicações de vídeo Documentos relacionados 1) Proposta do GT-IMAV submetida à RNP; 2) Relatório de Planejamento - Detalhamento das atividades (RP1); 3) Relatório Técnico Proposta de Protótipo (RT2); 4) Relatório Técnico Validação do Protótipo (RT3); 5) Relatório de Planejamento - Detalhamento das atividades (RP5); 6) Relatório de Planejamento Implantação Piloto (RP6) Organização do documento Este documento está organizado em 5 capítulos, no capítulo 2 é realizada uma apresentação da visão geral do projeto. O capítulo 3 apresenta detalhamentos do desenvolvimento realizado e informações para integração dos módulos de monitoração. O capítulo 4 mostra os procedimentos para realizar a instalação e configuração para colocar o serviço em operação. Finalizando, o capítulo 5 apresenta informações com relação ao uso da ferramenta Pentaho de análise de dados e geração dos relatórios. 8

9 2. Visão Geral No projeto GT-IMAV foi elaborado, especificado e implementado um conjunto de módulos e ferramentas para realizar o monitoramento de vários aspectos de um sistema de distribuição de vídeo pela Internet. São eles: 1. Módulo de monitoração da aplicação: compreende plug-ins desenvolvidos para suportar a monitoração das páginas web com vídeos e o player de vídeo em si. Através destes plug-ins é possível monitorar detalhadamente o comportamento do usuário quanto ao consumo do vídeo; 2. Módulo de monitoramento do servidor de vídeo: permite avaliar informações dos servidores que compõem a infraestrutura de distribuição de vídeo. Ao cruzar informações de consumo com informações da infraestrutura, é possível correlacionar diversos parâmetros, fornecendo subsídios importantes para possibilitar a manutenção e operação adequada da infraestrutura; 3. Módulo de monitoramento do transmissor de vídeo: permite avaliar mais profundamente as condições de operação da infraestrutura de distribuição de vídeo. Avaliando os transmissores, dados detalhados como por exemplo, número de sessões ativas, permitem, juntamente com dados de monitoramento do servidor onde o transmissor opera, dar uma visão mais precisa sobre o nível de uso da rede de vídeo. Dados como ponto de saturação da rede podem ser acompanhados mais de perto, permitindo uma gerência mais ativa dos recursos, permitindo um provisionamento mais adequado de infraestrutura e consequentemente, melhor qualidade de experiência para o usuário final; 4. Receptor: módulo responsável por persistir as informações coletadas e enviadas por cada um dos módulos de monitoramento descritos previamente. Representa um dos pontos mais críticos da aplicação, por ser responsável por receber uma grande massa de informações. Ele é responsável basicamente por alguns controles de segurança e fazer a persistência das informações para que possam ser tratadas e analisadas em um segundo momento; 5. Kettle/Pentaho: correspondem a ferramentas que foram utilizadas na concepção do serviço para apoiar respectivamente no processo de tratamento das informações armazenadas pelo coletor e por processar as informações, permitindo a geração de relatórios de análise de consumo. 9

10 Figura 3 Componentes do serviço de monitoração A Figura 3 ilustra cada um dos componentes descritos, exibindo como eles se relacionam. O intuito na concepção do projeto em desenvolvimento é a concepção de um serviço que permita ao mesmo tempo ser utilizado por: RNP: de forma a mensurar o consumo dos conteúdos do serviço Video@RNP, por meio de sua rede de distribuição de vídeo (RVD), fornecendo suporte a tomadas de decisões para a operação da rede e em novos investimentos para a infraestrutura; Universidades: como meio de avaliar a efetividade do uso de vídeo nas ações de ensino e aprendizagem, permitindo a definição de evoluções e melhorias nessas ações; TVs Universitárias (RITU) e TVs públicas: de modo a avaliar o consumo e aceitação de produções audiovisuais, com possibilidade de serem classificadas e usadas da melhor maneira por essas emissoras televisivas Modelo de Dados O serviço de monitoração é composto de dois bancos de dados: 1. Transacional: representa a base de dados onde são persistidas as informações coletadas pelos módulos de monitoração e persistidas pelo receptor. Representa um local de passagem onde os dados ficam antes de serem tratados e movidos para a base dimensional; 10

11 2. Dimensional: periodicamente os dados recebidos e armazenados na base de dados transacional são processados e movimentados para a base de dados dimensional. A base dimensional está estruturada de uma forma mais adequada para permitir a realização de análises sobre os dados monitorados Base transacional A base de dados transacional se caracteriza pela modelagem simplificada. Nela os dados são armazenados da forma cru, da mesma forma como são recebidos. Apesar da arquitetura de recepção ter sido concebida para ser o mais facilmente escalável possível, ela é um dos pontos críticos do serviço. Assim, o processo de persistência precisa ser simplificado de forma a ser realizado da forma mais rápida possível. Figura 4 - Base de dados transacional Tabelas para armazenamento dos dados coletados A Figura 4 ilustra as tabelas utilizadas para persistência dos dados coletados. Segue detalhadamento das tabelas: 1. Infocollect_watch: representa a tabela onde é armazenada as informações de identificação dos dados recebidos (metadados principais, exemplo, identificação do usuário, vídeo e aplicação monitorada). Um novo registro é gerado para cada nova monitoração que é realizada. Associada a uma monitoração são armazenadas os dados complementares (Infocollect_auxdata) e eventos (Infocollect_eventinfo) e associados à nova monitoração; 2. Infocollect_auxdata: tabela utilizada para armazenar metadados adicionais em relação à monitoração realizada (cada aplicação pode enviar metadados adicionais conforme interesse); 3. Infocollect_eventinfo: corresponde à tabela onde são armazenados todos os eventos monitorados. É nesta tabela que são armazenados os dados monitorados em si (eventos de player, de página, informações de servidores e transmissores). 11

12 A base de dados transacional é composta de outras tabelas auxiliares, estas para uso interno do coletor. A seguir (Figura 5) são apresentadas as tabelas utilizadas para gerenciamento das aplicações monitoradas: 1. app_manager_client: utilizada para armazenar informações de clientes do serviço. Basicamente as instituições que foram usuárias do serviço; 2. app_manager_application: armazenamento de aplicações de vídeo monitoradas. Cada cliente pode ter diversas aplicações monitoradas (ex. USP é um cliente e tem duas aplicações monitoradas, o IPTV e o eaulas da USP); 3. app_manager_responsible: dados da pessoa responsável por cada aplicação monitorada. Figura 5 - Base de dados transacional Tabelas para gerenciamento de aplicações monitoradas A base de dados transacional possui ainda algumas tabelas auxiliares de uso interno Base dimensional Após serem tratados pelo Kettle, os dados armazenados na base de dados transacional são movimentados para a base dimensional. Basicamente os dados da base transacional são analisados e salvos em um conjunto de tabelas específicas, de forma a facilitar a análise e geração de relatórios. A Figura 6 apresenta as tabelas dimensionais básicas. Consiste nas tabelas com dados referentes a cada dimensão monitorada. Figura 6 - Base de dados dimensional Dimensões básicas As tabelas dimensionais básicas são: 1. dim_client: dados de identificação do cliente monitorado (ex. USP, Unicamp); 12

13 2. dim_application: identificação da aplicação monitorada (no caso da USP teríamos o IPTV e o eaulas, no caso da RNP o Video@RNP e o Videoaula@RNP); 3. dim_video: identificação do vídeo cuja visualização foi monitorada; 4. dim_user: identificação do usuário que visualizou o vídeo; 5. dim_streamer: identificação dos servidores de transmissão monitorados; 6. dim_host: identificação das máquinas monitoradas. Além destas tabelas dimensionais, há também algumas tabelas de relacionamento entre dimensões. Estas são apresentadas a seguir: Figura 7 - Base de dados dimensional Relação entre dimensões 1. dim_client_application: relação das instituições clientes e as aplicações monitoradas; 2. dim_client_video: relação entre cada cliente e os vídeos monitorados; 3. dim_user_video: relação entre o usuário e o vídeo. Além das tabelas dimensionais, há também as tabelas fato. São as tabelas que contém os detalhes dos eventos monitorados. São elas: 1. fact_streamer: informações coletadas dos transmissores de vídeo (ex. número de sessões ativas); 2. fact_consuption: informações consolidadas sobre cada vídeo monitorado (seja informações obtidas da aplicação ou do player de vídeo); 3. fact_consumption_time: informações consolidadas sobre cada evento do vídeo monitorado, com a inclusão da informação do tempo de início e término de cada evento; 4. fact_host: informações coletadas das máquinas que compõem a infraestrutura de distribuição de vídeo (cpu, memória, etc.). 13

14 Figura 8 - Base de dados dimensional Tabelas Fato 2.2. Módulos de Monitoração das aplicações Os eventos das aplicações de vídeos são monitorados por meio de dois plug-ins em JavaScript. Um deles, o Page Collect, é específico para monitoramento de ações na página em que o vídeo é exibido. Esse plug-in basicamente monitora eventos como, por exemplo, eventos de compartilhamento, de submissões de formulários para avaliações, comentários e enquetes, bem como de botões de gostar ou não gostar do vídeo. Com isso é possível verificar a interação do usuário com a aplicação do vídeo, extraindo informações quando ao engajamento do usuário. O outro plug-in, o Player Collect, é destinado a obter, junto ao player de vídeo, informações referentes a como o vídeo está sendo consumido (por exemplo, se o usuário está vendo em full screen, se o usuário fez seek no vídeo, se o vídeo está em mute, tempo para carregar o vídeo, etc.). Fazendo uso desses dois plug-ins é possível obter uma gama extensa de métricas de consumo, que são utilizadas para gerar uma série de análises e relatórios possíveis, com base em interesses dos usuários do serviço de monitoração. O nível de informações que pode ser obtido depende do nível de integração realizado. Os plug-ins permitem que as aplicações enviem informações adicionais de interesse, de forma que se possa gerar análises e relatórios mais avançados. 14

15 Outro ponto que depende das aplicações são os tipos de ferramentas disponibilizadas junto aos vídeos. O plug-in Page Collect prevê a coleta de informações diversas, tais como recomendações, votos em enquetes e avaliações, conforme mencionado. No entanto, para conseguir tais informações, é necessário que a aplicação possua tais ferramentas. Além disso, podem ser necessários ajustes para compatibilizar o plug-in à forma como cada ferramenta foi desenvolvida Módulo de Monitoração de Eventos do Player O player de vídeo representa o principal componente dentro de um sistema de vídeo, portanto um sistema de monitoração de vídeo não poderia deixar de capturar eventos que ocorrem nele. Para atingir esse fim, foi desenvolvido o plug-in Player Collect. Para o desenvolvimento desse plug-in, utilizou-se como referência um dos mais utilizados players gratuitos disponíveis atualmente, o jwplayer[1]. Atualmente os seguintes eventos estão sendo monitorados pelo plug-in: Mouse Over Video: usuário passou o cursor sobre a área de vídeo; Mouse Left Video: usuário saiu com o cursor sobre a área de vídeo; User Left Video: a janela (ou aba) no navegador onde o vídeo está sendo executado passou a ser inativa; User Returned Video: a janela (ou aba) no navegador onde o vídeo está sendo executado passou a ser ativa; Video On Frame: o vídeo encontra-se enquadrado na tela do usuário (mais de 30% de sua altura); Video Out Of Frame: o vídeo encontra-se fora do enquadramento na tela do usuário (menos de 30% de sua altura); Buffer Change: indica quantitativamente em termos percentuais o carregamento do vídeo pelo player para a sua execução; Full Screen: indica que o usuário selecionou a exibição em tela cheia do vídeo; Mute: indica que o usuário selecionou o botão para cortar o áudio do vídeo; Play: indica que o usuário selecionou o botão para iniciar a reprodução do vídeo; Pause: indica que o usuário selecionou o botão para pausar a execução do vídeo; Seek: indica que o usuário selecionou manualmente, através da barra de execução do player de vídeo, um determinado trecho; Buffering State: indica a situação do carregamento do vídeo em buffer; Complete: indica que o player reproduziu totalmente o conteúdo do vídeo; Resize: indica a alteração das dimensões do vídeo; Meta Data Recovery: indica o envio do vídeo para o player das informações de metadados presentes no arquivo de vídeo; 15

16 Player Error: indica em caso de existência do erro e da mensagem referente a esse erro; Todos os eventos são monitorados e enviados para o coletor com o horário em que ocorreu o evento e o instante dentro do vídeo em que a informação foi coletada Módulo de Monitoração dos Eventos de página A página da aplicação Web pode apresentar algumas ferramentas de interação que permitam avaliar a qualidade do consumo de um vídeo. O plug-in responsável pela monitoração destes eventos, o Page Collect, foi desenvolvido de forma a ser genérico o suficiente para contemplar os principais elementos presentes nesse tipo de aplicação. São eles: Share: o compartilhamento (Share) trata os eventos referentes aos componentes específicos para o compartilhamento do conteúdo exibido através das redes sociais; Comment: os comentários (Comment) são os componentes muito presentes em qualquer aplicação de vídeo em que se pode deixar qualquer tipo de observação, análise, perguntas, ou qualquer tipo de informação na forma de texto; Eval: as avaliações (Evaluation) visam quantificar a qualidade de algum parâmetro, e no caso desta aplicação de validação foram escolhidos o conteúdo do vídeo e a qualidade da transmissão do mesmo; Poll: a enquete (Poll) baseia-se em um conjunto de perguntas em que cada uma dessas traz um conjunto de respostas, cabendo ao usuário respondê-las de acordo com o entendimento sobre o conteúdo do vídeo; Dislike: o não gostei (Dislike) corresponde a permitir ao usuário demonstrar que não gostou do vídeo; Like: o gostei (Like) corresponde a permitir ao usuário demonstrar que gostou do vídeo. Por fim, informações sobre a avaliação sobre o entendimento do conteúdo do vídeo são inseridas e enviadas por meio deste mesmo módulo. Além desses parâmetros, informações referentes ao perfil de usuário também podem ser enviadas por meio desse módulo, possibilitando análises e relatórios bem mais ricos Módulo de Monitoramento do Servidor de Vídeo As informações referentes aos servidores de distribuição de vídeo podem auxiliar tanto na análise do consumo dos fluxos de vídeo, bem como podem representar uma valiosa ferramenta de operação, monitoração e manutenção de um sistema (como suporte a dimensionamento adequado, etc.). Os parâmetros que foram levantados e analisados como relevantes a serem monitorados foram: Host Name: identificador da máquina a ser monitorada; 16

17 CPU Used: porcentagem de utilização do recurso de CPU; CPU Info: informações referentes à identificação da CPU, como modelo, fabricante; Memo Used: porcentagem de utilização do recurso de memória RAM; Memo Total Size: tamanho total de memória disponível, em KB; Memo Swap Used: porcentagem de utilização do recurso de memória SWAP; Memo Info: informações referentes à identificação da memória, como modelo, fabricante; Net Used: porcentagem de utilização do recurso de rede; Net Bandwidth: largura de banda total disponível, em Mbps; Disk Used: porcentagem de utilização do recurso de armazenamento em disco; Disk Total Size: tamanho total disponível de armazenamento em disco, em KB; Net RX: quantidade total, em bytes, de dados recebidos pela interface de rede; Net TX: quantidade total, em bytes, de dados transmitidos pela interface de rede; Net Info: identificação da interface de rede. O módulo responsável pela coleta desses parâmetros pode utilizar o protocolo SNMP[2] para realizar o monitoramento e coleta das informações desejadas, mas também permite tal acesso via HTTP Módulo de Monitoramento do Transmissor de Vídeo O transmissor de vídeo é o principal componente dentro da infraestrutura de um serviço de distribuição de vídeo, logo as informações monitoradas nele possuem um valor muito grande para a análise do desempenho do sistema como um todo. As informações que um transmissor monitora podem variar de acordo com a implementação do próprio transmissor de vídeo. Em nosso protótipo de serviço foram utilizados os transmissores (JDVoD e JDLive) desenvolvidos para o portal de vídeo da RNP, cujos parâmetros básicos disponíveis são: Host Name: identificador da máquina onde o transmissor está instalado; Session Num: quantidade total de sessões conectadas ao transmissor; Live Sessions: quantidade de sessões no modo ao vivo conectadas ao transmissor; VoD Sessions: quantidade de sessões no modo sob demanda conectadas ao transmissor; Live User Num: quantidade de usuários conectados ao transmissor sendo atendidos por sessões no modo ao vivo ; VoD User Num: quantidade de usuários conectados ao transmissor sendo atendidos por sessões no modo sob demanda ; RX: taxa de recepção de dados; TX: taxa de transmissão de dados; 17

18 Vale ressaltar que esse módulo possui compatibilidade com os transmissores desenvolvidos para o sistema Video@RNP junto ao LAVID[3], necessitando um mapeamento para os parâmetros definidos com as informações providas por esse transmissor Módulo de Análise - Gráficos e Relatórios Para realizar a análise, interpretação, refinamento e exibição dos resultados dos dados monitorados consolidados, foram levantadas algumas ferramentas gratuitas que oferecessem recursos que atendam às necessidades deste cenário de utilização. Dentre estas, as ferramentas escolhidas foram o Pentaho Community Edition[4] e o Kettle. Estas soluções consistem em um conjunto de ferramentas para Business Intelligence. O primeiro é responsável pelo gerenciamento dos gráficos e relatórios através de uma interface WEB. Já a segunda ferramenta é responsável pela parte conhecida como ETL (Extraction, Transformation and Loading), com essa ferramenta é possível realizar a análise, tratamento e extração dos dados para que possam ser utilizados pela ferramenta de exibição dos gráficos e relatórios. Na Figura 9 podemos observar uma tela de exemplo da aplicação de gerenciamento de gráficos do Pentaho, com alguns dados que foram coletados durante os testes no cenário de validação do sistema. Figura 9 - Tela de Relatórios 18

19 A versão utilizada dessa ferramenta permite uma customização da sua interface, além de permitir que novas funcionalidades sejam agregadas através da instalação de plug-ins disponíveis no próprio site da ferramenta. Uma dessas ferramentas que foram agregadas a suíte de relatórios foi o Pentaho Report Designer[5]. A ferramenta Pentaho Report Designer é uma aplicação desktop especifica para a elaboração de relatórios, gráficos e tabelas. Na Figura 10 podemos ver um exemplo de relatório que foi desenvolvido dentro da ferramenta, que posteriormente foi exportada para a suíte Pentaho para exibição. Figura 10 - Tela do Pentaho Report Design 2.6. Módulo de Gerenciamento de Aplicações Representa ambiente web desenvolvido para prover mecanismo para gerenciamento das aplicações de vídeos monitoradas. Através do ambiente são gerenciadas: Informações dos clientes: informações das instituições usuárias do serviço de monitoração. Como exemplo de clientes, podemos ter a USP ou a própria RNP; Informações das aplicações: informações das aplicações de vídeo das instituições que fizerem uso do serviço. Como exemplos de aplicações, para o caso da RNP, poderíamos ter o Video@RNP e o Videoaula@RNP. Para o caso da USP, poderíamos ter o IPTV da USP ou o e-aulas da USP. O objetivo deste ambiente é gerenciar não somente as informações dos clientes e aplicações de vídeos, mas o gerenciamento de informações de controle necessárias para a provisão dos mecanismos de segurança do serviço de monitoração. 19

20 A Figura 11 e a Figura 12 ilustram o módulo de gerenciamento das informações das aplicações de vídeos monitoradas. Na primeira figura são exibidas as aplicações de um determinado cliente (no exemplo, a própria RNP) e as aplicações monitoradas. Figura 11 - Módulo de Gerenciamento Clientes e aplicações Figura 12 - Módulo de Gerenciamento - Parâmetros de uma aplicação 20

21 3. Integração / Desenvolvimento A coleta das informações é feita por um conjunto de ferramentas que devem estar localizadas junto às suas correspondentes fontes, e muitas vezes essa comunicação entre aplicação e ferramenta de monitoramento requer uma customização para que os eventos que se desejem coletar sejam monitorados corretamente. Para realizar essa customização, é necessário realizar configurações que serão detalhadas a seguir. Dentro do conjunto de ferramentas e módulos, os que possuem tais implicações são os plug-ins de coleta, ou seja, os componentes de monitoração do player (Player Collect) e da aplicação Web (Page Collect) Módulo de Monitoração do Player Conforme apresentado, para realizar o monitoramento dos eventos específicos do player de vídeo, tomouse como base o player jwplayer, e foi desenvolvido o componente Player Collect, implementado em playercollect.js, que é o responsável pela monitoração e envio dos dados referentes ao player de vídeo. Para instanciar o player, deve-se chamar o seguinte script na página, da forma que for mais conveniente para o usuário. function generate_player(){ //jwplayer setup jwplayer('container').setup({ flashplayer: '/player.swf', file: document.getelementbyid('videourl').value, height: 123, width: 456, autoplay: true, plugins: { '<PLUGIN URL>' : { collector_url: '<collectorurl>', id_client: '<clientid>', id_application: '<applicationid>', id_user: '<userid>', id_video:'<videoid>', //javascript object with auxdata key-value pairs //(e.g.:{user_access_level: 3} ) 21

22 aux_data: {... } } } }); } Onde: '<PLUGIN URL>': deve ser substituído pelo endereço URL onde o plug-in está localizado; collector_url: '<collectorurl>': endereço URL correspondente ao coletor; id_client: '<clientid>': Id do cliente monitorável; id_application: '<applicationid>': Id da aplicação de vídeo; id_user: '<userid>': (Opcional) Id do usuário no contexto da aplicação; id_video: '<videoid>': Id do vídeo/conteúdo; aux_data: {myauxdata: 'myvalue', myotherdata: 'myothervalue', yetanotherdata: 'yetanothervalue'}: aceita um JSON que com dados auxiliares, como informações de perfil do usuário ou de tipo de transmissão do vídeo (ao vivo ou sob demanda) por exemplo. Os seguintes métodos foram criados no desenvolvimento deste plug-in: PlayerCollect(player, config): construtor do plug-in do player, os argumentos são o objeto do player jwplayer e as configurações; getconfigdata: constrói dados internos a partir das configurações, como os dados de cabeçalho de mensagem de eventos, por exemplo; setup(evt): instala o plug-in no player, é uma função de call-back para o status de pronto do player setiframe(): constrói o elemento dom do iframe; feedbacklistener(evt): quando o objeto monitorável (watch) é criado, via uma solicitação Ajax dentro do iframe do coletor, é enviada uma mensagem de feedback de modo a poder finalizar a função periódica; send_message_to_iframe(type= event_info, obj): formata e posta mensagem à janela do iframe; 22

23 createwatch(): tentar criar um watch, ou seja, objeto com as informações monitoráveis. Este método é um call-back para a função periódica createwatchfn; sendeventinfo(name, eventinfo={}): formata e posta a mensagem da ocorrência do evento para o iframe; bindplayerevents(): faz um binding dos eventos. Todos os eventos são enviados ao iframe; isplaying(): verifica se o player está ativamente executando o vídeo; framechecker(): função para monitorar se o vídeo está atualmente no frame. Não funcionará se o vídeo não estiver sendo mostrado de dentro de um iframe Módulo de Monitoração da Aplicação Web Novamente, conforme apresentado, o componente responsável pela monitoração dos eventos dos componentes da página da aplicação é o Page Collect implementado em pagecollect.js. A seguir serão detalhadas as customizações necessárias para o correto mapeamento dos componentes a serem monitorados por essa ferramenta. Para instanciar o componente de coleta é preciso referenciá-lo na página por meio da seguinte instrução: <script type="text/javascript" src="<plugin URL>"></script> Em seguida deve-se criar um script para inicialização de suas configurações, como no exemplo a seguir: <script type="text/javascript"> function loadpagecollectplugin(){ var pageconfigs= {}; pageconfigs.id_client = '<clientid>'; pageconfigs.id_application = '<applicationid>'; pageconfigs.id_user = '<userid>'; pageconfigs.id_video = '<videoid>'; pageconfigs.collector_url = '<collectorurl>'; pageconfigs.aux_data = {... }; var page_collect = new infocollect.pagecollect(pageconfigs, true); 23

24 page_collect.start(); } </script> Novamente, como ocorre no caso do plug-in do player, em aux_data pode-se colocar informações de perfil do usuário e/ou do tipo de transmissão caso precisem ser associados à transmissão de vídeo, por exemplo. Para que esse script seja executado, deve se invocá-lo no evento de carregamento da página: <body onload="loadpagecollectplugin();"> Com essa configuração, é possível monitorar eventos de enquetes, avaliações, comentários e redes sociais. As seguintes informações serão enviadas com a utilização deste plug-in: Enquetes: PollEvent = 104 { "name" : "104", "eventinfo":{ title : "Enquete sobre qualidade", fields : [ {question : "Avalie a qualidade da apresentação (transmissão do vídeo)", value : "Ruim", correct = "" }, {question:" Avalie a qualidade do conteúdo exposto", value : "Bom", correct = ""} } } ], "time": Avaliações: EvalEvent = 103 { "name" : "103", "eventinfo":{ 24

25 title : "Avaliação do conteúdo", fields : [ {question : "Ondas S são aquelas que ", value : "opcao1", correct = "opcao3" }, {question : "Na camiseta do professor está desenhado", value : "opcao4", correct = "opcao4"} } } ], "time": Comentários: CommentEvent = 102 { "name" : "102", "eventinfo":{ title : "", fields : [ {question : "", value : "eu não vou comentar", correct = "" }, ], "time": } } Redes Sociais: ShareEvent = 101 Google o Hover: usuário passa o mouse sobre o botão de +1. { "name": "101", "time": , 25

26 "eventinfo": { "social_network":"google_plus", "social_pluging":"plusone_button", "action":"hover", "target":" } } o Confirm: aparece ou desaparece uma bolha de confirmação. { "name": "101", "time": , "eventinfo": { "social_network":"google_plus", "social_pluging":"plusone_button", "action":"confirm", "target":" } } o On: usuário faz +1. { "name": "101", "time": , "eventinfo": { "social_network":"google_plus", "social_pluging":"plusone_button", "action":"on", "target":" } } 26

27 o Off: usuário desfaz +1. { "name": "101", "time": , "eventinfo": { "social_network":"google_plus", "social_pluging":"plusone_button", "action":"off", "target":" } } Facebook o Unlike: usuário não gosta de algum conteúdo. { "name": "101", "time": , "eventinfo": { "social_network":"facebook", "social_pluging":"like_button", "action":"unlike", "target":" } } o Like: usuário gosta de algum conteúdo. { "name": "101", "time": , "eventinfo": { 27

28 "social_network":"facebook", "social_pluging":"like_button", "action":"like", "target":" } } o Send message: usuário envia uma mensagem. { "name": "101", "time": , "eventinfo": { "social_network":"facebook", "social_pluging":"send_button", "action":"send_message", "target":" } } Twitter o Click: usuário clica no botão do twitter. { "name": "101", "time": , "eventinfo": { "social_network":"twitter", "social_pluging":"tweet_button", "action":"unlike", "target":" } } 28

29 Os seguintes métodos foram criados no desenvolvimento deste plug-in: PageCollect(config, prevent_default_submit): construtor do plug-in de página, os argumentos são as configurações e uma flag que indica se o prevent default do submit será executado ou não; setiframe(): constroi o elemento dom do iframe; setmessagetoiframe(obj): envia mensagem, obj, ao iframe; setiframe(): constroi o elemento dom do iframe; senddata(data, evt_name): envia os dados ao Iframe. Argumentos são os dados e o tipo de evento; bindfacebookevents(): realiza um bind com os eventos do botão do Facebook; bindpageevents(): realiza um bind com os eventos dos elementos de formulário da página; bindlikeevents(): realiza um bind com os eventos do botão de curtir da página de vídeo; bindtwitterevents(): realiza um bind com os eventos do botão do Twitter; bindgoogleplusevents(): realiza um bind com os eventos do botão do Google Plus; bindlinkedinevents(): realiza um bind com os eventos do botão do LinkedIn; start(): inicializa todos os binds do plugin da página. 29

30 4. Instalação As ferramentas que compõem o protótipo do serviço de monitoramento trabalham de forma hierárquica, onde o fluxo das informações inicia-se nas fontes de coleta, que enviam os dados para o coletor, que, por sua vez, tem que enviá-los para que sejam persistidos em base de dados e que possam ser consumidos pela ferramenta que realiza a análise e interpretação dos dados. Por fim, a ferramenta de gerenciamento de relatórios torna possível a visualização do resultado da análise dos dados na forma de gráficos e relatórios. Neste capitulo serão abordadas as etapas que compõem o processo de instalação de cada ferramenta, adotando a mesma hierarquia dos dados coletados. As ferramentas que serão abordadas neste capítulo possuem requisitos técnicos que variam de acordo com o escopo das informações. Portanto, serão abordados aqui procedimentos que envolvem execução de comandos UNIX para a instalação de alguns componentes. Para tanto, são requeridos conhecimentos básicos de configuração de parâmetros de rede para a comunicação entre os componentes, além de conhecimentos básicos de informações referentes à configuração de um computador, como processador, memória, disco rígido, entre outros Agentes de Monitoramento de Eventos O sistema de monitoramento elaborado pelo projeto GT-IMAV consiste em diversos módulos e ferramentas que se comunicam entre si para que no final uma ferramenta de análise possa capturar diversas informações de monitoramento e possa montar relatórios e tabelas dessas informações consolidadas. Dentro desse conjunto de ferramentas e módulos, os denominados agentes de monitoramento de eventos são os que iniciam o fluxo de captura dos dados brutos dentro do sistema de monitoramento, portanto nada mais justo iniciar os procedimentos de instalação pelos mesmos. Estes agentes são responsáveis pela captura das informações referentes ao transmissor de vídeo e ao servidor que hospeda o sistema de transmissão de vídeo. A Figura 13 apresenta a arquitetura proposta para a coleta dos dados de máquina e transmissor através dos agentes, lembrando que este cenário refere-se a apenas uma única instância, onde é possível escalar este cenário para múltiplas instâncias. Para realizar o acesso às informações pelo protocolo SNMP, os agentes necessitam de módulos intermediários, os chamados bridges, que funcionam como proxies de comunicação entre os protocolos SNMP e HTTP, pois os agentes coletam tais informações por meio do protocolo HTTP, usando o estilo arquitetural REST (Representational State Transfer)[6]. Para esse fim, foi desenvolvido o componente RESTful Monitor Bridge que acessa o serviço SNMP das fontes e repassa as informações de monitoração ao agente Multi Monitor Agent, que por sua vez, as reencaminham ao módulo do Coletor. 30

31 Figura 13 - Diagrama da arquitetura dos agentes de coleta dos dados de máquina e transmissor O procedimento de instalação desses agentes baseia-se na execução de um script, que por sua vez realiza a descompactação dos módulos necessários, assim como a configuração dos mesmos de acordo com a sua função dentro do sistema de monitoramento e coleta Instalação dos Agentes de Monitoramento e do Componente RESTful Monitor Bridge O componente RESTful Monitor Bridge obtém as informações fornecidas pelo serviço SNMP da máquina monitorada, em outras palavras, o agente de monitoramento consulta o RESTful Monitor Bridge e esse realiza uma consulta ao serviço SNMP da máquina. Atualmente há duas formas de se realizar a instalação dos agentes e do RESTful Monitor Bridge, a saber, por meio de um instalador ou simplesmente descompactando os pacotes desses componentes. O arquivo compactado que contém o RESTful Monitor Bridge é o restful-mon-bridge.tar.gz que possui a hierarquia de pastas: bin: contém os executáveis e os binários do componente; conf: contém os arquivos de configuração; lib: contém as bibliotecas das quais o componente é dependente; output: contém diversos arquivos estáticos utilizados pelo componente. 31

32 Analogamente, o arquivo compactado que contém o Multi Monitor Agent é o multi-mon-agent.tar.gz que segue a mesma hierarquia de pastas. O instalador, denominado fab-agents-installer, foi elaborado para facilitar o processo de instalação, desinstalação e configuração de tais componentes e também do serviço SNMP. Ele faz uso do framework denominado Fabric[7], que é uma biblioteca Python e ferramenta de linha de comando que permite a automatização na instalação de aplicações localmente ou remotamente (via SSH[8]), e também pode ser utilizado para tarefas de administração de sistemas. No arquivo de configuração fabsettings.py. do Fabric, estão contidas as informações principais para instalações remotas ou locais. Essas informações são as seguintes: REMOTE_HOST: endereço IP para acesso via ssh; REMOTE_USER: nome de usuário para acesso via ssh; REMOTE_PASSWORD: senha correspondente; REMOTE_SSH_PORT: porta correspondente; LOCAL_DIR_NAME: local com os pacotes dos componentes; REMOTE_INSTALLATION_PATH: local em que os componentes serão instalados, por exemplo, em /usr/local/java/gtimav/. Dos requisitos para esse instalador são o serviço SSH e o Fabric no servidor alvo, tanto remoto quanto local. Para a instalação desses componentes, execute os seguintes comandos (o servidor SSH deve ser instalado na máquina alvo de instalação, já o Fabric precisa estar disponível na máquina em que o instalador vai ser executado): sudo apt-get install fabric sudo apt-get install openssh-server Com o Fabric instalado, o instalador dos agentes deverá ser iniciado executando o seguinte comando dentro da pasta principal do instalador: fab install Em seu menu, o instalador exibirá as opções: What do you want to do? 1: Install 2: Configure 3: Uninstall 32

33 4: Exit Sendo que: 1. Install: para entrar no menu para instalação dos componentes; 2. Configure: para entrar no menu de configuração dos componentes; 3. Uninstall: para entrar no menu de desinstalação dos componentes; 4. Exit: para sair do instalador Ao entrar no menu Install, será apresentada uma listagem dos componentes que podem ser instalados ou configurados: Enter the option you want to configure: 1: Multi monitor agent 2: Restful monitor bridge 3: Snmp service 4: Exit Analogamente, os menus de desinstalação e configuração apresentam as mesmas opções. A seguir explicamos como podem ser feitas as configurações dos componentes a partir do instalador de maneira automatizada. Maiores detalhes sobre a semântica das configurações serão explanadas nas seções subsequentes. As configurações do Multi Monitor Agent podem ser feitas da seguinte forma, após a escolha da opção correspondente no menu do instalador, conforme o exemplo: What do you want to do? 1: Install 2: Configure 3: Uninstall 4: Exit Option: 2 Enter the option you want to configure: 1: Multi monitor agent 2: Restful monitor bridge 3: Snmp service 33

34 4: Exit Option: 1 [ ] sudo: rm /usr/local/java/gtimav/multi-mon-agent/conf/multi-mon-agent.xml [ ] out: sudo password: [ ] sudo: touch /usr/local/java/gtimav/multi-mon-agent/conf/multi-mon-agent.xml [ ] out: sudo password: [ ] sudo: echo '<?xml version="1.0" encoding="utf-8"?>' >> /usr/local/java/gtimav/multi-monagent/conf/multi-mon-agent.xml [ ] out: sudo password: [ ] sudo: echo '<agents>' >> /usr/local/java/gtimav/multi-mon-agent/conf/multi-mon-agent.xml [ ] out: sudo password: Write? or help to get some assistance Configuring agent description: [Agent 1] Configuring agent request period: [60000] Configuring source url: Configuring Collector url: Configuring source type: HOST Configuring client identifier: d cd949 Configuring application identifier: fe cd94a Configuring user: manager Configuring password: manager Configuring Backup Agent, attempts for send message: [3] Configuring Backup Agent, period between attempts for send message: [10000] Configuring Backup Agent, max number of messages in the repository: [1000] Configuring repository path: [../backup] Configure logs path: [../logs] Configuring logs pattern: [[%p %d{dd-mmm-yyyy HH:mm:ss}] %m %c %n] Configuring logs files size: [5MB] Analogamente, as configurações do RESTful Monitor Bridge seguem os seguintes passos de exemplo: What do you want to do? 34

35 1: Install 2: Configure 3: Uninstall 4: Exit Option: 2 Enter the option you want to configure: 1: Multi monitor agent 2: Restful monitor bridge 3: Snmp service 4: Exit Option: 2 RMB user: snmpuser RMB password: snmppassword Novamente de maneira análoga, o serviço SNMP (SNMP Service) pode ser configurado com os seguintes passos de exemplo: What do you want to do? 1: Install 2: Configure 3: Uninstall 4: Exit Option: 2 Enter the option you want to configure: 1: Multi monitor agent 2: Restful monitor bridge 3: Snmp service 4: Exit Option: 3 [ ] run: dpkg-query -W -f='${status} ' snmp [ ] out: install ok installed 35

36 [ ] run: dpkg-query -W -f='${status} ' snmpd [ ] out: install ok installed [ ] run: dpkg-query -W -f='${status} ' snmp-mibs-downloader [ ] out: install ok installed [ ] sudo: test -e "$(echo /etc/snmp/snmpd.conf)" [ ] out: sudo password: Configuring snmpd.conf Access control for SNMP Service SNMP user: snmpuser SNMP password: snmppassword Re-password: snmppassword Encryption method for SNMP password: [MD5] Partition to monitoring: [/] É importante frisar que caso o usuário opte pela configuração do serviço SNMP, o instalador verificará a existência de um arquivo de configuração padrão do SNMP, mais especificamente pelo arquivo snmpd.conf no diretório /etc/snmp. Caso o arquivo já exista, então o script irá criar um novo arquivo de configuração chamado snmpd.conf.gtimav, caso contrário ele irá simplesmente salvar as novas configurações no arquivo padrão Configuração dos Agentes de Monitoramento do Servidor e Transmissor O arquivo de configuração é instalado na pasta.../multi-mon-agent/conf do Multi Monitor Agent, e é denominado multi-mon-agent.xml e possui as configurações principais utilizadas por cada um de seus agentes de monitoramento. Os parâmetros configuráveis para os agentes são: id: identificador numérico do agente; description: descrição do agente; port-listen: porta de escuta em modo servidor; mode: define o estado de funcionamento do agente. Os valores possíveis para esse parâmetro são CLIENT e SERVER. Basicamente esta configuração determina se o agente solicita informações de uma 36

37 fonte (CLIENT), ou se aguarda o envio dessa informação por uma fonte (SERVER). Por padrão este parâmetro está configurado para CLIENT e não deve ser alterado no momento; request-period: período em milissegundos, que o agente usa para solicitar informações da fonte; source-url: endereço URL que o Agente usa para solicitar informação da fonte. (ex. collector-url: endereço URL que o Agente usa para enviar informação para o coletor. (ex. sourcetype: configuração do tipo de informação a qual a informação pertence, podendo variar no caso destes agentes entre HOST ou STREAMER; idclient: nome do (sistema) cliente monitorável, que é utilizado para identificação da fonte de coleta das informações, e especificada no modelo de dados; idapplication: nome da aplicação, que é utilizado para identificação da fonte de coleta, e especificada no modelo de dados; user: nome do usuário para autenticação na fonte; password: senha do usuário para autenticação na fonte; filters: são utilizados para fazer tratamento dos valores (ou inserções) de métricas. Com os filtros é possível modificar o tipo do valor da métrica, como passar de inteiro para string, por exemplo, ou então inserir alguma métrica com um valor default que não exista na fonte de dados (essa opção é importante, pois as métricas precisam existir por requisito dos ETLs quando esses realizam o parsing dessas informações). Os filtros possuem subparâmetros, tais como: o key: métrica a ser inserida ou a ter seu valor tratado; o type: tipo ao qual o valor da métrica será convertido; o default-value: valor padrão a ser posto no valor da métrica, caso ela não exista na fonte de monitoração; o regex: este parâmetro é utilizado caso se queira realizar a substituição do valor da métrica por algum outro, para tal é preciso indicar o padrão a ser buscado no valor da métrica para a substituição. Esse parâmetro possui subparâmetros: pattern: padrão a ser procurado para a substituição, podendo ser uma expressão regular ou o valor exato. Um exemplo seria a expressão regular /\d+ para substituir algum valor string em que se queira encontrar e modificar qualquer valor numérico após o caracter / ; replace-value: valor pelo qual o valor original da métrica deverá ser substituído. 37

38 Além desses parâmetros, os seguintes podem ser configurados de maneira global (localizado na tag <global>) ou de maneira específica para cada agente: Configurações de backup (no caso de falha de comunicação com o sistema de coleta): o send-message-attempts: número de tentativas que usa a classe BackupAgent para reenviar uma mensagem para o coletor; o send-message-attempts-period: período em milissegundos entre tentativas de envio das informações coletadas para o coletor; o repository-path: endereço no sistema de arquivos onde serão guardadas as mensagens que falharam na entrega ao coletor. Configurações de log: o path: caminho do diretório em que o arquivo de log será criado; o pattern: padrão das mensagens de log; o max-file-size: tamanho máximo dos arquivos de log. As bibliotecas utilizadas pelos agentes são instaladas em.../multi-mon-agent/lib. Os arquivos executáveis são encontrados em.../multi-mon-agent/bin. Entre os executáveis temos os seguintes arquivos: multi-mon-agent.jar (principal executável Java); multi-mon-agent.sh (script que inicializa o executável Java); Por fim, temos a pasta onde são armazenadas as informações que por algum motivo não puderam ser enviadas e foram armazenadas localmente para envio posterior. Está localizado em.../multi-monagent/backup. Dentro desta pasta temos o arquivo: agent_[<identificação do agente>].xml (armazena dados que não puderam ser enviados no momento da coleta para um dado agente, ex.: agent_1.xml para o agente de id igual a 1); Para executar o agente de monitoramento, navegue até a pasta onde se encontra o executável, e execute os seguintes comandos: Para iniciar: sudo./multi-mon-agent.sh start; Para verificar a situação de execução do agente: sudo./multi-mon-agent.sh status; Para parar: sudo./multi-mon-agent.sh stop; Neste ponto cabe uma observação com relação ao agente de monitoramento de máquina que pode utilizar o protocolo SNMP do Linux. Para o correto funcionamento deste componente, é necessário que o sistema operacional esteja devidamente configurado para a utilização deste protocolo, para tanto são necessários alguns passos que serão detalhados em seguida. 38

39 Configuração do protocolo SNMP Os comandos a seguir foram validados em um sistema executando um Ubuntu Server LTS, ou seja, caso necessite realizar os procedimentos em outro ambiente consulte a documentação específica do sistema operacional. Inicialmente instalar o serviço SNMP na máquina com os seguintes comandos: sudo apt-get install snmp snmpd snmp-mibs-downloader Após a instalação, será necessária a configuração do serviço que acabou de ser instalado através da edição do arquivo /etc/snmp/snmpd.conf com as seguintes diretivas: createuser [nome de usuário] MD5 [senha] No argumento [nome de usuário] será o usuário que terá acesso as informações disponibilizadas pelo protocolo SNPM, e o campo [senha] deverá corresponder a senha para o acesso, que deverá estar codificada utilizando o algoritmo MD5[9]. rouser [nome de usuário] (Full read-only access for SNMPv3) Nesse argumento deverá ser informado o mesmo usuário definido no item anterior, para configurar um acesso com privilégios restritos a somente leitura dos dados. disk [caminho] [espaço mínimo] E por fim o parâmetro [caminho] configura o caminho onde a partição a ser monitorada está montada (utilizado para o monitoramento das informações relacionadas ao disco rígido), e [espaço mínimo] especifica o tamanho mínimo para que o sistema emita um alerta, podendo ser preenchido um valor absoluto ou uma porcentagem do tamanho total da partição configurada Configuração do componente RESTful Monitor Bridge Os arquivos de configuração são instalados na pasta.../restful-mon-bridge/conf do RESTful Monitor Bridge, a qual possui, dentre outros, os seguintes arquivos: app-config.xml: configuração do contexto web no servidor de aplicativos, Jetty. Especifica a localização dos recursos REST na aplicação, as restrições de acesso, método de autenticação etc.; log4j.properties: define o comportamento dos registros (logs) da aplicação; realm.properties: especifica usuários, grupos e senhas para o acesso à aplicação; 39

40 snmp.properties: especifica usuários, grupos, senhas e outros dados para o acesso ao serviço SNMP; <nome-do-recurso>.properties: usado para estender a informação básica fornecida pela aplicação. O nome do recurso é importante, pois é utilizado na URL de busca das informações, por exemplo, digamos que o arquivo seja streamer.properties, a URL de busca será algo como Caso se queira acessar métricas específicas do serviço SNMP do Linux para informações de máquina, é importante frisar que no campo source_url na configuração dos agentes (.../multi-mon-agent/conf/multimon-agent.xml ) do Multi Monitor Agent, é possível configurá-lo para o recurso específico que já retorna os dados básicos de HOST, sem a necessidade da configuração do arquivo <nome-do-recurso>.properties. Os principais parâmetros configuráveis no arquivo snmp.properties que são utilizados para acesso ao serviço SNMP são os seguintes: ip-address: endereço IP do servidor que possui o serviço SNMP; port: porta para o serviço SNMP. Os demais parâmetros poderiam ser utilizados em cenários mais específicos do uso do serviço SNMP, para mais informações sugere-se consultar documentação específica desse serviço. Os arquivos <nome-do-recurso>.properties relacionam os OIDs a serem consultados do serviço SNMP. Os OIDs são relacionados como chave-valor, sendo a chave o nome ou etiqueta para indicar qual métrica está sendo monitorada e seu valor é o OID correspondente. Por exemplo, uma chave poderia ser n_requests para indicar o número de solicitações ao serviço de transmissão sob demanda, e seu valor deverá ser um OID, que nesse caso seria Dessa forma, é possível acrescentar ou remover os OIDs a serem usados na monitoração arbitrariamente, porém é recomendado não retirar nenhum dos OIDs que já estão presentes no arquivo de configuração padrão, pois a falta de um destes parâmetros acarretará em inconsistências de análise e geração de gráficos e tabelas. As bibliotecas utilizadas pelos agentes são instaladas em.../restful-mon-bridge/lib. Os arquivos executáveis são encontrados em.../restful-mon-bridge/bin. Entre os executáveis temos os seguintes arquivos: restful-mon-bridge.jar (principal executável Java); restful-mon-bridge.sh (script que inicializa o executável Java); 40

41 Para executar o agente de monitoramento, navegue até a pasta onde se encontra o executável, e execute os seguintes comandos: Para iniciar: sudo./restful-mon-bridge.sh start; Para verificar a situação de execução do agente: sudo./restful-mon-bridge.sh status; Para parar: sudo./restful-mon-bridge.sh stop; No anexo há um caso de uso para configuração dos agentes num cenário utilizando o serviço SNMP dos transmissores JDVoD e JDLive Coletor A instalação do componente responsável pela coleta e persistência das informações em base de dados compreende além do próprio serviço, uma série de módulos auxiliares que foram acoplados ao serviço de coleta, com o objetivo de torná-lo escalável, robusto e com uma alta confiabilidade contra falhas de diversas naturezas. Essas melhorias foram necessárias devido à importância desse componente dentro da arquitetura geral do sistema, sendo ele o centro de toda a cadeia de coleta e análise do projeto. A instalação deste componente envolve os seguintes comandos, que devem ser executados em um shell Unix. A instalação foi validada no sistema operacional Ubuntu Server LTS 64-bits. sudo apt-get install subversion sudo mkdir -p /srv/infocollect sudo chown `whoami` /srv/infocollect svn co /srv/infocollect cd /srv/infocollect Configuração do Coletor A configuração deste componente baseia-se na edição de um arquivo e a criação de um outro na raiz da instalação do projeto. Inicialmente copie o arquivo com o seguinte comando: cp local_settings.py-dist local_settings.py Feito a cópia, edite o arquivo com o editor de sua preferência com os parâmetros de conexão com a base de dados onde serão persistidas as informações coletadas. Completada a configuração para conexão com o banco de dados, devemos informar ao sistema o modo de execução que desejamos. Isso é feito através do comando: 41

42 echo production >.infocollect_env Feito isso, basta executar o seguinte comando para iniciar o módulo do coletor: sh scripts/bootstrap.sh Nesse momento, o sistema de coleta deverá estar funcionando e pronto para receber os dados monitorados Módulo de Gerenciamento O módulo de gerenciamento foi desenvolvido para realizar o gerenciamento das aplicações que serão monitoradas pelo sistema de monitoramento. A Figura 14 mostra a tela de gerenciamento com algumas aplicações cadastradas, e portanto, monitoradas pelo sistema. Figura 14 - Tela do sistema de gerenciamento Esse módulo é de extrema importância dentro do sistema de monitoramento, pois agrega além da função gerencial, uma camada de segurança ao sistema, impedindo que qualquer sistema ou agente externo com ciência da URL de coleta envie dados falsos de monitoramento, poluindo assim a análise final dentro dos relatórios, além de impedir ataques do tipo negação de serviço. O gerenciamento das aplicações monitoradas é feito através da geração de identificadores gerados por esse módulo, e que devem ser utilizados dentro dos agentes de monitoramento desenvolvidos pelo projeto, e documentados nesse manual. Para a utilização desses identificadores, consultar a seção correspondente ao agente de coleta a ser configurado com esses identificadores. 42

43 4.3. Pentaho O pacote que é responsável pela instalação do Pentaho consiste em dois arquivos, o install.sh e o biserverce stable.tar.gz. A instalação consiste em executar o script install.sh tomando o cuidado de executálo na mesma pasta onde se encontra o arquivo compactado biserver-ce stable.tar.gz. Assim que a execução seja finalizada, será criada a pasta biserver-ce stable, onde estarão localizados os arquivos start.sh, stop.sh, ctools-installer.sh, além de duas pastas, administration-console e biserver-ce. Para a execução deste módulo, será necessário apenas ter uma instalação Java rodando no sistema operacional, e basta executar o script start.sh para iniciar o sistema, e o script stop.sh realiza a parada do sistema. Figura 15 - Tela de administração Pentaho A configuração deste ambiente é feita através da interface WEB acessando o endereço da aplicação de administração deste sistema. A Figura 15 mostra a tela que será apresentada assim que for realizado o acesso. Por padrão, este sistema utiliza a porta 8099 para essa interface, utilizando as credencias admin/password Utilização das ferramentas de Relatório A finalidade principal deste projeto baseia-se na monitoração de eventos e na elaboração e exibição de gráficos e relatórios gerados a partir das informações que foram coletadas pelos agentes de monitoramento. 43