Metriche DropWizard Metri vs Timer

Question

Sto imparando il DropWizard Metrics library (in precedenza le metriche Coda Hale) e sono confuso su quando dovrei usare Meters vs Timers. Secondo la documentazione:

Meter: misure Un contatore La velocità alla quale una serie di eventi si verifica

e:

Timer: Un timer è fondamentalmente un istogramma della durata di un tipo di evento e un metro del tasso di occorrenza

Sulla base di queste definizioni, non posso discernere la differenza tra queste. Ciò che mi confonde è che lo Timer non è usato nel modo in cui mi sarei aspettato che fosse usato. Per me, Timer è proprio questo: un timer; dovrebbe misurare il fuso orario tra start() e stop(). Ma sembra che lo Timers catturi anche i tassi in cui si verificano gli eventi, il che sembra che stiano calpestando le dita dei piedi Meters'.

Se potessi vedere un esempio di cosa produce ciascun componente che potrebbe aiutarmi a capire quando/dove usare uno di questi.

Answer 1

Siete confusi in parte perché un timer Metrics DW IS, tra le altre cose, un misuratore di metrica DW.

Uno strumento riguarda esclusivamente le velocità, misurate in Hz (eventi al secondo). in corso di pubblicazione Ogni risultati metro di 4 parametri distinti (?):

• un tasso di media (media) dal Metrics è stato avviato
• 1, 5 e 15 minuti di laminazione significare tassi

si utilizza un Misuratore registrando un valore in diversi punti del tuo codice - DW Metrics registra automaticamente l'orario del muro di ogni chiamata insieme al valore che gli hai assegnato e li utilizza per calcolare la frequenza con cui tale valore aumenta:

Meter getRequests = registry.meter("some-operation.operations") 
getRequests.mark() //resets the value, e.g. sets it to 0 
int numberOfOps = doSomeNumberOfOperations() //takes 10 seconds, returns 333 
getRequests.mark(numberOfOps) //sets the value to number of ops. 

Ci aspettiamo che le nostre tariffe siano 33,3 Hz, poiché si sono verificate 333 operazioni e l'intervallo tra le due chiamate in mark() è stato di 10 secondi.

Un timer calcola questi suddetti 4 parametri (considerando ogni Timer.Context essere un evento) e aggiunge loro un certo numero di metriche aggiuntive:

• un conteggio del numero di eventi
• min, significano e durate max visti dall'inizio della metrica
• deviazione standard
• un "istogramma", registrando la durata distribuito al 50 °, 97 °, 98 °, 99 ° e 99,95 percentili

0.123.

Ci sono qualcosa come 15 metriche totali segnalate per ogni Timer.

In breve: I timer riportano un sacco di metriche, e possono essere difficili da capire, ma una volta fatto sono un modo abbastanza efficace per individuare il comportamento di spikey.

Il fatto è che la semplice raccolta del tempo trascorso tra due punti non è una metrica molto utile. Prendere in considerazione: si dispone di un blocco di codice come questo:

Timer timer = registry.timer("costly-operation.service-time") 
Timer.Context context = timer.time() 
costlyOperation() //service time 10 ms 
context.stop() 

Supponiamo che costlyOperation() ha un costo costante, carico costante e opera su un singolo thread. All'interno di un periodo di riferimento di 1 minuto, dovremmo aspettarci di eseguire questa operazione 6000 volte. Ovviamente, non riporteremo il tempo di servizio effettivo sul filo 6000x, ma abbiamo bisogno di un modo per riassumere tutte quelle operazioni per adattarle alla nostra finestra di segnalazione desiderata. Il timer di DW Metrics fa questo per noi, automaticamente, una volta al minuto (il nostro periodo di segnalazione). Dopo 5 minuti, il nostro registro metriche sarebbe segnalando:

• una velocità di 100 (eventi al secondo)
• un 1 minuto significa tasso del 100
• 5 minuti tasso medio di 100
• un Numero di 30000 (totale eventi osservati)
• un massimo di 10 (ms)
• un minimo di 10
• una media di 10
• a 50 ° percentile del valore (p50) di 10
• un valore percentile 99.9 (P999) del 10

Ora, consideriamo entriamo in un periodo in cui di tanto in tanto la nostra operazione va completamente fuori dai binari e blocchi per un lungo periodo:

Timer timer = registry.timer("costly-operation.service-time") 
Timer.Context context = timer.time() 
costlyOperation() //takes 10 ms usually, but once every 1000 times spikes to 1000 ms 
context.stop() 

Nel corso di un periodo di raccolta 1 minuto, ci sarebbe ora vedere meno di 6000 esecuzioni, come ogni esecuzione 1000i richiede più tempo. Funziona a circa 5505. Dopo il primo minuto (tempo di sistema 6 minuti in totale) di questo si dovrebbe ora vedere:

• un tasso medio di 98 (eventi al secondo)
• un 1 minuto significa tasso di 91.75
• significa 5 minuti a velocità di 98.35
• un conteggio di 35505 (eventi totali visto)
• una durata massima pari a 1000 (ms)
• un min durata 10
• una durata media di 10 .13
• un valore 50 ° percentile (p50) di 10
• un valore 99.9 percentile (P999) del 1000

Se graficamente questo, si vedrebbe che la maggior parte delle richieste (il p50, p75 , p99 ecc.) stavano completando in 10 ms, ma una richiesta su 1000 (p99) stava completando in 1s. Ciò sarebbe anche considerato come una leggera riduzione del tasso medio (circa il 2%) e una riduzione considerevole della media di 1 minuto (quasi il 9%).

Se si considera solo il tempo (sia in termini di tariffa che di durata), non si individueranno mai questi picchi: essi vengono trascinati nel rumore di fondo quando si calcola la media con molte operazioni riuscite. Allo stesso modo, solo conoscere il massimo non è utile, perché non ti dice con quale frequenza si verifica il massimo. Questo è il motivo per cui gli istogrammi sono un potente strumento per il tracciamento delle prestazioni, e perché DW Metrics 'Timer pubblica sia un rate AND un istogramma.