Habilitar o monitoramento para clusters Kubernetes

Este artigo descreve como habilitar o monitoramento completo de seus clusters Kubernetes usando os seguintes recursos do Azure Monitor:

• Prometheus gerenciado para coleta de métricas
• Informações de contêiner para coleta de logs
• Grafana gerenciado para visualização.

Usando o portal do Azure, você pode habilitar todos os recursos ao mesmo tempo. Você também pode habilitá-los individualmente usando a CLI do Azure, o modelo do Azure Resource Manager, o Terraform ou a Política do Azure. Cada um desses métodos é descrito neste artigo.

Importante

Os clusters do Kubernetes geram muitos dados de log, o que pode resultar em custos significativos se você não for seletivo sobre os logs coletados. Antes de habilitar o monitoramento para seu cluster, consulte os seguintes artigos para garantir que seu ambiente seja otimizado para custo e que você limite sua coleta de logs apenas aos dados necessários:

• Configurar a coleta de dados e a otimização de custos no Container insights usando a regra de coleta de dados
  Detalhes sobre como personalizar a coleta de logs depois de habilitar o monitoramento, incluindo o uso de configurações predefinidas de otimização de custos.
• Práticas recomendadas para monitorar o Kubernetes com o Azure Monitor
  Práticas recomendadas para monitorar clusters Kubernetes organizados pelos cinco pilares do Azure Well-Architected Framework, incluindo otimização de custos.
• Otimização de custos no Azure Monitor
  Práticas recomendadas para configurar todos os recursos do Azure Monitor para otimizar seus custos e limitar a quantidade de dados que você coleta.

Clusters suportados

Este artigo fornece orientações de integração para os seguintes tipos de clusters. Quaisquer diferenças no processo para cada tipo são anotadas nas seções relevantes.

• Clusters do Kubernetes do Azure (AKS)
• Clusters Kubernetes habilitados para Arc

Pré-requisitos

Permissões

• Você precisa de pelo menos acesso de Colaborador ao cluster para integração.
• Você precisa do Leitor de Monitoramento ou do Colaborador de Monitoramento para exibir dados depois que o monitoramento estiver habilitado.

Pré-requisitos do Managed Prometheus

• O cluster tem de utilizar a autenticação de identidade gerida.
• Os seguintes provedores de recursos devem ser registrados na assinatura do cluster AKS e no espaço de trabalho do Azure Monitor:
  • Microsoft.ContainerService
  • Microsoft.Insights
  • Microsoft.AlertsManagement
  • Microsoft.Monitor
• Os seguintes provedores de recursos devem estar registrados na assinatura do espaço de trabalho Grafana:
  • Microsoft.Dashboard

Pré-requisitos de clusters Kubernetes habilitados para Arc

• Pré-requisitos para extensões de cluster do Kubernetes habilitadas para Azure Arc.
  • Verifique os requisitos de firewall, além dos requisitos de rede do Kubernetes compatíveis com o Azure Arc.
  • Se instalou anteriormente a monitorização para o AKS, certifique-se de que desativou a monitorização antes de prosseguir para evitar problemas durante a instalação da extensão.
  • Se você instalou anteriormente o monitoramento em um cluster usando um script sem extensões de cluster, siga as instruções em Desabilitar o monitoramento do cluster do Kubernetes para excluir este gráfico de leme.

Nota

A extensão Managed Prometheus Arc-Enabled Kubernetes (preview) não suporta as seguintes configurações:

• Distribuições do Red Hat Openshift, incluindo o Azure Red Hat OpenShift (ARO)
• Nós do Windows

Áreas de Trabalho

A tabela a seguir descreve os espaços de trabalho necessários para dar suporte a insights do Managed Prometheus e do Container. Você pode criar cada espaço de trabalho como parte do processo de integração ou usar um espaço de trabalho existente. Consulte Criar uma arquitetura de espaço de trabalho do Log Analytics para obter orientação sobre quantos espaços de trabalho criar e onde eles devem ser colocados.

Caraterística	Área de trabalho	Notas
Prometheus Gerido	Espaço de trabalho do Azure Monitor	Contributor permissão é suficiente para habilitar o complemento para enviar dados para o espaço de trabalho do Azure Monitor. Você precisará de Owner permissão de nível para vincular seu Espaço de Trabalho do Azure Monitor para exibir métricas no Azure Managed Grafana. Isso é necessário porque o usuário que executa a etapa de integração precisa ser capaz de atribuir a função Identidade Monitoring Reader do Sistema Grafana Gerenciado do Azure no Espaço de Trabalho do Azure Monitor para consultar as métricas.
Informações de contentores	Área de trabalho do Log Analytics	Você pode anexar um cluster AKS a um espaço de trabalho do Log Analytics em uma assinatura diferente do Azure no mesmo locatário do Microsoft Entra, mas deve usar a CLI do Azure ou um modelo do Azure Resource Manager. No momento, não é possível executar essa configuração com o portal do Azure. Se você estiver conectando um cluster AKS existente a um espaço de trabalho do Log Analytics em outra assinatura, o provedor de recursos Microsoft.ContainerService deverá estar registrado na assinatura com o espaço de trabalho do Log Analytics. Para obter mais informações, consulte Registar fornecedor de recursos. Para obter uma lista dos pares de mapeamento suportados a serem usados para o espaço de trabalho padrão, consulte Mapeamentos de região suportados pelo Container insights.
Managed Grafana	Espaço de trabalho do Azure Managed Grafana	Vincule seu espaço de trabalho do Grafana ao espaço de trabalho do Azure Monitor para disponibilizar as métricas do Prometheus coletadas do cluster para os painéis do Grafana.

Ativar o Prometheus e Grafana

Use um dos seguintes métodos para habilitar a raspagem de métricas do Prometheus do cluster e habilitar o Managed Grafana para visualizar as métricas. Consulte Vincular um espaço de trabalho do Grafana para obter opções para conectar seu espaço de trabalho do Azure Monitor e o espaço de trabalho do Azure Managed Grafana.

Nota

Se você tiver um único Recurso do Azure Monitor vinculado a privados, a habilitação do Prometheus não funcionará se o cluster AKS e o Espaço de Trabalho do Azure Monitor estiverem em regiões diferentes. A configuração necessária para o complemento Prometheus não está disponível entre regiões devido à restrição de link privado. Para resolver isso, crie um novo DCE no local do cluster AKS e um novo DCRA (associação) na mesma região do cluster AKS. Associe o novo DCE ao cluster AKS e nomeie a nova associação (DCRA) como configurationAccessEndpoint. Para obter instruções completas sobre como configurar os DCEs associados ao seu espaço de trabalho do Azure Monitor para usar um Link Privado para ingestão de dados, consulte Habilitar link privado para monitoramento do Kubernetes no Azure Monitor.

CLI

Ativar com CLI

Se você não especificar um espaço de trabalho existente do Azure Monitor nos comandos a seguir, o espaço de trabalho padrão para o grupo de recursos será usado. Se ainda não existir um espaço de trabalho padrão na região do cluster, um com um nome no formato DefaultAzureMonitorWorkspace-<mapped_region> será criado em um grupo de recursos com o nome DefaultRG-<cluster_region>.

Pré-requisitos

• Az CLI versão 2.49.0 ou superior é necessária.
• A extensão aks-preview deve ser desinstalada dos clusters AKS usando o comando az extension remove --name aks-preview.
• A extensão k8s deve ser instalada usando o comando az extension add --name k8s-extension.
• É necessária a extensão k8s versão 1.4.1 ou superior.

Cluster do AKS

Use a -enable-azure-monitor-metrics opção az aks create ou az aks update (dependendo se você está criando um novo cluster ou atualizando um cluster existente) para instalar o complemento de métricas que raspa as métricas do Prometheus.

Comandos de exemplo

Azure CLI

### Use default Azure Monitor workspace
az aks create/update --enable-azure-monitor-metrics --name <cluster-name> --resource-group <cluster-resource-group>

### Use existing Azure Monitor workspace
az aks create/update --enable-azure-monitor-metrics --name <cluster-name> --resource-group <cluster-resource-group> --azure-monitor-workspace-resource-id <workspace-name-resource-id>

### Use an existing Azure Monitor workspace and link with an existing Grafana workspace
az aks create/update --enable-azure-monitor-metrics --name <cluster-name> --resource-group <cluster-resource-group> --azure-monitor-workspace-resource-id <azure-monitor-workspace-name-resource-id> --grafana-resource-id  <grafana-workspace-name-resource-id>

### Use optional parameters
az aks create/update --enable-azure-monitor-metrics --name <cluster-name> --resource-group <cluster-resource-group> --ksm-metric-labels-allow-list "namespaces=[k8s-label-1,k8s-label-n]" --ksm-metric-annotations-allow-list "pods=[k8s-annotation-1,k8s-annotation-n]"

Cluster habilitado para arco (visualização)

Azure CLI

### Use default Azure Monitor workspace
az k8s-extension create --name azuremonitor-metrics --cluster-name <cluster-name> --resource-group <resource-group> --cluster-type connectedClusters --extension-type Microsoft.AzureMonitor.Containers.Metrics

## Use existing Azure Monitor workspace
az k8s-extension create --name azuremonitor-metrics --cluster-name <cluster-name> --resource-group <resource-group> --cluster-type connectedClusters --extension-type Microsoft.AzureMonitor.Containers.Metrics --configuration-settings azure-monitor-workspace-resource-id=<workspace-name-resource-id>

### Use an existing Azure Monitor workspace and link with an existing Grafana workspace
az k8s-extension create --name azuremonitor-metrics --cluster-name <cluster-name> --resource-group <resource-group> --cluster-type connectedClusters --extension-type Microsoft.AzureMonitor.Containers.Metrics --configuration-settings azure-monitor-workspace-resource-id=<workspace-name-resource-id> grafana-resource-id=<grafana-workspace-name-resource-id>

### Use optional parameters
az k8s-extension create --name azuremonitor-metrics --cluster-name <cluster-name> --resource-group <resource-group> --cluster-type connectedClusters --extension-type Microsoft.AzureMonitor.Containers.Metrics --configuration-settings azure-monitor-workspace-resource-id=<workspace-name-resource-id> grafana-resource-id=<grafana-workspace-name-resource-id> AzureMonitorMetrics.KubeStateMetrics.MetricAnnotationsAllowList="pods=[k8s-annotation-1,k8s-annotation-n]" AzureMonitorMetrics.KubeStateMetrics.MetricLabelsAllowlist "namespaces=[k8s-label-1,k8s-label-n]"

Qualquer um dos comandos pode usar os seguintes parâmetros opcionais:

• AKS: --ksm-metric-annotations-allow-list
  Arco: --AzureMonitorMetrics.KubeStateMetrics.MetricAnnotationsAllowList
  Lista separada por vírgulas de chaves de anotações do Kubernetes usadas na métrica de kube_resource_annotations do recurso. Por exemplo, kube_pod_annotations é a métrica de anotações para o recurso pods. Por padrão, essa métrica contém apenas rótulos de nome e namespace. Para incluir mais anotações, forneça uma lista de nomes de recursos em sua forma plural e chaves de anotação do Kubernetes que você deseja permitir para eles. Um único * recurso pode ser fornecido para permitir quaisquer anotações, mas isso tem graves implicações de desempenho. Por exemplo, pods=[kubernetes.io/team,...],namespaces=[kubernetes.io/team],....
  
• AKS: --ksm-metric-labels-allow-list
  Arco: --AzureMonitorMetrics.KubeStateMetrics.MetricLabelsAllowlist
  Lista separada por vírgulas de mais chaves de rótulo do Kubernetes que são usadas na métrica kube_resource_labels métrica kube_resource_labels do recurso. Por exemplo, kube_pod_labels é a métrica de rótulos para o recurso pods. Por padrão, essa métrica contém apenas rótulos de nome e namespace. Para incluir mais rótulos, forneça uma lista de nomes de recursos em sua forma plural e chaves de rótulo do Kubernetes que você deseja permitir para eles Um único * pode ser fornecido para cada recurso para permitir quaisquer rótulos, mas isso tem graves implicações de desempenho. Por exemplo, pods=[app],namespaces=[k8s-label-1,k8s-label-n,...],....
  
• AKS: --enable-windows-recording-rules Permite ativar os grupos de regras de gravação necessários para o funcionamento adequado dos painéis do Windows.

Azure Resource Manager

Ativar com modelos ARM

Pré-requisitos

• O espaço de trabalho do Azure Monitor e a instância do Azure Managed Grafana já devem ser criados.
• O modelo deve ser implantado no mesmo grupo de recursos que a instância do Azure Managed Grafana.
• Se a instância do Azure Managed Grafana estiver em uma assinatura diferente da assinatura do espaço de trabalho do Azure Monitor, registre a assinatura do espaço de trabalho do Azure Monitor com o Microsoft.Dashboard provedor de recursos usando as orientações em Registrar provedor de recursos.
• Os usuários com a User Access Administrator função na assinatura do cluster AKS podem habilitar a Monitoring Reader função diretamente implantando o modelo.

Nota

Atualmente, no Bicep, não há como definir explicitamente o escopo da Monitoring Reader atribuição de função em um parâmetro de cadeia de caracteres "ID de recurso" para um espaço de trabalho do Azure Monitor, como em um modelo ARM. Bicep espera um valor do tipo resource | tenant. Também não há nenhuma especificação de API REST para um espaço de trabalho do Azure Monitor.

Portanto, o escopo padrão para a Monitoring Reader função está no grupo de recursos. A função é aplicada no mesmo espaço de trabalho do Azure Monitor por herança, que é o comportamento esperado. Depois de implantar esse modelo Bicep, a instância do Grafana recebe Monitoring Reader permissões para todos os espaços de trabalho do Azure Monitor nesse grupo de recursos.

Recuperar valores necessários para o recurso Grafana

Se a instância do Azure Managed Grafana já estiver vinculada a um espaço de trabalho do Azure Monitor, você deverá incluir essa lista no modelo. Na página Visão geral da azureMonitorWorkspaceIntegrations instância do Azure Managed Grafana no portal do Azure, selecione Exibição JSON e copie cujo valor será semelhante ao exemplo abaixo. Se não existir, a instância não foi vinculada a nenhum espaço de trabalho do Azure Monitor.

JSON

"properties": {
    "grafanaIntegrations": {
        "azureMonitorWorkspaceIntegrations": [
            {
                "azureMonitorWorkspaceResourceId": "full_resource_id_1"
            },
            {
                "azureMonitorWorkspaceResourceId": "full_resource_id_2"
            }
        ]
    }
}

Baixar e editar modelo e arquivo de parâmetro

1. Baixe os arquivos necessários para o tipo de cluster do Kubernetes com o qual você está trabalhando.

   AKS cluster ARM

   • Arquivo de modelo: https://aka.ms/azureprometheus-enable-arm-template
   • Arquivo de parâmetros: https://aka.ms/azureprometheus-enable-arm-template-parameters

   Cluster AKS Bíceps

   • Arquivo de modelo: https://aka.ms/azureprometheus-enable-bicep-template
   • Arquivo de parâmetros: https://aka.ms/azureprometheus-enable-bicep-template-parameters
   • Módulo DCRA: https://aka.ms/nested_azuremonitormetrics_dcra_clusterResourceId
   • Módulo de perfil: https://aka.ms/nested_azuremonitormetrics_profile_clusterResourceId
   • Módulo de atribuição de função do Azure Managed Grafana: https://aka.ms/nested_grafana_amw_role_assignment

   Cluster habilitado para arco (visualização) ARM

   • Arquivo de modelo: https://aka.ms/azureprometheus-arc-arm-template
   • Arquivo de parâmetros: https://aka.ms/azureprometheus-arc-arm-template-parameters

2. Edite os seguintes valores no arquivo de parâmetro. O mesmo conjunto de valores é usado para os modelos ARM e Bicep. Recupere a ID do recurso dos recursos na visualização JSON da página Visão geral.

   Parâmetro	Value
   azureMonitorWorkspaceResourceId	ID do recurso para o espaço de trabalho do Azure Monitor. Recupere do modo de exibição JSON na página Visão geral do espaço de trabalho do Azure Monitor.
   azureMonitorWorkspaceLocation	Local do espaço de trabalho do Azure Monitor. Recupere do modo de exibição JSON na página Visão geral do espaço de trabalho do Azure Monitor.
   clusterResourceId	ID do recurso para o cluster AKS. Recupere a partir da visualização JSON na página Visão geral do cluster.
   clusterLocation	Localização do cluster AKS. Recupere a partir da visualização JSON na página Visão geral do cluster.
   metricLabelsAllowlist	Lista separada por vírgulas de chaves de rótulos do Kubernetes a serem usadas na métrica de rótulos do recurso.
   metricAnnotationsAllowList	Lista separada por vírgulas de mais chaves de rótulo do Kubernetes a serem usadas na métrica de anotações do recurso.
   grafanaResourceId	ID do recurso para a instância gerenciada do Grafana. Recupere a partir da visualização JSON na página Visão geral da instância Grafana.
   grafanaLocation	Local para a instância gerenciada do Grafana. Recupere a partir da visualização JSON na página Visão geral da instância Grafana.
   grafanaSku	SKU para a instância gerenciada do Grafana. Recupere a partir da visualização JSON na página Visão geral da instância Grafana. Use o sku.name.

3. Abra o arquivo de modelo e atualize a grafanaIntegrations propriedade no final do arquivo com os valores recuperados da instância Grafana. Isso será semelhante aos exemplos a seguir. Nesses exemplos, full_resource_id_1 e full_resource_id_2 já estavam no recurso JSON do Azure Managed Grafana. A entrada final azureMonitorWorkspaceResourceId já está no modelo e é usada para vincular à ID de recurso do espaço de trabalho do Azure Monitor fornecida no arquivo de parâmetros.

   BRAÇO

   JSON

   {
       "type": "Microsoft.Dashboard/grafana",
       "apiVersion": "2022-08-01",
       "name": "[split(parameters('grafanaResourceId'),'/')[8]]",
       "sku": {
           "name": "[parameters('grafanaSku')]"
       },
       "location": "[parameters('grafanaLocation')]",
       "properties": {
           "grafanaIntegrations": {
           "azureMonitorWorkspaceIntegrations": [
               {
                   "azureMonitorWorkspaceResourceId": "full_resource_id_1"
               },
               {
                   "azureMonitorWorkspaceResourceId": "full_resource_id_2"
               },
               {
                   "azureMonitorWorkspaceResourceId": "[parameters('azureMonitorWorkspaceResourceId')]"
               }
           ]
           }
       }
   }
   

   Bicep

   Bicep

       resource grafanaResourceId_8 'Microsoft.Dashboard/grafana@2022-08-01' = {
           name: split(grafanaResourceId, '/')[8]
           sku: {
               name: grafanaSku
           }
           identity: {
               type: 'SystemAssigned'
           }
           location: grafanaLocation
           properties: {
               grafanaIntegrations: {
                   azureMonitorWorkspaceIntegrations: [
                       {
                           azureMonitorWorkspaceResourceId: 'full_resource_id_1'
                       }
                       {
                           azureMonitorWorkspaceResourceId: 'full_resource_id_2'
                       }
                       {
                           azureMonitorWorkspaceResourceId: azureMonitorWorkspaceResourceId
                       }
                   ]
               }
           }
       }
   

4. Implante o modelo com o arquivo de parâmetro usando qualquer método válido para implantar modelos do Gerenciador de Recursos. Para obter exemplos de métodos diferentes, consulte Implantar os modelos de exemplo.

Terraform

Ativar com Terraform

Pré-requisitos

• O espaço de trabalho do Azure Monitor e o espaço de trabalho do Azure Managed Grafana já devem ser criados.
• O modelo precisa ser implantado no mesmo grupo de recursos que o espaço de trabalho do Azure Managed Grafana.
• Os usuários com a função de Administrador de Acesso de Usuário na assinatura do cluster AKS podem habilitar a função Leitor de Monitoramento diretamente implantando o modelo.
• Se a instância do Azure Managed Grafana estiver em uma assinatura diferente da assinatura do Azure Monitor Workspaces, registre a assinatura do Azure Monitor Workspace com o Microsoft.Dashboard provedor de recursos seguindo esta documentação.

Recuperar valores necessários para um recurso Grafana

Na página Visão geral da instância do Azure Managed Grafana no portal do Azure, selecione Exibição JSON.

Se você estiver usando uma instância existente do Azure Managed Grafana que já esteja vinculada a um espaço de trabalho do Azure Monitor, precisará da lista de integrações do Grafana. Copie o azureMonitorWorkspaceIntegrations valor do campo. Se não existir, a instância não foi vinculada a nenhum espaço de trabalho do Azure Monitor. Atualize o azure_monitor_workspace_integrations bloco com main.tf a lista de integrações grafana.

.tf

  azure_monitor_workspace_integrations {
    resource_id  = var.monitor_workspace_id[var.monitor_workspace_id1, var.monitor_workspace_id2]
  }

Baixe e edite os modelos

Se você estiver implantando um novo cluster AKS usando o Terraform com o addon Prometheus gerenciado habilitado, siga estas etapas:

1. Baixe todos os arquivos em AddonTerraformTemplate.
2. Edite as variáveis em variables.tf arquivo com os valores de parâmetro corretos.
3. Execute terraform init -upgrade para inicializar a implantação do Terraform.
4. Execute terraform plan -out main.tfplan para inicializar a implantação do Terraform.
5. Execute terraform apply main.tfplan para aplicar o plano de execução à sua infraestrutura de nuvem.

Nota: Passe as variáveis para annotations_allowed e labels_allowed as chaves em main.tf somente quando esses valores existirem. Estes são blocos opcionais.

Nota

Edite o arquivo main.tf adequadamente antes de executar o modelo terraform. Adicione quaisquer valores de azure_monitor_workspace_integrations existentes ao recurso grafana antes de executar o modelo. Caso contrário, os valores mais antigos serão excluídos e substituídos pelo que está lá no modelo durante a implantação. Os usuários com a função 'Administrador de Acesso de Usuário' na assinatura do cluster AKS podem habilitar a função 'Leitor de Monitoramento' diretamente implantando o modelo. Edite o parâmetro grafanaSku se estiver usando um SKU não padrão e, finalmente, execute este modelo no grupo de recursos do Recurso Grafana.

Azure Policy

Ativar com o Azure Policy

1. Baixe os arquivos de modelo e parâmetro da Política do Azure.

   • Arquivo de modelo: https://aka.ms/AddonPolicyMetricsProfile
   • Arquivo de parâmetros: https://aka.ms/AddonPolicyMetricsProfile.parameters

2. Crie a definição de política usando o seguinte comando da CLI:

   az policy definition create --name "Prometheus Metrics addon" --display-name "Prometheus Metrics addon" --mode Indexed --metadata version=1.0.0 category=Kubernetes --rules AddonPolicyMetricsProfile.rules.json --params AddonPolicyMetricsProfile.parameters.json

3. Depois de criar a definição de política, no portal do Azure, selecione Política e, em seguida , Definições. Selecione a definição de política que criou.

4. Selecione Atribuir e preencha os detalhes na guia Parâmetros . Selecione Rever + Criar.

5. Se desejar aplicar a política a um cluster existente, crie uma tarefa de Correção para esse recurso de cluster a partir da Atribuição de Política.

Depois que a política for atribuída à assinatura, sempre que você criar um novo cluster sem o Prometheus habilitado, a política será executada e implantada para habilitar o monitoramento do Prometheus.

Habilitar insights de contêiner

Use um dos seguintes métodos para habilitar o Container insights em seu cluster. Quando terminar, consulte Configurar a recolha de dados do agente para informações de contentores para personalizar a configuração e para garantir que não recolhe mais dados do que o necessário.

CLI

Use um dos seguintes comandos para habilitar o monitoramento de seus clusters habilitados para AKS e Arc. Se você não especificar um espaço de trabalho existente do Log Analytics, o espaço de trabalho padrão para o grupo de recursos será usado. Se ainda não existir um espaço de trabalho padrão na região do cluster, será criado um com um nome no formato DefaultWorkspace-<GUID>-<Region>.

Pré-requisitos

• Azure CLI versão 2.43.0 ou superior
• A autenticação de identidade gerenciada é padrão na CLI versão 2.49.0 ou superior.
• Azure k8s-extension versão 1.3.7 ou superior
• A autenticação de identidade gerenciada é o padrão na extensão k8s versão 1.43.0 ou superior.
• A autenticação de identidade gerenciada não é suportada para clusters Kubernetes habilitados para Arc com ARO (Azure Red Hat Openshift) ou nós do Windows. Use a autenticação herdada.
• Para CLI versão 2.54.0 ou superior, o esquema de log será configurado para ContainerLogV2 usando ConfigMap.

Nota

Você pode habilitar o esquema ContainerLogV2 para um cluster usando a Regra de Coleta de Dados (DCR) ou o ConfigMap do cluster. Se ambas as configurações estiverem habilitadas, o ConfigMap terá precedência. Os logs Stdout e stderr só serão ingeridos na tabela ContainerLog quando o DCR e o ConfigMap estiverem explicitamente desativados.

Cluster do AKS

Azure CLI

### Use default Log Analytics workspace
az aks enable-addons --addon monitoring --name <cluster-name> --resource-group <cluster-resource-group-name>

### Use existing Log Analytics workspace
az aks enable-addons --addon monitoring --name <cluster-name> --resource-group <cluster-resource-group-name> --workspace-resource-id <workspace-resource-id>

### Use legacy authentication
az aks enable-addons --addon monitoring --name <cluster-name> --resource-group <cluster-resource-group-name> --workspace-resource-id <workspace-resource-id> --enable-msi-auth-for-monitoring false

Exemplo

Azure CLI

az aks enable-addons --addon monitoring --name "my-cluster" --resource-group "my-resource-group" --workspace-resource-id "/subscriptions/my-subscription/resourceGroups/my-resource-group/providers/Microsoft.OperationalInsights/workspaces/my-workspace"

Cluster habilitado para arco

Azure CLI

### Use default Log Analytics workspace
az k8s-extension create --name azuremonitor-containers --cluster-name <cluster-name> --resource-group <resource-group> --cluster-type connectedClusters --extension-type Microsoft.AzureMonitor.Containers

### Use existing Log Analytics workspace
az k8s-extension create --name azuremonitor-containers --cluster-name <cluster-name> --resource-group <resource-group> --cluster-type connectedClusters --extension-type Microsoft.AzureMonitor.Containers --configuration-settings logAnalyticsWorkspaceResourceID=<workspace-resource-id>

### Use managed identity authentication (default as k8s-extension version 1.43.0)
az k8s-extension create --name azuremonitor-containers --cluster-name <cluster-name> --resource-group <resource-group> --cluster-type connectedClusters --extension-type Microsoft.AzureMonitor.Containers --configuration-settings amalogs.useAADAuth=true

### Use advanced configuration settings
az k8s-extension create --name azuremonitor-containers --cluster-name <cluster-name> --resource-group <resource-group> --cluster-type connectedClusters --extension-type Microsoft.AzureMonitor.Containers --configuration-settings  amalogs.resources.daemonset.limits.cpu=150m amalogs.resources.daemonset.limits.memory=600Mi amalogs.resources.deployment.limits.cpu=1 amalogs.resources.deployment.limits.memory=750Mi

### With custom mount path for container stdout & stderr logs
### Custom mount path not required for Azure Stack Edge version > 2318. Custom mount path must be /home/data/docker for Azure Stack Edge cluster with version <= 2318
az k8s-extension create --name azuremonitor-containers --cluster-name <cluster-name> --resource-group <resource-group> --cluster-type connectedClusters --extension-type Microsoft.AzureMonitor.Containers --configuration-settings amalogs.logsettings.custommountpath=<customMountPath>

Consulte a seção solicitações de recursos e limites do gráfico Helm para obter as definições de configuração disponíveis.

Exemplo

Azure CLI

az k8s-extension create --name azuremonitor-containers --cluster-name "my-cluster" --resource-group "my-resource-group" --cluster-type connectedClusters --extension-type Microsoft.AzureMonitor.Containers --configuration-settings logAnalyticsWorkspaceResourceID="/subscriptions/my-subscription/resourceGroups/my-resource-group/providers/Microsoft.OperationalInsights/workspaces/my-workspace"

Cluster habilitado para arco com proxy de encaminhamento

Se o cluster estiver configurado com um proxy de encaminhamento, as configurações de proxy serão aplicadas automaticamente à extensão. No caso de um cluster com AMPLS + proxy, a configuração de proxy deve ser ignorada. Integre a extensão com a configuração .amalogs.ignoreExtensionProxySettings=true

Azure CLI

az k8s-extension create --name azuremonitor-containers --cluster-name <cluster-name> --resource-group <resource-group> --cluster-type connectedClusters --extension-type Microsoft.AzureMonitor.Containers --configuration-settings amalogs.ignoreExtensionProxySettings=true

Cluster habilitado para arco com nós ARO ou OpenShift ou Windows

A autenticação de identidade gerenciada não é suportada para clusters Kubernetes habilitados para Arc com ARO (Azure Red Hat OpenShift) ou nós OpenShift ou Windows. Use a autenticação herdada especificando amalogs.useAADAuth=false como no exemplo a seguir.

Azure CLI

az k8s-extension create --name azuremonitor-containers --cluster-name <cluster-name> --resource-group <resource-group> --cluster-type connectedClusters --extension-type Microsoft.AzureMonitor.Containers --configuration-settings amalogs.useAADAuth=false

Excluir instância de extensão

O comando a seguir exclui apenas a instância de extensão, mas não exclui o espaço de trabalho do Log Analytics. Os dados no recurso Log Analytics são deixados intactos.

Azure CLI

az k8s-extension delete --name azuremonitor-containers --cluster-type connectedClusters --cluster-name <cluster-name> --resource-group <resource-group>

Azure Resource Manager

Os modelos ARM e Bicep são fornecidos nesta seção.

Pré-requisitos

• O modelo deve ser implantado no mesmo grupo de recursos que o cluster.

Baixar e instalar modelo

1. Baixar e editar modelo e arquivo de parâmetro

   AKS cluster ARM

   • Arquivo de modelo: https://aka.ms/aks-enable-monitoring-msi-onboarding-template-file
   • Arquivo de parâmetros: https://aka.ms/aks-enable-monitoring-msi-onboarding-template-parameter-file

   Cluster AKS Bíceps

   • Arquivo de modelo (Syslog): https://aka.ms/enable-monitoring-msi-syslog-bicep-template
   • Arquivo de parâmetro (No Syslog): https://aka.ms/enable-monitoring-msi-syslog-bicep-parameters
   • Arquivo de modelo (No Syslog): https://aka.ms/enable-monitoring-msi-bicep-template
   • Arquivo de parâmetro (No Syslog): https://aka.ms/enable-monitoring-msi-bicep-parameters

   ARM de cluster habilitado para arco

   • Arquivo de modelo: https://aka.ms/arc-k8s-azmon-extension-msi-arm-template
   • Arquivo de parâmetros: https://aka.ms/arc-k8s-azmon-extension-msi-arm-template-params
   • Arquivo de modelo (autenticação herdada): https://aka.ms/arc-k8s-azmon-extension-arm-template
   • Arquivo de parâmetro (autenticação herdada): https://aka.ms/arc-k8s-azmon-extension-arm-template-params

2. Edite os seguintes valores no arquivo de parâmetro. O mesmo conjunto de valores é usado para os modelos ARM e Bicep. Recupere a ID do recurso dos recursos na visualização JSON da página Visão geral.

   Parâmetro	Description
   AKS: aksResourceId Arco: clusterResourceId	ID do recurso do cluster.
   AKS: aksResourceLocation Arco: clusterRegion	A localização do cluster.
   AKS: workspaceResourceId Arco: workspaceResourceId	ID do recurso do espaço de trabalho do Log Analytics.
   Arco: workspaceRegion	Região do espaço de trabalho do Log Analytics.
   Arco: workspaceDomain	Domínio do espaço de trabalho do Log Analytics. opinsights.azure.com para a nuvem pública do Azure opinsights.azure.us para AzureUSGovernment.
   AKS: resourceTagValues	Valores de tag especificados para a DCR (regra de coleta de dados) de extensão de Container insights existente do cluster e o nome do DCR. O nome será MSCI-<clusterName>-<clusterRegion> e este recurso será criado em um grupo de recursos de clusters AKS. Para a primeira integração, você pode definir valores de tag arbitrários.

3. Implante o modelo com o arquivo de parâmetro usando qualquer método válido para implantar modelos do Gerenciador de Recursos. Para obter exemplos de métodos diferentes, consulte Implantar os modelos de exemplo.

Terraform

Novo cluster AKS

1. Baixe o arquivo de modelo Terraform dependendo se você deseja habilitar a coleção Syslog.

   Syslog

   • https://aka.ms/enable-monitoring-msi-syslog-terraform

   Sem Syslog

   • https://aka.ms/enable-monitoring-msi-terraform

2. Ajuste o azurerm_kubernetes_cluster recurso em main.tf com base nas configurações do cluster.

3. Atualizar parâmetros em variables.tf para substituir valores em "<>"

   Parâmetro	Description
   aks_resource_group_name	Use os valores na página Visão geral do AKS para o grupo de recursos.
   resource_group_location	Use os valores na página Visão geral do AKS para o grupo de recursos.
   cluster_name	Defina o nome do cluster que você gostaria de criar.
   workspace_resource_id	Use o ID de recurso do seu espaço de trabalho do Log Analytics.
   workspace_region	Use o local do seu espaço de trabalho do Log Analytics.
   resource_tag_values	Corresponder aos valores de tag existentes especificados para a regra de coleta de dados (DCR) de extensão de Container insights existente do cluster e o nome do DCR. O nome corresponderá MSCI-<clusterName>-<clusterRegion> e este recurso é criado no mesmo grupo de recursos que os clusters AKS. Para a primeira integração, você pode definir os valores de tag arbitrários.
   enabledContainerLogV2	Defina esse valor de parâmetro como true para usar o padrão recomendado ContainerLogV2.
   Parâmetros de otimização de custos	Consulte Parâmetros de coleta de dados

4. Execute terraform init -upgrade para inicializar a implantação do Terraform.

5. Execute terraform plan -out main.tfplan para inicializar a implantação do Terraform.

6. Execute terraform apply main.tfplan para aplicar o plano de execução à sua infraestrutura de nuvem.

Cluster AKS existente

1. Importe o recurso de cluster existente primeiro com o comando: terraform import azurerm_kubernetes_cluster.k8s <aksResourceId>
2. Adicione o perfil de complemento oms_agent ao recurso azurerm_kubernetes_cluster existente.

   oms_agent {
       log_analytics_workspace_id = var.workspace_resource_id
       msi_auth_for_monitoring_enabled = true
     }
   

3. Copie os recursos DCR e DCRA dos modelos Terraform
4. Execute terraform plan -out main.tfplan e verifique se a alteração está adicionando a propriedade oms_agent. Nota: Se o recurso definido for diferente durante o azurerm_kubernetes_cluster plano de terraforme, o cluster existente será destruído e recriado.
5. Execute terraform apply main.tfplan para aplicar o plano de execução à sua infraestrutura de nuvem.

Sugestão

• Edite o main.tf arquivo adequadamente antes de executar o modelo terraform
• Os dados começarão a fluir após 10 minutos, uma vez que o cluster precisa estar pronto primeiro
• WorkspaceID precisa corresponder ao formato /subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/example-resource-group/providers/Microsoft.OperationalInsights/workspaces/workspaceValue
• Se o grupo de recursos já existir, execute antes do terraform import azurerm_resource_group.rg /subscriptions/<Subscription_ID>/resourceGroups/<Resource_Group_Name> plano de terraforma

Azure Policy

Portal do Azure

1. Na guia Definições do menu Política no portal do Azure, crie uma definição de política com os seguintes detalhes.

   • Local de definição: assinatura do Azure onde a definição de política deve ser armazenada.
   • Nome: AKS-Monitoring-Addon
   • Descrição: Política personalizada do Azure para habilitar o Complemento de Monitoramento em clusters do Kubernetes do Azure.
   • Categoria: Selecione Usar existente e, em seguida, Kubernetes na lista suspensa.
   • Regra de política: substitua o JSON de exemplo existente pelo conteúdo do https://aka.ms/aks-enable-monitoring-custom-policy.

2. Selecione a nova definição de política AKS Monitoring Addon.

3. Selecione Atribuir e especifique um Escopo de onde a política deve ser atribuída.

4. Selecione Avançar e forneça o ID do recurso do espaço de trabalho do Log Analytics.

5. Crie uma tarefa de correção se quiser aplicar a política aos clusters AKS existentes no escopo selecionado.

6. Selecione Rever + criar para criar a atribuição de política.

CLI do Azure

1. Baixe os arquivos de modelo e parâmetro da Política do Azure.

   • Arquivo de modelo: https://aka.ms/enable-monitoring-msi-azure-policy-template
   • Arquivo de parâmetros: https://aka.ms/enable-monitoring-msi-azure-policy-parameters

2. Crie a definição de política usando o seguinte comando da CLI:

   az policy definition create --name "AKS-Monitoring-Addon-MSI" --display-name "AKS-Monitoring-Addon-MSI" --mode Indexed --metadata version=1.0.0 category=Kubernetes --rules azure-policy.rules.json --params azure-policy.parameters.json
   

3. Crie a definição de política usando o seguinte comando da CLI:

   az policy assignment create --name aks-monitoring-addon --policy "AKS-Monitoring-Addon-MSI" --assign-identity --identity-scope /subscriptions/<subscriptionId> --role Contributor --scope /subscriptions/<subscriptionId> --location <location> --role Contributor --scope /subscriptions/<subscriptionId> -p "{ \"workspaceResourceId\": { \"value\":  \"/subscriptions/<subscriptionId>/resourcegroups/<resourceGroupName>/providers/microsoft.operationalinsights/workspaces/<workspaceName>\" } }"
   

Depois que a política for atribuída à assinatura, sempre que você criar um novo cluster sem o Prometheus habilitado, a política será executada e implantada para habilitar o monitoramento do Prometheus.

Habilite o monitoramento completo com o portal do Azure

Novo cluster AKS (Prometheus, Container insights, e Grafana)

Ao criar um novo cluster AKS no portal do Azure, você pode habilitar Prometheus, Container insights e Grafana na guia Monitoramento. Certifique-se de marcar as caixas de seleção Habilitar logs de contêiner, Habilitar métricas Prometheus e Habilitar Grafana.

Cluster existente (Prometheus, Container insights, e Grafana)

1. Navegue até o cluster AKS no portal do Azure.
2. No menu de serviço, em Monitoramento, selecione Insights>Configurar monitoramento.
3. O Container insights já está habilitado. Marque as caixas de seleção Ativar métricas Prometheus e Ativar Grafana . Se você tiver o espaço de trabalho do Azure Monitor e o espaço de trabalho do Grafana, eles serão selecionados para você.
4. Selecione Configurações avançadas se quiser selecionar espaços de trabalho alternativos ou criar novos. A configuração Predefinições de custo permite modificar os detalhes de coleta padrão para reduzir os custos de monitoramento. Consulte Habilitar configurações de otimização de custos em Insights de contêiner para obter detalhes.
5. Selecione Configurar.

Cluster existente (apenas Prometheus)

1. Navegue até o cluster AKS no portal do Azure.
2. No menu de serviço, em Monitoramento, selecione Insights>Configurar monitoramento.
3. Marque a caixa de seleção Ativar métricas do Prometheus.
4. Selecione Configurações avançadas se quiser selecionar espaços de trabalho alternativos ou criar novos. A configuração Predefinições de custo permite modificar os detalhes de coleta padrão para reduzir os custos de monitoramento.
5. Selecione Configurar.

Habilitar a coleta de métricas do Windows (visualização)

Nota

Não há limite de CPU/memória no windows-exporter-daemonset.yaml, portanto, ele pode provisionar demais os nós do Windows
Para obter mais detalhes, consulte Reserva de recursos

À medida que você implanta cargas de trabalho, defina a memória de recursos e os limites de CPU em contêineres. Isso também subtrai do NodeAllocatable e ajuda o agendador de todo o cluster a determinar quais pods colocar em quais nós. Agendar pods sem limites pode provisionar demais os nós do Windows e, em casos extremos, pode fazer com que os nós se tornem não íntegros.

A partir da versão 6.4.0-main-02-22-2023-3ee44b9e do contêiner de complemento Managed Prometheus (prometheus_collector), a coleta de métricas do Windows foi habilitada para os clusters AKS. A integração ao complemento Azure Monitor Metrics permite que os pods DaemonSet do Windows comecem a ser executados em seus pools de nós. O Windows Server 2019 e o Windows Server 2022 são suportados. Siga estas etapas para permitir que os pods coletem métricas de seus pools de nós do Windows.

1. Instale manualmente o windows-exporter em nós AKS para acessar as métricas do Windows implantando o arquivo YAML windows-exporter-daemonset . Habilite os seguintes coletores:

   • [defaults]
   • container
   • memory
   • process
   • cpu_info

   Para obter mais coletores, consulte Prometheus exporter for Windows metrics.

   Implante o arquivo YAML windows-exporter-daemonset . Observe que, se houver alguma mancha aplicada no nó, você precisará aplicar as tolerâncias apropriadas.

       kubectl apply -f windows-exporter-daemonset.yaml
   

2. Aplique o ama-metrics-settings-configmap ao cluster. Defina o windowsexporter e windowskubeproxy Booleans como true. Para obter mais informações, consulte Metrics add-on settings configmap.

3. Habilite as regras de gravação necessárias para os painéis prontos para uso:

   • Se a integração estiver usando a CLI, inclua a opção --enable-windows-recording-rules.
   • Se a integração estiver usando um modelo ARM, Bíceps ou Política do Azure, defina enableWindowsRecordingRules como true no arquivo de parâmetros.
   • Se o cluster já estiver integrado, use este modelo ARM e este arquivo de parâmetro para criar os grupos de regras. Isso adicionará as regras de gravação necessárias e não é uma operação ARM no cluster e não afeta o estado atual de monitoramento do cluster.

Verificar a implementação

Use a ferramenta de linha de comando kubectl para verificar se o agente está implantado corretamente.

Prometheus Gerido

Verifique se o DaemonSet foi implantado corretamente nos pools de nós do Linux

AzureCLI

kubectl get ds ama-metrics-node --namespace=kube-system

O número de pods deve ser igual ao número de nós Linux no cluster. A saída deve ser semelhante ao seguinte exemplo:

Output

User@aksuser:~$ kubectl get ds ama-metrics-node --namespace=kube-system
NAME               DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
ama-metrics-node   1         1         1       1            1           <none>          10h

Verifique se os nós do Windows foram implantados corretamente

AzureCLI

kubectl get ds ama-metrics-win-node --namespace=kube-system

O número de pods deve ser igual ao número de nós do Windows no cluster. A saída deve ser semelhante ao seguinte exemplo:

Output

User@aksuser:~$ kubectl get ds ama-metrics-node --namespace=kube-system
NAME                   DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
ama-metrics-win-node   3         3         3       3            3           <none>          10h

Verifique se os dois ReplicaSets foram implantados para o Prometheus

AzureCLI

kubectl get rs --namespace=kube-system

A saída deve ser semelhante ao seguinte exemplo:

Output

User@aksuser:~$kubectl get rs --namespace=kube-system
NAME                            DESIRED   CURRENT   READY   AGE
ama-metrics-5c974985b8          1         1         1       11h
ama-metrics-ksm-5fcf8dffcd      1         1         1       11h

Informações de contentores

Verifique se os DaemonSets foram implantados corretamente nos pools de nós do Linux

AzureCLI

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

O número de pods deve ser igual ao número de nós Linux no cluster. A saída deve ser semelhante ao seguinte exemplo:

Output

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

Verifique se os nós do Windows foram implantados corretamente

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

O número de pods deve ser igual ao número de nós do Windows no cluster. A saída deve ser semelhante ao seguinte exemplo:

Output

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

Verificar a implantação da solução Container insights

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

A saída deve ser semelhante ao seguinte exemplo:

Output

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

Ver configuração com CLI

Use o aks show comando para descobrir se a solução está habilitada, o ID do recurso do espaço de trabalho do Log Analytics e informações resumidas sobre o cluster.

Azure CLI

az aks show --resource-group <resourceGroupofAKSCluster> --name <nameofAksCluster>

O comando retornará informações formatadas em JSON sobre a solução. A addonProfiles seção deve incluir informações sobre o omsagent como no exemplo a seguir:

Output

"addonProfiles": {
    "omsagent": {
        "config": {
            "logAnalyticsWorkspaceResourceID": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/my-resource-group/providers/microsoft.operationalinsights/workspaces/my-workspace",
            "useAADAuth": "true"
        },
        "enabled": true,
        "identity": null
    },
}

Recursos provisionados

Quando você habilita o monitoramento, os seguintes recursos são criados em sua assinatura:

Nome do Recurso	Tipo de Recurso	Grupo de Recursos	Região/Localização	Description
MSCI-<aksclusterregion>-<clustername>	Regra de Recolha de Dados	O mesmo que cluster	O mesmo que o espaço de trabalho do Log Analytics	Esta regra de recolha de dados destina-se à recolha de registos pelo agente do Azure Monitor, que utiliza a área de trabalho do Log Analytics como destino e está associada ao recurso de cluster AKS.
MSPROM-<aksclusterregion>-<clustername>	Regra de Recolha de Dados	O mesmo que cluster	O mesmo que o espaço de trabalho do Azure Monitor	Esta regra de recolha de dados destina-se à recolha de métricas prometheus por addon de métricas, que tem a área de trabalho de monitorização do Azure escolhida como destino e também está associada ao recurso de cluster AKS
MSPROM-<aksclusterregion>-<clustername>	Ponto de extremidade de coleta de dados	O mesmo que cluster	O mesmo que o espaço de trabalho do Azure Monitor	Este ponto de extremidade de coleta de dados é usado pela regra de coleta de dados acima para ingerir métricas Prometheus do complemento de métricas

Quando você cria um novo espaço de trabalho do Azure Monitor, os seguintes recursos adicionais são criados como parte dele

Nome do Recurso	Tipo de Recurso	Grupo de Recursos	Região/Localização	Description
<azuremonitor-workspace-name>	Regra de Recolha de Dados	MA_<azuremonitor-workspace-name>_<azuremonitor-workspace-region>_managed	O mesmo que o Azure Monitor Workspace	DCR criado quando você usa o servidor OSS Prometheus para Gravação Remota no Espaço de Trabalho do Azure Monitor.
<azuremonitor-workspace-name>	Ponto Final de Recolha de Dados	MA_<azuremonitor-workspace-name>_<azuremonitor-workspace-region>_managed	O mesmo que o Azure Monitor Workspace	DCE criado quando você usa o servidor OSS Prometheus para Gravação Remota no Espaço de Trabalho do Azure Monitor.

Diferenças entre clusters Windows e Linux

As principais diferenças no monitoramento de um cluster do Windows Server em comparação com um cluster Linux incluem:

• O Windows não tem uma métrica RSS de memória. Como resultado, ele não está disponível para nós e contêineres do Windows. A métrica Conjunto de Trabalho está disponível.
• As informações sobre a capacidade de armazenamento em disco não estão disponíveis para nós do Windows.
• Apenas os ambientes pod são monitorados, não os ambientes Docker.
• Com a versão de visualização, há suporte para um máximo de 30 contêineres do Windows Server. Essa limitação não se aplica a contêineres Linux.

Nota

O suporte de informações de contêiner para o sistema operacional Windows Server 2022 está em visualização.

O agente Linux em contêiner (pod replicaset) faz chamadas de API para todos os nós do Windows na porta segura do Kubelet (10250) dentro do cluster para coletar métricas relacionadas ao desempenho do nó e do contêiner. A porta segura do Kubelet (:10250) deve ser aberta na rede virtual do cluster para que a coleta de métricas relacionadas ao desempenho do nó do Windows e do contêiner funcione.

Se você tiver um cluster Kubernetes com nós do Windows, revise e configure o grupo de segurança de rede e as políticas de rede para garantir que a porta segura do Kubelet (:10250) esteja aberta para entrada e saída na rede virtual do cluster.

Próximos passos

• Se você tiver problemas ao tentar integrar a solução, consulte o Guia de solução de problemas.
• Com o monitoramento habilitado para coletar a integridade e a utilização de recursos do cluster AKS e das cargas de trabalho em execução neles, saiba como usar o Container insights.