Contexte
La problématique est que lorsque le check shinken-broker-module-metrology-writer interrogeait le serveur graphite pour obtenir le nombre total de métrique, pour ce faire le serveur graphite un index complet de toutes les métriques contenu contenues dans la base graphite, ce qui provoquait un gros transfert de données vers le check et donc ralentissait le processus du serveur graphite.
Description
Pour parait à gérer cela, un script indépendant de graphite appelé shinken-iostats-collectorgatherer a été crée pour calculer, entre autres, le nombre total de métrique sans que ça ralentisse le serveur graphite. Ce script est installé lors de l'installation de shinken et se lance et s'éteint au même temps que le processus carbon-cache. A noter que le script se lance avec les droits root.
Une fois lancé le script se met en tache de fond et tourne en boucle pour créer deux fichiers, l'un pour stocker le nombre de métriques présent dans graphite et l'autre pour stocker les statistiques des disques du serveur.
Fonctionnement de la récupération du nombre de métriques
Pour connaitre le nombre de métrique présent dans graphite, shinken-iostats-collector regarde toute les minutes le nombre de fichier terminant par .wsp présent dans les dossiers du dossier de stockage des métriques (/opt/graphite/storage/whisper/) à l'aide de la commande find (plus rapide que la commande ls ). Une fois que shinken-iostats-collector connait le nombre de métrique, il stocke cette valeur dans le fichier /opt/graphite/storage/whisper/.nb_metrics.
Pour que le check shinken-broker-module-metrology-writer connaisse le nombre de métrique, il va interroger le serveur Apache (le serveur possédant graphite). Qui va ensuite lire le fichier /opt/graphite/storage/whisper/.nb_metrics pour obtenir la valeur et l'a revoit vers le check.
L'avantage d'utiliser shinken-iostats-collector dans ce cas est que comme c'est un processus indépendant le calcul du nombre de métrique n'influence que très peu les performances de graphite, car auparavant le check shinken-broker-module-metrology-writer demande directement au serveur graphite qui effectuait la commande ls puis renvoyer les informations. Sauf que sur de grosse configuration avec beaucoup de métrique, le serveur graphite été ralenti.
automatiquement avec les démons.
Vous pouvez voir toutes les informations sur ce script automatique sur sa page dédiée
Fonctionnement de la récupération des données des disques
Pour superviser correctement la métrologie, il faut aussi connaître le performance des disques du serveur. Auparavant le check shinken-broker-module-metrology-writer n'avait rien pour obtenir ses informations, car le serveur Apache n'avait pas les droits suffisant pour connaitre les performance des disques du à la protection SElinux.
C'est pour cela que shinken-iostats-collector possède les droits root afin d'effectuer les commandes nécessaires pour obtenir les valeurs d'utilisation des disques du serveur. Une fois ses valeurs récupérées, le script stocke ses données dans le fichier /tmp/__check_graphite_iostats.tmp. Enfin pour récupérer ses valeurs le check shinken-broker-module-metrology-writer va lire ce fichier.