Partager via

Analyser Azure Kubernetes Service (AKS)

La surveillance AKS nécessite plusieurs niveaux d’observabilité entre les métriques de plateforme, les métriques Prometheus, les journaux d’activité, les journaux de ressources et les informations sur les conteneurs. AKS fournit des fonctionnalités de supervision intégrées et s’intègre à Azure Monitor, Container Insights, service managé pour Prometheus et Azure Managed Grafana pour une analyse complète de l’intégrité et des performances des clusters.

Conseil

Vous pouvez utiliser Azure Copilot pour configurer la surveillance sur vos clusters AKS dans le portail Azure. Pour plus d’informations, consultez Utiliser efficacement des clusters AKS à l’aide d’Azure Copilot.

Insights

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.

Données de surveillance AKS : métriques, journaux d’activité, intégrations

AKS génère les mêmes types de données de surveillance que d’autres ressources Azure, comme décrit dans Surveiller les données à partir de ressources Azure. Pour plus d’informations sur les métriques et les journaux créés par AKS, consultez la référence des données de surveillance 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.

Diagramme des données de surveillance collectées à partir d’AKS.

Origine Descriptif
Métriques de plateforme Les mesures de plateforme sont automatiquement collectées pour les clusters AKS gratuitement. Vous pouvez analyser ces métriques à l’aide de l’Explorateur de métriques ou les utiliser pour créer des alertes de métriques.
Mesures Prometheus Lorsque vous activez la récupération des métriques pour votre cluster, le service managé pour Prometheus dans Azure Monitor collecte les métriques Prometheus et les stocke dans un espace de travail Azure Monitor. Analysez ces métriques à l’aide de tableaux de bord prédéfinis dans Azure Managed Grafana et avec des alertes Prometheus.
Journaux d’activité Le journal d’activité Azure Monitor collecte automatiquement certaines données pour les clusters AKS sans coût. Ces fichiers journaux effectuent le suivi des informations comme lorsqu’un cluster est créé ou que des modifications sont apportées à une configuration de cluster. Pour analyser les données du journal d’activité avec vos autres données de journal, envoyez des données de journal d’activité à un espace de travail Log Analytics.
Journaux d’activité de ressources Les journaux du plan de contrôle d’AKS sont implémentés en tant que journaux de ressources. Créez un paramètre de diagnostic pour envoyer des journaux de ressources à un espace de travail Log Analytics. Dans l’espace de travail, vous pouvez analyser les journaux à l’aide de requêtes et configurer des alertes en fonction des informations de journal.
Container Insights Container Insights collecte différents journaux et données de performances à partir d’un cluster et les stocke dans un espace de travail Log Analytics et dans les métriques Azure Monitor. Analysez les flux stdout et stderr à l’aide de vues et de classeurs dans Container Insights ou Log Analytics et l’explorateur de métriques.
Application Insights Application Insights, une fonctionnalité d’Azure Monitor, collecte les journaux, les mesures et les traces distribuées. Les données de télémétrie sont stockées dans un espace de travail Log Analytics à des fins d’analyse dans le portail Azure. 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, découvrez les principes de base de la collecte de données.

Types de ressources

Azure utilise le concept des types de ressources et des ID pour identifier chaque chose 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 façon similaire les données de surveillance de base en métriques et en 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 dans AKS, consultez la référence des données de surveillance AKS.

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 choisir d’acheminer les données des métriques et des journaux d’activité vers le magasin des journaux d’activité 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. Par exemple, le Stockage Azure, les systèmes partenaires hébergés et les 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 router la métrique vers les journaux Azure Monitor / 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 la liste des métriques que vous pouvez collecter pour AKS, consultez la référence des données de surveillance AKS.

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êtes à l’emploi installé dans l’espace kube-system de noms, qui extrait régulièrement les métriques de tous les nœuds AKS servis par kubelet. Vous devez également activer le service managé pour les métriques Prometheus pour collecter des métriques de conteneur et des métriques d’objet Kubernetes, y compris l’état du déploiement d’objets.

Vous pouvez afficher la liste des métriques Prometheus gérées par défaut.

Pour plus d’informations, consultez Collecter le service managé des mesures Prometheus d’un cluster AKS.

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.

Vous pouvez utiliser les services Azure suivants et les fonctionnalités Azure Monitor pour surveiller vos clusters AKS. Vous activez ces fonctionnalités lorsque vous créez un cluster AKS.

Dans le portail Azure, utilisez l’onglet Intégrations ou utilisez Azure CLI, Terraform ou Azure Policy. Dans certains cas, vous pouvez intégrer votre cluster à un service de surveillance ou une fonctionnalité après avoir créé le cluster. Chaque service ou fonctionnalité peut entraîner des coûts. Consultez donc les informations de tarification de chaque composant avant de l’activer.

Service ou fonctionnalité Descriptif
Container Insights Utilise une version conteneurisée de l’agent Azure Monitor pour collecter les journaux stdout et stderr et les événements Kubernetes de chaque nœud de 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 lorsqu’il est créé à l’aide d’Azure CLI, d’Azure Policy, du portail Azure ou de Terraform. Si vous n’activez pas Container Insights lorsque vous créez votre cluster, consultez Activer Container Insights pour le cluster AKS pour obtenir d’autres options pour l’activer.

Container Insights stocke la plupart de ses données dans un espace de travail Log Analytics. Vous utilisez généralement le même espace de travail Log Analytics que les journaux de ressources de votre cluster. Pour obtenir des conseils sur le nombre d’espaces de travail que vous devez utiliser et où les localiser, consultez Concevoir une architecture d’espace de travail Log Analytics.
Service managé pour Prometheus dans Azure Monitor Prometheus est une solution de métriques natives cloud de Cloud Native Computing Foundation. Il s’agit de l’outil le plus courant à utiliser pour collecter et analyser des données de métrique à partir de clusters Kubernetes. Le service managé pour Prometheus dans Azure Monitor est une solution de supervision entièrement gérée compatible prometheus. Si vous n’activez pas le service managé pour Prometheus lorsque vous créez votre cluster, consultez Collecter les métriques Prometheus à partir d’un cluster AKS pour obtenir d’autres options pour l’activer.

Le service managé pour Prometheus dans Azure Monitor stocke ses données dans un espace de travail Azure Monitorlié à un espace de travail Grafana. Vous pouvez utiliser Azure Managed Grafana pour analyser les données.
Grafana géré par Azure Implémentation entièrement managée de Grafana. Grafana 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 la pile complète. Si vous n’activez pas Azure Managed Grafana 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 métriques Prometheus à partir de votre cluster.

Surveillance des métriques du plan de contrôle AKS (aperçu)

Prérequis et étendue : cette fonctionnalité en préversion est disponible pour les clusters AKS exécutant Kubernetes 1.27 ou version ultérieure et nécessite que le service managé pour Prometheus soit activé sur votre cluster. La fonctionnalité prend actuellement en charge les pools de nœuds Linux et Windows, mais n’est pas compatible avec les groupes à haute disponibilité de machines virtuelles (VMAS).

AKS expose également des métriques provenant de composants de plan de contrôle critiques tels que le serveur d’API, etcd, et le planificateur via le service managé pour Prometheus dans Azure Monitor. Actuellement, cette fonctionnalité est en préversion. Pour plus d’informations, consultez Surveiller les métriques du plan de contrôle AKS. Un sous-ensemble de métriques de plan de contrôle pour le serveur d’API et etcd sont disponibles gratuitement via les métriques de plateforme Azure Monitor. Ces métriques sont collectées par défaut. Vous pouvez utiliser les métriques pour créer des alertes.

Journaux d’activité 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 sont organisés en catégories. Un espace de noms donné peut avoir plusieurs catégories de journal de ressource.

Collecte : les journaux d’activité de ressources ne sont pas collectés ni stockés tant que vous n’avez pas créé de paramètre de diagnostic et routé les journaux d'activité 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 de journaux de ressources disponibles, leurs tables Log Analytics associées et les schémas de journal pour AKS, consultez la référence des données de surveillance AKS.

Journaux des ressources du plan de contrôle AKS

Conditions préalables : nécessite un espace de travail Log Analytics dans le même abonnement que votre cluster AKS. Les journaux de ressources entraînent des coûts d’ingestion et de rétention dans l’espace de travail de destination. Pour optimiser les coûts, utilisez le mode spécifique aux ressources et configurez le niveau journaux de base pour les tables d’audit.

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

Pour savoir comment créer un paramètre de diagnostic à l’aide du portail Azure, d’Azure CLI ou d’Azure PowerShell, consultez Créer des paramètres 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 la référence des données de surveillance AKS.

Avertissement

Vous pouvez encourir des coûts importants quand vous collectez des journaux de ressources pour AKS, en particulier des journaux kube-audit. Tenez compte des recommandations suivantes pour réduire la quantité de données collectées :

  • Désactivez la kube-audit journalisation quand elle n’est pas nécessaire.
  • Activez la collecte à partir de kube-audit-admin, ce qui exclut les événements d’audit get et list.
  • Activez les journaux spécifiques aux ressources comme décrit dans cet article et configurez la table AKSAudit en tant que journaux de base.

Pour plus de recommandations de supervision, consultez Surveiller les clusters AKS à l’aide des services Azure et des outils natifs cloud. Pour obtenir des stratégies de réduction des coûts de surveillance, consultez l’optimisation des coûts et Azure Monitor.

AKS prend en charge le mode diagnostics Azure ou le mode spécifique à la ressource pour les journaux de ressources. Le mode diagnostics Azure envoie toutes les données à la table AzureDiagnostics. Le mode spécifique aux ressources spécifie les tables de l’espace de travail Log Analytics où les données sont envoyées. Il envoie également des données à AKSAudit, AKSAuditAdminet AKSControlPlane comme indiqué dans la table dans les journaux des ressources.

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

  • Les données sont plus faciles à interroger, car elles se trouvent dans des tables individuelles dédiées à AKS.
  • Le mode dédié aux ressources prend en charge la configuration en tant que journaux de base pour des économies de coûts significatives.

Pour plus d’informations sur la différence entre les modes de collecte, notamment la modification d’un paramètre existant, consultez Sélectionner le mode collection.

Remarque

Vous pouvez configurer les paramètres de diagnostic à l’aide d’Azure CLI. Cette approche n’est pas garantie pour réussir, car elle ne vérifie pas l’état d’approvisionnement du cluster. Après avoir modifié les paramètres de diagnostic, vérifiez que le cluster reflète les modifications de paramètre.

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

Requêtes et exemples de journaux de ressources AKS

Exigences relatives à l’étendue des requêtes : lorsque vous sélectionnez Journaux d’activité dans un menu de cluster AKS, Log Analytics s’ouvre avec l’étendue de requête définie sur le cluster actuel. Les requêtes de journal incluent uniquement les données de cette ressource. Pour exécuter des requêtes qui incluent des données provenant d’autres clusters ou services Azure, sélectionnez Journaux dans le menu Azure Monitor .

Si les paramètres de diagnostic de votre cluster utilisent le mode diagnostics Azure, les journaux de ressources pour AKS sont stockés dans la table AzureDiagnostics . Identifiez les logs via la colonne Catégorie . Pour une description de chaque catégorie, voir les journaux de ressources de référence AKS.

Descriptif Mode Requête de journal
Compter les journaux pour chaque catégorie Mode de diagnostic Azure AzureDiagnostics
| where ResourceType == "MANAGEDCLUSTERS"
| summarize count() by Category
Tous les journaux du serveur d’API Mode diagnostique Azure AzureDiagnostics
| where Category == "kube-apiserver"
Tous les journaux kube-audit dans un intervalle de temps Mode de diagnostics Azure let starttime = datetime("2023-02-23");
let endtime = datetime("2023-02-24");
AzureDiagnostics
| where TimeGenerated between(starttime..endtime)
| where Category == "kube-audit"
| extend event = parse_json(log_s)
| extend HttpMethod = tostring(event.verb)
| extend User = tostring(event.user.username)
| extend Apiserver = pod_s
| extend SourceIP = tostring(event.sourceIPs[0])
| project 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 get et list Mode spécifique aux ressources AKSAuditAdmin
Tous les journaux du serveur d’API Mode spécifique aux ressources AKSControlPlane
| where 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, puis sélectionnez le type de ressource Kubernetes Services . Pour obtenir la liste des requêtes courantes pour Container Insights, consultez les Requêtes Container Insights.

Journaux Container Insights du plan de données AKS

Prérequis et exigences de configuration : Container Insights nécessite un espace de travail Log Analytics pour le stockage des journaux et prend en charge à la fois l’authentification par identité managée et les méthodes d’authentification héritées. Pour les nouveaux clusters, l’authentification d’identité managée est recommandée. La collecte de données peut être personnalisée à l’aide des règles de collecte de données Azure Monitor pour contrôler les coûts et réduire le volume d’ingestion.

Container Insights collecte différents types de données de télémétrie à partir de conteneurs et de clusters AKS 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 les tables sont disponibles pour les requêtes de logs.

Utilisez les paramètres d’optimisation des coûts pour personnaliser et 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 pour la sélection de tables, les intervalles de collecte de données et les espaces de noms individuels afin d’exclure la collecte de données via les règles de collecte de données Azure Monitor (DCR). Ces paramètres contrôlent le volume d’ingestion et réduisent les coûts de surveillance de Container Insights. Vous pouvez personnaliser les données collectées par Container Insights dans le portail Azure à l’aide des options suivantes. La sélection d’options autres que Toutes (valeur par défaut) rend l’expérience Container Insights indisponible.

Regroupement Tables Remarques
Tous (valeur par défaut) Toutes les tables standard de Container Insights Obligatoire pour activer les visualisations Container Insights par défaut.
Performance Niveau de performance, InsightsMetrics N/A
Journaux et événements ContainerLog ou ContainerLogV2, KubeEvents, KubePodInventory Recommandé si vous avez activé le service managé pour les métriques Prometheus.
Charges de travail, déploiements et HPA InsightsMetrics, KubePodInventory, KubeEvents, ContainerInventory, ContainerNodeInventory, KubeNodeInventory, KubeServices N/A
Volumes persistants InsightsMetrics, KubePVInventory N/A

Le regroupement journaux et événements capture les journaux d’activité à partir des tables ContainerLog ou ContainerLogV2, KubeEvents et KubePodInventory, mais pas les métriques. Le chemin recommandé pour collecter des métriques consiste à activer le service managé 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

Compatibilité et configuration requises : Le schéma ContainerLogV2 est recommandé pour les nouveaux déploiements Container Insights à l’aide de l’authentification d’identité managée via des modèles Azure Resource Manager (ARM), Bicep, Terraform, Azure Policy ou le portail Azure. Le schéma est compatible avec le niveau journaux de base pour réaliser des économies et n’affecte pas les fonctionnalités d’analyse ou d’alertes. Pour plus d’informations sur l’activation de ContainerLogV2 via le DCR ou le configmap du cluster, consultez Activer le schéma ContainerLogV2.

Container Insights dans Azure Monitor fournit un schéma recommandé pour les journaux de conteneur, ContainerLogV2. Le format inclut les champs suivants pour les requêtes courantes pour afficher les données relatives aux clusters Kubernetes avec AKS et Azure Arc :

  • ContainerName
  • PodName
  • PodNamespace

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.

Collection : les événements du journal d’activité sont automatiquement générés et collectés dans un magasin distinct pour être affichés 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 conteneur AKS, les événements et les mesures de pod en temps réel

Conditions préalables et configuration requises : la fonctionnalité De données dynamiques nécessite que Container Insights soit activé sur votre cluster et utilise l’accès direct à l’API Kubernetes. Pour les clusters privés, l’accès nécessite un ordinateur dans le même réseau privé que le cluster. L’authentification suit le modèle RBAC Kubernetes et nécessite des autorisations de cluster appropriées.

Vous pouvez afficher les journaux de conteneur AKS, les événements et les métriques de pod en utilisant la fonctionnalité de données en direct dans Container Insights et résoudre les problèmes en temps réel avec un accès direct à kubectl logs -c, aux événements kubectl get et à kubectl top pods.

Remarque

AKS utilise des architectures de journalisation au niveau du cluster Kubernetes. Les journaux de conteneur se trouvent dans /var/log/containers sur le nœud. Pour accéder à un nœud, consultez Se connecter aux nœuds de cluster AKS.

Pour savoir comment configurer cette fonctionnalité, consultez Configurer des données actives dans Container Insights. La fonctionnalité accède directement à l’API Kubernetes. Pour plus d’informations sur le modèle d’authentification, consultez l’API Kubernetes.

Afficher les journaux dynamiques des ressources AKS

Configuration réseau du cluster privé requise : pour accéder aux journaux d’activité à partir d’un cluster privé, vous devez utiliser un ordinateur qui se trouve dans 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. Pour le Deployment, Pod, Replica Set, Stateful Set, Job ou CronJob, sélectionnez une valeur, puis sélectionnez Live Logs.

  4. Sélectionnez un journal de ressources à afficher.

    L’exemple suivant montre les logs d’une ressource de pod :

    Capture d’écran montrant le déploiement des journaux en direct.

Afficher les journaux de conteneurs en direct à l’aide de Container Insights

Authentification et diffusion en continu des données : une fois l’authentification réussie, si les données peuvent être récupérées, elle commence à diffuser en continu vers l’onglet Journaux en direct . Les données de journal apparaissent dans un flux continu. Un autre accès aux journaux est disponible via Afficher les journaux d’activité dans Log Analytics pour l’analyse historique.

Vous pouvez afficher les données de journal en temps réel lorsque le moteur de conteneur le génère sous l’onglet Cluster, Nœuds, Contrôleurs ou Conteneurs .

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

  2. Sous Supervision, sélectionnez Insights.

  3. Sous l’onglet Cluster, Nœuds, Contrôleurs ou Conteneurs , sélectionnez une valeur.

  4. Dans le volet Vue d’ensemble de la ressource, sélectionnez Journaux en direct.

    L’image suivante montre les journaux d’activité d’une ressource de conteneur :

    Capture d’écran montrant l’option Logs en direct du conteneur pour afficher les données.

Visualiser les événements en direct des conteneurs à l'aide de Container Insights

Diffusion et accès aux événements : flux de données d’événements en temps réel lorsque le moteur de conteneur le génère. Les événements incluent la création de pods, leur suppression, les opérations de mise à l’échelle, et les conditions d'erreur. Les données d’événements historiques sont accessibles via Afficher les événements dans Log Analytics.

Vous pouvez afficher les données d’événements en temps réel lorsque le moteur de conteneur le génère sous l’onglet 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ôleurs ou Conteneurs , puis sélectionnez un objet.

  4. Dans le volet Vue d’ensemble des ressources, sélectionnez Événements en direct.

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

    Capture d’écran montrant l’option Événements en direct du conteneur pour afficher les données.

Afficher les métriques dynamiques des pods à l’aide de Container Insights

Étendue et disponibilité des métriques : les métriques actives sont disponibles pour les ressources de pod sous les onglets Nœuds ou Contrôleurs . Les métriques incluent l’utilisation du processeur, la consommation de mémoire, les E/S réseau et les statistiques du système de fichiers. Les métriques historiques sont accessibles via l’affichage des événements dans Log Analytics.

Vous pouvez afficher les données de métriques en temps réel lorsque le moteur de conteneur le génère sous l’onglet Nœuds ou Contrôleurs en sélectionnant une ressource de 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 un objet pod.

  4. Dans le volet Vue d’ensemble des ressources, sélectionnez Métriques actives.

    Une fois l’authentification réussie, si les données peuvent être récupérées, elles commencent à diffuser en continu vers l’onglet Métriques actives . L’image suivante montre les métriques d’une ressource de pod :

    Capture d’écran montrant l’option Métriques actives du pod pour afficher les données.

    Analyser les données de surveillance

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

    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.
    • Classeurs, 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.

Surveiller les clusters AKS dans le portail Azure

L’onglet Surveillance du volet Vue d’ensemble de votre ressource de cluster AKS offre un moyen rapide de commencer à afficher les données de surveillance 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 Supervision inclut également des liens vers le service managé Azure pour Prometheus et Container Insights pour le cluster. Vous pouvez activer ces outils sous l’onglet Surveillance . Vous pouvez également voir une bannière en haut du volet qui recommande d’autres fonctionnalités d’améliorer la surveillance de votre cluster.

Conseil

Pour accéder aux fonctionnalités de surveillance de tous les clusters AKS de votre abonnement, dans la page d’accueil du portail Azure, sélectionnez Azure Monitor.

Requêtes Kusto

Vous pouvez analyser les données de surveillance dans les journaux d'activité Azure Monitor ou le magasin Log Analytics en utilisant le langage de requête Kusto (KQL).

Important

Quand vous sélectionnez Journaux d’activité 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 de mise en œuvre des alertes, des tableaux de bord et des recommandations concernant les 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

Configurer des alertes basées sur les métriques Prometheus

Exigences de téléchargement et de configuration : les règles d’alerte sont disponibles en tant que modèles ARM téléchargeables ou fichiers Bicep. Avant de configurer des alertes, vérifiez que le service managé pour Prometheus est activé sur votre cluster et qu’un espace de travail Azure Monitor est correctement lié à votre cluster AKS.

Lorsque vous activez la collecte du service managé pour les métriques Prometheus pour votre cluster, vous pouvez télécharger une collection de services managés recommandés pour les règles d’alerte Prometheus.

Le téléchargement inclut les règles suivantes :

Level 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

Pour plus d’informations, consultez Créer des alertes de journal à partir de Container Insights et Interroger des journaux d’activité à partir de Container Insights.

Les alertes de journal peuvent mesurer deux types d’informations pour vous aider à surveiller différents scénarios :

  • Nombre de résultats : compte le nombre de lignes retournées par la requête. Utilisez ces informations pour travailler avec des événements tels que les journaux d'événements Windows, les événements syslog et les exceptions d'application.
  • Calcul d’une valeur : effectue un calcul basé sur une colonne numérique. Utilisez ces informations pour inclure diverses ressources. Par exemple, le pourcentage d’UC.

La plupart des requêtes de journaux comparent une valeur DateTime à l’heure actuelle à l’aide de l’opérateur now, en remontant 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 quelle métrique, entrée de journal ou entrée de journal d’activité répertoriée dans la référence des données de surveillance AKS.

Condition Descriptif
Pourcentage >95 Alerte lorsque l’utilisation moyenne du processeur sur tous les nœuds dépasse le seuil.
Pourcentage de l'ensemble de travail de la mémoire>100 Alertes lorsque l'ensemble de travail moyen sur tous les nœuds dépasse le seuil.

Recommandations d’Advisor

Pour certains services, si des conditions critiques ou des changements imminents se produisent durant les opérations relatives aux ressources, une alerte s’affiche dans la page Vue d’ensemble du service au sein du portail. Vous trouverez plus d’informations ainsi que les correctifs recommandés pour l’alerte dans Recommandations Advisor, sous Supervision 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.

Surveillance des métriques réseau du nœud AKS

Configuration requise pour la version et l’activation : dans Kubernetes version 1.29 et ultérieures, les métriques réseau de nœud sont activées par défaut pour tous les clusters avec Azure Monitor activés. Pour les versions antérieures de Kubernetes, vous devez activer manuellement la supervision réseau via la configuration du cluster. Cette fonctionnalité nécessite qu’Azure Monitor ou Container Insights soit configuré sur votre cluster.

Les métriques réseau de nœud sont cruciales pour maintenir un cluster Kubernetes sain et performant. En collectant et en analysant des données sur le trafic réseau, vous pouvez obtenir des informations précieuses sur l’opération de votre cluster et identifier les problèmes potentiels avant qu’ils n’entraînent des pannes ou des pertes de performances.

Les métriques réseau de nœud suivantes sont activées par défaut et sont agrégées par nœud. Toutes les métriques incluent le cluster d’étiquettes et l’instance (nom du nœud). Vous pouvez facilement afficher ces métriques à l’aide du tableau de bord Managed Grafana sous Prometheus Azure géré>Kubernetes>Mise en réseau>Clusters.

Métriques réseau du nœud AKS par type de plan de données

Toutes les métriques incluent ces étiquettes :

  • cluster
  • instance (nom du nœud)

Prise en charge et limitations du système d’exploitation : pour les scénarios de plan de données Cilium, la fonctionnalité d’observabilité du réseau de conteneurs fournit des métriques uniquement pour les pools de nœuds Linux. Actuellement, Windows n’est pas pris en charge pour les métriques d’observabilité du réseau de conteneurs. Vérifiez que votre cluster dispose de pools de nœuds Linux pour la disponibilité complète des métriques Cilium.

Pour les scénarios de plan de données Cilium, la fonctionnalité d’observabilité du réseau de conteneurs fournit des métriques uniquement pour Linux. Actuellement, Windows n’est pas pris en charge pour les métriques d’observabilité du réseau de conteneurs.

Cilium expose plusieurs métriques que l’observabilité du réseau de conteneurs utilise :

Nom de la métrique Descriptif Étiquettes supplémentaires Linux Fenêtres
cilium_forward_count_total Nombre total de paquets transférés direction Prise en charge de ✅ Non pris en charge ❌
cilium_forward_bytes_total Nombre total d’octets transférés direction Prise en charge de ✅ Non pris en charge ❌
cilium_drop_count_total Nombre total de paquets ignorés direction, reason Prise en charge de ✅ Non supporté ❌
cilium_drop_bytes_total Nombre total d’octets ignorés direction, reason Prise en charge de ✅ Non pris en charge ❌

Désactiver la collecte des métriques réseau du nœud AKS

Vous pouvez désactiver la collecte de métriques réseau sur des nœuds spécifiques en ajoutant l’étiquette networking.azure.com/node-network-metrics=disabled à ces nœuds.

Remarque

La rétine a une operator: "Exists"effect: NoSchedule tolérance, donc elle contourne les NoSchedule impuretés. Par conséquent, les étiquettes sont utilisées au lieu de teintes pour contrôler la planification.

Si le cluster est un cluster de autoprovisioning/autoscaling nœuds, vous devez activer manuellement l’indicateur sur chaque nœud.

Important

Cette fonctionnalité n’est pas applicable si Advanced Container Networking Services (ACNS) est activé sur votre cluster.

Pour désactiver la collecte de métriques sur un nœud :

kubectl label node <node-name> networking.azure.com/node-network-metrics=disabled

Pour obtenir des métriques DNS et de niveau pod détaillées, consultez Advanced Container Networking Services.

Contenu connexe

  • Last updated on