La surveillance est devenue un élément très important des solutions cloud en pleine croissance à mesure que la complexité des systèmes distribués augmente. Il est nécessaire de comprendre leur comportement. Nous avons besoin d'outils évolutifs capables de collecter des données de tous les services et de fournir aux spécialistes une interface unique avec analyse des performances, démonstration des erreurs, disponibilité et journaux.
Ces mêmes outils doivent être efficaces et productifs. Dans cet article, nous examinerons deux piles technologiques populaires : EFK (Elasticsearch) et PLG (Loki) et examinerons leurs architectures et leurs différences.
Pile EFK
Vous avez peut-être déjà entendu parler des très populaires ELK ou EFK. La pile se compose de plusieurs parties distinctes : Elasticsearch (stockage d'objets), Logstash ou FluentD (collecte et agrégation de journaux) et Kibana pour la visualisation.
Un flux de travail typique ressemble à ceci :
ElasticSearch — stockage d'objets distribués avec recherche et analyse en temps réel. Excellente solution pour les données semi-structurées telles que les journaux. Les informations sont enregistrées sous forme de documents JSON, indexées en temps réel et distribuées sur les nœuds du cluster. Un index inversé est utilisé, contenant tous les mots uniques et les documents associés pour la recherche en texte intégral, qui à son tour est basée sur le moteur de recherche Apache Lucene.
CourantD est un collecteur de données qui unifie les données lors de leur collecte et de leur consommation. Il essaie d'organiser les données en JSON autant que possible. Son architecture est extensible, il y en a plus , soutenu par la communauté, pour toutes les occasions.
Kibana - un outil de visualisation de données pour Elasticsearch doté de diverses fonctionnalités supplémentaires, par exemple l'analyse de séries chronologiques, l'analyse de graphiques, l'apprentissage automatique, etc.
Architecture de recherche élastique
Les données du cluster Elasticsearch sont stockées réparties sur tous ses nœuds. Un cluster se compose de plusieurs nœuds pour améliorer la disponibilité et la résilience. N'importe quel nœud peut remplir tous les rôles du cluster, mais dans les déploiements à grande échelle, les nœuds se voient généralement attribuer des tâches individuelles.
Types de nœuds de cluster :
- nœud maître - gère le cluster, au moins trois sont nécessaires, un est toujours actif ;
- nœud de données - stocke les données indexées et effectue diverses tâches avec elles ;
- Nœud d'ingestion - organise des pipelines pour transformer les données avant l'indexation ;
- nœud de coordination - acheminement des requêtes, réduction de la phase de traitement de recherche, coordination de l'indexation de masse ;
- nœud d'alerte : lancement de tâches d'alerte ;
- nœud d'apprentissage automatique - traitement des tâches d'apprentissage automatique.
Le diagramme ci-dessous montre comment les données sont stockées et répliquées sur les nœuds pour obtenir une plus grande disponibilité des données.
Les données de chaque réplique sont stockées dans un index inversé, le diagramme ci-dessous montre comment cela se produit :
Installation
Les détails peuvent être consultés , j'utiliserai le tableau de barre :
$ helm install efk-stack stable/elastic-stack --set logstash.enabled=false --set fluentd.enabled=true --set fluentd-elasticsPile PLG
Ne soyez pas surpris si vous ne trouvez pas cet acronyme, car il est mieux connu sous le nom de Grafana Loki. Quoi qu’il en soit, cette stack gagne en popularité car elle utilise des solutions techniques éprouvées. Vous avez peut-être déjà entendu parler de Grafana, un outil de visualisation populaire. Ses créateurs, inspirés par Prometheus, ont développé Loki, un système d'agrégation de journaux hautes performances, évolutif horizontalement. Loki indexe uniquement les métadonnées, pas les revues elles-mêmes, une solution technique qui lui permet d'être facile à utiliser et rentable.
Promtail - un agent d'envoi des logs du système d'exploitation vers le cluster Loki. grafana est un outil de visualisation basé sur les données de Loki.
Loki est construit sur les mêmes principes que Prometheus, ce qui le rend bien adapté au stockage et à l'analyse des journaux Kubernetes.
L'architecture de Loki
Loki peut être exécuté soit comme un seul processus, soit comme plusieurs processus, permettant une mise à l’échelle horizontale.
Il peut également fonctionner comme une application monolithique ou comme un microservice. L’exécution en tant que processus unique peut être utile pour le développement local ou pour un suivi mineur. Pour une mise en œuvre industrielle et une charge de travail évolutive, il est recommandé d’utiliser l’option microservice. Les chemins d'écriture et de lecture des données sont séparés, ce qui permet de les ajuster et de les mettre à l'échelle selon les besoins.
Regardons l'architecture du système de collecte de logs sans entrer dans les détails :
Et voici la description (architecture microservice) :
Composants:
Promtail — un agent installé sur les nœuds (en tant qu'ensemble de services), il supprime les journaux des tâches et accède à l'API Kubernetes pour obtenir des métadonnées qui baliseront les journaux. Il envoie ensuite le journal au service principal Loki. Le mappage des métadonnées prend en charge les mêmes règles de balisage que Prometheus.
Distributeurs — un distributeur de services qui fonctionne comme un tampon. Pour traiter des millions d'enregistrements, il regroupe les données entrantes et les compresse en blocs au fur et à mesure de leur arrivée. Plusieurs récepteurs de données s'exécutent simultanément, mais les journaux appartenant à un flux de données entrant ne doivent apparaître que dans l'un d'entre eux pour tous ses blocs. Ceci est organisé en un anneau de puits et de hachage séquentiel. Pour la tolérance aux pannes et la redondance, cela est effectué n fois (3 si non configuré).
Ingérer — récepteur de service. Les blocs de données arrivent compressés avec des journaux ajoutés. Une fois que le bloc a une taille suffisante, il est vidé dans la base de données. Les métadonnées vont à l'index et les données du bloc de journal vont aux morceaux (généralement un stockage d'objets). Après la réinitialisation, le récepteur crée un nouveau bloc dans lequel de nouvelles entrées seront ajoutées.
Sommaire - base de données, DynamoDB, Cassandra, Google BigTable, etc.
Morceaux — des blocs de journaux sous forme compressée, généralement stockés dans le stockage d'objets, par exemple S3.
Interrogateur - le chemin de lecture qui fait tout le sale boulot. Il examine la plage horaire et l'horodatage, puis examine l'index pour trouver des correspondances. Ensuite, il lit des blocs de données et les filtre pour obtenir le résultat.
Voyons maintenant tout en action.
Installation
Le moyen le plus simple d’installer dans Kubernetes est d’utiliser helm. Nous supposons que vous l'avez déjà installé et configuré ( environ. traducteur)
Ajoutez un référentiel et installez une pile.
$ helm repo add loki https://grafana.github.io/loki/charts
$ helm repo update
$ helm upgrade --install loki loki/loki-stack --set grafana.enabled=true,prometheus.enabled=true,prometheus.alertmanager.persistentVolume.enabled=false,prometheus.server.persistentVolume.enabled=falseVous trouverez ci-dessous un exemple de tableau de bord montrant les données des métriques Prometheus pour Etcd et des journaux de pod Loki pour Etcd.
Discutons maintenant de l'architecture des deux systèmes et comparons également leurs capacités entre elles.
Comparaison
Langage de requête
Elasticsearch utilise le langage de requête Query DSL et Lucene pour fournir des fonctionnalités de recherche en texte intégral. Il s’agit d’un moteur de recherche établi et puissant bénéficiant d’un large support d’opérateur. Avec lui, vous pouvez effectuer une recherche par contexte et trier par pertinence.
De l’autre côté de l’anneau se trouve LogQL, utilisé dans Loki, le successeur de PromQL (langage de requête Prometheus). Il utilise des balises de journal pour filtrer et sélectionner les données du journal. Il est possible d'utiliser certains opérateurs et arithmétiques comme décrit , mais en termes de fonctionnalités, il est en retard sur le langage Elastic.
Étant donné que les requêtes dans Loki sont associées à des balises, elles sont faciles à corréler avec les métriques et, par conséquent, il est plus facile d'organiser la surveillance opérationnelle avec elles.
Évolutivité
Les deux piles sont évolutives horizontalement, mais Loki facilite la tâche car il dispose de chemins de lecture et d'écriture séparés et d'une architecture de microservices. Loki peut être personnalisé en fonction de vos besoins et peut être utilisé pour de très gros volumes de données de journalisation.
Locations multiples
La multilocation de cluster est un thème commun dans l'abréviation OPEX, les deux piles fournissent la multilocation. Il en existe plusieurs pour Elasticsearch séparation des clients : index séparé pour chaque client, routage basé sur le client, champs client uniques, filtres de recherche. Loki a sous la forme d'un en-tête HTTP X-Scope-OrgID.
coût de
Loki est assez rentable car il n’indexe pas les données, uniquement les métadonnées. Cela permet d'obtenir et la mémoire (cache), car le stockage d'objets est moins cher que le stockage en bloc, utilisé dans les clusters Elasticsearch.
Conclusion
La pile EFK peut être utilisée à diverses fins, offrant une flexibilité maximale et une interface Kibana riche en fonctionnalités pour l'analyse, la visualisation et les requêtes. Il peut être encore amélioré grâce aux capacités d’apprentissage automatique.
La pile Loki est utile dans l'écosystème Kubernetes en raison de son mécanisme de découverte de métadonnées. Vous pouvez facilement corréler les données pour la surveillance en fonction des séries chronologiques dans Grafana et des journaux.
En ce qui concerne le coût et le stockage des journaux à long terme, Loki constitue un excellent point d'entrée dans les solutions cloud.
Il existe d’autres alternatives sur le marché – certaines pourraient être meilleures pour vous. Par exemple, GKE dispose d'une intégration Stackdriver qui fournit une excellente solution de surveillance. Nous ne les avons pas inclus dans notre analyse dans cet article.
Liens:
L'article a été traduit et préparé pour Habr par des employés — cours intensifs, cours vidéo et formations en entreprise dispensés par des spécialistes en exercice (Kubernetes, DevOps, Docker, Ansible, Ceph, SRE, Agile)
Source: habr.com