Todos os produtos
Search

Este produto

    Container Service for Kubernetes:Gerenciamento de alertas do ACK

    Central de documentação

    Container Service for Kubernetes:Gerenciamento de alertas do ACK

    Última atualização: Jun 30, 2026

    Monitore eventos do cluster, métricas de recursos e a integridade dos componentes com regras de alerta configuráveis baseadas em CRD.

    Faturamento

    O recurso de alerta utiliza dados do Log Service SLS, Managed Service for Prometheus e CloudMonitor. Notificações como SMS e chamadas telefônicas geram cobranças adicionais. Consulte o modelo padrão de regra de alerta para identificar as fontes de alerta e ativar os serviços necessários.

    Fonte de dados do alerta

    Requisitos de configuração

    Detalhes de faturamento

    Log Service SLS

    Ative o monitoramento de eventos. O monitoramento de eventos é ativado por padrão ao habilitar o recurso de alerta.

    Faturamento por recurso

    Managed Service for Prometheus

    Configure o Managed Service for Prometheus para o seu cluster.

    Gratuito

    CloudMonitor

    Ative o CloudMonitor para o seu cluster ACK.

    pagamento conforme o uso

    Ativar o gerenciamento de alertas

    Configure alertas de métricas para recursos do cluster e receba notificações automáticas quando ocorrerem anomalias. Isso permite um gerenciamento mais eficiente do cluster e garante a operação estável do serviço. Consulte Modelo padrão de regra de alerta para obter detalhes sobre alertas de recursos.

    ACK managed clusters

    Ative a configuração de alerta para um cluster existente ou durante a criação de um novo cluster.

    Cluster existente

    1. Faça login no console do ACK. No painel de navegação à esquerda, clique em Clusters.

    2. Na página Clusters, clique no nome do seu cluster. No painel de navegação à esquerda, clique em Operations > Alerts.

    3. Na página Alerts, siga as instruções na tela para instalar ou atualizar os componentes necessários.

    4. Após a instalação ou atualização, acesse a página Alerts para configurar os alertas.

      Aba

      Descrição

      Alert Rules

      • Status: Ativa ou desativa um conjunto de regras de alerta.

      • Edit Contact Group: Define o grupo de contatos para notificações de alerta.

      As notificações são enviadas apenas para grupos de contatos. Crie contatos e grupos primeiro. Para notificar uma pessoa específica, crie um grupo dedicado para esse contato.

      Alert History

      Visualize até 100 registros de alerta das últimas 24 horas.

      • Clique em um link na coluna Alert Rule para visualizar as configurações da regra no sistema de monitoramento correspondente.

      • Clique em Details para acessar a página do recurso relacionado à anomalia.

      • Clique em Intelligent Analytics para análise e solução de problemas com inteligência artificial.

      Alert Contacts

      Crie, edite ou exclua contatos.

      Métodos de contato:

      • Chamada telefônica/SMS: Defina um número de celular para que um contato receba alertas por telefone e SMS.

        Apenas números de celular verificados podem receber notificações por chamada telefônica. Consulte Verificar um número de celular.

      • E-mail: Defina um endereço de e-mail para que um contato receba notificações de alerta.

      • Chatbots: chatbots do DingTalk, chatbots do WeCom e chatbots do Lark.

        Para chatbots do DingTalk, adicione palavras-chave de segurança: alert, dispatch.
      Verifique as notificações por e-mail e chatbot no console do CloudMonitor em Alerts > Alert Contacts antes de configurá-las.

      Alert Contact Groups

      Crie, edite ou exclua grupos de contatos.

      Se não existir nenhum grupo de contatos, o console criará um grupo padrão a partir da sua conta Alibaba Cloud.

    Novo cluster

    Ao criar um cluster, na página Component Configurations, selecione Alerts e, em seguida, selecione Use Default Alert Rule Template. Escolha um Alert Notification Contact Group. Consulte Criar um cluster gerenciado pelo ACK.

    image

    Depois que a configuração de alerta for ativada, as regras padrão entrarão em vigor e o grupo de contatos padrão receberá as notificações. Você pode modificar os contatos de alerta ou grupos de contatos.

    ACK dedicated clusters

    Para um cluster dedicado ACK, conceda permissões à função RAM Worker antes de ativar as regras de alerta padrão.

    Conceder permissões à função RAM Worker

    1. Faça login no console do ACK. No painel de navegação à esquerda, clique em Clusters.

    2. Na página Clusters, clique no nome do seu cluster. No painel de navegação à esquerda, clique em Cluster Information.

    3. Na página Cluster Information, na seção Cluster Resources, copie o nome ao lado de Worker RAM Role e clique no link para abrir o console RAM.

      1. Crie a seguinte política personalizada. Consulte Criar uma política personalizada.

        {
            "Action": [
                "log:*",
                "arms:*",
                "cms:*",
                "cs:UpdateContactGroup"
            ],
            "Resource": [
                "*"
            ],
            "Effect": "Allow"
}

      2. Na página Role, localize a função RAM Worker e anexe a política personalizada. Consulte Gerenciar permissões de uma função RAM.

        Nota: Este exemplo usa permissões amplas para simplificação. Em produção, siga o princípio do menor privilégio.

    4. Verifique se as permissões de alerta estão configuradas.

      1. No painel de navegação à esquerda da página de gerenciamento do cluster, esWorkloads > Deployments/span>.

      2. Selecione kube-system na lista suspensa Namespace e clique no nome de alicloud-monitor-controller na coluna Name.

      3. Clique na aba Logs para visualizar os logs do pod que indicam autorização bem-sucedida.

    Ativar regras de alerta padrão

    1. No painel de navegação à esquerda da página do cluster, escolha Operations > Alerts.

    2. Na página Alerts, configure as definições de alerta.

      Aba

      Descrição

      Alert Rules

      • Status: Ativa ou desativa um conjunto de regras de alerta.

      • Edit Contact Group: Define o grupo de contatos para notificações de alerta.

      As notificações são enviadas apenas para grupos de contatos. Crie contatos e grupos primeiro. Para notificar uma pessoa específica, crie um grupo dedicado para esse contato.

      Alert History

      Visualize até 100 registros de alerta das últimas 24 horas.

      • Clique em um link na coluna Alert Rule para visualizar as configurações da regra no sistema de monitoramento correspondente.

      • Clique em Details para acessar a página do recurso relacionado à anomalia.

      • Clique em Intelligent Analytics para análise e solução de problemas com inteligência artificial.

      Alert Contacts

      Crie, edite ou exclua contatos.

      Métodos de contato:

      • Chamada telefônica/SMS: Defina um número de celular para que um contato receba alertas por telefone e SMS.

        Apenas números de celular verificados podem receber notificações por chamada telefônica. Consulte Verificar um número de celular.

      • E-mail: Defina um endereço de e-mail para que um contato receba notificações de alerta.

      • Chatbots: chatbots do DingTalk, chatbots do WeCom e chatbots do Lark.

        Para chatbots do DingTalk, adicione palavras-chave de segurança: alert, dispatch.
      Verifique as notificações por e-mail e chatbot no console do CloudMonAlerts > Alert Contactss antes de configurá-las.

      Alert Contact Groups

      Crie, edite ou exclua grupos de contatos.

      Se não existir nenhum grupo de contatos, o console criará um grupo padrão a partir da sua conta Alibaba Cloud.

    Configurar regras de alerta

    Ativar a configuração de alerta cria um recurso CRD AckAlertRule chamado default no namespace kube-system com um modelo de regra de alerta padrão. Modifique este CRD para personalizar as regras de alerta.

    Console

    1. Faça login no console do ACK. No painel de navegação à esquerda, clique em Clusters.

    2. Na página Clusters, clique no nome do seu cluster. No painel de navegação à esquerda, clique em Operations > Alerts.

    3. Na aba Alert Rules, clique em Configure Alert Rule no canto superior direito. Em seguida, na coluna Actions da regra desejada, clique em YAML para visualizar a configuração do recurso CRD AckAlertRule.

    4. Modifique o arquivo YAML. Consulte Modelo padrão de regra de alerta para obter detalhes sobre os parâmetros.

      O exemplo a seguir mostra a configuração YAML de uma regra de alerta:

      Configuração YAML da regra de alerta

      apiVersion: alert.alibabacloud.com/v1beta1
kind: AckAlertRule
metadata:
  name: default
spec:
  groups:
    # The following is a sample configuration for a cluster event alert rule.
    - name: pod-exceptions                             # The name of the alert rule group, which corresponds to the Group_Name field in the alert template.
      rules:
        - name: pod-oom                                # The name of the alert rule.
          type: event                                  # The type of the alert rule (Rule_Type). Valid values: event, metric-cms (CloudMonitor metric), and metric-prometheus (Prometheus metric).
          expression: sls.app.ack.pod.oom              # The alert rule expression. If the rule type is event, the value is the Rule_Expression_Id from the default alert rule template in this topic.
          enable: enable                               # The state of the alert rule. Valid values: enable and disable.
        - name: pod-failed
          type: event
          expression: sls.app.ack.pod.failed
          enable: enable
    # The following is a sample configuration for a cluster infrastructure resource alert rule.
    - name: res-exceptions                              # The name of the alert rule group, which corresponds to the Group_Name field in the alert template.
      rules:
        - name: node_cpu_util_high                      # The name of the alert rule.
          type: metric-cms                              # The type of the alert rule (Rule_Type). Valid values: event, metric-cms (CloudMonitor metric), and metric-prometheus (Prometheus metric).
          expression: cms.host.cpu.utilization          # The alert rule expression. If the rule type is metric-cms, the value is the Rule_Expression_Id from the default alert rule template in this topic.
          contactGroups:                                # The contact groups mapped to the alert rule. This configuration is generated by the ACK console. Contacts are consistent for a single account and can be reused across multiple clusters.
            - arms_contact_group_id_v2: '69xxx'
              cms_contact_group_name: xxx Contact Group
              id: '10xxx'
          enable: enable                                # The state of the alert rule. Valid values: enable and disable.
          thresholds:                                   # The threshold of the alert rule.
            - key: CMS_ESCALATIONS_CRITICAL_Threshold
              unit: percent
              value: '85'                                # CPU utilization threshold. Default value: 85%.
            - key: CMS_ESCALATIONS_CRITICAL_Times
              value: '3'                                # An alert is triggered if the threshold is exceeded 3 consecutive times.
            - key: CMS_RULE_SILENCE_SEC                 # The silence period after the first alert is reported.
              value: '900'

      Use rules.thresholds para personalizar os limiares de alerta. Por exemplo, a configuração anterior aciona um alerta quando a utilização da CPU de um nó excede 85% por três vezes consecutivas e mais de 900 segundos se passaram desde o último alerta.

      Parâmetro

      Obrigatório

      Descrição

      Padrão

      CMS_ESCALATIONS_CRITICAL_Threshold

      Sim

      O limiar da regra de alerta. Se este parâmetro for omitido, a sincronização da regra falhará e a regra será desativada.

      • unit: A unidade do limiar. Valores válidos: percent, count e qps.

      • value: O valor do limiar.

      Varia conforme o modelo padrão de regra de alerta.

      CMS_ESCALATIONS_CRITICAL_Times

      Opcional

      O número de vezes consecutivas que a condição deve ser atendida antes que o CloudMonitor acione um alerta. Se este parâmetro for omitido, o valor padrão será usado.

      3

      CMS_RULE_SILENCE_SEC

      Opcional

      O período de silêncio em segundos após o relatório de um alerta inicial para uma regra do CloudMonitor que dispara continuamente. Isso evita a fadiga de alertas. Se este parâmetro for omitido, o valor padrão será usado.

      900

    CLI

    1. Edite o arquivo YAML da regra de alerta:

      kubectl edit ackalertrules default -n kube-system

    2. Modifique o arquivo YAML, salve e saia. Consulte Modelo padrão de regra de alerta para obter detalhes sobre os parâmetros.

      Configuração YAML da regra de alerta

      apiVersion: alert.alibabacloud.com/v1beta1
kind: AckAlertRule
metadata:
  name: default
spec:
  groups:
    # The following is a sample configuration for a cluster event alert rule.
    - name: pod-exceptions                             # The name of the alert rule group, which corresponds to the Group_Name field in the alert template.
      rules:
        - name: pod-oom                                # The name of the alert rule.
          type: event                                  # The type of the alert rule (Rule_Type). Valid values: event, metric-cms (CloudMonitor metric), and metric-prometheus (Prometheus metric).
          expression: sls.app.ack.pod.oom              # The alert rule expression. If the rule type is event, the value is the Rule_Expression_Id from the default alert rule template in this topic.
          enable: enable                               # The state of the alert rule. Valid values: enable and disable.
        - name: pod-failed
          type: event
          expression: sls.app.ack.pod.failed
          enable: enable
    # The following is a sample configuration for a cluster infrastructure resource alert rule.
    - name: res-exceptions                              # The name of the alert rule group, which corresponds to the Group_Name field in the alert template.
      rules:
        - name: node_cpu_util_high                      # The name of the alert rule.
          type: metric-cms                              # The type of the alert rule (Rule_Type). Valid values: event, metric-cms (CloudMonitor metric), and metric-prometheus (Prometheus metric).
          expression: cms.host.cpu.utilization          # The alert rule expression. If the rule type is metric-cms, the value is the Rule_Expression_Id from the default alert rule template in this topic.
          contactGroups:                                # The contact groups mapped to the alert rule. This configuration is generated by the ACK console. Contacts are consistent for a single account and can be reused across multiple clusters.
            - arms_contact_group_id_v2: 'xxx'
              cms_contact_group_name: xxx
              id: 'xxx'
          enable: enable                                # The state of the alert rule. Valid values: enable and disable.
          thresholds:                                   # The threshold of the alert rule.
            - key: CMS_ESCALATIONS_CRITICAL_Threshold
              unit: percent
              value: '85'                                # CPU utilization threshold. Default value: 85%.
            - key: CMS_ESCALATIONS_CRITICAL_Times
              value: '3'                                # An alert is triggered if the threshold is exceeded 3 consecutive times.
            - key: CMS_RULE_SILENCE_SEC                 # The silence period after the first alert is reported.
              value: '900'

      Use rules.thresholds para personalizar os limiares de alerta. Por exemplo, a configuração anterior aciona um alerta quando a utilização da CPU de um nó excede 85% por três vezes consecutivas e mais de 900 segundos se passaram desde o último alerta.

      Parâmetro

      Obrigatório

      Descrição

      Padrão

      CMS_ESCALATIONS_CRITICAL_Threshold

      Sim

      O limiar da regra de alerta. Se este parâmetro for omitido, a sincronização da regra falhará e a regra será desativada.

      • unit: A unidade do limiar. Valores válidos: percent, count e qps.

      • value: O valor do limiar.

      Varia conforme o modelo padrão de regra de alerta.

      CMS_ESCALATIONS_CRITICAL_Times

      Opcional

      O número de vezes consecutivas que a condição deve ser atendida antes que o CloudMonitor acione um alerta. Se este parâmetro for omitido, o valor padrão será usado.

      3

      CMS_RULE_SILENCE_SEC

      Opcional

      O período de silêncio em segundos após o relatório de um alerta inicial para uma regra do CloudMonitor que dispara continuamente. Isso evita a fadiga de alertas. Se este parâmetro for omitido, o valor padrão será usado.

      900

    Modelo padrão de regra de alerta

    Os alertas a seguir são sincronizados do Log Service, Prometheus Service e CloudMonitor. Na página Alerts, na coluna Alerts, clique em Advanced Settings para visualizar as configurações das regras.

    Eventos de erro

    Alerta

    Descrição

    Origem

    Tipo de regra

    Nome da regra ACK CR

    ID do evento SLS

    Evento de erro

    Disparado por qualquer evento de nível de erro no cluster.

    SLS

    event

    error-event

    sls.app.ack.error

    Eventos de aviso

    Alerta

    Descrição

    Origem

    Tipo de regra

    Nome da regra CRD

    ID do evento

    Evento de aviso

    Acionado por eventos críticos de nível de aviso no cluster, excluindo certos eventos ignoráveis.

    SLS

    event

    warn-event

    sls.app.ack.warn

    Alertas de componentes principais (cluster gerenciado ACK)

    Alerta

    Descrição

    Origem

    Tipo de regra

    Nome da regra ACK CR

    ID do evento SLS

    Anomalia de disponibilidade do API server do cluster

    Disparado quando o API server apresenta problemas de disponibilidade, o que pode limitar o gerenciamento do cluster.

    Managed Service for Prometheus

    metric-prometheus

    apiserver-unhealthy

    prom.apiserver.notHealthy.down

    Anomalia de disponibilidade do etcd do cluster

    A indisponibilidade do etcd afeta o estado de todo o cluster.

    Managed Service for Prometheus

    metric-prometheus

    etcd-unhealthy

    prom.etcd.notHealthy.down

    Anomalia de disponibilidade do kube-scheduler do cluster

    O kube-scheduler é responsável pelo agendamento dos pods. Se estiver indisponível, novos pods podem não iniciar.

    Managed Service for Prometheus

    metric-prometheus

    scheduler-unhealthy

    prom.scheduler.notHealthy.down

    Anomalia de disponibilidade do KCM do cluster

    O kube-controller-manager (KCM) executa loops de controle. Sua indisponibilidade pode afetar os mecanismos de autorrecuperação e ajuste de recursos do cluster.

    Managed Service for Prometheus

    metric-prometheus

    kcm-unhealthy

    prom.kcm.notHealthy.down

    Anomalia de disponibilidade do cloud-controller-manager do cluster

    O cloud-controller-manager gerencia o ciclo de vida de componentes externos da nuvem. Sua indisponibilidade pode afetar ajustes dinâmicos de serviço.

    Managed Service for Prometheus

    metric-prometheus

    ccm-unhealthy

    prom.ccm.notHealthy.down

    Anomalia de disponibilidade do CoreDNS do cluster - Contagem de solicitações cai para zero

    O CoreDNS fornece serviços de DNS ao cluster. Problemas no CoreDNS podem interromper a descoberta de serviços e a resolução de nomes de domínio.

    Managed Service for Prometheus

    metric-prometheus

    coredns-unhealthy-requestdown

    prom.coredns.notHealthy.requestdown

    Anomalia de disponibilidade do CoreDNS do cluster - Erro de pânico

    Disparado quando o CoreDNS entra em pânico. É necessária análise imediata de logs para diagnóstico.

    Managed Service for Prometheus

    metric-prometheus

    coredns-unhealthy-panic

    prom.coredns.notHealthy.panic

    Alta taxa de solicitações com erro no Ingress do cluster

    Uma alta taxa de erros em solicitações HTTP do controlador de Ingress pode impactar a acessibilidade dos serviços.

    Managed Service for Prometheus

    metric-prometheus

    ingress-err-request

    prom.ingress.request.errorRateHigh

    Certificado do controlador de Ingress do cluster expirando em breve

    Um certificado SSL expirado causará falhas nas solicitações HTTPS. Renove o certificado antecipadamente.

    Managed Service for Prometheus

    metric-prometheus

    ingress-ssl-expire

    prom.ingress.ssl.expire

    Número total de pods pendentes excede 1.000

    Um grande número de pods presos no estado Pending pode indicar recursos insuficientes ou uma política de agendamento inadequada.

    Managed Service for Prometheus

    metric-prometheus

    pod-pending-accumulate

    prom.pod.pending.accumulate

    Alto RT para webhook de admissão mutável do API server do cluster

    Respostas lentas do webhook de admissão mutável podem retardar a criação e modificação de recursos.

    Managed Service for Prometheus

    metric-prometheus

    apiserver-admit-rt-high

    prom.apiserver.mutating.webhook.rt.high

    Alto RT para webhook de admissão de validação do API server do cluster

    Respostas lentas do webhook de admissão de validação podem atrasar alterações de configuração.

    Managed Service for Prometheus

    metric-prometheus

    apiserver-validate-rt-high

    prom.apiserver.validation.webhook.rt.high

    OOM em componente do plano de controle do cluster

    Um componente principal do cluster está sem memória (OOM). É necessária uma investigação detalhada para evitar falhas no serviço.

    SLS

    event

    ack-controlplane-oom

    sls.app.ack.controlplane.pod.oom

    Regras de alerta para operações de pool de nós do cluster

    Alerta

    Descrição

    Origem

    Tipo de regra

    Nome da regra CRD

    ID do evento

    Falha na autorrecuperação de nó

    Uma falha na autorrecuperação de nó requer investigação imediata para manter a alta disponibilidade.

    SLS

    event

    node-repair_failed

    sls.app.ack.rc.node_repair_failed

    Falha na correção de CVE de nó

    Uma falha na correção de uma CVE crítica pode comprometer a segurança do cluster. Investigue e corrija com urgência.

    SLS

    event

    nodepool-cve-fix-failed

    sls.app.ack.rc.node_vulnerability_fix_failed

    Correção de CVE do pool de nós bem-sucedida

    Uma correção de CVE bem-sucedida reduz os riscos de segurança de vulnerabilidades conhecidas.

    SLS

    event

    nodepool-cve-fix-succ

    sls.app.ack.rc.node_vulnerability_fix_succeed

    Correção automática de CVE do pool de nós ignorada

    Uma correção automática foi ignorada, possivelmente devido a problemas de compatibilidade ou configurações personalizadas. Verifique se sua política de segurança é adequada.

    SLS

    event

    nodepool-cve-fix-skip

    sls.app.ack.rc.node_vulnerability_fix_skipped

    Falha na configuração do kubelet do pool de nós

    Uma falha na configuração do kubelet pode impactar o desempenho do nó e o agendamento de recursos.

    SLS

    event

    nodepool-kubelet-cfg-failed

    sls.app.ack.rc.node_kubelet_config_failed

    Configuração do kubelet do pool de nós bem-sucedida

    A nova configuração do kubelet foi aplicada com êxito. Verifique se ela entrou em vigor conforme esperado.

    SLS

    event

    nodepool-kubelet-config-succ

    sls.app.ack.rc.node_kubelet_config_succeed

    Falha na atualização do kubelet do pool de nós

    Uma falha na atualização do kubelet pode afetar a estabilidade e a funcionalidade do cluster. Revise o processo de atualização e a configuração.

    SLS

    event

    nodepool-k-c-upgrade-failed

    sls.app.ack.rc.node_kubelet_config_upgrade_failed

    Atualização do kubelet do pool de nós bem-sucedida

    Após uma atualização bem-sucedida, verifique se a nova versão do kubelet atende aos requisitos do cluster e das aplicações.

    SLS

    event

    nodepool-k-c-upgrade-succ

    sls.app.ack.rc.kubelet_upgrade_succeed

    Atualização de runtime do pool de nós bem-sucedida

    A atualização do runtime de contêiner do pool de nós foi concluída com êxito.

    SLS

    event

    nodepool-runtime-upgrade-succ

    sls.app.ack.rc.runtime_upgrade_succeed

    Falha na atualização de runtime do pool de nós

    A atualização do runtime de contêiner do pool de nós falhou.

    SLS

    event

    nodepool-runtime-upgrade-fail

    sls.app.ack.rc.runtime_upgrade_failed

    Atualização de imagem de SO do pool de nós bem-sucedida

    A atualização da imagem de SO do pool de nós foi concluída com êxito.

    SLS

    event

    nodepool-os-upgrade-succ

    sls.app.ack.rc.os_image_upgrade_succeed

    Falha na atualização de imagem de SO do pool de nós

    A atualização da imagem de SO do pool de nós falhou.

    SLS

    event

    nodepool-os-upgrade-failed

    sls.app.ack.rc.os_image_upgrade_failed

    Alteração de configuração do pool de nós Lingjun bem-sucedida

    As alterações de configuração no pool de nós Lingjun foram aplicadas com êxito.

    SLS

    event

    nodepool-lingjun-config-succ

    sls.app.ack.rc.lingjun_configuration_apply_succeed

    Falha na alteração de configuração do pool de nós Lingjun

    A aplicação de alterações de configuração no pool de nós Lingjun falhou.

    SLS

    event

    nodepool-lingjun-cfg-failed

    sls.app.ack.rc.lingjun_configuration_apply_failed

    Exceção de sistema de instância de nó

    Este alerta indica uma exceção de sistema (como um evento de sistema ECS ou um evento de instância Lingjun) no recurso subjacente de um nó ACK. Investigue imediatamente para mitigar o impacto de possíveis falhas de sistema ou hardware e determine se é necessária autorrecuperação ou gerenciamento de mudanças.

    SLS

    event

    node-system-exception

    sls.app.ack.nlc.out_of_band_event_observer

    Alertas de anomalia de nó do cluster

    Alerta

    Descrição

    Origem

    Tipo de regra

    Nome da regra ACK CR

    ID do evento SLS

    Anomalia de processo Docker

    O runtime Dockerd ou containerd em um nó do cluster trava ou deixa de responder.

    SLS

    event

    docker-hang

    sls.app.ack.docker.hang

    Evento de despejo

    Ocorre um evento de despejo (eviction) no cluster.

    SLS

    event

    eviction-event

    sls.app.ack.eviction

    Erro XID de GPU

    Uma GPU em um nó relata um erro XID, indicando um problema interno na GPU.

    SLS

    event

    gpu-xid-error

    sls.app.ack.gpu.xid_error

    Nó fica offline

    Um nó no cluster fica offline.

    SLS

    event

    node-down

    sls.app.ack.node.down

    Reinicialização de nó

    Um nó no cluster é reiniciado.

    SLS

    event

    node-restart

    sls.app.ack.node.restart

    Anomalia no serviço NTP

    O serviço NTP em um nó do cluster está com mau funcionamento.

    SLS

    event

    node-ntp-down

    sls.app.ack.ntp.down

    Anomalia PLEG

    O Pod Lifecycle Event Generator (PLEG) em um nó do cluster está com mau funcionamento.

    SLS

    event

    node-pleg-error

    sls.app.ack.node.pleg_error

    Anomalia de processo

    Um processo em um nó do cluster trava ou deixa de responder.

    SLS

    event

    ps-hang

    sls.app.ack.ps.hang

    Excesso de identificadores de arquivo

    Um nó possui muitos identificadores de arquivo abertos.

    SLS

    event

    node-fd-pressure

    sls.app.ack.node.fd_pressure

    Excesso de processos

    Um nó do cluster está executando processos demais.

    SLS

    event

    node-pid-pressure

    sls.app.ack.node.pid_pressure

    Falha ao excluir um nó

    O cluster falha ao excluir um nó.

    SLS

    event

    node-del-err

    sls.app.ack.ccm.del_node_failed

    Falha ao adicionar um nó

    O cluster falha ao adicionar um nó.

    SLS

    event

    node-add-err

    sls.app.ack.ccm.add_node_failed

    Falha na execução de comando em pool de nós gerenciado

    Falha na execução de um comando em um pool de nós gerenciado.

    SLS

    event

    nlc-run-cmd-err

    sls.app.ack.nlc.run_command_fail

    Comando de tarefa vazio em pool de nós gerenciado

    Uma tarefa é acionada em um pool de nós gerenciado sem um comando.

    SLS

    event

    nlc-empty-cmd

    sls.app.ack.nlc.empty_task_cmd

    Modo de tarefa não implementado em pool de nós gerenciado

    Um modo de tarefa não implementado é encontrado no pool de nós gerenciado.

    SLS

    event

    nlc-url-m-unimp

    sls.app.ack.nlc.url_mode_unimpl

    Operação de reparo desconhecida em pool de nós gerenciado

    Uma operação de reparo desconhecida é encontrada no pool de nós gerenciado.

    SLS

    event

    nlc-opt-no-found

    sls.app.ack.nlc.op_not_found

    Erro ao destruir nó de pool de nós gerenciado

    Ocorre um erro ao destruir um nó no pool de nós gerenciado.

    SLS

    event

    nlc-des-node-err

    sls.app.ack.nlc.destroy_node_fail

    Falha ao drenar nó de pool de nós gerenciado

    Um nó em um pool de nós gerenciado falha ao ser drenado corretamente.

    SLS

    event

    nlc-drain-node-err

    sls.app.ack.nlc.drain_node_fail

    Instância ECS reiniciada não atinge o estado desejado

    Uma instância ECS reiniciada em um pool de nós gerenciado não atinge seu estado desejado.

    SLS

    event

    nlc-restart-ecs-wait

    sls.app.ack.nlc.restart_ecs_wait_fail

    Falha ao reiniciar instância ECS em pool de nós gerenciado

    Uma instância ECS em um pool de nós gerenciado falha ao reiniciar.

    SLS

    event

    nlc-restart-ecs-err

    sls.app.ack.nlc.restart_ecs_fail

    Falha ao redefinir instância ECS em pool de nós gerenciado

    Uma instância ECS em um pool de nós gerenciado falha ao ser redefinida.

    SLS

    event

    nlc-reset-ecs-err

    sls.app.ack.nlc.reset_ecs_fail

    Falha em tarefa de autorrecuperação em pool de nós gerenciado

    Uma tarefa de autorrecuperação em um pool de nós gerenciado falha.

    SLS

    event

    nlc-sel-repair-err

    sls.app.ack.nlc.repair_fail

    Regras de alerta para anomalias de recursos do cluster

    Alerta

    Descrição

    Origem

    Tipo de regra

    Nome da regra

    ID do evento

    Nó: Utilização de CPU ≥ 85%

    Disparado quando a utilização de CPU de um nó excede o limiar (padrão: 85%).

    Quando os recursos restantes caem abaixo de 15%, a utilização pode exceder a CPU reservada para o mecanismo de contêiner, causando limitação frequente de CPU e impactando severamente a capacidade de resposta dos processos. Otimize o uso de CPU ou ajuste o limiar prontamente.

    Para ajustar o limiar, consulte Configurar regras de alerta.

    CloudMonitor

    metric-cms

    node_cpu_util_high

    cms.host.cpu.utilization

    Nó: Utilização de memória ≥ 85%

    Disparado quando a utilização de memória de um nó excede o limiar (padrão: 85%).

    Com recursos restantes abaixo de 15%, a utilização pode exceder a memória reservada para o mecanismo de contêiner, acionando a evicção forçada pelo kubelet. Otimize o uso de memória ou ajuste o limiar prontamente.

    Para ajustar o limiar, consulte Configurar regras de alerta.

    CloudMonitor

    metric-cms

    node_mem_util_high

    cms.host.memory.utilization

    Nó: Utilização de disco ≥ 85%

    Disparado quando a utilização de disco de um nó excede o limiar (padrão: 85%).

    Para ajustar o limiar, consulte Configurar regras de alerta.

    CloudMonitor

    metric-cms

    node_disk_util_high

    cms.host.disk.utilization

    Nó: Utilização de largura de banda de saída para Internet ≥ 85%

    Disparado quando a utilização de largura de banda de saída para Internet de um nó excede o limiar (padrão: 85%).

    Para ajustar o limiar, consulte Configurar regras de alerta.

    CloudMonitor

    metric-cms

    node_public_net_util_high

    cms.host.public.network.utilization

    Nó: Utilização de inode ≥ 85%

    Disparado quando a utilização de inodes de um nó excede o limiar (padrão: 85%).

    Para ajustar o limiar, consulte Configurar regras de alerta.

    CloudMonitor

    metric-cms

    node_fs_inode_util_high

    cms.host.fs.inode.utilization

    SLB: Utilização de QPS da Camada 7 ≥ 85%

    Disparado quando a utilização de QPS da Camada 7 de uma instância SLB excede o limiar (padrão: 85%).

    Nota

    A instância SLB está associada ao API server ou ao Ingress.

    Para ajustar o limiar, consulte Configurar regras de alerta.

    CloudMonitor

    metric-cms

    slb_qps_util_high

    cms.slb.qps.utilization

    SLB: Utilização de largura de banda de saída ≥ 85%

    Disparado quando a utilização de largura de banda de saída de uma instância SLB excede o limiar (padrão: 85%).

    Nota

    A instância SLB está associada ao API server ou ao Ingress.

    Para ajustar o limiar, consulte Configurar regras de alerta.

    CloudMonitor

    metric-cms

    slb_traff_tx_util_high

    cms.slb.traffic.tx.utilization

    SLB: Utilização máxima de conexões ≥ 85%

    Disparado quando a utilização máxima de conexões de uma instância SLB excede o limiar (padrão: 85%).

    Nota

    A instância SLB está associada ao API server ou ao Ingress.

    Para ajustar o limiar, consulte Configurar regras de alerta.

    CloudMonitor

    metric-cms

    slb_max_con_util_high

    cms.slb.max.connection.utilization

    SLB: Conexões descartadas por segundo para listener ≥ 1

    Disparado quando as conexões descartadas por segundo para um listener SLB excedem continuamente o limiar (padrão: 1).

    Nota

    A instância SLB está associada ao API server ou ao Ingress.

    Para ajustar o limiar, consulte Configurar regras de alerta.

    CloudMonitor

    metric-cms

    slb_drop_con_high

    cms.slb.drop.connection

    Nó: Espaço em disco insuficiente

    Um nó tem espaço em disco insuficiente.

    SLS

    event

    node-disk-pressure

    sls.app.ack.node.disk_pressure

    Nó: Recursos de agendamento insuficientes

    Um nó tem recursos insuficientes para agendamento.

    SLS

    event

    node-res-insufficient

    sls.app.ack.resource.insufficient

    Nó: Recursos de IP insuficientes

    Um nó tem recursos de IP insuficientes.

    SLS

    event

    node-ip-pressure

    sls.app.ack.ip.not_enough

    Cluster: Uso de disco excede o limiar

    O uso de disco do cluster excedeu o limiar.

    SLS

    event

    disk_space_press

    sls.app.ack.csi.no_enough_disk_space

    Alertas para operações do plano de controle ACK

    Alerta

    Descrição

    Origem

    Tipo de regra

    Nome da regra CRD

    ID do evento

    Notificação de tarefa de cluster ACK

    Operações agendadas e alterações no cluster.

    SLS

    event

    ack-system-event-info

    sls.app.ack.system_events.task.info

    Falha em tarefa de cluster ACK

    Uma operação do cluster falhou. Investigue prontamente.

    SLS

    event

    ack-system-event-error

    sls.app.ack.system_events.task.error

    Alertas de dimensionamento automático

    Alerta

    Descrição

    Origem

    Tipo de regra

    Nome da regra ACK CR

    ID do evento SLS

    Scale-out automático

    Adiciona nós automaticamente quando a carga aumenta.

    SLS

    event

    autoscaler-scaleup

    sls.app.ack.autoscaler.scaleup_group

    Scale-in automático

    Remove nós automaticamente quando a carga diminui.

    SLS

    event

    autoscaler-scaledown

    sls.app.ack.autoscaler.scaledown

    Tempo limite de scale-out

    O scale-out atingiu o tempo limite, possivelmente devido a recursos insuficientes ou uma política de dimensionamento incorreta.

    SLS

    event

    autoscaler-scaleup-timeout

    sls.app.ack.autoscaler.scaleup_timeout

    Scale-in de nó vazio

    Remove nós inativos ou vazios para recuperar recursos.

    SLS

    event

    autoscaler-scaledown-empty

    sls.app.ack.autoscaler.scaledown_empty

    Falha no scale-out

    Uma operação de scale-out falhou. Investigue e ajuste a política de recursos.

    SLS

    event

    autoscaler-up-group-failed

    sls.app.ack.autoscaler.scaleup_group_failed

    Cluster não saudável

    O autoscaler pausou o dimensionamento porque o cluster não está saudável.

    SLS

    event

    autoscaler-cluster-unhealthy

    sls.app.ack.autoscaler.cluster_unhealthy

    Exclusão de nó não iniciado

    Exclui nós que falham ao iniciar dentro de um período especificado.

    SLS

    event

    autoscaler-del-started

    sls.app.ack.autoscaler.delete_started_timeout

    Exclusão de nó não registrado

    Exclui nós que falham ao se registrar no cluster dentro de um período especificado.

    SLS

    event

    autoscaler-del-unregistered

    sls.app.ack.autoscaler.delete_unregistered

    Falha no scale-in

    Uma operação de scale-in falhou, o que pode desperdiçar recursos e causar distribuição desigual de carga.

    SLS

    event

    autoscaler-scale-down-failed

    sls.app.ack.autoscaler.scaledown_failed

    Drenagem de nó incompleta

    O autoscaler removeu um nó antes de despejar todos os pods. Isso pode causar interrupções no serviço.

    SLS

    event

    autoscaler-instance-expired

    sls.app.ack.autoscaler.instance_expired

    Alertas de carga de trabalho de aplicações do cluster

    Alerta

    Descrição

    Origem

    Tipo de regra

    Nome da regra CRD

    ID do evento SLS

    Falha em Job

    Um job falhou durante a execução.

    Prometheus

    metric-prometheus

    job-failed

    prom.job.failed

    Réplicas de deployment insuficientes

    Um deployment tem menos réplicas disponíveis do que o desejado, o que pode causar degradação do serviço.

    Prometheus

    metric-prometheus

    deployment-rep-err

    prom.deployment.replicaError

    Status anormal de réplica de DaemonSet

    Uma réplica de DaemonSet entrou em um estado anormal, como falha ao iniciar ou travamento. Isso pode interromper serviços no nó.

    Prometheus

    metric-prometheus

    daemonset-status-err

    prom.daemonset.scheduledError

    Anomalia de agendamento de DaemonSet

    Um DaemonSet falhou ao agendar pods em todos os nós elegíveis, possivelmente devido a restrições de recursos ou taints de nó.

    Prometheus

    metric-prometheus

    daemonset-misscheduled

    prom.daemonset.misscheduled

    Regras de alerta de anomalia de Pod

    Alerta

    Descrição

    Origem

    Rule_Type

    ACK_CR_Rule_Name

    SLS_Event_ID

    OOM de Pod

    Um pod ou processo sofreu um erro de falta de memória (OOM).

    Log Service

    event

    pod-oom

    sls.app.ack.pod.oom

    Falha na inicialização de Pod

    Um pod falhou ao iniciar.

    Log Service

    event

    pod-failed

    sls.app.ack.pod.failed

    Status não saudável de Pod

    Um pod está em um estado não saudável, como Pending, Failed ou Unknown.

    Managed Service for Prometheus

    metric-prometheus

    pod-status-err

    prom.pod.status.notHealthy

    CrashLoopBackOff de Pod

    Um pod falhou repetidamente ao iniciar e entrou em CrashLoopBackOff ou outros estados de falha.

    Managed Service for Prometheus

    metric-prometheus

    pod-crashloop

    prom.pod.status.crashLooping

    Regras de alerta de anomalia de armazenamento do cluster

    Alerta

    Descrição

    Origem

    Tipo de regra

    Nome da regra CRD

    ID do evento

    Capacidade de disco < 20 GiB

    Discos menores que 20 GiB não podem ser montados devido a uma limitação de armazenamento do cluster.

    SLS

    event

    csi_invalid_size

    sls.app.ack.csi.invalid_disk_size

    Disco por assinatura não suportado para volumes de contêiner

    Discos por assinatura não podem ser usados como volumes de contêiner.

    SLS

    event

    csi_not_portable

    sls.app.ack.csi.disk_not_portable

    Falha ao desmontar destino de montagem (dispositivo ocupado)

    O recurso não foi totalmente liberado ou um processo ativo está acessando o destino de montagem.

    SLS

    event

    csi_device_busy

    sls.app.ack.csi.device_busy

    Nenhum disco disponível

    Uma montagem de armazenamento falhou porque nenhum disco disponível foi encontrado.

    SLS

    event

    csi_no_ava_disk

    sls.app.ack.csi.no_ava_disk

    IOHang de disco

    Um disco no cluster não responde devido a um travamento de I/O.

    SLS

    event

    csi_disk_iohang

    sls.app.ack.csi.disk_iohang

    I/O lento em disco vinculado a PVC

    Um disco vinculado a um PersistentVolumeClaim (PVC) está apresentando alta latência de I/O.

    SLS

    event

    csi_latency_high

    sls.app.ack.csi.latency_too_high

    PersistentVolume em estado Failed

    Um PersistentVolume (PV) entrou em estado Failed, o que pode impedir que pods acessem o armazenamento.

    Alibaba Cloud Prometheus

    metric-prometheus

    pv-failed

    prom.pv.failed

    Regras de alerta para anomalias de rede do cluster

    Alerta

    Descrição

    Origem

    Tipo de regra

    Nome da regra CRD

    ID do evento

    Múltiplas tabelas de rotas VPC

    Múltiplas tabelas de rotas em uma VPC podem causar conflitos de roteamento. Otimize sua estrutura de rede.

    SLS

    event

    ccm-vpc-multi-route-err

    sls.app.ack.ccm.describe_route_tables_failed

    Nenhuma instância SLB disponível

    O cluster não consegue criar uma instância SLB, possivelmente devido a limites de cota ou permissões insuficientes.

    SLS

    event

    slb-no-ava

    sls.app.ack.ccm.no_ava_slb

    Falha na sincronização de SLB

    O cluster falhou ao sincronizar a configuração de uma instância SLB, o que pode causar roteamento ou configurações de backend desatualizados.

    SLS

    event

    slb-sync-err

    sls.app.ack.ccm.sync_slb_failed

    Falha na exclusão de SLB

    O cluster falhou ao excluir uma instância SLB, potencialmente deixando recursos órfãos.

    SLS

    event

    slb-del-err

    sls.app.ack.ccm.del_slb_failed

    Falha na criação de rota

    O cluster falhou ao criar uma rota necessária na tabela de rotas da VPC.

    SLS

    event

    route-create-err

    sls.app.ack.ccm.create_route_failed

    Falha na sincronização de rota

    O cluster falhou ao sincronizar uma rota na tabela de rotas da VPC.

    SLS

    event

    route-sync-err

    sls.app.ack.ccm.sync_route_failed

    Recurso Terway inválido

    Um recurso de rede inválido foi detectado no plugin CNI Terway.

    SLS

    event

    terway-invalid-res

    sls.app.ack.terway.invalid_resource

    Falha na alocação de IP do Terway

    O Terway falhou ao alocar um endereço IP para um pod, frequentemente devido ao esgotamento de IPs nas sub-redes configuradas.

    SLS

    event

    terway-alloc-ip-err

    sls.app.ack.terway.alloc_ip_fail

    Falha na análise de configuração de largura de banda de Ingress

    Ocorreu um erro de análise na anotação de largura de banda de ingress do cluster.

    SLS

    event

    terway-parse-err

    sls.app.ack.terway.parse_fail

    Falha na alocação de recursos do Terway

    O plugin CNI Terway falhou ao alocar um recurso de rede necessário.

    SLS

    event

    terway-alloc-res-err

    sls.app.ack.terway.allocate_failure

    Falha na recuperação de recursos do Terway

    O Terway falhou ao recuperar um recurso de rede após a exclusão de um pod.

    SLS

    event

    terway-dispose-err

    sls.app.ack.terway.dispose_failure

    Alteração de modo virtual do Terway

    O modo de rede virtual do Terway foi alterado.

    SLS

    event

    terway-virt-mod-err

    sls.app.ack.terway.virtual_mode_change

    Verificação de configuração de IP de pod do Terway

    O Terway iniciou uma verificação de configuração de IP de pod.

    SLS

    event

    terway-ip-check

    sls.app.ack.terway.config_check

    Falha no recarregamento de Ingress

    O controlador de ingress falhou ao recarregar sua configuração. Verifique se há erros de sintaxe.

    SLS

    event

    ingress-reload-err

    sls.app.ack.ingress.err_reload_nginx

    Regras de alerta para operações chave de auditoria do cluster

    Alerta

    Descrição

    Origem

    Rule_Type

    ACK_CR_Rule_Name

    SLS_Event_ID

    Execução de exec ou comando em contêiner

    Um usuário executou um comando ou fez login em um contêiner. Audite para rastrear manutenções e possíveis ameaças à segurança.

    SLS

    event

    audit-at-command

    sls.app.k8s.audit.at.command

    Alteração no status de agendamento de nó

    O status de agendamento de um nó mudou (cordoned ou uncordoned), o que pode afetar a eficiência do serviço e a carga de recursos.

    SLS

    event

    audit-cordon-switch

    sls.app.k8s.audit.at.cordon.uncordon

    Exclusão de recurso

    Um recurso do cluster foi excluído. Audite para investigar alterações planejadas ou atividades maliciosas.

    SLS

    event

    audit-resource-delete

    sls.app.k8s.audit.at.delete

    Drenagem ou evicção de nó

    Um nó foi drenado ou um pod foi despejado, indicando pressão de recursos ou manutenção planejada.

    SLS

    event

    audit-drain-eviction

    sls.app.k8s.audit.at.drain.eviction

    Login via rede pública

    Uma tentativa de login pela rede pública foi detectada. Revise as permissões de acesso e monitore atividades não autorizadas.

    SLS

    event

    audit-internet-login

    sls.app.k8s.audit.at.internet.login

    Atualização de rótulo de nó

    Um rótulo de nó foi atualizado. Alterações de rótulo afetam o agendamento de cargas de trabalho — verifique a correção para evitar comportamentos indesejados.

    SLS

    event

    audit-node-label-update

    sls.app.k8s.audit.at.label

    Atualização de taint de nó

    Um taint de nó foi adicionado, removido ou atualizado. Alterações de taint podem repelir pods sem tolerâncias correspondentes, interrompendo cargas de trabalho.

    SLS

    event

    audit-node-taint-update

    sls.app.k8s.audit.at.taint

    Modificação de recurso

    Um recurso do cluster foi modificado. Alterações frequentes ou inesperadas podem indicar desvio de configuração.

    SLS

    event

    audit-resource-update

    sls.app.k8s.audit.at.update

    Regras de alerta de segurança do cluster

    Alerta

    Descrição

    Origem

    Tipo de regra

    Nome da regra CRD

    ID do evento

    Configuração de alto risco encontrada

    Uma inspeção de segurança encontrou uma configuração de alto risco no cluster.

    SLS

    event

    si-c-a-risk

    sls.app.ack.si.config_audit_high_risk

    Regras de alerta para anomalias de inspeção do cluster

    Alerta

    Descrição

    Origem

    Tipo de regra

    Nome da regra ACK CR

    ID do evento SLS

    Anomalia na inspeção do cluster

    A inspeção automatizada detectou uma possível anomalia. Revise o problema e ajuste a manutenção conforme necessário.

    SLS

    event

    cis-sched-failed

    sls.app.ack.cis.schedule_task_failed

    Solucionar problemas de alertas

    Evicção de Pod devido a pressão de disco

    Mensagem de alerta

    (combined from similar events): Failed to garbage collect required amount of images. Attempted to free XXXX bytes, but only found 0 bytes eligible to free

    Sintomas

    O status do Pod é Evicted. O nó está sofrendo pressão de disco (The node had condition: [DiskPressure].).

    Causa

    Quando o uso de disco de um nó atinge o limiar de evicção (85% por padrão), o kubelet inicia a evicção baseada em pressão, executando a coleta de lixo de imagens e potencialmente despejando Pods. Faça login no nó alvo e execute df -h para verificar o uso do disco.

    Resolução

    1. Faça login no nó alvo (runtime containerd) e execute o seguinte comando para remover imagens não utilizadas:

      crictl rmi --prune

    2. Limpe logs ou expanda a capacidade de disco do nó.

    3. Ajuste os limiares relevantes.

    Recomendações e prevenção

    • Se um nó acionar este alerta frequentemente, avalie os requisitos de armazenamento da sua aplicação e planeje a capacidade de disco do nó adequadamente.

    • Monitore regularmente o uso de armazenamento através do Painel de monitoramento de armazenamento de nós.

    OOMKilling de Pod

    Mensagem de alerta

    pod was OOM killed. node:xxx pod:xxx namespace:xxx uuid:xxx

    Sintomas

    O status do Pod está anormal e os detalhes do evento contêm PodOOMKilling.

    Resolução

    Um evento de falta de memória (OOM) pode ser acionado no nível do nó ou no nível do cgroup do contêiner.

    • Causa:

      • OOM no nível de cgroup do contêiner: o uso de memória do Pod excede os limites configurados, fazendo com que o Kubernetes o encerre.

      • OOM no nível do nó: geralmente ocorre quando muitos Pods sem limites de recursos são executados no nó ou quando processos fora do Kubernetes consomem memória excessiva.

    • Diagnóstico: execute dmesg -T | grep -i "memory" no nó de destino. Se a saída contiver out_of_memory, ocorreu um evento OOM. Caso também inclua Memory cgroup, o OOM está no nível de cgroup do contêiner; caso contrário, está no nível do nó.

    • Ações recomendadas:

    Consulte Causas e soluções para eventos do OOM killer.

    Pod em CrashLoopBackOff

    Quando um processo dentro de um Pod é encerrado inesperadamente, o ACK o reinicia. Se o Pod falhar repetidamente em se estabilizar, ele entra no estado CrashLoopBackOff. Siga os passos abaixo para solucionar o problema:

    1. Faça login no console do ACK. No painel de navegação à esquerda, clique em Clusters.

    2. Na página Clusters, clique no nome do seu cluster. No painel de navegação à esquerda, clique em Workloads > Pods.

    3. Localize o Pod afetado e clique em Details na coluna Actions.

    4. Na aba Events, revise os detalhes de quaisquer eventos anormais.

    5. Verifique a aba Logs para identificar a causa da falha.

      Nota

      Se o Pod foi reiniciado, selecione Show the log of the last container exit.

      O console exibe apenas as 500 entradas mais recentes. Para logs mais antigos, configure a persistência de logs .