Cada métrica tem uma definição de um período de monitoramento. O período de monitoramento é o período durante o qual a métrica precisa gerar um resultado de nível de serviço, e é esse resultado que deve ser comparado com o destino definido. O resultado gerado para o período de monitoramento são os resultados comerciais; em outras palavras, é o resultado contratual com o qual o provedor se comprometeu em fornecer um determinado nível de serviço de destino. Cada instância da lógica de negócios para cada período é conhecida como um agente e está diretamente relacionada às granularidades associadas a cada métrica.
Por exemplo, se a métrica for definida com um período de monitoramento de um mês, será executada para fornecer um resultado mensal.
Para fornecer o recurso de detalhamento, no qual o usuário pode fazer uma busca detalhada nos resultados mensais para ver o resultado diário, a métrica deve ter uma definição de outras unidades de tempo nas quais deve ser calculada. As unidades de tempo são definidas na seção Detalhes gerais da métrica na guia Granularidade.
Para cada uma das unidades de tempo definidas na guia Granularidade da métrica e para o período de monitoramento, uma instância da lógica de negócios separada é executada pelo mecanismo. Cada uma dessas instâncias executa o mesmo código da lógica de negócios, mas OnPeriodStart e OnPeriodEnd serão acionados de maneira diferente para cada uma dessas instâncias. Para a instância diária, será acionado no início e no final do dia. Para cada unidade de tempo, será iniciado de acordo com os pontos de início e de término da unidade de tempo.
Cada uma das instâncias da lógica de negócios é executada para produzir o resultado relevante da unidade de tempo. Além disso, cada período deve ter um resultado que leva em consideração quaisquer exceções. Qualquer período que não fizer isso, (se as exceções estiverem definidas) deve permitir que o usuário escolha se deseja ver o resultado de nível de serviço com ou sem as exceções que foram consideradas. Devido a esse requisito, cada métrica potencialmente terá catorze agentes (instâncias) executadas pelo mecanismo: dois agentes para os resultados comerciais e doze para os seis períodos operacionais adicionais.

Isso significa que a definição de granularidade tem um sério impacto no desempenho do mecanismo de cálculo, pois cada período é calculado para um agente diferente. Portanto, nos casos em que o recurso de detalhamento não for necessário como um todo ou parcialmente, é recomendável que alguns dos agentes sejam desativados. Isso tem um impacto particularmente grande no caso das granularidades inferiores, como os resultados de hora em hora. Também tem um enorme impacto na métrica agrupada, pois o mecanismo faz todos os cálculos acima para cada ClusterItem que encontra. Na verdade, trata cada ClusterItem como uma nova métrica. Por exemplo, ao calcular uma métrica em um grupo de recursos de 50 itens, haverá 49 vezes mais trabalho para o mecanismo, em comparação com a mesma métrica não agrupada.
Por exemplo, se a métrica for definida para calcular o tempo de resolução em número de dias, um resultado de hora em hora não faz sentido e deve ser desmarcado na guia de granularidades para evitar que o mecanismo realize cálculos desnecessários.
O atributo TimeUnit do objeto de contexto (isto é, context.TimeUnit na lógica de negócios) retorna a unidade de tempo do agente em execução no momento, onde os possíveis valores retornados são: HORA, DIA, SEMANA, MÊS, TRIMESTRE, ANO.
Por exemplo, para o agente diário, Context.TimeUnit retornará "DIA".
O atributo IsTrackingPeriod do objeto de contexto retornará Verdadeiro para o agente que calcula a unidade de tempo do período de monitoramento. É também importante observar que os agentes mostrados na guia Granularidade das métricas são adicionais para o agente do período de monitoramento da métrica. Portanto, até mesmo para uma métrica com um período de monitoramento mensal, você pode desativar o agente mensal e ela ainda calculará o nível de serviço mensal, mas apenas como "Resultados comerciais" (resultados não operacionais).

Conforme mencionado anteriormente, os vários agentes geralmente executam o mesmo código da lógica de negócios, mas existem casos em que é necessário aplicar uma lógica um pouco diferente.
Por exemplo, no caso mensal, o resultado será o número de downtime por cada mês separadamente, conforme mostrado a seguir:

Para o detalhamento diário, pode ser necessário que seja possível ver os downtimes cumulativos, onde cada dia é uma soma de todos os dias a partir do início do mês. Esse método deve ser aplicado a todas as unidades de tempo menores do que um único mês, conforme mostrado a seguir:

A diferença entre as duas unidades de tempo é que, para o agente que calcula o período de monitoramento, o contador de downtime será inicializado como 0 no início de cada período, mas para o agente diário, o contador será inicializado apenas caso o dia seja o primeiro dia do mês.
A seguir, está o manipulador de eventos OnPeriodStart:
Sub OnPeriodStart(time)
If InStr(“MONTH,QUARTER,YEAR”, Context.TimeUnit) > 0 _
Or (Context.TimeUnit = “DAY” And Day(time) = 1) _
Or (Context.TimeUnit = “HOUR” And Day(time) = 1 And Hour(time) = 0) Then
DownTimeCounter = 0
End If
End Sub
O recálculo é executado quando o mecanismo de correlação identifica que o resultado periódico final de uma métrica não é mais válido e que deve, portanto, recalcular os resultados.
O recálculo pode ser causado por:
O método mais eficiente para registro é por parte contratual e serviço. Organizar os recursos em Parte contratual e Serviços é uma maneira de expressar o relacionamento lógico entre a camada de dados e a camada de negócios no sistema. Registrar os recursos por essas entidades não exigirá alterações nas fórmulas quando usadas em diferentes contratos ou para diferentes serviços. O contexto atual da métrica identificou o contrato e o serviço, que define a Parte contratual relevante e o Serviço associado. As fórmulas de lógicas de negócios definidas nesse tipo de registro são facilmente reutilizáveis, pois não precisam de alterações no registro.
| Copyright © 2012 CA. Todos os direitos reservados. | Enviar email à CA Technologies sobre este tópico |