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?
http
high-availability
scalability
graphite
statsd
David142
la source
la source
Réponses:
Il existe un proxy statsd avec un hachage cohérent, qui permet de répartir le trafic statsd entre plusieurs agrégateurs statsd, chacun utilisant son propre ensemble de noms de métriques. C'est un élément d'évolutivité crucial dans votre architecture, vous permettant de faire évoluer les processus statsd.
Le graphite est également délicat, mais nous espérons que vous n'aurez pas besoin d'une échelle infinie et que vous pourrez effectuer un partage fin par service ou tout autre paramètre statique.
La partie la plus difficile est la mise à l'échelle de l'application Web, et cela dépend beaucoup de vos requêtes de graphique les plus lourdes. Cependant, vous pouvez toujours pré-agréger les données pour les graphiques les plus difficiles et vous débarrasser de la majeure partie de la charge.
J'utilise HostedGraphite depuis un certain temps pour éviter toute cette douleur, ces gars-là ont implémenté leur propre backend Riak pour Carbon et y font toute la mise à l'échelle.
la source