Todos os produtos
Search

Este produto

    Container Service for Kubernetes:Configure alert rules with Prometheus

    Central de documentação

    Container Service for Kubernetes:Configure alert rules with Prometheus

    Última atualização: Oct 15, 2026

    Escreva regras de alerta personalizadas em PromQL para monitorar nós do cluster, hosts, réplicas de contêiner e cargas de trabalho.

    Pré-requisitos

    Antes de começar, verifique se você tem:

    Configurar regras de alerta com PromQL personalizado

    Tanto o Alibaba Cloud Prometheus quanto o Prometheus de código aberto suportam regras de alerta personalizadas baseadas em PromQL, que acionam notificações ao atender às condições.

    Alibaba Cloud Prometheus

    Para criar uma regra de alerta do Prometheus usando PromQL personalizado, consulte Create a Prometheus alert rule.

    Prometheus de código aberto

    1. Configure uma política de notificação de alerta. O Prometheus de código aberto suporta webhooks, DingTalk e e-mail. Defina o método de notificação por meio do parâmetro receiver no ack-prometheus-operator. Consulte Alerting configuration.

    2. Crie uma regra de alerta. Implante um CRD PrometheusRule no cluster para definir as regras de alerta (consulte Deploying Prometheus rules). O exemplo a seguir dispara quando o uso de CPU do nó excede 90% em uma janela de 2 minutos. O campo expr especifica a expressão PromQL e a condição de acionamento.

      apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  labels:
    # Labels must match ruleSelector.matchLabels in the Prometheus CRD.
    prometheus: example
    role: alert-rules
  name: prometheus-example-rules
spec:
  groups:
  - name: example.rules
    rules:
    - alert: ExampleAlert
      # expr: PromQL query and trigger condition.
      # Refer to the PromQL configuration column in the alert rule tables below.
      expr: 100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[2m])) * 100) > 90

    3. Verifique se a regra de alerta está ativa.

      1. Execute o seguinte comando para encaminhar o service do Prometheus para a porta 9090 na sua máquina local: kubectl port-forward svc/ack-prometheus-operator-prometheus 9090:9090 -n monitoring

      2. Abra localhost:9090 no seu navegador.

      3. Escolha Status > Rules. Se a regra de alerta aparecer na página Rules, ela está ativa.

    Referência de regras de alerta

    O ACK fornece regras de alerta recomendadas com base na experiência em O&M, abrangendo a estabilidade do cluster, o uso de recursos de nós e hosts, réplicas de contêiner, cargas de trabalho, armazenamento e rede.

    Níveis de severidade:

    • Critical: Afeta o cluster, o aplicativo ou os negócios. Requer ação imediata.

    • Warning: Afeta o cluster, o aplicativo ou os negócios. Investigue prontamente.

    • Normal: Indica uma alteração importante em um recurso.

    A coluna Rule description usa a aba Alert Rules na página Alerts como ponto de entrada. Para acessar: acesse o ACK console , clique em seu cluster na lista Clusters e, em seguida, escolha Operations > Alerts > Alert Rules .

    Réplicas de contêiner anormais

    Descrição

    Severidade

    PromQL

    Limiar

    Janela

    Descrição da regra

    Solução de problemas

    Status anormal do pod

    Critical

    min_over_time(sum by (namespace, pod, phase) (kube_pod_status_phase{phase=~"Pending|Unknown|Failed"})[5m:1m]) > 0

    > 0

    5 min

    Dispara quando um pod permanece no status Pending, Unknown ou Failed por 5 minutos. Configure por meio de Alert Rule Set for Pod Exceptions > Pod anomaly. Consulte Manage alerts in ACK.

    Consulte Troubleshoot pod exceptions.

    Falha na inicialização do pod

    Critical

    sum_over_time(increase(kube_pod_container_status_restarts_total{}[1m])[5m:1m]) > 3

    > 3 reinicializações

    5 min

    Dispara quando um pod reinicia mais de 3 vezes em 5 minutos. Configure por meio de Alert Rule Set for Pod Exceptions > Pod startup failures. Consulte Manage alerts in ACK.

    Consulte Troubleshoot pod exceptions.

    Mais de 1.000 pods com falha de agendamento por 10 minutos contínuos

    Critical

    count((min_over_time(kube_pod_status_phase{phase="Pending"}[10m]) == 1) and (count_over_time(kube_pod_status_phase{phase="Pending"}[10m:15s]) >= (10 * 4 - 1))) > 1000

    > 1.000 pods

    10 min

    Dispara quando mais de 1.000 pods permanecem no estado Pending devido a falhas de agendamento por mais de 10 minutos contínuos.

    Pode indicar pressão excessiva de agendamento. O ACK Pro Edition fornece agendamento aprimorado e um SLA. Consulte Overview of ACK managed cluster Pro Edition.

    Throttling frequente de CPU do contêiner

    Warning

    rate(container_cpu_cfs_throttled_seconds_total[3m]) * 100 > 25

    > 25% de tempo com throttling

    3 min

    Dispara quando o tempo de CPU com throttling excede 25% em 3 minutos. O throttling reduz as fatias de tempo, aumentando o tempo de execução do processo e desacelerando a lógica do aplicativo.

    Verifique se o resource limit de CPU do pod está muito baixo. Reduza o throttling com a CPU Burst policy. Em nós multi-core, use a CPU topology-aware scheduling para maximizar os recursos de CPU fragmentados.

    Uso de CPU do pod > 85% do limite

    Warning

    (sum(irate(container_cpu_usage_seconds_total{pod=~"{{PodName}}.*",namespace=~"{{Namespace}}.*",container!="",container!="POD"}[1m])) by (namespace,pod) / sum(container_spec_cpu_quota{pod=~"{{PodName}}.*",namespace=~"{{Namespace}}.*",container!="",container!="POD"}/100000) by (namespace,pod) * 100 <= 100 or on() vector(0)) >= 85

    >= 85% do limite do pod

    1 min

    Dispara quando o uso de CPU do pod excede 85% do seu limite. Sem efeito se não houver um limite configurado. Limiar padrão: 85% — ajuste conforme necessário. Para filtrar, substitua pod=~"{{PodName}}.*",namespace=~"{{Namespace}}.*" pelos valores reais; remova o filtro para consultar todos os pods.

    O alto uso de CPU causa throttling e reduz as fatias de tempo. Verifique se o resource limit de CPU está muito baixo. Consulte Enable the CPU Burst policy e Enable CPU topology-aware scheduling.

    Uso de memória do pod > 85% do limite

    Warning

    ((sum(container_memory_working_set_bytes{pod=~"{{PodName}}.*",namespace=~"{{Namespace}}.*",container!="",container!="POD"}) by (pod,namespace) / sum(container_spec_memory_limit_bytes{pod=~"{{PodName}}.*",namespace=~"{{Namespace}}.*",container!="",container!="POD"}) by (pod, namespace) * 100) <= 100 or on() vector(0)) >= 85

    >= 85% do limite do pod

    —

    Dispara quando o uso de memória do pod excede 85% do seu limite. Sem efeito se não houver um limite configurado. Limiar padrão: 85% — ajuste conforme necessário.

    O alto uso de memória pode causar OOM kills e reinicializações do pod. Verifique se o resource limit de memória está muito baixo. Dimensione os limites corretamente com Resource profiling.

    Cargas de trabalho anormais

    Descrição

    Severidade

    PromQL

    Limiar

    Janela

    Descrição da regra

    Solução de problemas

    Incompatibilidade de réplicas do Deployment

    Critical

    kube_deployment_spec_replicas{} != kube_deployment_status_replicas_available{}

    Qualquer incompatibilidade

    —

    Dispara quando as réplicas disponíveis do Deployment não correspondem à contagem desejada. Configure por meio de Alert Rule Set for Workload Exceptions > Deployment pod anomaly. Consulte Manage alerts in ACK.

    Consulte Troubleshoot pod exceptions.

    Incompatibilidade de réplicas do DaemonSet

    Critical

    ((100 - kube_daemonset_status_number_ready{} / kube_daemonset_status_desired_number_scheduled{} * 100) or (kube_daemonset_status_desired_number_scheduled{} - kube_daemonset_status_current_number_scheduled{})) > 0

    > 0

    —

    Dispara quando as réplicas disponíveis do DaemonSet não correspondem à contagem desejada. Configure por meio de Alert Rule Set for Workload Exceptions > DaemonSet pod anomaly. Consulte Manage alerts in ACK.

    Consulte Troubleshoot pod exceptions.

    Erro de agendamento do DaemonSet

    Critical

    kube_daemonset_status_number_misscheduled{job} > 0

    > 0

    —

    Dispara quando uma réplica do DaemonSet é executada em um nó incorreto. Configure por meio de Alert Rule Set for Workload Exceptions > DaemonSet pod scheduling errors. Consulte Manage alerts in ACK.

    Consulte Troubleshoot pod exceptions.

    Falha no Job

    Critical

    kube_job_status_failed{} > 0

    > 0

    —

    Dispara quando um Job falha. Configure por meio de Alert Rule Set for Workload Exceptions > Job execution failures. Consulte Manage alerts in ACK.

    Verifique os logs do pod com falha para obter detalhes do erro. Consulte Troubleshoot pod exceptions.

    Exceções de armazenamento

    Descrição

    Severidade

    PromQL

    Limiar

    Janela

    Descrição da regra

    Solução de problemas

    Status anormal do PersistentVolume (PV)

    Critical

    kube_persistentvolume_status_phase{phase=~"Failed|Pending"} > 0

    > 0

    —

    Dispara quando um PV entra no estado Failed ou Pending. Configure por meio de Alert Rule Set for Storage Exceptions > PV anomaly. Consulte Manage alerts in ACK.

    Consulte a seção de montagem de disco em FAQ about disk PVs.

    Uso de disco do host > 85%

    Critical

    (100 - node_filesystem_avail_bytes / node_filesystem_size_bytes * 100) >= 85

    >= 85%

    —

    Dispara quando o espaço livre em disco do nó é inferior a 15%. Configure por meio de Alert Rule Set for Resource Exceptions > Node - Disk usage >= 85%. Consulte Manage alerts in ACK.

    Escale o nó horizontalmente ou expanda seu disco. Consulte FAQ about disk PVs.

    Status anormal do nó

    Descrição

    Severidade

    PromQL

    Limiar

    Janela

    Descrição da regra

    Solução de problemas

    Nó NotReady por 3 minutos

    Critical

    (sum(max_over_time(kube_node_status_condition{condition="Ready",status="true"}[3m]) <= 0) by (node)) or (absent(kube_node_status_condition{condition="Ready",status="true"})) > 0

    > 0

    3 min

    Dispara quando um nó permanece no estado NotReady por 3 minutos. Configure por meio de Alert Rule Set for Node Exceptions > Node changes to the unschedulable state. Consulte Manage alerts in ACK.

    Determine se o estado NotReady é esperado (por exemplo, substituição ou manutenção do nó). Se for inesperado, verifique se os pods do aplicativo foram afetados e evacue-os se necessário. Verifique as condições do nó para causas como pressão de memória ou disco cheio.

    Uso anormal de recursos do host

    As métricas de recursos do host medem os recursos da máquina física ou virtual. Uso = uso de recursos de todos os processos / capacidade máxima do host.
    Descrição Severidade PromQL Limiar Janela Descrição da regra Solução de problemas
    Uso de memória do host > 85% Warning (100 - node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes * 100) >= 85 >= 85% — Dispara quando o uso de memória do host excede 85%. Configure por meio de Alert Rule Set for Resource Exceptions > Node - Memory usage >= 85% . Consulte Manage alerts in ACK . Limiar padrão: 85% — ajuste conforme necessário.
    Nota

    As regras de alerta do ACK são fornecidas pelo Cloud Monitor, com métricas consistentes com as regras do Prometheus.

    		 Libere recursos: verifique a alocação de recursos do pod com cost analysis e dimensione corretamente as solicitações de memória com resource profiling. Escale os nós horizontalmente — consulte Scale nodes in an ACK cluster.
    Uso de memória do host > 90% Critical (100 - node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes * 100) >= 90 >= 90% — Dispara quando o uso de memória do host excede 90%. Libere recursos com cost analysis e resource profiling. Escale os nós horizontalmente — consulte Scale nodes in an ACK cluster.
    Uso de CPU do host > 85% Warning 100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[2m])) * 100) >= 85 >= 85% 2 min Dispara quando o uso de CPU do host excede 85%. Configure por meio de Alert Rule Set for Resource Exceptions > Node - CPU usage >= 85% .
    Nota

    O ACK usa métricas do CloudMonitor ECS, equivalentes a esta regra do Prometheus. Limiar padrão: 85% — ajuste conforme necessário. Consulte Manage alerts in ACK.

    		 Libere recursos com cost analysis e resource profiling. Escale os nós horizontalmente — consulte Scale nodes in an ACK cluster.
    Uso de CPU do host > 90% Critical 100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[2m])) * 100) >= 90 >= 90% 2 min Dispara quando o uso de CPU do host excede 90%. Libere recursos com cost analysis e resource profiling. Escale os nós horizontalmente — consulte Scale nodes in an ACK cluster.

    Recursos anormais do nó

    As métricas de recursos do nó medem o consumo de recursos do contêiner em relação à capacidade alocável do nó, e não à capacidade da máquina física.
    Recursos consumidos (numerador) : Total de recursos de todos os contêineres no nó, incluindo memória do conjunto de trabalho (working set), cache de página, entre outros.
    Recursos alocáveis (denominador) : Recursos disponíveis para contêineres após subtrair as reservas do nó. Consulte Node resource reservation policy .
    O agendamento de pods é baseado em solicitações de recursos, e não no uso real.

    Descrição

    Severidade

    PromQL

    Limiar

    Janela

    Descrição da regra

    Solução de problemas

    Uso de CPU do nó > 85%

    Warning

    sum(irate(container_cpu_usage_seconds_total{pod!=""}[1m])) by (node) / sum(kube_node_status_allocatable{resource="cpu"}) by (node) * 100 >= 85

    >= 85%

    1 min

    Dispara quando o uso de CPU do nó excede 85% dos recursos alocáveis. Fórmula: Uso de recursos do nó / Total de recursos alocáveis no nó.

    Libere recursos com cost analysis e resource profiling para distribuir pods entre os nós. Escale os nós horizontalmente — consulte Scale nodes in an ACK cluster.

    Taxa de alocação de recursos de CPU do nó > 85%

    Normal

    (sum(sum(kube_pod_container_resource_requests{resource="cpu"}) by (pod, node) * on (pod) group_left max(kube_pod_status_ready{condition="true"}) by (pod, node)) by (node)) / sum(kube_node_status_allocatable{resource="cpu"}) by (node) * 100 >= 85

    >= 85%

    —

    Dispara quando a taxa de alocação de recursos de CPU excede 85% dos recursos alocáveis. Fórmula: Total de solicitações de recursos de pods agendados / Total de recursos alocáveis no nó.

    Recursos insuficientes para agendar mais pods. Verifique se há desperdício de recursos (uso real muito abaixo das solicitações) com cost analysis e resource profiling. Escale os nós horizontalmente — consulte Scale nodes in an ACK cluster.

    Taxa de overselling de CPU do nó > 300%

    Warning

    (sum(sum(kube_pod_container_resource_limits{resource="cpu"}) by (pod, node) * on (pod) group_left max(kube_pod_status_ready{condition="true"}) by (pod, node)) by (node)) / sum(kube_node_status_allocatable{resource="cpu"}) by (node) * 100 >= 300

    >= 300%

    —

    Dispara quando a taxa de overselling de CPU excede 300% dos recursos alocáveis. Fórmula: Total de limites de recursos de pods agendados / Total de recursos alocáveis no nó. O limiar de 300% é o padrão recomendado — ajuste conforme necessário.

    Os limites totais de CPU excedem em muito os recursos alocáveis. Durante picos de tráfego, a contenção e o throttling podem desacelerar as respostas. Dimensione corretamente as solicitações e limites de CPU com cost analysis e resource profiling. Escale os nós horizontalmente — consulte Scale nodes in an ACK cluster.

    Uso de memória do nó > 85%

    Warning

    sum(container_memory_working_set_bytes{pod!=""}) by (node) / sum(kube_node_status_allocatable{resource="memory"}) by (node) * 100 >= 85

    >= 85%

    —

    Dispara quando o uso de memória do nó excede 85% dos recursos alocáveis. Fórmula: Uso de recursos do nó / Total de recursos alocáveis no nó.

    Libere recursos com cost analysis e resource profiling para distribuir pods entre os nós. Escale os nós horizontalmente — consulte Scale nodes in an ACK cluster.

    Taxa de alocação de recursos de memória do nó > 85%

    Normal

    (sum(sum(kube_pod_container_resource_requests{resource="memory"}) by (pod, node) * on (pod) group_left max(kube_pod_status_ready{condition="true"}) by (pod, node)) by (node)) / sum(kube_node_status_allocatable{resource="memory"}) by (node) * 100 >= 85

    >= 85%

    —

    Dispara quando a taxa de alocação de recursos de memória excede 85% dos recursos alocáveis. Fórmula: Total de solicitações de recursos de pods agendados / Total de recursos alocáveis no nó.

    Recursos insuficientes para agendar mais pods. Verifique se há desperdício de recursos (uso real muito abaixo das solicitações) com cost analysis e resource profiling. Escale os nós horizontalmente — consulte Scale nodes in an ACK cluster.

    Taxa de overselling de memória do nó > 300%

    Warning

    (sum(sum(kube_pod_container_resource_limits{resource="memory"}) by (pod, node) * on (pod) group_left max(kube_pod_status_ready{condition="true"}) by (pod, node)) by (node)) / sum(kube_node_status_allocatable{resource="memory"}) by (node) * 100 >= 300

    >= 300%

    —

    Dispara quando a taxa de overselling de memória excede 300% dos recursos alocáveis. Fórmula: Total de limites de recursos de pods agendados / Total de recursos alocáveis no nó. O limiar de 300% é o padrão recomendado — ajuste conforme necessário.

    Os limites totais de memória excedem em muito os recursos alocáveis. Durante picos de tráfego, a memória pode atingir o limite do nó, causando OOM kills que interrompem as cargas de trabalho. Dimensione corretamente as solicitações e limites de memória com cost analysis e resource profiling. Escale os nós horizontalmente — consulte Scale nodes in an ACK cluster.

    Exceções de rede

    Descrição

    Severidade

    PromQL

    Limiar

    Janela

    Descrição da regra

    Solução de problemas

    A contagem de solicitações do CoreDNS cai para zero

    Critical

    (sum(rate(coredns_dns_request_count_total{}[1m]))by(server,zone)<=0) or (sum(rate(coredns_dns_requests_total{}[1m]))by(server,zone)<=0)

    <= 0

    1 min

    Detectável apenas em clusters gerenciados pelo ACK (edições Pro e Basic).

    Verifique se os pods do CoreDNS no cluster estão sendo executados normalmente.

    Exceção de panic do CoreDNS

    Critical

    sum(rate(coredns_panic_count_total{}[3m])) &gt; 0

    > 0

    3 min

    Detectável apenas em clusters gerenciados pelo ACK (edições Pro e Basic).

    Verifique se os pods do CoreDNS no cluster estão sendo executados normalmente.

    Certificado do Ingress controller expirando em 14 dias

    Warning

    ((nginx_ingress_controller_ssl_expire_time_seconds - time()) / 24 / 3600) &lt; 14

    < 14 dias

    —

    Requer que o componente ACK Ingress controller esteja instalado com o recurso Ingress ativado.

    Reemita o certificado do Ingress controller.

    Exceções do Auto Scaling

    Descrição Severidade PromQL Limiar Janela Descrição da regra Solução de problemas
    Contagem de réplicas do HPA no máximo Warning max(kube_horizontalpodautoscaler_spec_max_replicas) by (namespace, horizontalpodautoscaler) - max(kube_horizontalpodautoscaler_status_current_replicas) by (namespace, horizontalpodautoscaler) <= 0 <= 0 de diferença — Dispara quando as réplicas atuais do HPA atingem o máximo configurado.
    Nota

    Ative primeiro as métricas do horizontalpodautoscaler no Alibaba Cloud Prometheus — desativadas por padrão, sem custo.

    		 Verifique se a política do HPA atende às expectativas. Se a carga de trabalho permanecer alta, aumente maxReplicas ou otimize o desempenho do aplicativo.

    Próximos passos