Luciano Paschoal Gaspary, Ederson Canterle

Transcrição

1 Um Agente SNMP para Monitoração do Tempo de Resposta de Interações de Protocolos Luciano Paschoal Gaspary, Ederson Canterle Centro de Ciências Exatas e Tecnológicas Universidade do Vale do Rio dos Sinos Av. Unisinos São Leopoldo, RS paschoal@exatas.unisinos.br, canterle@terra.com.br Abstract. This paper proposes an approach for protocol interaction response time measurement that uses a passive network traffic monitoring technique and stores the resulting statistics in a management information base compatible with the SNMP architecture. The work is within the scope of Trace platform, which provides support for high-layer protocol, service and networked application management. The implementation of the proposed approach comprises the extension of the monitoring agent, key component of the platform, so that it stores information related to response time and generates performance-related reports, besides monitoring the number of trace occurrences. Resumo. Este artigo propõe uma abordagem para a medição do tempo de resposta de interações de protocolos que utiliza a técnica de monitoração passiva do tráfego de rede e armazena as estatísticas resultantes em uma base de informações de gerenciamento compatível com a arquitetura SNMP. O trabalho está inserido no escopo da plataforma Trace, que oferece suporte ao gerenciamento de protocolos de alto nível, serviços e aplicações em rede. A implementação da abordagem proposta compreende a extensão do agente de monitoração, componente-chave da plataforma, para que ele, além de monitorar o número de ocorrências de traços, passe a contabilizar informações relacionadas ao seu tempo de reposta e gerar relatórios sobre desempenho. 1 Introdução A crescente utilização das redes de computadores como suporte a aplicações que requerem altas disponibilidade e desempenho, como portais web e aplicações de comércio eletrônico, tem provocado a investigação de mecanismos que, além de garantir o bom funcionamento da infraestrutura física da rede, permitam identificar a saúde dos serviços e aplicações que são executados sobre elas. Uma das métricas mais consideradas para avaliar o estado funcional de uma aplicação é o seu desempenho. Nesse contexto entendese desempenho como sendo a capacidade de resposta da infraestrutura e de determinada aplicação em um ambiente de rede [Sturm, 1999]. Um dos indicadores mais importantes para medir o desempenho de aplicações é o tempo de resposta das transações (interações dos protocolos). Existem diversas aplicações comerciais preocupadas em oferecer soluções para medir o desempenho de aplicações. VitalSuite [Lucent, 2002], Pegasus Network and Application Monitor [NetIQ, 2002], Application Performance Management [Tivoli, 2002], ETE Watch [Candle, 2002], ehealth [Concord, 2002], AppScout [NetScout, 2002] e Spectrum [Aprisma, 2002] são exemplos dessas aplicações. Entre as abordagens utilizadas para medir o tempo de resposta, destacam-se cinco. Na primeira delas agentes

2 de software são instalados nas estações dos usuários finais. Esses agentes monitoram as transações executadas pelo usuário, calculam os tempos decorridos e, de tempos em tempos, informam os resultados obtidos a uma estação central. VitalSuite, ETEWatch, Pegasus Application Monitor, Application Performance Management e Spectrum são exemplos de aplicações de gerenciamento que utilizam agentes nas estações dos usuários. Uma variante dessa abordagem, implementada nas aplicações ehealth e Spectrum, é a presença de agentes nas estações servidoras monitorando o comportamento das aplicações (por exemplo, através da observação permanente dos arquivos de log). A terceira abordagem trabalha com o acompanhamento da execução de transações artificiais, disparadas por estações posicionadas em segmentos a partir dos quais seja importante medir o desempenho percebido pelos usuários. VitalSuite, Pegasus Network Monitor, Application Performance Management e Spectrum oferecem esse tipo de funcionalidade. A quarta (e mais poderosa) abordagem, usada pela plataforma Tivoli, é baseada na instrumentação da aplicação a ser monitorada nos lados cliente e/ou servidor. Na quinta abordagem, por fim, as informações são obtidas através da monitoração passiva do tráfego de rede. AppScout e VitalSuite são aplicações que implementam essa técnica. As primeiras quatro abordagens supracitadas são invasivas. A utilização de agentes nas estações dos usuários finais ou no servidor implica o consumo de recursos e perda de desempenho das estações onde for instalado. A utilização de transações sintéticas para medir o desempenho de aplicações apresenta como desvantagem a utilização de recursos adicionais de rede. A instrumentação de software é muito útil para monitorar aplicações construídas na própria organização, mas não pode ser usada para monitorar protocolos e aplicações proprietárias. Além disso, são necessários investimentos consideráveis para treinar pessoal em como usar as APIs (Application Programming Interface) de programação. Além da maioria das abordagens existentes ser invasiva, outro problema existente com as aplicações de gerenciamento disponíveis é que elas são proprietárias, induzindo as organizações a adquirir software de gerenciamento de um único fabricante, mesmo que ele não atenda satisfatoriamente a boa parte das necessidades. Torna-se uma tarefa complicada integrar as informações geradas pelas aplicações recém mencionadas às plataformas de gerenciamento já em uso nas organizações, comprometendo a obtenção de uma visão integrada do funcionamento da infraestrutura de rede e das aplicações. Este artigo propõe uma abordagem para a monitoração do tempo de resposta de interações de protocolos que (a) utiliza a técnica de monitoração passiva do tráfego de rede e (b) armazena as estatísticas resultantes em uma base de informações de gerenciamento compatível com a arquitetura SNMP (permitindo que estatísticas possam ser obtidas a partir de qualquer aplicação de gerenciamento que suporte SNMP). O trabalho está inserido no escopo da plataforma Trace, que oferece suporte ao gerenciamento de protocolos de alto nível, serviços e aplicações em rede [Gaspary et al., 2002]. A implementação da abordagem proposta compreende a extensão do agente de monitoração, componentechave da plataforma, para que ele, além de monitorar o número de ocorrências de traços, passe a contabilizar informações relacionadas ao seu tempo de reposta e gerar relatórios sobre desempenho. A especificação das interações de protocolos, cujo tempo de resposta se deseja medir, é realizada com a utilização da linguagem PTSL (Protocol Trace Specification Language), proposta em [Gaspary et al., 2001]. Estas especificações são usadas pelo gerente de rede para configurar remotamente o agente de monitoração (através da MIB Script [Levi e Schönwälder, 2001]). Para configurar as medições de desempenho a serem realizadas e recuperar os resultados obtidos o gerente interage com o agente, também via SNMP, através de um sub-conjunto da MIB Application Performance Measurement [Waldbusser, 2002].

3 As principais contribuições desse trabalho são três. Primeiro, desenvolvemos uma solução para medir o tempo de resposta de interações de protocolos e aplicações que, ao mesmo tempo, utiliza uma técnica baseada em monitoração passiva e fornece resultados via SNMP (permitindo sua integração com sistemas de gerenciamento já em uso nas organizações). Segundo, propomos um mecanismo mais flexível para especificar, em tempo de execução, as transações cujo tempo de resposta deve ser medido (em substituição ao mecanismo proposto pela MIB APM). Terceiro, disponibilizamos um agente de monitoração baseado em software aberto e gratuito, que é uma extensão ao NET-SNMP [NET-SNMP, 2002], que pode ser utilizado em qualquer instituição (com custo próximo de zero) e como base para outros trabalhos acadêmicos. O artigo está organizado da seguinte forma: a seção 2 descreve alguns trabalhos relacionados. Na seção 3 apresenta-se resumidamente como representar, usando a linguagem PTSL, as interações de protocolos a serem monitoradas. Em seguida, a seção 4 introduz o sub-conjunto da MIB Application Performance Measurement utilizado. O artigo prossegue com uma apresentação detalhada, na seção 5, da arquitetura do agente de monitoração. A seção 6 aborda alguns exemplos de uso do agente e a seção 7 encerra o artigo com algumas considerações finais e perspectivas de trabalhos futuros. 2 Trabalhos Relacionados Boa parte dos trabalhos relacionados foi mencionada na introdução. Como pôde ser observado, as abordagens utilizadas pelas aplicações de gerenciamento de desempenho são, na sua maioria, invasivas. Não obstante, oferecem um conjunto significativo de informações. A utilização de agentes de software nas estações dos usuários finais é a abordagem que oferece os resultados mais precisos com relação ao desempenho, uma vez que agrupa os atrasos da rede, da aplicação servidora e da própria aplicação cliente (ex: para apresentar os resultados). Para Boardman [Boardman, 1999], a abordagem mais apropriada é aquela onde as aplicações são monitoradas por agentes de software localizados no lado servidor. Segundo ele, embora essa abordagem falhe ao não considerar atrasos gerados pela estação cliente e a própria rede, ela permite centralizar as medições no servidor, que é justamente onde ocorrem as maiores variações de desempenho. Monitorar transações através da observação do tráfego de rede é a técnica que produz o menor impacto na infraestrutura existente, pois não requer a instalação/configuração de software nas estações clientes e servidoras, não compromete a rede com tráfego de transações artificiais, nem exige que as aplicações sejam instrumentadas. Além disso, é flexível o bastante para realizar medições de acordo com as necessidades do gerente da rede. Quanto mais perto da estação servidora o agente estiver localizado, resultados mais semelhantes à técnica onde são utilizados agentes de software na estação servidora serão obtidos. Por outro lado, quanto mais perto à estação cliente o agente estiver, resultados mais próximos à técnica onde são utilizados agentes de software nas estações dos usuários finais serão gerados. Um dos pontos críticos da monitoração passiva é determinar, em ambientes segmentados, onde os agentes de monitoração serão posicionados. O desempenho desses agentes para capturar e processar pacotes em redes de alta velocidade também pode ser um aspecto crítico. Trabalhos mais recentes relacionados a gerenciamento de desempenho têm explorado uma abordagem baseada na instrumentação transparente de aplicações. [Debusmann et al., 2002] propõem a medição de desempenho de aplicações EJB (Enterprise Java Beans) a partir da instrumentação do servidor EJB. [Villagrá et al., 2002] seguem abordagem similar ao proporem a instrumentação transparente de aplicações CORBA e EJB. Em ambos os casos, nenhum esforço de programação é necessário. Como

4 & a instrumentação é realizada automaticamente, todos os componentes utilizados são instrumentados da mesma maneira, permitindo a comparação de resultados. Embora conceitualmente interessante, a abordagem é limitada a uma classe restrita de aplicações, não podendo ser usada para monitorar o desempenho de protocolos convencionais e aplicações desenvolvidas em outros ambientes. 3 Representação das Interações a Serem Monitoradas Esta seção apresenta, de forma resumida, a linguagem para representação de traços de protocolos denominada PTSL (Protocol Trace Specification Language), que foi originalmente descrita em [Gaspary et al., 2001]. Através dessa linguagem, o gerente de rede deve especificar as interações de protocolos (transações), cujos tempos de resposta devam ser medidos. A linguagem, baseada no conceito de máquinas de estados finitos, é composta de uma notação gráfica (Graphical PTSL) e uma textual (Textual PTSL). As notações não são equivalentes. A textual permite a representação completa de um traço, incluindo a especificação da máquina de estados e os eventos que provocam as transições. A notação gráfica, por sua vez, equivale a um sub-conjunto da textual, oferecendo a possibilidade de representar pictoricamente a máquina de estados e de apenas rotular os eventos que habilitam as transições. 3.1 Graphical PTSL As figuras 1 e 2 ilustram alguns traços de protocolos descritos através da notação gráfica da linguagem. O traço apresentado na figura 1 permite monitorar requisições HTTP que são retornadas com sucesso, podendo ser usado para contabilizar o tempo de resposta dos acessos bem sucedidos que são realizados a um servidor web. Este tipo de informação pode ser bastante útil para hospedeiros de sites, portais e aplicações de comércio eletrônico por permitir identificar regiões a partir das quais o tempo de resposta percebido pelos usuários esteja elevado. O tempo de resposta de outras interações previstas no protocolo HTTP pode ser monitorado de forma similar. Por exemplo, o tempo decorrido entre a submissão de um determinado formulário via browser e o respectivo retorno pode ser medido com a especificação de um traço onde a requisição GET da figura 1 é substituída por algo como POST /path/script.cgi HTTP/1.1. "!# $ ')(./ " "4"+,- 5/ 0 " "3 489 " " : "!; < & --, "% =/ > 4 /? &- -? 7 4 A - BC 3 4 D /E "% '< " F G 07/H96 I" 7 /4 J"? &"KL " & - -& +M N +M N-- ')O) "" * +", + & -- Figura 1: Traço para monitorar requisições HTTP bem sucedidas Conforme pode ser observado na figura 1, na notação gráfica os estados são representados por círculos. A partir do estado inicial denominado idle podem ser criados outros n estados, desde que os mesmos sejam sempre atingíveis por alguma transição. O estado final é identificado por dois círculos concêntricos. As transições são representadas por setas unidirecionais. A seta contínua indica que a transição é provocada pela estação cliente, enquanto a pontilhada determina que a transição é disparada por um evento provocado pela estação servidora. O texto associado a uma transição apenas rotula o evento causador da transição; a especificação do mesmo só pode ser realizada através

5 l l X l l da notação textual. A notação gráfica oferece ainda um construtor onde são incluídas informações sobre o traço, que são relevantes para a catalogação e o controle de versão das especificações. A figura 2 ilustra outros exemplos. Em (a) e (b) são apresentados os traços que modelam a autenticação de um usuário junto a um servidor POP3. Em (a) o nome do usuário é informado e em (b), a senha. Esses traços podem ser usados para contabilizar o tempo de resposta de cada etapa do processo de autenticação. Se o gerente estiver interessado em contabilizar um único tempo de resposta, contemplando todo o processo de autenticação, então os dois traços podem ser mesclados. Nesse caso, o traço resultante possuiria quatro estados: idle idle. Outras interações significativas do protocolo podem ser modeladas substituindo a transição USER em (a) por LIST 1, RETR 2 ou DELE 3, apenas para citar algumas. O traço ilustrado em (c) permite monitorar o tempo de resposta de solicitações de resolução de nomes destinadas a um servidor DNS. A linguagem PTSL permite, também, modelar traços de protocolos que não pertencem ao nível de aplicação. Por exemplo, o ilustrado em (d) especifica os três passos do processo de abertura de uma conexão TCP (three-way handshaking). Esse traço pode ser usado para medir o tempo despendido para iniciar conexões TCP entre quaisquer dois end-points. P Q R S T U V"WV X)Y:Z[\"]^_` _a b"cdë [efgfh"i _ej m/no p P"Q RS T U V W)V/X9Yu9f^\"]^_ab cd ev_bg\ ] wb j V"u/n/n _[ k\ q Wr sb t P Q R S T U p\ y f _g_cd e[ \ i\ge kf cdë [\]e"z)\ j { n i\y"f\ g ^ _[ k\ {9 /n}i\ ~"k sat _["k\ q W)r sxt P Q RS T U o/g ^b"x\"k\ a_z)\"] ^ e[ \ae"]\ d ë )V"j " 9Vn/ƒ _["k\ )Vu/ )r s[t )V n/ƒ u/ )r Figura 2: Representação gráfica de traços de protocolos 3.2 Textual PTSL A figura 3 apresenta a especificação textual do traço ilustrado anteriormente na figura 1. Toda especificação escrita em Textual PTSL inicia com a palavra Trace e encerra com EndTrace (linhas 1 e 37). As informações para catalogação e controle de versão aparecem logo após a palavra-chave Trace (linhas 2 a 7). Em seguida, a especificação é dividida em três seções: MessageSection (linhas 9 a 22), GroupSection (não usada neste exemplo) e StatesSection (linhas 24 a 35). Em MessagesSection e em GroupSection são definidas as mensagens que provocam a evolução do traço. Em StatesSection é definida a máquina de estados que representa o traço. 1 Solicita informações sobre as mensagens armazenadas no servidor. 2 Solicita a recuperação (download) de mensagem para o cliente de . 3 Solicita a remoção de uma mensagem no servidor.

6 O evento que provoca a evolução da máquina de estados é a observação na rede de um pacote que apresente campos com valores equivalentes aos especificados em uma mensagem (Message). A forma de especificar os campos a serem analisados depende do tipo de protocolo a ser monitorado. No caso de protocolos baseados em caracteres, que possuem campos de tamanho variável separados por espaços em branco (ex: HTTP e POP), a identificação de um campo é determinada pela posição do mesmo na mensagem (estratégia FieldCounter). Em HTTP/ , por exemplo, HTTP/1.1 ocupa a posição 0 e 200, a posição 1 da mensagem. Por outro lado, a identificação de campos em protocolos binários, caracterizados por possuírem campos de tamanho fixo (ex: TCP e DNS), é determinada por um offset em bits a partir do início do cabeçalho do protocolo em questão até o início do campo desejado; além da posição inicial do campo é preciso indicar ainda o número de bits que o campo ocupa (estratégia BitCounter). 1 Trace "Requisicao HTTP retornada com sucesso" 2 Version: Description: Acesso HTTP com resposta Key: HTTP, 200, sucesso 5 Port: 80 6 Owner: Luciano Paschoal Gaspary 7 Last Update: Fri, 27 Dec :16:00 GMT MessagesSection 11 Message "GET" 12 MessageType: client 13 FieldCounter Ethernet/IP/TCP 0 GET 14 EndMessage Message "HTTP/ " 17 MessageType: server 18 FieldCounter Ethernet/IP/TCP 0 HTTP/ FieldCounter Ethernet/IP/TCP EndMessage EndMessagesSection StatesSection 25 FinalState idle State idle 28 "GET" GotoState 2 29 EndState State 2 32 "HTTP/ " GotoState idle 33 EndState EndStatesSection EndTrace Figura 3: Representação textual de um traço O traço ilustrado na figura 1 é de um protocolo baseado em caracteres. A especificação da mensagem GET é ilustrada na figura 3 (linhas 11 a 14). Na linha 12 a mensagem é definida como sendo do tipo client, significando que a transição de estado à qual esta mensagem está associada será provocada pela estação cliente. Na linha

7 13 é especificado o único campo a ser analisado. As informações necessárias para identificá-lo são: estratégia de localização (FieldCounter), encapsulamento do protocolo (Ethernet/IP/TCP), posição do campo (0), valor esperado (GET) e, opcionalmente, descrição do campo. A definição da mensagem HTTP/ (linhas 16 a 20) segue o mesmo raciocínio. Mais informações sobre a linguagem PTSL, incluindo outros exemplos de traços, podem ser obtidas em [Gaspary et al., 2001]. 4 A MIB Application Performance Management A MIB APM (Application Performance Management), proposta em [Waldbusser, 2002], define objetos que disponibilizam estatísticas sobre o desempenho (ex: tempo de reposta) que os usuários percebem nas aplicações que utilizam. Os métodos a serem empregados para construir essas estatísticas não são especificados na MIB, de modo que cada fabricante pode optar pelos que julgar serem mais convenientes. Originalmente projetada para oferecer informações sobre o desempenho de aplicações orientadas à transação, à vazão e a fluxo, a MIB foi simplificada para oferecer suporte apenas ao primeiro tipo (orientadas à transação) [Gaspary et al., 2002], que são as aplicações alvo da plataforma Trace. 4.1 Relatórios de desempenho Os traços (transações) observados por um agente APM podem ser agregados de várias formas, gerando relatórios estatísticos de desempenho. A granularidade desses relatórios e a freqüência com que devem ser gerados podem ser especificados pelo gerente da rede. As estatísticas oferecidas pela MIB, após a agregação de um conjunto de traços, são: TransactionCount: número de traços observado durante o período; SuccessfulTransactions: número de traços que completaram com sucesso; ResponsivenessMean: média aritmética do desempenho de todos os traços agregados que completaram com sucesso; ResponsivenessMin: desempenho mínimo observado entre todos os traços agregados que completaram com sucesso; ResponsivenessMax: desempenho máximo observado entre todos os traços agregados que completaram com sucesso; ResponsivenessBx: número de traços que completaram com sucesso, cujo desempenho se enquadra em uma das seis faixas especificadas. Como o desempenho de cada aplicação varia muito, o valor dessas faixas pode ser especificado separadamente para cada traço monitorado. Quatro tipos distintos de agregação são suportados pela MIB APM: Agregação de fluxos: nesse tipo de agregação, um registro é criado para cada combinação distinta de traço, cliente e servidor observada pelo agente; Agregação de clientes: um registro é criado para cada combinação distinta de traço e cliente observada; Agregação de servidores: um registro é criado para cada combinação distinta de traço e servidor observada; Agregação de aplicações: um registro é criado para cada traço observado. A tabela 1 ilustra um exemplo hipotético de relatório com informações de desempenho relacionadas a um conjunto de traços Requisição HTTP retornada com sucesso, agregados por fluxo, monitorados em um determinado intervalo de tempo. Como é possível observar, foram contabilizados 125 traços HTTP entre as estações e Desses 125 traços, 100 completaram com sucesso. O tempo médio de resposta dos traços que obtiveram sucesso foi de 4.50 segundos. O traço mais rápido

8 levou 0.75 segundos para completar e o mais lento, 5.85 segundos. Percebe-se, ainda, que a maior quantidade dos traços que completou com sucesso apresentou tempo de resposta entre 2.00 e 5.00 segundos. Tabela 1: Exemplo de relatório de desempenho gerado pela MIB APM Req. HTTP Req. HTTP Req. HTTP Traço Cliente Servidor TransactionCount SuccessfulTransactions ResponsivenessMean ResponsivenessMin Faixas de ResponsivenessMax desempenho ResponsivenessB t.r. < 1 ResponsivenessB t.r. < 2 ResponsivenessB t.r. < 3 ResponsivenessB t.r. < 4 ResponsivenessB t.r. < 5 ResponsivenessB t.r. < Estrutura da MIB Para oferecer as estatísticas supracitadas a MIB APM resumida é composta por dois grupos: o apmappdirectory e o apmreport. O primeiro é usado para realizar configurações a respeito das aplicações monitoradas incluindo as seis faixas de desempenho (tabela apmappdirectory). O segundo grupo, por sua vez, controla a criação e a recuperação de relatórios sobre o desempenho dessas aplicações. Para tal, possui duas tabelas: apmappreportcontrol e apmappreport. A figura 4 ilustra essas tabelas. A tabela apmappdirectory possui uma entrada para cada traço a ser monitorado 4. Nessa tabela é possível configurar, para cada traço, se o agente APM deve ou não contabilizar estatísticas de desempenho para o mesmo e seis faixas de desempenho. A figura 4 ilustra a entrada relativa ao traço Requisição HTTP retornada com sucesso na tabela apmappdirectory. Um agente configurado dessa forma está habilitado a medir o tempo de resposta do traço mencionado (apmappdirectoryconfig=1) e as faixas de desempenho para o mesmo são 0 1, 1 2, 2 3, 3 4, 4 5 e 5 6 segundos. A tabela apmappreportcontrol permite configurar os parâmetros para a geração dos relatórios de desempenho sobre os traços observados. Cada entrada nessa tabela corresponde a um tipo de relatório a ser gerado e possui as seguintes informações: interface monitorada (apmappreportcontroldatasource), nível de agregação (apmappreportcontrolaggregationtype), intervalo de monitoração (apmappreportcontrolinterval), número de registros admitidos no relatório (apmappreportcontrolgrantedsize), número de relatórios armazenáveis (apmappreportcontrolgrantedreports), entre outras. Na figura 4 o relatório solicitado será gerado a partir da monitoração da interface padrão (0.0), os traços serão agregados por fluxos (1), o intervalo de monitoração será de segundos e o relatório admitirá no máximo 100 registros. O número máximo de relatórios armazenáveis não é apresentado por limitação de espaço. A função da tabela apmappreport, por fim, é armazenar os registros gerados para os relatórios configurados. As informações contidas nessa tabela foram 4 Os traços a serem monitorados são definidos na tabela protocoldir da MIB RMON2 [Gaspary et al., 2001].

9 Ü especificadas na sub-seção anterior. Como é possível observar na figura 4 as entradas disponíveis na tabela apmappreport pertencem a dois relatórios consecutivos, gerados a partir da configuração realizada junto à tabela apmappreportcontrol. Para recuperar o número de traços Requisição HTTP retornada com sucesso completados com sucesso (apmappreporttransactioncount) entre as estações e no primeiro relatório gerado o OID a ser usado é apmreporttransactioncount ÏÐ ± Ñ "¹ Ò ÓÔ ± Ñ "¹Ò"ÕÖ ØÔ ± Ñ "¹ Ò"Õ Ö Õ± Ù ÚÔ ± Ñ "¹ Ò"Õ Ö Õ Û" ± Ñ "¹ Ò"Õ Ö Õ± Ù "Õ ¹ "Ý Ö³ÖÞß ² ѱ ± ¹ ± ² ¹ Û Ù² à#³ Ù "³³² áô ± Ñ "¹ Ò"Õ Ö Õ± Ù "Õ ² â)ã/öû " ± Öä ÖÙ Þß² Û² ³ å ¹ Ö² æô ± Ñ "¹ Ò"Õ Ö Õ± Ù "Õ ² â)ã ± ± ÖÙ "Þß² çö ³ " Ñ èô ± Ñ "¹ Ò"Õ Ö Õ Û" Õ ¹ Ý" Ö³ÖÞß²Û ¹ ³ ² µ Þß ²Û ² à ³ éô ± Ñ "¹ Ò"Õ Ö Õ "³ ± µ "ÙÖà ± ²Û Ù²" êß ²)± Ù ë À ì)íó9á)â à ÄÅ"Æ Ã Ç Ë Í Â Í"Ì Í"Æ ÉÊ Ë ž º)» žž œ9 ž Ž ½ /Ž "½ Ž Ï î"õî ï ï âð îî ïîî ïîî ÕÕÕñÕÕÕ ÕÕÕ ÕÕÕ ÕÕÕ ÕÕÕ ÕÕÕ ) ± ²³) ²"µ ¹ ³ "¼ "½ õ Ž» "½šŽ /ö ž " ½ œ ø" ½õ"šù ú9 "½ "õ šù œ ø" ½ œ9 ž Ž ½ ú/ ½ œ9 ž Ž ½ "õ ½ ½ ö šº œ ž Ž ½û9 º)ü" ½ ¼ š " "¼/ Ž žž " ý º "þ)ÿ/ "õ ½ "½ ¾) ÀòÁ) Ã"Ä Å"Æà Ã"Ç È¾Ç"Ç ë Å ÇÍ/Ë Â ó/í/ôâ Ë Í Æ ž º)» žž ¼/š " ½Ž» žž Ž" ˆ Š Œ ) ± ² ³9 9²"µ ¹ ³ Ž " /Ž" š œ9 žÿž š " Ž œ ž Ž š Ž" " "œ " ž Ž " š " /Ž " œ ž Ž š Ž" " ª "œ " ž Ž " š " /Ž "«œ ž Ž š Ž" " ¾) À Á  à ÄÅ"Æ ÃÃ"Ç È¾Ç"Ç"É/Ê Ë Å ÌÂ Í Ë Î ž ºœ ž Ž ½ /Ž ½ Ž ž º œ ž Ž ½ " ž Ž½Ž" Ž ¼/š Ž " ž º)» ž ž ¼š " ½Ž» žž "Ž " ž ºœ ž Ž ½õ»/ ž ºû9 º š ½ ¼ Ï Ï Õ Õ Õ ï Ò"Õ ïð"õ ïî "ÕÒ ïò ïîî Õ î"õ Õ Õ Õ Ï Ï Õ Õ Õ ï Ò"Õ ïð"õ ïî "ÕÒ î î â ÕÒ Ò"ÕÒ Õ Õ Õ Ï Ó Õ Õ Õ Ò î î ÕÒ "Õ Ò Ò"Õ ï â ïâ Ò îî ÕÒ â"õò Õ Õ Õ Ï Ó Õ Õ Õ ï Ò"Õ ïð"õ ïî "ÕÒ âî î Ò î Õî î â"õ ïò Õ Õ Õ ) ± ² ³) ²"µ ¹ ³ "õ» ö " " ½šŽ Ž "½ õ " ö " " ½šŽ œ " ž Ž š œ ž Ž š " š "œ ž Ž š œ ž Ž š " ) œ " ž Ž š / œ ž Ž š " œ " ž Ž š ª œ ž Ž š " «œ " ž Ž š / ¾) ÀòÁ) à ÄÅ"Æ Ãà ÇÈ ¾)Ç Ç ë Å"Ç Í Ë Â Figura 4: Tabelas da MIB APM resumida 5 Arquitetura do Agente O agente SNMP para medição de desempenho requer como entrada traços de protocolos especificados usando a linguagem PTSL. A configuração dos traços que devem ser monitorados em um dado momento é realizada pelo gerente de rede, que se comunica com o agente através da MIB Script. Uma vez programado ele passa a monitorar a ocorrência dos traços. Para configurar as medições de desempenho a serem realizadas o gerente interage com o agente, também via SNMP, através do sub-conjunto da MIB Application Performance Measurement apresentado na seção 4. Os relatórios resultantes podem ser recuperados a partir de qualquer aplicação que suporte SNMP através de consultas periódicas ao agente APM. A figura 5 ilustra o fluxo de informações entre gerente e agente. O agente de monitoração foi implementado na plataforma Linux usando a linguagem C e a biblioteca de threads POSIX [Pthreads, 1995]. Uma visão mais detalhada da arquitetura do agente é apresentada na figura 6. A thread gerente PTSL é responsável pela integração entre a MIB Script e a máquina de execução PTSL. Ela atualiza as estruturas usadas pela máquina PTSL sempre que um novo traço é programado para ser monitorado ou um traço existente é removido (por não ser mais necessário). Outras três threads fila, máquina PTSL e APM operam segundo o paradigma produtor/consumidor. A primeira é responsável por capturar todos os pacotes usando a biblioteca libpcap e adicioná-los a uma fila circular. Embora essa biblioteca suporte a especificação de filtros

10 & # $ # # )! " # $ # % & $ # '$ # % $ # % * & # # # ) +,'-. / , 6, , 7 6+,'-. / ,, 7:2 9 ; 38 <'2 /, 7 & $ # '$ # % $ # % $ # ( # > # # )? # ) , 6, 7:2 9 ; 38 <'2 /, 7 / = 4 5, 6, 7:2 9 ; 38 <'2 /, , 6, , 7 Figura 5: Fluxo de informações entre gerente e agente APM utilizando a notação BPF (BSD Packet Filter) [Mccanne e Jacobson, 1993], esse recurso não está sendo utilizado pelo agente. A segunda thread processa cada pacote presente na fila, sem retirá-lo dela, com o objetivo de identificar se o mesmo possui as características esperadas para permitir que um ou mais traços evoluam na máquina de estados. Caso afirmativo, o pacote recebe marcações especiais. A thread APM, por fim, retira cada pacote da fila e, de acordo com as marcações e com os relatórios configurados, faz atualizações em uma estrutura de dados em memória. Tão logo encerre o intervalo de monitoração de um relatório, as informações disponíveis em memória são processadas e os resultados são armazenados em um banco de dados (mysql). Essa base de dados é consultada por uma extensão ao agente NET-SNMP [NET-SNMP, 2002] que implementa a MIB APM resumida. UV W XY WZ W[\'X ] Y \^ _ ` a \ [n o'p ] X _Z WWq'W r p ` a \st ujv k P T Bj D Q B N l F D m B C D EF D GHJIK IL M G'N O PQ F S D O E D T w B m c P E x D O D EF D K'g Gh cd e f P E B K g Gh F i O D B j k P T B IL M RJK'I S D O E D T RJK'I b B E Nl j D j B j l m F i O D B j RKI T P b Q N B Q Figura 6: Arquitetura interna do agente Com relação à segurança, o agente suporta todas as facilidades oferecidas pelo protocolo SNMPv3, incluindo os modelos USM (User-based Security Model) [Blumenthal e Wijnen, 1999] e VACM (View-based Access Control Model) [Wijnen et al., 1999]. Ao utilizar essas facilidades impede-se que o agente seja reconfigurado por um indivíduo não autorizado.

11 6 Exemplos de Uso para o Agente A monitoração do tempo de resposta de interações de protocolos, serviços e aplicações em rede é uma tarefa bastante relevante quando esses softwares são usados como suporte a operações críticas, que requerem altas disponibilidade e desempenho. Diversos cenários podem ser usados para ilustrar a necessidade de garantir esses requisitos. A seguir são ilustrados dois: provedores de hospedagem de aplicações e redes corporativas. 6.1 Provedores de hospedagem de aplicações Hospedeiros de sites, portais e aplicações de comércio eletrônico (ou Application Service Providers) precisam garantir acesso 24 horas nos 7 dias da semana aos usuários/clientes. Dada a grande competitividade estabelecida entre empresas que oferecem serviços de hospedagem semelhantes, além da alta disponibilidade é preciso proporcionar baixo tempo de resposta. As empresas que contratam os serviços de hospedagem, para se certificarem que seus usuários/clientes estão tendo acesso eficiente aos sites, portais, etc. (dentro dos parâmetros de qualidade contratados), dependem de aplicações que monitorem os acessos realizados. O agente aqui apresentado pode ser usado, nesse cenário, no provedor e/ou na rede interna de alguns usuários/clientes. Independente de onde esteja localizado o agente, o contratante do serviço de hospedagem pode, remotamente, configurá-lo com os traços e os relatórios desejados e recuperar os resultados do mesmo usando alguma aplicação de gerenciamento com suporte a SNMP (vide figura 7). { ~ ƒ~ ' ˆ ~ ˆ ~' ˆ z:} ~: Š z } ~ { z Œ ' JžŸ y z { z } ~ «Ž š œ ' š J š ' ' š ' ª š Figura 7: Monitoração de um ambiente de hospedagem 6.2 Redes corporativas O ambiente de redes corporativas é outro cenário indicado para a monitoração do tempo de resposta de interações de protocolos, serviços e aplicações em rede. Nesse ambiente, além de sites e portais (ex: Intranet), merecem ser medidos os tempos de resposta de serviços essenciais como DNS e POP, bem como de aplicações da própria organização. A figura 8 ilustra um cenário real de gerenciamento. O roteador, por intermédio de uma interface serial, é o elo de ligação com a Internet. Além da interface serial, o roteador possui duas interfaces Ethernet. À primeira interface está conectado um hub, que tem ligado a ele duas estações: uma hospeda o servidor de DNS e outra, o servidor POP. À segunda interface do roteador está ligada uma estação com duas interfaces de rede. Esta executa um firewall e, portanto, representa a divisa entre a rede externa e a interna. Ligado à outra inteface do firewall (interface interna) está um hub. Nele estão conectados o servidor Web responsável pela Intranet da organização e um switch que segmenta a rede interna em várias sub-redes. Os demais equipamentos (em branco na figura) são a estação de gerenciamento e duas estações dedicadas à tarefa de monitoração. Com o intuito de monitorar o tempo de resposta dos acessos ao servidor responsável pela Intranet, o agente AM 1 precisa ser configurado com traços como

12 å ; ý ; ; Ç 2 < '¹ Ú ± ² ± ³ µ' Ø Ì½ ¾ Á ̾ ½»¼ ½ ¾ À ¼ Á ÂJÃ Ä Ð Ç Á ¾ Æ Ñ Ñ '¹'Ù Ò ¾ Á Ó Ç À ¼ Á Ò ¾ Á Ó Ç À ¼ Á Ô ÕÔ Ö Å Ø Ì ½ Á Ì ¾ ½ Û'ÜÝ µ Þ ß à ± ² ±'á ± ³ â ã µ ä±'³ý à ¹ º Å ÆÇ ½ È É ÊË ¾ ̽ ¾À ¾ Í ¼ Ì ½ ¼ Á Î Ï ¼ Figura 8: Monitoração de um ambiente corporativo Requisição HTTP retornada com sucesso, ilustrado na figura 2. De forma similar, o agente AM 2 deve ser programado com traços como POP3 - Identificação do usuário, POP3 - Autenticação via senha e Requisição de resolução de nomes para monitorar o tempo de resposta dos acessos que são realizados aos servidores POP e DNS. Tão logo configurados os traços, é preciso interagir com os agentes, através da MIB APM, para solicitar a geração de relatórios de desempenho (criação de uma ou mais entradas na tabela apmappreportcontrol, apresentada na sub-seção 4.2). Os resultados podem ser obtidos, algum tempo depois, com consultas à tabela apmappreport. A figura 9 apresenta alguns gráficos que podem ser formatados com esses resultados. æ'ç è ç é:ê ç ë ì í:î í èaï ð ç è è í è:ñ ç éòè ó ð ç î ô î í è õ ô õ ø ô õ ç ï ö ï î í è:ï íaè ç î í õù ë ú ï ë ç ú û ü ý þ'ÿ ü ÿ ü 'ÿ þ þ ü ü þ ü ü ý þ ü ü þ þ þ ' () þ ü ç éê íaî ç õ ç è ê í è ú ï é î ô íaî í è:ï ð ç è è í è"! #%$ ñ ç é è ó ð ç î ô î í è:í ñ è ç õ ø ï î í èaë ï õ ç î çaû ü þ & ü ì 4,5 üý þ'ÿ ü 'ÿ ü 'ÿ ü üý þ'ÿ ü 'ÿ ü 'ÿ þ 3,25 üý þ'ÿ ü 'ÿ ü ÿ þ üý þ'ÿ ü ÿ ü 'ÿ þ 5,25 üý þ'ÿ ü 'ÿ ü 'ÿ ü þ ÿ þ 'ÿ þ þ'ÿ ü ax _ `]_ \Y]^ [ X ZYX UVW Tempo de resposta.%/ " : 2 3 2" : 2 3 = > 92 x ;< 0 2 3"3 8 /?A@: 2 / 8 3CBDEBC8CF#G%HJI K L M N OPQ R K K O T K O R S O K K N T K S O N K K T K R L N N K POP3 - Identificação do usuário bem sucedidos * +, * -, l m n Requisição de resolução de nome não completados [ Z _ i Xjk^ d f T g R O N K F Nd Oe N f#e N K Le N 2,45 Cliente/Servidor P2b6 8/ 4 8 2b6 8 70" b b0 2b3 8 /?%@: 2/#F#G%H 3,35 3,47 K L M K S P K S MhN K P N K M N NP N N M NO P l o n 4,5 Figura 9: Exemplos de gráficos gerados a partir de relatórios da MIB APM

13 O primeiro (a), gerado a partir de um relatório cujos registros foram agregados por servidor (obtido do agente AM 1 ), ilustra a distribuição dos tempos de resposta dos traços Requisição HTTP retornada com sucesso observados onde o servidor foi a estação O segundo gráfico (b) apresenta os tempos médio, máximo e mínimo de resposta do mesmo traço, observado entre cada dupla de end-points no intervalo entre 12 e 13h. Este gráfico foi gerado a partir de um relatório agregado por fluxos também recuperado do agente AM 1. A relação entre traços completados com sucesso e não completados é o que o terceiro gráfico (c) demonstra. Elaborado a partir de um relatório agregado por servidores, gerado pelo agente AM 2, o gráfico ilustra essa relação para os traços POP3 - Identificação do usuário e Requisição de resolução de nomes observados, respectivamente, nas interações com os servidores POP e DNS. O quarto e último gráfico (d) destaca o tempo médio de resposta percebido pela estação em seus acessos ao servidor DNS (agregação por clientes) ao longo de quatro intervalos de tempo. Para ser criado, foram recuperados quatro relatórios do agente AM 2, um a cada hora. 7 Conclusões e Trabalhos Futuros Este trabalho apresentou um agente para monitoração do tempo de resposta de interações de protocolos que, ao contrário das soluções disponíveis, reúne ao mesmo tempo duas características essenciais: utilização da técnica de monitoração passiva do tráfego de rede e armazenamento das estatísticas resultantes em uma base de informações de gerenciamento compatível com a arquitetura SNMP. A seção 2 apresentou trabalhos relacionados. As seções 3 e 4 apresentaram, respectivamente, a linguagem PTSL, usada para especificar as interações de protocolos a serem monitoradas, e a MIB APM resumida, interface do gerente com as estatísticas de desempenho geradas pelo agente. A arquitetura interna e exemplos de uso do mesmo foram abordados nas seções 5 e 6. Com relação à MIB APM originalmente proposta em [Waldbusser, 2002], é importante destacar que ela se encontra em fase de padronização há pelo menos quatro anos, com vários pontos divergentes. A MIB original é extensa, de difícil implementação, muito em função do suporte a vários tipos de aplicações (orientadas à transação, vazão e fluxo). Além disso, é limitada quanto às transações que podem ser monitoradas. Através de um documento, também em fase de padronização [Bierman et al., 2002], são definidas transações de protocolos bem conhecidos e disseminados que os agentes APM devem suportar. As aplicações mais importantes para as organizações, no entanto, são proprietárias e normalmente desenvolvidas dentro das próprias empresas. Essas aplicações nunca serão registradas como aplicações padrões e fabricantes de agentes APM dificilmente poderão incluir suporte a essas aplicações em seus produtos. As limitações mencionadas levaram a adaptações da MIB (pelo nosso grupo de pesquisa), que foi simplificada para suportar uma classe específica de aplicações, as orientadas à transação, e teve o seu mecanismo de identificação das transações a serem monitoradas substituído por um bem mais flexível, configurável pelo gerente de rede através da linguagem PTSL. O poder de expressão de PTSL é um ponto a ser destacado. Através dessa linguagem é possível especificar interações de protocolos de nível de rede, transporte e aplicação. Além disso, ao contrário das soluções existentes, a linguagem permite modelar interações tanto de protocolos convencionais quanto de aplicações internas às organizações. Para especificar transações ligadas a protocolos criptografados (ex: Secure Electronic Transaction), os traços são descritos de forma similar. O agente, no entanto, precisará ser remodelado de modo a interceptar e decifrar as mensagens observadas. Se por um lado a abordagem baseada na monitoração passiva do tráfego de rede é a menos invasiva, por outro, ela é onerosa computacionalmente. Através de

14 medições realizadas, detectou-se que a baixa capacidade de processamento dos pacotes pelo agente se deve à larga utilização de um banco de dados (mysql) para consolidar as estatísticas relacionadas ao desempenho. A partir dessa constatação, passou-se a reprojetar a implementação original do agente tendo em vista a substituição do banco de dados por estruturas de dados em memória. Entre as estruturas consideradas, as tabelas hash mostraram-se mais adequadas, por propiciarem rápida inclusão e atualização de elementos. No presente momento encontra-se em andamento a implementação gradual das modificações projetadas. Referências Aprisma (2002). Aprisma Technologies Homepage. Bierman, A., Bucci, C., Dietz, R., e Warth, A. (2002). Remote Network Monitoring MIB Protocol Identifier Reference Extensions. RFC Blumenthal, U. e Wijnen, B. (1999). User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3). RFC Boardman, B. (1999). Finding the best approach to app monitoring. In Network Computing. Candle (2002). Candle Corporation Homepage. Concord (2002). Concord Communications Inc. Homepage. Debusmann, M., Schmid, M., e Kroeger, R. (2002). Generic performance instrumentation of ejb applications for service-level management. In Proc. of the VIII IEEE/IFIP Network Operations and Management Symposium, pages Gaspary, L., Balbinot, L. F., Storch, R., Wendt, F., e Tarouco, L. (2001). Uma arquitetura para gerenciamento distribuído e flexível de protocolos de alto nível e serviços de rede. In IXX Simpósio Brasileiro de Redes de Computadores. Gaspary, L., Meneghetti, E., Wendt, F., Braga, L., Storch, R., e Tarouco, L. (2002). Trace: An open platform for high-layer protocolos, services and networked applications management. In Proc. of the VIII IEEE/IFIP Network Operations and Management Symposium, pages Levi, D. e Schönwälder, J. (2001). Definitions of Managed Objects for the Delegation of Management Scripts. RFC Lucent (2002). Lucent Technologies Homepage. Mccanne, S. e Jacobson, V. (1993). The bsd packet filter: A new architecture for user-level packet capture. In Proc. of the USENIX CONFERENCE, pages NET-SNMP (2002). NET-SNMP Project Homepage. NetIQ (2002). NetIQ Corporation Homepage. NetScout (2002). NetScout Systems, Inc. Homepage. Pthreads (1995). Pthreads: POSIX threads standard. IEEE Std c Sturm, R. (1999). Foundations of Application Management. John Wiley & Sons. Tivoli (2002). Tivoli Systems, Inc. Homepage. Villagrá, V., Asensio, J., de Vergara, J. L., Berrocal, J., e Pignaton, R. (2002). An approach to the transparent management instrumentation of distributed applications. In Proc. of the VIII IEEE/IFIP Network Operations and Management Symposium, pages Waldbusser, S. (2002). Application Performance Measurement MIB. Internet Draft. Wijnen, B., Presuhn, R.,, e McCloghrie, K. (1999). View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP). RFC 2575.