GT-IMAV Manual da Aplicação - GT-IMAV - Segunda Fase

Transcrição

GT-IMAV
Manual da Aplicação
Versão 1.12
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/2013
1.0
Lucas Chigami
Versão Inicial
12/06/2013
1.1
Hélcio M. Pimentel
Complementação
13/06/2013
1.2
Reinaldo Matushima
Complementação e Revisão
24/09/2013
1.6
Hélcio M. Pimentel
Atualização
24/09/2013
1.7
Lucas Chigami
25/09/2013
1.8
Hélcio M. Pimentel
Correções e Complementações
25/09/2013
1.9
Lucas Chigami
29/09/2013
1.10
Reinaldo Matushima
Revisão e complementação
30/09/2013
1.11
Lucas Chigami
Complementação imagens
30/09/2013
1.12
Reinaldo Matushima
Revisão
2
Sumário
Lista de Figuras ................................................................................................................................................... 5
1.
2.
Introdução .................................................................................................................................................. 6
1.1.
Público Alvo ........................................................................................................................................ 7
1.2.
Documentos relacionados ................................................................................................................. 8
1.3.
Organização do documento ............................................................................................................... 8
Visão Geral ................................................................................................................................................. 9
2.1.
2.1.1.
Base transacional ......................................................................................................................... 11
2.1.2.
Base dimensional ......................................................................................................................... 12
2.2.
3.
4.
Modelo de Dados ............................................................................................................................. 10
Módulos de Monitoração das aplicações ........................................................................................ 14
2.2.1.
Módulo de Monitoração de Eventos do Player ....................................................................... 15
2.2.2.
Módulo de Monitoração dos Eventos de página ..................................................................... 16
2.3.
Módulo de Monitoramento do Servidor de Vídeo .......................................................................... 16
2.4.
Módulo de Monitoramento do Transmissor de Vídeo .................................................................... 17
2.5.
Módulo de Análise - Gráficos e Relatórios ....................................................................................... 18
2.6.
Módulo de Gerenciamento de Aplicações ....................................................................................... 19
Integração / Desenvolvimento ................................................................................................................. 21
3.1.
Módulo de Monitoração do Player .................................................................................................. 21
3.2.
Módulo de Monitoração da Aplicação Web .................................................................................... 23
Instalação ................................................................................................................................................. 30
4.1.
Agentes de Monitoramento de Eventos .......................................................................................... 30
4.1.1.
Instalação dos Agentes de Monitoramento e do Componente RESTful Monitor Bridge ........ 31
4.1.2.
Configuração dos Agentes de Monitoramento do Servidor e Transmissor ............................. 36
4.1.3.
Configuração do protocolo SNMP ............................................................................................ 39
4.1.4.
Configuração do componente RESTful Monitor Bridge ........................................................... 39
3
4.2.
4.2.1.
Configuração do Coletor .......................................................................................................... 41
4.2.2.
Módulo de Gerenciamento ...................................................................................................... 42
4.3.
5.
Coletor.............................................................................................................................................. 41
Pentaho ............................................................................................................................................ 43
4.3.1.
Utilização das ferramentas de Relatório .................................................................................. 43
4.3.2.
Pentaho BI Server ..................................................................................................................... 44
4.3.3.
Módulo Kettle........................................................................................................................... 46
Considerações .......................................................................................................................................... 48
Anexo I - Monitoramento por serviço SNMP de JDVoD e JDLive..................................................................... 49
Coleta de Informações de Transmissão de Vídeo .................................................................................... 49
Coleta de Informações de Máquina ......................................................................................................... 53
Referências ....................................................................................................................................................... 57
4
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 ...................................................................................... 10
Figura 4 - Base de dados transacional – Tabelas para armazenamento dos dados coletados ........................ 11
Figura 5 - Base de dados transacional – Tabelas para gerenciamento de aplicações monitoradas ................ 12
Figura 6 - Base de dados dimensional – Dimensões básicas........................................................................... 12
Figura 7 - Base de dados dimensional – Relação entre dimensões ................................................................ 13
Figura 8 - Base de dados dimensional – Tabelas Fato...................................................................................... 14
Figura 9 - Tela de Relatórios............................................................................................................................. 18
Figura 10 - Tela do Pentaho Report Design ...................................................................................................... 19
Figura 11 - Módulo de Gerenciamento – Clientes e aplicações....................................................................... 20
Figura 12 - Módulo de Gerenciamento - Parâmetros de uma aplicação ......................................................... 20
Figura 13 - Diagrama da arquitetura dos agentes de coleta dos dados de máquina e transmissor................ 31
Figura 14 - Tela do sistema de gerenciamento ................................................................................................ 42
Figura 15 - Tela de administração Pentaho ..................................................................................................... 43
Figura 16 - Tela de Exemplo da Interface WEB ................................................................................................ 44
Figura 17 - Tela Principal Pentaho ................................................................................................................... 45
Figura 18 - Tela de edição ................................................................................................................................ 46
Figura 19 - Tela da ferramenta Kettle .............................................................................................................. 47
5
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
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.
1.1.
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
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.
1.2.
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).
1.3.
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
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
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.
2.1.
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
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.
2.1.1. 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
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.
2.1.2. 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
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
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
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.
2.2.1. 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

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.
2.2.2. 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.
2.3.
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

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.
2.4.
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
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.
2.5.
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
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
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
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).
3.1.
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
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

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.
3.2.
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
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":1341488216440
}
}

Avaliações:
EvalEvent = 103
{
"name" : "103",
"eventInfo":{
24
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":1341488167787
}
}

Comentários:
CommentEvent = 102
{
"name" : "102",
"eventInfo":{
title : "",
fields : [
{question : "", value : "eu não vou comentar", correct = "" },
],
"time":1341488118923
}
}

Redes Sociais:
ShareEvent = 101

Google
o
Hover: usuário passa o mouse sobre o botão de +1.
{
"name": "101",
"time": 456789,
25
"eventInfo": {
"social_network":"google_plus",
"social_pluging":"plusone_button",
"action":"hover",
"target":"http://www.rnp.br/"
}
}
o
Confirm: aparece ou desaparece uma bolha de confirmação.
{
"name": "101",
"time": 456789,
"eventInfo": {
"action":"confirm",
}
}
o
On: usuário faz +1.
{
"name": "101",
"time": 456789,
"eventInfo": {
"action":"on",
}
}
26
o
Off: usuário desfaz +1.
{
"name": "101",
"time": 456789,
"eventInfo": {
"action":"off",
}
}

Facebook
o
Unlike: usuário não gosta de algum conteúdo.
{
"name": "101",
"time": 456789,
"eventInfo": {
"social_network":"facebook",
"social_pluging":"like_button",
"action":"unlike",
}
}
o
Like: usuário gosta de algum conteúdo.
{
"name": "101",
"time": 456789,
"eventInfo": {
27
"social_pluging":"like_button",
"action":"like",
}
}
o
Send message: usuário envia uma mensagem.
{
"name": "101",
"time": 456789,
"eventInfo": {
"social_pluging":"send_button",
"action":"send_message",
}
}

Twitter
o
Click: usuário clica no botão do twitter.
{
"name": "101",
"time": 456789,
"eventInfo": {
"social_network":"twitter",
"social_pluging":"tweet_button",
"action":"unlike",
}
}
28
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
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.
4.1.
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
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.
4.1.1. 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
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
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:
1: Install
2: Configure
3: Uninstall
4: Exit
Option: 2
3: Snmp service
33
4: Exit
Option: 1
[192.168.1.86] sudo: rm /usr/local/java/gtimav/multi-mon-agent/conf/multi-mon-agent.xml
[192.168.1.86] out: sudo password:
[192.168.1.86] sudo: touch /usr/local/java/gtimav/multi-mon-agent/conf/multi-mon-agent.xml
[192.168.1.86] sudo: echo '<?xml version="1.0" encoding="UTF-8" ?>' >> /usr/local/java/gtimav/multi-monagent/conf/multi-mon-agent.xml
[192.168.1.86] sudo: echo '<agents>' >> /usr/local/java/gtimav/multi-mon-agent/conf/multi-mon-agent.xml
Write ? or help to get some assistance
Configuring agent description: [Agent 1]
Configuring agent request period: [60000]
Configuring source url: http://localhost:8081/gt-imav/snmp/sysinfo
Configuring Collector url: http://localhost:8000/watch_generic/
Configuring source type: HOST
Configuring client identifier: 523849d314740518878cd949
Configuring application identifier: 523849fe14740518878cd94a
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:
34
1: Install
2: Configure
3: Uninstall
4: Exit
Option: 2
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:
1: Install
2: Configure
3: Uninstall
4: Exit
Option: 2
3: Snmp service
4: Exit
Option: 3
[192.168.1.86] run: dpkg-query -W -f='${Status}
' snmp
[192.168.1.86] out: install ok installed
35
' snmpd
' snmp-mibs-downloader
[192.168.1.86] sudo: test -e "$(echo /etc/snmp/snmpd.conf)"
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.
4.1.2. 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
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.
http://localhost:8081/gt-imav/snmp/oids/streamer,
http://localhost:8081gt-imav/snmp/oids/host);

collector-url: endereço URL que o Agente usa para enviar informação para o coletor.
(ex. http://localhost:8000/watch_generic/);

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
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
4.1.3. Configuração do protocolo SNMP
Os comandos a seguir foram validados em um sistema executando um Ubuntu Server 12.04.3 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.
4.1.4. 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

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
http://localhost:8081/gt-imav/snmp/oids/streamer.
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
“http://localhost:8081/gt-imav/snmp/sysinfo”, 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 “.1.3.6.1.4.1.9998.1.5.0”.
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
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.
4.2.
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 12.04.2 LTS 64-bits.
sudo apt-get install subversion
sudo mkdir -p /srv/InfoCollect
sudo chown `whoami` /srv/InfoCollect
svn co https://143.107.111.253/svn/LARC_Projects/trunk/GTIMAV/trunk/InfoCollect/
/srv/InfoCollect
cd /srv/InfoCollect
4.2.1. 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
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.
4.2.2. 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
4.3.
Pentaho
O pacote que é responsável pela instalação do Pentaho consiste em dois arquivos, o install.sh e o biserverce-3.10.0-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-3.10.0-stable.tar.gz. Assim que a
execução seja finalizada, será criada a pasta biserver-ce-3.10.0-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.
4.3.1. 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
Com esse intuito foi escolhida a ferramenta Pentaho Community, que além de ser gratuita, possuía o melhor
conjunto de recursos que poderiam ser utilizadas no contexto do projeto.
Dentro da suíte de ferramentas que o Pentaho Community disponibiliza, foram utilizadas duas ferramentas
para este projeto, o Pentaho BI Server, responsável pelo gerenciamento dos relatórios montados, e o Kettle,
que é a ferramenta responsável por realizar a fase de análise e tratamento dos dados coletados.
4.3.2. Pentaho BI Server
A interface principal da ferramenta utiliza uma interface WEB para o gerenciamento da apresentação dos
relatórios. A Figura 16 mostra um exemplo de um relatório aberto dentro da interface WEB do sistema de
gerenciamento WEB do Pentaho.
Figura 16 - Tela de Exemplo da Interface WEB
44
O pacote disponibilizado pelo projeto já possui uma customização visual, onde foram alteradas algumas cores
na interface principal, além da inclusão do logo do projeto no canto superior direito. A Figura 17 mostra a
tela inicial do sistema Pentaho assim que o usuário insere suas credencias de acesso.
Além das alterações visuais, já foram incorporados nesse pacote algumas ferramentas adicionais que não
estão disponíveis na versão que é distribuída por padrão pelo site do Pentaho.
Figura 17 - Tela Principal Pentaho
O ambiente WEB do Pentaho disponibiliza além da visualização dos gráficos e relatórios, ferramentas que
possibilitam a elaboração de outros, necessitando para tal conhecimentos de comandos SQL para realizar
consultas das informações que se deseje visualizar na forma de gráficos e tabelas, além de conceitos de CSS
para diagramar os componentes dentro do espaço do relatório. A Figura 18 mostra a tela que é utilizada para
a edição dos relatórios, mostrando os componentes disponíveis para utilização.
45
Figura 18 - Tela de edição
Este ambiente possui dois grupos de relatórios, os relatórios padrão e os customizados. Os relatórios do tipo
padrão são aqueles que apresentam as métricas que o grupo classificou como genéricas, onde qualquer
sistema de vídeo possui e estão sendo monitoradas. Já os relatórios customizados são aqueles em que
apresentam informações que de certa forma são únicas a uma certa aplicação de vídeo, ou que apresentam
relacionamentos entre certos parâmetros monitorados pelo sistema que são de interesse para determinados
públicos. Vale ressaltar que este tipo de relatório não é disponibilizado por padrão nesse ambiente,
necessitando a sua confecção de acordo com a sua necessidade.
4.3.3. Módulo Kettle
As informações coletadas pelos módulos são enviadas ao coletor, que por sua vez persiste os dados em um
banco de dados. Porém para a exibição dos mesmos em forma de gráficos e relatórios, é necessária uma
etapa anterior à consulta do Pentaho BI Server, que consiste em realizar uma análise e interpretação das
informações coletadas. Com essa finalidade foi utilizada a ferramenta Kettle presente na suíte do Pentaho.
46
Figura 19 - Tela da ferramenta Kettle
A Figura 19 mostra um exemplo de uma das diversas tarefas que foram programados na ferramenta para
realizar a análise dos dados referentes ao consumo do vídeo. Pode-se notar que a ferramenta utiliza o
conceito de blocos funcionais, onde cada um desses blocos é responsável por uma tarefa especifica, e ao
interligarmos todos esses blocos, são realizadas todas as análises e interpretações necessárias para a tarefa.
47
5. Considerações
Este documento representa o manual que reflete o status trabalho desenvolvido até a presente data.
Algumas alterações podem ter sido realizados eventualmente decorrente de evoluções no projeto. Para mais
informações, consultar a equipe técnica do projeto.
48
Anexo I - Monitoramento por serviço SNMP de JDVoD e JDLive
Apresenta indicação de configuração do serviço desenvolvido pelo GTIMAV para monitoração dos
transmissores de Vídeo Sob Demanda (JDVoD) e Vídeo ao Vivo (JDLive) que compõem o serviço vídeo da RNP
(Video@RNP).
Coleta de Informações de Transmissão de Vídeo
Configuração Módulo RESTful-Mon-Bridge
Configuração do componente Restful-Mon-Bridge a ser adotada para coleta de informações de serviço VoD
no arquivo vod.properties (ou live.properties para o JDLive):
vod_user_num=.1.3.6.1.4.1.9998.1.7.0
tx=.1.3.6.1.4.1.9998.1.11.0
start_time=.1.3.6.1.4.1.9998.1.3.0
n_requests=.1.3.6.1.4.1.9998.1.5.0
n_requests_failed=.1.3.6.1.4.1.9998.1.6.0
n_max_clients=.1.3.6.1.4.1.9998.1.8.0
n_cache_hits=.1.3.6.1.4.1.9998.1.9.0
n_cache_miss=.1.3.6.1.4.1.9998.1.10.0
tx_min=.1.3.6.1.4.1.9998.1.12.0
tx_max=.1.3.6.1.4.1.9998.1.13.0
tx_std_dev=.1.3.6.1.4.1.9998.1.14.0
tx_max_all=.1.3.6.1.4.1.9998.1.15.0
id_streamer=.1.3.6.1.4.1.29091.1.1.1.1.13.1.3.1
Caso o serviço for JDLive, use a métrica live_user_num em lugar de vod_user_num.
Conforme se pode observar, há algumas métricas a mais que as básicas já apresentadas, a semântica dessas
métricas é a seguinte:

n_requests_failed: número de requests negados o início do serviço;

tx_min: taxa mínima de transferência dentre todos os clientes atualmente conectados (kbit/s);

tx_max_all: taxa máxima de transferência observada desde o início do serviço (kbit/s);
49

n_max_clients: número de clientes máximo observado desde o início do serviço;

tx_std_dev: desvio padrão amostral da taxa de transferência dentre todos os clientes atualmente
conectados (kbit/s);

n_cache_miss: número absoluto de miss na cache desde o início do serviço (Cache não reflete o
conceito do JDLive);

tx_max: taxa máxima de transferência dentre todos os clientes atualmente conectados (kbit/s);

n_requests: número de requests recebidos desde o início do serviço;

n_cache_hits: número absoluto de hits na cache desde o início do serviço (Cache não reflete o
conceito do JDLive);

start_time: data e hora do início do serviço.
Configuração Módulo Multi-Mon-Agent
A seguir exemplo de configuração do componente Multi-Mon-Agent para coleta de informações de serviços
VoD ou Live no arquivo multi-mon-agent.xml:
<agent>
<id>1</id>
<description>Agent for dvod monitoring</description>
<port-listen>0</port-listen>
<mode>CLIENT</mode>
<request-period>20000</request-period>
<source-url>http://localhost:8081/gt-imav/snmp/oids/vod</source-url>
<collector-url>http://172.20.5.40:80/watch_generic/</collector-url>
<request-method>POST</request-method>
<referer>http://172.20.5.76</referer>
<sourcetype>streamer</sourcetype>
<idclient>51e5552314740546f0e612b9</idclient>
<idapplication>51e5598a1474057c68d24022</idapplication>
<user>manager</user>
<password>manager</password>
<backup-agent>
50
<send-message-attempts>3</send-message-attempts>
<send-message-attempts-period>10000</send-message-attempts-period>
<repository-max-number-messages>1000</repository-max-number-messages>
<repository-path>../backup</repository-path>
</backup-agent>
<log>
<path>../logs</path>
<pattern>[%p|%d{dd-MMM-yyyy | HH:mm:ss}] %m %c %n</pattern>
<max-file-size>5MB</max-file-size>
</log>
<filters>
<attribute-filter>
<key>rx</key>
<type>STRING</type>
<default-value></default-value>
</attribute-filter>
<attribute-filter>
<key>tx</key>
<type>STRING</type>
</attribute-filter>
<attribute-filter>
<key>id_streamer</key>
<type>STRING</type>
<regex>
<pattern>/\d+</pattern>
<replace-value></replace-value>
</regex>
</attribute-filter>
<attribute-filter>
<key>live_sessions</key>
51
<type>STRING</type>
</attribute-filter>
<attribute-filter>
<key>vod_sessions</key>
<type>STRING</type>
</attribute-filter>
<attribute-filter>
<key>live_user_num</key>
<type>STRING</type>
</attribute-filter>
<attribute-filter>
<key>vod_user_num</key>
<type>STRING</type>
</attribute-filter>
<attribute-filter>
<key>sessions_num</key>
<type>STRING</type>
</attribute-filter>
<attribute-filter>
<key>start_time</key>
<type>TIMESTAMP_AS_STRING</type>
<source-format>dd/MM/yyyy - HH:mm:ss</source-format>
</attribute-filter>
</filters>
</agent>
Caso o serviço for JDLive, o campo source_url substitua por:
52
<source-url>http://localhost:8081/gt-imav/snmp/oids/live</source-url>
Coleta de Informações de Máquina
Configuração Módulo RESTful-Mon-Bridge
Configuração do componente Restful-Mon-Bridge a ser adotada para coleta de informações de máquina pelo
serviço SNMP do JDLive ou JDVoD no arquivo host.properties (basta a configuração em apenas um dos
serviços, pois tais métricas estão disponibilizadas por ambos transmissores):
cpu_info=.1.3.6.1.4.1.9998.1.20.0
cpu_used=.1.3.6.1.4.1.9998.1.21.0
memo_total_size=.1.3.6.1.4.1.9998.1.23.0
memo_used=.1.3.6.1.4.1.9998.1.24.0
memory_max_usage=.1.3.6.1.4.1.9998.1.25.0
cpu_max_usage=.1.3.6.1.4.1.9998.1.22.0
threshold_cpu=.1.3.6.1.4.1.9998.1.26.0
threshold_memory=.1.3.6.1.4.1.9998.1.27.0
hostname=.1.3.6.1.4.1.29091.1.1.1.1.13.1.3.1
Conforme se pode observar, há algumas métricas a mais que as básicas já apresentadas, a semântica dessas
métricas é a seguinte:

threshold_memory: limite máximo de Memory configurado após o qual clientes são rejeitados (%);

memory_max_usage: nível de memória máximo desde o início do serviço;

cpu_max_usage: nível instantâneo de uso da CPU (média de todas as CPU) (%);

threshold_cpu: limite máximo de CPU configurado após o qual clientes são rejeitados (%).
Configuração Módulo Multi-Mon-Agent
A seguir exemplo de configuração do componente Multi-Mon-Agent para coleta de informações de máquina
a partir do serviço SNMP do JDVoD ou JDLive no arquivo multi-mon-agent.xml:
<agent>
<id>2</id>
<description>Agent for host (via dvod) monitoring</description>
<port-listen>0</port-listen>
<mode>CLIENT</mode>
53
<request-period>20000</request-period>
<source-url>http://localhost:8081/gt-imav/snmp/oids/host</source-url>
<collector-url>http://172.20.5.40:80/watch_generic/</collector-url>
<request-method>POST</request-method>
<referer>Erro! A referência de hiperlink não é válida.>
<sourcetype>streamer</sourcetype>
<idclient>51e5552314740546f0e612b9</idclient>
<idapplication>51e5598a1474057c68d24022</idapplication>
<user>manager</user>
<password>manager</password>
<backup-agent>
<send-message-attempts>3</send-message-attempts>
<send-message-attempts-period>10000</send-message-attempts-period>
<repository-max-number-messages>1000</repository-max-number-messages>
<repository-path>../backup</repository-path>
</backup-agent>
<log>
<path>../logs</path>
<pattern>[%p|%d{dd-MMM-yyyy | HH:mm:ss}] %m %c %n</pattern>
<max-file-size>5MB</max-file-size>
</log>
<filters>
<attribute-filter>
<key>net_rx</key>
<type>STRING</type>
</attribute-filter>
<attribute-filter>
<key>net_tx</key>
<type>STRING</type>
54
</attribute-filter>
<attribute-filter>
<key>hostname</key>
<type>STRING</type>
<regex>
<pattern>/\d+</pattern>
<replace-value></replace-value>
</regex>
</attribute-filter>
<attribute-filter>
<key>cpu_info</key>
<type>STRING</type>
</attribute-filter>
<attribute-filter>
<key>cpu_used</key>
<type>STRING</type>
</attribute-filter>
<attribute-filter>
<key>memo_used</key>
<type>STRING</type>
</attribute-filter>
<attribute-filter>
<key>memo_total_size</key>
<type>STRING</type>
</attribute-filter>
55
<attribute-filter>
<key>memo_swap_used</key>
<type>STRING</type>
</attribute-filter>
<attribute-filter>
<key>disk_total_size</key>
<type>STRING</type>
</attribute-filter>
<attribute-filter>
<key>disk_used</key>
<type>STRING</type>
</attribute-filter>
<attribute-filter>
<key>net_info</key>
<type>STRING</type>
</attribute-filter>
<attribute-filter>
<key>net_bandwidth</key>
<type>STRING</type>
</attribute-filter>
</filters>
</agent>
56
Referências
[1] http://www.longtailvideo.com/players/ (acesso em 06/08/2012)
[2] http://www.snmp.com/ (acesso em 07/08/2012)
[3] http://www.lavid.ufpb.br/ (acesso em 10/06/2013)
[4] http://community.pentaho.com/ (acesso em 08/08/2012)
[5] http://reporting.pentaho.com/report_designer.php (acesso em 12/06/2013)
[6] http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm (acesso em 25/09/2013)
[7] http://docs.fabfile.org/en/1.8/ (acesso em 25/09/2013)
[8] http://tools.ietf.org/html/rfc4252 (acesso em 25/09/2013)
[9] http://www.ietf.org/rfc/rfc1321.txt (acesso em 20/08/2012)
57

GT-IMAV Manual da Aplicação - GT-IMAV - Segunda Fase

Transcrição

Documentos relacionados

Unidade 3 - Fernando Zaidan

22 Visto de profissional de outro Crea - EXT - CREA

Como acessar a sala de conferência

Guia do usuário da Transmissão de Vídeo ao Vivo Descrição O

Alfabeto fonético universal

SNMP - diatinf

Proprietário do maior acervo de desenhos animados do mundo, o

Rider de Som

lifepak 12 - Medtronic

Instalando C**Tools no Pentaho Business Intelligence Community