Je voudrais configurer statsd / graphite pour pouvoir enregistrer les applications JS exécutées sur des appareils HTML (c'est-à-dire pas dans un environnement LAN confiné, et éventuellement avec un grand volume de données entrantes que je ne contrôle pas directement).
Mes contraintes:
- le point d'entrée doit parler HTTP: ceci est résolu par un simple proxy HTTP-à-UDP-statsd (par exemple httpstatsd sur github)
- doit résister à l'échec d'un seul serveur (pour combattre la loi de Murphy :)
- doit être évolutif horizontalement: échelle Web, bébé! :)
- l'architecture doit être aussi simple (et bon marché) que possible
- mes serveurs sont des machines virtuelles
- les fichiers de données seront stockés sur une appliance de filer (avec NFS)
- J'ai des équilibreurs de charge matérielle TCP / UDP à disposition
En bref, le chemin des données: [client] - (http) -> [http2statsd] - (udp) -> [statsd] - (tcp) -> [graphite] - (nfs) -> [filer]
Mes résultats jusqu'à présent:
- la mise à l'échelle de la partie http2statsd est facile (démons sans état)
- la mise à l'échelle de la partie statsd ne semble pas simple (je suppose que je me retrouverais avec des valeurs incohérentes en graphite pour des données agrégées telles que somme, moyenne, min, max ...). À moins que le démon HTTP n'effectue un hachage cohérent afin de partager les clés. Peut-être une idée ... (mais il y a ensuite la question HA)
- la mise à l'échelle de la pièce en graphite peut être effectuée par sharding (à l'aide de relais carbone) (mais cela ne résout pas non plus la question HA). Évidemment, plusieurs instances de chuchotement ne devraient pas écrire le même fichier NFS.
- la mise à l'échelle de la partie filer ne fait pas partie de la question (mais moins il y a d'E / S, mieux c'est :)
- la mise à l'échelle de la webapp semble évidente (bien que je n'ai pas testé) car ils ne lisent que les données NFS partagées
Je me demandais donc si quelqu'un avait des expériences et des meilleures pratiques à partager pour un déploiement solide de stats / graphite?