On a cassé notre fédération Prometheus aujourd'hui. La cause ? HAproxy qui génère 27'000 métriques par noeud.
Le nombre de métriques est exponentiel avec le nombre de backends & serveurs.
À la base on est "juste" passés de 10 VM de cache à 30, les 900'000 métriques d'un coup, la federation coince.
Le nombre de métriques est exponentiel avec le nombre de backends & serveurs.
À la base on est "juste" passés de 10 VM de cache à 30, les 900'000 métriques d'un coup, la federation coince.
Comments
Bref pour contourner rapidement le problème : j'ai fait du sharding basé sur l'hostname de la VM, pour diviser par 10 le nombre de métriques récupérées à la fois par la fédération.
Peut-être des idées à prendre dans l'article suivant.
https://techblog.criteo.com/how-we-reduc...
Mais oui c'est un peu ma crainte : si je dois le faire par métrique, ça va être complexe.
Ce que j'aime dans la fédération, c'est que "monitorer le monitoring" c'est vachement plus facile.
J'ai plein de stacks différentes, chez plein d'hébergeurs différents, j'ai pas encore mis en place tout ce qu'il me faut pour passer en remote-write.
Le pull a tjr été une erreur et prom a été une regression sur ce sujet je pense (comparé à avant où le push était là en force, et ça revient avec otel).
En tout cas, j'ai pu constater à de nombreuses reprises par le passé des situations où l'infra obs était mise à mal par l'ajout de quelques metrics/logs dans un service tout juste déployé.