Partager via

Surveiller Azure Kubernetes Service

  • Article

Cet article aborde les points suivants :

  • Types de données de monitoring que vous pouvez collecter pour ce service.
  • Comment analyser ces données.

Remarque

Si vous connaissez déjà ce service et/ou Azure Monitor et que vous voulez simplement savoir comment analyser les données de monitoring, consultez la section Analyser vers la fin de cet article.

Quand vous avez des applications critiques et des processus métier qui s’appuient sur des ressources Azure, vous devez monitorer votre système et obtenir des alertes. Le service Azure Monitor collecte et agrège les métriques et les journaux de chaque composant de votre système. Azure Monitor vous fournit une vue de la disponibilité, des performances et de la résilience, et vous avertit des problèmes. Vous pouvez utiliser le portail Azure, PowerShell, Azure CLI, l’API REST ou des bibliothèques de client pour configurer et visualiser les données de monitoring.

Important

Kubernetes est un système distribué complexe avec de nombreux composants mobiles. Il nécessite une surveillance à plusieurs niveaux. Bien qu’AKS soit un service Kubernetes géré, une même rigueur autour de la surveillance à plusieurs niveaux est toujours nécessaire. Cet article fournit des informations générales et des bonnes pratiques pour la surveillance d’un cluster AKS.

Informations

Dans Azure, certains services ont un tableau de bord de monitoring intégré dans le portail Azure, qui constitue un point de départ pour le monitoring de votre service. Ces tableaux de bord sont appelés insights et vous pouvez les trouver dans le Hub d’insights d’Azure Monitor dans le portail Azure.

Azure Monitor Container Insights collecte des indicateurs de performance personnalisés pour des nœuds, pods, conteneurs et volumes persistants. Pour plus d’informations, consultez Indicateurs de performance collectés par Container Insights.

Azure Monitor Application Insights est utilisé pour l’APM (Application Performance Monitoring). Pour activer Application Insights avec des changements de code, consultez Activer Azure Monitor OpenTelemetry. Pour activer Application Insights sans changement de code, consultez Autoinstrumentation AKS. Pour plus d’informations sur l’instrumentation, consultez Bases de la collecte de données.

Données de surveillance

AKS génère les mêmes types de données d’analyse que d’autres ressources Azure, lesquelles sont décrites dans Analyse des données de ressources Azure. Pour obtenir des informations détaillées sur les métriques et les métriques de journaux créées par le service AKS, consultez Informations de référence sur les données de supervision d’AKS. D’autres services et fonctionnalités Azure collectent des données supplémentaires et activent d’autres options d’analyse, comme indiqué dans le diagramme et le tableau suivants.

Schéma de la collecte des données de surveillance auprès de l’AKS.

Source Description
Métriques de plateforme Les métriques de plateforme sont collectées automatiquement pour les clusters AKS gratuitement. Vous pouvez analyser ces métriques avec l’Explorateur de métriques ou les utiliser pour les alertes de métriques.
Métriques Prometheus Quand vous activez le scraping d’indicateurs de performance pour votre cluster, le service géré pour Prometheus sur Azure Monitor collecte des indicateurs de performance Prometheus et les stocke dans un espace de travail Azure Monitor. Analysez-les avec des tableaux de bord prédéfinis dans Azure Managed Grafana et avec des alertes Prometheus.
Journaux d’activité Le journal d’activité est collecté automatiquement pour les clusters AKS gratuitement. Ces journaux suivent les informations telles qu’un cluster est créé ou a une modification de configuration. Pour l’analyser avec vos autres données de journal, envoyez le journal d’activité à un espace de travail Log Analytics.
Journaux d’activité de ressources Les journaux du plan de contrôle pour AKS sont implémentés en tant que journaux de ressources. Créez un paramètre de diagnostic pour les envoyer à l’espace de travail Log Analytics , où vous pouvez les analyser et les alerter avec des requêtes de journal dans Log Analytics.
Container Insights Container Insights collecte différents journaux d’activité et données de performance à partir d’un cluster, notamment des flux stdout/stderr. Il les stocke ensuite dans un espace de travail Log Analytics et dans Azure Monitor Metrics. Analysez ces données avec des vues et des classeurs inclus dans Container Insights ou avec Log Analytics et l’Explorateur de métriques.
Application Insights Azure Monitor Application Insights collecte les journaux, les métriques et les traces distribuées. Cette télémétrie est stockée dans un espace de travail Log Analytics pour être analysée dans le portail Azure.

Types de ressource

Azure utilise le concept de types de ressources et d’ID pour identifier tout dans un abonnement. Les types de ressource font également partie des ID de ressource pour chaque ressource exécutée dans Azure. Par exemple, le type de ressource pour une machine virtuelle peut être Microsoft.Compute/virtualMachines. Pour obtenir la liste des services et leurs types de ressource associés, consultez Fournisseurs de ressources.

Azure Monitor organise de même manière les données de supervision de base en métriques et journaux en fonction des types de ressources, également appelés espaces de noms. Différentes métriques et journaux sont disponibles pour les différents types de ressource. Votre service peut être associé à plusieurs types de ressource.

Pour plus d’informations sur les types de ressources pour AKS, consultez la référence des données de surveillance Azure Kubernetes Service.

Stockage des données

Pour Azure Monitor :

  • Les données de métriques sont stockées dans la base de données des métriques Azure Monitor.
  • Les données de journal sont stockées dans le magasin de journaux Azure Monitor. Log Analytics est un outil du portail Azure qui peut interroger ce magasin.
  • Le journal d’activité Azure est un magasin distinct avec sa propre interface dans le portail Azure.

Vous pouvez aussi envoyer les données des métriques et des journaux d’activité vers le magasin de journaux Azure Monitor. Vous pouvez ensuite utiliser Log Analytics pour interroger les données et les mettre en corrélation avec d’autres données de journal.

De nombreux services peuvent utiliser les paramètres de diagnostic pour envoyer les données des métriques et des journaux vers d’autres emplacements de stockage en dehors d’Azure Monitor. Il peut ainsi s’agit du Stockage Azure, des systèmes partenaires hébergés et des systèmes partenaires non-Azure, en utilisant Event Hubs.

Pour plus d’informations sur la façon dont Azure Monitor stocke les données, consultez Plateforme de données Azure Monitor.

Métriques de plateforme Azure Monitor

Azure Monitor fournit des métriques de plateforme pour la plupart des services. Ces mesures sont :

  • Définies individuellement pour chaque espace de noms.
  • Stockées dans la base de données de métriques de série chronologique Azure Monitor.
  • Légères et capables de prendre en charge les alertes en quasi-temps réel.
  • Utilisées pour suivre les performances d’une ressource au fil du temps.

Collecte : Azure Monitor collecte automatiquement les métriques de plateforme. Aucune configuration n'est requise.

Routage : vous pouvez également acheminer certaines mesures de plateforme vers Azure Monitor Logs/Log Analytics afin de pouvoir les interroger avec d’autres données de journal. Vérifiez le paramètre d’exportation DS pour chaque métrique pour voir si vous pouvez utiliser un paramètre de diagnostic pour acheminer la métrique vers Azure Monitor Logs/Log Analytics.

Pour obtenir la liste de toutes les métriques qu’il est possible de collecter pour toutes les ressources dans Azure Monitor, consultez Métriques prises en charge dans Azure Monitor.

Pour obtenir une liste des indicateurs de performance disponibles pour AKS, consultez la référence des données de surveillance Azure Kubernetes Service.

Les métriques jouent un rôle important dans la surveillance des clusters, l’identification des problèmes et l’optimisation des performances dans les clusters AKS. Les métriques de plateforme sont capturées à l’aide du serveur de métriques prêt à l’emploi installé dans l’espace de noms kube-system, qui extrait régulièrement les métriques de tous les nœuds Kubernetes servis par Kubelet. Vous devez également activer les métriques Prometheus gérées par Azure pour collecter des métriques de conteneur et des métriques d’objet Kubernetes, comme l’état de l’objet des déploiements. Pour plus d’informations, consultez Collecter des indicateurs de performance Prometheus à partir d’un cluster AKS.

AKS expose également des indicateurs de performance à partir de composants critiques du plan de contrôle, tels que le serveur API, ETCD et Scheduler via Prometheus géré par Azure. Actuellement, cette fonctionnalité est uniquement disponible en tant que version préliminaire. Pour plus d’informations, consultez Surveiller les indicateurs de performance du plan de contrôle Azure Kubernetes Service (AKS) (préversion).

Métriques non basées sur Azure Monitor

Ce service fournit d’autres métriques qui ne sont pas comprises dans la base de données de métriques Azure Monitor.

Les services et fonctionnalités Azure suivants d’Azure Monitor peuvent être utilisés pour une meilleure surveillance de vos clusters Kubernetes. Vous pouvez activer ces fonctionnalités pendant la création d’un cluster AKS à partir de l’onglet Intégrations dans le portail Azure, Azure CLI, Terraform, Azure Policy ou intégrer votre cluster ultérieurement. Chacune de ces fonctionnalités peut entraîner des coûts supplémentaires. Reportez-vous donc aux informations tarifaires pour chacune d’elles avant de les activer.

Service / Fonctionnalité Description
Container Insights Utilise une version conteneurisée de l’agent Azure Monitor pour collecter les journaux stdout/stderr et des événements Kubernetes de chaque nœud dans votre cluster. La fonctionnalité prend en charge différents scénarios de surveillance pour les clusters AKS. Vous pouvez activer la surveillance d’un cluster AKS lors de sa création à l’aide d’Azure CLI, d’Azure Policy, du Portail Azure ou de Terraform. Si vous n’activez pas Container Insights lors de la création de votre cluster, consultez Activer container insights pour Azure Kubernetes Service cluster (AKS) pour obtenir d’autres options permettant de l’activer.

Container Insights stocke la plupart de ses données dans un espace de travail Log Analytics et vous utilisez généralement le même espace que celui pour les journaux de ressources de votre cluster. Consultez Concevoir une architecture d’espace de travail Log Analytics pour obtenir des conseils sur le nombre d’espaces de travail à utiliser et leur emplacement.
Service Azure Monitor géré pour Prometheus Prometheus est une solution d’indicateurs de performance natifs cloud fournie par la Cloud Native Compute Foundation. Il s’agit de l’outil le plus courant pour collecter et analyser des données d’indicateurs de performance issues de clusters Kubernetes. Le service managé Azure Monitor pour Prometheus est une solution de supervision entièrement managée compatible Prometheus dans Azure. Si vous n’activez pas Prometheus managé lors de la création de votre cluster, consultez Collecter des métriques Prometheus à partir d’un cluster AKS pour obtenir d’autres options pour l’activer.

Le service managé Azure Monitor pour Prometheus stocke ses données dans un espace de travail Azure Monitor, qui est lié à un espace de travail Grafana afin que vous puissiez analyser les données avec Azure Managed Grafana.
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. 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. Si vous n’activez pas Grafana managé lorsque vous créez votre cluster, consultez Lier un espace de travail Grafana. Vous pouvez le lier à votre espace de travail Azure Monitor afin qu’il puisse accéder aux indicateurs de performance Prometheus pour votre cluster.

Surveiller les indicateurs de performance du plan de contrôle AKS (préversion)

Cette section vous montre comment utiliser la fonctionnalité d’indicateurs de performance du plan de contrôle (préversion). Collectez des métriques à partir du plan de contrôle et affichez les données de télémétrie dans Azure Monitor. La fonctionnalité d’indicateurs de performance du plan de contrôle est entièrement compatible avec Prometheus et Grafana. La fonctionnalité offre une meilleure visibilité sur la disponibilité et les performances des composants du plan de contrôle, tels que le serveur API, ETCD, Scheduler, la mise à l’échelle automatique et le gestionnaire de contrôleurs. Vous pouvez utiliser ces métriques pour optimiser l’observabilité globale et maintenir l’excellence opérationnelle de votre cluster AKS.

Conditions préalables et limitations

Installer l’extension aks-preview

Important

Les fonctionnalités d’évaluation AKS sont disponibles en libre-service et font l’objet d’un abonnement. Les préversions sont fournies « en l’état » et « en fonction des disponibilités », et sont exclues des contrats de niveau de service et de la garantie limitée. Les préversions AKS sont, dans la mesure du possible, partiellement couvertes par le service clientèle. Telles quelles, ces fonctionnalités ne sont pas destinées à une utilisation en production. Pour plus d’informations, consultez les articles de support suivants :

  • Installez ou mettez à jour l’extension de l’interface de ligne de commande Azure aks-preview en utilisant la commande az extension add ou az extension update.

    # Install the aks-preview extension
az extension add --name aks-preview

# Update the aks-preview extension
az extension update --name aks-preview

Inscrire l’indicateur AzureMonitorMetricsControlPlanePreview

  1. Inscrivez l’indicateur de fonctionnalité AzureMonitorMetricsControlPlanePreview à l’aide de la commande az feature register.

    az feature register --namespace "Microsoft.ContainerService" --name "AzureMonitorMetricsControlPlanePreview"

    Quelques minutes sont nécessaires pour que l’état s’affiche Registered (Inscrit).

  2. Vérifiez l’état de l’inscription en utilisant la commande az feature show.

    az feature show --namespace "Microsoft.ContainerService" --name "AzureMonitorMetricsControlPlanePreview"

  3. Quand l’état reflète Inscrit, actualisez l’inscription du fournisseur de ressources Microsoft.ContainerService à l’aide de la commande az provider register.

    az provider register --namespace "Microsoft.ContainerService"

Activer les métriques du plan de contrôle sur votre cluster AKS

Vous pouvez activer les métriques du plan de contrôle avec le service Azure Monitor géré Prometheus pendant la création d’un nouveau cluster ou la mise à jour d’un cluster existant.

Activer les indicateurs de performance du plan de contrôle sur un nouveau cluster AKS :

Pour collecter des métriques Prometheus à partir de votre cluster Kubernetes, consultez Activer Prometheus et Grafana pour les clusters Kubernetes et suivez les étapes sous l’onglet interface de ligne de commande pour un cluster AKS.

Activer les métriques du plan de contrôle sur un cluster AKS existant

  • Si votre cluster dispose déjà de l’extension Prometheus, mettez à jour le cluster pour vous assurer qu’il commence à collecter les métriques du plan de contrôle à l’aide de la commande az aks update.

    az aks update --name $CLUSTER_NAME --resource-group $RESOURCE_GROUP

Remarque

Contrairement aux métriques collectées à partir de nœuds de cluster, les métriques du plan de contrôle sont collectées par un composant qui ne fait pas partie du module complémentaire ama-metrics. L’activation de l’indicateur de fonctionnalité AzureMonitorMetricsControlPlanePreview et de l’extension Prometheus géré garantit que les métriques du plan de contrôle sont collectées. Après avoir activé la collecte de métriques, l’affichage des données dans l’espace de travail peut prendre plusieurs minutes.

Requête sur les métriques du plan de contrôle

Les métriques du plan de contrôle sont stockées dans un espace de travail Azure Monitor dans la région du cluster. Vous pouvez chercher des informations dans les métriques directement à partir de l’espace de travail ou via l’instance Azure gérée pour Grafana connectée à l’espace de travail.

Affichez les métriques du plan de contrôle dans l’espace de travail Azure Monitor en procédant comme suit :

  1. Dans le portail Azure, accédez à votre cluster AKS.

  2. Sous Supervision, sélectionnez Insights.

    Capture d’écran de l’espace de travail Azure Monitor.

Remarque

AKS fournit des modèles de tableau de bord pour vous aider à afficher et analyser vos données de télémétrie de plan de contrôle en temps réel. Si vous utilisez Azure géré pour Grafana pour visualiser les données, vous pouvez importer les tableaux de bord suivants :

Personnaliser les métriques du plan de contrôle

AKS inclut un ensemble préconfiguré de métriques à collecter et stocker pour chaque composant. API server et etcd sont activés par défaut. Vous pouvez personnaliser cette liste via le ama-settings-configmap.

Les cibles par défaut comprennent les valeurs suivantes :

controlplane-apiserver = true
controlplane-cluster-autoscaler = false
controlplane-kube-scheduler = false
controlplane-kube-controller-manager = false
controlplane-etcd = true

Toutes les ressources ConfigMaps doivent être appliqués à l’espace de noms kube-system pour n’importe quel cluster.

Pour plus d’informations sur les métriques de profil minimal-ingestion, consultez le Profil d’ingestion minimal pour les métriques du plan de contrôle dans l’extension Prometheus gérée.

  • Ingérer uniquement des métriques minimales pour les cibles par défaut

    Lorsque vous définissez default-targets-metrics-keep-list.minimalIngestionProfile="true", seul le jeu minimal de métriques est ingéré pour chacune des cibles par défaut : controlplane-apiserver et controlplane-etcd.

  • Ingérer toutes les métriques de toutes les cibles

    Procédez comme suit pour collecter toutes les métriques de toutes les cibles sur le cluster :

    1. Téléchargez le fichier ConfigMap ama-metrics-settings-configmap.yaml et renommez-le en configmap-controlplane.yaml.

    2. Définissez minimalingestionprofile = false.

    3. Sous default-scrape-settings-enabled, vérifiez que les cibles que vous souhaitez scraper sont définies sur true. Les seules cibles que vous pouvez spécifier sont : controlplane-apiserver, controlplane-cluster-autoscaler, controlplane-kube-scheduler, controlplane-kube-controller-manageret controlplane-etcd.

    4. Appliquez la ConfigMap avec la commande kubectl apply.

      kubectl apply -f configmap-controlplane.yaml

      Une fois la configuration appliquée, plusieurs minutes sont nécessaires avant que les métriques des cibles spécifiées extraites du plan de contrôle apparaissent dans l’espace de travail Azure Monitor.

  • Ingérer quelques autres métriques en plus des métriques minimales

    minimal ingestion profile est un paramètre qui permet de réduire le volume d’ingestion de métriques, car seules les métriques utilisées par les tableaux de bord par défaut, les règles d’enregistrement par défaut et les alertes par défaut sont collectées. Pour personnaliser ce paramètre, procédez comme suit :

    1. Téléchargez le fichier ConfigMap ama-metrics-settings-configmap et renommez-le en configmap-controlplane.yaml.

    2. Définissez minimalingestionprofile = true.

    3. Sous default-scrape-settings-enabled, vérifiez que les cibles que vous souhaitez scraper sont définies sur true. Les seules cibles que vous pouvez spécifier sont : controlplane-apiserver, controlplane-cluster-autoscaler, controlplane-kube-scheduler, controlplane-kube-controller-manageret controlplane-etcd.

    4. Sous default-targets-metrics-keep-list, spécifiez la liste des métriques pour les cibles de true. Par exemple :

      controlplane-apiserver= "apiserver_admission_webhook_admission_duration_seconds| apiserver_longrunning_requests"

    5. Appliquez la ConfigMap avec la commande kubectl apply.

      kubectl apply -f configmap-controlplane.yaml

    Une fois la configuration appliquée, plusieurs minutes sont nécessaires avant que les métriques des cibles spécifiées extraites du plan de contrôle apparaissent dans l’espace de travail Azure Monitor.

  • Ingérer uniquement des métriques spécifiques à partir de certaines cibles

    1. Téléchargez le fichier ConfigMap ama-metrics-settings-configmap et renommez-le en configmap-controlplane.yaml.

    2. Définissez minimalingestionprofile = false.

    3. Sous default-scrape-settings-enabled, vérifiez que les cibles que vous souhaitez scraper sont définies sur true. Les seules cibles que vous pouvez spécifier ici sont controlplane-apiserver, controlplane-cluster-autoscaler, controlplane-kube-scheduler,controlplane-kube-controller-manageret controlplane-etcd.

    4. Sous default-targets-metrics-keep-list, spécifiez la liste des métriques pour les cibles de true. Par exemple :

      controlplane-apiserver= "apiserver_admission_webhook_admission_duration_seconds| apiserver_longrunning_requests"

    5. Appliquez la ConfigMap avec la commande kubectl apply.

      kubectl apply -f configmap-controlplane.yaml

      Une fois la configuration appliquée, plusieurs minutes sont nécessaires avant que les métriques des cibles spécifiées extraites du plan de contrôle apparaissent dans l’espace de travail Azure Monitor.

Résoudre les problèmes liés aux métriques du plan de contrôle

Veillez à vérifier que l’indicateur de fonctionnalité AzureMonitorMetricsControlPlanePreview est activé et que les pods ama-metrics s’exécutent.

Remarque

Les méthodes de résolution des problèmes pour le service Azure géré pour Prometheus ne se traduisent pas directement ici, car les composants qui scrapent le plan de contrôle ne sont pas présents dans l’extension gérée pour Prometheus.

  • Mise en forme ConfigMap

    Vérifiez que vous utilisez une mise en forme appropriée dans la ressource ConfigMap et que les champs, en particulier default-targets-metrics-keep-list, minimal-ingestion-profile et default-scrape-settings-enabled, sont correctement renseignés avec leurs valeurs prévues.

  • Isoler le plan de contrôle du plan de données

    Commencez par définir certaines des métriques liées au nœud sur true et vérifiez que les métriques sont transférées à l’espace de travail. Cela permet de déterminer si le problème est spécifique aux métriques du plan de contrôle de scraping.

  • Événements ingérés

    Une fois les modifications appliquées, vous pouvez ouvrir Metrics Explorer à partir de la page Vue d’ensemble d’Azure Monitor ou de la section Surveillance du cluster sélectionné et rechercher une augmentation ou une diminution du nombre d’événements ingérés par minute. Cela devrait vous aider à déterminer s’il manque une métrique spécifique ou si toutes les métriques sont manquantes.

  • Aucune métrique spécifique n’est exposée

    Il existe des cas où les métriques sont documentées, mais ne sont pas exposées à partir de la cible et ne sont pas transférées à l’espace de travail Azure Monitor. Dans ce cas, il est nécessaire de vérifier que d’autres métriques sont transférées à l’espace de travail.

  • Aucun accès à l’espace de travail Azure Monitor

    Lorsque vous activez le module complémentaire, vous pourriez spécifier un espace de travail existant auquel vous n’avez pas accès. Dans ce cas, il semblerait que les métriques ne sont ni collectées ni transférées. Veillez à créer un espace de travail lors de l’activation du module complémentaire ou lors de la création du cluster.

Désactiver les métriques du plan de contrôle sur votre cluster AKS

Vous pouvez désactiver les métriques du plan de contrôle à tout moment en désactivant l’extension gérée pour Prometheus managé et en annulant l’inscription de l’indicateur de fonctionnalité AzureMonitorMetricsControlPlanePreview.

  1. Supprimez le l’extension de métriques qui scrape les métriques Prometheus à l’aide de la commande az aks update.

    az aks update --disable-azure-monitor-metrics --name $CLUSTER_NAME --resource-group $RESOURCE_GROUP

  2. Désactivez le scraping des métriques du plan de contrôle sur le cluster AKS en annulant l’inscription de l’indicateur de fonctionnalité AzureMonitorMetricsControlPlanePreview en utilisant la commande az feature unregister.

    az feature unregister "Microsoft.ContainerService" --name "AzureMonitorMetricsControlPlanePreview"

Forum aux questions

  • Puis-je scraper les métriques du plan de contrôle avec Prometheus auto-hébergé ?

    Non, vous ne pouvez pas scraper les métriques du plan de contrôle avec Prometheus auto-hébergé. Prometheus auto-hébergé peut uniquement scraper l’instance unique en fonction de l’équilibreur de charge. Les métriques ne sont pas fiables, car il existe souvent plusieurs réplicas des métriques du plan de contrôle uniquement visibles via Prometheus géré

  • Pourquoi l’agent utilisateur n’est-il pas disponible via les métriques du plan de contrôle ?

    Les métriques du plan de contrôle dans Kubernetes ne comportent pas l’agent utilisateur. L’agent utilisateur est disponible uniquement via les journaux d’activité du plan de contrôle disponibles dans les paramètres de diagnostic.

Journaux de ressources Azure Monitor

Les journaux de ressource fournissent des insights sur les opérations effectuées par une ressource Azure. Les journaux sont générés automatiquement, mais vous devez les router vers les journaux Azure Monitor pour les enregistrer ou les interroger. Les journaux d’activité sont organisés en catégories. Un espace de noms donné peut avoir plusieurs catégories de journal de ressource.

Collecte : les journaux de ressource ne sont pas collectés ni stockés tant que vous n’avez pas créé un paramètre de diagnostic et routé les journaux vers un ou plusieurs emplacements. Lorsque vous créez un paramètre de diagnostic, vous spécifiez les catégories de journaux à collecter. Il existe plusieurs façons de créer et gérer des paramètres de diagnostic, notamment le portail Azure, programmatiquement et avec Azure Policy.

Routage : la valeur par défaut suggérée est le routage des journaux de ressource vers les journaux Azure Monitor afin de pouvoir les interroger avec d’autres données de journal. D’autres emplacements comme le Stockage Azure, Azure Event Hubs et certains partenaires de monitoring de Microsoft sont également disponibles. Pour plus d’informations, consultez Journaux de ressource Azure et Destinations des journaux de ressource.

Pour plus d’informations sur la collecte, le stockage et le routage des journaux de ressource, consultez Paramètres de diagnostic dans Azure Monitor.

Pour obtenir la liste de toutes les catégories de journal de ressource disponibles dans Azure Monitor, consultez Journaux de ressource pris en charge dans Azure Monitor.

Tous les journaux de ressource dans Azure Monitor ont les mêmes champs d’en-tête, suivis de champs propres au service. Le schéma commun est décrit dans Schéma des journaux des ressources Azure Monitor.

Pour connaître les catégories disponibles de journaux de ressources, leurs tables Log Analytics associées et les schémas de journaux pour AKS, consultez Référence sur les données de surveillance Azure Kubernetes Service.

Journaux du plan de contrôle/des ressources AKS

Les journaux du plan de contrôle pour les clusters AKS sont implémentés en tant que journaux de ressources dans Azure Monitor. Les journaux de ressources ne sont pas collectés ni stockés tant que vous n’avez pas créé un paramètre de diagnostic pour les acheminer vers un ou plusieurs emplacements. Vous les envoyez généralement à un espace de travail Log Analytics où sont stockées la plupart des données pour Container Insights.

Pour plus d’informations sur la création des paramètres de diagnostic à l’aide du portail Azure, de l’interface CLI ou de PowerShell, consultez Créer un paramètre de diagnostic. Lorsque vous créez un paramètre de diagnostic, vous spécifiez les catégories de journaux à collecter. Les catégories d’AKS sont répertoriées dans référence des données de surveillance AKS.

Important

Il peut y avoir des coûts importants lors de la collecte des journaux de ressources pour AKS, en particulier pour les journaux d’audit kube. Tenez compte des recommandations suivantes pour réduire la quantité de données collectées :

  • Désactivez la journalisation kube-audit lorsqu’elle n’est pas nécessaire.
  • Activez une collection à partir de kube-audit-admin qui exclut les événements d’audit liste et get.
  • Activez les journaux spécifiques aux ressources comme décrit ici, puis configurez la table AKSAudit en tant que journaux d’activité basiques.

Pour obtenir d’autres stratégies sur l’optimisation de vos coûts, consultez Surveiller les clusters Kubernetes à l’aide des services Azure et d’outils natifs cloud et Optimisation des coûts et Azure Monitor.

AKS prend en charge le mode Diagnostics Azure ou le mode spécifique aux ressources pour des journaux de ressources. Ce mode spécifie les tables de l’espace de travail Log Analytics où les données sont envoyées. Le mode Diagnostics Azure envoie toutes les données à la table AzureDiagnostics, tandis que le mode spécifique aux ressources envoie des données à AKS Audit, AKS Audit Administration et Plan de contrôle AKS, comme indiqué dans le tableau Journaux de ressources.

Nous vous recommandons le mode spécifique aux ressources pour AKS pour les raisons suivantes :

  • Les données sont plus faciles à interroger, car elles se situent dans des tables individuelles dédiées à AKS.
  • Prend en charge la configuration en tant que journaux de base pour bénéficier d’économies importantes.

Pour obtenir plus de détails sur la différence entre les modes de collecte, notamment sur la façon de modifier un paramètre existant, consultez Sélectionner le mode de collecte.

Remarque

Il est également possible de configurer les paramètres de diagnostic via l’interface CLI. Dans ces cas, il n’est pas garanti que cela fonctionne correctement, car l’état d’approvisionnement du cluster n’est pas vérifié. Veillez à vérifier les paramètres de diagnostic du cluster concerné après l’avoir configuré.

az monitor diagnostic-settings create --name AKS-Diagnostics --resource /subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/myresourcegroup/providers/Microsoft.ContainerService/managedClusters/my-cluster --logs '[{"category": "kube-audit","enabled": true}, {"category": "kube-audit-admin", "enabled": true}, {"category": "kube-apiserver", "enabled": true}, {"category": "kube-controller-manager", "enabled": true}, {"category": "kube-scheduler", "enabled": true}, {"category": "cluster-autoscaler", "enabled": true}, {"category": "cloud-controller-manager", "enabled": true}, {"category": "guard", "enabled": true}, {"category": "csi-azuredisk-controller", "enabled": true}, {"category": "csi-azurefile-controller", "enabled": true}, {"category": "csi-snapshot-controller", "enabled": true}]'  --workspace /subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourcegroups/myresourcegroup/providers/microsoft.operationalinsights/workspaces/myworkspace --export-to-resource-specific true

Exemples de requêtes de journal

Important

Lorsque vous sélectionnez Journaux dans le menu d’un cluster AKS, Log Analytics s’ouvre avec l’étendue de la requête définie sur le cluster actuel. Cela signifie que les requêtes de journal n’incluront que les données de cette ressource. Si vous voulez exécuter une requête qui inclut des données provenant d’autres clusters ou d’autres services Azure, sélectionnez Journaux dans le menu Azure Monitor. Pour plus d’informations, consultez Étendue de requête de journal et intervalle de temps dans la fonctionnalité Log Analytics d’Azure Monitor.

Si le paramètre de diagnostic de votre cluster utilise le mode Diagnostics Azure, les journaux de ressources pour AKS sont stockés dans la table AzureDiagnostics. Vous pouvez distinguer les différents journaux à l'aide de la colonne Catégorie. Pour une description de chaque catégorie, voir les journaux de ressources de référence AKS.

Description Requête de journal
Compter les journaux pour chaque catégorie
(Mode Diagnostics Azure)		 AzureDiagnostics
| où ResourceType == « MANAGEDCLUSTERS »
| résumer count() par Category
Tous les journaux de serveur d’API
(Mode Diagnostics Azure)		 AzureDiagnostics
| où Category == « kube-apiserver »
Tous les journaux kube-audit dans un intervalle de temps
(Mode Diagnostics Azure)		 let starttime = datetime(« 2023-02-23 ») ;
let endtime = datetime(« 2023-02-24 »);
AzureDiagnostics
| où TimeGenerated entre (starttime..endtime)
| où Category == « kube-audit »
| prolonger event = parse_json(log_s)
| prolonger HttpMethod = tostring(event.verb)
| prolonger User = tostring(event.user.username)
| prolonger Apiserver = pod_s
| prolonger SourceIP = tostring(event.sourceIPs[0])
| projet TimeGenerated, Category, HttpMethod, User, Apiserver, SourceIP, OperationName, event
Tous les journaux d’audit
(mode spécifique aux ressources)		 AKSAudit
Tous les journaux d'audit, à l'exception des événements d'audit obtenir et liste
(mode spécifique aux ressources)		 AKSAuditAdmin
Tous les journaux de serveur d’API
(mode spécifique aux ressources)		 AKSControlPlane
| où Category == « kube-apiserver »

Pour accéder à un ensemble de requêtes prédéfinies dans l’espace de travail Log Analytics, consultez l’interface des requêtes Log Analytics et sélectionnez le type de ressource Kubernetes Services. Pour obtenir la liste des requêtes courantes pour Container Insights, consultez Requêtes Container Insights.

Journaux du plan de données AKS/Container Insights

Container Insights collecte différents types de données de télémétrie à partir de conteneurs et de clusters Kubernetes pour vous aider à surveiller, dépanner et obtenir des insights sur vos applications conteneurisées s’exécutant dans vos clusters AKS. Pour obtenir une liste des tables et leurs descriptions détaillées utilisées par Container insights, consultez la référence des tables Azure Monitor. Toutes ces tables sont disponibles pour les requêtes de journal.

Les paramètres d’optimisation des coûts offrent aux utilisateurs la possibilité de personnaliser et de contrôler les données de métriques collectées via l’agent Container Insights. Cette fonctionnalité prend en charge les paramètres de collecte de données de la sélection de table individuelle, des intervalles de collecte de données et les espaces de noms à exclure de la collecte de données via les règles de collecte de données (DCR) Azure Monitor. Ces paramètres contrôlent le volume d’ingestion et réduisent les coûts de surveillance de Container Insights. Les données collectées par les insights de conteneur peuvent être personnalisées via le portail Azure, à l’aide des options suivantes. La sélection d’autres options que Tous (par défaut) entraîne l’indisponibilité de l’expérience des insights de conteneur.

Regroupement Tableaux Notes
Tous (valeur par défaut) Toutes les tables standard des insights de conteneur Requis pour activer les visualisations d’insights de conteneur par défaut
Performances Niveau de performance, InsightsMetrics
Journaux et événements ContainerLog ou ContainerLogV2, KubeEvents, KubePodInventory Recommandé si vous activez les métriques Prometheus managées
Charges de travail, déploiements et HPA InsightsMetrics, KubePodInventory, KubeEvents, ContainerInventory, ContainerNodeInventory, KubeNodeInventory, KubeServices
Volumes persistants InsightsMetrics, KubePVInventory

Le regroupement Journaux d’activité et d’événements capture les journaux des ContainerLog ou ContainerLogV2, KubeEvents, les tables KubePodInventory, mais pas les métriques. Le chemin recommandé pour collecter des métriques consiste à activer le Service managé Azure Monitor Prometheus pour Prometheus à partir de votre cluster AKS et à utiliser Azure Managed Grafana pour la visualisation des données. Pour plus d’informations, consultezGérer un espace de travail Azure Monitor.

Schéma de ContainerLogV2

Azure Monitor Container Insights fournit un schéma pour les journaux de conteneurs appelés ContainerLogV2, qui est l’option recommandée. Ce format inclut les champs suivants pour faciliter les requêtes courantes pour l’affichage des données relatives aux clusters Kubernetes avec AKS et Azure Arc :

  • ContainerName
  • PodName
  • PodNamespace

De plus, ce schéma est compatible avec le plan de données Journaux basiques qui offrent une alternative à faible coût aux journaux d’analytique standard. Le forfait de données de journal Essentiel vous permet d’économiser les coûts d’ingestion et de stockage de gros volumes de journaux d’activité verbeux dans votre espace de travail Log Analytics pour le débogage, le dépannage et l’audit. Cela n’affecte pas les coûts liés à l’analytique et aux alertes. Pour plus d’informations, consultez Gérer les tables dans un espace de travail Log Analytics.

ContainerLogV2 est l’approche recommandée pour les clients qui intégreront container Insights avec l’authentification d’identité managée à l’aide de l’intégration ARM, Bicep, Terraform, Policy et le portail Azure. Pour plus d’informations sur l’activation de ContainerLogV2 via la règle de collecte de données (DCR) ou ConfigMap du cluster, consultez Activer le schéma ContainerLogV2.

Journal des activités Azure

Le journal d’activité contient des évènements au niveau de l’abonnement qui suivent les opérations sur chaque ressource Azure qui sont vues comme extérieures à cette ressource, par exemple, la création d’une ressource ou le démarrage d’une machine virtuelle.

Collecte : les évènements de journal d’activité sont générés et collectés automatiquement dans un magasin distinct pour leur consultation dans le portail Azure.

Routage : vous pouvez envoyer les données de journal d’activité aux journaux Azure Monitor afin de pouvoir les analyser en même temps que d’autres données de journal. D’autres emplacements comme le Stockage Azure, Azure Event Hubs et certains partenaires de monitoring de Microsoft sont également disponibles. Pour plus d’informations sur le routage du journal d’activité, consultez Vue d’ensemble du journal d’activité Azure.

Afficher les journaux de conteneurs, les événements et les mesures de pod Azure Kubernetes Service (AKS) en temps réel

Dans cette section, vous apprenez à utiliser la fonctionnalité de données en direct dans Container Insights pour afficher les journaux de conteneur, les événements et les indicateurs de performance de pod Azure Kubernetes Service (AKS) en temps réel. Cette fonctionnalité fournit un accès dynamique à kubectl logs -c, événements kubectl get et kubectl top pods pour vous aider à résoudre les problèmes en temps réel.

Remarque

AKS utilise des architectures de journalisation au niveau du cluster Kubernetes. Les journaux de conteneur se trouvent à l’intérieur /var/log/containers sur le nœud. Pour accéder à un nœud, consulter Se connecter à des nœuds de cluster Azure Kubernetes Service (AKS).

Pour obtenir de l’aide sur la configuration de la fonctionnalité de données actives, consultez Configurer des données actives dans Container Insights. Cette fonctionnalité accède directement à l’API Kubernetes. Pour plus d’informations sur le modèle d’authentification, consultez API Kubernetes.

Afficher les journaux dynamiques des ressources AKS

Remarque

Pour accéder aux journaux à partir d’un cluster privé, vous devez être sur un ordinateur sur le même réseau privé que le cluster.

  1. Dans le portail Azure, accédez à votre cluster AKS.

  2. Sous Ressources Kubernetes, sélectionnez Charges de travail.

  3. Sélectionnez le Déploiement, le Pod, le Jeu de réplicas, le StatefulSet, la Tâche ou la Tâche Cron pour laquelle vous souhaitez afficher les journaux d’activité, puis sélectionnez Journaux dynamiques.

  4. Sélectionnez la ressource pour laquelle vous souhaitez afficher les journaux.

    L’exemple suivant montre les journaux d’une ressource Pod :

    Capture d’écran montrant le déploiement de journaux dynamiques.

Afficher les journaux d’activité dynamiques

Vous pouvez voir les données des journaux en temps réel à mesure qu’elles sont générées par le moteur de conteneur dans le Cluster, les Nœuds, les Contrôleurs ou les Conteneurs.

  1. Dans le portail Azure, accédez à votre cluster AKS.

  2. Sous Supervision, sélectionnez Insights.

  3. Sélectionnez l’onglet Cluster, Nœuds, Contrôleursou Conteneurs, puis sélectionnez l’objet pour lequel vous souhaitez afficher les journaux d’activité.

  4. Dans la Vue d’ensemble de la ressource, sélectionnez Journaux dynamiques.

    Remarque

    Pour afficher les données de votre espace de travail Log Analytics, sélectionnez Afficher les journaux dans Logs Analytics. Pour en savoir plus sur l’affichage des journaux, des événements et des métriques historiques, consultez Comment interroger les journaux à partir des informations sur les conteneurs.

    Une fois l’authentification réussie, si les données peuvent être récupérées, elles commencent à être diffusées en continu dans l’onglet Journaux dynamiques. Vous pouvez afficher les données de journal ici dans un flux continu. L’image suivante montre les journaux d’une ressource Conteneur :

    Capture d’écran montrant l’option de données de la vue Journaux dynamiques du conteneur.

Afficher les événements dynamiques

Vous pouvez voir les données des événements en temps réel à mesure qu’elles sont générées par le moteur de conteneur dans Cluster, Nœuds, Contrôleurs ou Conteneurs.

  1. Dans le portail Azure, accédez à votre cluster AKS.

  2. Sous Supervision, sélectionnez Insights.

  3. Sélectionnez l’onglet Cluster, Nœuds, Contrôleursou Conteneurs, puis sélectionnez l’objet pour lequel vous souhaitez afficher les événements d’activité.

  4. Dans la page Vue d’ensemble de la ressource, sélectionnez Événements dynamiques.

    Remarque

    Pour afficher les données de votre espace de travail Log Analytics, sélectionnez Afficher les événements dans Logs Analytics. Pour en savoir plus sur l’affichage des journaux, des événements et des métriques historiques, consultez Comment interroger les journaux à partir des informations sur les conteneurs.

    Une fois l’authentification réussie, si les données peuvent être récupérées, elles commencent à être diffusées en continu dans l’onglet Événements en direct. L’image suivante montre les événements d’une ressource Conteneur :

    Capture d’écran montrant l’option de données de la vue Événements dynamiques du conteneur.

Afficher les mesures

Vous pouvez afficher les données d’indicateurs de performance en temps réel, car elles sont générées par le moteur de conteneur sur les Nœuds ou Contrôleurs en sélectionnant une ressource Pod.

  1. Dans le portail Azure, accédez à votre cluster AKS.

  2. Sous Supervision, sélectionnez Insights.

  3. Sélectionnez l’onglet Nœuds ou Contrôleurs, puis sélectionnez l’objet Pod pour lequel vous souhaitez afficher les mesures.

  4. Dans la page Vue d’ensemble de la ressource, sélectionnez Mesures dynamiques.

    Remarque

    Pour afficher les données de votre espace de travail Log Analytics, sélectionnez Afficher les événements dans Logs Analytics. Pour en savoir plus sur l’affichage des journaux, des événements et des métriques historiques, consultez Comment interroger les journaux à partir des informations sur les conteneurs.

    Une fois l’authentification réussie, si les données peuvent être récupérées, elles commencent à être diffusées en continu dans l’onglet Mesures dynamiques. L’image suivante montre les mesures d’une ressource Pod :

    Capture d’écran montrant l’option de données de la vue Mesures dynamiques de pod.

Analyser les données de surveillance

Il existe de nombreux outils pour analyser les données de supervision.

Outils Azure Monitor

Azure Monitor prend en charge les outils de base suivants :

Les outils qui permettent une visualisation plus complexe sont notamment :

  • Les tableaux de bord, qui vous permettent de combiner différentes sortes de données dans un même volet du portail Azure.
  • Les workbooks, des rapports personnalisables que vous pouvez créer dans le portail Azure. Les workbooks peuvent inclure du texte, des métriques et des requêtes de journal.
  • Grafana, un outil de plateforme ouvert, parfait pour les tableaux de bord opérationnels. Vous pouvez utiliser Grafana pour créer des tableaux de bord à partir de données de plusieurs sources autres qu’Azure Monitor.
  • Power BI, un service d’analyse métier qui fournit des visualisations interactives pour diverses sources de données. Vous pouvez configurer Power BI pour importer automatiquement les données de journal à partir d’Azure Monitor afin de tirer parti de ces visualisations supplémentaires.

Outils d’exportation Azure Monitor

Vous pouvez extraire des données d’Azure Monitor dans d’autres outils en utilisant les méthodes suivantes :

Pour bien démarrer avec l’API REST pour Azure Monitor, consultez Procédure pas à pas de l’API REST d’analyse Azure.

Page de présentation de la supervision dans Portail Azure

L’onglet Monitoring de la page Vue d’ensemble de votre ressource de cluster AKS offre un moyen rapide de commencer à afficher les données de monitoring dans le Portail Azure. Cet onglet inclut des graphiques avec des métriques courantes pour le cluster séparées par pool de nœuds. Vous pouvez sélectionner l’un de ces graphiques pour analyser plus en détail les données dans Metrics Explorer.

L’onglet Monitoring inclut également des liens vers le service géré pour Prometheus et Container Insights pour le cluster. Si vous avez besoin d’activer ces outils, vous pouvez le faire ici. Vous pouvez également voir une bannière en haut de l’écran vous recommandant d’activer d’autres fonctionnalités afin d’améliorer le monitoring de votre cluster.

Conseil

Vous pouvez accéder aux fonctionnalités de monitoring de tous les clusters AKS de votre abonnement en sélectionnant Azure Monitor dans la page d’accueil du Portail Azure.

Requêtes Kusto

Vous pouvez analyser les données de supervision dans les journaux Azure Monitor ou le magasin Log Analytics à l’aide du langage de requête Kusto (KQL).

Important

Quand vous sélectionnez Journaux dans le menu du service dans le portail, Log Analytics s’ouvre avec l’étendue de requête définie sur le service actuel. Cette étendue signifie que les requêtes de journal ont seulement des données de ce type de ressource. Si vous voulez exécuter une requête qui comprend des données d’autres services Azure, sélectionnez Journaux dans le menu Azure Monitor. Pour plus d’informations, consultez Étendue de requête de journal et intervalle de temps dans la fonctionnalité Log Analytics d’Azure Monitor.

Pour obtenir la liste des requêtes courantes pour n’importe quel service, consultez l’Interface de requêtes Log Analytics.

Alertes

Azure Monitor vous alerte de façon proactive quand des conditions spécifiques sont détectées dans vos données de monitoring. Les alertes permettent d’identifier et de résoudre les problèmes affectant votre système avant que vos clients ne les remarquent. Pour plus d’informations, consultez Alertes Azure Monitor.

Il existe de nombreuses sources d’alertes courantes pour les ressources Azure. Pour obtenir des exemples d’alertes courantes pour les ressources Azure, consultez Exemples de requêtes d’alerte de journal. Le site Azure Monitor Baseline Alerts (AMBA) fournit une méthode semi-automatisée pour implémenter les alertes, les tableaux de bord et les recommandations associés·es les plus importants·es aux métriques de plateforme. Le site s’applique à un sous-ensemble des services Azure en constante expansion, y compris tous les services qui font partie de la zone d’atterrissage Azure (ALZ).

Le schéma d’alerte commun standardise la consommation de notifications d'alerte pour Azure Monitor. Pour plus d’informations, consultez Schéma d’alerte courant.

Types d'alertes

Vous pouvez définir une alerte sur n’importe quelle source de données de métrique ou de journal dans la plateforme de données Azure Monitor. Il existe de nombreux types d’alertes différents en fonction des services que vous monitorez et des données de monitoring que vous collectez. Les différents types d’alertes ont divers avantages et inconvénients. Pour plus d’informations, consultez Choisir le bon type d’alerte de monitoring.

La liste suivante décrit les types d’alertes Azure Monitor que vous pouvez créer :

  • Les alertes de métrique évaluent les métriques de ressource à intervalles réguliers. Les métriques peuvent être des métriques de plateforme, des métriques personnalisées, des journaux provenant d’Azure Monitor convertis en métriques ou des métriques Application Insights. Les alertes de métriques peuvent également appliquer plusieurs conditions et seuils dynamiques.
  • Les alertes de journal permettent aux utilisateurs d’utiliser une requête Log Analytics pour évaluer les journaux de ressource à une fréquence prédéfinie.
  • Les alertes de journal d’activité sont déclenchées quand un nouvel événement de journal d’activité correspond à des conditions définies. Les alertes Resource Health et les alertes Service Health sont des alertes de journal d’activité qui concernent l’intégrité de votre service et de vos ressources.

Certains services Azure prennent également en charge les alertes de détection intelligente, les alertes Prometheus ou les règles d’alerte recommandées.

Pour certains services, vous pouvez opérer une surveillance à grande échelle en appliquant la même règle d’alerte de métrique à plusieurs ressources du même type qui existent dans la même région Azure. Les notifications individuelles sont envoyées pour chaque ressource supervisée. Pour connaître les services et clouds Azure pris en charge, consultez Monitorer plusieurs ressources avec une seule règle d’alerte.

Pour certains services Azure, vous pouvez activer des règles d’alerte recommandées prêtes à l’emploi.

Le système compile une liste de règles d’alerte recommandées en fonction des éléments suivants :

  • La connaissance par le fournisseur de la ressource des signaux et des seuils importants pour la surveillance de la ressource.
  • Données qui indiquent ce sur quoi les clients alertent généralement pour cette ressource.

Remarque

Les règles d’alerte recommandées sont disponibles pour :

  • Machines virtuelles
  • Ressources Azure Kubernetes Service (AKS)
  • Espaces de travail Log Analytics

Alertes basées sur les métriques Prometheus

Lorsque vous activez la collecte d’indicateurs de performance Prometheus pour votre cluster, vous pouvez télécharger une collection de règles d’alerte Prometheus recommandées. Le téléchargement inclut les règles suivantes :

Niveau Alertes
Au niveau du cluster KubeCPUQuotaOvercommit
KubeMemoryQuotaOvercommit
KubeContainerOOMKilledCount
KubeClientErrors
KubePersistentVolumeFillingUp
KubePersistentVolumeInodesFillingUp
KubePersistentVolumeErrors
KubeContainerWaiting
KubeDaemonSetNotScheduled
KubeDaemonSetMisScheduled
KubeQuotaAlmostFull
Niveau de nœud KubeNodeUnreachable
KubeNodeReadinessFlapping
Niveau de pod KubePVUsageHigh
KubeDeploymentReplicasMismatch
KubeStatefulSetReplicasMismatch
KubeHpaReplicasMismatch
KubeHpaMaxedOut
KubePodCrashLooping
KubeJobStale
KubePodContainerRestart
KubePodReadyStateLow
KubePodFailedState
KubePodNotReadyByController
KubeStatefulSetGenerationMismatch
KubeJobFailed
KubeContainerAverageCPUHigh
KubeContainerAverageMemoryHigh
KubeletPodStartUpLatencyHigh

Consultez Comment créer des alertes de journal à partir de Container Insights et Comment interroger des journaux à partir de Container Insights. Les Alertes de journal peuvent mesurer deux choses différentes, qui peuvent être utilisées pour surveiller des machines virtuelles dans différents scénarios :

  • Nombre de résultats : compte le nombre de lignes retournées par la requête et permet de travailler avec des événements comme des journaux des événements Windows, Syslog et les exceptions des applications.
  • Calcul d’une valeur : effectue des calculs sur une colonne numérique et permet d’inclure le nombre de ressources de votre choix. Par exemple, le pourcentage d’UC.

Selon le scénario d’alerte requis, les requêtes de journal doivent être créées en comparant un DateHeure à l’heure actuelle à l’aide de l’opérateur now et de revenir en arrière d’une heure. Pour apprendre comment créer des alertes basées sur des journaux, consultez Créer des alertes de journal à partir de Container Insights.

Règles d’alerte AKS

Le tableau suivant liste quelques suggestions de règles d’alerte pour AKS. Ces alertes ne sont que des exemples. Vous pouvez définir des alertes pour n’importe quel indicateur de performance, entrée de journal ou entrée de journal d’activité répertoriée dans la référence sur les données de surveillance d’Azure Kubernetes Service.

Condition Description
Pourcentage d’utilisation du processeur > 95 Se déclenche lorsque l’utilisation moyenne du processeur sur tous les nœuds dépasse le seuil.
Mémoire de plage de travail en pourcentage > 100 Se déclenche lorsque l’ensemble de travail moyen de tous les nœuds dépasse le seuil.

Recommandations d’Advisor

Pour certains services, si des conditions critiques ou des changements imminents se produisent pendant des opérations de ressources, une alerte s’affiche dans la page Vue d’ensemble du service concerné dans le portail. Des informations supplémentaires et les correctifs recommandés pour l’alerte sont disponibles dans les Recommandations Advisor sous Surveillance dans le menu de gauche. Pendant les opérations normales, aucune recommandation Advisor ne s’affiche.

Pour plus d’informations sur Azure Advisor, consultez Vue d’ensemble d’Azure Advisor.

Remarque

Si vous créez ou exécutez une application qui s’exécute sur votre service, il est possible qu’Azure Monitor Application Insights vous propose d’autres types d’alertes.

Observabilité du réseau

L’observabilité du réseau est une partie importante du maintien d’un cluster Kubernetes sain et performant. En collectant et en analysant des données sur le trafic réseau, vous pouvez obtenir des insights sur le fonctionnement de votre cluster et identifier les problèmes potentiels avant qu’ils ne provoquent des pannes ou une détérioration des performances.

Quand le module complémentaire d’Observabilité du réseau est activé, il permet la collecte et la conversion de mesures utiles au format Prometheus, qui peuvent ensuite être visualisées dans Grafana. Lorsque cette option est activée, les métriques collectées sont automatiquement ingérées dans le service managé Azure Monitor pour Prometheus. Un tableau de bord Grafana est disponible dans le dépôt public de tableaux de bord Grafana pour visualiser les métriques d’observabilité réseau collectées par Prometheus. Pour plus d’informations, consultez Configuration de l’observabilité du réseau pour obtenir des instructions détaillées.

Contenu connexe