Journalisation gérée multitenante dans Container Insights (version préliminaire)

2025-04-22

La journalisation multilocataire dans Container Insights est utile pour les clients qui exploitent des plateformes de cluster partagées à l’aide d’AKS. Vous devrez peut-être configurer la collecte des journaux de console de conteneur d’une manière qui sépare les journaux d’activité par différentes équipes afin que chacun ait accès aux journaux de conteneur des conteneurs exécutés dans des espaces de noms K8s qu’ils possèdent et la possibilité d’accéder à la facturation et à la gestion associées à l’espace de travail Azure Log Analytics. Par exemple, les journaux de conteneur provenant d’espaces de noms d’infrastructure tels que kube-system peuvent être dirigés vers un espace de travail Log Analytics spécifique pour l’équipe d’infrastructure, tandis que les journaux de conteneur de chaque équipe d’application peuvent être envoyés à leurs espaces de travail respectifs.

Cet article décrit le fonctionnement de la journalisation mutualisée dans Container Insights, les scénarios qu’il prend en charge et comment intégrer votre cluster pour utiliser cette fonctionnalité.

Scénarios

La fonctionnalité de journalisation mutualisée dans Container Insights prend en charge les scénarios suivants :

Architecture mutualisée. Envoie les journaux d’activité de conteneur (stdout &stderr) à partir d’un ou de plusieurs espaces de noms K8s à l’espace de travail Log Analytics correspondant.
Multirésidence : envoie le même ensemble de journaux de conteneur (stdout &stderr) d’un ou plusieurs espaces de noms K8s à plusieurs espaces de travail Log Analytics.

Fonctionnement

Container Insights utilise une règle de collecte de données (DCR) pour définir les paramètres de collecte de données pour votre cluster AKS. Une DCR d’extension ContainerInsights par défaut est créée automatiquement lorsque vous activez Container Insights. Ce DCR est un singleton, ce qui signifie qu’il existe un DCR par cluster Kubernetes.

Pour la journalisation multilocataire, Container Insights ajoute la prise en charge des DCR ContainerLogV2Extension, qui sont utilisées pour définir la collection de journaux d’activité de conteneur pour les espaces de noms K8s. Plusieurs DCRs ContainerLogV2Extension peuvent être créés avec des paramètres différents pour différents namespaces et tous associés au même cluster AKS.

Lorsque vous activez la fonctionnalité de multilocation via un ConfigMap, l’agent Container Insights récupère régulièrement le DCR de l’extension ContainerInsights par défaut ainsi que les DCR ContainerLogV2Extension associés au cluster AKS. Cette extraction est effectuée toutes les 5 minutes à compter du démarrage du conteneur. Si des DCR ContainerLogV2Extension supplémentaires sont ajoutées, elles sont reconnues la prochaine fois que la récupération est effectuée. Tous les flux configurés dans la DCR par défaut en dehors des journaux de conteneur continuent d’être envoyés à l’espace de travail Log Analytics dans le DCR ContainerInsights par défaut comme d’habitude.

La logique suivante permet de déterminer comment traiter chaque entrée de journal :

S’il existe un DCR ContainerLogV2Extension pour l’espace de noms de l’entrée de journal, ce DCR est utilisé pour traiter l’entrée. Cela inclut la destination de l’espace de travail Log Analytics et toute transformation effectuée au moment de l’ingestion.
S’il n’existe pas de DCR ContainerLogV2Extension pour l’espace de noms de l’entrée de journal, le DCR ContainerInsights par défaut est utilisé pour traiter l’entrée.

Limites

Consultez Limitations pour la collecte de journaux d’activité à grande échelle dans Container Insights.
Au maximum 30 associations DCR ContainerLogV2Extension sont prises en charge par cluster.

Conditions préalables

Le mode de mise à l’échelle élevée des journaux doit être configuré pour le cluster à l’aide des instructions de l’article Collecte de journaux à grande échelle dans Container Insights (préversion).
Un point de terminaison de collecte de données (DCE) est créé avec le DCR pour chaque équipe d’application ou d’infrastructure. Le point de terminaison Ingestion des journaux d’activité de chaque DCE doit être configuré dans le pare-feu, comme décrit dans l’article Exigences du pare-feu réseau pour la collecte de journaux à grande échelle dans Container Insights.

Activer l’architecture mutualisée pour le cluster

Suivez les instructions de Configurer et déployer ConfigMap pour télécharger et mettre à jour ConfigMap pour le cluster.
Activez le mode de mise à l’échelle élevée en modifiant le paramètre enabled dans agent_settings.high_log_scale comme suit.
```
agent-settings: |-
    [agent_settings.high_log_scale]
        enabled = true
```

Activez l’architecture mutualisée en modifiant le paramètre enabled sous log_collection_settings.multi_tenancy, comme indiqué ici.

log-data-collection-settings: |-
    [log_collection_settings]
       [log_collection_settings.multi_tenancy]
        enabled = true

Appliquez configMap au cluster avec les commandes suivantes.

kubectl config set-context <cluster-name>
kubectl apply -f <configmap_yaml_file.yaml>

Créer DCR pour chaque équipe d’application ou d’infrastructure

Répétez les étapes suivantes pour créer une DCR distincte pour chaque équipe d’application ou d’infrastructure. Chacun inclut un ensemble d’espaces de noms K8s et une destination d’espace de travail Log Analytics.

Conseil / Astuce

Pour multihoming, déployez un modèle DCR et un fichier de paramètres distincts pour chaque espace de travail Log Analytics et incluez le même ensemble d’espaces de noms K8s. Cela permet d’envoyer les mêmes journaux d’activité à plusieurs espaces de travail. Par exemple, si vous souhaitez envoyer des journaux d’activité pour app-team-1, app-team-2 à LAW1 et LAW2,

Créer DCR1 et inclure LAW1 pour les espaces de noms app-team-1 et app-team-2
Créer DCR2 et inclure LAW2 pour les espaces de noms app-team-1 et app-team-2

Récupérez le modèle ARM et le fichier de paramètres suivants.

Modèle : https://aka.ms/aks-enable-monitoring-multitenancy-onboarding-template-file
Paramètre : https://aka.ms/aks-enable-monitoring-multitenancy-onboarding-template-parameter-file

Modifiez le fichier de paramètres avec des valeurs pour les valeurs suivantes.

Nom du paramètre	Descriptif
`aksResourceId`	ID de ressource Azure du cluster AKS
`aksResourceLocation`	Région Azure du cluster AKS
`workspaceResourceId`	ID de ressource Azure de l’espace de travail Log Analytics
`workspaceRegion`	Région Azure de l’espace de travail Log Analytics
`K8sNamespaces`	Liste des espaces de noms K8s pour les journaux à envoyer à l’espace de travail Log Analytics défini dans ce fichier de paramètres.
`resourceTagValues`	Balises de ressources Azure à utiliser sur AKS, règle de collecte de données (DCR) et point de terminaison de collecte de données (DCE).
`transformKql`	Filtre KQL pour le filtrage avancé utilisant une transformation au moment de l'ingestion. Par exemple, pour exclure les journaux d’activité d’un pod spécifique, utilisez `source \\| where PodName != '<podName>'`. Pour plus d’informations , consultez Transformations dans Azure Monitor .
`useAzureMonitorPrivateLinkScope`	Indique s’il faut configurer l’étendue de liaison privée Azure Monitor.
`azureMonitorPrivateLinkScopeResourceId`	ID de ressource Azure de l’étendue de liaison privée Azure Monitor.

Déployez le modèle à l’aide du fichier de paramètres avec la commande suivante.

az deployment group create --name AzureMonitorDeployment --resource-group <aksClusterResourceGroup> --template-file existingClusterOnboarding.json --parameters existingClusterParam.json

Désactivation de la journalisation multilocataire

Remarque

Consultez Désactiver la surveillance de votre cluster Kubernetes si vous souhaitez désactiver complètement Container Insights pour le cluster.

Procédez comme suit pour désactiver la journalisation multilocataire sur un cluster.

Utilisez la commande suivante pour répertorier toutes les associations DCR pour le cluster.

az monitor data-collection rule association list-by-resource --resource /subscriptions/<subId>/resourcegroups/<rgName>/providers/Microsoft.ContainerService/managedClusters/<clusterName>

Utilisez la commande suivante pour supprimer toutes les associations DCR pour l’extension ContainerLogV2.

az monitor data-collection rule association delete --association-name <ContainerLogV2ExtensionDCRA> --resource /subscriptions/<subId>/resourcegroups/<rgName>/providers/Microsoft.ContainerService/managedClusters/<clusterName>

Supprimez le DCR ContainerLogV2Extension.

az monitor data-collection rule delete --name <ContainerLogV2Extension DCR> --resource-group <rgName>

Modifiez container-azm-ms-agentconfig et changez la valeur de enabled sous [log_collection_settings.multi_tenancy] de true à false.
```
kubectl edit cm container-azm-ms-agentconfig -n kube-system -o yaml
```

Résolution des problèmes

Procédez comme suit pour résoudre les problèmes liés à la journalisation multilocataire dans Container Insights.

Vérifiez que la journalisation à grande échelle est activée pour le cluster.

  # get the list of ama-logs and these pods should be in Running state
  # If these are not in Running state, then this needs to be investigated
  kubectl get po -n kube-system | grep ama-logs
  # get the logs one of the ama-logs daemonset pod and check for log message indicating high scale enabled
  kubectl logs ama-logs-xxxxx -n kube-system -c ama-logs | grep high
  # output should be something like
   "Using config map value: enabled = true for high log scale config"

Vérifiez que le schéma ContainerLogV2 est activé pour le cluster.

  # get the list of ama-logs and these pods should be in Running state
  # If these are not in Running state, then this needs to be investigated
  kubectl get po -n kube-system | grep ama-logs
  # exec into any one of the ama-logs daemonset pod and check for the environment variables
  kubectl exec -it  ama-logs-xxxxx -n kube-system -c ama-logs -- bash
  # check if the containerlog v2 schema enabled or not
  env | grep AZMON_CONTAINER_LOG_SCHEMA_VERSION
  # output should be v2. If not v2, then check whether this is being enabled through DCR
  AZMON_CONTAINER_LOG_SCHEMA_VERSION=v2
  # check if its enabled through DCR
  grep -r "enableContainerLogV2" /etc/mdsd.d/config-cache/configchunks/
  # validate the enableContainerLogV2 configured with true or not from JSON output

Vérifiez que l’architecture mutualisée est activée pour le cluster.

  # get the list of ama-logs and these pods should be in Running state
  # If these are not in Running state, then this needs to be investigated
  kubectl get po -n kube-system | grep ama-logs
  # get the logs one of the ama-logs daemonset pod and check for log message indicating high scale enabled
  kubectl logs ama-logs-xxxxx -n kube-system -c ama-logs | grep multi_tenancy
  # output should be something like
  "config::INFO: Using config map setting multi_tenancy enabled: true, advanced_mode_enabled: false and namespaces: [] for Multitenancy log collection"

Vérifiez que les DCR et DCE liés à ContainerInsightsExtension et ContainerLogV2Extension sont créés.

    az account set -s <clustersubscriptionId>
    az monitor data-collection rule association list-by-resource --resource "<clusterResourceId>"
    # output should list both ContainerInsightsExtension and ContainerLogV2Extension DCRs associated to the cluster
    # From the output, for each dataCollectionRuleId and check dataCollectionEndpoint associated or not
    az monitor data-collection rule show --ids <dataCollectionRuleId>
    # you can also check the extension settings for the K8s namespace configuration

Vérifiez que l'agent télécharge toutes les DCR associées.

  # get the list of ama-logs and these pods should be in Running state
  # If these are not in Running state, then this needs to be investigated
  kubectl get po -n kube-system | grep ama-logs
  # exec into any one of the ama-logs daemonset pod and check for the environment variables
  kubectl exec -it  ama-logs-xxxxx -n kube-system -c ama-logs -- bash
  # check if its enabled through DCR
  grep -r "ContainerLogV2Extension" /etc/mdsd.d/config-cache/configchunks
  # output should list all the associated DCRs and configuration
  # if there are no DCRs downloaded then likely Agent has issues to pull associate DCRs and this could be missing network or firewall issue and check for errors in mdsd.err log file
  cat /var/opt/microsoft/linuxmonagent/log/mdsd.err

Vérifier s’il existe des erreurs dans fluent-bit-out-oms-runtime.log fichier

  # get the list of ama-logs and these pods should be in Running state
  # If these are not in Running state, then this needs to be investigated
  kubectl get po -n kube-system | grep ama-logs
  # exec into any one of the ama-logs daemonset pod and check for the environment variables
  kubectl exec -it ama-logs-xxxxx -n kube-system -c ama-logs -- bash
  # check for errors
  cat /var/opt/microsoft/docker-cimprov/log/fluent-bit-out-oms-runtime.log

Étapes suivantes

En savoir plus sur Container Insights.