{"id":52113,"date":"2019-11-01T00:00:00","date_gmt":"2019-10-31T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/bioyino-raspredelyonnyj-masshtabiruemyj-agregator-metrik"},"modified":"2020-02-18T13:59:47","modified_gmt":"2020-02-18T10:59:47","slug":"bioyino-raspredelyonnyj-masshtabiruemyj-agregator-metrik","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/bioyino-raspredelyonnyj-masshtabiruemyj-agregator-metrik","title":{"rendered":"Bioyino \u2014 agr\u00e9gateur de m\u00e9triques distribu\u00e9 et \u00e9volutif","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Alors, vous collectez des m\u00e9triques. Tout comme nous. Nous collectons \u00e9galement des m\u00e9triques. Bien s\u00fbr, celles n\u00e9cessaires pour les affaires. Aujourd'hui, nous allons parler du tout premier maillon de notre syst\u00e8me de surveillance \u2014 un serveur d'agr\u00e9gation compatible avec statsd. bioyino<\/a><\/noindex>, pourquoi nous l'avons \u00e9crit et pourquoi nous avons abandonn\u00e9 brubeck. <\/p>\n

<\/p>\n

\"Bioyino<\/p>\n

<\/a><\/noindex><\/p>\n

Dans nos articles pr\u00e9c\u00e9dents (1<\/a><\/noindex>, 2<\/a><\/noindex>) vous pouvez apprendre que jusqu'\u00e0 un certain moment, nous avons collect\u00e9 des tags \u00e0 l'aide de brubeck<\/a><\/noindex>. Il est \u00e9crit en C. En termes de code, il est aussi simple qu'un bouchon (ce qui est important lorsque vous souhaitez contribuer) et, surtout, il g\u00e8re sans probl\u00e8me nos volumes de 2 millions de m\u00e9triques par seconde (MPS) en pointe. La documentation annonce un support de 4 millions de MPS avec ast\u00e9risque. Cela signifie que vous obtiendrez le chiffre annonc\u00e9 si vous configurez correctement le r\u00e9seau sous Linux. (Nous ne savons pas combien de MPS il est possible d'obtenir si le r\u00e9seau reste tel quel). Malgr\u00e9 ces avantages, nous avions quelques griefs s\u00e9rieux contre brubeck.<\/p>\n

<\/p>\n

Grief 1.<\/em> Github \u2014 le d\u00e9veloppeur du projet \u2014 a cess\u00e9 de le soutenir : publier des patchs et des corrections, accepter nos PR (et d'autres \u00e9galement). Au cours des derniers mois (depuis environ f\u00e9vrier-mars 2018), l'activit\u00e9 a repris, mais avant cela, il y avait presque 2 ans de silence complet. De plus, le projet est d\u00e9velopp\u00e9 pour les besoins internes de Github<\/a><\/noindex>, ce qui peut constituer un obstacle s\u00e9rieux \u00e0 l'impl\u00e9mentation de nouvelles fonctionnalit\u00e9s.<\/p>\n

<\/p>\n

Grief 2.<\/em> Pr\u00e9cision des calculs. Brubeck ne collecte que 65536 valeurs pour l'agr\u00e9gation. Dans notre cas, pour certaines m\u00e9triques pendant la p\u00e9riode d'agr\u00e9gation (30 secondes), il peut y avoir beaucoup plus de valeurs (1 527 392 en pointe). En cons\u00e9quence de cet \u00e9chantillonnage, les valeurs des maximums et minimums semblent inutiles. Par exemple, ainsi : <\/p>\n

<\/p>\n

\"Bioyino
\nComment c'\u00e9tait<\/em><\/p>\n

<\/p>\n

\"Bioyino
\nComment cela aurait d\u00fb \u00eatre<\/em><\/p>\n

<\/p>\n

Pour la m\u00eame raison, les sommes sont compl\u00e8tement incorrectes. Ajoutez \u00e0 cela un bug de d\u00e9bordement des flottants 32 bits, qui envoie le serveur dans un segfault lorsqu'il re\u00e7oit une m\u00e9trique apparemment innocente, et c'est encore mieux. Au fait, ce bug n'a toujours pas \u00e9t\u00e9 corrig\u00e9.<\/p>\n

<\/p>\n

Et enfin, Grief X<\/em>. Au moment de la r\u00e9daction de cet article, nous sommes pr\u00eats \u00e0 le soumettre \u00e0 toutes les 14 impl\u00e9mentations de statsd plus ou moins fonctionnelles que nous avons pu trouver. Imaginons qu'une infrastructure donn\u00e9e ait grandi au point o\u00f9 accepter 4 millions de MPS ne suffit plus. Ou peut-\u00eatre n'a-t-elle pas encore grandi, mais les m\u00e9triques sont d\u00e9j\u00e0 si importantes pour vous que m\u00eame de courtes interruptions de 2 \u00e0 3 minutes sur les graphiques peuvent devenir critiques et plonger les managers dans une d\u00e9pression insurmontable. Comme traiter la d\u00e9pression est une t\u00e2che ingrate, des solutions techniques sont n\u00e9cessaires.<\/p>\n

<\/p>\n

Tout d'abord, la tol\u00e9rance aux pannes, afin qu'un probl\u00e8me soudain sur le serveur ne d\u00e9clenche pas l'apocalypse zombie psychiatrique au bureau. Deuxi\u00e8mement, l'\u00e9volutivit\u00e9, pour pouvoir accepter plus de 4 millions de MPS sans avoir \u00e0 plonger dans la pile r\u00e9seau Linux et cro\u00eetre ais\u00e9ment \"en largeur\" jusqu'aux dimensions n\u00e9cessaires.<\/p>\n

<\/p>\n

Comme nous avions suffisamment de r\u00e9serve en mati\u00e8re d'\u00e9volutivit\u00e9, nous avons d\u00e9cid\u00e9 de commencer par la tol\u00e9rance aux pannes. \u00ab Oh ! Tol\u00e9rance aux pannes ! C'est simple, nous savons faire \u00e7a \u00bb, avons-nous pens\u00e9 et avons lanc\u00e9 2 serveurs, levant sur chacun une copie de brubeck. Pour cela, nous avons d\u00fb copier le trafic des m\u00e9triques sur les deux serveurs et m\u00eame \u00e9crire une petite utilitaire<\/a><\/noindex>. Nous avons r\u00e9solu le probl\u00e8me de tol\u00e9rance aux pannes, mais... pas tr\u00e8s bien. Au d\u00e9but, tout semblait aller bien : chaque brubeck collecte sa propre variante d'agr\u00e9gation, \u00e9crit des donn\u00e9es dans Graphite toutes les 30 secondes, en \u00e9crasant l'intervalle pr\u00e9c\u00e9dent (cela se fait c\u00f4t\u00e9 Graphite). Si un serveur tombe en panne, nous avons toujours le deuxi\u00e8me avec sa propre copie des donn\u00e9es agr\u00e9g\u00e9es. Mais voil\u00e0 le probl\u00e8me : si un serveur tombe en panne, il y a une \"scie\" sur les graphiques. Cela est d\u00fb au fait que les intervalles de 30 secondes sur brubeck ne sont pas synchronis\u00e9s, et au moment de la panne, l'un d'eux n'est pas r\u00e9\u00e9crit. Lors du d\u00e9marrage du deuxi\u00e8me serveur, c'est la m\u00eame chose. C'est assez tol\u00e9rable, mais nous voulons mieux ! Le probl\u00e8me d'\u00e9volutivit\u00e9 n'a \u00e9galement pas disparu. Toutes les m\u00e9triques continuent de \"fuser\" vers un serveur unique, et nous sommes donc limit\u00e9s par ces m\u00eames 2 \u00e0 4 millions de MPS en fonction de l'optimisation du r\u00e9seau.<\/p>\n

<\/p>\n

Si l'on r\u00e9fl\u00e9chit un peu au probl\u00e8me tout en pelletant la neige, une id\u00e9e \u00e9vidente peut venir \u00e0 l'esprit : un statsd capable de fonctionner en mode distribu\u00e9. C'est-\u00e0-dire, celui qui dispose d'une synchronisation entre les n\u0153uds en termes de temps et de m\u00e9triques. \u00ab Bien s\u00fbr, une telle solution existe s\u00fbrement d\u00e9j\u00e0 \u00bb, avons-nous dit en allant faire des recherches\u2026 Et nous n'avons rien trouv\u00e9. En parcourant la documentation de diff\u00e9rents statsd,https:\/\/github.com\/etsy\/statsd\/wiki#server-implementations<\/a><\/noindex> \u00e0 la date du 11.12.2017), nous n'avons trouv\u00e9 absolument rien. Il semble que ni les d\u00e9veloppeurs ni les utilisateurs de ces solutions ne se soient encore heurt\u00e9s \u00e0 UN TEL nombre de m\u00e9triques, sinon ils auraient s\u00fbrement trouv\u00e9 quelque chose.<\/p>\n

<\/p>\n

Et l\u00e0, nous nous sommes rappel\u00e9s du statsd \u00ab jouet \u00bb - bioyino, que nous avions \u00e9crit lors du hackathon juste pour le plaisir (le nom du projet a \u00e9t\u00e9 g\u00e9n\u00e9r\u00e9 par un script avant le d\u00e9but du hackathon) et nous avons r\u00e9alis\u00e9 qu'il nous fallait d'urgence notre propre statsd. Pourquoi ?<\/p>\n

<\/p>\n