Pourquoi utiliser statsd quand l'agrégateur de carbone de graphite peut faire le même travail?
J'ai exploré l'outil graphique Graphite pour afficher les métriques de plusieurs serveurs, et il semble que la méthode "recommandée" consiste à envoyer toutes les données de métriques à StatsD en premier. StatsD agrège les données et les envoie au graphite (ou plutôt, Carbon).
Dans mon cas, je veux faire des agrégations simples comme la somme et la moyenne des métriques sur les serveurs et tracer cela en graphite. Le graphite est livré avec un agrégateur de carbone qui peut le faire.
StatsD ne fournit même pas d'agrégation du genre dont je parle.
Ma question est - dois-je utiliser statsd pour mon cas d'utilisation? Quelque chose me manque ici?
StatsD fonctionne sur UDP, ce qui élimine le risque que carbon-aggregator.py soit lent à répondre et introduise une latence dans votre application. En d'autres termes, un couplage lâche.
StatsD prend en charge l'échantillonnage des métriques entrantes, ce qui est utile lorsque vous ne voulez pas que votre agrégateur utilise 100% de tous les points de données pour calculer des statistiques descriptives. Pour les sections de code à volume élevé, il est courant d'utiliser des taux d'échantillonnage de 0,5% à 1% afin de ne pas surcharger StatsD.
StatsD a large côté client support.
tldr: vous voudrez probablement statsd (ou carbon-c-relay ) si vous voulez regarder le serveur- des sommes ou des moyennes spécifiques.
agrégateur de carbone est conçu pour agréger les valeurs de plusieurs métriques ensemble en une seule métrique de sortie, généralement pour augmenter les performances de rendu du graphique. statsd est conçu pour agréger plusieurs points de données dans une seule métrique, car sinon, le graphite stocke uniquement la dernière valeur signalée dans la résolution de stockage minimale.
exemple statsd: supposons que votre fichier graphite storage-schemas.conf a une rétention minimale de 10 secondes (par défaut) et que votre application envoie environ 100 données points toutes les 10 secondes pour services.login.server1.count avec une valeur de 1. sans statsd, le graphite ne stockerait que le dernier décompte reçu dans chaque compartiment de 10 secondes. après la réception du 100e message, les 99 autres points de données auraient été supprimés. cependant, si vous mettez des stats entre votre application et le graphite, il additionnera les 100 points de données ensemble avant d'envoyer le total au graphite. ainsi, sans statsd, votre graphique indique uniquement si une connexion s'est produite pendant l'intervalle de 10 secondes. avec statsd, il indique combien les connexions ont eu lieu pendant cet intervalle. ( par exemple )
exemple d'agrégateur de carbone: supposons que vous avez 200 serveurs différents signalant 200 mesures distinctes ( services.login.server1.response.time =, services.login.server2.response.time, etc.). sur votre tableau de bord des opérations, vous affichez un graphique de la moyenne sur tous les serveurs utilisant cette requête graphite: weightedAverage (services.login.server * .response.time, services.login.server * .response.count, 2). malheureusement, le rendu de ce graphique prend 10 secondes. pour résoudre ce problème, vous pouvez ajouter une règle d'agrégateur de carbone pour pré-calculer la moyenne sur tous vos serveurs et stocker la valeur dans une nouvelle métrique. vous pouvez maintenant mettre à jour votre tableau de bord pour extraire simplement une seule métrique (par exemple services.login.response.time). la nouvelle métrique s'affiche presque instantanément.
notes annexes:
les règles d'agrégation dans storage -gregation.conf s'appliquent à tous les intervalles de stockage dans storage-schemas.conf sauf la première (la plus petite) période de rétention pour chaque chaîne de rétention. il est possible d'utiliser l'agrégateur de carbone pour agréger des points de données dans une métrique pour cette première période de rétention. malheureusement ,gregation-rules.conf utilise des modèles "blob" plutôt que des modèles regex. vous devez donc ajouter une entrée de fichier d'agrégation-règles.conf distincte pour chaque profondeur de chemin et type d'agrégation. l'avantage de statsd est que le client qui envoie la métrique peut spécifier le type d'agrégation plutôt que de l'encoder dans le chemin de la métrique. qui vous donne la possibilité d'ajouter une nouvelle métrique à la volée quelle que soit la profondeur du chemin métrique. si vous vouliez configurer carbone-agrégateur pour faire automatiquement une agrégation de type statsd lorsque vous ajoutez une nouvelle métrique, votre fichier agrégation-rules.conf ressemblerait à ceci:
<n1>.avg (10)= avg <n1>.avg$ <n1>.count (10)= sum <n1>.count$ <n1>.<n2>.avg (10)= avg <n1>.<n2>.avg$ <n1>.<n2>.count (10)= sum <n1>.<n2>.count$ <n1>.<n2>.<n3>.avg (10)= avg <n1>.<n2>.<n3>.avg$ <n1>.<n2>.<n3>.count (10)= sum <n1>.<n2>.<n3>.count$ ... <n1>.<n2>.<n3> ... <n99>.count (10)= sum <n1>.<n2>.<n3> ... <n99>.count$notes: le "$" de fin n'est pas nécessaire dans graphite 0.10+ (actuellement pré-version) voici le patch approprié sur github et voici la documentation standard sur règles d'agrégation
la fonction weightedAverage est nouvelle dans le graphite 0.10, mais généralement la fonction averageSeries donnera un nombre très similaire tant que votre charge est également équilibrée. si vous avez des serveurs qui sont à la fois plus lents et traitent moins de demandes ou si vous êtes juste un bâton pour la précision, vous pouvez toujours calculer une moyenne pondérée avec graphite 0.9. il vous suffit de créer une requête plus complexe comme celle-ci:
divideSeries(sumSeries(multiplySeries(a.time,a.count), multiplySeries(b.time,b.count)),sumSeries(a.count, b.count))si statsd est exécuté sur la boîte client, cela réduit également la charge du réseau. bien que, en théorie, vous puissiez également exécuter l'agrégateur de carbone côté client. cependant, si vous utilisez l'une des bibliothèques client statsd, vous pouvez également utiliser l'échantillonnage pour réduire la charge sur le processeur de votre machine d'application (par exemple, créer des paquets udp de bouclage). en outre, statsd peut effectuer automatiquement plusieurs agrégations différentes sur une seule métrique d'entrée (somme, moyenne, min, max, etc.)
si vous utilisez statsd sur chaque serveur d'applications pour agréger les temps de réponse, puis ré-agréger ces valeurs sur le serveur graphite à l'aide de l'agrégateur de carbone, vous vous retrouvez avec un temps de réponse moyen pondéré par le serveur d'applications plutôt que de demander. évidemment, cela n'a d'importance que pour l'agrégation en utilisant une règle d'agrégation moyenne ou top_90, et non pas min, max ou sum. aussi, cela n'a d'importance que si votre charge est déséquilibrée. à titre d'exemple: supposons que vous avez un cluster de 100 serveurs, et soudainement 1 serveur est envoyé à 99% du trafic. par conséquent, les temps de réponse quadruplent sur ce 1 serveur, mais restent stables sur les 99 autres serveurs. si vous utilisez l'agrégation côté client, votre métrique globale n'augmenterait que d'environ 3%. mais si vous effectuez toute votre agrégation dans un seul agrégateur carbone côté serveur, votre métrique globale augmenterait d'environ 300%.
carbone-relais c est essentiellement un remplacement sans rendez-vous pour le carbone-agrégateur écrit en c. il a amélioré les performances et les règles de correspondance basées sur les expressions rationnelles. le résultat est que vous pouvez faire à la fois l'agrégation de points de données de style statsd et l'agrégation de métriques de style relais carbone et d'autres trucs sympas comme l'agrégation multicouche dans le même fichier de configuration basé sur des regex simples.
si vous utilisez le back-end cyanite au lieu de carbone-cache, alors la cyanite fera la moyenne intra-métrique pour vous en mémoire (à partir de version 0.5.1 ) ou au moment de la lecture (dans l'architecture de la version <0.1.3).
Si l'agrégateur Carbon offre tout ce dont vous avez besoin, il n'y a aucune raison de ne pas l'utiliser. Il a deux fonctions d'agrégation de base (somme et moyenne), et en effet celles-ci ne sont pas couvertes par StatsD. (Je ne suis pas sûr de l'historique, mais peut-être que l'agrégateur Carbon existait déjà et que les auteurs de StatsD ne voulaient pas dupliquer les fonctionnalités?) La réception de données via UDP est également prise en charge par Carbon, donc la seule chose que vous manqueriez serait l'échantillonnage , ce qui n'a pas d'importance si vous agrégez par moyenne.
StatsD prend en charge différents types de mesures en ajoutant des valeurs agrégées supplémentaires (par exemple, pour les temporisateurs: moyenne, inférieure, Xe centile supérieur et supérieur, ...). Je les aime, mais si vous n'en avez pas besoin, l'agrégateur de carbone est un bon moyen d'y aller aussi.
J'ai regardé le code source de l'agrégateur Carbon et StatsD (et Bucky , une implémentation StatsD en Python), et ils sont tous si simples, que je ne me soucierais pas de l'utilisation des ressources ou des performances pour soit choix.
On dirait que l'agrégateur de carbone et les statistiques prennent en charge un ensemble de fonctionnalités disjointes:
- statsd prend en charge le calcul et la sommation des taux mais ne prend pas en charge les valeurs moyennes
- l'agrégateur de carbone prend en charge la moyenne mais ne prend pas en charge le calcul du taux.