🧑🏿 👋🏿 👨🏻‍🚒 Thanos - Prométhée évolutif 📼 👩🏿‍💻 🎙️

La traduction de l'article a été préparée spécialement pour les étudiants du cours "DevOps Practices and Tools" .

(Fabian Reinartz) — , Go . Prometheus Kubernetes SIG instrumentation. production- SoundCloud CoreOS. Google.

(Bartek Plotka) — Improbable. . Intel, Mesos production- SRE Improbable. . : Golang, open source .

En regardant notre produit phare SpatialOS, vous pouvez deviner qu'Improbable a besoin d'une infrastructure cloud mondiale hautement dynamique avec des dizaines de clusters Kubernetes. Nous avons été l'un des premiers à utiliser le système de surveillance Prometheus . Prometheus est capable de suivre des millions de métriques en temps réel et est livré avec un langage de requête puissant pour récupérer les informations nécessaires.

Simplicité et fiabilité Prometheus est l'un de ses principaux avantages. Cependant, ayant dépassé une certaine échelle, nous avons rencontré plusieurs inconvénients. Pour résoudre ces problèmes, nous avons développé Thanos- Un projet open source créé par Improbable pour transformer en toute transparence les clusters Prometheus existants en un système de surveillance unique avec un référentiel illimité de données historiques. Thanos est disponible sur github ici .

Restez à jour avec les dernières nouvelles d'Improbable.

Nos objectifs avec Thanos

À une certaine échelle, des problèmes surgissent qui dépassent les capacités du vanille Prométhée. Comment stocker de manière fiable et économique des pétaoctets de données historiques? Peut-on le faire sans préjudice du délai de réponse à la demande? Est-il possible d'accéder à toutes les métriques situées sur différents serveurs Prometheus avec une seule demande d'API? Est-il possible de combiner en quelque sorte les données répliquées collectées à l'aide de Prometheus HA?

Pour résoudre ces problèmes, nous avons créé Thanos. Les sections suivantes décrivent comment nous avons abordé ces questions et expliqué les objectifs que nous avons poursuivis.

Interrogation de données à partir de plusieurs instances de Prométhée (requête globale)

Prometheus propose une approche fonctionnelle du sharding. Un seul serveur Prometheus offre une évolutivité suffisante pour libérer les utilisateurs des difficultés de partage horizontal dans presque tous les cas d'utilisation.

Bien qu'il s'agisse d'un excellent modèle de déploiement, il est souvent nécessaire d'accéder aux données sur différents serveurs Prometheus via une seule API ou UI - vue globale. Bien sûr, il est possible d'afficher plusieurs requêtes dans un panneau Grafana, mais chaque requête ne peut être exécutée que sur un serveur Prometheus. Avec Thanos, d'autre part, vous pouvez interroger et agréger les données de plusieurs serveurs Prometheus, car ils sont tous accessibles à partir d'un point de terminaison.

Auparavant, pour obtenir une vue globale d'Improbable, nous avons organisé nos instances Prometheus en plusieurs niveauxFédération hiérarchique . Cela signifiait créer un méta-serveur Prometheus qui collecte une partie des métriques de chaque serveur feuille,

ce qui s'est avéré problématique, compliquant la configuration, ajoutant un point de défaillance potentiel supplémentaire et appliquant des règles complexes pour fournir au point de terminaison fédéré les bonnes données. De plus, une telle fédération ne vous permet pas d'obtenir une véritable vue globale, car toutes les données ne sont pas accessibles à partir d'une seule demande d'API.

La présentation unique des données collectées sur les serveurs haute disponibilité (HA) de Prometheus est étroitement liée à cela. Le modèle Prometheus HA collecte indépendamment les données deux fois, ce qui est si simple qu'il ne pourrait pas être plus simple. Cependant, l'utilisation d'une représentation combinée et dédupliquée des deux threads serait beaucoup plus pratique.

Bien sûr, il existe un besoin de serveurs Prometheus hautement disponibles. Chez Improbable, nous tenons vraiment à surveiller les données chaque minute, mais avoir une instance de Prometheus par cluster est un point de défaillance unique. Toute erreur de configuration ou défaillance matérielle peut potentiellement entraîner la perte de données importantes. Même les déploiements simples peuvent entraîner des problèmes mineurs dans la collecte des mesures, car le redémarrage peut être considérablement plus long que l'intervalle de raclage.

Stockage fiable des données historiques

Le stockage de métriques bon marché, rapide et à long terme est notre rêve (partagé par la plupart des utilisateurs de Prometheus). Dans Improbable, nous avons été obligés de définir la période de stockage des métriques sur neuf jours (pour Prometheus 1.8). Cela ajoute des limites évidentes à jusqu'où nous pouvons regarder en arrière.

Prometheus 2.0 est meilleur à cet égard, car le nombre de séries chronologiques n'affecte plus les performances globales du serveur (voir le discours KubeCon sur Prometheus 2 ). Cependant, Prometheus stocke les données sur un disque local. Bien que la compression de données très efficace puisse réduire considérablement l'utilisation d'un SSD local, il existe toujours une limitation de la quantité de données historiques enregistrées.

Chez Improbable, nous nous soucions également de la fiabilité, de la simplicité et du coût. Les gros disques locaux sont plus difficiles à utiliser et à sauvegarder. Ils sont plus chers et nécessitent davantage d'outils de sauvegarde, ce qui entraîne une complexité inutile.

Sous-échantillonnage

Dès que nous avons commencé à travailler avec des données historiques, nous avons réalisé qu'il existe des difficultés fondamentales avec O-big qui rendent les requêtes de plus en plus lentes si nous travaillons avec des données pendant des semaines, des mois et des années.

Une solution standard à ce problème sera le sous- échantillonnage - sous-échantillonnage du signal. Par sous-échantillonnage, nous pouvons «réduire» à une plus grande plage de temps et maintenir le même nombre d'échantillons, ce qui nous permet de maintenir la réactivité des demandes.

Le sous-échantillonnage des anciennes données est une exigence inévitable de toute solution de stockage à long terme et va au-delà de Prometheus vanille.

Objectifs supplémentaires

L'un des objectifs initiaux du projet Thanos était de s'intégrer de manière transparente à toutes les installations Prometheus existantes. Le deuxième objectif était une opération simple avec une barrière d'entrée minimale. Toutes les dépendances doivent être facilement satisfaites pour les petits et les grands utilisateurs, ce qui implique également un faible coût de base.

Architecture de Thanos

Une fois nos objectifs répertoriés dans la section précédente, travaillons dessus et voyons comment Thanos résout ces problèmes.

Vue globale

Pour obtenir une vue globale sur les instances existantes de Prometheus, nous devons associer un point d'entrée de demande unique à tous les serveurs. C'est exactement ce que fait le composant Thanos Sidecar . Il est déployé à côté de chaque serveur Prometheus et agit comme un proxy, servant les données Prometheus locales via l'interface gRPC du magasin, vous permettant de sélectionner des données de séries chronologiques par étiquette et plage de temps.

D'un autre côté, il existe un composant Querier sans état évolutif horizontalement qui fait un peu plus que simplement répondre aux requêtes PromQL via l'API HTTP Prometheus standard. Les composants Querier, Sidecar et autres Thanos communiquent via le protocole Gossip .

Querier, à la réception de la demande, se connecte au serveur API Store correspondant, c'est-à-dire à notre Sidecar, et reçoit les données de séries chronologiques des serveurs Prometheus correspondants.
Après cela, il combine les réponses et effectue une requête PromQL sur celles-ci. Querier peut combiner des données disjointes et des données en double provenant des serveurs Prometheus HA.

Cela résout l'essentiel de notre casse-tête: combiner les données de serveurs Prometheus isolés en une seule vue. En fait, Thanos ne peut être utilisé que pour cette opportunité. Les serveurs Prometheus existants ne nécessitent aucune modification!

Durée de conservation illimitée!

Cependant, tôt ou tard, nous voudrons enregistrer des données qui dépassent la durée de stockage normale de Prometheus. Pour stocker des données historiques, nous avons choisi le stockage d'objets. Il est largement disponible dans n'importe quel cloud, ainsi que dans les centres de données locaux et est très économique. De plus, presque n'importe quel stockage d'objets est accessible via l'API S3 bien connue.

Prometheus écrit des données de la RAM sur le disque toutes les deux heures environ. Le bloc de données stockées contient toutes les données pour une période de temps fixe et est immuable. C'est très pratique, car Thanos Sidecar peut simplement consulter le catalogue de données Prometheus et, à mesure que de nouveaux blocs apparaissent, les charger dans les compartiments de stockage d'objets.

Le téléchargement sur le stockage de l'objet immédiatement après l'écriture sur un disque vous permet également de garder simple la simplicité d'un «grattoir» (Prométhée et Thanos Sidecar). Ce qui simplifie le support, le coût et la conception du système.

Comme vous pouvez le voir, la sauvegarde des données est très simple. Mais qu'en est-il de la requête de données dans le stockage d'objets?

Le composant Thanos Store agit comme un proxy pour récupérer les données du stockage d'objets. Comme Thanos Sidecar, il participe au cluster de potins et implémente l'API Store. Ainsi, Querier existant peut le considérer comme Sidecar, comme une autre source de données de séries chronologiques - aucune configuration spéciale n'est requise.

Les blocs de données de séries chronologiques sont constitués de plusieurs fichiers volumineux. Les télécharger à la demande serait assez inefficace et la mise en cache locale nécessitait une mémoire et un espace disque énormes.

Au lieu de cela, Store Gateway sait comment gérer le format de stockage Prometheus. Grâce au planificateur de requêtes intelligent et à la mise en cache uniquement des parties d'index nécessaires des blocs, il est devenu possible de réduire les requêtes complexes au nombre minimal de requêtes HTTP pour les fichiers de stockage d'objets. Ainsi, il est possible de réduire le nombre de demandes de quatre à six ordres de grandeur et d'obtenir des temps de réponse généralement difficiles à distinguer des demandes de données sur un SSD local.

Comme le montre le diagramme ci-dessus, Thanos Querier réduit considérablement le coût d'une seule demande de données dans le stockage d'objets en utilisant le format de stockage Prometheus et en plaçant les données associées côte à côte. En utilisant cette approche, nous pouvons combiner de nombreuses requêtes uniques en un nombre minimum d'opérations en bloc.

Compactage et sous-échantillonnage

Une fois que le nouveau bloc de données de série chronologique a été chargé avec succès dans le stockage d'objets, nous le considérons comme des données «historiques» qui deviennent immédiatement disponibles via Store Gateway.

Cependant, après un certain temps, les blocs d'une seule source (Prométhée avec Sidecar) s'accumulent et n'utilisent plus le plein potentiel d'indexation. Pour résoudre ce problème, nous avons introduit un autre composant appelé Compacteur. Il applique simplement le mécanisme de compactage Prometheus local aux données historiques dans le magasin d'objets et peut être exécuté comme un travail par lots périodique simple.

Grâce à une compression efficace, une requête dans le référentiel pendant une longue période ne présente pas de problèmes en termes de taille des données. Cependant, le coût potentiel du déballage d'un milliard de valeurs et de leur exécution via un processeur de requêtes entraînera inévitablement une forte augmentation du temps d'exécution des requêtes. D'un autre côté, comme il y a des centaines de points de données par pixel de l'écran, il devient même impossible de visualiser les données en pleine résolution. Ainsi, le sous-échantillonnage est non seulement possible, mais n'entraînera pas une perte notable de précision.

Pour le sous-échantillonnage des données, Compactor agrège en continu les données avec une résolution de cinq minutes et une heure. Pour chaque fragment brut codé à l'aide de la compression TSDB XOR, différents types de données agrégées sont stockées, telles que min, max ou sum pour un bloc. Cela permet à Querier de sélectionner automatiquement l'agrégat qui convient à cette requête PromQL.

Pour utiliser les données avec une précision réduite, l'utilisateur n'a besoin d'aucune configuration spéciale. Querier bascule automatiquement entre différentes résolutions et données brutes lorsque l'utilisateur effectue un zoom avant ou arrière. Si vous le souhaitez, l'utilisateur peut le contrôler directement via le paramètre «step» dans la demande.

Étant donné que le coût de stockage d'un Go est faible, Thanos enregistre par défaut les données d'origine, des données avec une résolution de cinq minutes et une heure. Il n'est pas nécessaire de supprimer les données d'origine.

Règles d'enregistrement

Même avec Thanos, les règles d'enregistrement sont un élément essentiel de la pile de surveillance. Ils réduisent la complexité, la latence et le coût des demandes. Ils permettent également aux utilisateurs d'obtenir des données métriques agrégées. Thanos est basé sur des instances vanille de Prometheus, il est donc parfaitement acceptable de stocker des règles d'enregistrement et des règles d'alerte sur un serveur Prometheus existant. Cependant, dans certains cas, cela peut ne pas être suffisant:

Alertes et règles globales (par exemple, alertes lorsqu'un service est en panne sur plus de deux des trois clusters).
Règle pour les données en dehors du stockage local.
Le désir de garder toutes les règles et d'alerte en un seul endroit.

Pour tous ces cas, Thanos comprend un composant distinct appelé Règle, qui calcule la règle et alerte via les requêtes Thanos. En fournissant le StoreAPI bien connu, le nœud Query peut accéder à des métriques fraîchement calculées. Plus tard, ils sont également stockés dans le stockage d'objets et mis à disposition via Store Gateway.

Le pouvoir de Thanos

Thanos est suffisamment flexible pour être personnalisé selon vos besoins. Cela est particulièrement utile lors de la migration à partir d'un simple Prométhée. Jetons un coup d'œil à ce que nous avons appris sur les composants de Thanos. Voici comment transférer votre Prometheus vanille dans le monde du «stockage de métriques illimité»:

Ajoutez Thanos Sidecar à vos serveurs Prometheus - par exemple, le conteneur adjacent dans le module Kubernetes.
Développez plusieurs répliques Thanos Querier pour afficher les données. À ce stade, il est facile de configurer les ragots entre Scraper et Querier. Utilisez la métrique 'thanos_cluster_members' pour tester les interactions des composants.

Seules ces deux étapes sont suffisantes pour fournir une vue globale et une déduplication transparente des données à partir des réplicas potentiels de Prometheus HA! Connectez simplement vos tableaux de bord au point de terminaison HTTP Querier ou utilisez directement l'interface utilisateur de Thanos.

Cependant, si vous devez sauvegarder des métriques et un stockage à long terme, vous devrez effectuer trois étapes supplémentaires:

Créez un compartiment AWS S3 ou GCS. Configurez Sidecar pour copier les données dans ces compartiments. Vous pouvez désormais minimiser le stockage de données local.
Développez Store Gateway et connectez-le à un cluster de potins existant. Vous pouvez maintenant envoyer des demandes de données dans des sauvegardes!
Déployez Compactor pour améliorer les performances des requêtes sur de longues périodes en utilisant le compactage et le sous-échantillonnage.

Si vous voulez en savoir plus, n'hésitez pas à regarder nos exemples de kubernetes manifestes et à commencer !

En cinq étapes seulement, nous avons transformé Prometheus en un système de surveillance fiable avec une vue globale, un temps de stockage illimité et une haute disponibilité potentielle des métriques.

Tirez la demande: nous avons besoin de vous!

Thanos était un projet open source depuis le début. L'intégration transparente avec Prometheus et la possibilité d'utiliser uniquement une partie de Thanos en font un excellent choix pour faire évoluer un système de surveillance sans effort supplémentaire.

Nous accueillons toujours les demandes et problèmes GitHub Pull. Dans le même temps, n'hésitez pas à nous contacter via Github Issues ou relâchez Improbable-fra #thanos si vous avez des questions ou des commentaires, ou si vous souhaitez partager votre expérience! Si vous aimez ce que nous faisons chez Improbable, n'hésitez pas à nous contacter - nous avons toujours des postes vacants !

En savoir plus sur le cours.

Thanos - Prométhée évolutif