Surveiller les clusters Kubernetes à l’aide des services Azure et d’outils cloud natifs

Cet article explique comment surveiller l’intégrité et les performances de vos clusters Kubernetes et des charges de travail qui s’exécutent sur ceux-ci à l’aide d’Azure Monitor et de services Azure et cloud natifs associés. Cela inclut les clusters s’exécutant dans Azure Kubernetes Service (AKS) ou d’autres clouds tels qu’AWS et GCP. Différents ensembles d’instructions sont fournis pour les différents rôles qui gèrent généralement les composants uniques qui composent un environnement Kubernetes.

Important

Cet article fournit des conseils complets sur la surveillance des différentes couches de votre environnement Kubernetes en fonction d’Azure Kubernetes Service (AKS) ou de clusters Kubernetes dans d’autres clouds. Si vous commencez juste à utiliser AKS ou Azure Monitor, consultez Surveillance d’AKS pour obtenir des informations de base sur la surveillance d’un cluster AKS.

Couches et rôles de l’environnement Kubernetes

Voici une illustration d’un modèle commun d’environnement Kubernetes classique, de la couche d’infrastructure jusqu’aux applications. Chaque couche a des exigences de supervision distinctes qui sont traitées par différents services et généralement gérées par différents rôles dans l’organisation.

Diagram of layers of Kubernetes environment with related administrative roles.

Les responsabilités associées aux différentes couches d’un environnement Kubernetes et aux applications qui en dépendent sont généralement traitées par plusieurs rôles. Selon la taille de votre organisation, ces rôles peuvent être exécutés par différentes personnes ou même par différentes équipes. Le tableau suivant décrit les différents rôles, tandis que les sections ci-dessous fournissent les scénarios de surveillance généralement rencontrés par chacun de ces rôles.

Rôles Description
Développeur Développez et maintenez l’application qui s’exécute sur le cluster. Responsable du trafic spécifique à l’application, ainsi que des performances et des échecs de l’application. Maintient la fiabilité de l’application en conformité avec les contrats SLA.
Ingénieur plateforme Responsable du cluster Kubernetes. Provisionne et gère la plateforme utilisée par les développeurs.
Ingénieur réseau Responsable du trafic entre les charges de travail et de toute entrée/sortie avec le cluster. Analyse le trafic réseau et effectue une analyse des menaces.

Sélection des outils de surveillance

Azure fournit un ensemble complet de services basés sur Azure Monitor permettant de surveiller l’intégrité et les performances des différentes couches de votre infrastructure Kubernetes et des applications qui en dépendent. Ces services fonctionnent ensemble pour fournir une solution de surveillance complète et sont recommandés à la fois pour AKS et pour vos clusters Kubernetes s’exécutant dans d’autres clouds. Vous avez peut-être déjà un investissement dans les technologies cloud natives approuvées par la Cloud Native Computing Foundation, auquel cas vous pouvez choisir d’intégrer des outils Azure à votre environnement existant.

La sélection des outils à déployer et leur configuration dépendent des exigences de votre environnement particulier. Par exemple, vous pouvez utiliser les offres managées dans Azure pour Prometheus et Grafana, ou choisir d’utiliser votre installation existante de ces outils avec vos clusters Kubernetes dans Azure. Votre organisation peut également utiliser des outils autres que Container Insights pour collecter et analyser les journaux Kubernetes, tels que Splunk ou Datadog.

Important

La surveillance d’un environnement complexe tel que Kubernetes implique la collecte d’une quantité importante de données de télémétrie, ce qui peut être coûteux. Vous devriez collecter juste assez de données pour répondre à vos besoins. Considérez la quantité de données collectées, la fréquence de collecte et la période de rétention. Si vous êtes très soucieux des coûts, vous pouvez choisir d’implémenter un sous-ensemble des fonctionnalités complètes afin de réduire vos dépenses de surveillance.

Ingénieur réseau

L’ingénieur réseau est responsable du trafic entre les charges de travail et de toute entrée/sortie avec le cluster. Il analyse le trafic réseau et effectue une analyse des menaces.

Diagram of layers of Kubernetes environment for network engineer.

Services Azure pour l’administrateur réseau

Le tableau suivant répertorie les services couramment utilisés par l’ingénieur réseau afin de surveiller l’intégrité et les performances du réseau prenant en charge le cluster Kubernetes.

Service Description
Network Watcher Suite d’outils dans Azure permettant de surveiller les réseaux virtuels utilisés par vos clusters Kubernetes et de diagnostiquer les problèmes détectés.
Analyse du trafic Fonctionnalité de Network Watcher qui analyse les journaux de flux pour fournir des insights sur le flux de trafic.
Insights réseau Fonctionnalité d’Azure Monitor qui inclut une représentation visuelle des performances et de l’intégrité de différents composants réseau et fournit l’accès aux outils de surveillance réseau qui font partie de Network Watcher.

Insights réseau est activé par défaut et ne nécessite aucune configuration. Network Watcher est généralement activé par défaut dans chaque région Azure.

Surveiller le niveau 1 - Réseau

Voici des scénarios courants de surveillance du réseau.

  • Créez des journaux de flux pour consigner des informations sur le trafic IP transitant par les groupes de sécurité réseau utilisés par votre cluster, puis utilisez l’analyse du trafic pour analyser et fournir des insights sur ces données. Pour l’analyse du trafic, vous utiliserez probablement l’espace de travail Log Analytics que vous utilisez pour Container Insights et pour les journaux de votre plan de contrôle.
  • À l’aide de l’analyse du trafic, vous pouvez détecter le trafic qui circule vers ou depuis des ports inattendus utilisés par le cluster, ainsi que le trafic qui circule sur des adresses IP publiques qui ne devraient pas être exposées. Utilisez ces informations pour déterminer si vos règles réseau doivent être modifiées.
  • Pour les clusters AKS, utilisez le module complémentaire Network Observability pour AKS (préversion) pour surveiller et observer l’accès entre les services du cluster (trafic est-ouest).

Ingénieur plateforme

L’ingénieur de plateforme, également appelé administrateur de cluster, est responsable du cluster Kubernetes lui-même. Il provisionne et gère la plateforme utilisée par les développeurs. Il doit comprendre l’intégrité du cluster et de ses composants, et être en mesure de résoudre les problèmes détectés. Il doit également comprendre le coût d’exploitation du cluster et éventuellement être en mesure d’allouer des coûts à différentes équipes.

Diagram of layers of Kubernetes environment for platform engineer.

Les organisations importantes peuvent également avoir un architecte de flotte, dont le rôle est semblable à celui de l’ingénieur de la plateforme. Cependant, il est responsable de plusieurs clusters. Il a besoin d’une visibilité sur l’ensemble de l’environnement et doit effectuer des tâches administratives à grande échelle. Les recommandations à grande échelle sont incluses dans les conseils ci-dessous. Consultez Qu’est-ce qu’Azure Kubernetes Fleet Manager (préversion) ? pour plus d’informations sur la création d’une ressource Fleet pour les scénarios multi-clusters et à grande échelle.

Services Azure pour l’ingénieur de plateforme

Le tableau suivant répertorie les services Azure permettant à l’ingénieur de plateforme de surveiller l’intégrité et les performances du cluster Kubernetes et de ses composants.

Service Description
Container Insights Service Azure pour AKS et les clusters Kubernetes avec Azure Arc qui utilisent une version conteneurisée de l’agent Azure Monitor pour collecter les journaux stdout/stderr, les métriques de performances et les événements Kubernetes de chaque nœud de votre cluster. Il collecte également les métriques du plan de contrôle Kubernetes et les stocke dans l’espace de travail. Vous pouvez afficher les données dans le portail Azure ou les interroger à l’aide de Log Analytics.
Service Azure Monitor géré pour Prometheus Prometheus est une solution de métriques natives cloud de Cloud Native Compute Foundation et l’outil le plus couramment utilisé pour collecter et analyser les données de métrique à partir de clusters Kubernetes. Le service managé Azure Monitor pour Prometheus est une solution complètement managée compatible avec le langage de requête Prometheus (PromQL) et les alertes Prometheus et qui s’intègre à Grafana géré par Azure pour la visualisation. Ce service prend en charge votre investissement dans des outils open source sans la complexité de gestion de votre propre environnement Prometheus.
Kubernetes compatible avec Azure Arc Vous permet de joindre des clusters Kubernetes s’exécutant dans d’autres clouds afin de pouvoir les gérer et les configurer dans Azure. Une fois l’agent Arc installé, vous pouvez surveiller AKS et les clusters hybrides ensemble à l’aide des mêmes méthodes et outils, notamment Container Insights et Prometheus.
Grafana géré par Azure Implémentation entièrement managée de Grafana, qui est une plateforme de visualisation de données open source couramment utilisée pour présenter des données Prometheus ou autres. Plusieurs tableaux de bord Grafana prédéfinis sont disponibles pour la surveillance de Kubernetes et la résolution des problèmes de pile complète.

Configurer la surveillance pour l’ingénieur de plateforme

Les sections ci-dessous identifient les étapes de surveillance complète de votre environnement Kubernetes à l’aide des services Azure répertoriés dans le tableau ci-dessus. Les options de fonctionnalité et d’intégration sont fournies pour chaque service afin de vous aider à déterminer où vous devrez peut-être modifier cette configuration pour répondre à vos besoins particuliers.

Activer le scraping des métriques Prometheus

Important

Pour utiliser le service géré Azure Monitor pour Prometheus, vous devez disposer d'un espace de travail Azure Monitor. Pour plus d’informations sur les considérations relatives à la conception d’une configuration d’espace de travail, consultez Architecture de l’espace de travail Azure Monitor.

Activez le scraping des métriques Prometheus par le service managé Azure Monitor pour Prometheus à partir de votre cluster à l’aide de l’une des méthodes suivantes :

Si vous disposez déjà d’un environnement Prometheus que vous souhaitez utiliser pour vos clusters AKS, activez le service managé Azure Monitor pour Prometheus, puis utilisez l’écriture à distance pour envoyer des données à votre environnement Prometheus existant. Vous pouvez également utiliser l’écriture à distance pour envoyer des données de votre environnement Prometheus autogéré existant au service managé Azure Monitor pour Prometheus.

Pour plus d’informations sur les métriques collectées par défaut et leur fréquence de collecte, consultez Configuration des métriques Prometheus par défaut dans Azure Monitor. Si vous souhaitez personnaliser la configuration, consultez Personnaliser le scraping des métriques Prometheus dans le service managé Azure Monitor pour Prometheus.

Activer Grafana pour l’analyse des données Prometheus

Créez une instance de Managed Grafana et liez-la à votre espace de travail Azure Monitor afin de pouvoir utiliser vos données Prometheus comme source de données. Il est également possible d’effectuer cette configuration manuellement en ajoutant un service managé Azure Monitor pour Prometheus en tant que source de données. Une variété de tableaux de bord prédéfinis sont disponibles pour la surveillance des clusters Kubernetes, dont plusieurs présentent des informations semblables à celles des vues Container Insights.

Si vous disposez d’un environnement Grafana existant, vous pouvez continuer à l’utiliser et ajouter un service managé Azure Monitor pour Prometheus en tant que source de données. Vous pouvez également ajouter la source de données Azure Monitor à Grafana pour utiliser les données collectées par Container Insights dans des tableaux de bord Grafana personnalisés. Effectuez cette configuration si vous souhaitez vous concentrer sur les tableaux de bord Grafana plutôt que sur les vues et rapports Container Insights.

Activer Container Insights pour la collecte de journaux

Lorsque vous activez Container Insights pour votre cluster Kubernetes, il déploie une version conteneurisée de l’agent Azure Monitor qui envoie des données à un espace de travail Log Analytics dans Azure Monitor. Container Insights collecte les stdout/stderr des conteneurs, les journaux d’infrastructure et les données de performances. Toutes les données de journal sont stockées dans un espace de travail Log Analytics où elles peuvent être analysées à l’aide du Langage de requête Kusto (KQL).

Consultez Activer Container Insights pour connaître les prérequis et les options de configuration pour l’intégration de vos clusters Kubernetes. Intégrez à l’aide d’Azure Policy pour vous assurer que tous les clusters conservent une configuration cohérente.

Une fois que Container Insights est activé pour un cluster, effectuez les actions suivantes pour optimiser votre installation.

  • Container Insights collecte la plupart des mêmes valeurs de métriques que Prometheus. Vous pouvez désactiver la collecte de ces métriques en configurant Container Insights pour qu’il ne collecte uniquement les journaux et les événements, comme décrit dans Activer les paramètres d’optimisation des coûts dans Container Insights. Cette configuration désactive l’expérience Container Insights dans le portail Azure, mais vous pouvez utiliser Grafana pour visualiser les métriques Prometheus et Log Analytics pour analyser les données de journal collectées par Container Insights.
  • Réduisez le coût d’ingestion de données Container Insights en réduisant la quantité de données collectées.
  • Pour améliorer votre expérience de requête avec les données collectées par Container Insights et réduire les coûts de collecte, activez le schéma ContainerLogV2 pour chaque cluster. Si vous utilisez uniquement les journaux pour résoudre des problèmes occasionnels, envisagez de configurer cette table en tant que journaux de base.

Si vous disposez d’une solution existante pour la collecte des journaux, suivez les instructions relatives à cet outil ou activez Container Insights et utilisez la fonctionnalité d’exportation de données de l’espace de travail Log Analytics pour envoyer des données à Azure Event Hubs à transférer vers un autre système.

Collecter les journaux du plan de contrôle pour les clusters AKS

Les journaux pour les composants du plan de contrôle AKS sont implémentés dans Azure en tant que journaux de ressources. Container Insights n’utilise pas ces journaux. Vous devez donc créer vos propres requêtes de journal pour les afficher et les analyser. Pour plus d’informations sur la structure des journaux et les requêtes, consultez Interroger les journaux à partir de Container Insights.

Créez un paramètre de diagnostic pour chaque cluster AKS afin d’envoyer des journaux de ressources à un espace de travail Log Analytics. Utilisez Azure Policy pour assurer une configuration cohérente de plusieurs clusters.

Il y a un coût pour l’envoi de journaux de ressources à un espace de travail. Par conséquent, vous ne devez collecter que les catégories de journaux que vous avez l’intention d’utiliser. Pour obtenir une description des catégories disponibles pour AKS, consultez Journaux de ressources. Commencez par collecter un nombre minimal de catégories, puis modifiez le paramètre de diagnostic pour collecter des catégories supplémentaires à métrique que vos besoins augmentent et que vous comprenez vos coûts associés. Vous pouvez envoyer des journaux à un compte de stockage Azure pour réduire les coûts si vous avez besoin de conserver les informations à des fins de conformité. Pour plus d’informations sur le coût de l’ingestion et de la conservation des données de journal, consultez Informations sur les tarifs des Journaux Azure Monitor.

Si vous n’êtes pas sûr de quels journaux de ressources activer initialement, utilisez les recommandations suivantes basées sur les exigences client les plus courantes. Vous pouvez activer d’autres catégories ultérieurement si nécessaire.

Catégorie Activer ? Destination
kube-apiserver Activer Espace de travail Log Analytics
kube-audit Activer stockage Azure. Cela permet de réduire les coûts au minimum tout en conservant les journaux d’audit s’ils sont requis par un auditeur.
kube-audit-admin Activer Espace de travail Log Analytics
kube-controller-manager Activer Espace de travail Log Analytics
kube-scheduler Désactiver
cluster-autoscaler Activer si la mise à l’échelle automatique est activée Espace de travail Log Analytics
guard Activer si Microsoft Entra ID est activé Espace de travail Log Analytics
AllMetrics Désactiver, car les métriques sont collectées dans Prometheus managé Espace de travail Log Analytics

Si vous disposez d’une solution existante pour la collecte des journaux, suivez les instructions relatives à cet outil ou activez Container Insights et utilisez la fonctionnalité d’exportation de données de l’espace de travail Log Analytics pour envoyer des données au hub d’événements Azure à transférer vers un autre système.

Collecter le journal d’activité pour les clusters AKS

Les modifications de configuration apportées à vos clusters AKS sont stockées dans le journal d’activité. Créez un paramètre de diagnostic pour envoyer ces données à votre espace de travail Log Analytics afin de les analyser avec d’autres données de surveillance. Aucun coût n’est associé à cette collecte de données et vous pouvez analyser les données ou les alerter à l’aide de Log Analytics.

Surveiller le niveau 2 - Composants au niveau du cluster

Le niveau du cluster inclut les composants suivants :

Composant Exigences de supervision
Nœud Comprenez l’état de préparation et les performances UC, mémoire, disque et d’utilisation d’IP pour chaque nœud et surveillez de manière proactive leurs tendances d’utilisation avant de déployer des charges de travail.

Voici des scénarios courants pour la surveillance des composants au niveau du cluster.

Container Insights

  • La vue Cluster vous donne un aperçu rapide de la performance des nœuds de votre cluster, y compris leur utilisation de l’UC et de la mémoire.
  • Utilisez la vue Nœuds pour voir l’intégrité de chaque nœud et l’intégrité et les performances des pods exécutés sur chacun. Voir Superviser les performances de votre cluster Kubernetes avec Container Insights pour plus de détails sur l’utilisation de cette vue et d’analyser l’intégrité et les performances du nœud.
  • Sous Rapports, utilisez les classeurs Surveillance des nœuds pour analyser la capacité du disque, les E/S de disque et l’utilisation du GPU. Pour plus d’informations sur ces classeurs, consultez Classeurs de supervision des nœuds.
  • Sous Surveillance, sélectionnez Classeurs, puis Utilisation de l’adresse IP du sous-réseau pour voir l’allocation d’adresses IP et l’affectation sur chaque nœud pour une plage de temps sélectionnée.

Tableaux de bord Grafana

  • Utilisez le tableau de bord prédéfini dans Grafana managé pour Kubelet pour voir l’intégrité et les performances de chacun d’eux.
  • Utilisez des tableaux de bord Grafana avec des valeurs de métrique Prometheus liées au disque, telles que node_disk_io_time_seconds_total et windows_logical_disk_free_bytes pour surveiller le stockage attaché.
  • Plusieurs tableaux de bord Kubernetes sont disponibles pour visualiser les performances et l’intégrité de vos nœuds en fonction des données stockées dans Prometheus.

Log Analytics

Dépannage

Analyse des coûts

  • Configurez OpenCost, un projet de bac à sable certifié CNCF, open source et indépendant du fournisseur, pour comprendre vos coûts Kubernetes et soutenir votre analyse des coûts de votre cluster. Il exporte des données de coût détaillées vers le stockage Azure.
  • Utilisez les données d’OpenCost pour détailler l’utilisation relative du cluster par différentes équipes de votre organisation afin de pouvoir allouer les coûts entre chacune d’elles.
  • Utilisez les données d’OpenCost pour vous assurer que le cluster utilise la pleine capacité de ses nœuds en empaquetant densément les charges de travail, en utilisant un faible nombre de grands nœuds plutôt qu’un grand nombre de nœuds plus petits.

Surveiller le niveau 3 - Composants Kubernetes managés

Le niveau Kubernetes managé inclut les composants suivants :

Composant Surveillance
Serveur d’API Surveillez l’état du serveur d’API et identifiez toute augmentation de la charge de la requête et les goulots d’étranglement si le service est défaillant.
Kubelet La surveillance de Kubelet vous aide à résoudre les problèmes de gestion des pods, les pods non démarrés, les nœuds non prêts ou les pods interrompus de force.

Voici des scénarios courants pour la surveillance de vos composants Kubernetes managés.

Container Insights

  • Sous Surveillance, sélectionnez Métriques pour afficher le compteur Demandes en cours.
  • Sous Rapports, utilisez le classeur Kubelet pour afficher l’intégrité et les performances de chaque kubelet. Pour plus d’informations sur ces classeurs, consultez Classeurs d’analyse des ressources.

Grafana

  • Utilisez le tableau de bord prédéfini dans Grafana managé pour Kubelet pour voir l’intégrité et les performances de chaque kubelet.
  • Utilisez un tableau de bord tel que kubernetes apiserver pour obtenir une vue complète des performances du serveur d’API. Cela comprend des valeurs comme la latence des requêtes et le temps de traitement des files d’attente de travaux.

Log Analytics

  • Utilisez les requêtes de journal avec les journaux de ressources pour analyser les journaux de plan de contrôle générés par les composants AKS.

  • Toutes les activités de configuration pour AKS sont enregistrées dans le journal d’activité. Lorsque vous envoyez le journal d’activité à un espace de travail Log Analytics, vous pouvez l’analyser avec Log Analytics. Par exemple, l’exemple de requête suivant peut être utilisé pour retourner des enregistrements identifiant une mise à niveau réussie sur tous vos clusters AKS.

    AzureActivity
    | where CategoryValue == "Administrative"
    | where OperationNameValue == "MICROSOFT.CONTAINERSERVICE/MANAGEDCLUSTERS/WRITE"
    | extend properties=parse_json(Properties_d) 
    | where properties.message == "Upgrade Succeeded"
    | order by TimeGenerated desc
    

Dépannage

Surveiller le niveau 4 - Objets et charges de travail Kubernetes

Le niveau Objets et charges de travail Kubernetes inclut les composants suivants :

Composant Exigences de supervision
Déploiements Surveillez l’état réel et l’état souhaité du déploiement, ainsi que l’état et l’utilisation des ressources des pods exécutés dessus.
Pods Surveillez l’état et l’utilisation des ressources, y compris l’UC et la mémoire, et les pods en cours d’exécution sur votre cluster AKS.
Conteneurs Surveillez l’utilisation des ressources, y compris l’UC et la mémoire, et les conteneurs en cours d’exécution sur votre cluster AKS.

Voici des scénarios courants pour la surveillance de vos objets et charges de travail Kubernetes.

Container Insights

  • Utilisez les vues Nœuds et Contrôleurs pour afficher l’état d’intégrité et les performances des pods qui s’exécutent dessus, ainsi que l’état d’intégrité et les performances de leurs conteneurs.
  • Utilisez la vue Conteneurs pour voir l’intégrité et les performances des conteneurs. Voir Superviser les performances de votre cluster Kubernetes avec Container Insights pour plus de détails sur l’utilisation de cette vue et d’analyser l’intégrité et les performances du conteneur.
  • Sous Rapports, utilisez le classeur Déploiements pour afficher les métriques de déploiement. Pour plus d’informations, consultez l’article Déploiement et métriques HPA avec Container Insights.

Tableaux de bord Grafana

  • Utilisez les tableaux de bord prédéfinis dans Grafana managé pour les nœuds et les pods afin d’afficher leur intégrité et leurs performances.
  • Plusieurs tableaux de bord Kubernetes sont disponibles pour visualiser les performances et l’intégrité de vos nœuds en fonction des données stockées dans Prometheus.

Données actives

  • Dans les scénarios de dépannage, Container Insights fournit un accès aux journaux de conteneur AKS (stdout/stderr), aux événements et aux métriques de pod en temps réel. Pour plus d’informations sur cette fonctionnalité, consultez How to view Kubernetes logs, events, and pod metrics in real time (Comment afficher les journaux, les événements et les mesures pod Kubernetes en temps réel).

Alertes pour l’ingénieur de plateforme

Les alertes dans Azure Monitor vous informent de façon proactive des données et des modèles intéressants dans vos données de surveillance. Elles permettent d’identifier et de résoudre les problèmes affectant votre système avant que vos clients ne les remarquent. Si vous disposez d’une solution ITSM existante pour les alertes, vous pouvez l’intégrer à Azure Monitor. Vous pouvez également exporter des données d’espace de travail pour envoyer des données de votre espace de travail Log Analytics vers un autre emplacement qui prend en charge votre solution d’alerte actuelle.

Types d’alertes

Le tableau suivant décrit les différents types de règles d’alerte personnalisées que vous pouvez créer en fonction des données collectées par les services décrits ci-dessus.

type d’alerte Description
Alertes Prometheus Les alertes Prometheus sont écrites dans le langage de requête Prometheus (Prom QL) et appliquées aux métriques Prometheus stockées dans les services managés Azure Monitor pour Prometheus. Les alertes recommandées incluent déjà les alertes Prometheus les plus courantes, et vous pouvez créer des règles d’alerte supplémentaires si nécessaire.
Règles d’alerte de métrique Les règles d’alerte de métrique utilisent les mêmes valeurs de métrique que Metrics Explorer. En fait, vous pouvez créer une règle d’alerte directement à partir de Metrics Explorer avec les données que vous analysez actuellement. Les règles d’alerte de métrique peuvent être utiles pour alerter sur les performances AKS à l’aide de l’une des valeurs des métriques de référence de données AKS.
Règles d’alerte de recherche dans les journaux Utilisez les règles d’alerte de recherche dans les journaux pour générer une alerte à partir des résultats d’une requête de journal. Pour plus d’informations, consultez Comment créer des alertes de recherche dans les journaux à partir de Container Insights et Comment interroger des journaux à partir de Container Insights.

Commencez par un ensemble d’alertes Prometheus recommandées à partir des Règles d’alerte de métrique dans Container Insights (préversion) qui incluent les conditions d’alerte les plus courantes pour un cluster Kubernetes. Vous pouvez ajouter d’autres règles d’alerte ultérieurement à mesure que vous identifiez d’autres conditions d’alerte.

Développeur

En plus de développer l’application, le développeur gère l’application qui s’exécute sur le cluster. Il est responsable du trafic spécifique à l’application, ainsi que des performances et des défaillances de l’application, et maintient la fiabilité de l’application en conformité avec les contrats SLA définis par l’entreprise.

Diagram of layers of Kubernetes environment for developer.

Services Azure pour les développeurs

Le tableau suivant répertorie les services couramment utilisés par le développeur afin de surveiller l’intégrité et les performances de l’application s’exécutant sur le cluster.

Service Description
Application Insights Fonctionnalité d’Azure Monitor qui fournit la surveillance des performances des applications (APM) pour surveiller les applications s’exécutant sur votre cluster Kubernetes au cours du développement, du test et de la production. Identifiez et atténuez rapidement les problèmes de latence et de fiabilité à l’aide de traces distribuées. Prend en charge OpenTelemetry pour l’instrumentation indépendante du fournisseur.

Consultez Principes de base de la collecte de données d’Azure Monitor Application Insights pour connaître les options de configuration de la collecte de données à partir de l’application qui s’exécute sur votre cluster et les critères de décision sur la méthode la mieux adaptée à vos besoins particuliers.

Surveiller le niveau 5 - Application

Voici des scénarios courants de surveillance de votre application.

Performances de l’application

  • Utilisez la vue Performances dans Application Insights pour afficher les performances des différentes opérations dans votre application.
  • Utilisez le Profileur pour capturer et afficher les traces de performances de votre application.
  • Utilisez le Plan de l’application pour afficher les dépendances entre les composants de votre application et identifier les goulots d’étranglement éventuels.
  • Activez le suivi distribué, qui fournit un profileur de performances qui fonctionne comme des piles d’appels pour les architectures cloud et microservices, afin d’améliorer l’observabilité de l’interaction entre les services.

Échecs d’application

  • Utilisez l’onglet Échecs d’Application Insights pour afficher le nombre de requêtes ayant échoué et les exceptions les plus courantes.
  • Vérifiez que les alertes pour les anomalies de défaillance identifiées avec la détection intelligente sont correctement configurées.

Surveillance de l’intégrité

  • Créez un test de disponibilité dans Application Insights pour créer un test périodique afin de surveiller la disponibilité et la réactivité de votre application.
  • Utilisez le rapport SLA pour calculer et signaler le contrat SLA pour les tests web.
  • Utilisez des annotations pour identifier le moment où une nouvelle build est déployée afin de pouvoir inspecter visuellement toute modification des performances après la mise à jour.

Journaux d’application

  • Container Insights envoie les journaux stdout/stderr à un espace de travail Log Analytics. Consultez Journaux de ressources pour obtenir une description des différents journaux et Services Kubernetes comprenant la liste des tables à laquelle chacun est envoyé.

Maillage de services

  • Pour les clusters AKS, déployez le module complémentaire de maillage de services basé sur Istio qui fournit une observabilité de votre architecture de microservices. Istio est un maillage de services open source qui s’intègre de façon transparente aux applications distribuées existantes. Le module complémentaire facilite le déploiement et la gestion d’Istio pour AKS.

Voir aussi

  • Consultez Supervision d’AKS pour obtenir des conseils sur la surveillance spécifique à Azure Kubernetes Service (AKS).