Convenzioni di denominazione statica/grafite per metriche

Question

Sto iniziando il processo di strumentazione di un'applicazione Web e utilizzo di StatsD per raccogliere il maggior numero possibile di metriche pertinenti. Per esempio, qui ci sono alcuni esempi di nomi metriche di alto livello sono attualmente in uso:

http.responseTime 
http.status.4xx 
http.status.5xx 
view.renderTime 
oauth.begin.facebook 
oauth.complete.facebook 
oauth.time.facebook 
users.active 

... e ci sono molti, molti di più. Ciò a cui mi sto confrontando in questo momento è la creazione di una gerarchia coerente e un insieme di convenzioni di denominazione per le varie metriche, in modo che quelle attuali abbiano un senso e che vi siano bucket logici entro i quali aggiungere metriche future.

La mia domanda è duplice:

1. Quali metriche stai raduno che avete trovato indespensible rilevante?
2. Quale struttura di denominazione si utilizza per classificare le metriche?

Answer 1

Questa è una domanda che non ha risposta definitiva, ma ecco come lo facciamo a Datadog (siamo un servizio di monitoraggio hosted in modo tendiamo a ossessionare queste cose).

1. Quali metriche sono indispensabili? Dipende da chi guarda. Ma ad alto livello, per ogni squadra, qualsiasi metrica che sia il più vicino possibile ai propri obiettivi (che potrebbe non essere la più facile da raccogliere).

Le metriche di sistema (ad esempio carico di sistema, memoria ecc.) Sono banali da raccogliere ma raramente utilizzabili perché sono troppo difficili da collegarle in modo affidabile a una causa probabile.

D'altra parte, il numero di tour del prodotto completati è importante per chiunque abbia il compito di assicurarsi che i nuovi utenti siano felici fin dal primo minuto in cui utilizzano il prodotto. StatsD rende questo genere di cose banalmente facile da collezionare.

Abbiamo anche riscontrato che il set principale di metriche chiave per qualsiasi cambio di squadra man mano che il prodotto si evolve, vi è un processo editoriale continuo .

Che a sua volta significa che chiunque nell'azienda deve essere in grado di scegliere quali metriche sono importanti per loro. Nessuna autorizzazione richiesta, nessuna frizione per ottenere i dati.

2. Struttura dei nomi Il livello più alto di gerarchia è la linea di prodotti o il processo. Il nostro frontend web è internamente chiamato dogweb, quindi tutte le metriche di quel componente sono precedute da dogweb.. Il livello successivo di gerarchia è il sottocomponente, ad es. dogweb.db., dogweb.http., ecc. L'ultimo livello di gerarchia è la cosa misurata (ad esempio renderTime o responseTime).

Il problema irrisolto in grafite è la codifica dei metadati metrici nel nome della metrica (e selezione utilizzando *, ad esempio dogweb.http.browser.*.renderTime) È intelligente ma può essere d'intralcio.

Abbiamo finito per implementare metadati espliciti nel nostro modello di dati, ma questo non è in stats/graphite quindi lascerò i dettagli fuori. Se vuoi saperne di più, contattami direttamente.