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 dans la base graphite, ce qui provoquait un gros transfert de données vers le check et donc ralentissait le processus du serveur graphite.
Pour parait à cela, un script indépendant de graphite appelé shinken-iostats-collector a été crée pour calculer le nombre total de métrique sans que ça ralentisse le serveur graphite. Ce script se lance avec les droits root lors du démarrage de carbon-cache et s’éteint au en même temps que carbon-cache.
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.
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 connaitre le nombre de métrique le check shinken-broker-module-metrology-writer 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.
Cela a pour avantage de