Résolution de problèmes liés à Insights du conteneur

Article
02/15/2024

Lorsque vous configurez la surveillance de votre cluster Azure Kubernetes Service (AKS) avec Insights du conteneur, vous pouvez rencontrer un problème empêchant la collecte de données ou le statut de génération d’état. Cet article décrit certains problèmes courants et indique la façon de les résoudre.

Messages d’erreur connus

Le tableau suivant récapitule les erreurs connues que vous pouvez rencontrer lorsque vous utilisez Insights du conteneur.

Messages d’erreur	Action
Message d’erreur « Aucune donnée pour les filtres sélectionnés »	L’établissement du flux de données de supervision peut prendre un certain temps pour les clusters nouvellement créés. Patientez au moins 10 à 15 minutes avant l’affichage des données de votre cluster. Si les données n’apparaissent toujours pas, vérifiez si l’espace de travail Log Analytics est configuré pour `disableLocalAuth = true`. Si oui, remettre à jour vers `disableLocalAuth = false`. `az resource show --ids "/subscriptions/[Your subscription ID]/resourcegroups/[Your resource group]/providers/microsoft.operationalinsights/workspaces/[Your workspace name]"` `az resource update --ids "/subscriptions/[Your subscription ID]/resourcegroups/[Your resource group]/providers/microsoft.operationalinsights/workspaces/[Your workspace name]" --api-version "2021-06-01" --set properties.features.disableLocalAuth=False`
Message d’erreur « Erreur lors de la récupération des données »	Bien que le cluster AKS soit configuré pour la supervision de l’intégrité et des performances, une connexion est établie entre le cluster et l’espace de travail Log Analytics. Un espace de travail Log Analytics est utilisé pour stocker toutes les données de supervision de votre cluster. Cette erreur peut se produire lorsque votre espace de travail Log Analytics a été supprimé. Vérifiez si l’espace de travail a été supprimé. Si c’est le cas, réactivez la surveillance de votre cluster avec Insights du conteneur. Sélectionnez ensuite un espace de travail existant ou créez-en un. Pour réactiver, vous devez désactiver la supervision du cluster, puis réactiver insights du conteneur.
« Erreur lors de la récupération des données » après l’ajout de Insights de conteneur via `az aks cli`	Lorsque vous activez la surveillance à l’aide de `az aks cli`, Insights de conteneur peut ne pas être correctement déployé. Vérifiez si la solution est déployée. Pour vérifier cela, accédez à votre espace de travail Log Analytics et voyez si la solution est disponible en sélectionnant Solutions hérités dans le volet de gauche. Pour résoudre ce problème, redéployez la solution. Suivez les instructions fournies dans Activer Insights de conteneur.
Message d’erreur « Inscription de l’abonnement manquante »	Si l’erreur « Missing Subscription registration for Microsoft.OperationsManagement » s’affiche, vous pouvez la résoudre en enregistrant le fournisseur de ressources Microsoft.OperationsManagement dans l’abonnement où est défini l’espace de travail. Pour la marche à suivre, consultez Résoudre les erreurs d’inscription de fournisseurs de ressources.
Message d’erreur « L’URL de réponse spécifiée dans la requête ne correspond pas aux URL de réponse configurées pour l’application : '<ID d’application>' ».	Ce message d’erreur peut s’afficher lorsque vous activez les journaux dynamiques. Pour la solution, consultez Afficher les données de conteneur en temps réel avec Container Insights.

Pour vous aider à diagnostiquer le problème, nous vous fournissons un script de résolution des problèmes.

Erreur d’autorisation durant une opération d’intégration ou de mise à jour

Lorsque vous activez Insights de conteneur ou mettez à jour un cluster pour prendre en charge la collecte de métriques, vous pouvez recevoir une erreur du type « Le client <user's Identity> avec l’ID <user's objectId> d’objet n’a pas l’autorisation d’effectuer une action Microsoft.Authorization/roleAssignments/write sur l’étendue »

Lors du processus de mise à jour ou d’intégration, une tentative d’attribution de rôle Publication des métriques de surveillance sur la ressource de cluster est effectuée. L’utilisateur qui initialise le processus d’activation de Container insights ou de mise à jour pour la prise en charge de la collecte des métriques doit disposer de l’autorisation Microsoft.Authorization/roleAssignments/write sur l’étendue de la ressource de cluster AKS. Seuls les membres des rôles intégrés Propriétaire et Administrateur des accès utilisateur se voient accorder l’accès. Si vos stratégies de sécurité vous obligent à attribuer des autorisations de niveau granulaire, consultez Rôles personnalisés Azure et attribuer une autorisation aux utilisateurs qui en ont besoin.

Vous pouvez également accorder manuellement ce rôle à partir de le Portail Azure : Attribuer le rôle serveur de publication à l’étendue Métriques de surveillance. Pour connaître la procédure détaillée, consultez Attribuer des rôles Azure à l’aide du portail Azure.

Container Insights est activé, mais ne rapporte aucune information

Pour diagnostiquer le problème si vous ne pouvez pas afficher les informations d’état ou si aucun résultat n’est retourné à partir d’une requête de journal :

Vérifiez le statut de l’agent en exécutant la commande suivante :

kubectl get ds ama-logs --namespace=kube-system

Le nombre de pods doit être égal au nombre de nœuds Linux du cluster. La sortie doit ressembler à l’exemple suivant, qui indique que l’agent a été correctement déployé :
```
User@aksuser:~$ kubectl get ds ama-logs --namespace=kube-system
NAME       DESIRED   CURRENT   READY     UP-TO-DATE   AVAILABLE   NODE SELECTOR    AGE
ama-logs   2         2         2         2            2           <none>           1d
```
Si vous avez des nœuds Windows Server, vérifiez l’état de l’agent en exécutant la commande suivante :

kubectl get ds ama-logs-windows --namespace=kube-system

Le nombre de pods doit être égal au nombre de nœuds Windows du cluster. La sortie doit ressembler à l’exemple suivant, qui indique que l’agent a été correctement déployé :
```
User@aksuser:~$ kubectl get ds ama-logs-windows --namespace=kube-system
NAME                   DESIRED   CURRENT   READY     UP-TO-DATE   AVAILABLE   NODE SELECTOR    AGE
ama-logs-windows           2         2         2         2            2           <none>       1d
```
Vérifiez l’état du déploiement à l’aide de la commande suivante :

kubectl get deployment ama-logs-rs --namespace=kube-system

La sortie doit ressembler à l’exemple suivant, qui indique que l’agent a été correctement déployé :
```
User@aksuser:~$ kubectl get deployment ama-logs-rs --namespace=kube-system
NAME          READY   UP-TO-DATE   AVAILABLE   AGE
ama-logs-rs   1/1     1            1           24d
```

Vérifiez l’état du pod pour confirmer qu’il est bien en cours d’exécution à l’aide de la commande kubectl get pods --namespace=kube-system.

La sortie devrait ressembler à l’exemple suivant avec un statut de Running pour ama-logs :

User@aksuser:~$ kubectl get pods --namespace=kube-system
NAME                                READY     STATUS    RESTARTS   AGE
aks-ssh-139866255-5n7k5             1/1       Running   0          8d
azure-vote-back-4149398501-7skz0    1/1       Running   0          22d
azure-vote-front-3826909965-30n62   1/1       Running   0          22d
ama-logs-484hw                      1/1       Running   0          1d
ama-logs-fkq7g                      1/1       Running   0          1d
ama-logs-windows-6drwq              1/1       Running   0          1d

Si les pods sont en cours d’exécution, mais qu’il n’y a pas de données dans Log Analytics ou que les données ne semblent être envoyées que pendant une certaine partie de la journée, cela peut indiquer que la limite quotidienne a été atteinte. Lorsque cette limite est atteinte chaque jour, les données arrêtent l’ingestion dans l’espace de travail Log Analytics et sont réinitialisées au moment de la réinitialisation. Pour plus d’informations, consultez Limites quotidiennes de Log Analytics.

Les pods ReplicaSet d’agent insights du conteneur ne sont pas planifiés sur un cluster non AKS

Les pods ReplicaSet d’agent insights de conteneur dépendent des sélecteurs de nœuds suivants sur les nœuds Worker (ou agent) pour la planification :

nodeSelector:
  beta.kubernetes.io/os: Linux
  kubernetes.io/role: agent

Si aucune étiquette de nœud n’est associée à vos nœuds Worker, les pods ReplicaSet d’agent ne sont pas planifiés. Pour obtenir des instructions sur la façon d’attacher l’étiquette, voir Attribuer des sélecteurs d’étiquettes Kubernetes.

Les graphiques de performances n’affichent pas l’UC ou la mémoire des nœuds et des conteneurs sur un cluster non Azure

Les pods d’agent d’aperçu des conteneurs utilisent le point de terminaison cAdvisor sur l’agent de nœud pour collecter des métriques de performances. Vérifiez que l’agent en conteneur sur le nœud est configuré pour autoriser l’ouverture de cAdvisor secure port: 10250 ou cAdvisor unsecure port: 10255 sur tous les nœuds du cluster pour collecter les métriques de performance. Pour plus d’informations, consultez les prérequis pour les clusters Kubernetes hybrides .

Les clusters non AKS ne s’affichent pas dans Insights du conteneur

Pour visualiser le cluster non AKS dans insights de conteneur, un accès en lecture est requis sur l’espace de travail Log Analytics qui prend en charge cette insight, ainsi que sur la ressource de solution Insights de conteneur ContainerInsights (espace de travail).

Les métriques ne sont pas collectées

Vérifiez que l’attribution de rôle Éditeur de métriques de surveillance existe à l’aide de la commande CLI suivante :
```
az role assignment list --assignee "SP/UserassignedMSI for Azure Monitor Agent" --scope "/subscriptions/<subid>/resourcegroups/<RG>/providers/Microsoft.ContainerService/managedClusters/<clustername>" --role "Monitoring Metrics Publisher"
```
Pour les clusters avec MSI, l’ID client attribué par l’utilisateur pour l’agent Azure Monitor change à chaque activation ou désactivation du monitoring. L’attribution de rôle doit donc exister sur l’ID client MSI actuel.
Pour les clusters avec l’identité pod Microsoft Entra activée et utilisant MSI :
- Vérifiez que l’étiquette requise kubernetes.azure.com/managedby: aks est présente sur les pods de l’agent Azure Monitor, en utilisant la commande suivante :
  
  kubectl get pods --show-labels -n kube-system | grep ama-logs
- Vérifiez que les exceptions sont activées lorsque l’identité de pod est activée à l’aide de l’une des méthodes prises en charge dans https://github.com/Azure/aad-pod-identity#1-deploy-aad-pod-identity.
  
  Exécutez la commande suivante pour vérifier :
  
  kubectl get AzurePodIdentityException -A -o yaml
  
  La sortie devrait ressembler à l’exemple suivant :
```
apiVersion: "aadpodidentity.k8s.io/v1"
kind: AzurePodIdentityException
metadata:
name: mic-exception
namespace: default
spec:
podLabels:
app: mic
component: mic
---
apiVersion: "aadpodidentity.k8s.io/v1"
kind: AzurePodIdentityException
metadata:
name: aks-addon-exception
namespace: kube-system
spec:
podLabels:
kubernetes.azure.com/managedby: aks
```

L’installation de l’extension de conteneurs Azure Monitor échoue sur un cluster Kubernetes avec Azure Arc

L’erreur « Les manifestes contiennent une ressource qui existe déjà » indique que des ressources de l’agent Insights de conteneur existent déjà sur le cluster Kubernetes compatible avec Azure Arc. Cette erreur indique que l’agent Insights de conteneur est déjà installé. Il est installé via un graphique Helm azuremonitor-containers ou le module complémentaire monitoring s’il s’agit d’un cluster AKS connecté via Azure Arc.

La solution à ce problème consiste à nettoyer les ressources existantes de l’agent Insights de conteneur, le cas échéant. Activez ensuite l’extension des conteneurs Azure Monitor.

Pour les clusters non AKS

Sur le cluster K8s qui est connecté à Azure Arc, exécutez la commande ci-dessous pour vérifier si la version du chart Helm azmon-containers-release-1 existe ou pas :

helm list -A
Si la sortie de la commande précédente indique que azmon-containers-release-1 existe, supprimez la version du chart Helm :

helm del azmon-containers-release-1

Pour les clusters AKS

Exécutez les commandes suivantes et recherchez le profil de module complémentaire de l’agent Azure Monitor pour vérifier si le module complémentaire Monitoring AKS est activé :
```
az  account set -s <clusterSubscriptionId>
az aks show -g <clusterResourceGroup> -n <clusterName>
```
Si la sortie inclut une configuration de profil de module complémentaire de l’agent Azure Monitor avec un ID de ressource d’espace de travail Log Analytics, l’information indique que le module complémentaire Monitoring AKS est activé et doit être désactivé :

az aks disable-addons -a monitoring -g <clusterResourceGroup> -n <clusterName>

Si les étapes précédentes n’ont pas résolu les problèmes d’installation de l’extension des conteneurs de Azure Monitor, créez un ticket de support à envoyer à Microsoft pour qu’ils soient examinés.

Alertes en double reçues

Vous pourriez avoir activé les règles d’alerte Prometheus sans désactiver les alertes recommandées pour les informations du conteneur. Consultez Migrer à partir des alertes recommandées pour les informations du conteneur vers les règles d’alerte recommandées Prometheus (préversion).

Container Insights a historiquement permis aux utilisateurs d’accéder à l’expérience du portail Azure en fonction de l’autorisation d’accès de l’espace de travail Log Analytics. Il vérifie maintenant l’autorisation au niveau du cluster pour fournir l’accès à l’expérience du portail Azure. Vous pouvez avoir besoin que votre administrateur de cluster attribue cette autorisation.

Pour l’accès de base au niveau du cluster en lecture seule, attribuez le rôle Lecteur d’analyse pour les types de clusters suivants.

AKS sans autorisation de contrôle d’accès en fonction du rôle (RBAC) Kubernetes activée
AKS activé avec l’authentification unique Microsoft Entra basée sur SAML
AKS activé avec autorisation Kubernetes RBAC
AKS configuré avec la liaison de rôle de cluster clusterMonitoringUser
Clusters Kubernetes avec Azure Arc

Consultez Attribuer des autorisations de rôle à un utilisateur ou à un groupe pour plus d’informations sur l’attribution de rôles pour AKS et Options d’accès et d’identité pour Azure Kubernetes Service (AKS) pour en savoir plus sur les attributions de rôles.

Je ne vois pas les valeurs de propriété Image et Nom renseignées quand j’interroge la table ContainerLog

Pour la version de l’agent ciprod12042019 et ultérieures, par défaut, ces deux propriétés ne sont pas remplies pour chaque ligne de journal afin de réduire les coûts liés aux données de journal collectées. Il existe deux options pour interroger la table qui inclut ces propriétés avec leurs valeurs :

Option 1 :

Joignez d’autres tables pour inclure ces valeurs de propriétés dans les résultats.

Modifiez vos requêtes pour inclure les propriétés Image et ImageTag à partir de la table ContainerInventory en joignant la propriété ContainerID. Vous pouvez inclure la propriété Name (telle qu’elle apparaissait dans la table ContainerLog) à partir du champ KubepodInventory de la table ContainerName en joignant la propriété ContainerID. Cette option est celle que nous recommandons.

L’exemple suivant illustre une requête détaillée qui explique comment obtenir ces valeurs de champs avec des jointures.

//Let's say we're querying an hour's worth of logs
let startTime = ago(1h);
let endTime = now();
//Below gets the latest Image & ImageTag for every containerID, during the time window
let ContainerInv = ContainerInventory | where TimeGenerated >= startTime and TimeGenerated < endTime | summarize arg_max(TimeGenerated, *)  by ContainerID, Image, ImageTag | project-away TimeGenerated | project ContainerID1=ContainerID, Image1=Image ,ImageTag1=ImageTag;
//Below gets the latest Name for every containerID, during the time window
let KubePodInv  = KubePodInventory | where ContainerID != "" | where TimeGenerated >= startTime | where TimeGenerated < endTime | summarize arg_max(TimeGenerated, *)  by ContainerID2 = ContainerID, Name1=ContainerName | project ContainerID2 , Name1;
//Now join the above 2 to get a 'jointed table' that has name, image & imagetag. Outer left is safer in case there are no kubepod records or if they're latent
let ContainerData = ContainerInv | join kind=leftouter (KubePodInv) on $left.ContainerID1 == $right.ContainerID2;
//Now join ContainerLog table with the 'jointed table' above and project-away redundant fields/columns and rename columns that were rewritten
//Outer left is safer so you don't lose logs even if we can't find container metadata for loglines (due to latency, time skew between data types, etc.)
ContainerLog
| where TimeGenerated >= startTime and TimeGenerated < endTime
| join kind= leftouter (
  ContainerData
) on $left.ContainerID == $right.ContainerID2 | project-away ContainerID1, ContainerID2, Name, Image, ImageTag | project-rename Name = Name1, Image=Image1, ImageTag=ImageTag1

Option 2 :

Réactivez la collecte pour ces propriétés pour chaque ligne de journal de conteneur.

Si la première option ne convient pas en raison des modifications apportées aux requêtes, vous pouvez réactiver la collecte de ces champs. Activez le paramètre log_collection_settings.enrich_container_logs dans le mappage de configuration de l’agent, comme décrit dans les paramètres de configuration de collecte de données.

Notes

Nous ne recommandons pas la deuxième option pour les clusters volumineux qui ont plus de 50 nœuds. Celle-ci génère des appels de serveur d’API à partir de chaque nœud du cluster pour effectuer cet enrichissement. En outre, cette option augmente la taille des données pour chaque ligne de journal collectée.

Je ne peux pas mettre à niveau un cluster après l’intégration

Voici le scénario : Vous avez activé Container Insights pour un cluster Azure Kubernetes Service. Vous avez ensuite supprimé l’espace de travail Log Analytics vers lequel le cluster envoyait ses données. Désormais, lorsque vous tentez de mettre à niveau le cluster, l’opération échoue. Pour contourner ce problème, vous devez désactiver la supervision, puis la réactiver en référençant un autre espace de travail valide dans votre abonnement. Lorsque vous réessayez de mettre le cluster à niveau, il doit être traité et s’effectuer correctement.

Ne pas collecter les journaux d’activité sur un cluster Azure Stack HCI

Si vous avez inscrit votre cluster et/ou configuré HCI Insights avant novembre 2023, les fonctionnalités qui utilisent l’agent Azure Monitor sur HCI, telles que les insights Arc pour serveurs, insights de machine virtuelle, insights de conteneur, Defender pour le cloud ou Microsoft Sentinel, peuvent ne pas collecter correctement les journaux et les données d’événement. Consultez Réparer l’agent AMA pour HCI pour obtenir les étapes de reconfiguration de l’agent Azure Monitor et de HCI Insights.

Étapes suivantes

Vous pouvez activer la fonctionnalité de supervision pour collecter des métriques d’intégrité pour les nœuds et pods du cluster AKS et les consulter dans le Portail Azure. Pour savoir comment utiliser Container insights, consultez Afficher l’intégrité d’Azure Kubernetes Service.