Distribuzione altamente disponibile, accessibile sul Web e scalabile di statsd e grafite

Mi piacerebbe impostare statsd / graphite in modo da poter registrare le app JS in esecuzione su dispositivi HTML (cioè non in un ambiente LAN contenuto, e possibilmente con un grande volume di dati in entrata che non controllo direttamente).

I miei vincoli:

• il punto di ingresso deve parlare HTTP: questo è risolto da un semplice proxy da HTTP a UDP-statsd (es. httpstatsd su github)
• deve resistere al fallimento di un singolo server (per combattere la legge di Murphy :)
• deve essere scalabile in senso orizzontale: vendita web, piccola! :)
• l'architettura dovrebbe essere mantenuta il più semplice (ed economica) possibile
• i miei server sono macchine virtuali
• i file di dati verranno archiviati su un'appliance di filer (con NFS)
• Ho a disposizione bilance di carico hardware tcp / udp

In breve, il percorso dei dati: [client] - (http) -> [http2statsd] - (udp) -> [statsd] - (tcp) -> [graphite] - (nfs) -> [filer]

I miei risultati finora:

• ridimensionare la parte http2statsd è semplice (demoni senza stato)
• ridimensionare la parte statsd non sembra semplice (immagino che finirei con valori incoerenti in grafite per dati aggregati come sum, avg, min, max ...). A meno che il demone HTTP non esegua un hash coerente per frammentare le chiavi. Forse un'idea ... (ma poi c'è la domanda HA)
• il ridimensionamento della parte di grafite può essere fatto tramite lo sharding (usando carbon-relay) (ma questo non risolve nemmeno la domanda HA). Ovviamente diverse istanze di sussurro non dovrebbero scrivere lo stesso file NFS.
• ridimensionare la parte del filer non fa parte della domanda (ma meno IO, meglio è :)
• il ridimensionamento della webapp sembra ovvio (anche se non l'ho testato) in quanto leggono solo i dati NFS condivisi

Quindi mi chiedevo se qualcuno avesse esperienze e buone pratiche da condividere per una solida distribuzione di statd / grafite?

Esiste un proxy statsd con hashing coerente, che rende possibile distribuire il traffico statsd tra più aggregatori statsd, ciascuno utilizzando il proprio set di nomi di metriche. È un elemento di scalabilità cruciale nella tua architettura, che consente di ridimensionare i processi statsd.

Anche la grafite è complicata, ma si spera che non sia necessaria una scala infinita e che si possa fare solo un buon sharding per servizio o qualche altro parametro statico.

La parte più difficile è il ridimensionamento di webapp e dipende molto da quali sono le tue query grafiche più pesanti. Tuttavia, è sempre possibile pre-aggregare i dati per i grafici più difficili e sbarazzarsi della maggior parte del carico.

Sto usando HostedGraphite da un po 'di tempo per evitare tutto questo dolore, questi ragazzi hanno implementato il loro backend Riak per Carbon e fanno tutto il ridimensionamento lì.