Observabilité des services pour Kubernetes avec Azure Arc

Article
07/11/2023

L’observabilité est une caractéristique d’application qui fait référence à la façon dont l’état interne d’un système peut être compris à partir de ses sorties externes. Nous mesurons les systèmes informatiques en observant le temps processeur, la mémoire, l’espace disque, la latence, les erreurs entre autres métriques. Plus un système est observable, plus il est facile pour nous de comprendre ce qu'il fait en l'observant.

L'observabilité d'un système a un effet important sur son coût d'exploitation. Les systèmes observables fournissent des données explicites et exploitables à leurs opérateurs, ce qui leur permet d'obtenir des résultats favorables et de réduire les temps d'arrêt. Plus d'informations ne se traduit pas nécessairement par un système plus observable. En fait, il arrive que la quantité d'informations générées par un système rende plus difficile l'identification des signaux d’intégrité utiles issus du bruit généré par l'application.

L’observabilité des services est importante, car elle vous aide à comprendre les performances et les problèmes des systèmes distribués et cloud basés sur des architectures dynamiques.

L’implémentation d’une solution pour obtenir une observabilité des services peut vous aider à :

Vous assurer que les utilisateurs finaux peuvent utiliser votre application et que vos attentes métier sont satisfaites.
Comprendre un système et comment il fonctionne ensemble à l’aide d’un volet unique.
Établir une base de référence pour votre système et comprenez comment différentes circonstances affectent ses performances.
Générer des éléments d’action à partir de scénarios et de comportements inattendus.

Kubernetes avec Azure Arc fournit deux options d’extension intégrées pour vous aider à obtenir l’observabilité des services : le Open Service Mesh et la passerelle Gestion des API auto-hébergée. Ces options sont examinées en détail dans les sections suivantes relatives aux considérations de conception.

Architecture

Le diagramme suivant illustre les trois piliers de l’observabilité des services avec l’impact sur le volume de données.

Le diagramme suivant montre différents composants Open Service Mesh s’exécutant dans un cluster Kubernetes avec Arc. Il présente également un exemple d’application activé dans le maillage de services, qui est automatiquement configuré avec un conteneur annexe Envoy.

Considérations sur la conception

Les trois piliers de l’observabilité sont les métriques, les journaux et les traces. Incorporez-les à votre stratégie d’observabilité pour faciliter l’observabilité de votre système.

Les métriques sont des valeurs numériques qui décrivent un certain aspect d’un système à un moment donné. Elles sont toujours collectées à intervalles réguliers.

La capture d’écran suivante présente une visualisation d’exemple de métrique de requête HTTP pour un service. La métrique de cet exemple s’affiche sous forme de taux de requête HTTP par minute sur une période spécifiée.

Les journaux peuvent stocker différents types de données présentant leurs propres structures. Un journal contient des détails relatifs aux transactions qui peuvent vous permettre d’obtenir un déroulé plus complet pour un événement donné. Les journaux d’application incluent généralement des timestamps, des niveaux de journalisation, ainsi que toutes les informations nécessaires pour comprendre le contexte d’un événement. Les journaux sont collectés et envoyés à un service de journal à des fins de stockage et d’analyse.
Le suivi distribué est une technique de diagnostic permettant aux utilisateurs de localiser les défaillances et les problèmes de performances au sein des applications, en particulier celles qui sont distribuées sur plusieurs ordinateurs ou processus. Cette technique effectue le suivi des requêtes par le biais d’une application, en corrélant le travail effectué par différents composants d’application et en le séparant d’autres tâches que l’application peut effectuer pour les requêtes simultanées.

La capture d’écran suivante présente une visualisation de transaction de bout en bout à l’aide d’Application Insights. Ce visuel permet de facilement comprendre les temps de réponse, les codes de réponse et toutes les exceptions qui se produisent entre les requêtes d’une chaîne de transactions.

Les trois piliers des métriques, des journaux et du traçage distribué sont interconnectés. Les métriques sont stockées sous forme de valeurs numériques dans une base de données de série chronologique. Elles sont moins volumineuses que les journaux, ce qui les rend plus faciles à évaluer et utiles pour les alertes en quasi temps réel. Les journaux capturent et transmettent nettement plus d’informations que les métriques, ce qui les rend utiles pour un débogage plus approfondi. Les traces sont étendues aux requêtes et utiles pour obtenir une visibilité sur une requête lorsqu’elle traverse plusieurs composants d’un système distribué.

Le tableau suivant présente l’impact de la collecte pour les trois piliers.

Caractéristique de collecte	Mesures	Journaux d’activité	Suivi distribué
Comptes pour chaque transaction	Oui	Oui	non (échantillonné)
Protégé contre les problèmes de cardinalité	non	oui	Oui
Coût	low	high	low

Il existe différentes façons d’obtenir l’observabilité des services. Vous pouvez utiliser un maillage de services pour le faire au niveau de la couche de plateforme, où votre application n'est pas consciente et ne change pas. Vous pouvez également instrumenter une application avec une bibliothèque, ce qui se fait généralement à l’aide d’un outil APM (Application Performance Monitoring) comme Application Insights. Les passerelles d’API fournissent une observabilité du trafic nord-sud, mais ne présentent pas d’observabilité en termes de communication de pod à pod et ne sont pas faciles à configurer à grande échelle.

Les sections suivantes expliquent comment utiliser un maillage de services et la passerelle d’API auto-hébergée disponible pour Azure Arc afin d’obtenir une observabilité des services.

Maillage de services

Un maillage de services offre des fonctionnalités sur les aspects suivants notamment : gestion du trafic, résilience, application des stratégies, sécurité de l’identité et observabilité des charges de travail. Votre application est dissociée de ces fonctionnalités opérationnelles ; le maillage de services les déplace hors de la couche Application, au niveau de la couche Infrastructure. Cela se fait par l'intermédiaire d'un proxy hautement performant qui gère tout le trafic entrant et sortant de votre service.

Kubernetes avec Azure Arc prend en charge Open Service Mesh (OSM), un projet CNCF (Cloud Native Computing Foundation), qui est déployé en tant qu’extension. Open Service Mesh est un maillage de services natif Cloud léger et extensible qui permet aux utilisateurs de gérer et de sécuriser uniformément les environnements de microservices hautement dynamiques et de bénéficier de fonctionnalités d’observabilité prêtes à l’emploi.
Parmi les autres maillages de services qui nécessitent une prise en charge du fournisseur figurent Istio, Consul Connecter et Linkerd.
En fonction des fonctionnalités que vous utilisez lors de l’implémentation d’un maillage de services, les opérateurs d'applications peuvent être amenés à définir une configuration pour chaque service (règles d'accès et services d'intégration, par exemple). En outre, les opérateurs de cluster doivent gérer et connaître le contrôleur de maillage de services. En raison de la façon dont le maillage de services utilise le modèle annexe, les journaux d'accès du plan de contrôle du maillage de services et annexes sont nécessaires pour déboguer la sortie et l’entrée.

Observabilité du maillage de services

L’observabilité est une fonctionnalité importante parmi les nombreuses fonctionnalités que fournissent les maillages de services. Optez pour un maillage de services qui répond à vos exigences minimales en matière d'observabilité afin de réduire la complexité et les composants fournis avec le maillage et devant être configurés. Évaluez les fonctionnalités courantes et les cas d’utilisation suivants d’observabilité que fournissent les maillages de services :

Génération de métriques, y compris les quatre signaux principaux : latence, trafic, erreurs et saturation.
Méthode RED (Rates-calls/sec, Errors, Duration-call latencies), qui est un sous-ensemble des quatre signaux principaux utilisé pour mesurer les services. Votre maillage de services doit fournir un moyen normalisé de collecter des métriques RED, des traces, etc.
L'observabilité augmente, grâce à l'élargissement de la couverture à tous les services qui font partie de votre maillage de services.
Fonctionnalités qui augmentent l’adoption de l’observabilité en instrumentant automatiquement tous les services.
Intégration forte avec les piliers d’observabilité des services. Votre maillage de services doit être capable d'extraire des métriques et de collecter les journaux qui sont transmis à votre solution de monitoring. Assurez-vous que la collecte de données de télémétrie de votre maillage de services prend en charge vos besoins métier et s’intègre bien votre solution de monitoring existante.

Le diagramme suivant présente un exemple de la fonctionnalité service de proxy de maillage de services en matière de collecte et de transfert de données.

Passerelle auto-hébergée de gestion des API

Avec l’intégration entre la Gestion des API Azure et Azure Arc sur Kubernetes, vous pouvez déployer le composant de passerelle Gestion des API en tant qu’extension dans un cluster Kubernetes avec Azure Arc. Cela permet à une version conteneurisée de la passerelle Gestion des API de s’exécuter dans votre cluster. Toutes les passerelles auto-hébergées sont managées à partir du service Gestion des API avec lequel elles sont fédérées, ce qui vous offre une visibilité et une expérience de gestion unifiée sur l’ensemble des API internes et externes.

La configuration de la passerelle auto-hébergée permettant d’accepter le trafic entrant vers vos services nécessite la création d’une stratégie. Sa gestion peut devenir plus complexe au fur et à mesure que l'échelle de vos services augmente.

Pour plus d’informations, consultez la Vue d’ensemble de la passerelle auto-hébergée.

Observabilité de la passerelle auto-hébergée Gestion des API

La passerelle auto-hébergée émet des métriques, des journaux stdout et des journaux stderr. Les métriques émises peuvent être configurées par un ConfigMap dans votre cluster. Pour plus d’informations sur la surveillance avancée Gestion des API, consultez Surveillance avancée.

L’observabilité de la passerelle auto-hébergée prend en compte le trafic externe (nord-sud) accédant à votre cluster, mais ne fournit aucune observabilité pour le trafic de pod à pod au sein de votre cluster (est-ouest).

Métriques et journaux cloud : les métriques sont émises par défaut dans Azure Monitor. Log Analytics vous permet de collecter et d’afficher les journaux de conteneur de la passerelle auto-hébergée à l’aide d’Azure Monitor pour conteneurs. Pour plus d’informations, consultez Configurer des métriques et journaux locaux pour la passerelle auto-hébergée de Gestion des API Azure.

Métriques et journaux locaux : les métriques et les journaux de votre passerelle auto-hébergée peuvent être intégrés à vos outils de surveillance locaux ou émis par Config Map. Les métriques peuvent être configurées à des fins de publication sur des serveurs de métriques. Les journaux de passerelle sont émis par défaut sur stdout et stderr. Pour plus d’informations, consultez Configurer des métriques et journaux locaux pour la passerelle auto-hébergée de Gestion des API Azure.

Tableau de comparaison des technologies

Le tableau suivant présente les différences entre les options d’implémentation pour vous aider à choisir une méthode d’observabilité des services.

Fonctionnalité	Maillage de services	Analyse des performances des applications	Passerelle d’API auto-hébergée
Trafic Est-Ouest pris en charge	Oui	oui	non
Fonctionnalité de métriques	Oui	oui	Oui
Fonctionnalité de journalisation	Oui	Oui	Implémentation personnalisée
Fonctionnalité de traces distribuées	Oui	oui	Oui
Couche d’implémentation	réseau	application	réseau
Protocoles pris en charge	http(s), tcp, gRPC	N/A	http(s), websockets
Responsabilité de la configuration	Opérateurs de cluster	Développeurs d'applications	Opérateurs d’application et Opérateurs de cluster
Complexité de la configuration pour l’observabilité	low	high	moyenne

Recommandations de conception

Implémentez Open Service Mesh pour obtenir une observabilité de l’intégrité et des performances de vos services. Open Service Mesh utilise des proxys annexes injectés en tant que conteneur distinct dans les mêmes pods que vos charges de travail pour obtenir des données de télémétrie. Ces proxys interceptent tout le trafic HTTP entrant et sortant vers vos charges de travail et transmettent les données à Open Service Mesh. Avec ce système, les développeurs de services ne sont pas tenus d’instrumenter leur code pour collecter des données de télémétrie.

Activez Open Service Mesh à l’aide de la fonctionnalité d’extension de cluster Kubernetes avec Azure Arc pour permettre à Microsoft de gérer le plan de contrôle pour vous. Pour plus d’informations, consultez Déployer Open Service Mesh avec Azure Arc (préversion).

Pour optimiser la disponibilité et les performances de vos applications et services, activez Azure Monitor Container Insights. Il offre une solution complète pour collecter, analyser et exploiter les données de télémétrie de vos environnements cloud et locaux. Open Service Mesh avec Azure Arc s’intègre en profondeur à Azure Monitor, ce qui vous permet d’afficher et de répondre aux indicateurs de performance clés critiques fournis par les métriques OSM et les journaux des conteneurs d’applications. Vous pouvez activer les métriques OSM en suivant ces étapes. Pour le suivi distribué, nous vous recommandons Jaeger, qui peut s’intégrer à votre plan de contrôle OSM.

Open Service Mesh fournit également des intégrations d’observabilité documentés pour les métriques avec Prometheus et Grafana, le suivi avec Jaeger et le transfert de journaux avec Fluent Bit. Ces intégrations offrent d’autres options si vous n’utilisez pas de solutions de monitoring Azure. Vous pouvez utiliser ces intégrations pour étendre d’autres outils de surveillance internes, si besoin.

Au minimum, vous devez définir les trois métriques RED suivantes et les mesurer pour tous les services :

Taux de requêtes : nombre de requêtes reçues par le service par seconde.
Erreurs : nombre de requêtes ayant échoué ou de taux de requêtes ayant échoué par seconde.
Durée : durée nécessaire pour qu’un service gère une requête.

Open Service Mesh fournit plusieurs classeurs de service préconfigurés dans Azure Monitor pour éviter de devoir configurer manuellement les tableaux de bord et les graphiques. Cette télémétrie détaillée vous permet d’observer le comportement du service et de résoudre les problèmes, de gérer et d’optimiser vos applications. Dans Azure Monitor, l’utilisation d’un classeur de surveillance OSM vous permet ce qui suit :

Obtenir une vue d’ensemble de tous les services de votre maillage et accéder aux métriques de niveau de service critiques pour trois des quatre principaux signaux de surveillance : latence, requêtes et erreurs.
Définir, examiner et configurer des alertes sur des objectifs de niveau de service, qui résument les performances visibles par l’utilisateur de votre service.
Afficher des graphiques de métriques pour les services individuels afin de pouvoir les analyser en profondeur à l’aide du filtrage et des décompositions, de l’analyse des données par code de réponse, protocole, pod de destination, source de trafic, etc.

Utilisez les visualisations de l’interface utilisateur Jaeger pour :

Observer une visualisation de graphique de topologie présentant les microservices qui communiquent entre eux, la destination des requêtes ainsi que leur délai.
Examiner les requêtes et les réponses spécifiques pour voir quand et comment quand elles se produisent pour la surveillance et la résolution des problèmes des systèmes distribués.

L’observabilité des services n’est qu’une discipline de votre stratégie de supervision cloud. Pour plus d’informations sur les disciplines de gestion, consultez Zone de conception critique des disciplines de gestion.

Étapes suivantes

Pour plus d’informations sur votre parcours cloud hybride et multicloud, consultez les articles suivants :

Passez en revue les prérequis pour Kubernetes avec Azure Arc.
Passez en revue les distributions Kubernetes validées pour Kubernetes avec Azure Arc.
Découvrez comment Gérer des environnements hybrides et multiclouds.
Pour en savoir plus sur Open Mesh Service avec Azure Arc, consultez :
Découvrez comment Configurer la surveillance et l’observabilité avec Open Service Mesh sur AKS (Azure Kubernetes Service)
Découvrez la Gestion et la surveillance pour Kubernetes avec Azure Arc.
En savoir plus sur les maillages de services.
Expérimentez Kubernetes avec Azure Arc avec l’extension Open Service Mesh à l’aide du Démarrage rapide avec Azure Arc.
En savoir plus sur Azure Arc via le Parcours d’apprentissage Azure Arc.
Consultez les Questions fréquentes (FAQ) sur Azure Arc pour trouver des réponses aux questions les plus courantes.

Share via