Jean Carlo Faustino <jean@rnp.br>
Graciela Machado Leopoldino <graciela@rnp.br>
SSO
- Serviço de Suporte a Operações
Rede Nacional de Ensino
e Pesquisa
1. Introdução
2.
Monitoramento
3. Análise dos logs
3.1
Tempo total de uso
3.2 Número total de
conexões
3.3 Uso das larguras de banda
3.4 Programas clientes
4.
Considerações finais
Referências
bibliográficas
Como já foi tratado no artigo "VRVS - Virtual Rooms Videoconferencing System: um sistema de videoconferência", publicado no NewsGeneration (v6, n4), o VRVS é um sistema que "tem como objetivo prover serviços de videoconferência e trabalho colaborativo de baixo custo, que usem o mínimo possível de largura de banda." [1]
Adotar esta solução de videoconferência traz, dentre outros, o benefício financeiro de uma solução de baixo custo. Por exemplo, para se disponibilizar uma MCU (Multipoint Control Unit) é necessário um hardware específico que, em geral, é solução proprietária - exceto uma solução que está, atualmente, em desenvolvimento, o OpenH323. Já o VRVS e seus refletores, que implementam as funcionalidades de uma MCU, podem ser instalados em computadores rodando Linux - sem, portanto, a dependência de um hardware específico.
Contudo, a instituição que adota o VRVS como solução precisa também ter em mente que isso traz consigo as implicações próprias de uma solução aberta - o que significa dizer que o servidor local (chamado de refletor VRVS) fará parte de uma rede mundial de servidores de videoconferência que, potencialmente, pode ser utilizado por qualquer usuário da Internet.
Mas o objetivo deste artigo não é o de discutir os prós e os contras desta solução, e sim ocupar-se com a questão relativa ao monitoramento do uso do serviço de VRVS.
Todo serviço de rede, após a sua implementação, precisa ser monitorado. Mais do que saber, simplesmente, se ele está sendo ou não utilizado, é preciso saber como e quanto ele está sendo usado - a fim de se tomar medidas preventivas e implementar as melhorias necessárias.
Uma das maneiras mais tradicionais de se realizar esse monitoramento é através da análise, freqüente, dos logs da respectiva aplicação. Neste pormenor, entretanto, o monitoramento do VRVS esbarra no obstáculo de que não há documentação alguma disponível sobre os logs desse serviço. Para superar este problema foi que teve início o trabalho que, aqui, está sendo apresentado.
Ele consistiu numa pesquisa realizada a partir do conteúdo do arquivo vrvs_h323.log, o qual localiza-se no diretório VRVS/H323/logs do home-directory do usuário vrvs. O trabalho, realizado no final do ano de 2002, ocupou-se com a versão 2.0 do VRVS, ou seja, a versão "estável" naquele período. Mas o que será aqui exposto não é o resultado da análise do refletor VRVS da RNP e, sim, a metodologia utilizada para a obtenção dos dados.
Conforme já mencionado, no momento da realização deste trabalho, não se encontrou documentação alguma sobre os logs gerados pelo VRVS - tanto no website do VRVS quanto no contato, por e-mail, com os desenvolvedores do sistema.
Iniciou-se, então, uma verificação
manual do conteúdo do arquivo vrvs_h323.log, em busca de alguns padrões
que viessem a fornecer algum dado sobre como o sistema estava sendo utilizado.
A partir dessa pesquisa inicial foi, desenvolvido um conjunto de scripts que viabilizou
a obtenção dos seguintes dados:
O tempo total de utilização é a primeira medida importante na análise dos logs do VRVS, pois ele indica quanto o serviço de videoconferência está sendo utilizado.
Obter esse número total, em script shell, não é algo trivial - em particular, no que se refere aos cálculos relativos às horas, minutos e segundos. Mas, deixando esses detalhes de lado, pode-se dizer que a essência do script pode ser resumida da seguinte maneira: procura-se por linhas com a string "duration"; exceto aquelas que possuírem a string "error" ou "No phone running". Essa diretiva irá retornar linhas semelhantes a esta:
"João José [200.10.20.98]" has cleared the call, duration 42:09
Feito isso, o próximo passo corresponde à obtenção dos valores que vêm após a string "duration". Após o somatório de todos os valores, de todas as respectivas linhas, tem-se o número do tempo total de uso.
O número total de conexões é outra medida importante e complementar ao tempo total de uso do sistema porque, dividindo-se este último pelo primeiro, é possível obter uma média do tempo utilizado para cada conexão.
A maneira de obter esses números, via script, é bastante simples. Em primeiro lugar, obtém-se o número total de conexões; em seguida, obtém-se apenas o número de conexões bem sucedidas; e, por último, o número de conexões com insucesso, que se obtém subtraindo-se o número de conexões bem sucedidas do número total de conexões.
Para se obter o número total de conexões, deve-se procurar por linhas com a string "duration" - o que fornecerá, como resultados, linhas semelhantes a que se segue. Contando-se, então, o número dessas linhas, obtém-se o valor procurado.
"João José [200.10.20.98]" has cleared the call, duration 42:09 Transport error calling "ip$mach.dtc.rnp.br", duration 0:01 No phone running for "ip$mach2.ldk.org.br", duration 0:01
Desse primeiro resultado, deve-se fazer um novo filtro eliminando as linhas com a string "error" e linhas com a string "No phone running". Assim, contando-se o número dessas linhas, obtém-se o número de conexões bem sucedidas.
E, por último, para a obtenção do número de conexões com insucesso, basta subtrair o número de conexões bem sucedidas do número total de conexões.
Do resultado, fornecido pela execução do script, pode-se construir um gráfico como o indicado no Gráfico 1, dentro de um contexto maior como, por exemplo, um relatório periódico de utilização do serviço.
Gráfico 1 - Total de conexões
As larguras de banda registradas no arquivo de log do VRVS referem-se apenas à banda utilizada pelo vídeo, ou seja, ela não inclui a banda utilizada pelo áudio - que costuma variar entre 9 Kbps e 78 Kbps. De qualquer maneira, identificar as larguras de banda utilizadas pelos usuários do VRVS é de vital importância até mesmo porque o princípio do VRVS é utilizar o mínimo possível desse recurso. [2]
Segundo a política de uso do sistema VRVS, a largura de banda recomendada é de, no máximo, 256 Kbps. Porém, considerando-se o fato de que os programas clientes de videoconferência permitem que o usuário configure qual largura de banda deve ser utilizada, pode acontecer que alguém acabe utilizando um número superior ao recomendado. Se isso estiver acontecendo, a política do VRVS é clara: o participante é desconectado do refletor e a sua autorização de acesso ao sistema VRVS é reconsiderada[2]. Portanto, é preciso identificar as larguras de banda, utilizadas pelo refletor local, para que as devidas medidas administrativas possam ser tomadas.
Para conseguir a informação de quais larguras de banda vêm sendo utilizadas, foi desenvolvido um script que, inicialmente, obtém todas as larguras registradas no arquivo de log para, em seguida, contar o uso de cada uma delas - o que é feito nas linhas que possuem a string "bandwidth" selecionando, a partir do próximo campo, o respectivo valor. A seguir, um exemplo de uma dessas linhas.
vrvsReflector: vrvs-rj.rnp.br ; vrvsAudioport: 48868 ; \ vrvsVideoport: 48870 ; Bandwidth: 640 ; CIF: 2 ; Audio: 0
Do resultado fornecido pela execução do script, a exemplo do número total de conexões, pode-se construir um gráfico como o indicado no Gráfico 2.
Gráfico 2 - Uso de larguras de banda
Uma última informação que pode ser obtida a partir da análise do log do VRVS é a identificação dos programas clientes utilizados pelos usuários do serviço. Apesar de não haver, em princípio, nenhuma medida administrativa a se tomar em relação a esses dados, eles podem servir para, por exemplo, constatar que a maioria dos acessos tem sido feitos com um aplicativo X ou Y.
O script, desenvolvido para este fim, procura esta informação nas linhas que possuem a string "Machine deleted". São linhas semelhantes ao exemplo a seguir:
Machine deleted: plutao.dtt.rnp.br (200.100.50.90) - Machine deleted: dkt.rnp.br (200.100.60.80) - CUseeMe 5.0 181:0:0 Machine deleted: opus.rnp.br (200.100.50.98) - Microsoft® NetMeeting® \ 3.0 181:0:21324
Nas linhas acima, a identificação do programa cliente vem logo depois do hífen que se segue ao número IP do cliente do serviço. Contudo, como se pode observar nessas linhas, o log nem sempre registra o nome do programa cliente. Assim, a solução que se aplica ao script desenvolvido para a obtenção desta informação, foi a de contar o número de vezes que os programas x, y, etc. foram utilizados como clientes de acesso do VRVS. Como se trata de um script shell, novos nomes de programas clientes podem ser cadastrados para ampliar a especificidade da verificação.
A exemplo dos outros dois tipos de informações anteriormente tratadas, a partir do resultado fornecido pela execução do respectivo script pode-se construir um gráfico como o indicado a seguir no Gráfico 3.
Gráfico 3 - Uso de clientes
Este artigo ocupou-se com o monitoramento do serviço VRVS. Contudo, o administrador de um refletor VRVS deve, também, ater-se ao monitoramento dos recursos do próprio servidor, como por exemplo: CPU, memória RAM, área de Swap, etc. Com base nesses dados, é possível não somente analisar a maneira como o serviço vem sendo utilizado mas, também, se o hardware (no caso, o computador) está sendo suficiente para a operação do serviço em questão.
Conforme se disse no início, esse trabalho foi realizado a partir do estudo do conteúdo de um arquivo específico de log do VRVS: o /home/vrvs/VRVS/H323/logs/vrvs_h323.log. Havia outros dois arquivos de log: o /home/vrvs/VRVS/MCU/logs/vrvs.log e o /home/vrvs/VRVS/MCU/logs/vrvs_mgr.log. No entanto, esses arquivos pouco informavam sobre os dados que se deseja obter - sobre os quais se discorreu ao longo desse texto.
A versão atualmente estável do VRVS (a 2.0) não traz, no arquivo de log vrvs_h323.log, nenhuma referência a data e hora em que o cliente acessou o serviço - o que se constitui um problema para análises periódicas do serviço. Uma alternativa seria a implementação de um rotacionamento deste arquivo - o que, por outro lado, também não se mostrou algo trivial. De qualquer maneira, espera-se que com o advento da nova versão do aplicativo (a 3.0) esses problemas sejam resolvidos - o que irá, então, exigir uma atualização nos scripts adotados.
Por último, deve-se ressaltar que esses scripts (disponíveis em http://www.rnp.br/videoconferencia/) ocuparam-se apenas com os acessos do tipo H323, não cobrindo, portanto, acessos provenientes do Quicktime, VNC e outros que não utilizem o padrão H323. Isto, porém, se explica pelo próprio conteúdo dos logs de acesso do servidor utilizado para realizar este trabalho, que registrou - ao longo de todo um ano - acessos exclusivamente do tipo H323.
[1] Leopoldino, Graciela Machado. VRVS - Virtual Rooms Videoconferencing System: um sistema de videoconferência. NewsGeneration, volume 6, número 4. RNP. http://www.rnp.br/newsgen/0207/vrvs.shtml.
[2] The VRVS Team. VRVS - Policy. http://www.vrvs.org/About/index.html.