Todos os produtos
Search
Central de documentação

Managed Service for Prometheus:Políticas de notificação

Última atualização: Sep 08, 2026

As políticas de notificação definem as condições para o envio de alertas. Quando um evento de alerta atende a esses critérios, o sistema notifica os destinatários especificados para que tomem as medidas necessárias.

Pré-requisitos

É necessário criar um contato antes de adicioná-lo a uma política de notificação. Para mais informações, consulte {{XREF_0}}.

Criar uma política de notificação

  1. Faça login no console do Managed Service for Prometheus. No painel de navegação à esquerda, escolha Alert Management > Notification Policies.

  2. Na página Notification Policies, clique em Create Notification Policy.

  3. No topo da página Create Notification Policy, insira um nome para a política.

  4. Na seção Matching Rule, defina as regras de correspondência para eventos de alerta.

    Importante

    Uma política de silêncio tem precedência sobre uma política de notificação. Se um evento de alerta corresponder a uma política de silêncio, ele será silenciado e não avaliado por nenhuma política de notificação. Para criar uma política de silêncio, consulte {{XREF_1}}.

    1. Selecione uma source de dados.

      • Specific source: Filtra eventos de alerta de uma integração específica.

      • No preset source: Filtra eventos de alerta de todas as integrações.

    2. Defina as expressões da regra de correspondência. É possível usar tags personalizadas ou selecionar tags existentes.

      As tags existentes incluem:

      • Tags provenientes das métricas em uma expressão de regra de alerta. Para saber como criar tags para uma regra de alerta do Managed Service for Prometheus, consulte {{XREF_2}}.

      • O sistema ARMS fornece as seguintes tags padrão.

        Categoria

        Tag

        Descrição

        Campos comuns

        alertname

        Nome do alerta.

        clustername

        Nome do cluster.

        severity

        Nível de severidade:

        • P1

        • P2

        • P3

        • P4

        • Default

        namespace

        namespace.

        pod_name

        Nome do Pod.

        Campos predefinidos do sistema

        _aliyun_arms_integration_name

        Nome da integração. O nome padrão da integração para alertas reportados pelo ARMS é ARMS-DEFAULT.

        _aliyun_arms_involvedObject_id

        ID do objeto de alerta.

        _aliyun_arms_involvedObject_name

        Nome do objeto de alerta.

        _aliyun_arms_region_id

        ID da região.

        _aliyun_arms_alert_rule_id

        ID da regra de alerta.

        _aliyun_arms_alert_type

        Tipo de regra de alerta:

        • 101: Alerta do Prometheus

        • 5: Alerta do Application Monitoring

        • 4: Alerta do Browser Monitoring

        _arms_contact_group_v2_id

        ID do grupo de contatos (v2) para notificações de alerta. O ARMS adiciona essa tag automaticamente às tags do evento de alerta. Seu valor corresponde ao identificador do grupo de contatos v2 exibido na página Alarm Management > Notification Objects > Contact Group no console. Quando uma política de notificação é criada automaticamente via integração com ACK, essa tag é usada para corresponder à política sem necessidade de configuração manual. Esta tag difere da ContactGroupId v1 retornada pela API. Ela fica visível no campo commonLabels do payload de notificação do webhook.

      Comportamento de exibição de tags

      As tags exibidas na página de análise de eventos de alerta originam-se dos rótulos de métrica da regra de alerta acionada e dos campos predefinidos do sistema. Diferentes eventos de alerta podem conter campos de tag distintos, pois as regras envolvidas associam-se a métricas e tipos de recursos variados. Eventos que não possuem um determinado campo não exibirão a tag correspondente. Portanto, é normal que algumas tags apareçam em um evento e não em outro; isso não indica erro do sistema.

      Por exemplo, um evento só contém a tag pod_name quando o alerta envolve um recurso Pod. Alertas que não envolvem Pods não exibem essa tag.

      Nota
      • Para exigir que um alerta corresponda a todas as condições de uma regra (lógica AND), clique em Add Condition.

      • Para exigir que um alerta corresponda a qualquer regra (lógica OR), clique em Add Rule para criar uma nova regra.

      • O tamanho total da configuração de todas as regras de correspondência em uma política de notificação não pode exceder 64 KB. Esse limite comporta aproximadamente 100 regras, dependendo da complexidade. Exceder esse limite causa falha na configuração. Para evitar isso, crie uma nova política de notificação para regras adicionais.

      Nota

      Quando uma política de notificação contém regras de correspondência baseadas em dimensões de cluster ou objeto — por exemplo, usando o rótulo _aliyun_arms_involvedObject_id para corresponder a um ID de cluster Kubernetes — as regras de alerta associadas ao cluster ou objeto correspondente são vinculadas automaticamente à política de notificação. Não é necessário configurar uma política de notificação em cada regra de alerta individualmente.

      Isso é especialmente útil em cenários em massa, como regras de alerta criadas automaticamente pelo Container Service for Kubernetes (ACK). Basta configurar regras de correspondência baseadas em rótulos na política de notificação para associar automaticamente todas as regras de alerta relevantes de uma vez, sem precisar editá-las individualmente.

      As regras de alerta criadas automaticamente por um cluster ACK carregam a tag gerada pelo sistema _arms_contact_group_v2_id, cujo valor é um ID de grupo de contatos. As políticas de notificação usam essa tag para corresponder às regras e rotear as notificações de alerta para o grupo de contatos especificado. O valor da tag corresponde ao ID do grupo de contatos exibido na página Alarm Management > Notification Objects > Contact Group no console do ARMS. Essa tag é gerada automaticamente pelo sistema e não precisa ser adicionada manualmente.

    3. Clique em Next.

  5. Na seção Event Group, configure o agrupamento dos eventos de alerta e clique em Next.

    • Do not group: Cada evento de alerta é enviado como uma notificação separada.

    • Set grouping fields: Agrupa eventos de alerta com valores idênticos nos campos especificados em uma única notificação.

  6. Na seção Notification Objects, configure os seguintes parâmetros.

    1. Clique em +Add Notification Recipient para selecionar um destinatário de notificação.

      Tipos de destinatários de notificação:

      • Contact: Selecione também um método de notificação (ligação telefônica, mensagem de texto ou e-mail) para o contato escolhido.

      • Contact Group: Selecione também um método de notificação (ligação telefônica, mensagem de texto ou e-mail) para o grupo de contatos escolhido.

      • On-call Schedule: Selecione também um método de notificação (ligação telefônica, mensagem de texto ou e-mail) para a escala de plantão escolhida.

      • DingTalk/Lark/WeCom: Envia notificações para um canal do DingTalk, Lark ou WeCom.

      • General Webhook: Envia notificações para uma URL de webhook especificada.

    2. Escolha se deseja enviar uma notificação de recuperação após a resolução do alerta.

      Send recovery notification: Quando ativado, envia uma notificação de recuperação após a resolução de todos os eventos de um alerta, marcando-o automaticamente como Resolvido.

    3. Defina um modelo de notificação. Para mais informações, consulte {{XREF_3}}.

    4. Defina um período de notificação para enviar alertas apenas dentro da janela de tempo especificada.

    5. Opcional: Selecione um sistema de tickets para encaminhar os alertas. Para detalhes sobre como integrar um sistema de tickets, consulte {{XREF_4}}.

    6. Clique em Next.

  7. Na seção Repeat/escalation/recovery policy, configure as políticas para alertas não resolvidos. É possível definir repetição de notificações, aplicar uma política de escalonamento ou exigir recuperação manual. Em seguida, clique em Next.

    • Sem a configuração de uma política de escalonamento, o sistema envia apenas uma notificação para um alerta não resolvido.

    • Repeat notifications: Defina uma frequência. Caso o alerta não seja resolvido, as notificações serão reenviadas no intervalo especificado até a resolução.

    • Escalation policy: Selecione uma política. Se o alerta permanecer sem resolução, o sistema enviará notificações a destinatários adicionais conforme a política de escalonamento escolhida.

    • Manual recovery: Ao ativar esta opção, o alerta não será resolvido automaticamente mesmo que nenhum novo evento seja acionado dentro do período de resolução automática definido na integração de alertas. A alteração do status do alerta deverá ser feita manualmente.

  8. Na seção Action Integration, configure uma integração de ação para execução automática.

    Ao ativar esta opção, selecione as integrações de ação a serem executadas quando um alerta for acionado e quando for resolvido. O sistema as executará automaticamente.

  9. Clique em Save para criar a política.

Gerenciar políticas de notificação

Após a criação, a política de notificação aparece na página Notification Policies. Na página Notification Policies, você pode realizar as seguintes operações:

  • Editar uma política de notificação: Clique no nome da política ou em Edit na coluna Actions. Após fazer as alterações, clique em Save.

  • Ativar ou desativar uma política de notificação: Na coluna Status, alterne o botão.

  • Excluir uma política de notificação: Clique em Delete na coluna Actions e confirme clicando em Confirm.

  • Copiar uma política de notificação: Clique em Copy na coluna Actions para duplicar a política.