Partager via

Gérer l’agent Insights de conteneur

  • Article

Container Insights utilise une version conteneurisée de l’agent Log Analytics pour Linux. Après le déploiement initial, vous devrez peut-être effectuer des tâches de routine ou facultatives pendant son cycle de vie. Cet article explique comment mettre à niveau l’agent manuellement et comment désactiver la collecte des variables d’environnement à partir d’un conteneur donné.

Remarque

Si vous avez déjà déployé un cluster AKS et activé la supervision avec l’interface Azure CLI ou un modèle Resource Manager, vous ne pouvez pas utiliser kubectl pour mettre à niveau, supprimer, redéployer ou déployer l’agent. Le modèle doit être déployé dans le même groupe de ressources que le cluster.

Mettre à niveau l’agent Container Insights

Container Insights utilise une version conteneurisée de l’agent Log Analytics pour Linux. Lorsqu’une nouvelle version de l’agent est disponible, celui-ci est automatiquement mis à niveau sur vos clusters Kubernetes managés sur Azure Kubernetes Service (AKS) et Kubernetes avec Azure Arc.

Si la mise à niveau de l’agent sur un cluster managé sur AKS échoue, cet article décrit également le processus permettant de mettre à niveau l’agent manuellement. Pour suivre les versions publiées, consultez Annonces des versions de l’agent.

Mettre à niveau l’agent sur un cluster AKS

Le processus de mise à niveau de l’agent sur un cluster AKS se compose de deux étapes. La première étape consiste à désactiver la surveillance avec Container Insights à l’aide de l’interface de ligne de commande Azure. Suivez les étapes décrites dans l’article Désactiver Container Insights sur votre cluster Kubernetes. En utilisant l’Azure CLI, vous pouvez retirer l'agent des nœuds du cluster sans affecter la solution et les données correspondantes qui sont stockées dans l'espace de travail.

Notes

Pendant que vous effectuez cette activité de maintenance, les nœuds du cluster ne transfèrent pas les données collectées. Les vues performances n’affichent pas les données entre le moment où vous avez supprimé l’agent et installé la nouvelle version.

La deuxième étape consiste à installer la nouvelle version de l’agent. Suivez les étapes décrites dans Activer la supervision à l’aide d’Azure CLI pour terminer ce processus.

Après l’activation de la surveillance, un délai d’environ 15 minutes peut être nécessaire pour afficher les métriques d’intégrité mises à jour pour le cluster. Vous disposez de deux méthodes pour vérifier que l’agent a été correctement mis à niveau :

  • Exécutez la commande kubectl get pod <ama-logs-agent-pod-name> -n kube-system -o=jsonpath='{.spec.containers[0].image}'. Dans l’état retourné, notez la valeur sous Image pour l’agent Azure Monitor, dans la section Containers de la sortie.
  • Sous l’onglet Nœuds, sélectionnez le nœud de cluster. Dans le volet Propriétés à droite, notez la valeur sous Balise d’image de l’agent.

La version de l’agent indiquée doit correspondre à la version la plus récente répertoriée sur la page Historique de version.

Mettre à niveau l’agent sur un cluster Kubernetes hybride

Procédez comme suit pour mettre à niveau l’agent sur un cluster Kubernetes s’exécutant sur :

  • Des clusters Kubernetes automanagés hébergés sur Azure à l’aide du moteur AKS.
  • Des clusters Kubernetes automanagés hébergés sur Azure Stack ou localement à l’aide du moteur AKS.

Si l’espace de travail Log Analytics se trouve dans un cloud commercial Azure, exécutez la commande suivante :

$ helm upgrade --set omsagent.secret.wsid=<your_workspace_id>,omsagent.secret.key=<your_workspace_key>,omsagent.env.clusterName=<my_prod_cluster> incubator/azuremonitor-containers

Si l’espace de travail Log Analytics se trouve dans Microsoft Azure géré par 21Vianett, exécutez la commande suivante :

$ helm upgrade --set omsagent.domain=opinsights.azure.cn,omsagent.secret.wsid=<your_workspace_id>,omsagent.secret.key=<your_workspace_key>,omsagent.env.clusterName=<your_cluster_name> incubator/azuremonitor-containers

Si l’espace de travail Log Analytics se trouve dans Azure US Government, exécutez la commande suivante :

$ helm upgrade --set omsagent.domain=opinsights.azure.us,omsagent.secret.wsid=<your_workspace_id>,omsagent.secret.key=<your_workspace_key>,omsagent.env.clusterName=<your_cluster_name> incubator/azuremonitor-containers

Désactiver la collecte des variables d’environnement sur un conteneur

Container Insights collecte des variables d’environnement à partir des conteneurs en cours d’exécution dans un pod, puis les présente dans le volet des propriétés du conteneur sélectionné dans l’affichage Conteneurs. Vous pouvez contrôler ce comportement en désactivant la collecte pour un conteneur spécifique, soit pendant le déploiement du cluster Kubernetes, soit après le déploiement en définissant la variable d’environnement AZMON_COLLECT_ENV. Cette fonctionnalité est disponible avec l’agent ciprod11292018 et versions ultérieures.

Pour désactiver la collecte des variables d’environnement sur un nouveau conteneur ou sur un conteneur existant, définissez la variable AZMON_COLLECT_ENV avec la valeur False dans votre fichier de configuration YAML pour le déploiement de Kubernetes.

- name: AZMON_COLLECT_ENV  
  value: "False"

Pour appliquer la modification aux clusters Kubernetes autres qu’Azure Red Hat OpenShift, exécutez cette commande : kubectl apply -f <path to yaml file>. Pour modifier ConfigMap et appliquer cette modification aux clusters Azure Red Hat OpenShift, exécutez la commande suivante :

oc edit configmaps container-azm-ms-agentconfig -n openshift-azure-logging

Cette commande ouvre votre éditeur de texte par défaut. Définissez la variable, puis enregistrez le fichier dans l’éditeur.

Pour vérifier que le changement de configuration est effectif, sélectionnez un conteneur dans l’affichage Conteneurs de Insights de conteneur. Dans le volet de propriétés, développez Variables d’environnement. La section doit afficher uniquement la variable créée précédemment, qui est AZMON_COLLECT_ENV=FALSE. Pour tous les autres conteneurs, la section des variables d’environnement doit répertorier toutes les variables d’environnement détectées.

Pour réactiver la découverte des variables environnementales, appliquez le même processus que celui que vous avez utilisé précédemment et remplacez la valeur Falsepar True. Réexécutez ensuite la kubectl commande pour mettre à jour le conteneur.

- name: AZMON_COLLECT_ENV  
  value: "True"

Mise à jour de version sémantique de la version de l’agent Container Insights

Container Insights a déplacé la version de l’image et la convention d’affectation de noms vers [semver format] (https://semver.org/). SemVer aide les développeurs à suivre toutes les modifications apportées aux logiciels pendant sa phase de développement et garantit que la gestion des versions logicielles est cohérente et significative. L’ancienne version était au format ciprod<timestamp>-<commitId> et win-ciprod<timestamp>-<commitId>, nos premières versions d’image utilisant le format Semver sont 3.1.4 pour Linux et win-3.1.4 pour Windows.

SemVer est un schéma de contrôle de version de logiciel universel défini au format MAJOR.MINOR.PATCH, qui présente les contraintes suivantes :

  1. Incrémentez la version MAJOR lorsque vous apportez des modifications d’API incompatibles.
  2. Incrémentez la version MINOR lorsque vous ajoutez des fonctionnalités de manière rétrocompatible.
  3. Incrémentez la version de PATCH lorsque vous apportez des correctifs de bogues rétrocompatibles.

Avec l’essor de Kubernetes et de l’écosystème OSS, Container Insights migre pour utiliser l’image SemVer en suivant la norme recommandée K8s dans laquelle, avec chaque version mineure introduite, tous les changements cassants devaient être décrits publiquement avec chaque nouvelle version de Kubernetes.

Réparer les agents dupliqués

Si vous avez activé manuellement container Recommandations à l’aide de méthodes personnalisées antérieures à octobre 2022, vous pouvez finir par plusieurs versions de l’agent en cours d’exécution. Suivez les étapes ci-dessous pour effacer cette duplication.

  1. Rassemblez les détails de tous les paramètres personnalisés, tels que la mémoire et les limites du processeur sur vos conteneurs omsagent.

  2. Passez en revue les limites de ressources par défaut pour ama-logs et déterminez s’ils répondent à vos besoins. Si ce n’est pas le cas, vous devrez peut-être créer une rubrique de support pour vous aider à examiner et à désactiver les limites de mémoire/processeur. Cela peut aider à résoudre les problèmes de limitations de mise à l’échelle rencontrés précédemment par certains clients qui ont entraîné des exceptions OOMKilled.

    Système d’exploitation Nom du contrôleur Limites par défaut
    Linux ds-cpu-limit-linux 500m
    Linux ds-memory-limit-linux 750 Mi
    Linux rs-cpu-limit 1
    Linux rs-memory-limit 1,5 Gi
    Windows ds-cpu-limit-windows 500m
    Windows ds-memory-limit-windows 1Gi

  3. Nettoyer les ressources de l’intégration précédente :

    Si vous avez déjà intégré à l’aide du graphique Helm :

    Répertoriez toutes les versions entre les espaces de noms avec la commande suivante :

     helm list --all-namespaces

    Nettoyez le graphique installé pour Container Insights avec la commande suivante :

    helm uninstall <releaseName> --namespace <Namespace>

    Si vous avez déjà intégré à l’aide du déploiement yaml :

    Téléchargez le fichier yaml de déploiement personnalisé précédent avec la commande suivante :

    curl -LO raw.githubusercontent.com/microsoft/Docker-Provider/ci_dev/kubernetes/omsagent.yaml

    Nettoyez l’ancien graphique omsagent avec la commande suivante :

    kubectl delete -f omsagent.yaml

  4. Désactiver Container Insights pour propre toutes les ressources associées à l’aide des instructions de Désactiver Container Insights sur votre cluster Kubernetes

  5. Réinscrire à Container Insights à l’aide des instructions de l’option Activer Container Insights sur votre cluster Kubernetes

Étapes suivantes

Si vous rencontrez des problèmes lors de la mise à niveau de l'agent, consultez le guide de résolution des problèmes.