{"id":81888,"date":"2020-05-17T13:42:23","date_gmt":"2020-05-17T11:42:23","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/thanos-masshtabiruemyj-prometheus"},"modified":"2020-05-17T13:42:23","modified_gmt":"2020-05-17T11:42:23","slug":"thanos-masshtabiruemyj-prometheus","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/thanos-masshtabiruemyj-prometheus","title":{"rendered":"Thanos \u2014 un Prometheus \u00e9volutif","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

La traduction de l'article a \u00e9t\u00e9 pr\u00e9par\u00e9e sp\u00e9cialement pour les \u00e9tudiants du cours \u00ab Pratiques et outils DevOps \u00bb<\/a><\/noindex>.<\/i><\/b><\/p>\n

\nFabian Reinartz<\/a><\/noindex> \u2014 d\u00e9veloppeur de logiciels, passionn\u00e9 par Go et amateur de r\u00e9soudre des d\u00e9fis complexes. Il est \u00e9galement mainteneur de Prometheus et cofondateur du SIG instrumentation de Kubernetes. Auparavant, il \u00e9tait ing\u00e9nieur de production chez SoundCloud et a dirig\u00e9 l'\u00e9quipe de surveillance chez CoreOS. Il travaille actuellement chez Google.<\/p>\n

Bartek Plotka<\/a><\/noindex> \u2014 ing\u00e9nieur d'infrastructure chez Improbable. Il s'int\u00e9resse aux nouvelles technologies et aux d\u00e9fis des syst\u00e8mes distribu\u00e9s. Il a de l'exp\u00e9rience en programmation bas niveau chez Intel, en tant que contributeur \u00e0 Mesos et en tant qu'ing\u00e9nieur SRE mondial chez Improbable. Il travaille \u00e0 am\u00e9liorer le monde des microservices. Ses trois passions : Golang, open source et volleyball.<\/i><\/p>\n

En regardant notre produit phare SpatialOS, on peut deviner qu'Improbable a besoin d'une infrastructure cloud hautement dynamique \u00e0 l'\u00e9chelle mondiale avec des dizaines de clusters Kubernetes. Nous avons \u00e9t\u00e9 parmi les premiers \u00e0 commencer \u00e0 utiliser le syst\u00e8me de surveillance Prometheus<\/a><\/noindex>. Prometheus peut suivre des millions de m\u00e9triques en temps r\u00e9el et est livr\u00e9 avec un langage de requ\u00eate puissant qui permet d'extraire les informations n\u00e9cessaires.<\/p>\n

La simplicit\u00e9 et la fiabilit\u00e9 de Prometheus sont l'un de ses principaux atouts. Cependant, apr\u00e8s avoir atteint une certaine \u00e9chelle, nous avons rencontr\u00e9 plusieurs inconv\u00e9nients. Pour r\u00e9soudre ces probl\u00e8mes, nous avons d\u00e9velopp\u00e9 Thanos<\/a><\/noindex> \u2014 un projet open source cr\u00e9\u00e9 par Improbable, pour transformer sans couture les clusters Prometheus existants en un syst\u00e8me de surveillance unique avec un stockage illimit\u00e9 des donn\u00e9es historiques. Thanos est disponible sur Github ici<\/a><\/noindex>.<\/a><\/noindex><\/p>\n

Restez inform\u00e9 des derni\u00e8res nouvelles d'Improbable.<\/a><\/noindex><\/p>\n

Nos objectifs avec Thanos<\/h2>\n

\n\u00c0 une certaine \u00e9chelle, des probl\u00e8mes \u00e9mergent qui d\u00e9passent les capacit\u00e9s de Prometheus vanilla. Comment stocker de mani\u00e8re fiable et \u00e9conomique des p\u00e9taoctets de donn\u00e9es historiques ? Est-il possible de le faire sans compromettre le temps de r\u00e9ponse des requ\u00eates ? Peut-on acc\u00e9der \u00e0 toutes les m\u00e9triques situ\u00e9es sur diff\u00e9rents serveurs Prometheus via une seule requ\u00eate API ? Est-il possible de regrouper d'une mani\u00e8re ou d'une autre les donn\u00e9es r\u00e9pliqu\u00e9es collect\u00e9es via Prometheus HA ?<\/p>\n

Pour r\u00e9pondre \u00e0 ces questions, nous avons cr\u00e9\u00e9 Thanos. Dans les sections suivantes, nous d\u00e9crivons comment nous avons abord\u00e9 ces probl\u00e8mes et expliquons les objectifs que nous avons poursuivis.<\/p>\n

Requ\u00eate de donn\u00e9es \u00e0 partir de plusieurs instances Prometheus (requ\u00eate globale)<\/h4>\n

\nPrometheus propose une approche fonctionnelle pour le sharding. M\u00eame un serveur Prometheus fournit une \u00e9chelle suffisante pour lib\u00e9rer les utilisateurs des complexit\u00e9s du sharding horizontal dans presque tous les cas d'utilisation.<\/p>\n

Bien que ce soit un excellent mod\u00e8le de d\u00e9ploiement, il est souvent n\u00e9cessaire d'acc\u00e9der aux donn\u00e9es sur diff\u00e9rents serveurs Prometheus via une seule API ou une interface utilisateur \u2014 une vue globale. Bien s\u00fbr, il est possible d'afficher plusieurs requ\u00eates dans un m\u00eame tableau de bord Grafana, mais chaque requ\u00eate ne peut \u00eatre effectu\u00e9e que sur un seul serveur Prometheus. D'autre part, gr\u00e2ce \u00e0 Thanos, vous pouvez interroger et agr\u00e9ger des donn\u00e9es de plusieurs serveurs Prometheus, puisque tous sont accessibles \u00e0 partir d'un seul point de terminaison.<\/p>\n

Auparavant, pour obtenir une vue globale chez Improbable, nous organisions nos instances Prometheus en une architecture multicouche. F\u00e9d\u00e9ration Hi\u00e9rarchique<\/a><\/noindex>. Cela signifiait cr\u00e9er un m\u00e9ta-serveur Prometheus qui collecte une partie des m\u00e9triques de chaque serveur \u00ab feuille \u00bb.<\/p>\n

\"Thanos
\n
\nCette approche s'est r\u00e9v\u00e9l\u00e9e probl\u00e9matique. Elle a entra\u00een\u00e9 une complexit\u00e9 accrue de la configuration, l'ajout d'un point de d\u00e9faillance potentiel suppl\u00e9mentaire et l'application de r\u00e8gles complexes pour fournir \u00e0 la fin des requ\u00eates f\u00e9d\u00e9r\u00e9es uniquement les donn\u00e9es n\u00e9cessaires. De plus, une f\u00e9d\u00e9ration de ce type n'offre pas de v\u00e9ritable vue globale, car toutes les donn\u00e9es ne sont pas accessibles par une seule requ\u00eate API.<\/p>\n

Cela est \u00e9troitement li\u00e9 \u00e0 une vue unifi\u00e9e des donn\u00e9es collect\u00e9es sur des serveurs Prometheus \u00e0 haute disponibilit\u00e9 (high-availability, HA). Le mod\u00e8le HA de Prometheus collecte ind\u00e9pendamment les donn\u00e9es deux fois, ce qui est si simple que cela ne peut pas \u00eatre plus facile. Cependant, utiliser une vue combin\u00e9e et d\u00e9dupliqu\u00e9e des deux flux serait beaucoup plus pratique.<\/p>\n

Bien s\u00fbr, il y a un besoin pour des serveurs Prometheus \u00e0 haute disponibilit\u00e9. Chez Improbable, nous prenons tr\u00e8s au s\u00e9rieux la surveillance des donn\u00e9es minute par minute, mais avoir une seule instance de Prometheus dans un cluster constitue un point de d\u00e9faillance unique. Toute erreur de configuration ou panne mat\u00e9rielle peut potentiellement entra\u00eener la perte de donn\u00e9es importantes. M\u00eame un simple d\u00e9ploiement peut provoquer de l\u00e9gers \u00e9checs dans la collecte des m\u00e9triques, car un red\u00e9marrage peut \u00eatre consid\u00e9rablement plus long que l'intervalle de scraping.<\/p>\n

Stockage fiable des donn\u00e9es historiques<\/h4>\n

\nUn stockage de m\u00e9triques bon march\u00e9, rapide et \u00e0 long terme est notre r\u00eave (partag\u00e9 par la plupart des utilisateurs de Prometheus). Chez Improbable, nous avons \u00e9t\u00e9 contraints de configurer la dur\u00e9e de stockage des m\u00e9triques \u00e0 neuf jours (pour Prometheus 1.8). Cela impose des limites claires \u00e0 la r\u00e9troactivit\u00e9 de nos analyses.<\/p>\n

Prometheus 2.0 s'est am\u00e9lior\u00e9 \u00e0 cet \u00e9gard, car le nombre de s\u00e9ries temporelles n'influence plus la performance globale du serveur (voir la keynote de KubeCon sur Prometheus 2<\/a><\/noindex>). Cependant, Prometheus stocke les donn\u00e9es sur un disque local. Bien qu'une compression des donn\u00e9es tr\u00e8s efficace puisse consid\u00e9rablement r\u00e9duire l'utilisation d'un SSD local, il existe quand m\u00eame une limite sur la quantit\u00e9 de donn\u00e9es historiques pouvant \u00eatre conserv\u00e9e.<\/p>\n

De plus, chez Improbable, nous nous soucions de la fiabilit\u00e9, de la simplicit\u00e9 et des co\u00fbts. Les grands disques locaux sont plus difficiles \u00e0 g\u00e9rer et \u00e0 sauvegarder. Ils sont plus co\u00fbteux et n\u00e9cessitent plus d'outils de sauvegarde, ce qui entra\u00eene une complexit\u00e9 excessive.<\/p>\n

R\u00e9duction d'\u00e9chantillonnage<\/h4>\n

\nD\u00e8s que nous avons commenc\u00e9 \u00e0 travailler avec des donn\u00e9es historiques, nous avons r\u00e9alis\u00e9 qu'il existait des complexit\u00e9s fondamentales en O-grand, qui ralentissent de plus en plus les requ\u00eates lorsque nous travaillons avec des donn\u00e9es sur des semaines, mois et ann\u00e9es.<\/p>\n

La solution standard \u00e0 ce probl\u00e8me est la r\u00e9duction d'\u00e9chantillonnage<\/a><\/noindex> (downsampling) \u2014 r\u00e9duire la fr\u00e9quence d'\u00e9chantillonnage d'un signal. En abaissant la fr\u00e9quence d'\u00e9chantillonnage, nous pouvons \"redimensionner\" sur une plus grande plage temporelle tout en maintenant le m\u00eame nombre d'\u00e9chantillons, ce qui permet de garder les requ\u00eates r\u00e9actives.<\/p>\n

La r\u00e9duction d'\u00e9chantillonnage des anciennes donn\u00e9es est un besoin in\u00e9vitable de toute solution de stockage \u00e0 long terme et d\u00e9passe les capacit\u00e9s de Prometheus vanille.<\/p>\n

Objectifs suppl\u00e9mentaires<\/h4>\n

\nL'un des objectifs initiaux du projet Thanos \u00e9tait une int\u00e9gration sans faille avec toutes les installations existantes de Prometheus. Le deuxi\u00e8me objectif \u00e9tait une exploitation simple avec une barri\u00e8re d'entr\u00e9e minimale. Toutes les d\u00e9pendances doivent \u00eatre facilement satisfaites tant pour les petits que pour les grands utilisateurs, ce qui implique \u00e9galement un co\u00fbt de base faible.<\/p>\n

Architecture de Thanos<\/h2>\n

\nApr\u00e8s avoir \u00e9num\u00e9r\u00e9 nos objectifs dans la section pr\u00e9c\u00e9dente, travaillons \u00e0 leur r\u00e9alisation et voyons comment Thanos r\u00e9sout ces probl\u00e8mes.<\/p>\n

Vue globale<\/h4>\n

\nPour obtenir une vue globale au-dessus des instances existantes de Prometheus, nous devons relier un point d'entr\u00e9e unique pour toutes les requ\u00eates vers les serveurs. C'est exactement ce que fait le composant Thanos. Sidecar<\/a><\/noindex>. Il est d\u00e9ploy\u00e9 \u00e0 c\u00f4t\u00e9 de chaque serveur Prometheus et fonctionne comme un proxy, servant les donn\u00e9es locales de Prometheus via l'interface gRPC du Store API, permettant de s\u00e9lectionner des donn\u00e9es de s\u00e9ries temporelles par labels et plage temporelle.<\/p>\n

D'autre part, il y a le composant Querier, qui est \u00e9volutif horizontalement et sans \u00e9tat, et qui fait un peu plus que r\u00e9pondre aux requ\u00eates PromQL via l'API HTTP standard de Prometheus. Les composants Querier, Sidecar et d'autres de Thanos interagissent via le protocole gossip.<\/a><\/noindex>.<\/p>\n

\"Thanos
\n<\/p>\n

    \n
  1. Lorsqu'il re\u00e7oit une requ\u00eate, le Querier se connecte au serveur Store API correspondant, c'est-\u00e0-dire \u00e0 nos Sidecar, et r\u00e9cup\u00e8re les donn\u00e9es de s\u00e9ries temporelles des serveurs Prometheus appropri\u00e9s.<\/li>\n
  2. Ensuite, il fusionne les r\u00e9ponses et ex\u00e9cute la requ\u00eate PromQL. Le Querier peut fusionner des donn\u00e9es non chevauchantes ainsi que des donn\u00e9es dupliqu\u00e9es provenant des serveurs HA de Prometheus.<\/li>\n<\/ol>\n

    \nCela r\u00e9sout la plupart de notre casse-t\u00eate : la fusion des donn\u00e9es de serveurs Prometheus isol\u00e9s en une seule repr\u00e9sentation. En fait, Thanos peut \u00eatre utilis\u00e9 uniquement pour cette fonctionnalit\u00e9. Il n'est pas n\u00e9cessaire d'apporter des modifications aux serveurs Prometheus existants !<\/p>\n

    Dur\u00e9e de conservation illimit\u00e9e !<\/h4>\n

    \nCependant, t\u00f4t ou tard, nous voudrons conserver des donn\u00e9es qui d\u00e9passent la dur\u00e9e de conservation normale de Prometheus. Pour le stockage des donn\u00e9es historiques, nous avons choisi un stockage d'objets. Il est largement disponible dans n'importe quel cloud, ainsi que dans les centres de donn\u00e9es locaux, et est tr\u00e8s \u00e9conomique. De plus, presque n'importe quel stockage d'objets est accessible via le bien connu API S3.<\/p>\n

    Prometheus \u00e9crit les donn\u00e9es de la m\u00e9moire vive sur le disque environ toutes les deux heures. Un bloc de donn\u00e9es conserv\u00e9es contient toutes les donn\u00e9es d'une p\u00e9riode fixe et est immuable. C'est tr\u00e8s pratique, car Thanos Sidecar peut simplement consulter le r\u00e9pertoire des donn\u00e9es de Prometheus et, \u00e0 mesure que de nouveaux blocs apparaissent, les charger dans les buckets de stockage d'objets.<\/p>\n

    \"Thanos
    \n
    \nLe chargement vers le stockage d'objets imm\u00e9diatement apr\u00e8s l'\u00e9criture sur le disque permet \u00e9galement de maintenir la simplicit\u00e9 du \u00ab scrapeur \u00bb (Prometheus et Thanos Sidecar). Ce qui simplifie la maintenance, le co\u00fbt et la conception du syst\u00e8me.<\/p>\n

    Comme vous pouvez le voir, la sauvegarde des donn\u00e9es est mise en \u0153uvre tr\u00e8s simplement. Mais qu'en est-il de la requ\u00eate des donn\u00e9es dans le stockage d'objets ?<\/p>\n

    Le composant Thanos Store agit comme un proxy pour obtenir des donn\u00e9es depuis le stockage d'objets. Comme le Thanos Sidecar, il participe au cluster de gossip et impl\u00e9mente l'API Store. Ainsi, les Querier existants peuvent le consid\u00e9rer comme un Sidecar, comme une source suppl\u00e9mentaire de donn\u00e9es de s\u00e9ries temporelles \u2013 aucune configuration sp\u00e9ciale n'est requise.<\/p>\n

    \"Thanos
    \n
    \nLes blocs de donn\u00e9es de s\u00e9ries temporelles se composent de plusieurs gros fichiers. Les charger \u00e0 la demande serait assez inefficace, et la mise en cache locale n\u00e9cessiterait une \u00e9norme m\u00e9moire et un grand espace disque.<\/p>\n

    Au lieu de cela, le Store Gateway sait comment g\u00e9rer le format de stockage de Prometheus. Gr\u00e2ce \u00e0 un planificateur de requ\u00eates intelligent et \u00e0 la mise en cache uniquement des parties d'index n\u00e9cessaires des blocs, il est possible de r\u00e9duire les requ\u00eates complexes \u00e0 un minimum de requ\u00eates HTTP vers les fichiers de stockage d'objets. Ainsi, le nombre de requ\u00eates peut \u00eatre r\u00e9duit de quatre \u00e0 six ordres de grandeur et atteindre des temps de r\u00e9ponse qui sont g\u00e9n\u00e9ralement difficiles \u00e0 distinguer de ceux des requ\u00eates de donn\u00e9es sur SSD locaux.<\/p>\n

    \"Thanos
    \n
    \nComme l'illustre le diagramme ci-dessus, le Thanos Querier r\u00e9duit consid\u00e9rablement les co\u00fbts d'une requ\u00eate de donn\u00e9es dans le stockage d'objets en utilisant le format de stockage de Prometheus et en pla\u00e7ant les donn\u00e9es connexes pr\u00e8s les unes des autres. En utilisant cette approche, nous pouvons combiner de nombreuses requ\u00eates individuelles en un minimum d'op\u00e9rations en masse.<\/p>\n

    Consolidation et \u00e9chantillonnage descendant<\/h4>\n

    \nUne fois qu'un nouveau bloc de donn\u00e9es de s\u00e9ries temporelles est charg\u00e9 avec succ\u00e8s dans le stockage d'objets, nous le consid\u00e9rons comme des donn\u00e9es \u00ab historiques \u00bb qui deviennent imm\u00e9diatement accessibles via le Store Gateway.<\/p>\n

    Cependant, apr\u00e8s un certain temps, les blocs d'une seule source (Prometheus avec Sidecar) s'accumulent et n'exploitent plus pleinement le potentiel d'indexation. Pour r\u00e9soudre ce probl\u00e8me, nous avons introduit un autre composant appel\u00e9 Compactor. Il applique simplement le m\u00e9canisme de consolidation local de Prometheus aux donn\u00e9es historiques dans le stockage d'objets et peut \u00eatre ex\u00e9cut\u00e9 comme une simple t\u00e2che par lots p\u00e9riodiques.<\/p>\n

    \"Thanos
    \n
    \nGr\u00e2ce \u00e0 une compression efficace, les requ\u00eates de stockage \u00e0 long terme ne posent pas de probl\u00e8me en termes de taille des donn\u00e9es. Cependant, le co\u00fbt potentiel de d\u00e9compression d'un milliard de valeurs et de leur passage \u00e0 travers le processeur de requ\u00eates entra\u00eenera in\u00e9vitablement une augmentation rapide du temps d'ex\u00e9cution de la requ\u00eate. D'autre part, \u00e9tant donn\u00e9 que chaque pixel \u00e0 l'\u00e9cran correspond \u00e0 des centaines de points de donn\u00e9es, il devient impossible m\u00eame de visualiser les donn\u00e9es en pleine r\u00e9solution. Ainsi, le downsampling est non seulement possible, mais ne conduira pas \u00e0 une perte de pr\u00e9cision significative. <\/p>\n

    \"Thanos
    \n
    \nPour le downsampling des donn\u00e9es, le Compactor agr\u00e8ge en continu les donn\u00e9es avec une r\u00e9solution de cinq minutes et une heure. Pour chaque fragment brut, cod\u00e9 \u00e0 l'aide de la compression TSDB XOR, diff\u00e9rents types de donn\u00e9es agr\u00e9g\u00e9es sont stock\u00e9s, comme min, max ou sum pour un bloc donn\u00e9. Cela permet au Querier de choisir automatiquement l'agr\u00e9gat qui convient pour une requ\u00eate PromQL donn\u00e9e. <\/p>\n

    Pour utiliser des donn\u00e9es avec une pr\u00e9cision r\u00e9duite, l'utilisateur n'a besoin d'aucune configuration sp\u00e9ciale. Le Querier change automatiquement entre diff\u00e9rentes r\u00e9solutions et donn\u00e9es brutes \u00e0 mesure que l'utilisateur zoom ou d\u00e9zoom. Si d\u00e9sir\u00e9, l'utilisateur peut g\u00e9rer cela directement via le param\u00e8tre \u201cstep\u201d de la requ\u00eate. <\/p>\n

    \u00c9tant donn\u00e9 que le co\u00fbt de stockage d'un Go est faible, Thanos par d\u00e9faut conserve les donn\u00e9es brutes, ainsi que les donn\u00e9es avec une r\u00e9solution de cinq minutes et d'une heure. Il n'est pas n\u00e9cessaire de supprimer les donn\u00e9es brutes.<\/p>\n

    R\u00e8gles d'enregistrement<\/h2>\n

    \nM\u00eame avec Thanos, les r\u00e8gles d'enregistrement sont une partie essentielle de la pile de surveillance. Elles r\u00e9duisent la complexit\u00e9, la latence et le co\u00fbt des requ\u00eates. Elles sont \u00e9galement pratiques pour les utilisateurs souhaitant obtenir des donn\u00e9es agr\u00e9g\u00e9es sur les m\u00e9triques. Thanos est bas\u00e9 sur des instances vanilla de Prometheus, donc il est tout \u00e0 fait acceptable de stocker des r\u00e8gles d'enregistrement et des r\u00e8gles d'alerte sur un serveur Prometheus existant. Cependant, dans certains cas, cela peut ne pas suffire :<\/p>\n