Application Real-Time Monitoring Service:Políticas de notificação

Pré-requisitos

Você já criou destinatários de notificação. Para mais informações, consulte Gerencie notification recipients.

Criar uma política de notificação

1. Faça login no ARMS console. No painel de navegação à esquerda, escolha Alert Management > Notification Policies.

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

3. Na parte superior 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 os eventos de alerta.

   Importante

   Uma política de silêncio tem precedência sobre uma política de notificação. Eventos de alerta que correspondem a uma política de silêncio são silenciados e não são avaliados por nenhuma política de notificação. Para crie uma política de silêncio, consulte Silence policies.

   1. Selecione uma fonte 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 das regras de correspondência. Use tags personalizadas ou selecione entre as tags existentes.

      As tags existentes incluem:

      • Tags provenientes das métricas em uma expressão de regra de alerta. Para saber como crie tags para uma regra de alerta do Managed Service for Prometheus, consulte Create a Prometheus alert rule.

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

        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 para alertas reportados pelo ARMS é ARMS-DEFAULT.
        	_aliyun_arms_involvedObject_id	ID do objeto do alerta.
        	_aliyun_arms_involvedObject_name	Nome do objeto do 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
        Outros campos	_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 por meio da integração com o ACK, essa tag é usada para associar a política sem nenhuma configuração manual. Ela difere do ContactGroupId v1 retornado pela API e fica visível no campo commonLabels do payload de notificação via webhook.

      Comportamento de exibição das tags

      As tags exibidas na página de análise de eventos de alerta são provenientes dos rótulos de métricas carregados pela regra de alerta acionada e dos campos predefinidos pelo sistema. Eventos de alerta distintos podem conter campos de tag diferentes, pois as regras de alerta envolvidas estão associadas a métricas e tipos de recursos variados. Um evento que não carrega determinado campo não exibe a tag correspondente. Por isso, algumas tags podem aparecer em um evento e não em outro — esse é o comportamento esperado, não um erro do sistema.

      Por exemplo, um evento carrega a tag pod_name somente quando o alerta envolve um recurso Pod. Alertas que não envolvem um Pod 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 crie 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 ultrapassar 64 KB. Esse limite comporta aproximadamente 100 regras, dependendo da complexidade de cada uma. Ultrapassar esse limite causa falha na configuração. Para evitar isso, crie uma nova política de notificação para as 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 identificado são automaticamente vinculadas à política de notificação. Não é necessário configure uma política de notificação em cada regra de alerta individualmente.

      Esse recurso é especialmente útil em cenários de grande escala, como regras de alerta criadas automaticamente pelo Container Service for Kubernetes (ACK). Basta configure 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 só vez, sem 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 associar regras e encaminhar notificações de alerta ao 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 ARMS console. Essa tag é gerada automaticamente pelo sistema e não precisa ser adicionada manualmente.

   3. Clique em Next.

5. Na seção Event Group, configure como os eventos de alerta são agrupados e clique em Next.

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

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

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

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

      Tipos de destinatário 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 um URL de webhook especificado.

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

      Send recovery notification: Quando ative, uma notificação de recuperação é enviada após todos os eventos de um alerta serem resolvidos, e o alerta é então marcado automaticamente como Resolved.

   3. Defina um modelo de notificação. Para mais informações, consulte Configure notification and webhook templates.

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

   5. Optional: Selecione um sistema de tickets para encaminhar os alertas. Para detalhes sobre como integrar um sistema de tickets, consulte Integrations.

   6. Clique em Next.

7. Na seção Repeat/Escalate/Recover Policy, configure se as notificações devem ser repetidas ou se uma política de escalonamento deve ser aplicada ao alerta e clique em Next.

   • Repeat notifications for an alert: Quando ative, as notificações de alertas não resolvidos são reenviadas na frequência especificada até que o alerta seja resolvido.

   • Escalation policy:

     Ao selecione No escalation policy, a notificação é enviada apenas uma vez para um alerta não resolvido.

     Ao selecione Use escalation policy, a notificação é enviada a outros destinatários conforme a política de escalonamento.

   • Manual recovery: Quando ative, os alertas não são resolvidos automaticamente, mesmo que nenhum novo evento seja acionado durante o período de recuperação automática da integração. Esses alertas devem ser resolvidos manualmente.

8. Na seção Action Integration, configure ações automatizadas que são executadas quando um alerta é acionado ou resolvido. Para mais informações, consulte Execute an alert plan by using an ARMS action integration.

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

Gerenciar políticas de notificação

Após crie uma política de notificação, ela é exibida na página Notification Policies. Nessa página, as seguintes operações estão disponíveis:

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

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

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

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

Perguntas frequentes

P: Como configure métodos de notificação diferentes para severidades de alerta distintas dentro de uma única política de notificação?

R: Adicione múltiplas Actions dentro da mesma política de notificação para implementar notificações diferenciadas. Para cada ação, configure as condições de correspondência (por exemplo, severidade P1 ou P2) e selecione o canal de notificação correspondente (por exemplo, ligação telefônica ou grupo do DingTalk). Essa abordagem elimina a necessidade de crie uma política de notificação separada para cada nível de severidade.

P: Por que o intervalo de notificação efetivo difere do intervalo de notificação repetida configurado?

R: O intervalo efetivo é influenciado por múltiplos fatores sobrepostos:

• Ciclo de verificação de alertas do Prometheus: Por padrão, o Prometheus verifica alertas a cada 1 minuto.

• Mecanismo "Check after data is complete": Ative por padrão, esse mecanismo adiciona tempo de processamento extra para garantir que os dados do alerta estejam completamente disponíveis antes de o sistema avaliar novos eventos.

• Agregação de eventos e atraso no processamento do sistema: Atrasos adicionais ocorrem durante a agregação de eventos e o processamento downstream.

Devido a esses efeitos acumulativos, o intervalo efetivo pode ser maior que o valor configurado. Por exemplo, um intervalo configurado de 1 minuto pode resultar em um intervalo efetivo de 3 minutos.

Além disso, as notificações de recuperação são recalculadas com base no timestamp do último evento de alerta. Se os alertas continuarem sendo acionados, as notificações de recuperação serão proporcionalmente postergadas.

P: É possível remover o id de usuário da Alibaba Cloud exibido ao final das mensagens SMS de alerta do ARMS?

R: Não. O texto "This message was configured in ARMS by Alibaba Cloud user: xxxxxx" é um formato fixo do sistema e não pode ser removido por meio de configuração.