Aperçu
Pour les systèmes à mise à l'échelle élastique et à haute disponibilité, il y a généralement une grande quantité de données d'indicateurs qui doivent être collectées et stockées. Comment créer une solution de surveillance pour un tel système ? Cet article décrit comment créer un système de surveillance à l'aide de Thanos+Prometheus+Grafana.
Présentation de la capacité du cluster
Histoire de l'utilisateur
Jusqu'en janvier de cette année, je surveillais les clusters Kubernetes avec une solution de surveillance de niveau entreprise qui était également utilisée pour l'APM. Il semble naturel à utiliser, s'intègre très facilement à Kubernetes avec des ajustements mineurs et peut intégrer des métriques APM et d'infrastructure.
Bien que cette solution de surveillance puisse facilement collecter et stocker des données, l'utilisation de métriques pour créer des alertes présente des limitations importantes en matière de requêtes . Souvent, les alertes que nous recevons sont différentes de ce qui est affiché sur le tableau de bord. Sans oublier que nous avons 6 clusters et que le nombre de métriques collectées et stockées est très élevé, ce qui augmente notre coût économique dans une large mesure.
Après réflexion, nous nous sommes rendu compte que continuer à utiliser cette solution de monitoring ferait plus de mal que de bien. Il est temps de remplacer notre solution de surveillance ! Mais quel produit ou outil utiliser ? Grafana est la meilleure option pour les outils de visualisation , mais notre "backend" doit avoir une évolutivité élastique et une haute disponibilité. Quel outil devrions-nous utiliser ?
Si vous utilisez uniquement OpenTSDB, l'installation nécessite trop de travail et d'efforts ; Prometheus autonome ne fournit pas de capacités de réplication et vous devez l'équiper de plusieurs bases de données ; TimeScaleDB a l'air bien, mais je ne suis pas très doué pour utiliser PostgreSQL.
Après avoir expérimenté certaines des solutions ci-dessus, j'ai consulté le site Web de la CNCF et j'ai finalement trouvé Thanos ! Elle répond à tous nos besoins : rétention des données à long terme, réplicable, hautement disponible, adaptée aux microservices, a une vue globale de tous les clusters utilisant la même base de données !
architecture
Nous n'avons pas de stockage persistant disponible sur notre cluster (tous les services restent sans état), donc l'approche side-car Prometheus + Thanos par défaut n'est pas disponible et le stockage des métriques doit être placé en dehors du cluster. De plus, les clusters sont isolés les uns des autres, il n'est pas possible de lier les composants Thanos à un ensemble spécifique de clusters, et les clusters doivent être surveillés de "l'extérieur".
Pour résumer, compte tenu de la haute disponibilité et de la possibilité de faire tourner Thanos sur une machine virtuelle, notre architecture finale est la suivante :
Comme le montre la figure, nous avons une architecture multi-centre de données. Chacun de ces centres dispose d'un ensemble de serveurs Grafana + Query , d'un ensemble de serveurs de stockage et de trois serveurs de réception (la moitié du nombre de clusters).
La base de données utilisée par Grafana dispose également d'un AWS RDS. Cette base de données n'a pas besoin d'être énorme (pour réduire les coûts) et notre équipe n'a pas besoin de gérer MySQL.
Parmi tous les composants fournis par Thanos, nous en avons implémenté 4 :
-
Réception : responsable de TSDB, gère également la réplication entre tous les serveurs exécutant la réception et le téléchargement des blocs TSBD vers S3.
-
Query : responsable de l'interrogation de la base de données de réception.
-
Stocker : lit S3 pour les métriques à long terme qui ne sont plus stockées dans la réception.
-
Compactor : gère le sous-échantillonnage et la compression des données des blocs TSDB stockés dans S3.
intégration de données
L'ingestion de données pour tous les clusters est gérée par un pod Prometheus dédié exécuté au sein du cluster . Il collecte des métriques à partir de la plaque de contrôle (serveur d'API, contrôleur et planificateur), du cluster etcd et des pods au sein du cluster avec des métriques liées à l'infrastructure et à Kubernetes lui-même (Kube-proxy, Kubelet, Node Exporter, State Metrics, Metrics Server, et d'autres pods avec des annotations de grattage).
Le pod Prometheus envoie ensuite les informations à l'un des serveurs de réception qui gèrent la TSDB avec la configuration de stockage à distance.
ingestion de données
Toutes les données sont envoyées à un seul serveur, puis répliquées sur d'autres serveurs. L'adresse DNS utilisée par Prometheus est un GSLB DNS qui sonde chaque serveur de réception et équilibre la résolution DNS entre les serveurs sains, partageant la charge entre tous les serveurs car la résolution DNS ne fournit qu'une adresse IP pour chaque requête DNS.
Il convient de souligner que les données doivent être envoyées à une seule instance de réception et la laisser gérer la réplication, l'envoi de la même métrique entraînera l'échec et le mauvais comportement de la réplication .
À ce niveau, les métriques sont également chargées dans un compartiment S3 pour une conservation à long terme. Recevez des téléchargements d'un bloc toutes les 2 heures (lorsque chaque bloc TSDB est fermé), et ces métriques peuvent être utilisées pour les requêtes utilisant le composant Store.
Vous pouvez également définir la durée de conservation des données locales. Dans ce cas, toutes les données locales sont conservées pendant 30 jours pour une utilisation et un dépannage quotidiens, ce qui accélère les requêtes .
Les données de plus de 30 jours ne sont disponibles que sur S3 et sont conservées jusqu'à 1 an pour une évaluation et une comparaison à long terme.
requête de données
Les données sont collectées et stockées dans le récepteur pour interrogation. Cette partie est également configurée pour être disponible dans plusieurs centres de données.
Avec chaque serveur exécutant Grafana et Query, si l'un (ou les deux) tombe en panne, nous pouvons plus facilement l'identifier et le supprimer de l'équilibreur de charge. Dans Grafana, la source de données est configurée en tant qu'hôte local, elle utilise donc toujours la requête locale pour récupérer les données.
Pour la configuration des requêtes, il doit connaître tous les serveurs (Receiver et Store) qui stockent les métriques. Le composant de requête sait quels serveurs sont en ligne et peut collecter des métriques à partir d'eux.
requête de données
Il gère également la déduplication, puisqu'il interroge tous les serveurs et configure la réplication, toutes les métriques ont plusieurs copies. --query.replica-label=QUERY.REPLICA-LABELCela peut être fait à l'aide d'étiquettes et de paramètres de requête ( ) attribués aux métriques . Avec ces configurations, le composant de requête sait si les métriques collectées à partir de Receiver et Store sont dupliquées et utilise un seul point de données.
données à long terme
Comme mentionné précédemment, les données sont conservées localement jusqu'à 30 jours, tout le reste est stocké sur S3. Cela réduit la quantité d'espace requis sur le récepteur et réduit les coûts, car le stockage par blocs est plus coûteux que le stockage d'objets. Sans oublier que l'interrogation de données de plus de 30 jours n'est pas très courante et est principalement utilisée pour l'historique et les prévisions d'utilisation des ressources.
requête de données à distance
Le magasin conserve également une copie locale de l'index pour chaque bloc TSDB stocké sur le compartiment S3, donc s'il doit interroger plus de 30 jours de données, il sait quels blocs télécharger et utiliser pour servir les données.
État des données
Considérant tous les clusters, le schéma de suivi :
-
Surveillance de 6 clusters Kubernetes ;
-
Mesures collectées de 670 services ;
-
246 serveurs ont été surveillés à l'aide de Node Exporter ;
-
Collectez environ 27 w d'indicateurs par minute ;
-
Ingérez environ 7,3 Go de données par jour, soit environ 226,3 Go de données par mois ;
-
Création de 40 tableaux de bord dédiés pour les composants Kubernetes ;
-
116 alarmes sont créées sur Grafana.
Pour les frais mensuels, la plupart des composants fonctionnant sur site, le coût a été réduit de 90,61 % , passant de 38 421,25 USD à 3 608,99 USD par mois, ce qui inclut les coûts de service AWS.
Résumer
Il a fallu environ un mois pour configurer et mettre en place l'architecture ci-dessus, y compris tester d'autres solutions, valider l'architecture, mettre en œuvre, activer la collecte sur le cluster et créer tous les tableaux de bord.
Dans la première semaine, les avantages étaient évidents. La surveillance des clusters est devenue plus facile, les tableaux de bord peuvent être rapidement créés et personnalisés, la collecte des métriques est presque plug-and-play, la plupart des applications exportent les métriques au format Prometheus et les collectent automatiquement en fonction des annotations.
De plus, un contrôle plus fin des autorisations d'équipe peut être obtenu en intégrant le LDAP de Grafana. Les développeurs et les SRE ont accès à un grand nombre de tableaux de bord avec des métriques pertinentes sur leur espace de noms, leur entrée, etc.