Uma das técnicas mais usada para observação de aplicações é sem dúvida a recolha de um traço da sua execução. Muitas técnicas têm sido usadas: desde a simples introdução de “printf”s ou funções equivalentes no código fonte, até sistemas autónomos que a nível do sistema de operação ou por alteração da aplicação, recolhem e armazenam durante a execução, todo o tipo de eventos que permitam descrever as mais variadas transições de estado de todo o sistema.
Estas técnicas são usadas para, por exemplo (visto no capítulo 2):
• visualizar e ajudar à compreensão do comportamento da aplicação;
• ajudar na identificação e localização de erros, assim como de quais as suas possíveis causas;
• efectuar medições e contagens de valores que permitam obter o perfil da execução da aplicação com vista a melhorar o seu desempenho; ou identificar problemas de concepção ou implementação no seu desempenho ou no uso dos recursos;
• permitir suportar serviços de adaptação dinâmica da aplicação à plataforma computa- cional (balanço de carga, tolerância a falhas, etc.);
Normalmente os sistemas de observação necessitam de um mecanismo para coligir e registar uma sequência de eventos que permitam descrever a execução da aplicação — o seu traço de execução. Este mecanismo permite coligir e canalizar para as ferramentas, uma sequência de registos que descrevem esse traço, possivelmente com armazenamento temporário dos mesmos.
4.7. Exemplos de serviços 93
Seguindo as ideias antes apresentadas, concebeu-se um serviço para o encaminhamento de traços de execução (ou qualquer outra sequência de registos). A ideia base para este ser- viço é a de dispor de um simples canal que recebe registos e, posteriormente, os difunde para os seus consumidores. Este serviço pode servir de base para a implementação de funções de monitorização mais complexas.
Este serviço necessita de ser neutro em relação ao conteúdo dos registos que transporta, para poder ser usado nas mais variadas situações. Terá de ser o consumidor final da informa- ção a interpretá-la. O serviço assegura apenas o fluir dos registos da sua origem para os seus consumidores. Assim se garante a transparência deste serviço e se torna possível o seu uso para qualquer tipo de registos e traços de execução.
Get Put
notificação Interface de controlo
repositório
Figura 4.12: Um canal para traços
Este trata-se de um serviço local a cada máquina, possuindo um repositório, parame- trizável quanto ao seu tamanho, para reter temporariamente os registos, até os passar aos consumidores.
Estes serviços podem ser encadeados formando uma árvore que encaminha os registos recolhidos por todo o sistema, até à ferramenta que os pretende obter. Estas conexões per- mitem desenhar topologias que melhor se adaptam à arquitectura do sistema monitorizado e às necessidades das ferramentas. Os sensores responsáveis pela recolha de informação (a instrumentação p.e.) em cada máquina, devem ser capazes de entregar essa informação no serviço de traço nessa máquina. Por sua vez este fará, de acordo com parâmetros de funcio- namento, fluir esta informação para o respectivo canal consumidor, e assim sucessivamente até chegar à raiz onde a ferramenta recebe essa informação.
Um monitor do tipo já descrito no capítulo 3, pode ser construído usando várias instâncias destes serviços segundo a arquitectura idêntica à apresentada na figura 4.13.
host A ferramenta de monitorização host C host B entidades monitorizadas
Figura 4.13: Monitorização usando uma rede de serviços de traço
Caso a ferramenta só pretenda o traço da execução completa da aplicação, para análise post-mortem, só vale a pena enviar para a ferramenta a informação recolhida em cada má- quina após o término da aplicação. Isto corresponde a ter um “buffer infinito” nos serviços de traço em cada máquina. Só após a execução da aplicação terminar é que um monitor central requer o envio do traço coligido em cada representante do serviço local. A detecção do fim da aplicação pode ser determinada pela ferramenta, por exemplo, por eventos que lhe são entregues, indicando o término de cada processo da aplicação.
Com maior pormenor, cada serviço local de traço compreende os seguintes elementos:
• uma interface para controlar/parametrizar o seu próprio funcionamento (configuração);
• uma operação para inserir registos de eventos no repositório do serviço e outra opera- ção para pedir os existentes (Put/Get);
• uma lista de subscritores consumidores, na qual fica registada a função de cada subs- critor destinada à entrega dos registos;
• uma lista de subscritores produtores, onde uma função fica registada para obter os registos, que o produtor disponha;
• um canal de eventos associado, para propagar notificações urgentes a todos os clientes do serviço.
4.7. Exemplos de serviços 95
quando pretendido; ou num modo em que o serviço toma a iniciativa de enviar para todos os subscritores consumidores a informação que recebe.
Serve assim, este serviço, de intermediário — transportador da informação — entre os produtores e os consumidores de registos. Estes modos procuram cobrir as mais variadas uti- lizações. Dependendo da utilização, os sensores e as ferramentas (ou outros serviços) tomam papéis activos ou passivos, no que diz respeito ao desencadear do transporte da informação pelo serviço de traço. Todos os padrões possíveis encontram-se na seguinte tabela, que são depois descritos:
sens. activo sens. passivo
ferramenta activa 1 2
ferramenta passiva 3 4
Estes padrões correspondem às seguintes situações:
1. os sensores injectam no serviço de traço local os registos que descrevem os eventos recolhidos. Os serviços de traço podem armazenar essa informação até que esta seja pedida explicitamente pelas ferramentas. Quando uma ferramenta pede a informação recolhida até esse instante, esta é-lhe então entregue. O meio de comunicação é aqui passivo para não perturbar a aplicação. A situação extrema é o caso da recolha a posteriori quando a ferramenta só vai pedir a informação após detectar o término da aplicação. 2. neste caso o sensor apenas se regista como produtor de informação. A fer- ramenta, tal como no caso anterior, desencadeia o pedido do processo de transferência. Este caso pode corresponder às situações em que os sensores coligem informação sob a forma de contadores ou indicadores que reflec- tem o estado da aplicação ou da máquina, os quais são consultados pela ferramenta durante a execução da aplicação (on-line) quando necessário. 3. nesta situação a ferramenta regista-se apenas como consumidora da infor-
mação. À medida que a informação é coligida pelos sensores e injectada no serviço de traço, esta vai fluindo até às ferramentas sem qualquer acção destas. Este caso contempla as situações de monitorização efectuada en- quanto a aplicação se executa (on-line), casos em que as ferramentas vão consumindo a informação recolhida num fluxo contínuo.
4. este último caso revela-se inútil se não existir outra qualquer entidade (ser- viço ou ferramenta) que desencadeie o processo de transferência da infor- mação, já que tanto os produtores como os consumidores estão inactivos. Nesta situação podemos considerar, por exemplo, os casos em que a re- colha de informação e o respectivo tratamento são despoletados periódi- camente, com base em intervalos de tempo (a entidade que desencadeia o processo é aquela que controla esses intervalos de tempo).
Na situações em que se pretende uma utilização do traço apenas após o termino da apli- cação, será necessário que a ferramenta, quando tal decida, desencadeie explicitamente o processo de transferência completa desse traço para a ferramenta. Para tal, será conveni- ente uma primitiva para requerer explicitamente o envio de todo o traço coligido (tipo flush). Esta desencadeia um modo de funcionamento como na situação 3, onde cada serviço passa a informação disponível aos respectivos subscritores.
Vejamos a seguir as operações abstractas a suportar pelo serviço de traço:
SetWorkingParam(long buffsize) — apenas vamos considerar um parâmetro para configu- rar o seu funcionamento. Este define o tamanho do repositório interno, que pode variar de zero (difusão imediata dos registos entrados) até infinito (os registos são guardados, podendo recorrer a um ficheiro local), até que sejam pedidos pelos consumidores;
SetProd( produce ) — o produtor regista junto do serviço a sua função de produção. Quando requerido pelos consumidores o serviço invoca a função registada para que esta lhe en- tregue os registos e depois passa essa informação aos consumidores;
SetCons( consume ) — o consumidor subscreve o serviço indicando uma função responsá- vel por receber a informação. Quando necessário, e dependendo da configuração, o serviço invoca essas funções entregando-lhes os registos existentes;
Put( register ) — quando existe um novo registo este é explicitamente introduzido no ser- viço usando esta operação;
Get( register ) — quando interessado, o consumidor pede explicitamente ao serviço todos os registos existentes invocando uma operação para esse efeito;
Flush() — esta operação permite que o consumidor, quando interessado, peça explicita- mente ao serviço todos os registos existentes.
4.7. Exemplos de serviços 97
EvCh GetEvCh() — obter o identificador do canal de eventos associado ao serviço. Atra- vés deste, podem os sensores/actuadores, enviar, eventualmente, notificações aos cli- entes do serviço; os clientes podem subscrever este canal para receberem essas notifi- cações.
A utilização deste serviço pode revelar-se complexa, especialmente no caso deste dever ser acedido concorrentemente por mais de uma ferramenta, em particular se emitirem coman- dos de configuração incompatíveis. Deve-se então optar por construir sobre este, um outro serviço vocacionado para a gestão da monitorização, de modo que funcione como coordena- dor global para as várias ferramentas. Fica este responsável pelo lançamento e configuração de uma infraestrutura construída com os serviços de traço, de acordo com a configuração pre- tendida (e arquitectura sob monitorização), servindo também de intermediário e coordenador de todas as ferramentas que acedam a estes serviços de traço.