scaling statsd con più server

Question

Sto stendendo un'architettura in cui useremo statsd e grafite. Capisco come funziona la grafite e come un singolo server statsd potrebbe comunicare con esso. Mi chiedo come l'architettura e la configurazione funzionerebbero per ridimensionare i server statsd. Avresti più server statsd server e poi un server statsd centrale che spinge in grafite? Non riuscivo a trovare nulla su come ridimensionare le statistiche e qualsiasi idea su come avere più server statsd sarebbe apprezzata.

Answer 1

Mi sto occupando dello stesso problema in questo momento. Fare un ingenuo bilanciamento del carico tra più statsds ovviamente non funziona perché le chiavi con lo stesso nome finirebbero con diverse statistiche e sarebbero quindi aggregate in modo errato.

Ma ci sono un paio di opzioni per l'utilizzo di statsd in un ambiente che ha bisogno di scalare:

• uso di campionamento sul lato client per le metriche da banco, come descritto nella documentazione statsd (cioè invece di inviare ogni evento per statsd, invia solo ogni 10 eventi e crea statistiche moltiplicandolo per 10). Lo svantaggio è che è necessario impostare manualmente una frequenza di campionamento appropriata per ciascuna metrica. Se assumi troppo pochi valori, i risultati saranno imprecisi. Se assumi troppo, uccidi la tua (unica) istanza statsd.

• creare un bilanciamento del carico personalizzato che suddivide il nome metrico in diverse statistiche, eludendo in tal modo il problema dell'aggregazione interrotta. Ognuno di questi potrebbe scrivere direttamente su Graphite.

• creare un client statsd che conta gli eventi localmente e li invia solo in aggregato a statsd. Ciò riduce notevolmente il traffico verso statistiche e lo rende costante (a condizione che non si aggiungano più server). Finché il periodo con il quale invii i dati a statsd è molto più piccolo del periodo di flush dello stesso statsd, dovresti anche ottenere risultati altrettanto accurati.

• variazione del punto finale che ho implementato con grande successo nella produzione: utilizzare un primo strato di multiplo (nel mio caso locali) statsds, che a sua volta tutta aggregato in un'unica statsd centrale, che poi parla Grafite. Il primo strato di statsds avrebbe bisogno di un tempo di flush molto più piccolo del secondo. Per fare ciò, avrai bisogno di un backend statsd-to-statsd. Dal momento che ho dovuto affrontare proprio questo problema, ho scritto uno che cerca di essere il più efficiente in rete il più possibile: https://github.com/juliusv/ne-statsd-backend

Così com'è, statsd è stato, purtroppo, non progettato per essere scalabile in modo gestibile (no, I don' vedere la regolazione manuale delle frequenze di campionamento come "gestibile"). Ma i rimedi sopra descritti dovrebbero aiutare se sei bloccato con esso.

Answer 2

Se si ha accesso a un sistema di bilanciamento del carico hardware come un BigIP F5 (immagino ci siano implementazioni software OSS che lo fanno) e capita di avere il nome host di ciascun host nelle proprie metriche (cioè si stanno contando cose come " appname.servername.foo.bar.baz "e aggregandoli a livello di grafite) è possibile utilizzare il bilanciamento del carico di affinità con l'indirizzo di origine: invia tutto il traffico da un indirizzo di origine allo stesso nodo di destinazione (entro un ragionevole timeout). Quindi, purché ogni nome di metrica provenga da un solo host di origine, otterrà il risultato desiderato.

Answer 3

La maggior parte delle implementazioni che ho visto usare per metriche dei server, come: <env>.applications.<app>.<server>.<metric>

Con questo approccio è possibile avere istanze statsd locali su ogni scatola, fare il lavoro UDP localmente, e lasciare che statsd pubblicare le sue aggregati alla grafite.

se non si ha realmente bisogno per metriche dei server, sono disponibili due opzioni:

1. Combine metriche correlate nello strato di visualizzazione (ad es: by configuring graphiti to do so)
2. Carbonio aggregazione take care of that