Todos os produtos
Search
Central de documentação

Managed Service for Prometheus:Criar uma regra de alerta do Prometheus

Última atualização: Jul 10, 2026

Crie uma regra de alerta do Prometheus para monitorar métricas específicas e acionar eventos de alerta quando condições definidas forem atendidas. Configure uma política de notificação para receber alertas por SMS, e-mail, chamadas telefônicas, DingTalk, WeCom ou webhooks.

Pré-requisitos

É necessária uma instância integrada do Prometheus. Para mais informações, consulte os seguintes tópicos:

Procedimento

  1. Faça login no console do ARMS.

  2. No painel de navegação à esquerda, escolha Prometheus Monitoring > Prometheus Alert Rules.

  3. Faça login no console do Managed Service for Prometheus.

  4. Clique em View Alert Rules.

  5. Na página Prometheus Alert Rules, clique em Create Prometheus Alert Rule.

Criar uma regra de alerta do Prometheus com base em um limiar estático

O tipo de verificação de limiar estático oferece métricas de alerta predefinidas. Selecione uma métrica para criar rapidamente uma regra de alerta.

  1. Na página Create Prometheus Alert Rule, defina os parâmetros a seguir.

    Parâmetro

    Descrição

    Exemplo

    Alert name

    Nome da regra de alerta.

    Cluster de produção - alerta de uso de CPU do contêiner

    Check type

    Selecione Static Threshold.

    Static Threshold

    Prometheus instance

    Selecione a instância do Prometheus para a qual deseja criar a regra de alerta.

    Cluster de produção

    Alert group

    Selecione um grupo de alertas.

    Diferentes tipos de Prometheus suportam grupos de alertas distintos. As opções disponíveis variam conforme o tipo de instância do Prometheus selecionado.

    Carga de trabalho do Kubernetes

    Alert metric

    Escolha a métrica para configurar o alerta. As métricas disponíveis dependem do grupo de alertas selecionado.

    Uso de CPU do contêiner

    Alert condition

    Defina as condições que acionam um evento de alerta.

    A condição de alerta é atendida quando o uso de CPU do contêiner é greater than 80%.

    Filter conditions

    Define o escopo da regra de alerta. Um evento de alerta é gerado apenas quando um recurso atende tanto às condições de filtro quanto às de alerta.

    As seguintes condições de filtro estão disponíveis:

    • Traverse: Aplica a regra de alerta a todos os recursos na instância atual do Prometheus. Esta é a condição padrão.

    • Equal To: Aplica a regra de alerta a um único recurso especificado. Não é possível especificar múltiplos recursos.

    • Not Equal To: Aplica a regra de alerta a todos os recursos, exceto ao especificado. Não é possível especificar múltiplos recursos.

    • Match Regular Expression: Aplica a regra de alerta a todos os recursos cujos nomes correspondem à expressão regular especificada.

    • Do Not Match Regular Expression: Aplica a regra de alerta a todos os recursos, exceto àqueles que correspondem à expressão regular especificada.

    Nota
    • Após configurar as condições de filtro, a seção Data Preview será exibida.

    • A condição de filtro não deve exceder 300 caracteres.

    Traverse

    Data preview

    A seção Data Preview exibe a consulta PromQL correspondente e um gráfico de série temporal da métrica.

    Por padrão, mostra o valor em tempo real de um único recurso. Utilize os filtros para visualizar diferentes recursos e intervalos de tempo.

    Nota
    • O limiar de alerta é representado por uma linha horizontal vermelha no gráfico. Os dados da série temporal que atingem o limiar aparecem em vermelho escuro, enquanto os dados abaixo do limiar são mostrados em azul.

    • Passe o mouse sobre a curva da série temporal para ver detalhes do recurso em um ponto específico no tempo.

    • Selecione um intervalo de tempo no gráfico para ampliar e visualizar a curva da série temporal correspondente.

    --

    Duration

    • Aciona um alerta se um único ponto de dados atingir o limiar.

    • Aciona um alerta apenas se a condição persistir por uma duração especificada (N minutos).

    O parâmetro de duração não suporta configurações subminuto (nível de segundos). Trata-se de uma limitação do mecanismo no nível do product, e não de um comportamento anormal.

    1

    Alert level

    Defina um nível de alerta personalizado. O nível padrão é Default. A severidade aumenta na ordem: Default, P4, P3, P2 até P1.

    Default

    Alert message

    Conteúdo da notificação. Use variáveis de modelo Go para personalizar a mensagem de alerta.

    Namespace: {{$labels.namespace}} / Pod: {{$labels.pod_name}} / Container: {{$labels.container}} CPU usage {{$labels.metrics_params_opt_label_value}} {{$labels.metrics_params_value}}%, Current value: {{ printf "%.2f" $value }}%

    Alert notification

    • Simple Mode: Permite configurar Notification Receiver, Notification Period e Whether to Resend Notifications.

    • Standard Mode:

      • Do Not Specify Notification Policy: Selecione esta opção para vincular este alerta a uma política de notificação posteriormente. Após criar a regra de alerta, acesse a página Notification Policies para criar uma política que corresponda a esta regra por nome ou outras condições. Para mais informações, consulte Políticas de notificação.

      • Selecionar uma política na lista suspensa: O ARMS adiciona automaticamente uma regra de correspondência à política de notificação selecionada. Essa regra utiliza o ID da regra de alerta (exibido como nome da regra) para garantir que os eventos de alerta desta regra sejam correspondidos pela política escolhida.

      Importante

      Especificar uma política de notificação aqui garante apenas que os eventos de alerta da regra atual sejam correspondidos pela política selecionada. Eventos desta regra também podem ser correspondidos por outras políticas que utilizem correspondência difusa. A relação entre regras de alerta e políticas de notificação é de muitos para muitos.

    Do Not Specify Notification Policy

    Advanced Settings

    Alert check cycle

    Intervalo de verificação em minutos. O mínimo e padrão é 1 minuto. Mesmo que você insira um valor inferior a 1 minuto (por exemplo, 15 segundos) na interface, o sistema ainda realizará verificações em intervalos de 1 minuto. Trata-se de uma limitação do mecanismo no nível do product, e não de um comportamento anormal.

    1

    Data Completion Check

    • Yes

    • No

    Yes

    Tags

    Tags da regra de alerta. As tags podem ser usadas como condições de correspondência nas políticas de notificação.

    --

    Annotations

    Anotações da regra de alerta.

    --

  2. Após concluir as configurações, clique em Save. A página de Regras de Alerta do Prometheus exibirá o status da regra de alerta atual.

    Se o Status da regra de alerta for Automatic Interruption, edite a regra com base no motivo fornecido para a interrupção e clique em Start. Em seguida, na caixa de diálogo exibida, clique em Confirm. Caso enfrente um problema de interrupção de regra que não consiga resolver, entre em contato com o service de alertas do ARMS no DingTalk (ID: d9j_rg9e4062f) para obter assistência.

    Uma regra de alerta pode ser interrompida automaticamente pelos seguintes motivos:

    • O número de resultados da consulta excede 1.500.

    • Nenhum objeto de notificação está configurado no Alert Management.

    • A instância do Prometheus foi desinstalada ou está indisponível.

Criar uma regra de alerta PromQL personalizada

Para monitorar métricas não cobertas pelas opções de limiar estático, utilize o tipo de verificação Custom PromQL.

  1. Na página Create Prometheus Alert Rule, defina os parâmetros a seguir.

    Parâmetro

    Descrição

    Exemplo

    Alert name

    Nome da regra de alerta.

    Uso de CPU do Pod superior a 8%

    Check type

    Defina como Custom PromQL.

    Custom PromQL

    Prometheus instance

    Selecione a instância do Prometheus para a qual deseja criar a regra de alerta.

    --

    Reference alert group

    Selecione um grupo de alertas.

    Diferentes tipos de Prometheus suportam grupos de alertas distintos. As opções disponíveis variam conforme o tipo de instância do Prometheus selecionado.

    Carga de trabalho do Kubernetes

    Reference metrics

    Opcional. As métricas de referência fornecem configurações Custom PromQL para métricas comuns. Selecione uma métrica semelhante para preencher a consulta e modifique-a conforme necessário.

    O parâmetro Reference Metrics filtra automaticamente as métricas de alerta suportadas com base no tipo de instância do Prometheus selecionado.

    Alerta de uso de disco do Pod

    Custom PromQL

    Expressão PromQL para a regra de alerta.

    max(container_fs_usage_bytes{pod!="", namespace!="arms-prom",namespace!="monitoring"}) by (pod_name, namespace, device)/max(container_fs_limit_bytes{pod!=""}) by (pod_name,namespace, device) * 100 > 90

    Data preview

    A seção Data Preview exibe a consulta PromQL correspondente e um gráfico de série temporal da métrica.

    Por padrão, mostra o valor em tempo real de um único recurso. Utilize os filtros para visualizar diferentes recursos e intervalos de tempo.

    Nota
    • Passe o mouse sobre a curva da série temporal para ver detalhes do recurso em um ponto específico no tempo.

    • Selecione um intervalo de tempo no gráfico para ampliar e visualizar a curva da série temporal correspondente.

    --

    Duration

    • Aciona um alerta se um único ponto de dados atingir o limiar.

    • Aciona um alerta apenas se a condição persistir por uma duração especificada (N minutos).

    O parâmetro de duração não suporta configurações subminuto (nível de segundos). Trata-se de uma limitação do mecanismo no nível do product, e não de um comportamento anormal.

    1

    Alert level

    Defina um nível de alerta personalizado. O nível padrão é Default. A severidade aumenta na ordem: Default, P4, P3, P2 até P1.

    Default

    Alert message

    Conteúdo da notificação. Use a sintaxe de modelo Go para personalizar a mensagem de alerta com variáveis de parâmetro.

    Exemplo (alerta de uso de disco): Namespace: {{$labels.namespace}}/Pod: {{$labels.pod_name}}/Disk device: {{$labels.device}} usage exceeds 90%, current value: {{ printf "%.2f" $value }}%

    Exemplo (alerta de reinicialização de Pod): Namespace: {{$labels.namespace}}/Pod: {{$labels.pod_name}} restarted more than {{ $labels.metrics_params_value}} times in {{$labels.metrics_params_time}} minutes, current restarts: {{ $value }}

    Utilize o modelo de alerta de reinicialização de Pod para gerar conteúdo de notificação legível em cenários de reinicialização de Pods.

    Namespace: {{$labels.namespace}}/Pod: {{$labels.pod_name}}/Disk device: {{$labels.device}} usage exceeds 90%, current value: {{ printf "%.2f" $value }}%

    Alert notification

    • Simple Mode: Permite configurar Notification Receiver, Notification Period e Whether to Resend Notifications.

    • Standard Mode:

      • Do Not Specify Notification Policy: Selecione esta opção para vincular este alerta a uma política de notificação posteriormente. Após criar a regra de alerta, acesse a página Notification Policies para criar uma política que corresponda a esta regra por nome ou outras condições. Para mais informações, consulte Políticas de notificação.

      • Selecionar uma política na lista suspensa: O ARMS adiciona automaticamente uma regra de correspondência à política de notificação selecionada. Essa regra utiliza o ID da regra de alerta (exibido como nome da regra) para garantir que os eventos de alerta desta regra sejam correspondidos pela política escolhida.

      Importante

      Especificar uma política de notificação aqui garante apenas que os eventos de alerta da regra atual sejam correspondidos pela política selecionada. Eventos desta regra também podem ser correspondidos por outras políticas que utilizem correspondência difusa. A relação entre regras de alerta e políticas de notificação é de muitos para muitos.

    Do Not Specify Notification Policy

    Advanced settings

    Alert check cycle

    Intervalo de verificação em minutos. O mínimo e padrão é 1 minuto. Mesmo que você insira um valor inferior a 1 minuto (por exemplo, 15 segundos) na interface, o sistema ainda realizará verificações em intervalos de 1 minuto. Trata-se de uma limitação do mecanismo no nível do product, e não de um comportamento anormal.

    1

    Data Completion Check

    • Yes

    • No

    Yes

    Tags

    Tags da regra de alerta. As tags podem ser usadas como condições de correspondência nas políticas de notificação.

    --

    Annotations

    Anotações da regra de alerta.

    --

  2. Clique em Save. A página de Regras de Alerta do Prometheus exibirá o status da regra de alerta atual.

    Se o Status da regra de alerta for Automatic Interruption, edite a regra com base no motivo fornecido, clique em Start e, em seguida, clique em Confirm na caixa de diálogo. Caso enfrente um problema que não consiga resolver, entre em contato com o service de alertas do ARMS no DingTalk (ID: d9j_rg9e4062f) para obter assistência.

    Uma regra de alerta pode ser interrompida automaticamente pelos seguintes motivos:

    • O número de resultados da consulta excede 1.500.

    • Nenhum objeto de notificação está configurado no Alert Management.

    • A instância do Prometheus foi desinstalada ou está indisponível.

Gerenciar regras de alerta

  • Para regras de limiar estático e Custom PromQL criadas no console do Managed Service for Prometheus, é possível executar ações como editar, iniciar, parar, excluir, copiar e visualizar eventos históricos de alerta.

  • Para regras originárias de outros services da Alibaba Cloud, visualize eventos históricos de alerta e navegue até a lista de alertas do service de source.

Perguntas frequentes

P1: Por que há atraso nas notificações de recuperação de alerta?

As notificações de recuperação de alerta podem sofrer atraso pelos seguintes motivos:

  1. Causa raiz: O sistema possui um mecanismo de atraso máximo tolerado. Para evitar perda de alertas causada por atrasos nos relatórios do Agent, o mecanismo de alerta analisa os últimos 10 minutos de dados em cada verificação. Mesmo que as métricas não atendam mais à condição de alerta, o sistema aguarda o fim da janela de análise retrospectiva antes de confirmar a recuperação.

  2. Temporização: As notificações de recuperação geralmente são enviadas aproximadamente 10 minutos após os dados pararem de acionar o alerta.

  3. Nota sobre o mecanismo: O Prometheus em si não possui lógica automática de recuperação integrada. O ARMS depende de seu próprio mecanismo de detecção para determinar quando um alerta foi recuperado.

P2: O que fazer se a política de notificação for perdida após aplicar um modelo de regra de alerta?

  1. Causa raiz: Modelos de regras de alerta não contêm configurações de política de notificação. Reaplicar um modelo pode alterar o ID da regra, o que invalida a correspondência original da política de notificação baseada em _aliyun_arms_alert_rule_id.

  2. Solução: Acesse Alert Management > Notification Policy, localize a política correspondente e atualize as Dispatch Conditions para usar rótulos mais estáveis — como alertname ou o nome do cluster cluster — em vez do ID da regra para correspondência.

P3: O que fazer se eu continuar recebendo alertas duplicados após alterar a expressão de alerta para increase?

  1. Causa raiz: Se a política de notificação estiver configurada com "Repetir notificação a cada N minutos" combinado com "Recuperação manual", o sistema gera continuamente novos eventos de alerta enquanto as métricas continuarem atendendo à nova condição da expressão.

  2. Solução: Modifique a política de notificação para alterar a configuração de repetição para "Apenas primeira notificação" ou mude para o modo "Recuperação automática". Confirme também se a nova expressão foi salva corretamente e está em vigor.

P4: Como solucionar problemas quando uma regra de alerta do Prometheus não mostra dados ou não é acionada?

Siga estas etapas:

  1. Verificar componentes: Confirme se o cluster ACK tem o componente kube-state-metrics instalado; instale-o se estiver ausente. Verifique o status do componente Prometheus e reinstale o componente ack-arms-prometheus se necessário.

  2. Verificar registros de acionamento: Clique em Alert History ao lado da regra para verificar se há registros.

    • Sem registros: As condições da regra nunca foram atendidas. Causas comuns incluem nomes de métricas incorretos, dados vazios ou intervalo de tempo de consulta errado.

    • Registros existem, mas nenhuma notificação enviada: Verifique se as regras de despacho da política de notificação (rótulos, nome do cluster, etc.) correspondem à regra de alerta.

  3. Recomendação: Utilize os modelos de alerta mais recentes verificados pela Alibaba Cloud para evitar falsos positivos ou falhas de acionamento decorrentes de modelos antigos.

  4. Verificação de sintaxe: Se a página exibir um erro, confirme se a sintaxe regex do PromQL é válida. Por exemplo, {pvc=~} (regex vazia) causa erro; altere para {pvc=~".*"} ou especifique um valor concreto.

P5: O monitoramento de memória de Pod pelo Prometheus para clusters ACS é gratuito?

Clusters ACS suportam monitoramento e alertas de métricas de memória de Pod. Alertas por SMS e chamadas de voz incorrem em cobranças adicionais, mas alertas via bot do DingTalk e Webhook são gratuitos.