Regras

Abrir na plataforma

Uma regra de notificação define o roteamento dos alertas gerados pela plataforma. Dado um alerta que casa com certos critérios (severidade, tags, hostname ou alertas específicos), a regra decide para quais canais ele deve ser entregue.

A página de Regras é o filtro entre o alerta gerado e o destinatário final. Sem regra, o alerta é registrado e fica visível em Observar & Explorar → Alertas, mas não é empurrado para nenhum lugar. É a regra que decide se aquele evento vira mensagem no Slack do plantão, push no celular do líder ou email para a caixa coletiva do time.

Regra é roteamento, não definição

A definição do alerta (limiar, métrica, condição) vive no host ou no perfil. A regra de notificação é uma camada acima: ela só decide para onde a notificação vai. Mudar uma regra nunca apaga ou silencia o alerta na tela de Alertas, só muda quem recebe a mensagem.

Acesse por Notificações → Regras.

Quem usa

A página é usada por três perfis no dia a dia:

• Admin do tenant: configura as regras gerais (plantão NOC, time de DBA, infra, segurança). É quem garante que todo alerta crítico de produção cai no canal certo, sem furo.
• SRE ou líder de time: cria regras específicas do seu domínio. O time de aplicações cria a regra que manda alertas com tag app:checkout para o Slack do squad. O time de banco mantém a regra que filtra db-prod-*.
• Líder de plantão: ativa/desativa regras temporariamente em janelas de manutenção, troca o canal de destino quando o time de plantão muda.

Usuários comuns também conseguem abrir a tela e ver as regras existentes (ver Quem vê o quê (ACL) mais abaixo), mas só admin do tenant altera.

A lista

A tabela principal mostra todas as regras configuradas no tenant. Cada linha é uma regra, com as colunas:

Coluna	Conteúdo
Nome	Nome da regra (usado também nos logs e na trilha de auditoria).
Severidades	Badges coloridos das severidades que a regra cobre: Crítico, Alto, Médio, Informação.
Tags	Padrões de tag que a regra casa, separados por vírgula, com badge por padrão.
Nomes de Host	Padrões de hostname (suporta wildcard, ex: srv-web-*).
Alertas	Estatísticas de execução: quantas vezes acionou, quantas vezes falhou.
Canais	Lista dos canais destino dessa regra.
Stats	Último acionamento da regra.
Status	Toggle ativo/inativo.
Ações	Editar, excluir e ver logs da regra.

A tabela é ordenável. Clique no cabeçalho de uma coluna para ordenar por nome, severidade ou último acionamento. O botão Nova Regra no canto superior direito abre o modal de criação.

Use o nome como índice

Em ambiente com 20+ regras, o nome vira o índice mental do time. Convencione um padrão tipo [time] - [escopo] - [severidade] (ex: NOC - Producao - Critico e Alto, DBA - db-prod - Critico). Fica fácil achar e fácil de auditar.

Como uma regra funciona

A lógica de matching de uma regra é um E entre todos os critérios: o alerta precisa atender a todas as condições simultaneamente para a regra disparar.

Dado um alerta gerado pela plataforma, ele passa por cada regra ativa e a regra dispara se:

1. A severidade do alerta está na lista de severidades da regra, E
2. Pelo menos uma tag do host ou do alerta casa com algum padrão da lista de tags da regra, E
3. Pelo menos um hostname do alerta casa com algum padrão da lista de hostnames da regra, E
4. (Opcional) Se a regra tem uma lista de alertas específicos, o alerta atual está nessa lista.

Dentro de cada lista (tags, hostnames, alertas específicos) a lógica é OU: basta um padrão bater. Entre as listas é E: todas precisam ter pelo menos um match.

Exemplo passo a passo

Considere a regra:

• Nome: NOC - Producao - Critico e Alto
• Severidades: Crítico, Alto
• Tags: env:prod, time:noc
• Nomes de Host: srv-web-*, api-*
• Alertas específicos: (vazio)
• Canais: Slack #plantao-noc

Agora chegam três alertas:

Alerta	Severidade	Host	Tags	Casa?
Alerta 1	Crítico	srv-web-03	env:prod, app:portal	Sim (severidade ok, host bate srv-web-*, tag bate env:prod).
Alerta 2	Médio	srv-web-03	env:prod, app:portal	Não (severidade fora da lista).
Alerta 3	Alto	db-prod-01	env:prod, time:dba	Não (host não bate nenhum padrão).

Só o Alerta 1 dispara essa regra. Os outros dois podem disparar outras regras, mas não esta.

Regras não são exclusivas

Um mesmo alerta pode disparar várias regras ao mesmo tempo. Se você tem uma regra geral de NOC e uma regra específica de DBA, e um alerta de banco crítico em produção bate nas duas, ambas notificam (NOC e DBA recebem). Isso é desejado: redundância de plantão é melhor que alerta perdido.

Criar uma regra

O botão Nova Regra abre o modal de criação com os campos:

Campo	O que preencher
Nome da Regra	Obrigatório. Identifica a regra na tabela, nos logs e na auditoria. Convencione um padrão (ver tip acima).
Severidades	Checkboxes múltiplas: Crítico, Alto, Médio, Informação e a opção Todas. Marque ao menos uma.
Tags	Chip input. Adicione padrões um a um (Enter confirma). Matching é ANY, basta um padrão bater. Suporta wildcards.
Nomes de Host	Chip input com padrões de hostname. Suporta wildcards como srv-web-*, db-prod-*, api-*.
Alertas específicos	Seleção opcional de alertas individuais. Útil quando a regra é dedicada a alertas pontuais (ex: só o alerta de "espaço em disco" do storage X).
Canais	Multi-select dos canais já criados em Canais. Marque um ou mais destinos.
Status	Toggle ativo/inativo. Regra inativa fica salva mas não dispara.

Confirme com Salvar. A regra entra na tabela e passa a ser avaliada nos próximos alertas. Para anular tudo e fechar o modal, use Cancelar.

Sem canal, sem notificação

Uma regra sem canais selecionados pode ser salva (fica registrada), mas não notifica nada quando aciona. A plataforma loga o disparo mas não tem para onde mandar. Se o objetivo é silenciar um alerta, prefira desativar a regra ou ajustar o critério, em vez de deixar regra ativa sem destino.

Wildcards e padrões

Tags e hostnames aceitam wildcards com asterisco. Os padrões mais comuns:

Padrão	Casa com
srv-web-*	srv-web-01, srv-web-prod-02, srv-web-homolog.
*-prod	srv-web-prod, db-mysql-prod, api-prod.
*producao*	srv-producao-01, app-producao-checkout, producao-storage.
db-prod-*	db-prod-01, db-prod-mysql, db-prod-postgres-02.
api-*-01	api-checkout-01, api-pagamentos-01.
*backup* (tag)	Qualquer tag que contenha "backup": tipo:backup, backup:diario.

Algumas observações úteis:

• O matching é case-insensitive: SRV-WEB-* e srv-web-* casam com srv-web-01.
• Um único padrão simples como * casa com tudo. Útil quando você quer ignorar o critério (ex: regra que cobre qualquer hostname).
• Para listar exatamente um host, sem wildcard, basta colocar o nome completo: api-checkout-01.

Comece restritivo, abra depois

É mais fácil receber notificação a menos do que a mais. Crie a regra com critério apertado, observe um dia de operação, e amplie se perceber que alertas relevantes estão ficando de fora. O caminho contrário, regra ampla que vira spam, gera ruído rapidamente e o time aprende a ignorar.

Alertas específicos vs. critérios genéricos

A regra aceita dois modos de seleção combinados:

• Critérios genéricos (severidade + tags + hostnames): a regra cobre qualquer alerta novo que case com o padrão. Ideal para plantões, times, áreas inteiras.
• Alertas específicos (lista nominal de alertas): a regra só dispara para esses alertas. Ideal para casos pontuais.

Quando usar cada um:

Cenário	Modo recomendado
Plantão NOC pega Crítico/Alto de produção.	Genérico (severidade + tags + hostnames).
Time DBA recebe tudo de db-prod-*.	Genérico (hostnames).
Alerta de "certificado SSL próximo do vencimento" vai só para o líder de segurança.	Específico (lista nominal).
Alerta de "backup atrasou" entra em canal dedicado.	Específico (lista nominal) ou genérico por tag *backup*.
Notificação pessoal do líder de squad sobre alertas do app que ele cuida.	Genérico por tag de app (app:checkout).

Específico para o que é único, genérico para o que é padrão

Se você se pegar listando 30 alertas no modo específico de uma regra, provavelmente esses 30 alertas têm algo em comum (tag, severidade, padrão de nome) e a regra fica mais fácil de manter no modo genérico. O modo específico brilha quando o critério não cabe em nenhum padrão (ex: três alertas históricos críticos do storage legado que precisam de tratamento próprio).

Editar e gerenciar

Na coluna Ações de cada linha:

• Editar: abre o mesmo modal de criação preenchido. Ajuste critérios, canais ou status e salve.
• Ver logs: abre o histórico de disparos daquela regra. Útil para auditar se um alerta foi notificado ou para diagnosticar regra que parou de acionar.
• Excluir: remove a regra. Confirmação obrigatória.

O toggle Status na própria coluna desativa a regra sem precisar abrir o modal. Útil em janela de manutenção (você desativa a regra de plantão por 1 hora durante o deploy planejado, e religa depois).

Mudança de regra entra valendo no próximo alerta

Ao salvar a edição, a próxima avaliação de alertas já usa o critério novo. Alertas que já dispararam antes da mudança não são reavaliados (não recebem notificação retroativa nem perdem notificação que já saiu). O efeito é sempre para frente.

Quem vê o quê (ACL)

A página segue o modelo de ACL padrão do módulo de Notificações:

Perfil	O que pode fazer
Usuário	Ver a lista de regras e abrir o detalhe (modo leitura). Não cria, edita nem exclui.
Admin do tenant	Tudo do usuário, mais criar, editar, ativar/desativar e excluir regras do próprio tenant.

Toda alteração de regra (criação, edição, exclusão, ativação/desativação) é registrada na Trilha de Auditoria com usuário, data, hora e diff dos campos alterados.

Cenários de uso

Três cenários do dia a dia para deixar a configuração concreta:

Plantão NOC só Crítico e Alto

Time de NOC quer ser acordado de madrugada só se for problema sério em produção.

• Nome: NOC - Producao - Critico e Alto
• Severidades: Crítico, Alto
• Tags: env:prod
• Nomes de Host: * (todos)
• Canais: Slack #plantao-noc + telefone (push mobile)

Resultado: qualquer alerta crítico ou alto de host com tag de produção dispara no Slack e no celular. Médio e Informação ficam fora, evitando barulho desnecessário às 3h.

Time DBA só de db-*

DBAs querem ver tudo que acontece nos bancos, mas só dos bancos.

• Nome: DBA - Todos os bancos
• Severidades: Crítico, Alto, Médio
• Tags: * (qualquer)
• Nomes de Host: db-*
• Canais: Slack #time-dba, email coletivo do time

Resultado: o time DBA recebe Crítico, Alto e Médio de qualquer host cujo nome começa com db-. Informação fica de fora porque o time decidiu olhar isso só pela tela.

Push pessoal do líder de squad

O líder do squad de checkout quer notificação no celular pessoal para alertas críticos do app que ele cuida, sem incomodar o squad inteiro fora do horário.

• Nome: Lider Checkout - Critico pessoal
• Severidades: Crítico
• Tags: app:checkout
• Nomes de Host: *
• Canais: Push mobile (canal pessoal do líder)

Resultado: só alertas críticos com tag de checkout chegam no push pessoal. O squad continua recebendo alertas pelo Slack do time via outra regra, sem duplicar barulho no celular dele.

Boas práticas

Comece com regra ampla de plantão, depois refine

A primeira regra de qualquer tenant deveria ser uma de plantão geral cobrindo Crítico de produção. Garante que ninguém perde um alerta crítico enquanto você arruma os recortes mais finos. Refine depois com regras específicas por time e por app.

Nomeie bem

Nome de regra é o que aparece nos logs, na auditoria e na lista. Use um padrão tipo [time] - [escopo] - [criterio]. Evite nomes genéricos como "regra 1" ou "teste". Em 6 meses ninguém lembra o que faz cada uma e o time fica com medo de mexer.

Próximos passos

• Canais

  ---

  Configure os destinos das notificações (Slack, Teams, email, push, webhook) antes de criar regras.

  Ver Canais

• Alertas

  ---

  Página de operação no dia a dia. Veja os alertas em aberto que estão sendo roteados pelas regras.

  Abrir Alertas

• Conceitos

  ---

  Vocabulário completo da plataforma: regra de notificação, alerta, severidade, canal.

  Ver Conceitos