你当前正在访问 Microsoft Azure Global Edition 技术文档网站。如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

容器见解中的多租户托管日志记录（预览版）

2025-04-17

容器见解中的多租户日志记录对于使用 AKS 操作共享群集平台的客户非常有用。你可能需要能够以按不同团队隔离日志的方式配置容器控制台日志收集，以便每个团队都可以访问在其拥有的 K8s 命名空间中运行的容器的容器日志，并能够访问与 Azure Log Analytics 工作区关联的计费和管理。例如，来自基础结构命名空间（例如 kube-system）的容器日志可以定向到基础结构团队的特定 Log Analytics 工作区，而每个应用程序团队的容器日志都可以发送到各自的工作区。

本文介绍多租户日志记录在容器洞察中的工作原理、支持的场景以及如何启动群集以使用此功能。

应用场景

容器洞察中的多租户日志记录功能支持下列情况：

多租户。 将容器日志（stdout 和 stderr）从一个或多个 K8s 命名空间发送到相应的 Log Analytics 工作区。
多宿主： 将同一组容器日志（stdout 和 stderr）从一个或多个 K8s 命名空间发送到多个 Log Analytics 工作区。

工作原理

容器见解使用数据收集规则（DCR）来定义 AKS 群集的数据收集设置。启用 Container insights 功能时，会自动创建默认的 ContainerInsights 扩展 DCR。此 DCR 是单一实例，这意味着每个 Kubernetes 群集有一个 DCR。

对于多租户日志记录，Container Insights 添加了对 ContainerLogV2Extension DCR 的支持，后者用于定义 K8s 命名空间的容器日志集合。可以使用不同命名空间的不同设置创建多个 ContainerLogV2Extension DCR，并将其全部与同一 AKS 群集关联。

通过 ConfigMap 启用多租户功能时，Container Insights 代理会定期提取默认 ContainerInsights 扩展 DCR 和与 AKS 群集关联的 ContainerLogV2Extension DCR。从容器启动时开始，每隔 5 分钟执行一次此提取。如果添加了任何其他 ContainerLogV2Extension DCR，可在下次执行提取时识别它们。除了容器日志之外，默认 DCR 中所有配置的流将继续像往常一样发送到默认 ContainerInsights DCR 中的 Log Analytics 工作区。

以下逻辑用于确定如何处理每个日志条目：

如果日志条目的命名空间存在 ContainerLogV2Extension DCR，则使用该 DCR 来处理该条目。这包括 Log Analytics 工作区目标以及任何引入时间转换。
如果日志条目的命名空间没有 ContainerLogV2Extension DCR，则默认 ContainerInsights DCR 用于处理该条目。

局限性

请参阅容器见解中大规模日志收集的限制。
每个群集最多支持 30 个 ContainerLogV2Extension DCR 关联。

先决条件

必须根据 Container Insights（预览版）中高规模日志收集的指导配置群集的高日志规模模式。
使用 DCR 为每个应用程序或基础结构团队创建数据收集终结点（DCE）。每个 DCE 的 日志引入 终结点必须在防火墙中配置，如容器见解中大规模日志收集的网络防火墙要求中所述。

为群集启用多租户

按照配置和部署 ConfigMap 中的指南下载和更新群集的 ConfigMap。
通过如下方式更改 enabled 下的 agent_settings.high_log_scale 设置来启用高缩放模式。
```
agent-settings: |-
    [agent_settings.high_log_scale]
        enabled = true
```

通过按如下所示更改 enabled 下的 log_collection_settings.multi_tenancy 设置来启用多租户。

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

使用以下命令将 ConfigMap 应用到群集。

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

为每个应用程序或基础结构团队创建 DCR

重复以下步骤，为每个应用程序或基础结构团队创建单独的 DCR。每个命名空间将包括一组 K8s 命名空间和一个 Log Analytics 工作区目标。

小提示

对于多宿主，请为每个 Log Analytics 工作区部署单独的 DCR 模板和参数文件，并包含相同的 K8s 命名空间集。这样就可以将相同的日志发送到多个工作区。例如，如果要将 app-team-1 的日志、app-team-2 发送到 LAW1 和 LAW2，

创建 DCR1 并将在 app-team-1 和 app-team-2 命名空间中包含 LAW1
创建 DCR2 并包括 app-team-1 和 app-team-2 命名空间的 LAW2

检索以下 ARM 模板和参数文件。

模板：https://aka.ms/aks-enable-monitoring-multitenancy-onboarding-template-file
参数：https://aka.ms/aks-enable-monitoring-multitenancy-onboarding-template-parameter-file

用以下值编辑参数文件。

参数名称	DESCRIPTION
`aksResourceId`	AKS 群集的 Azure 资源 ID
`aksResourceLocation`	AKS 群集的 Azure 区域
`workspaceResourceId`	Log Analytics 工作区的 Azure 资源 ID
`workspaceRegion`	Log Analytics 工作区的 Azure 区域
`K8sNamespaces`	要发送到此参数文件中定义的 Log Analytics 工作区的日志的 K8s 命名空间列表。
`resourceTagValues`	用于 AKS、数据收集规则（DCR）和数据收集终结点（DCE）的 Azure 资源标记。
`transformKql`	使用引入时转换进行高级筛选的 KQL 筛选器。例如，若要排除特定 Pod 的日志，请使用 `source \\| where PodName != '<podName>'`。请参阅 Azure Monitor 中的转换以了解详细信息。
`useAzureMonitorPrivateLinkScope`	指示是否配置 Azure Monitor 专用链接范围。
`azureMonitorPrivateLinkScopeResourceId`	Azure Monitor 专用链接范围的 Azure 资源 ID。

使用参数文件通过以下命令部署模板。

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

禁用多租户日志记录

注释

如果要完全禁用群集的容器见解，请参阅禁用对 Kubernetes 群集的监视。

使用以下步骤在群集上禁用多租户日志记录。

使用以下命令列出群集的所有 DCR 关联。

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

使用以下命令删除 ContainerLogV2 扩展的所有 DCR 关联。

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

删除“ContainerLogV2Extension DCR”。

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

编辑container-azm-ms-agentconfig并在enabled下将[log_collection_settings.multi_tenancy]的值从true更改为false。
```
kubectl edit cm container-azm-ms-agentconfig -n kube-system -o yaml
```

故障排除

执行以下步骤，排查容器见解中多租户日志记录的问题。

验证是否为群集启用了大规模日志记录。

  # 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"

验证是否已为群集启用 ContainerLogV2 架构。

  # 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

验证是否为群集启用了多租户。

  # 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"

验证是否已创建与 ContainerInsightsExtension 和 ContainerLogV2Extension 相关的 DCR 和 DCE。

    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

验证代理是否正在下载所有关联的 DCR。

  # 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

检查 fluent-bit-out-oms-runtime.log 文件中是否存在任何错误

  # 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

后续步骤

详细了解容器见解。

通过