Ciascuna metrica presenta una definizione di un periodo di riferimento. Il periodo di riferimento è il periodo durante il quale la metrica deve dare l'output di un risultato del livello di servizio e tale risultato deve essere confrontato con la destinazione definita. Il risultato prodotto per il periodo di riferimento è il risultato di business, in altre parole, è il risultato contrattuale per cui il provider si è impegnato a fornire un determinato livello di servizio di destinazione. Ciascuna istanza di business logic per ogni periodo di tempo è nota come agente ed è direttamente correlata alle granularità associate a ciascuna metrica.
Ad esempio, se la metrica è definita con un periodo di riferimento di un mese, la metrica è eseguita per fornire un risultato mensile.
Per fornire la caratteristica funzionale di drill-down in cui l'utente può eseguire il drill-down in un risultato mensile per vedere il risultato giornaliero, la metrica deve avere una definizione di altre unità di tempo in cui deve essere calcolata. Le unità di tempo definite nella sezione Dettagli generali della metrica nella scheda Granularità.
Per ogni unità di tempo definita nella scheda Granularità della metrica e per il periodo di riferimento, viene eseguita una nuova istanza di business logic dal motore. Ciascuna di tali istanze esegue lo stesso codice di business logic, ma OnPeriodStart e OnPeriodEnd verranno avviati in modo diverso per ciascuna istanza. Ogni istanza giornaliera verrà attivata all'inizio del giorno e alla fine del giorno. Ogni unità di tempo verrà attivata in base all'inizio dell'unità di tempo e ai punti di fine.
Tutte le istanze di business logic vengono eseguite per generare il risultato di unità di tempo pertinente. Inoltre, ogni periodo deve avere un risultato che prenda in considerazione eventuali eccezioni. Qualsiasi periodo che non ne tiene conto, se le eccezioni sono definite, deve consentire all'utente di scegliere se visualizzare il risultato del livello di servizio con o senza le eccezioni prese in considerazione. A causa di questo requisito, ciascuna metrica potrebbe avere quattordici agenti (istanze) eseguiti dal motore, due agenti per i risultati di business e dodici per i sei ulteriori periodi operativi.

Questo significa che la definizione di granularità ha un forte impatto sulle prestazioni del motore di calcolo perché ogni periodo viene calcolato per un agente diverso. Pertanto, nei casi in cui la caratteristica funzionale di drill-down non è necessaria per intero o in parte, è consigliabile che alcuni agenti siano disattivati. Questa operazione ha un impatto particolarmente notevole nel caso di granularità inferiori quali i risultati orari. Ha anche un enorme impatto per la metrica di gruppo, poiché il motore esegue tutti i calcoli di cui sopra per ogni ClusterItem rilevato. In effetti, tratta ogni ClusterItem come nuova metrica. Ad esempio, durante il calcolo di una metrica in un gruppo di risorse di 50 elementi, il motore effettuerà un lavoro 49 volte superiore rispetto alla stessa metrica non di gruppo.
Ad esempio, se la metrica è impostata per calcolare il tempo di risoluzione in numero di giorni, il risultato orario è irrilevante e deve essere deselezionato nella scheda delle granularità per evitare al motore di eseguire calcoli inutili.
L'attributo TimeUnit dell'oggetto Contesto (ad esempio, context.TimeUnit nella business logic) restituisce l'unità di tempo dell'agente attualmente in esecuzione, in cui i possibili valori restituiti sono: HOUR, DAY, WEEK, MONTH, QUARTER, YEAR.
Ad esempio, per ogni agente giornaliero Context.TimeUnit restituirà "DAY".
L'attributo IsTrackingPeriod dell'oggetto Contesto restituisce true per l'agente che calcola l'unità di tempo del periodo di riferimento. È importante notare inoltre che gli agenti visualizzati nella scheda Granularità delle metriche si aggiungono all'agente del periodo di riferimento della metrica. Pertanto, anche per una metrica con un periodo di riferimento mensile è possibile disattivare l'agente mensile e verrà comunque calcolato il livello di servizio mensile, ma solo come risultato di business (risultati non operativi).

Come descritto sopra, i diversi agenti in genere eseguono lo stesso codice di business logic, ma vi sono casi in cui è necessario applicare una logica leggermente diversa.
Ad esempio, per il caso mensile, il risultato deve essere il numero di tempi di inattività per ogni mese separatamente, come mostrato di seguito:

Per il drill-down giornaliero è necessario poter visualizzare i tempi di inattività complessivi, in cui ogni giorno è la somma di tutti i giorni dall'inizio del mese. Questo metodo deve essere applicato a tutte le unità di tempo inferiori a un mese, come mostrato di seguito:

La differenza tra le due unità di tempo è che per l'agente che calcola il periodo di riferimento il contatore del tempo di inattività verrà inizializzato su 0 all'inizio di ogni periodo, ma per l'agente giornaliero il contatore verrà inizializzato solo nel caso in cui il giorno è il primo giorno del mese.
Di seguito è riportato il gestore eventi 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
Il ricalcolo viene eseguito quando il motore di correlazione identifica che un risultato periodico finale di metrica non è più valido ed è pertanto necessario calcolare nuovamente i risultati.
Il ricalcolo potrebbe essere causato da:
Il metodo più efficiente di registrazione è per Contraente e servizio. La disposizione delle risorse per contraente e per servizi è un modo per esprimere la relazione logica tra il livello di dati e il livello di business nel sistema. La registrazione delle risorse attraverso queste entità non richiede la modifica delle formule se utilizzate in diversi contratti o per diversi servizi. Il contesto corrente della metrica identifica il contratto e il servizio, che definisce il contraente pertinente e il servizio associato. È possibile riutilizzare facilmente le formule di business logic definite in questo tipo di registrazione perché non richiedono modifiche nella registrazione.
|
Copyright © 2013 CA.
Tutti i diritti riservati.
|
|