Monitorizar o Azure Kubernetes Service (AKS)

Aplica-se a: ✔️ AKS Automatic ✔️ AKS Standard

A monitorização AKS requer múltiplos níveis de observabilidade em métricas de plataforma, métricas Prometheus, registos de atividade, registos de recursos e informações sobre contentores. O AKS oferece capacidades de monitorização integradas e integra-se com o Azure Monitor, Container Insights, serviço gerido para Prometheus e Azure Managed Grafana para monitorização abrangente da saúde e desempenho do cluster.

Resposta rápida: Como posso ativar a monitorização no AKS? Para os clusters automáticos do AKS, a monitorização está ativada por predefinição, com Prometheus gerido, Container insights e dashboards do Azure Monitor pré-configurados. Para os clusters AKS Standard, tem de ativar manualmente a monitorização no separador Integrações do portal do Azure ou com a CLI do Azure.

Para a maioria das cargas de trabalho de produção, o AKS Automatic é a opção predefinida pronta para produção recomendada para o AKS. Os clusters automáticos do AKS incluem uma base de monitorização pré-configurada com o serviço gerido do Prometheus para recolha de métricas, o Container Insights para recolha de registos e painéis do Azure Monitor com Grafana para visualização no portal do Azure. No AKS Standard, pode ativar e configurar as mesmas capacidades de monitorização com base nas suas necessidades.

Sugestão

Pode usar o Azure Copilot para configurar a monitorização nos seus clusters AKS no portal Azure. Para mais informações, consulte Trabalhar com clusters AKS de forma eficiente usando o Azure Copilot.

Análises

Alguns serviços no Azure têm um painel de monitoramento interno no portal do Azure que fornece um ponto de partida para monitorar seu serviço. Esses painéis são chamados de insights, e você pode encontrá-los no Hub de Insights do Azure Monitor no portal do Azure.

Predefinições de monitorização automática do AKS

O AKS Automatic oferece uma experiência padrão pronta para produção para a maioria das cargas de trabalho do AKS. Como parte dessa experiência, AKS Automatic configura uma base de monitorização predefinida para si.

Capacidade de monitorização AKS Automático Padrão AKS
Serviço gerenciado para Prometheus Predefinição Opcional
Informações detalhadas sobre contentores Predefinição Opcional
Azure Monitor dashboards com Grafana Predefinição no portal do Azure Predefinição no portal do Azure
Azure Managed Grafana Opcional Opcional

Utilize o AKS Automatic quando quiser a experiência AKS recomendada e pronta para produção, com as predefinições de monitorização já configuradas. Usa o AKS Standard quando quiseres escolher e configurar componentes de monitorização individualmente.

Para mais informações sobre os padrões automáticos do AKS, veja O que é o Azure Kubernetes Service (AKS) Automatic?

Dados de monitorização do AKS: métricas, registos, integrações

O AKS gera os mesmos tipos de dados de monitoramento que outros recursos do Azure, conforme descrito em Monitorar dados de recursos do Azure. Para obter informações detalhadas sobre as métricas e logs criados pelo AKS, consulte a referência de dados de monitoramento do AKS.

No AKS Automatic, a pilha de monitorização padrão recomendada já está configurada para si. No AKS Standard, pode configurar a mesma pilha de monitorização ao ativar os serviços e integrações de monitorização relevantes.

Outros serviços e recursos do Azure coletam outros dados e habilitam outras opções de análise, conforme mostrado no diagrama e na tabela a seguir.

Diagrama de dados de monitorização que são recolhidos a partir de AKS.

Origem Descrição
Métricas de plataforma As métricas da plataforma são coletadas automaticamente para clusters AKS sem nenhum custo. Pode analisar estas métricas usando o explorador de métricas ou usá-las para criar alertas de métricas.
Métricas Prometheus Quando você habilita a raspagem de métricas para seu cluster, o serviço gerenciado do Prometheus no Azure Monitor coleta métricas do Prometheus e as armazena em um espaço de trabalho do Azure Monitor. Analise estas métricas usando dashboards pré-construídos no Azure Managed Grafana e com alertas Prometheus.
Registos de atividade O log de atividades do Azure Monitor coleta automaticamente alguns dados para clusters AKS sem nenhum custo. Esses arquivos de log rastreiam informações como quando um cluster é criado ou alterações são feitas em uma configuração de cluster. Para analisar os dados do registo de atividade com os seus outros dados, envie os dados do registo de atividade para um espaço de trabalho de Análise de Registos.
Registos de recursos Os registos do plano de controlo do AKS são implementados como registos de recursos. Crie uma definição de diagnóstico para enviar os registos para um espaço de trabalho de Análise de Logs. No espaço de trabalho, pode analisar os registos através de consultas e configurar alertas com base na informação dos registos.
Informações detalhadas sobre contentores O Container Insights recolhe vários logs e dados de desempenho de um cluster e armazena-os num espaço de trabalho Log Analytics e em métricas Azure Monitor. Analisa dados como stdout e stderr fluxos usando vistas e workbooks no Container Insights ou Log Analytics e no explorador de métricas.
Application Insights O Application Insights, um recurso do Azure Monitor, coleta logs, métricas e rastreamentos distribuídos. A telemetria é armazenada em um espaço de trabalho do Log Analytics para análise no portal do Azure. Para habilitar o Application Insights com alterações de código, consulte Habilitar o Azure Monitor OpenTelemetry. Para habilitar o Application Insights sem alterações ao código, consulte a autoinstrumentação do AKS. Para obter mais informações sobre instrumentação, saiba mais sobre as noções básicas de coleta de dados.

Tipos de recursos

O Azure usa o conceito de tipos de recursos e IDs para identificar tudo em uma assinatura. Os tipos de recursos também fazem parte das IDs de recursos para cada recurso em execução no Azure. Por exemplo, um tipo de recurso para uma máquina virtual é Microsoft.Compute/virtualMachines. Para obter uma lista de serviços e seus tipos de recursos associados, consulte Provedores de recursos.

O Azure Monitor organiza, de modo semelhante, os principais dados de monitorização em métricas e registos com base nos tipos de recurso, também designados por namespaces. Diferentes métricas e logs estão disponíveis para diferentes tipos de recursos. Seu serviço pode estar associado a mais de um tipo de recurso.

Para obter mais informações sobre os tipos de recursos no AKS, consulte a referência de dados de monitoramento do AKS.

Armazenamento de dados

Para o Azure Monitor:

  • Os dados de métricas são armazenados no banco de dados de métricas do Azure Monitor.
  • Os dados de log são armazenados no repositório de logs do Azure Monitor. O Log Analytics é uma ferramenta no portal do Azure que permite consultar este repositório.
  • O log de atividades do Azure é um repositório separado com sua própria interface no portal do Azure.

Opcionalmente, você pode rotear dados de métricas e logs de atividades para o repositório de logs do Azure Monitor. Em seguida, você pode usar o Log Analytics para consultar os dados e correlacioná-los com outros dados de log.

Muitos serviços podem usar configurações de diagnóstico para enviar dados de métrica e log para outros locais de armazenamento fora do Azure Monitor. Os exemplos incluem o Armazenamento do Azure, sistemas de parceiros hospedados e sistemas de parceiros que não são do Azure, usando Hubs de Eventos.

Para obter informações detalhadas sobre como o Azure Monitor armazena dados, consulte Plataforma de dados do Azure Monitor.

Métricas da plataforma Azure Monitor

O Azure Monitor fornece métricas de plataforma para a maioria dos serviços. Essas métricas são:

  • Definido individualmente para cada namespace.
  • Armazenado no banco de dados de métricas de séries cronológicas do Azure Monitor.
  • Leve e capaz de suportar alertas quase em tempo real.
  • Usado para acompanhar o desempenho de um recurso ao longo do tempo.

Coleção: o Azure Monitor coleta métricas da plataforma automaticamente. Não é necessária qualquer configuração.

Roteamento: você também pode rotear algumas métricas da plataforma para o Azure Monitor Logs / Log Analytics para poder consultá-las com outros dados de log. Verifique a definição DS export de cada métrica para verificar se é possível usar definições de diagnóstico para encaminhar a métrica para o Azure Monitor Logs / Log Analytics.

Para obter uma lista de todas as métricas que é possível reunir para todos os recursos no Azure Monitor, consulte Métricas suportadas no Azure Monitor.

Para obter uma lista de métricas que você pode coletar para o AKS, consulte a referência de dados de monitoramento do AKS.

As métricas desempenham um papel importante no monitoramento de clusters, na identificação de problemas e na otimização do desempenho em clusters AKS. O AKS cria métricas de plataforma que o Azure Monitor recolhe automaticamente, sem configuração. Você também deve habilitar o serviço gerenciado para métricas do Prometheus para coletar métricas de contêiner e métricas de objeto do Kubernetes, incluindo o estado de implantação do objeto.

No AKS Automatic, o serviço gerido para o Prometheus está ativado por defeito, por isso começa com uma linha base de métricas pronta para produção sem configuração adicional.

Você pode exibir a lista de serviços gerenciados padrão para métricas do Prometheus.

Para obter mais informações, consulte Coletar métricas de serviço gerenciado para Prometheus de um cluster AKS.

Métricas não baseadas no Azure Monitor

Este serviço fornece outras métricas que não estão incluídas no banco de dados de métricas do Azure Monitor.

Você pode usar os seguintes serviços do Azure e recursos do Azure Monitor para monitorar seus clusters AKS. No AKS Automatic, a configuração base de monitorização predefinida já inclui o serviço gerido do Prometheus, o Container Insights e os dashboards do Azure Monitor com Grafana. No AKS Standard, pode ativar estas funcionalidades ao criar um cluster ou ao integrar o cluster mais tarde.

No portal do Azure, use o separador Integrações ou utilize a CLI do Azure, Terraform ou a Política do Azure. Em alguns casos, você pode integrar seu cluster a um serviço ou recurso de monitoramento depois de criar o cluster. Cada serviço ou recurso pode incorrer em custos, portanto, consulte as informações de preços de cada componente antes de ativá-lo.

Serviço ou funcionalidade Descrição
Informações sobre contêineres Usa uma versão conteinerizada do Azure Monitor Agent para coletar stdout e stderr registos e eventos do Kubernetes de cada nó no teu cluster. O recurso suporta uma variedade de cenários de monitoramento para clusters AKS. Podes ativar a monitorização de um cluster AKS quando este for criado usando o CLI do Azure, Azure Policy, o portal Azure ou o Terraform. Se você não habilitar Insights de contêiner ao criar seu cluster, consulte Habilitar insights de contêiner para cluster AKS para outras opções para habilitá-lo.

O Container insights armazena a maioria de seus dados em um espaço de trabalho do Log Analytics. Normalmente, você usa o mesmo espaço de trabalho do Log Analytics que os logs de recursos do cluster. Para obter orientação sobre quantos espaços de trabalho você deve usar e onde localizá-los, consulte Criar uma arquitetura de espaço de trabalho do Log Analytics.
Serviço gerenciado para Prometheus no Azure Monitor O Prometheus é uma solução de métricas nativa da nuvem da Cloud Native Computing Foundation. É a ferramenta mais comum a ser usada para coletar e analisar dados métricos de clusters do Kubernetes. O serviço gerenciado do Prometheus no Azure Monitor é uma solução de monitoramento totalmente gerenciada compatível com Prometheus. Se você não habilitar o serviço gerenciado para Prometheus ao criar seu cluster, consulte Coletar métricas do Prometheus de um cluster AKS para obter outras opções para habilitá-lo.

O serviço gerenciado do Prometheus no Azure Monitor armazena seus dados em um espaço de trabalho do Azure Monitorvinculado a um espaço de trabalho do Grafana. Você pode usar o Azure Managed Grafana para analisar os dados.
Azure Managed Grafana Uma implementação totalmente gerida do Grafana. Grafana é uma plataforma de visualização de dados de código aberto comumente usada para apresentar dados do Prometheus. Estão disponíveis vários painéis predefinidos do Grafana para monitorizar o Kubernetes e diagnosticar problemas de toda a pilha. Se você não habilitar o Azure Managed Grafana ao criar seu cluster, consulte Vincular um espaço de trabalho do Grafana. Você pode vinculá-lo ao seu espaço de trabalho do Azure Monitor para que ele possa acessar as métricas do Prometheus do seu cluster.

Monitoramento das métricas do plano de controlo do AKS (versão prévia)

Pré-requisitos e âmbito: Esta funcionalidade de pré-visualização requer um cluster AKS que utilize autenticação de identidade gerida e tenha o serviço gerido do Prometheus ativado. Deve também registar o AzureMonitorMetricsControlPlanePreview sinalizador de funcionalidade. O Azure Private Link não é suportado, e só podes personalizar o ficheiro de configmap predefinidoama-metrics-settings-configmap.yaml.

O AKS também expõe métricas de componentes críticos do plano de controle, como o servidor de API, etcd, e o agendador por meio do serviço gerenciado para Prometheus no Azure Monitor. Atualmente, este recurso está em pré-visualização. Para obter mais informações, consulte Monitorar métricas do plano de controle AKS. Um subconjunto de métricas de plano de controle para o servidor de API e etcd está disponível gratuitamente por meio das métricas da plataforma Azure Monitor. Essas métricas são coletadas por padrão. Você pode usar as métricas para criar alertas.

Registos de recursos do Azure Monitor

Os logs de recursos fornecem informações sobre operações que foram feitas por um recurso do Azure. Os logs são gerados automaticamente, mas você deve roteá-los para os logs do Azure Monitor para salvá-los ou consultá-los. Os logs são organizados em categorias. Um determinado namespace pode ter várias categorias de log de recursos.

Coleção: Os registos de recursos não são recolhidos nem armazenados até criar uma definição de diagnóstico e encaminhar os registos para um ou mais destinos. Ao criar uma definição de diagnóstico, especifica as categorias de registos que devem ser recolhidas. Há várias maneiras de criar e manter configurações de diagnóstico, incluindo o portal do Azure, programaticamente e por meio da Política do Azure.

Roteamento: o padrão sugerido é rotear logs de recursos para Logs do Azure Monitor para que você possa consultá-los com outros dados de log. Outros locais, como o Armazenamento do Azure, Hubs de Eventos do Azure e determinados parceiros de monitoramento da Microsoft também estão disponíveis. Para obter mais informações, consulte registos de recursos do Azure e destinos de registo de recursos.

Para obter informações detalhadas sobre como coletar, armazenar e rotear logs de recursos, consulte Configurações de diagnóstico no Azure Monitor.

Para obter uma lista de todas as categorias de log de recursos disponíveis no Azure Monitor, consulte Logs de recursos com suporte no Azure Monitor.

Todos os logs de recursos no Azure Monitor têm os mesmos campos de cabeçalho, seguidos por campos específicos do serviço. O esquema comum encontra-se descrito em esquema de registos de recursos do Azure Monitor.

Para consultar as categorias de log de recursos disponíveis, as suas tabelas de Log Analytics associadas e os esquemas de log para AKS, consulte a referência de dados de monitorização do AKS.

Logs de recursos do plano de controle AKS

Pré-requisitos: Exige um espaço de trabalho de Log Analytics. O espaço de trabalho pode estar numa subscrição diferente se a pessoa que configura a definição de diagnóstico tiver acesso apropriado ao controlo de acesso baseado em funções (RBAC) do Azure para ambas as subscrições. Para um espaço de trabalho noutro inquilino do Microsoft Entra, use o Azure Lighthouse. Os registos de recursos geram custos de ingestão e retenção no espaço de trabalho de destino. Para otimização de custos, utilize o modo específico por recurso e configure o nível de registos básicos para tabelas de auditoria. Para mais informações, consulte Destinos das definições de diagnóstico.

Os logs de plano de controle para clusters AKS são implementados como logs de recursos no Azure Monitor. Os logs de recursos não são coletados e armazenados até que você crie uma configuração de diagnóstico para roteá-los para pelo menos um local. Normalmente, você envia logs de recursos para um espaço de trabalho do Log Analytics, onde a maioria dos dados para informações de contêiner é armazenada.

Para aprender a criar uma definição de diagnóstico usando o portal Azure, a CLI do Azure ou o Azure PowerShell, consulte Criar definições de diagnóstico. Ao criar uma definição de diagnóstico, especifica as categorias de registos que devem ser recolhidas. As categorias para AKS estão listadas na referência de dados de monitoramento AKS.

Advertência

Você pode incorrer em custos consideráveis ao coletar logs de recursos para o AKS, particularmente para logs kube-audit. Considere as seguintes recomendações para reduzir a quantidade de dados coletados:

  • Desative o kube-audit registro quando não for necessário.
  • Habilite a coleta de kube-audit-admin, que exclui os eventos de auditoria get e list.
  • Ative registos específicos de recursos conforme descrito neste artigo e configure a tabela AKSAudit como registos básicos.

Para mais recomendações de monitorização, consulte Monitorar clusters AKS usando serviços Azure e ferramentas cloud-native. Para obter estratégias para reduzir seus custos de monitoramento, consulte Otimização de custos e Azure Monitor.

O AKS suporta o modo de diagnóstico do Azure ou o modo específico de recursos para registos de recursos. O modo de diagnóstico do Azure envia todos os dados para a tabela AzureDiagnostics. O modo específico do recurso especifica as tabelas no espaço de trabalho do Log Analytics para onde os dados são enviados. Ele também envia dados para AKSAudit, AKSAuditAdmine AKSControlPlane conforme mostrado na tabela em Logs de recursos.

Recomendamos que você use o modo específico de recursos para o AKS pelos seguintes motivos:

  • Os dados são mais fáceis de consultar porque estão em tabelas individuais dedicadas ao AKS.
  • O modo específico para recursos suporta a configuração como logs básicos para significativas poupanças de custos.

Para obter mais informações sobre a diferença entre os modos de coleta, incluindo como alterar uma configuração existente, consulte Selecionar o modo de coleta.

Nota

Pode configurar as definições de diagnóstico usando a CLI do Azure. Não é garantido que essa abordagem seja bem-sucedida porque não verifica o estado de provisionamento do cluster. Depois de alterar as configurações de diagnóstico, verifique se o cluster reflete as alterações de configuração.

az monitor diagnostic-settings create --name AKS-Diagnostics --resource /subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/myresourcegroup/providers/Microsoft.ContainerService/managedClusters/my-cluster --logs '[{"category": "kube-audit","enabled": true}, {"category": "kube-audit-admin", "enabled": true}, {"category": "kube-apiserver", "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}]'  --workspace /subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourcegroups/myresourcegroup/providers/microsoft.operationalinsights/workspaces/myworkspace --export-to-resource-specific true

Consultas e exemplos de registos de recursos do AKS

Requisitos do âmbito da consulta: Quando seleciona Logs num menu de cluster AKS, o Log Analytics abre com o âmbito da consulta definido para o cluster atual. As consultas de log incluem dados somente desse recurso. Para executar consultas que incluam dados de outros clusters ou serviços Azure, selecione Logs no menu Azure Monitor .

Se as definições de diagnóstico do seu cluster usarem o modo de diagnóstico Azure, os registos de recursos do AKS são armazenados na tabela AzureDiagnostics . Identifique os logs por meio da coluna Categoria . Para obter uma descrição de cada categoria, consulte Logs de recursos de referência do AKS.

Descrição Mode Consulta de log
Registos de contagem para cada categoria Azure modo de diagnóstico AzureDiagnostics
| where ResourceType == "MANAGEDCLUSTERS"
| summarize count() by Category
Todos os logs do servidor de API Azure modo de diagnóstico AzureDiagnostics
| where Category == "kube-apiserver"
Todos os registos do kube-audit num determinado intervalo de tempo Azure modo de diagnóstico let starttime = datetime("2023-02-23");
let endtime = datetime("2023-02-24");
AzureDiagnostics
| where TimeGenerated between(starttime..endtime)
| where Category == "kube-audit"
| extend event = parse_json(log_s)
| extend HttpMethod = tostring(event.verb)
| extend User = tostring(event.user.username)
| extend Apiserver = pod_s
| extend SourceIP = tostring(event.sourceIPs[0])
| project TimeGenerated, Category, HttpMethod, User, Apiserver, SourceIP, OperationName, event
Todos os logs de auditoria Modo específico de recurso AKSAudit
Todos os registos de auditoria, excluindo os eventos de auditoria get e list Modo específico de recurso AKSAuditAdmin
Todos os logs do servidor de API Modo específico de recurso AKSControlPlane
| where Category == "kube-apiserver"

Para acessar um conjunto de consultas pré-criadas no espaço de trabalho do Log Analytics, consulte a interface de consultas do Log Analytics e selecione o tipo de recurso Serviços Kubernetes . Para ver uma lista de consultas comuns do Container Insights, consulte Consultas do Container Insights.

Política de auditoria da AKS

O AKS utiliza uma política de auditoria Kubernetes para controlar que eventos são registados e que dados contêm. A política define regras que determinam o nível de auditoria para diferentes tipos de pedidos de API com base em utilizadores, recursos, espaços de nomes e verbos. São utilizados os seguintes níveis de auditoria:

  • Nenhum: Eventos que cumpram esta regra não são registados.
  • Metadados: Metadados do pedido de registo (utilizador solicitante, carimbo temporal, recurso, verbo), mas não corpo de pedido ou resposta.
  • Pedido: Registar metadados do evento e corpo do pedido, mas não o corpo da resposta.
  • RequestResponse: Registar metadados de eventos, corpos de pedido e resposta.

A tabela seguinte resume as principais regras de política de auditoria aplicadas no AKS:

Nível de auditoria Descrição Exemplos de eventos
Nenhum Operações de leitura de alto volume e baixo risco aksServiceOperações do utilizadorget/list, kube-proxy monitorar endpoints/serviços, kubelet get nos nós/estado dos nós, URLs de verificação de saúde (/healthz*, /version, /swagger*)
Metadados Eventos do sistema, recursos de eventos (exceto criações/atualizações em default/kube-system), segredos, mapas de configuração, contas de serviço, revisões de tokens Revisões de tokens, acesso a segredos/configmaps, CRDs grandes como installations.operator.tigera.io
Pedido Atualizações de estado de nós e pods a partir de kubelets/nós, operações de eliminação em massa, atualizações de CRD para instantâneos de volume, operações de leitura (get/list/watch) em grupos de API principais, alterações no VPA. Atualizações de estado do Kubelet, eliminações de namespace, atualizações de pontos de controlo VPA
RequestResponse Atualizações do configmap personalizado do CoreDNS, operações da API do Fleet, alterações de recursos do Karpenter, todas as outras operações de escrita nos grupos principais da API Alterações na configuração do CoreDNS, operações do cluster dos membros da frota, alterações no pool de nós Karpenter

A política completa de auditoria utilizada no AKS está disponível para revisão na seguinte secção dobrável.

Consulte a política completa de auditoria do AKS 
apiVersion: audit.k8s.io/v1
kind: Policy
rules:
  # audit level 'None' for high volume and low risk events
  - level: None
    users: ["aksService"]
    verbs: ["get", "list"]
  # audit level 'None' for low-risk requests
  - level: None
    users: ["system:kube-proxy"]
    verbs: ["watch"]
    resources:
      - group: ""
        resources: ["endpoints", "services", "services/status"]
  # audit level 'None' for low-risk requests
  - level: None
    users: ["kubelet"] # legacy kubelet identity
    verbs: ["get"]
    resources:
      - group: ""
        resources: ["nodes", "nodes/status"]
  # audit level 'None' for low-risk requests
  - level: None
    userGroups: ["system:nodes"]
    verbs: ["get"]
    resources:
      - group: ""
        resources: ["nodes", "nodes/status"]
  # audit level 'None' for low-risk requests
  - level: None
    users:
      - aksService # the default user/cert used by aks in master node
      - system:serviceaccount:kube-system:endpoint-controller
    verbs: ["get", "update"]
    namespaces: ["kube-system"]
    resources:
      - group: ""
        resources: ["endpoints"]
  # audit level 'None' for low-risk requests
  - level: None
    users: ["system:apiserver"]
    verbs: ["get"]
    resources:
      - group: ""
        resources: ["namespaces", "namespaces/status", "namespaces/finalize"]
  # audit level 'None' for low-risk requests
  - level: None
    users:
      - aksService # the default user/cert used by aks in master node
    verbs: ["get", "list"]
    resources:
      - group: "metrics.k8s.io"
  # Don't log these read-only URLs.
  - level: None
    nonResourceURLs:
      - /healthz*
      - /version
      - /swagger*
  # monitor metadata for system events which are being logged by eventlogger component
  - level: Metadata
    verbs: ["create", "update", "patch"]
    resources:
      - group: ""
        resources: ["events"]
      - group: "events.k8s.io"
        resources: ["events"]
    namespaces: ["default", "kube-system"]
  # Monitoring of actions to detect security/performance relevant activities.
  - level: Metadata
    verbs: ["delete", "list"]
    resources:
      - group: ""
        resources: ["events"]
      - group: "events.k8s.io"
        resources: ["events"]
  # Don't log other events requests.
  - level: None
    resources:
      - group: ""
        resources: ["events"]
      - group: "events.k8s.io"
        resources: ["events"]
  # node and pod status calls from nodes are high-volume and can be large, don't log responses for expected updates from nodes
  - level: Request
    users: ["client", "kubelet", "system:node-problem-detector", "system:serviceaccount:kube-system:node-problem-detector", "system:serviceaccount:kube-system:aci-connector-linux"]
    verbs: ["update","patch"]
    resources:
      - group: ""
        resources: ["nodes/status", "pods/status"]
    omitStages:
      - "RequestReceived"
  # node and pod status calls from nodes are high-volume and can be large, don't log responses for expected updates from nodes
  - level: Request
    userGroups: ["system:nodes"]
    verbs: ["update","patch"]
    resources:
      - group: ""
        resources: ["nodes/status", "pods/status"]
    omitStages:
      - "RequestReceived"
  # deletecollection calls can be large, don't log responses for expected namespace deletions
  - level: Request
    users: ["system:serviceaccount:kube-system:namespace-controller"]
    verbs: ["deletecollection"]
    omitStages:
      - "RequestReceived"
  # ignore response object that has big size
  - level: Request
    verbs: ["update","patch"]
    resources:
      - group: "apiextensions.k8s.io"
        resources: ["customresourcedefinitions"]
        resourceNames: ["volumesnapshotcontents.snapshot.storage.k8s.io", "volumesnapshots.snapshot.storage.k8s.io"]
    omitStages:
      - "RequestReceived"
  # ignore request and response objects for large CRDs that will be filtered down anyway
  - level: Metadata
    resources:
      - group: "apiextensions.k8s.io"
        resources: ["customresourcedefinitions"]
        resourceNames: ["installations.operator.tigera.io"]
    omitStages:
      - "RequestReceived"
  # overriding the default behavior of coredns might have security threats for Kubernetes DNS in security perspective, set the level as RequestResponse
  - level: RequestResponse
    verbs: ["update","patch"]
    resources:
      - group: ""
        resources: ["configmaps"]
        resourceNames: ["coredns-custom"]
    namespaces: ["kube-system"]
    omitStages:
      - "RequestReceived"
  # Secrets, ConfigMaps, ServiceAccounts, TokenRequest and TokenReviews can contain sensitive & binary data,
  # so only log at the Metadata level.
  - level: Metadata
    resources:
      - group: ""
        resources: ["secrets", "configmaps", "serviceaccounts", "serviceaccounts/token"]
      - group: authentication.k8s.io
        resources: ["tokenreviews"]
    omitStages:
      - "RequestReceived"
  # Capture state of vertical pod autoscalers
  - level: Request
    verbs: ["create", "update", "patch", "delete"]
    resources:
      - group: "autoscaling.k8s.io"
        resources: ["verticalpodautoscalers", "verticalpodautoscalercheckpoints"]
    omitStages:
      - "RequestReceived"
  # Capture create and delete of internal fleet resources
  - level: RequestResponse
    verbs: ["create", "delete"]
    resources:
      - group: "cluster.kubernetes-fleet.io"
        resources: ["memberclusters", "internalmemberclusters"]
      - group: "placement.kubernetes-fleet.io"
        resources: ["works"]
      - group: "networking.fleet.azure.com"
        resources: ["internalserviceexports", "internalserviceimports"]
    omitStages:
      - "RequestReceived"
  # Capture CUD of user facing Fleet API
  - level: RequestResponse
    verbs: ["create", "update", "patch", "delete"]
    resources:
      - group: "placement.kubernetes-fleet.io"
        resources: ["clusterstagedupdateruns", "clusterresourceplacements", "clusterresourceplacementevictions", "clusterresourceplacementdisruptionbudgets", "clusterstagedupdatestrategies", "clusterapprovalrequests", "clusterresourceoverrides", "resourceoverrides"]
      - group: "networking.fleet.azure.com"
        resources: ["serviceexports", "multiclusterservices", "trafficmanagerprofiles", "trafficmanagerbackends"]
    omitStages:
      - "RequestReceived"
  # Capture CUD of user facing Karpenter resources
  - level: RequestResponse
    verbs: ["create", "update", "patch", "delete"]
    resources:
      - group: "karpenter.azure.com"
        resources: ["aksnodeclasses", "aksnodeclasses/status"]
      - group: "karpenter.sh"
        resources: ["nodepools", "nodepools/status", "nodeclaims", "nodeclaims/status"]
    omitStages:
      - "RequestReceived"
  # Get responses can be large; don't log response
  - level: Request
    verbs: ["get", "list", "watch"]
    resources:
      - group: ""
      - group: "admissionregistration.k8s.io"
      - group: "apiextensions.k8s.io"
      - group: "apiregistration.k8s.io"
      - group: "apps"
      - group: "authentication.k8s.io"
      - group: "authorization.k8s.io"
      - group: "autoscaling"
      - group: "batch"
      - group: "certificates.k8s.io"
      - group: "extensions"
      - group: "metrics.k8s.io"
      - group: "networking.k8s.io"
      - group: "policy"
      - group: "rbac.authorization.k8s.io"
      - group: "scheduling.k8s.io"
      - group: "settings.k8s.io"
      - group: "storage.k8s.io"
    omitStages:
      - "RequestReceived"
  # Default level for known APIs
  - level: RequestResponse
    resources:
      - group: ""
      - group: "admissionregistration.k8s.io"
      - group: "apiextensions.k8s.io"
      - group: "apiregistration.k8s.io"
      - group: "apps"
      - group: "authentication.k8s.io"
      - group: "authorization.k8s.io"
      - group: "autoscaling"
      - group: "batch"
      - group: "certificates.k8s.io"
      - group: "extensions"
      - group: "metrics.k8s.io"
      - group: "networking.k8s.io"
      - group: "policy"
      - group: "rbac.authorization.k8s.io"
      - group: "scheduling.k8s.io"
      - group: "settings.k8s.io"
      - group: "storage.k8s.io"
    omitStages:
      - "RequestReceived"
  # Default level for all other requests.
  - level: Metadata
    omitStages:
      - "RequestReceived"

Nota

A política de auditoria é gerida pela AKS e não pode ser personalizada. A política foi concebida para equilibrar a observabilidade de segurança com a otimização de desempenho e custos, reduzindo o volume de logs para operações de alta frequência e baixo risco.

Logs de insights do plano de dados AKS para contêineres

Pré-requisitos e requisitos de configuração: O Container Insights requer um espaço de trabalho de Log Analytics para armazenamento de registos e suporta tanto identidade gerida como métodos de autenticação legados. Para novos clusters, recomenda-se a autenticação de identidade gerida. A recolha de dados pode ser personalizada utilizando as Regras de Recolha de Dados (DCRs) do Azure Monitor para controlar custos e reduzir o volume de ingestão.

O Container insights coleta vários tipos de dados de telemetria de contêineres e clusters AKS para ajudá-lo a monitorar, solucionar problemas e obter informações sobre seus aplicativos em contêineres em execução em seus clusters AKS. Para obter uma lista das tabelas e as respetivas descrições detalhadas utilizadas pelo Container Insights, consulte a referência de tabelas do Azure Monitor. Todas as tabelas estão disponíveis para consultas de log.

No AKS Automatic, o Container Insights está ativado por defeito como parte da linha base de monitorização.

Use as configurações de otimização de custos para personalizar e controlar os dados de métricas coletados por meio do agente Container insights. Esse recurso dá suporte às configurações de coleta de dados para seleção de tabela individual, intervalos de coleta de dados e namespaces para excluir a coleta de dados por meio das DCRs (Regras de Coleta de Dados do Azure Monitor). Essas configurações controlam o volume de ingestão e reduzem os custos de monitoramento do Container insights. Pode personalizar os dados recolhidos de insights do Container no portal Azure usando as seguintes opções. A seleção de quaisquer opções diferentes de Todas (Padrão) torna a experiência de insights do contêiner indisponível.

Agrupamento Tabelas Notas
Tudo (predefinição) Todas as tabelas de insights de contêiner padrão Necessário para habilitar as visualizações padrão do Container insights.
Performance Perf, InsightsMetrics N/A
Logs e eventos ContainerLog ou ContainerLogV2, KubeEvents, KubePodInventory Recomendado se activaste o serviço gerido para as métricas do Prometheus.
Cargas de trabalho, implementações e HPAs InsightsMetrics, KubePodInventory, KubeEvents, ContainerInventory, ContainerNodeInventory, KubeNodeInventory, KubeServices N/A
Volumes Persistentes InsightsMetrics, KubePVInventory N/A

O agrupamento Logs e eventos captura os logs das tabelas ContainerLog ou ContainerLogV2, KubeEvents e KubePodInventory , mas não as métricas. O caminho recomendado para coletar métricas é habilitar o serviço gerenciado para Prometheus a partir do cluster AKS e usar o Azure Managed Grafana para visualização de dados. Para obter mais informações, consulte Monitorizar um espaço de trabalho do Azure Monitor.

Esquema de ContainerLogV2

Requisitos de compatibilidade e configuração: Use o esquema ContainerLogV2 para novas implementações Container insights que utilizam autenticação de identidade gerida através de templates Azure Resource Manager (ARM), Bicep, Terraform, Azure Policy ou o portal Azure. O esquema suporta o escalão de registos básicos para reduzir os custos. Os registos básicos suportam alertas de pesquisa simples em registos, mas os alertas avançados requerem registos do escalão Analytics. Para alertas agregados ou quase em tempo real, utilize o Prometheus gerido quando houver métricas disponíveis, regras resumidas ou encaminhe dados selecionados para o nível de Análise com transformações. Para mais informações, consulte Ativar o esquema ContainerLogV2 e Estratégias de alerta custo-efetivas para AKS.

As informações de contêiner no Azure Monitor fornecem um esquema recomendado para logs de contêiner, ContainerLogV2. O formato inclui os seguintes campos para consultas comuns para exibir dados relacionados a clusters Kubernetes habilitados para AKS e Azure Arc:

  • Nome do contêiner
  • PodName
  • PodNamespace

Registo de atividades do Azure

O log de atividades contém eventos no nível de assinatura que rastreiam as operações para cada recurso do Azure visto de fora desse recurso; por exemplo, criar um novo recurso ou iniciar uma máquina virtual.

Coleção: Os eventos do registo de atividades são gerados e recolhidos automaticamente num repositório separado para visualização no portal do Azure.

Roteamento: você pode enviar dados de log de atividades para os Logs do Azure Monitor para analisá-los junto com outros dados de log. Outros locais, como o Armazenamento do Azure, Hubs de Eventos do Azure e determinados parceiros de monitoramento da Microsoft também estão disponíveis. Para obter mais informações sobre como rotear o log de atividades, consulte Visão geral do log de atividades do Azure.

Visualize logs de contêineres, eventos e métricas de pod do AKS em tempo real

Pré-requisitos e requisitos de configuração: A funcionalidade de dados em tempo real exige que o Container Insights esteja ativado no seu cluster e utiliza acesso direto à API Kubernetes. Para clusters privados, o acesso requer um computador na mesma rede privada que o cluster. A autenticação segue o modelo Kubernetes RBAC e requer permissões apropriadas do cluster.

Pode visualizar registos de contentores, eventos e métricas de pod do AKS usando a funcionalidade de dados em tempo real no Container insights e resolver problemas em tempo real com acesso direto a kubectl logs -c, kubectl get eventos e kubectl top pods.

Nota

O AKS utiliza arquiteturas de registo ao nível do cluster do Kubernetes. Os logs de contêiner estão localizados no nó em /var/log/containers. Para aceder a um nó, consulte Ligar-se a nós do cluster AKS.

Para saber como configurar esse recurso, consulte Configurar dados dinâmicos no Container insights. O recurso acessa diretamente a API do Kubernetes. Para obter mais informações sobre o modelo de autenticação, consulte a API do Kubernetes.

Ver registos em tempo real dos recursos AKS

Requisitos de rede de cluster privado: Para aceder a registos de um cluster privado, deve usar um computador que esteja na mesma rede privada do cluster.

  1. No portal do Azure, vá para o cluster AKS.

  2. Em Recursos do Kubernetes, selecione Cargas de trabalho.

  3. Para Deployment, Pod, Replica set, Stateful set, Job ou Cron Job, selecione um valor e, em seguida, selecione Live Logs.

  4. Selecione um log de recursos para exibir.

    O exemplo a seguir mostra os logs de um recurso pod:

    Captura de ecrã que mostra a implementação de registos em direto.

Visualize registos em tempo real de contentores usando insights de contentores

Autenticação e transmissão de dados: Após a autenticação bem-sucedida, se os dados puderem ser recuperados, começam a ser transmitidos para o separador Live Logs . Os dados de registo aparecem num fluxo contínuo. O acesso alternativo aos registos está disponível através do Ver Registos no Log Analytics para análise histórica.

Você pode visualizar dados de log em tempo real à medida que o motor de contentores os gera no separador Cluster, Nós, Controladores ou Contentores.

  1. No portal do Azure, vá para o cluster AKS.

  2. Em Monitorizar, selecione Informações.

  3. Na guia Cluster, Nós, Controladores ou Contêineres, selecione um valor.

  4. No painel Visão geral do recurso, selecione Logs dinâmicos.

    A imagem a seguir mostra os logs de um recurso de contêiner:

    Captura de tela que mostra a opção Live Logs do contêiner para exibir dados.

Visualize eventos ao vivo no contentor usando o Insights de Contentores.

Streaming e acesso a eventos: Fluxos de dados de eventos em tempo real à medida que o motor de contentores os gera. Os eventos incluem criação de pods, eliminação, operações de escalonamento e condições de erro. Os dados históricos dos eventos estão acessíveis através do Ver Eventos no Log Analytics.

Você pode visualizar dados de eventos em tempo real enquanto o motor de contentor os gera na guia Cluster, Nós, Controladores ou Contentores.

  1. No portal do Azure, vá para o cluster AKS.

  2. Em Monitorizar, selecione Informações.

  3. Selecione a guia Cluster, Nós, Controladores ou Contêineres e selecione um objeto.

  4. No painel Visão geral do recurso, selecione Eventos ao vivo.

    Após a autenticação bem-sucedida, se os dados puderem ser recuperados, eles começarão a ser transmitidos para a guia Eventos ao vivo . A imagem a seguir mostra os eventos de um recurso de contêiner:

    Captura de tela que mostra a opção Eventos ao vivo do contêiner para exibir dados.

Veja métricas em direto do pod usando insights do Container

Âmbito e disponibilidade de métricas: Métricas ao vivo estão disponíveis para recursos de pods nos separadores Nós ou Controladores. As métricas incluem utilização de CPU, consumo de memória, E/S de rede e estatísticas do sistema de ficheiros. Métricas históricas estão acessíveis através do View Events in Log Analytics.

Você pode visualizar dados de métricas em tempo real enquanto o motor de contentores os gera na guia Nós ou Controladores ao selecionar um recurso do pod.

  1. No portal do Azure, vá para o cluster AKS.

  2. Em Monitorizar, selecione Informações.

  3. Selecione o separador Nós ou Controladores e, em seguida, selecione um objeto de pod.

  4. No painel Visão geral do recurso, selecione Métricas em tempo real.

    Após a autenticação bem-sucedida, se os dados puderem ser recuperados, eles começarão a ser transmitidos para a guia Métricas em tempo real . A imagem a seguir mostra as métricas de um recurso pod:

    Captura de tela que mostra a opção pod Live Metrics para visualizar dados.

    Analise os dados de monitoramento

    Existem muitas ferramentas para analisar dados de monitoramento.

    Ferramentas do Azure Monitor

    O Azure Monitor dá suporte às seguintes ferramentas básicas:

    As ferramentas que permitem uma visualização mais complexa incluem:

    • Painéis que permitem combinar diferentes tipos de dados em um único painel no portal do Azure.
    • Pastas de trabalho, relatórios personalizáveis que você pode criar no portal do Azure. As pastas de trabalho podem incluir texto, métricas e consultas de log.
    • Grafana, uma ferramenta de plataforma aberta que se destaca em dashboards operacionais. Você pode usar o Grafana para criar painéis que incluem dados de várias fontes diferentes do Azure Monitor.
    • Power BI, um serviço de análise de negócios que fornece visualizações interativas em várias fontes de dados. Você pode configurar o Power BI para importar automaticamente dados de log do Azure Monitor para aproveitar essas visualizações.

    Ferramentas de exportação do Azure Monitor

    Você pode obter dados do Azure Monitor para outras ferramentas usando os seguintes métodos:

    Para começar a usar a API REST para o Azure Monitor, consulte Passo a passo da API REST de monitoramento do Azure.

Monitorizar clusters AKS no portal do Azure

A guia Monitoramento no painel Visão geral do seu recurso de cluster AKS oferece uma maneira rápida de começar a exibir dados de monitoramento no portal do Azure. Este separador inclui gráficos com métricas comuns do cluster, separadas por conjunto de nós. Você pode selecionar qualquer um desses gráficos para analisar melhor os dados no explorador de métricas.

A guia Monitoramento também inclui links para o serviço gerenciado do Azure para Prometheus e informações de contêiner para o cluster. Você pode habilitar essas ferramentas na guia Monitoramento . Você também pode ver um banner na parte superior do painel que recomenda outros recursos para melhorar o monitoramento do cluster.

No AKS Automatic, os dashboards do Azure Monitor com Grafana estão disponíveis por predefinição na experiência do portal do Azure.

Sugestão

Para acessar os recursos de monitoramento para todos os clusters AKS em sua assinatura, na home page do portal do Azure, selecione Azure Monitor.

Observar e resolver problemas de aplicações usando o ambiente de trabalho AKS

O AKS desktop é uma experiência de desktop focada em aplicações para Azure Kubernetes Service (AKS) que o ajuda a ligar-se a clusters, visualizar recursos, implementar aplicações e resolver problemas de cargas de trabalho sem conhecimentos profundos em Kubernetes.

O desktop do AKS complementa os insights do Azure Monitor e do Container ao proporcionar às equipas de aplicação um local único e pronto a usar para observação diária de alto nível e resolução de problemas das suas cargas de trabalho individuais, sem necessidade de construir ferramentas personalizadas ou alternar entre ferramentas.

Num projeto de ambiente de trabalho do AKS, pode:

  • Consulte métricas como o consumo de CPU e memória para componentes de aplicação.
  • Transmite os logs dos pods em tempo real para depuração.
  • Visualize as dependências entre cargas de trabalho e serviços usando o mapa de recursos.

Captura de ecrã da visão geral do Projeto no ambiente de trabalho do AKS, mostrando os componentes da aplicação, as métricas e o estado de funcionamento de um projeto.

Para mais informações, consulte a visão geral do ambiente de trabalho do AKS.

Consultas Kusto

Você pode analisar dados de monitoramento no repositório Azure Monitor Logs / Log Analytics usando a linguagem de consulta Kusto (KQL).

Importante

Quando você seleciona Logs no menu do serviço no portal, o Log Analytics é aberto com o escopo da consulta definido para o serviço atual. Esse escopo significa que as consultas de log incluirão apenas dados desse tipo de recurso. Se quiser executar uma consulta que inclua dados de outros serviços do Azure, selecione Logs no menu Azure Monitor . Consulte Escopo e intervalo de tempo da consulta de log no Azure Monitor Log Analytics para obter detalhes.

Para obter uma lista de consultas comuns para qualquer serviço, consulte a interface de consultas do Log Analytics.

Alertas

Os alertas do Azure Monitor notificam proativamente quando condições específicas são encontradas em seus dados de monitoramento. Os alertas permitem-lhe identificar e resolver problemas no seu sistema antes que os seus clientes os percebam. Para obter mais informações, consulte Alertas do Azure Monitor.

Há muitas fontes de alertas comuns para recursos do Azure. Para obter exemplos de alertas comuns para recursos do Azure, consulte Consultas de alerta de log de exemplo. O site Azure Monitor Baseline Alerts (AMBA) fornece um método semiautomatizado de implementação de alertas métricos de plataforma, painéis e diretrizes importantes. O site aplica-se a um subconjunto em contínua expansão dos serviços do Azure, incluindo todos os serviços que fazem parte da Zona de Aterragem do Azure (ALZ).

O esquema de alerta comum padroniza o consumo de notificações de alerta do Azure Monitor. Para obter mais informações, consulte Esquema de alerta comum.

Tipos de alertas

Pode criar alertas para qualquer origem de dados de métricas ou de registos na plataforma de dados do Azure Monitor. Há muitos tipos diferentes de alertas, dependendo dos serviços que você está monitorando e dos dados de monitoramento que você está coletando. Diferentes tipos de alertas têm vários benefícios e desvantagens. Para obter mais informações, consulte Escolher o tipo de alerta de monitoramento correto.

A lista a seguir descreve os tipos de alertas do Azure Monitor que você pode criar:

  • Os alertas métricos avaliam as métricas de recursos em intervalos regulares. As métricas podem ser métricas de plataforma, métricas personalizadas, logs do Azure Monitor convertidos em métricas ou métricas do Application Insights. Os alertas métricos também podem aplicar várias condições e limites dinâmicos.
  • Os alertas de log permitem que os usuários usem uma consulta do Log Analytics para avaliar logs de recursos em uma frequência predefinida.
  • Os alertas do log de atividades são acionados quando ocorre um novo evento do log de atividades que corresponde às condições definidas. Os alertas de Estado de funcionamento do Recurso e os alertas de Estado de funcionamento do Serviço são alertas do registo de atividades que comunicam o estado de funcionamento do seu serviço e dos seus recursos.

Alguns serviços do Azure também suportam alertas de deteção inteligente, alertas Prometheus ou regras de alerta recomendadas.

Para alguns serviços, você pode monitorar em escala aplicando a mesma regra de alerta de métrica a vários recursos do mesmo tipo que existem na mesma região do Azure. Notificações individuais são enviadas para cada recurso monitorado. Para serviços e nuvens do Azure com suporte, consulte Monitorar vários recursos com uma regra de alerta.

Para alguns serviços do Azure, você pode habilitar regras de alerta prontas para uso recomendadas.

O sistema compila uma lista de regras de alerta recomendadas com base em:

  • O conhecimento do fornecedor do recurso sobre os sinais importantes e os limiares para a monitorização do recurso.
  • Dados que indicam para que é que os clientes normalmente configuram alertas neste recurso.

Nota

As regras de alerta recomendadas estão disponíveis para:

  • Máquinas virtuais
  • Recursos do Serviço Kubernetes do Azure (AKS)
  • Áreas de trabalho do Log Analytics

Configurar alertas baseados em métricas Prometheus

Requisitos de download e configuração: As regras de alerta estão disponíveis como modelos ARM descarregáveis ou ficheiros Bicep. Antes de configurar alertas, certifique-se de que o serviço gerido do Prometheus está ativado no seu cluster e que um espaço de trabalho Azure Monitor está devidamente ligado ao seu cluster AKS.

Ao habilitar a coleta do serviço gerenciado para métricas do Prometheus para seu cluster, você pode baixar uma coleção de regras de alerta recomendadas do serviço gerenciado para o Prometheus.

O download inclui as seguintes regras:

Nível Alertas
Nível do cluster KubeCPUQuotaOvercommit
KubeMemoryQuotaOvercommit
KubeContainerOOMKilledCount
KubeClientErrors
KubePersistentVolumeFillingUp
KubePersistentVolumeInodesFillingUp
KubePersistentVolumeErrors
KubeContainerWaiting
KubeDaemonSetNotScheduled
KubeDaemonSetMisScheduled
KubeQuotaAlmostFull
Nível do nó KubeNodeUnreachable
KubeNodeReadinessFlapping
Nível do pod KubePVUsageHigh
KubeDeploymentReplicasMismatch
KubeStatefulSetReplicasMismatch
KubeHpaReplicasMismatch
KubeHpaMaxedOut
KubePodCrashLooping
KubeJobStale
KubePodContainerRestart
KubePodReadyStateLow
KubePodFailedState
KubePodNotReadyByController
KubeStatefulSetGenerationMismatch
KubeJobFailed
KubeContainerAverageCPUHigh
KubeContainerAverageMemoryHigh
KubeletPodStartUpLatencyHigh

Para obter mais informações, consulte Criar alertas de log a partir de Insights de Contentores e Consultar logs de Insights de Contentores.

Os alertas de log podem medir dois tipos de informações para ajudá-lo a monitorar diversos cenários:

  • Contagem de resultados: conta o número de linhas retornadas pela consulta. Utilize estas informações para trabalhar com eventos como logs de eventos do Windows, eventos syslog e exceções de aplicações.
  • Cálculo de um valor: faz um cálculo com base em uma coluna numérica. Use essas informações para incluir diversos recursos. Um exemplo é a percentagem de CPU.

A maioria das consultas de log compara um DateTime valor com o tempo presente usando o now operador e recuando uma hora. Para saber como criar alertas baseados em log, consulte Criar alertas de log a partir de informações de contêiner.

Regras de alerta do AKS

A tabela a seguir lista algumas regras de alerta sugeridas para o AKS. Estes alertas são apenas exemplos. Você pode definir alertas para qualquer métrica, entrada de log ou entrada de registro de atividades listada na referência de dados de monitoramento do AKS.

Condição Descrição
Percentagem de Utilização da CPU>95 Alerta quando o uso médio da CPU em todos os nós excede o limite.
Percentagem do Conjunto de Trabalho de Memória>100 Alerta quando o conjunto de trabalho médio em todos os nós excede o limite.

Recomendações do assistente

Para alguns serviços, se ocorrerem condições críticas ou alterações iminentes durante as operações de recursos, será exibido um alerta na página Visão geral do serviço no portal. Você pode encontrar mais informações e correções recomendadas para o alerta em Recomendações do Advisor em Monitoramento no menu à esquerda. Durante as operações normais, nenhuma recomendação do consultor é exibida.

Para obter mais informações sobre o Assistente do Azure, consulte Visão geral do Assistente do Azure.

Nota

Se você estiver criando ou executando um aplicativo executado em seu serviço, o Azure Monitor Application Insights pode oferecer mais tipos de alertas.

Monitorização das métricas de rede de nós AKS

Requisitos de habilitação: Quando ativar o serviço gerido do Azure Monitor para o Prometheus no seu cluster, as métricas de rede ao nível dos nós são recolhidas por defeito. Para recolher métricas avançadas ao nível do pod e outras métricas avançadas de rede, ative a Observabilidade da Rede de Contentores.

As métricas de rede de nó são cruciais para manter um cluster Kubernetes saudável e com desempenho. Ao coletar e analisar dados sobre o tráfego de rede, você pode obter informações valiosas sobre a operação do cluster e identificar possíveis problemas antes que eles levem a interrupções ou perda de desempenho.

As métricas de rede dos nós seguintes são ativadas por padrão e são agregadas por cada nó. Todas as métricas incluem os rótulos: cluster e instância (nome do nó). Pode facilmente visualizar estas métricas usando o painel Managed Grafana em Azure Managed Prometheus>Kubernetes>Networking>Clusters.

Métricas de rede de nós AKS por tipo de plano de dados

Todas as métricas incluem estes rótulos:

  • cluster
  • instance (nome do nó)

Suporte e limitações do sistema operativo: Para cenários do plano de dados Cilium, a funcionalidade Container Network Observability fornece métricas apenas para pools de nós Linux. Atualmente, o Windows não é suportado para métricas de Observabilidade de Rede de Contêiner. Assegure que o seu cluster tem pools de nós Linux para garantir a disponibilidade total de métricas Cilium.

O Cilium expõe várias métricas que o Container Network Observability usa:

Nome da métrica Descrição Rótulos extras Linux Windows
cilium_forward_count_total Contagem total de pacotes encaminhados direction Suportado ✅ Não suportado ❌
cilium_forward_bytes_total Contagem total de bytes encaminhados direction Suportado ✅ Não suportado ❌
cilium_drop_count_total Contagem total de pacotes descartados direction, reason Suportado ✅ Não suportado ❌
cilium_drop_bytes_total Total de bytes perdidos direction, reason Suportado ✅ Não suportado ❌

Desativar a recolha de métricas de nós na rede AKS

Você pode desabilitar a coleta de métricas de rede em nós específicos adicionando o rótulo networking.azure.com/node-network-metrics=disabled a esses nós.

Nota

A retina tem uma tolerância operator: "Exists"effect: NoSchedule, por isso ignora NoSchedule defeitos. Portanto, rótulos são usados em vez de manchas para controlar o agendamento.

Se o cluster for autoprovisioning/autoscaling de nós, deve-se ativar manualmente a flag em cada um dos nós.

Importante

Esta funcionalidade não é aplicável se o Advanced Container Networking Services (ACNS) estiver ativado no seu cluster.

Para desativar a recolha de métricas num nó:

kubectl label node <node-name> networking.azure.com/node-network-metrics=disabled

Para obter métricas detalhadas de nível de pod e DNS, consulte Advanced Container Networking Services.

Conteúdos relacionados

  • Last updated on