Partilhar via


Habilitar o monitoramento para clusters Kubernetes

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

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

Importante

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

Clusters suportados

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

Pré-requisitos

Permissões

Pré-requisitos do Managed Prometheus

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

Pré-requisitos de clusters Kubernetes habilitados para Arc

Nota

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

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

Áreas de Trabalho

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

Caraterística Área de trabalho Notas
Prometheus Gerido Espaço de trabalho do Azure Monitor Contributor permissão é suficiente para habilitar o complemento para enviar dados para o espaço de trabalho do Azure Monitor. Você precisará de Owner permissão de nível para vincular seu Espaço de Trabalho do Azure Monitor para exibir métricas no Azure Managed Grafana. Isso é necessário porque o usuário que executa a etapa de integração precisa ser capaz de atribuir a função Identidade Monitoring Reader do Sistema Grafana Gerenciado do Azure no Espaço de Trabalho do Azure Monitor para consultar as métricas.
Informações de contentores Área de trabalho do Log Analytics Você pode anexar um cluster AKS a um espaço de trabalho do Log Analytics em uma assinatura diferente do Azure no mesmo locatário do Microsoft Entra, mas deve usar a CLI do Azure ou um modelo do Azure Resource Manager. No momento, não é possível executar essa configuração com o portal do Azure.

Se você estiver conectando um cluster AKS existente a um espaço de trabalho do Log Analytics em outra assinatura, o provedor de recursos Microsoft.ContainerService deverá estar registrado na assinatura com o espaço de trabalho do Log Analytics. Para obter mais informações, consulte Registar fornecedor de recursos.

Para obter uma lista dos pares de mapeamento suportados a serem usados para o espaço de trabalho padrão, consulte Mapeamentos de região suportados pelo Container insights.
Managed Grafana Espaço de trabalho do Azure Managed Grafana Vincule seu espaço de trabalho do Grafana ao espaço de trabalho do Azure Monitor para disponibilizar as métricas do Prometheus coletadas do cluster para os painéis do Grafana.

Ativar Prometheus e Grafana

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

Nota

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

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

Pré-requisitos

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

Cluster do AKS

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

Comandos de exemplo

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

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

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

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

Cluster habilitado para arco

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

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

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

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

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

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

Habilitar insights de contêiner

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

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

Pré-requisitos

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

Nota

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

Cluster do AKS

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

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

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

Exemplo

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

Cluster habilitado para arco

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

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

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

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

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

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

Exemplo

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

Cluster habilitado para arco com proxy de encaminhamento

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

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

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

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

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

Excluir instância de extensão

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

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

Habilite o monitoramento completo com o portal do Azure

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

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

Captura de ecrã do separador Monitorização para o novo cluster AKS.

Cluster existente (Prometheus, Container insights, e Grafana)

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

Cluster existente (apenas Prometheus)

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

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

Nota

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

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

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

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

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

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

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

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

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

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

Verificar a implementação

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

Prometheus Gerido

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

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

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

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 semelhante ao seguinte exemplo:

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

Verifique se os dois ReplicaSets foram implantados para o Prometheus

kubectl get rs --namespace=kube-system

A saída deve ser semelhante ao seguinte exemplo:

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

Informações de contentores

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

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

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

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

Verifique se os nós do Windows foram implantados corretamente

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

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

User@aksuser:~$ kubectl get ds ama-logs-windows --namespace=kube-system
NAME                   DESIRED   CURRENT   READY     UP-TO-DATE   AVAILABLE   NODE SELECTOR     AGE
ama-logs-windows           2         2         2         2            2       <none>            1d

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

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

A saída deve ser semelhante ao seguinte exemplo:

User@aksuser:~$ kubectl get deployment ama-logs-rs --namespace=kube-system
NAME          READY   UP-TO-DATE   AVAILABLE   AGE
ama-logs-rs   1/1     1            1           24d

Ver configuração com CLI

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

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

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

"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 são criados em sua assinatura:

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

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

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

Diferenças entre clusters Windows e Linux

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

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

Nota

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

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

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

Próximos passos

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