Graphite cesse de collecter des données de manière aléatoire

Il ne s'agit pas d'un bug de la pile graphite, mais plutôt d'un goulot d'étranglement au niveau des entrées/sorties, très probablement parce que votre stockage n'a pas le nombre d'IOPS suffisant. Pour cette raison, la file d'attente continue de s'accumuler, et déborde à 4M. À ce moment-là, vous perdre autant de données en attente, qui se reflètent plus tard, sous forme de "trous" aléatoires dans votre graphique. Votre système ne peut pas keep up avec l'échelle à laquelle il reçoit les métriques. Il garde remplir et déborder .

Étrangement, le cpuUsage diminue légèrement de 100% ( à 50% lorsque la taille du cache augmente.

Cela s'explique par le fait que votre système commence à échanger des données et que les processeurs ont beaucoup de temps d'inactivité, en raison de l'attente des entrées-sorties.

Pour ajouter au contexte, j'ai 500 IOPS provisionnées chez aws sur un système sur lequel je reçois environ 40K métriques. La file d'attente est stable à 50K.

Un autre répondant a mentionné un goulot d'étranglement au niveau des entrées/sorties du disque. Je parlerai du goulot d'étranglement du réseau comme d'une autre cause de ce problème.

Dans mon environnement, nous utilisons un cluster de serveurs d'interface utilisateur frontale (httpd, memcached), un autre cluster de relais de couche intermédiaire (carbon-c-relay qui effectue le transfert et l'agrégation) et une couche dorsale (httpd, memcached, carbon-c-relay et carbon-cache). Chacun de ces clusters se compose de plusieurs instances dans EC2 et traite au total 15 millions de métriques par minute.

Nous avions un problème où nous voyions des écarts pour les métriques générées par la fonction "somme" agrégée, et aussi les valeurs agrégées étaient incorrectes (trop basses). Le problème s'atténuait en redémarrant carbon-c-relay dans la couche intermédiaire, mais les écarts recommençaient à apparaître après plusieurs heures.

L'agrégation avait lieu à la fois dans la couche intermédiaire et dans la couche dorsale (la couche dorsale agrégeait les métriques agrégées qui lui étaient transmises par la couche intermédiaire).

Les hôtes de la couche intermédiaire n'étaient pas limités par le processeur, ni par le disque, et n'avaient aucune contrainte sur la mémoire. Ceci, combiné au fait que le problème n'apparaissait que quelques heures après le redémarrage des processus de relais, signifiait qu'il y avait un goulot d'étranglement dans le réseau. Notre solution consistait simplement à ajouter des hôtes supplémentaires à la couche intermédiaire. Grâce à cette mesure, les métriques agrégées se sont instantanément comportées correctement et n'ont pas connu d'écarts.

L'endroit exact de la pile réseau où se trouvait le goulot d'étranglement ? Je ne pourrais pas vous le dire. Cela pourrait être sur les hôtes linux, cela pourrait être du côté d'Amazon.