Guia de Implementação › Implementação › Coleta de dados (Especialista em fonte de dados) › Tópicos avançados para o recurso do conector › Agregar dados da transação

Tópico anterior: Comportamento do listener de conectores com singularidade do evento

Próximo tópico: Executar um conector com proteção de um firewall
Agregar dados da transação

Os dados da transação geralmente são coletados para comparar aos limites ou para calcular as porcentagens periódicas eventuais de êxito. Por exemplo, a cada 5 minutos, uma transação virtual é executada em um sistema e o resultado (tempo de resposta em milissegundos) é armazenado, conforme mostrado a seguir:

[…]
1/1/2004 00:00 432
1/1/2004 00:05 560
1/1/2004 00:10 329
1/1/2004 00:15 250
1/1/2004 00:20 275
1/1/2004 00:25 2860
1/1/2004 00:30 140
[…]

Em outras situações, em vez de usar transações virtuais, pode haver acesso a transações reais em execução no sistema. Nesses casos, centenas ou até milhares de transações podem ser realizadas por hora.

Em ambos os casos acima, o carregamento desse volume de informações no CA Business Service Insight deve ser evitado, se possível.

Agregar os dados por períodos é a melhor maneira de reduzir as quantidades de dados. Quando o limite que funciona como base para medir o êxito é fixo, a agregação pode ser executada permitindo que o conector conte o número de transações que tiveram êxito dentro do período agregado. Por exemplo, se o limite de êxito no exemplo anterior estiver definido como 500 milissegundos, apenas cinco de sete transações tiveram êxito durante o período exibido. O problema dessa abordagem é o limite fixo: e se, posteriormente, alguém desejar alterar o limite? Nesse caso, os dados brutos devem ser lidos e testados novamente pelo conector com base no novo limite.

Portanto, o ideal seria que o conector agregasse os dados da transação de uma maneira flexível sem perder os dados significativos.

Uma solução limitada é permitir que o conector teste as transações com base em vários limites. Há duas maneiras de fazer isso:

As duas opções têm o mesmo problema - os limites podem ser alterados no futuro apenas dentro de um pequeno conjunto de valores predefinidos.

Solução recomendada

Premissa - todos os possíveis limites são múltiplos de um determinado número. Por exemplo, todos os limites (em milissegundos) são múltiplos de 250, desse modo, 0, 250, 500, 1750 e 3000 milissegundos são possíveis limites.

Com base nessa premissa, a solução sugerida é agregar as transações, arredondando todos os valores para um múltiplo comum e contando o número de transações que se enquadram em cada valor arredondado. Event Type = {RangeFrom, RangeTo, TransactionCount}

Por exemplo, os seguintes eventos serão gerados para agregar os dados exibidos acima, onde o múltiplo comum é 250 milissegundos:

{1,     250,    2}
{251,   500,    3}
{501,   750,    1}
{751,  1000,   1}

Comentários:

A data e a hora desses eventos seriam as mesmas. (Por exemplo, todos os eventos agregados podem ocorrer em 1/1/2007 00:00, e pode haver outro conjunto de eventos para o próximo exemplo de hora, 1/1/2007 01:00, presumindo que houve a agregação de hora em hora.)

RangeTo é calculado arredondando uma transação para o múltiplo comum (consulte a seguir).

RangeFrom é RangeTo menos o múltiplo, mais 1. É especificado apenas para fins de clareza, e você pode ignorá-lo.

Por exemplo - agregar por hora pode ser semelhante ao seguinte (substituir MULTIPLE pelo valor do múltiplo):

select  trunc (time_stamp, 'hh') "TimeStamp",
        round (response_time/MULTIPLE, 0)*MULTIPLE-MULTIPLE+1 "RangeFrom",
        round (response_time/MULTIPLE, 0)*MULTIPLE "RangeTo",
        count (*) "TransactionCount"
from    t_log
group by trunc (time_stamp, 'hh'),
        round (response_time/MULTIPLE, 0)*MULTIPLE

Na lógica de negócios, a seguinte condição pode ser aplicada aos eventos:

If eventDetails("RangeTo")<=Threshold Then
	SuccessfulTransactions=SuccessfulTransactions+eventDetails("TransactionCount")
End If

Algumas ideias conclusivas: