Avec le développement et la croissance continus des entreprises, le nombre de serveurs en ligne augmente également, de sorte que la probabilité de défaillance des logiciels et du matériel d'entreprise augmentera également. Dans la situation ci-dessus, lorsque l'hôte ou l'application de l'entreprise est anormal, si l'entreprise ne dispose pas d'un système de surveillance relativement complet et puissant, cela entraînera l'interruption des activités de l'entreprise, et cette perte est énorme pour l'entreprise.

Auteur : Edward Li, ingénieur en développement Cloud Intelligence. Fort de plusieurs années d' expérience en exploitation et maintenance et Devops , il s'est engagé dans la recherche et la mise en œuvre de l'orientation cloud native .

Introduction à la surveillance

Avec l'avènement des microservices, les systèmes de surveillance sont devenus encore plus importants. Lorsque les développeurs écrivent un programme à relativement petite échelle, ils choisiront d'écrire un script ou un petit programme de surveillance ; lorsque l'échelle d'application de service d'une entreprise est relativement importante, une solution de surveillance commerciale adaptée à son propre système d'entreprise sera adoptée. . Cloud Wisdom est l'un des principaux fournisseurs de solutions complètes d'exploitation et de maintenance intelligentes pour les entreprises en Chine, et ses produits incluent le trésor de surveillance, le trésor de perspective et d'autres logiciels d'entreprise. De plus, certaines entreprises choisiront des solutions de surveillance open source, telles que Zabbix, Prometheus, etc. Dans cet article, nous expliquerons comment choisir une solution de surveillance appropriée à l'ère du cloud natif.

Objectif de la surveillance

La mise en place d'un système de surveillance sonore peut atteindre les objectifs suivants :

Alarme : lorsque le système se produit ou est sur le point de tomber en panne, le système de surveillance doit réagir rapidement et informer l'administrateur, afin que le problème puisse être traité rapidement ou que l'apparition du problème puisse être prévenue à l'avance pour éviter l'impact sur le des affaires;
Analyse des tendances à long terme : effectuer une analyse des tendances à long terme des indicateurs de suivi grâce à la collecte continue et aux statistiques des données d'échantillonnage de suivi ;
Analyse comparative : Quelle est la différence dans l'utilisation des ressources d'exploitation des deux versions du système ? Comment la simultanéité et la charge du système varient-elles avec différentes capacités ? Grâce à la surveillance, le système peut être facilement suivi et comparé ;
Analyse et localisation des défauts : Lorsqu'un problème survient, le problème doit être étudié et traité. Grâce à l'analyse de différentes données de surveillance et historiques, la cause profonde peut être trouvée et résolue ;
Visualisation des données : grâce au tableau de bord visuel, vous pouvez obtenir directement des informations intuitives telles que l'état de fonctionnement du système, l'utilisation des ressources et l'état de fonctionnement du service.

dimensions de la surveillance

Les dimensions du suivi comprennent principalement les aspects suivants :

Couche réseau : comprenant la surveillance des protocoles réseau (http, dns, tcp, icmp) et du matériel réseau (routeurs, commutateurs, etc.) ;
Couche hôte : surveille principalement l'utilisation des ressources telles que le processeur, le MEM et le stockage ;
Couche conteneur : surveille principalement l'utilisation du processeur, du MEM, du stockage et d'autres ressources ;
Couche d'application : surveillance principalement du retard, de l'erreur, du QPS, de l'état interne, etc. ;
Couche middleware : surveille principalement l'utilisation des ressources et l'état du service ;
Couche d'outils d'orchestration : surveille principalement l'utilisation des ressources du cluster, la planification, etc.

Quatre indicateurs de surveillance de l'or

Golden Signals est un résumé de l'expérience de Google dans un grand nombre de surveillance distribuée. Les quatre indicateurs dorés peuvent aider à mesurer des problèmes tels que l'expérience de l'utilisateur final, l'interruption de service et l'impact commercial au niveau du service. L'accent est mis sur les quatre types de métriques suivants : latence, trafic, erreurs et saturation :

Latence : le temps nécessaire pour traiter une demande. Enregistrer le temps nécessaire pour toutes les demandes de l'utilisateur, en mettant l'accent sur la distinction entre le temps de retard d'une demande réussie et le temps de retard d'une demande échouée ;
Trafic : surveille le trafic système actuel pour mesurer les besoins en capacité du service. Le trafic peut signifier différentes choses pour différents types de systèmes. Par exemple, dans une API REST HTTP, le trafic correspond généralement aux requêtes HTTP par seconde ;
Erreurs : surveillez toutes les demandes d'erreur qui se produisent dans le système actuel et mesurez la fréquence à laquelle les erreurs se produisent dans le système actuel. Certains des échecs sont explicites (par exemple, l'erreur HTTP 500) et d'autres sont implicites (par exemple, la réponse HTTP 200, mais le processus métier réel a quand même échoué). Pour certaines exceptions à l'intérieur du système, vous devrez peut-être ajouter des statistiques de hook directement à partir du service et les obtenir ;
Saturation : mesure la saturation du service actuel. L'accent est mis sur les ressources limitées qui affectent le plus l'état du service. Car généralement, lorsque ces ressources sont saturées, les performances du service chutent de manière significative. Dans le même temps, la saturation peut également être utilisée pour faire des prédictions sur le système. Par exemple, "Le disque est-il susceptible d'être plein dans 4 heures".

Système de surveillance Prometheus

Prometheus est une solution de surveillance open source et un cadre de surveillance et d'alerte de système open source. Utilisé pour collecter et agréger des métriques sous forme de données de séries chronologiques, développé en tant que projet open source communautaire et officiellement publié en 2015.

Avantages de Prometheus

Halo natif du cloud : il est compatible avec la prise en charge de Kubernetes (tendance). Comme Kubernetes a établi une position de leader dans la planification et la gestion des conteneurs, Prometheus est également devenu la norme pour la surveillance des conteneurs Kubernetes ;
Langage de requête puissant : Prometheus intègre un puissant langage de requête de données PromQL. La requête et l'agrégation des données de surveillance peuvent être réalisées via PromQL. Dans le même temps, PromQL est également utilisé dans la visualisation de données (comme Grafana) et l'alerte ;
Mécanisme de découverte dynamique des services : Kubernetes, Consul, Etcd, etc. sont actuellement pris en charge, ce qui peut réduire la charge de travail de la configuration manuelle par le personnel d'exploitation et de maintenance (particulièrement important dans les environnements de conteneurs) ;
Extensible : partition fonctionnelle (sharding) + ensemble de fédération (fédération) extensible ;
Facile à intégrer : l'utilisation de Prometheus permet de créer rapidement des services de surveillance et peut être très pratique à intégrer dans l'application. Clients de collection riches (officiels, tiers, personnalisés) ;
Efficace et facile à gérer : le déploiement multiplateforme est compatible avec des millions de mesures de surveillance et des centaines de milliers de points de données par seconde.

Architecture Prométhée

Serveur Prometheus : la récupération récupère régulièrement des données de métriques à partir de cibles découvertes dynamiquement par le service via le serveur HTTP. Chaque cible de récupération doit exposer une interface de service HTTP (conforme à la spécification Prometheus) à récupérer régulièrement avec Prometheus. Les données de surveillance collectées sont conservées et stockées dans TSDB ;
Requête PromQL : vous pouvez utiliser PromQL pour interroger diverses données d'indicateur via Prometheus WebUi, Api Clients ou Grafana ;
Alarm push : envoie les alarmes qui dépassent le seuil après calcul à l'Alertmanager.Après nouveau regroupement, suppression et silence, l'Alertmanager les envoie vers un canal d'alarme plus riche ;
Cible de collecte : la cible collectée peut être soit une variété d'exportateurs officiels, soit une interface tierce qui implémente la spécification Prometheus (telle que l'interface de métriques de Nacos et Arrangodb), telle que PushGateway, etc.

Type d'indicateur

Compteur : un compteur qui ne fait qu'incrémenter et ne décrémente pas, utile pour stocker des informations telles que le nombre de requêtes HTTP servies ou le temps CPU utilisé ;
Jauge : un tableau de bord qui peut être augmenté ou diminué, cet indicateur se concentre sur l'état actuel du système de réaction ;
Récapitulatif : le récapitulatif est utilisé pour enregistrer la taille moyenne d'un élément, peut-être le temps de calcul ou la taille du fichier traité. Le récapitulatif affiche deux informations liées : le nombre (le nombre de fois où l'événement s'est produit) et la somme. (la taille totale de tous les événements) ;
Histogramme : L'indicateur Histogramme reflète directement le nombre d'échantillons dans différents intervalles, et l'intervalle est défini par l'étiquette le. Les histogrammes sont appelés histogrammes principaux ou histogrammes et sont principalement utilisés pour compter une distribution de valeurs d'indicateurs. Bucket : Définissez l'intervalle de l'axe horizontal, définissez uniquement la limite supérieure mais pas la limite inférieure. Il est principalement utilisé pour compter la distribution chronophage des requêtes.

Exportateur commun

Les exportateurs couramment utilisés dans la communauté comprennent principalement les éléments suivants :

Tâches et exemples

En ajoutant la configuration suivante dans le fichier de configuration prometheus.yml :

scrape_configs:
  - job_name: 'prometheus'
    static_configs:
      - targets: ['localhost:9090']

objectif de collecte

Prometheus prend déjà en charge plusieurs mécanismes intégrés de découverte de services. Les développeurs peuvent le configurer via la section scrape_config du fichier de configuration Prometheus. Prometheus mettra à jour en permanence la liste des cibles d'exploration dynamiques, arrêtera automatiquement l'exploration des anciennes instances et commencera à explorer les nouvelles instances. Prometheus est particulièrement adapté à une exécution sous le cluster Kubernetes et peut découvrir automatiquement les cibles de surveillance. Sous Kubernetes, Promethues prend principalement en charge 5 modes de découverte de services en s'intégrant à l'API Kubernetes, à savoir : Node, Service, Pod, Endpoints, Ingress.

Solution de surveillance de cluster Kubernetes

cAdvisor : cAdvisor est l'outil open source de surveillance des ressources et d'analyse des performances des conteneurs de Google. Il est spécialement conçu pour les conteneurs et prend en charge les conteneurs Docker. Il est actuellement intégré au composant kubelet.
kube-state-metrics : kube-state-metrics génère des métriques d'état sur les objets de ressource, tels que le déploiement, le nœud et le pod, en écoutant le serveur d'API. Il convient de noter que kube-state-metrics fournit simplement des données de métrique et ne les stocke pas. Ces données métriques, nous pouvons donc utiliser Prometheus pour récupérer ces données et les stocker. L'accent est mis sur certaines métadonnées liées à l'entreprise, telles que le déploiement, le pod, l'état de la réplique, etc.
metrics-server : metrics-server est également un outil d'agrégation de données de ressources à l'échelle du cluster, qui remplace Heapster. De même, metrics-server affiche uniquement les données et ne fournit pas de services de stockage de données. La principale préoccupation est la mise en œuvre d'API de mesure des ressources, telles que le processeur, les descripteurs de fichiers, la mémoire, la latence des requêtes et d'autres indicateurs.

Visualisation des données Grafana

Type de panneau de données

Séries chronologiques : visualisation des données de graphiques linéaires, en aires et à barres basés sur le temps ;
Diagramme à barres : visualisation de la classification des données ;
Stat : pour la visualisation des données liées aux statistiques de données ;
Jauge : une visualisation indiquant la valeur actuelle par rapport aux valeurs minimale et maximale ;
Tableau : le contenu des données est affiché dans la présentation du tableau ;
Graphique à secteurs : visualisation du panneau de graphique à secteurs ;
Heatmap : Affiche la distribution des valeurs.

Haute disponibilité Prometheus

Scénario de disponibilité

Dans Prometheus, lorsqu'une instance raccroche, elle est automatiquement supprimée du LB, et elle a également la fonction d'équilibrage de charge, ce qui peut réduire la pression sur Prometheus. Cependant, ce mode présente des lacunes évidentes, c'est-à-dire qu'il ne répond pas aux problèmes de cohérence et de persistance des données.Prometheus étant une méthode Pull, même si plusieurs instances capturent les mêmes indicateurs de surveillance, les valeurs capturées ne peuvent être garanties. cohérent. De plus, il y aura des problèmes de retard de réseau dans le processus d'utilisation réel, ce qui entraînera le problème de l'incohérence des données. Cependant, pour les scénarios de surveillance et d'alarme, une forte cohérence des données n'est généralement pas requise, cette méthode est donc acceptable d'un point de vue commercial. Le scénario de disponibilité Prometheus convient aux scénarios où l'échelle de surveillance n'est pas grande et où seules les données de surveillance à courte période doivent être enregistrées.

Scénario de persistance des données

Après avoir configuré le stockage distant pour Prometheus, vous n'avez plus à vous soucier de la perte de données. Même lorsqu'une instance Prometheus tombe en panne ou que des données sont perdues, elles peuvent être récupérées via les données stockées à distance.

cluster fédéré

Lorsqu'une seule instance Promthues ne peut pas gérer un grand nombre de tâches de collecte, les développeurs peuvent utiliser l'approche basée sur un cluster fédéré Prometheus pour diviser les tâches de surveillance en différentes instances Prometheus. Les développeurs peuvent diviser différents types de tâches de collecte en différentes instances Prometheus pour l'exécution et effectuer un sharding fonctionnel. Par exemple, un Prometheus est responsable de la collecte des données des indicateurs de nœud, un autre Prometheus est responsable de la collecte des données des indicateurs de surveillance liés à l'activité de l'application, et enfin le couche supérieure Les données sont agrégées via un Prometheus.

Il convient de noter que lorsque le nombre de cibles dans une même tâche de collecte est trop important, un partitionnement fonctionnel au niveau de l'instance peut être envisagé. Divisez les tâches de collecte de données de surveillance de différentes instances d'une tâche en différentes instances Prometheus.

Architecture haute disponibilité

Sidecar : connectez-vous à Prometheus et exposez Prometheus à la passerelle de requête (Querier/Query) pour une requête en temps réel, et chargez les données Prometheus sur le stockage cloud pour un stockage à long terme ;
Querier/Query : implémente l'API Prometheus et agrège les données des composants sous-jacents (tels que le composant sidecar Sidecar ou la passerelle de stockage Store Gateway) ;
Passerelle de magasin : exposez le contenu des données dans le stockage en nuage ;
Compacteur : compresse et sous-échantillonne les données dans le stockage en nuage ;
Règle : évaluer et alerter sur les données de surveillance.

Querier/Query : implémente l'API Prometheus et agrège les données des composants sous-jacents (tels que le composant sidecar Sidecar ou la passerelle de stockage Store Gateway) ;
Passerelle de magasin : exposez le contenu des données dans le stockage en nuage ;
Compacteur : compresse et sous-échantillonne les données dans le stockage en nuage ;
Récepteur : obtenez des données à partir du WAL d'écriture à distance de Prometheus (journal d'écriture anticipée à distance de Prometheus), exposez-les ou téléchargez-les sur le stockage en nuage ;
Règle : évaluer et alerter sur les données de surveillance

Avantages de Thanos

Thanos est une solution de supervision basée sur Prometheus avec des fonctions de haute disponibilité (HA), de persistance du stockage et de requête multi-cluster. Elle comprend principalement les avantages suivants :

Entrée de requête unifiée : en utilisant Querier comme entrée de requête unifiée, il implémente l'interface de requête de Prometheus et StoreAPI, et peut fournir des services de requête pour d'autres Queriers. Au cours de l'interrogation, il obtiendra des données d'indicateur de Sidecar et Store Gateway de chaque instance Prometheus. ;
Utilisation élevée de l'espace : chaque Prometheus lui-même ne stocke pas de données à long terme, et Sidecar téléchargera les blocs de données persistants de Prometheus dans le stockage d'objets. Le compacteur compressera régulièrement les données à long terme dans le stockage d'objets distants et les nettoiera en fonction du temps d'échantillonnage pour économiser de l'espace de stockage ;
Requête inter-cluster : lorsque vous devez combiner les résultats de la requête de plusieurs clusters, il vous suffit d'ajouter une autre couche de Querier au-dessus du Querier de chaque cluster. Ce type d'imbrication peut augmenter l'échelle du cluster sans limite ;
Expansion horizontale : lorsque la pression de collecte d'indicateurs de Prometheus est trop élevée, vous pouvez créer une nouvelle instance Prometheus, diviser le travail de grattage en plusieurs Prometheus, et Querier agrège les résultats de plusieurs requêtes Prometheus, réduisant ainsi la pression sur un seul Prometheus ;
Haute disponibilité : Querier est un service sans état qui prend en charge de manière inhérente la mise à l'échelle horizontale et la haute disponibilité. Store, Rule et Sidecar sont des services avec état, qui prennent également en charge la haute disponibilité dans le cas d'un déploiement à plusieurs copies, mais généreront une redondance des données et devront sacrifier l'espace de stockage ;
Déduplication de requête : chaque bloc de données aura une étiquette de cluster spécifique. Querier supprimera l'étiquette de cluster lors de l'interrogation et fusionnera les séquences avec le même nom d'index et la même étiquette en fonction de l'ordre chronologique. Bien que les données de l'indicateur proviennent de différentes sources de collecte, elles ne répondront qu'à un seul résultat au lieu de plusieurs répétitions.

Avantages de l'open source

Aujourd'hui, Cloud Wisdom dispose de la plate-forme d'orchestration de visualisation de données open source FlyFish. En configurant le modèle de données, il fournit aux utilisateurs des centaines de composants graphiques visuels, et le codage zéro peut obtenir un grand écran visuel cool qui répond à leurs propres besoins commerciaux. Dans le même temps, FlyFish fournit également des capacités d'extension flexibles, prend en charge le développement de composants, des fonctions personnalisées et des événements mondiaux et d'autres configurations, et peut assurer un développement et une livraison efficaces pour des scénarios de demande complexes.

Cliquez sur le lien d'adresse ci-dessous et invitez tout le monde à donner un like à FlyFish et à envoyer une étoile. Participez au développement des composants et plus de 10 000 yuans en espèces vous attendront.

Adresse GitHub : https://github.com/CloudWise-OpenSource/FlyFish

Adresse du gîte : https://gitee.com/CloudWise/fly-fish

Prestation en espèces de dix mille yuans : http://bbs.aiops.cloudwise.com/t/Activity

Scannez Wechat pour identifier le code QR ci-dessous, notez [Flying Fish] Rejoignez le groupe d'échange de développeurs Flying Fish de la communauté AIOps et communiquez en face à face avec le projet FlyFish PMC ~

À l'ère du cloud natif, comparaison des outils de surveillance populaires et analyse des scénarios d'utilisation