Habilitar monitoramento para clusters do Kubernetes

Artigo
03/11/2024

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

Prometheus gerenciado para coleta de métricas
Insights de contêineres 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 utilizando a CLI do Azure,o modelo do Azure Resource Manager, Terraform ou Azure Policy. 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 coleção de logs apenas aos dados necessários:

Configurar a coleta de dados e a otimização de custos em insights de contêiner usando a regra de coleta de dados
Detalhes sobre como personalizar a coleção de logs depois de habilitar o monitoramento, incluindo o uso de configurações de otimização de custo predefinidas.
Melhores práticas 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 coletados.

Clusters com suporte

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

Pré-requisitos

Permissões

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.

Pré-requisitos do Prometheus gerenciado

O cluster deve usar a autenticação de identidade gerenciada.
Os provedores de recursos a seguir devem ser registrados na assinatura do cluster do AKS e no espaço de trabalho do Azure Monitor:
- Microsoft.ContainerService
- Microsoft.insights
- Microsoft.AlertsManagement
- Microsoft.Monitor
Os seguintes provedores de recursos devem ser registrados na assinatura da assinatura do workspace do Grafana:
- Microsoft.Dashboard

Pré-requisitos dos clusters do Kubernetes habilitados para Arc

Pré-requisitos para extensões do cluster do Kubernetes habilitado para Azure Arc.
Verifique os requisitos de firewall, além dos requisitos de rede do Kubernetes habilitados para o Azure Arc.
Se você já instalou o monitoramento para AKS, verifique se desabilitou o monitoramento antes de continuar a fim de evitar problemas durante a instalação da extensão.
Se você já instalou o monitoramento em um cluster usando um script sem extensões de cluster, siga as instruções descritas em Desabilitar o monitoramento do seu cluster do Kubernetes para excluir este gráfico do Helm.

Observação

A extensão Kubernetes Habilitada para Arc do Prometheus Gerenciado não é compatível com as seguintes configurações:

Distribuições do Red Hat Openshift
Nós do Windows

Workspaces

A tabela a seguir descreve os workspaces necessários para suportar o Prometheus gerenciado e os Insights de contêiner. Você pode criar cada workspace como parte do processo de integração ou usar um workspace já existente. Confira Criar uma arquitetura de workspace do Log Analytics para obter diretrizes sobre quantos workspaces criar e onde posicioná-los.

Recurso	Workspace	Observações
Prometheus Gerenciado	Workspace do Azure Monitor	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.
Insights do contêiner	Espaço de Trabalho do Log Analytics	Você pode anexar um cluster do AKS a um workspace do Log Analytics em uma assinatura diferente do Azure no mesmo locatário do Microsoft Entra, mas precisa 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. Caso esteja conectando um cluster do AKS existente a um workspace do Log Analytics em outra assinatura, o provedor de recursos Microsoft.ContainerService deverá ser registrado na assinatura do workspace do Log Analytics. Para saber mais, confira Registrar provedores de recursos. 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.
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 Prometheus e Grafana

Use um dos métodos a seguir para habilitar a extração de métricas do Prometheus no seu cluster e ativar o Grafana gerenciado para visualizar as métricas. 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.

Se você não especificar um workspace do Azure Monitor já existente nos comandos a seguir, será usado o workspace padrão para o grupo de recursos. 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>.

Pré-requisitos

É necessária a versão 2.49.0 ou superior da CLI do Azure.
É necessário desinstalar a extensão aks-preview dos clusters do AKS usando o comando az extension remove --name aks-preview.
Instale a extensão k8s-extension com 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 opção -enable-azure-monitor-metrics, 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.

Comandos de exemplo

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

### Use existing Azure Monitor workspace
az aks create/update --enable-azure-monitor-metrics -n <cluster-name> -g <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 -n <cluster-name> -g <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 -n <cluster-name> -g <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 Arc

### 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 parâmetros opcionais a seguir:

AKS: --ksm-metric-annotations-allow-list
Arc: --AzureMonitorMetrics.KubeStateMetrics.MetricAnnotationsAllowList
Lista separada por vírgulas das 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 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],....
AKS: --ksm-metric-labels-allow-list
Arc: --AzureMonitorMetrics.KubeStateMetrics.MetricLabelsAllowlist
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,...],....
AKS: --enable-windows-recording-rules permite que você habilite os grupos de regras de gravação necessários para o funcionamento adequado dos painéis do Windows.

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

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.

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

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

Cluster do AKS – ARM
- Arquivo de modelo: https://aka.ms/azureprometheus-enable-arm-template
- Arquivo de parâmetro: https://aka.ms/azureprometheus-enable-arm-template-parameters
Cluster do AKS – Bicep
- 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
Cluster habilitado para Arc – ARM
- Arquivo de modelo: https://aka.ms/azureprometheus-arc-arm-template
- Arquivo de parâmetro: https://aka.ms/azureprometheus-arc-arm-template-parameters

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.

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.

ARM

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

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

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.

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 um recurso Grafana

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.

Se você estiver usando uma instância do Espaço Gerenciado do Azure para Grafana existente que já está vinculada a um espaço de trabalho do Azure Monitor, você precisa da lista de integrações do Grafana. Copie o valor do campo azureMonitorWorkspaceIntegrations. Se ela não existir, a instância não foi vinculada a nenhum espaço de trabalho do Azure Monitor. 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 os modelos

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

Baixe todos os arquivos em AddonTerraformTemplate.
Edite as variáveis no arquivo variables.tf com os valores de parâmetro corretos.
Execute terraform init -upgrade para inicializar a implantação do Terraform.
Execute terraform plan -out main.tfplan para inicializar a implantação do Terraform.
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 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 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.

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
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
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.
Selecione Atribuir e preencha os detalhes na guia Parâmetros. Selecione Examinar + criar.
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.

Habilitar os Insights do contêiner

Use um dos métodos a seguir para habilitar o Insights de contêiner. Depois de concluir, confira Configurar a coleta de dados do agente para obter Insights de contêiner para ajustar a configuração e assegurar que não esteja coletando mais dados do que o necessário.

Use um dos comandos a seguir para habilitar o monitoramento dos clusters habilitados para Arc e AKS. 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>.

Pré-requisitos

CLI do Azure versão 2.43.0 ou posterior
A autenticação de identidade gerenciada será padrão na versão 2.49.0 ou superior da CLI.
Extensão k8s do Azure versão 1.3.7 ou superior
A autenticação de identidade gerenciada é o padrão na versão de extensão1.43.0 ou superior da extensão k8s.
Não há suporte para autenticação de identidade gerenciada para clusters do Kubernetes habilitados para Arc com Azure Red Hat Openshift (ARO) ou nós do Windows. Use a autenticação herdada.
Para a CLI versão 2.54.0 ou superior, o esquema de registro em log será configurado para ContainerLogV2 usando o ConfigMap.

Cluster do AKS

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

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

Exemplo

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

Cluster habilitado para Arc

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

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

Exemplo

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 Arc 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 definição de configuração amalogs.ignoreExtensionProxySettings=true.

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 Arc com nós ARO, OpenShift ou Windows

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

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 do Log Analytics permanecem intactos.

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

Os modelos do 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

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

Cluster do AKS – 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
Cluster do AKS – Bicep
- Arquivo de modelo (Syslog): https://aka.ms/enable-monitoring-msi-syslog-bicep-template
- Arquivo de parâmetro (Sem 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
Cluster habilitado para Arc – ARM
- Arquivo de modelo: https://aka.ms/arc-k8s-azmon-extension-msi-arm-template
- Arquivo de parâmetro: 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

Parâmetro	Descrição
AKS: `aksResourceId` Arc: `clusterResourceId`	ID do recurso do cluster.
AKS: `aksResourceLocation` Arc: `clusterRegion`	Localização do cluster.
AKS: `workspaceResourceId` Arc: `workspaceResourceId`	A ID do recurso do workspace do Log Analytics.
Arc: `workspaceRegion`	A região do espaço de trabalho do Log Analytics.
Arc: `workspaceDomain`	O domínio do workspace do Log Analytics. `opinsights.azure.com` para nuvem pública Azure `opinsights.azure.us` para AzureUSGovernment.
AKS: `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.

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.

Novo cluster do AKS

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
Ajuste o recurso azurerm_kubernetes_cluster em main.tf de acordo com as configurações do cluster.

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

Execute terraform init -upgrade para inicializar a implantação do Terraform.
Execute terraform plan -out main.tfplan para inicializar a implantação do Terraform.
Execute terraform apply main.tfplan para aplicar o plano de execução à sua infraestrutura de nuvem.

Cluster do AKS existente

Primeiro, importe o recurso de cluster existente com o comando: terraform import azurerm_kubernetes_cluster.k8s <aksResourceId>

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
  }

Copie os recursos DCR e DCRA dos modelos do Terraform
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.
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/12345678-1234-9876-4563-123456789012/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

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.
Selecione a nova definição de política Complemento de Monitoramento do AKS.
Selecione Atribuir e especifique um Escopo de onde a política deve ser atribuída.
Selecione Avançar e forneça a ID do recurso do workspace do Log Analytics.
Crie uma tarefa de correção se desejar aplicar a política nos clusters do AKS existentes no escopo selecionado.
Selecione Revisar + criar para criar a atribuição de função.

CLI do Azure

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

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

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> --role Contributor --scope /subscriptions/<subscriptionId> -p "{ \"workspaceResourceId\": { \"value\":  \"/subscriptions/<subscriptionId>/resourcegroups/<resourceGroupName>/providers/microsoft.operationalinsights/workspaces/<workspaceName>\" } }"

Habilite o monitoramento completo pelo portal Azure

Com o portal Azure, é possível ativar o Prometheus gerenciado e os Insights de contêiner simultaneamente.

Observação

Se quiser habilitar o Prometheus Gerenciado sem os Insights de contêiner, habilite-o a partir do workspace do Azure Monitor, conforme descrito abaixo.

Novo cluster do AKS (Prometheus e Insights de contêiner)

Ao criar um novo cluster do AKS no portal do Azure, você pode habilitar o Prometheus, o Insights de Contêiner e o Grafana na guia Integrações. Na seção do Azure Monitor, selecione a Configuração padrão, ou a Configuração personalizada se você quiser especificar quais workspaces serão usados. Você pode executar uma configuração adicional após o cluster ser criado.

Cluster existente (Prometheus e Insights de contêiner)

Esta opção habilita os Insights de contêiner e, opcionalmente, o Prometheus e o Grafana em um cluster do AKS já existente.

Selecione Insights no menu do cluster OU Contêineres no menu Monitor, na aba Clusters não monitorados, e clique em Habilitar ao lado do cluster.
1. Se o recurso Insights de Contêiner não estiver habilitado para o cluster, você verá uma tela identificando quais dos recursos foram habilitados. Clique em Configurar monitoramento.
1. Se o recurso Insights de Contêiner já tiver sido habilitado no cluster, selecione o botão Definições de Monitoramento para modificar a configuração.
O recurso Insights de Contêiner será habilitado. Selecione as caixas de seleção para Habilitar as métricas do Prometheus e Habilitar o Grafana, se você também quiser habilitá-los para o cluster. Se você tiver um workspace do Azure Monitor e um workspace do Grafana existentes, estes serão selecionados para você.
Clique em Configurações avançadas para selecionar workspaces alternativos ou criar novos. A configuração Predefinições de custos permite que você modifique os detalhes da coleta padrão para reduzir seus custos de monitoramento. Confira Habilitar configurações de otimização de custos no Insights de Contêiner para obter mais detalhes.
Clique em Configurar para modificar a configuração.

Cluster existente (somente Prometheus)

Essa opção habilita as métricas do Prometheus em um cluster sem habilitar insights de contêiner.

Abra o menu espaços de trabalho do Azure Monitor no portal do Azure e selecione seu espaço de trabalho.
Selecione Clusters monitorados na seção Prometheus Gerenciado para exibir uma lista de clusters do AKS.
Selecione Configurar ao lado do cluster que você deseja habilitar.

Cluster existente (Adicionar Prometheus)

Selecione Contêineres no menu Monitor, na aba Clusters monitorados, e clique em Configurar ao lado de um cluster na coluna Prometheus gerenciado.

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

Observação

Não há limite de CPU/memória no windows-exporter-daemonset.yaml, portanto, ele pode provisionar em excesso os nós do Windows
Para obter mais detalhes, confira 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.

A partir da versão 6.4.0-main-02-22-2023-3ee44b9e do contêiner de complemento do Prometheus Gerenciado (prometheus_collector), a coleção de métricas do Windows foi habilitada para os clusters do AKS. 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.

Instalar manualmente o exportador do Windows nos nós AKS para acessar as métricas do Windows. Habilite os seguintes coletores:
- [defaults]
- container
- memory
- process
- cpu_info
Para obter mais coletores, confira Exportador do Prometheus para métricas do Windows.

Implantar o arquivo windows-exporter-daemonset YAML:
```
    kubectl apply -f windows-exporter-daemonset.yaml
```
Aplicar ama-metrics-settings-configmap ao seu cluster. Defina os valores boolianos windowsexporter e windowskubeproxy para true. Para obter mais informações, consulte Configurações do complemento de Métricas configmap.
Habilite as regras de gravação necessárias para os painéis prontos para uso:
- Se estiver integrando 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.

Verificar a 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

Insights do 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

Verifique a implantação da solução Insights 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 -g <resourceGroupofAKSCluster> -n <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/00000000-0000-0000-0000-000000000000/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 do Azure são criados em sua assinatura:

Nome do Recurso	Tipo de recurso	Grupo de recursos	Região/Localização	Descrição
`MSCI-<aksclusterregion>-<clustername>`	Regra de Coleta de Dados	Igual ao cluster	Igual ao workspace do Log Analytics	Esta regra de coleta de dados destina-se à coleta de logs pelo agente do Azure Monitor, que utiliza o workspace do Log Analytics como destino e está associada ao recurso de cluster do AKS.
`MSPROM-<aksclusterregion>-<clustername>`	Regra de Coleta de Dados	Igual ao cluster	Igual ao workspace do Azure Monitor.	Essa regra de coleta de dados destina-se à coleta de métricas do Prometheus por complemento de métricas, que o workspace do Azure Monitor escolheu como destino e também está associada ao recurso de cluster do AKS
`MSPROM-<aksclusterregion>-<clustername>`	Ponto de extremidade da Coleta de Dados	Igual ao cluster	Igual ao workspace do Azure Monitor.	Esse ponto de extremidade da coleta de dados é usado pela regra de coleta de dados acima para ingerir métricas do Prometheus do complemento de métricas

Quando você cria um novo workspace do Azure Monitor, os recursos adicionais a seguir são criados como parte dele

Nome do Recurso	Tipo de recurso	Grupo de recursos	Região/Localização	Descrição
`<azuremonitor-workspace-name>`	Regra de Coleta de Dados	MA_<azuremonitor-workspace-name>_<azuremonitor-workspace-region>_managed	Igual ao workspace do Azure Monitor	DCR criada quando você usa o servidor Prometheus OSS para Gravação Remota no Workspace do Azure Monitor.
`<azuremonitor-workspace-name>`	Ponto de extremidade da coleta de dados	MA_<azuremonitor-workspace-name>_<azuremonitor-workspace-region>_managed	Igual ao workspace do Azure Monitor	DCE criado quando você usa o servidor Prometheus OSS para Gravação Remota no Workspace do Azure Monitor.

Diferenças entre clusters do Windows e do Linux

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

O Windows não tem uma métrica de RSS de Memória. Como resultado, ela 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 do disco não estão disponíveis para nós do Windows.
Somente ambientes de pod são monitorados, não ambientes do Docker.
Com a versão prévia, há suporte para até 30 contêineres do Windows Server. Essa limitação não se aplica a contêineres do Linux.

Observação

O suporte aos insights do Contêiner para o sistema operacional Windows Server 2022 está em versão prévia.

O agente do Linux em contêineres (pod replicaset) faz chamadas à API para todos os nós do Windows na porta segura do Kubelet (10250) no 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 entrada e saída de modo que a coleta de métricas relacionadas desempenho do contêiner e do nó do Windows funcione.

Se tiver um cluster do Kubernetes com nós do Windows, revise e configure o grupo de segurança de rede e as políticas de rede para verificar se a porta segura do Kubelet (:10250) está aberta tanto para entrada quanto para saída na rede virtual do cluster.

Próximas etapas

Se enfrentar problemas ao tentar integrar a solução, examine o Guia de solução de problemas.
Com o monitoramento habilitado para coletar a integridade e a utilização de recursos do seu cluster AKS e cargas de trabalho em execução neles, saiba como usar insights do Contêiner.

Habilitar monitoramento para clusters do Kubernetes

Clusters com suporte

Pré-requisitos

Workspaces

Habilitar Prometheus e Grafana

Pré-requisitos

Cluster do AKS

Cluster habilitado para Arc

Habilitar os Insights do contêiner

Pré-requisitos

Cluster do AKS

Cluster habilitado para Arc

Habilite o monitoramento completo pelo portal Azure

Novo cluster do AKS (Prometheus e Insights de contêiner)

Cluster existente (Prometheus e Insights de contêiner)

Cluster existente (somente Prometheus)

Cluster existente (Adicionar Prometheus)

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

Verificar a implantação

Prometheus Gerenciado

Insights do contêiner

Recursos provisionados

Diferenças entre clusters do Windows e do Linux

Próximas etapas

Recursos adicionais