Habilitar o monitoramento para clusters de AKS

Conforme descrito no monitoramento do Kubernetes no Azure Monitor, vários recursos do Azure Monitor funcionam juntos para fornecer monitoramento completo dos clusters do AKS (Serviço de Kubernetes do Azure). Este artigo descreve como habilitar os seguintes recursos para clusters do AKS:

• Métricas do Prometheus
• Grafana Gerenciado
• Registro de logs de contêiner
• Logs do painel de controle

Pré-requisitos

• Para integração,é necessário ter pelo menos acesso de Colaborador ao cluster.
• Para visualizar os dados após o monitoramento ser habilitado, é necessário ter a função de Leitor de Monitoramento ou Colaborador de Monitoramento.

Criar workspaces

A tabela a seguir descreve os workspaces necessários para dar suporte aos recursos do Azure Monitor habilitados neste artigo. Se você ainda não tiver um espaço de trabalho existente de cada tipo, poderá criá-los como parte do processo de configuração. Confira Criar uma arquitetura de workspace do Log Analytics para obter diretrizes sobre quantos workspaces criar e onde posicioná-los.

Recurso	Espaço de trabalho	Observações
Prometheus Gerenciado	Workspace do Azure Monitor	Se você não especificar um workspace existente do Azure Monitor durante a integração, o workspace padrão do grupo de recursos será utilizado. Se ainda não houver um workspace padrão na região do seu cluster, um novo será criado com um nome seguindo o formato DefaultAzureMonitorWorkspace-<mapped_region> dentro de um grupo de recursos chamado DefaultRG-<cluster_region>. A permissão Contributor é suficiente para habilitar o complemento para enviar dados para o workspace do Azure Monitor. Você precisará de permissão no nível de Owner para vincular seu Workspace do Azure Monitor para exibir métricas no Espaço Gerenciado do Azure para Grafana. Isso é necessário porque o usuário que executa a etapa de integração precisa ser capaz de fornecer a função Monitoring Reader à Identidade do Sistema de Espaço Gerenciado do Azure para Grafana no Workspace do Azure Monitor para consultar as métricas.
Registro de logs de contêiner Logs do painel de controle	Espaço de Trabalho do Log Analytics	Você pode anexar um cluster 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 existente a um workspace do Log Analytics em outra assinatura, o provedor de recursos Microsoft.ContainerService deverá ser registrado na assinatura com o workspace do Log Analytics. Para saber mais, confira Registrar provedores de recursos. Se você não especificar um workspace do Log Analytics já existente nos comandos a seguir, será usado o workspace padrão para o grupo de recursos. Se um workspace padrão ainda não existir na região do cluster, um será criado com um nome no formato DefaultWorkspace-<GUID>-<Region>. Para obter uma lista dos pares de mapeamento com suporte a serem usados para o workspace padrão, consulte Mapeamento de regiões para insights de contêiner. Consulte Configurar o Azure Monitor com o Perímetro de Segurança de Rede para obter diretrizes sobre como configurar o workspace com o perímetro de segurança de rede.
Grafana Gerenciado	Workspace do Espaço Gerenciado do Azure para Grafana	Vincule seu workspace do Grafana ao seu workspace do Azure Monitor para disponibilizar as métricas do Prometheus coletadas do seu cluster nos painéis do Grafana.

Habilitar métricas do Prometheus e log de contêiner

Quando você habilita o Prometheus e o registro de logs do contêiner em um cluster, uma versão em contêiner do agente do Azure Monitor é instalada no cluster. Você pode configurar esses recursos ao mesmo tempo em um cluster novo ou existente ou habilitar cada recurso separadamente.

Habilite o Espaço Gerenciado para Grafana para o cluster ao mesmo tempo que habilita a coleta de métricas do Prometheus. Confira Vincular um workspace do Grafana para opções de conectar seu workspace do Azure Monitor e o workspace do Espaço Gerenciado do Azure para Grafana.

Pré-requisitos

• O cluster deve usar a autenticação de identidade gerenciada.
• Os seguintes provedores de recursos devem ser registrados na assinatura do cluster e no workspace do Azure Monitor:
  • Microsoft.ContainerService (Serviço de Contêineres)
  • Microsoft.insights
  • Microsoft.GerenciamentoDeAlertas
  • Microsoft.Monitor
• Os seguintes provedores de recursos devem ser registrados na assinatura da assinatura do workspace do Grafana:
  • Microsoft.Dashboard

CLI

Pré-requisitos

• A autenticação de identidade gerenciada será padrão na versão 2.49.0 ou superior da CLI.
• É necessário desinstalar a extensão aks-preview dos clusters do AKS usando o comando az extension remove --name aks-preview.

Métricas do Prometheus

Use a opção -enable-azure-monitor-metrics com az aks create ou az aks update dependendo se você estiver criando um novo cluster ou atualizando um cluster existente para instalar o complemento de métricas que extrai as métricas do Prometheus. Isso usará a configuração descrita na configuração de métricas padrão do Prometheus no Azure Monitor. Para modificar essa configuração, confira Personalizar a extração de métricas do Prometheus no serviço gerenciado para Prometheus do Azure Monitor.

Veja os exemplos a seguir.

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

Exemplo

az aks create/update --enable-azure-monitor-metrics --name "my-cluster" --resource-group "my-resource-group" --azure-monitor-workspace-resource-id "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/my-resource-group/providers/microsoft.monitor/accounts/my-workspace"

Parâmetros opcionais

Cada um dos comandos acima permite os seguintes parâmetros opcionais. O nome do parâmetro é diferente para cada um, mas seu uso é o mesmo.

Parâmetro	Nome e descrição
Chaves de anotação	--ksm-metric-annotations-allow-list Lista de chaves de anotações do Kubernetes separadas por vírgulas usadas na métrica do recurso kube_resource_annotations. Por exemplo, kube_pod_annotations é a métrica de anotações do recurso de 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 no plural e chaves de anotação do Kubernetes que você deseja permitir para elas. Um único * pode ser fornecido para cada recurso para permitir anotações, mas isso tem sérias implicações de desempenho. Por exemplo, pods=[kubernetes.io/team,...],namespaces=[kubernetes.io/team],....
Chaves de rótulo	--ksm-metric-labels-allow-list Lista separada por vírgulas de mais chaves de rótulo do Kubernetes usadas na métrica kube_resource_labels da métrica do recurso kube_resource_labels. Por exemplo, kube_pod_labels é a métrica de rótulos do recurso de 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 dos nomes de recursos no seu formato plural e chaves de rótulo do Kubernetes que você quer permitir para eles. Um único * pode ser fornecido para cada recurso para permitir rótulos, mas isso tem severas implicações de desempenho. Por exemplo, pods=[app],namespaces=[k8s-label-1,k8s-label-n,...],....
Regras de gravação	--enable-windows-recording-rules Permite habilitar os grupos de regras de gravação necessários para o funcionamento adequado dos painéis do Windows.

Observação

Observe que os parâmetros definidos usando - ksm-metric-annotations-allow-list e ksm-metric-labels-allow-list podem ser substituídos ou, como alternativa, definidos usando o ama-metrics-settings-configmap

Logs de contêiner

Use a opção --addon monitoring com az aks create para um novo cluster ou az aks enable-addon para atualizar um cluster existente e habilitar a coleta de logs de contêiner. Veja abaixo para modificar as configurações de coleção de logs.

Veja os exemplos a seguir.

### 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 custom log configuration file
az aks enable-addons --addon monitoring --name <cluster-name> --resource-group <cluster-resource-group-name> --workspace-resource-id <workspace-resource-id> --data-collection-settings dataCollectionSettings.json

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

az aks enable-addons --addon monitoring --name "my-cluster" --resource-group "my-resource-group" --workspace-resource-id "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/my-resource-group/providers/Microsoft.OperationalInsights/workspaces/my-workspace"

Arquivo de configuração de log

Para personalizar as configurações de coleção de logs para o cluster, você pode fornecer a configuração como um arquivo JSON usando o seguinte formato. Se você não fornecer um arquivo de configuração, as configurações padrão identificadas na tabela abaixo serão usadas.

{
  "interval": "1m",
  "namespaceFilteringMode": "Include",
  "namespaces": ["kube-system"],
  "enableContainerLogV2": true, 
  "streams": ["Microsoft-Perf", "Microsoft-ContainerLogV2"]
}

Cada uma das configurações na configuração é descrita na tabela a seguir.

Nome	Descrição
interval	Determina com que frequência o agente coleta dados. Os valores válidos são de 1m a 30m em intervalos de 1m se o valor estiver fora do intervalo permitido, o padrão será 1 m. Padrão: 1m.
namespaceFilteringMode	Inclua: coleta apenas dados dos valores no campo namespaces. Excluir: coleta dados de todos os namespaces, exceto os valores no campo namespaces. Desativado: ignora as seleções de namespace e coleta dados em todos os namespaces. Padrão: Desativado
namespaces	Matriz de namespaces do Kubernetes separados por vírgulas para coletar dados de inventário e perf com base no namespaceFilteringMode. Por exemplo, namespaces = ["kube-system", "default"] com a configuração Incluir coleta apenas esses dois namespaces. Com a configuração Excluir, o agente coleta dados de todos os outros namespaces, exceto kube-system e default. Com a configuração Desativar, o agente coleta dados de todos os namespaces, incluindo kube-system e default. Namespaces inválidos e não reconhecidos são ignorados. Nenhum.
enableContainerLogV2	Sinalizador booliano para habilitar o esquema ContainerLogV2. Se definido como true, os logs stdout/stderr serão ingeridos na tabela ContainerLogV2. Caso contrário, os logs de contêiner serão ingeridos na tabela ContainerLog, a menos que seja especificado de outra forma no ConfigMap. Ao especificar os fluxos individuais, você deve incluir a tabela correspondente para ContainerLog ou ContainerLogV2. Padrão: True
streams	Uma matriz de fluxos de tabela. Consulte os valores do Stream para obter uma lista dos fluxos válidos e suas tabelas correspondentes. Padrão: ContainerLogV2, KubeEvents, KubePodInventory

ARM

Pré-requisitos

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

Observação

Atualmente no Bicep, não há como fazer escopo explicitamente na atribuição de função do Monitoring Reader em um parâmetro de cadeia de caracteres "ID de recurso" para um workspace do Azure Monitor, como é feito em um modelo do ARM. Bicep espera um valor de tipo resource | tenant. Não há especificação de API REST para um workspace do Azure Monitor.

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

Métricas do Prometheus

Recuperar os valores necessários para o recurso Grafana

Se a instância do Espaço Gerenciado do Azure para Grafana já estiver vinculada a um workspace do Azure Monitor, você deverá incluir essa lista no modelo; caso contrário, ela será sobrescrita. Na página Visão geral da instância do Espaço Gerenciado do Azure para Grafana no portal do Azure, selecione a Exibição JSON e copie o valor de azureMonitorWorkspaceIntegrations, que será parecido com o exemplo a seguir. Se não existir, a instância não foi vinculada a um workspace do Azure Monitor.

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

Baixar e editar o modelo e o arquivo de parâmetro

1. Baixe os arquivos necessários.

   Bíceps

   • Arquivo de modelo: https://aka.ms/azureprometheus-enable-bicep-template
   • Arquivo de parâmetro: 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 Grafana Gerenciada do Azure: https://aka.ms/nested_grafana_amw_role_assignment

   JSON

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

2. Edite os seguintes valores no arquivo de parâmetro. O mesmo conjunto de valores é usado para os modelos do ARM e Bicep. Para recuperar o ID do recurso, acesse a Exibição JSON na página de Visão geral do recurso.

   Parâmetro	Valor
   azureMonitorWorkspaceResourceId	ID do recurso para o workspace do Azure Monitor. Recupere da exibição JSON na página Visão geral do workspace do Azure Monitor.
   azureMonitorWorkspaceLocation	Localização do workspace do Azure Monitor. Recupere da exibição JSON na página Visão geral do workspace do Azure Monitor.
   clusterResourceId	ID do recurso para o cluster do AKS. Recupere da exibição JSON na página Visão geral do cluster.
   clusterLocation	Localização do cluster do AKS. Recupere da exibição JSON na página Visão geral do cluster.
   metricLabelsAllowlist	Lista separada por vírgulas das 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ótulos 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 da exibição JSON na página Visão geral da instância do Grafana.
   grafanaLocation	Localização da instância gerenciada do Grafana. Recupere da exibição JSON na página Visão geral da instância do Grafana.
   grafanaSku	SKU da instância gerenciada do Grafana. Recupere da exibição JSON na página Visão geral da instância do Grafana. Defina o sku.name.

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

   Bíceps

       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
                       }
                   ]
               }
           }
       }
   

   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')]"
               }
           ]
           }
       }
   }
   

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

Logs de contêiner

Pré-requisitos

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

Baixar e instalar modelo

1. Baixe e edite o modelo e o arquivo de parâmetro.

   Bíceps

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

   ARM

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

2. Edite os seguintes valores no arquivo de parâmetro. O mesmo conjunto de valores é usado para os modelos do ARM e Bicep. Para recuperar o ID do recurso, acesse a Exibição JSON na página de Visão geral do recurso.

   Parâmetro	Descrição
   aksResourceId	ID do recurso do cluster.
   aksResourceLocation	Localização do cluster.
   workspaceResourceId	A ID do recurso do workspace do Log Analytics.
   resourceTagValues	Valores de marca especificados existentes para a Regra de Coleta de Dados (DCR) da extensão Insights de contêiner do cluster e o nome da DCR. O nome será MSCI-<clusterName>-<clusterRegion> e esse recurso será criado em um grupo de recursos de cluster do AKS. Se essa for a primeira integração, você poderá definir os valores arbitrários da marca.
   enableRetinaNetworkFlowLogs	Sinalize para indicar se os Logs de Fluxo de Rede do Retina devem ser habilitados ou não.
   enableContainerLogV2	Sinalizador booliano para habilitar o esquema ContainerLogV2. Se definido como true, os logs stdout/stderr serão enviados para a tabela ContainerLogV2 . Caso contrário, os logs de contêiner são enviados para a tabela ContainerLog , a menos que especificado de outra forma no ConfigMap. Ao especificar os fluxos individuais, você deve incluir a tabela correspondente para ContainerLog ou ContainerLogV2.
   enableSyslog	Especifica se a coleção Syslog deve ser habilitada.
   syslogLevels	Se a coleção Syslog estiver habilitada, especifica os níveis de log a serem coletados.
   dataCollectionInterval	Determina com que frequência o agente coleta dados. Os valores válidos são de 1m a 30m em intervalos de 1m O valor padrão é 1m. Se o valor estiver fora do intervalo permitido, ele será padronizado como 1 m.
   namespaceFilteringModeForDataCollection	Inclua: coleta apenas dados dos valores no campo namespaces. Excluir: coleta dados de todos os namespaces, exceto os valores no campo namespaces. Desativado: ignora as seleções de namespace e coleta dados em todos os namespaces.
   namespacesForDataCollection	Matriz de namespaces do Kubernetes separados por vírgulas para coletar dados de inventário e perf com base no namespaceFilteringMode. Por exemplo, namespaces = ["kube-system", "default"] com a configuração Incluir coleta apenas esses dois namespaces. Com a configuração Excluir, o agente coleta dados de todos os outros namespaces, exceto kube-system e default. Com a configuração Desativar, o agente coleta dados de todos os namespaces, incluindo kube-system e default. Namespaces inválidos e não reconhecidos são ignorados.
   streams	Uma matriz de fluxos de tabela. Consulte os valores do Stream para obter uma lista dos fluxos válidos e suas tabelas correspondentes.
   useAzureMonitorPrivateLinkScope	Especifica se o link privado deve ser usado para a conexão de cluster com o Azure Monitor.
   azureMonitorPrivateLinkScopeResourceId	Se o link privado for usado, a ID do recurso do escopo do link privado.

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

Terraform

Pré-requisitos

• O workspace do Azure Monitor e o workspace do Espaço Gerenciado do Azure para Grafana já devem ter sido criados.
• O modelo precisa ser implantado no mesmo grupo de recursos que o workspace do Espaço Gerenciado do Azure para Grafana.
• Os usuários com a função Administrador de Acesso do Usuário na assinatura do cluster AKS podem habilitar a função de Leitor de Dados de Monitoramento diretamente através da implantação do modelo.
• Se a instância do Espaço Gerenciado do Azure para Grafana estiver em uma assinatura diferente da assinatura de Espaço de Trabalho do Azure Monitor, registre a assinatura de Espaço de Trabalho do Azure Monitor com o provedor de recursos Microsoft.Dashboard seguindo esta documentação.

Recuperar os valores necessários para o recurso Grafana

Se a instância do Espaço Gerenciado do Azure para Grafana já estiver vinculada a um workspace do Azure Monitor, você deverá incluir essa lista no modelo; caso contrário, ela será sobrescrita. Na página Visão geral da instância do Espaço Gerenciado do Azure para Grafana no portal do Azure, selecione a Exibição JSON e copie o valor de azureMonitorWorkspaceIntegrations, que será parecido com o exemplo a seguir. Se não existir, a instância não foi vinculada a um workspace do Azure Monitor.

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

Atualize o bloco azure_monitor_workspace_integrations em main.tf com a lista de integrações do Grafana.

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

Baixar e editar modelos

Novo cluster do AKS

1. Baixe todos os arquivos em AddonTerraformTemplate.
2. Edite as variáveis no arquivo variables.tf 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.

Observação: passe as variáveis para as chaves annotations_allowed e labels_allowed em main.tf somente quando esses valores existirem. Eles são blocos opcionais.

Observação

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

Logs de contêiner

Novo cluster do AKS

1. Baixe o arquivo de modelo do Terraform, dependendo da sua intenção ao habilitar a coleta do Syslog.

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

2. Ajuste o recurso azurerm_kubernetes_cluster em main.tf de acordo com as configurações do cluster.

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

   Parâmetro	Descrição
   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 a ID de recurso do seu workspace do Log Analytics.
   workspace_region	Use a localização do seu workspace do Log Analytics.
   resource_tag_values	Faça a correspondência entre os valores de tag existentes especificados para a Regra de Coleta de Dados (DCR) da extensão do Insights de Contêiner do cluster e o nome da DCR. O nome corresponderá a MSCI-<clusterName>-<clusterRegion> e esse recurso será criado no mesmo grupo de recursos que os clusters do AKS. Se essa for a primeira integração, você poderá definir os valores arbitrários da marca.
   enabledContainerLogV2	Defina esse valor de parâmetro como true para usar o ContainerLogV2 recomendado padrão.
   Parâmetros de otimização de custos	Consulte Parâmetros de coleta de dados
   streams	Fluxos para coleta de dados. Confira os valores do Stream.
   use_azure_monitor_private_link_scope	Sinalizador para indicar se o Escopo de Link Privado do Azure Monitor deve ser configurado.
   azure_monitor_private_link_scope_resource_id	ID de Recurso do Azure do Escopo de Link Privado do Azure Monitor.

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 do AKS existente

1. Primeiro, importe o recurso de cluster existente 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 do Terraform
4. Execute terraform plan -out main.tfplan e verifique se a alteração está adicionando a propriedade oms_agent. Observação: se o recurso azurerm_kubernetes_cluster definido for diferente durante o plano do Terraform, 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.

Dica

• Edite o arquivo main.tf adequadamente antes de executar o modelo terraform
• Os dados começarão a fluir após 10 minutos, pois o cluster precisa estar pronto primeiro
• O 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 terraform import azurerm_resource_group.rg /subscriptions/<Subscription_ID>/resourceGroups/<Resource_Group_Name> antes do plano terraform

Portal do Azure

Você pode habilitar métricas do Prometheus e logs de contêiner ao criar um cluster do AKS ou em um cluster existente no portal do Azure. Em ambos os casos, a experiência de configuração é a mesma.

Novo cluster do AKS

Ao criar um novo cluster do AKS no portal do Azure, configure o monitoramento na guia Monitoramento .

Cluster existente

Navegue até seu cluster no portal do Azure. No menu de serviço, selecione Monitorar e, em seguida, Monitorar Configurações.

Opções de configuração

As opções de configuração são as mesmas para clusters novos e existentes. A única diferença é que talvez seja necessário selecionar configurações avançadas para exibir todas as opções de um cluster existente.

3. Métricas do Prometheus, Grafana e Logs de Contêiner e eventos são selecionados para você. Se você tiver um workspace existente do Azure Monitor, um workspace existente do Grafana e um workspace existente do Log Analytics, eles estarão automaticamente selecionados para você.
4. Selecione Configurações avançadas se quiser selecionar espaço de trabalho alternativas ou criar novas. A configuração de perfis de log e perfis clássicos permite que você modifique os detalhes da coleção padrão para reduzir os custos de monitoramento. Confira Habilitar configurações de otimização de custos no Insights de Contêiner para obter mais detalhes.
5. Selecione Configurar.

Para logs de contêiner, você deve selecionar um perfil de log, que define quais logs serão coletados e em que frequência. Os perfis disponíveis estão listados na tabela a seguir.

Predefinição de custo	Frequência de coleta	Filtros de namespace	Coleta de Syslog	Dados coletados
Logs e eventos (padrão)	1min	None	não ativado	ContainerLogV2 KubeEvents KubePodInventory
Syslog	1min	None	Habilitado por padrão	Todas as tabelas de insights do contêiner padrão
Standard	1min	None	não ativado	Todas as tabelas de insights do contêiner padrão
Com otimização de custos	5min	Exclui kube-system, gatekeeper-system, azure-arc	não ativado	Todas as tabelas de insights do contêiner padrão

Se você quiser personalizar as configurações, clique em Editar configurações de coleção. Cada uma dessas configurações é descrita na tabela a seguir.

Nome	Descrição
Frequência de coleta	Determina com que frequência o agente coleta dados. Os valores válidos são de 1m a 30m em intervalos de 1m O valor padrão é 1m. Essa opção não pode ser configurada por meio do ConfigMap.
Filtragem de namespace	Desativado: coleta dados em todos os namespaces. Inclua: coleta apenas dados dos valores no campo namespaces. Excluir: coleta dados de todos os namespaces, exceto os valores no campo namespaces. Matriz de namespaces do Kubernetes separados por vírgulas para coletar dados de inventário e perf com base no namespaceFilteringMode. Por exemplo, namespaces = ["kube-system", "default"] com a configuração Incluir coleta apenas esses dois namespaces. Com a configuração Excluir, o agente coleta dados de todos os outros namespaces, exceto kube-system e default.
Dados coletados	Define quais tabelas do Container Insights serão coletadas. Veja abaixo uma descrição de cada agrupamento.
Habilitar a ContainerLogV2	Sinalizador booliano para habilitar o esquema ContainerLogV2. Se definido como true, os logs stdout/stderr serão ingeridos na tabela ContainerLogV2. Caso contrário, os logs de contêiner serão ingeridos na tabela ContainerLog, a menos que seja especificado de outra forma no ConfigMap. Ao especificar os fluxos individuais, você deve incluir a tabela correspondente para ContainerLog ou ContainerLogV2.
Habilitar a coleção Syslog	Habilita a coleção Syslog do cluster.

A opção Dados coletados permite que você selecione as tabelas preenchidas para o cluster. As tabelas são agrupadas pelos cenários mais comuns.

Grouping	Tables	Observações
Todos (padrão)	Todas as tabelas de insights do contêiner padrão	É necessário para habilitar as visualizações de insights de contêiner padrão
Performance	Perf, InsightsMetrics
Logs e eventos	ContainerLog ou ContainerLogV2, KubeEvents, KubePodInventory	Recomendado se você habilitou as métricas gerenciadas do Prometheus
Cargas de trabalho, implantações e HPAs	InsightsMetrics, KubePodInventory, KubeEvents, ContainerInventory, ContainerNodeInventory, KubeNodeInventory, KubeServices
Volumes persistentes	InsightsMetrics, KubePVInventory

Azure Policy

Métricas do Prometheus

1. Baixe os arquivos de parâmetro e o modelo do Azure Policy.

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

2. Crie a definição de política usando o seguinte comando 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 depois Definições. Selecione a definição de política que você criou.

4. Selecione Atribuir e preencha os detalhes na guia Parâmetros. Selecione Examinar + criar.

5. Se você quiser aplicar a política a um cluster já existente, crie uma Tarefa de correção para esse recurso de cluster por meio da Atribuição de Política.

Depois que a política é 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.

portal do Azure

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

   • Local de definição: a assinatura do Azure onde a definição de política deve ser armazenada.
   • Nome: AKS-Monitoring-Addon
   • Descrição: a política personalizada do Azure para habilitar o complemento de monitoramento nos clusters Kubernetes do Azure.
   • Categoria: selecione Usar existente e depois Kubernetes na lista de seleção.
   • Regra de política: substitua o JSON de exemplo existente pelo conteúdo de https://aka.ms/aks-enable-monitoring-custom-policy.

2. Selecione a nova definição de política Complemento de Monitoramento do AKS.

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

4. Selecione Avançar e forneça a ID do recurso do workspace do Log Analytics.

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

6. Selecione Revisar + criar para criar a atribuição de função.

CLI do Azure

1. Baixe os arquivos de parâmetro e o modelo do Azure Policy.

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

2. Crie a definição de política usando o seguinte comando 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 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> -p "{ \"workspaceResourceId\": { \"value\": \"/subscriptions/<subscriptionId>/resourcegroups/<resourceGroupName>/providers/microsoft.operationalinsights/workspaces/<workspaceName>\" }, \"resourceTagValues\": { \"value\": {} }, \"workspaceRegion\": { \"value\": \"<location>\" }}"
   

Depois que a política for atribuída à assinatura, sempre que você criar um cluster sem insights de contêiner habilitados, a política será executada e implantada para habilitar o monitoramento de insights do contêiner.

Valores de fluxo

Ao especificar as tabelas a serem coletadas usando a CLI ou o ARM, especifique um nome de fluxo que corresponda a uma tabela específica no workspace do Log Analytics. A tabela a seguir lista o nome do fluxo para cada tabela.

Observação

Se você estiver familiarizado com a estrutura de uma regra de coleta de dados, os nomes de fluxo nesta tabela serão especificados na seção Fluxos de dados do DCR.

Stream	Tabela de insights do contêiner
Microsoft-ContainerInventory	ContainerInventory
Microsoft-ContainerLog	ContainerLog
Microsoft-ContainerLogV2	ContainerLogV2
Microsoft-ContainerLogV2-HighScale	ContainerLogV2 (Modo de ajuste de escala alta)1
Microsoft-ContainerNodeInventory	ContainerNodeInventory
Microsoft-InsightsMetrics	InsightsMetrics
Microsoft-KubeEvents	KubeEvents
Microsoft-KubeMonAgentEvents	KubeMonAgentEvents
Microsoft-KubeNodeInventory	KubeNodeInventory
Microsoft-KubePodInventory	KubePodInventory
Microsoft-KubePVInventory	KubePVInventory
Microsoft-KubeServices	KubeServices
Microsoft-Perf	Perf
Microsoft-RetinaNetworkFlowLogs	RetinaNetworkFlowLogs

¹ Não use Microsoft-ContainerLogV2 e Microsoft-ContainerLogV2-HighScale juntos. Isso resultará em dados duplicados.

Tabelas e métricas aplicáveis

As configurações de frequência de coleta e filtragem de namespace não se aplicam a todos os dados de log. As tabelas a seguir listam as tabelas no workspace do Log Analytics, juntamente com as configurações que se aplicam a cada uma delas.

Nome da tabela	Intervalo?	Namespaces?	Observações
ContainerInventory	Yes	Yes
ContainerNodeInventory	Yes	Não	A configuração de coleta de dados para namespaces não é aplicável, pois o Nó do Kubernetes não é um recurso com escopo de namespace
KubeNodeInventory	Yes	Não	A configuração de coleta de dados para namespaces não é aplicável. O Nó do Kubernetes não é um recurso com escopo de namespace
KubePodInventory	Yes	Yes
KubePVInventory	Yes	Yes
KubeServices	Yes	Yes
KubeEvents	Não	Yes	A configuração de coleta de dados para intervalo não é aplicável aos eventos do Kubernetes
Perf	Yes	Yes	A configuração de coleta de dados para namespaces não é aplicável às métricas relacionadas ao Nó do Kubernetes, pois o Nó do Kubernetes não é um objeto com escopo de namespace.
InsightsMetrics	Yes	Yes	As configurações de coleta de dados só são aplicáveis para as métricas que coletam os seguintes namespaces: container.azm.ms/kubestate, container.azm.ms/pv e container.azm.ms/gpu

Observação

A filtragem do namespace não se aplica aos registros do agente de ama-logs. Como resultado, mesmo que o namespace do sistema Kube esteja listado entre os namespaces excluídos, os registros associados ao contêiner do agente ama-logs ainda serão ingeridos.

Namespace da métrica	Intervalo?	Namespaces?	Observações
Insights.container/nodes	Yes	Não	O nó não é um recurso com escopo de namespace
Insights.container/pods	Yes	Yes
Insights.container/containers	Yes	Yes
Insights.container/persistentvolumes	Yes	Yes

Cenários especiais

Verifique as referências abaixo para obter requisitos de configuração para cenários específicos.

• Se você estiver usando o link privado, consulte Habilitar link privado para monitoramento do Kubernetes no Azure Monitor.
• Para habilitar o registro de logs de contêiner com o perímetro de segurança de rede, consulte Configurar o Azure Monitor com o Perímetro de Segurança de Rede para configurar seu espaço de trabalho do Log Analytics.
• Para habilitar o modo de alta escala, siga o processo de habilitação em Habilitar modo de alta escala para o complemento de monitoramento. Você também deve configurar o ConfigMap conforme descrito em Update ConfigMap, e o fluxo DCR precisa ser alterado de Microsoft-ContainerLogV2 para Microsoft-ContainerLogV2-HighScale.

Habilitar registros do plano de controle

Os logs do plano de controle são implementados como logs de recursos no Azure Monitor. Para coletar esses logs, crie uma configuração de diagnóstico para o cluster. Envie-os para o mesmo workspace do Log Analytics que os logs de contêiner.

CLI

Use o comando az monitor diagnostic-settings create para criar uma configuração de diagnóstico com a CLI do Azure. Consulte a documentação deste comando para obter descrições de seus parâmetros.

O exemplo a seguir cria uma configuração de diagnóstico que envia todas as categorias do Kubernetes para um workspace do Log Analytics. Isso inclui o modo específico do recurso para enviar os logs para tabelas específicas listadas em Logs de recursos com suporte para Microsoft.ContainerService/fleets.

az monitor diagnostic-settings create \
--name 'Collect control plane logs' \
--resource  /subscriptions/<subscription ID>/resourceGroups/<resource group name>/providers/Microsoft.ContainerService/managedClusters/<cluster-name> \
--workspace /subscriptions/<subscription ID>/resourcegroups/<resource group name>/providers/microsoft.operationalinsights/workspaces/<log analytics workspace name> \
--logs '[{"category": "karpenter-events","enabled": true},{"category": "kube-audit","enabled": true},
{"category": "kube-apiserver","enabled": true},{"category": "kube-audit-admin","enabled": true},{"category": "kube-controller-manager","enabled": true},{"category": "kube-scheduler","enabled": true},{"category": "cluster-autoscaler","enabled": true},{"category": "cloud-controller-manager","enabled": true},{"category": "guard","enabled": true},{"category": "csi-azuredisk-controller","enabled": true},{"category": "csi-azurefile-controller","enabled": true},{"category": "csi-snapshot-controller","enabled": true},{"category": "fleet-member-agent","enabled": true},{"category": "fleet-member-net-controller-manager","enabled": true},{"category": "fleet-mcs-controller-manager","enabled": true}]'
--metrics '[{"category": "AllMetrics","enabled": true}]' \
--export-to-resource-specific true

ARM

A seguir estão exemplos de modelo e arquivos de parâmetro para criar uma configuração de diagnóstico para logs de plano de controle. Modifique os modelos para coletar categorias diferentes ou para enviar os logs para um destino diferente.

Bíceps

param clusterName string
param workspaceId string
param settingName string

resource cluster 'Microsoft.ContainerService/managedClusters@2021-05-01-preview' existing = {
  name: clusterName
}

resource setting 'Microsoft.Insights/diagnosticSettings@2021-05-01-preview' = {
  name: settingName
  scope: cluster
  properties: {
    workspaceId: workspaceId
    logs: [
      {
        category: 'kube-apiserver'
        enabled: true
      }
      {
        category: 'kube-audit'
        enabled: true
      }
      {
        category: 'kube-audit-admin'
        enabled: true
      }
      {
        category: 'kube-controller-manager'
        enabled: true
      }
      {
        category: 'kube-scheduler'
              }
      {
        category: 'cluster-autoscaler'
        enabled: true
      }
      {
        category: 'guard'
        enabled: true
      }
    ]
  }
}

JSON

{
    "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
    "contentVersion": "1.0.0.0",
    "parameters": {
        "clusterName": {
            "type": "String"
        },
        "workspaceId": {
            "type": "String"
        },
        "settingName": {
            "type": "String"
        }
    },
    "resources": [
        {
            "type": "Microsoft.Insights/diagnosticSettings",
            "apiVersion": "2021-05-01-preview",
            "scope": "[format('Microsoft.ContainerService/managedClusters/{0}', parameters('clusterName'))]",
            "name": "[parameters('settingName')]",
            "properties": {
                "workspaceId": "[parameters('workspaceId')]",
                "logs": [
                    {
                        "category": "kube-apiserver",
                        "enabled": true
                    },
                    {
                        "category": "kube-audit",
                        "enabled": true
                    },
                    {
                        "category": "kube-audit-admin",
                        "enabled": true
                    },
                    {
                        "category": "kube-controller-manager",
                        "enabled": true
                    },
                    {
                        "category": "kube-scheduler",
                        "enabled": false
                    },
                    {
                        "category": "cluster-autoscaler",
                        "enabled": true
                    },
                    {
                        "category": "guard",
                        "enabled": true
                    }
                ]
            }
        }
    ]
}

Arquivo de parâmetros

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentParameters.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "settingName": {
        "value": "<cluster-name>"
    },
    "workspaceId": {
      "value": "/subscriptions/<subscription id>/resourcegroups/<resourcegroup name>/providers/microsoft.operationalinsights/workspaces/<workspace name>"
    },
    "scope": {
      "value": "Microsoft.<resource type>/<resourceName>"
    }
  }
}

Terraform

Use o modelo a seguir para criar uma configuração de diagnóstico para logs de painel de controle. Modifique o modelo para coletar categorias diferentes ou enviar os logs para um destino diferente.

  features {}
}

variable "setting_name" {
  type        = string
  description = "Name for the diagnostic setting."
}

variable "workspace_id" {
  type        = string
  description = "Resource ID of the Log Analytics workspace."
}

variable "cluster_id" {
  type        = string
  description = "Resource ID of the AKS cluster to attach diagnostics to."
}

resource "azurerm_monitor_diagnostic_setting" "aks" {
  name                       = var.setting_name
  target_resource_id         = var.cluster_id
  log_analytics_workspace_id = var.workspace_id

  log {
    category = "kube-apiserver"
    enabled  = true
  }

  log {
    category = "kube-audit"
    enabled  = true
  }

  log {
    category = "kube-audit-admin"
    enabled  = true
  }

  log {
    category = "kube-controller-manager"
    enabled  = true
  }

  log {
    category = "kube-scheduler"
    enabled  = false
  }

  log {
    category = "cluster-autoscaler"
    enabled  = true
  }

  log {
    category = "guard"
    enabled  = true
  }
}

Portal do Azure

Selecione as configurações de diagnóstico na seção Monitoramento do menu do cluster. Em seguida, selecione + Adicionar configuração de diagnóstico.

Selecione Enviar para o espaço de trabalho do Log Analytics e selecione o mesmo workspace para onde você envia seus logs de contêiner. Em seguida, selecione as diferentes Categorias que você deseja coletar. Dê ao nome da configuração de diagnóstico um nome descritivo, como Coletar Logs do Plano de Controle.

Verificar implantação

Em poucos minutos após habilitar o monitoramento, você deve ser capaz de usar os métodos a seguir para verificar se os recursos de monitoramento estão habilitados.

• O cluster deve passar da visualização de clusters não monitorados para a visualização de clusters monitorados na visualização em Modo de exibição de multicluster de insights de contêineres.
• A visualização Monitor do cluster deve começar a ser preenchida com dados e não fornecer mais a opção de habilitar o monitoramento. Isso inclui as guias Nós, Cargas de Trabalho e Contêineres.

Azure Policy

Consulte Criar configurações de diagnóstico em escala usando as Políticas internas do Azure para obter detalhes sobre como usar o Azure Policy para criar configurações de diagnóstico em escala.

Habilitar métricas do Windows (versão prévia)

A coleção de métricas do Windows está habilitada para clusters do AKS a partir da versão 6.4.0-main-02-22-2023-3ee44b9e do contêiner de complemento do Prometheus Gerenciado. A integração para o complemento de Métricas do Azure Monitor permite que os pods do Windows DaemonSet comecem a serem executados em seus pools de nós. Tanto o Windows Server 2019 quanto 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.

Observação

Não há limite de CPU/Memória em windows-exporter-daemonset.yaml, por isso pode haver sobreprovisionamento dos nós do Windows. Para obter detalhes , consulte Reserva de recursos

Ao implantar cargas de trabalho, defina limites de recursos de memória e CPU nos 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. O agendamento de pods sem limites pode provisionar excessivamente os nós do Windows e, em casos extremos, pode fazer com que os nós se tornem não íntegros.

Instalar o exportador do Windows

Instale manualmente o exportador de janelas em nós do AKS para acessar as métricas do Windows implantando o arquivo YAML windows-exporter-daemonset. Habilite os coletores a seguir. Para obter mais coletores, confira Exportador do Prometheus para métricas do Windows.

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

Implante o arquivo YAML windows-exporter-daemonset. Se houver algum taint aplicado ao nó, você precisará aplicar as tolerâncias apropriadas.

kubectl apply -f windows-exporter-daemonset.yaml

Habilitar métricas do Windows

Defina os booleanos windowsexporter e windowskubeproxy como true nas suas configurações de métricas no ConfigMap e aplique-o ao cluster. Confira Personalizar a coleta de métricas do Prometheus a partir do cluster do Kubernetes usando ConfigMap.

Habilitar regras de gravação

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

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

Verificar implantação

Utilize a ferramenta de linha de comando kubectl para verificar se o agente foi implantado corretamente.

Prometheus Gerenciado

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

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

O número de pods deve ser igual ao número de nós do Linux no cluster. A saída deve ser assemelhar ao exemplo a seguir:

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

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 assemelhar ao exemplo a seguir:

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 no Prometheus

kubectl get rs --namespace=kube-system

A saída deve ser assemelhar ao exemplo a seguir:

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

Registro de logs de contêiner

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

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

O número de pods deve ser igual ao número de nós do Linux no cluster. A saída deve ser assemelhar ao exemplo a seguir:

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 assemelhar ao exemplo a seguir:

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 de log de contêiner

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

A saída deve ser assemelhar ao exemplo a seguir:

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

Exibir configuração com a CLI

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

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

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

"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
    },
}

Próximas etapas

• Se você tiver problemas ao tentar executar a integração, consulte o Guia de solução de problemas.
• Saiba como analisar dados de monitoramento do Kubernetes nos insights de contêiner do portal do Azure.