Reduza o ruído dos alertas

Uma aplicação nova pode enviar alertas demais. Limites são definidos antes de alguém conhecer a faixa normal da métrica, triggers observam todo host e todo valor de tag, e cada notificação vai para um único canal. Em poucas semanas a equipe começa a ignorar aquele canal, e pouco depois alguém desativa as notificações dele. Esta página é a rodada de ajustes que corrige isso. Os passos estão ordenados por quanto ruído cada um remove, então trabalhar de cima para baixo traz a maior parte do benefício logo no início. Para a mecânica de cada configuração, veja ajuste seus alertas. Os dois passos que normalmente removem mais notificações são usar filtros de tag exatos em vez de curingas amplos e manter os valores de tag em um conjunto pequeno e fixo. Ambos impedem que um trigger abra alertas para valores que você não pretendia monitorar.

Escolha o destino pela rapidez com que alguém precisa agir

A maior parte do ruído de notificação vem de alertas enviados a um canal que sugere mais urgência do que eles têm. Escolha o destino com base em quão rápido alguém precisa agir.

Clientes perdem dinheiro ou acesso hoje à noite. Plantão, como PagerDuty ou Opsgenie.
A situação piora, mas nada foi perdido ainda. Chat da equipe, como Slack.
Amanhã está realmente bom. E-mail, ou um canal de chat de baixo tráfego.
Nada, porque já é conhecido. Nenhum notifier.

Cada trigger seleciona seus próprios notifiers. Um trigger sem notifier ainda registra seus alertas, então você pode monitorar uma métrica sem enviar notificações. Dê ao staging seu próprio canal, ou deixe seus triggers sem notifier. Alertas de staging chegando em um canal de produção são a forma mais rápida de ensinar uma equipe a ignorar aquele canal.

Restrinja cada trigger à série que você realmente pretende

Um trigger não abre um alerta. Ele abre um alerta por série correspondente. Um trigger de host mantido no hostname padrão * cobre todo host que reporta ao app, então 30 hosts cruzando um limite juntos produzem 30 notificações para um único problema. Restrinja o escopo até a notificação dizer exatamente o que foi afetado:

Substitua * por um hostname específico, ou um prefixo como web-*. Valores de tag aceitam curingas, então hostname=frontend* restringe um trigger a uma classe de máquina.
Restrinja triggers de taxa de erros e de tempo de resposta a um único namespace, para que web, background e admin possam ter limites e destinos diferentes.
Adicione uma tag para o recurso específico que importa para você, como um único mountpoint em vez de todo sistema de arquivos montado.

Use filtros de tag exatos ou envie uma métrica de alerta dedicada

Essa limitação causa muitas solicitações de suporte sobre alertas ruidosos, e vale entendê-la antes de projetar uma métrica. Suponha que você envie um contador chamado api_request, com a tag status, para poder segmentá-lo por 200, 404 e 500. Se você só se importa com um valor exato, como status=500, use esse valor exato no trigger. O problema começa quando você quer um grupo de valores: todas as respostas 5xx, qualquer coisa exceto 200, ou toda resposta que falhou. Um filtro de tag não consegue expressar exclusões nem faixas, e * corresponde a todo valor daquela tag. Um trigger com curinga amplo pode abrir alertas para status de sucesso junto com as falhas, e a maior parte do que chega descreve uma aplicação funcionando corretamente. A solução é transformar a condição sobre a qual você quer alertar em sua própria série, no ponto em que você a envia. Mantenha a métrica com tags quando ela é útil para gráficos, e envie uma segunda, mais restrita, para alertar:

status_code = response.code.to_s

# Useful for charts broken down by status.
Appsignal.increment_counter("api_request", 1, :status => status_code)

# Useful for alerting because it only increments for 5xx responses.
Appsignal.increment_counter("api_request_failed", 1) if status_code.to_i >= 500

status = response.status

# Useful for charts broken down by status.
Appsignal.increment_counter("api_request", 1, %{status: status})

if status >= 500 do
  # Useful for alerting because it only increments for 5xx responses.
  Appsignal.increment_counter("api_request_failed", 1)
end

Depois configure o trigger para usar a métrica mais restrita:

Shell

appsignal-cli triggers create --app "MyApp" --environment production \
  --name "Server errors from the payment API" \
  --metric-name api_request_failed --kind Advanced --field counter \
  --comparison-operator ">" --condition-value 10 \
  --warmup-duration 3 --cooldown-duration 5 \
  --notifier-ids <NOTIFIER_ID>

O alerta agora abre apenas para a condição que deve enviar uma notificação. Decida isso enquanto escreve a métrica personalizada, porque é mais fácil que redesenhar a métrica depois que os alertas começarem a abrir.

Mantenha os valores de tag em um conjunto pequeno e fixo

Nunca use como valor de tag um valor que seja único por evento. Identificadores de requisição, números de pedido, identificadores de cliente e timestamps todos parecem contexto útil e todos causam os mesmos dois problemas. Cada valor distinto é uma série separada. Um trigger sobre essa métrica abre um alerta por valor, o que pode criar um número ilimitado de alertas. Tags de alta cardinalidade também tornam gráficos de métricas e alertas difíceis de gerenciar. Um valor de tag deve ter um punhado de variações que você conseguiria listar de memória. Por exemplo, use como tag uma dimensão limitada como region, e não um identificador único:

# A tag with a small set of values is safe to graph and alert on.
Appsignal.increment_counter("order_processed", 1, :region => order.region)

# A tag with a small set of values is safe to graph and alert on.
Appsignal.increment_counter("order_processed", 1, %{region: order.region})

O identificador do pedido continua importando quando você está investigando, então coloque-o em uma linha de log, onde alta cardinalidade é esperada. Use tags de métrica para dimensões pelas quais você gostaria de agrupar um gráfico. A referência de métricas personalizadas tem mais sobre a escolha de tags, incluindo manter a mesma combinação em todos os lugares onde você reporta uma métrica.

Alerte sobre taxas, não sobre contagens

Uma contagem de erros cruza um limite fixo sempre que o tráfego cresce, então notifica você no seu dia mais movimentado, independentemente de algo estar errado. A taxa de erros permanece significativa às 4h da manhã e no pico. Trocar uma contagem por uma taxa muitas vezes é a única alteração que transforma um alerta noturno em um alerta útil. Mantenha contagens apenas onde qualquer ocorrência importa e o volume é naturalmente baixo, como falhas em um fluxo de pagamento.

Ajuste o warm-up conforme a métrica muda

Warm-up é quanto tempo o AppSignal espera antes de abrir um alerta. Durante essa espera, a métrica precisa permanecer acima ou abaixo do limite, dependendo do trigger. Isso filtra picos de um minuto, como um deploy lento, uma pausa de garbage collection ou um host reiniciando. Defina o warm-up com base em quanto a métrica muda de minuto a minuto, não em quão séria a métrica é. Comece com zero a dois minutos para a maioria dos alertas de produção. Use um warm-up mais longo apenas quando uma métrica costuma ter picos e se recuperar rapidamente. Memória e swap se movem gradualmente, então frequentemente precisam de pouco ou nenhum warm-up. Se você precisa de 30 ou 60 minutos para reduzir notificações, revise o limite ou o escopo em vez disso.

Use cooldown quando uma métrica fica perto do seu limite

Cooldown evita que um único incidente produza uma sequência de notificações de abertura e fechamento enquanto uma métrica cruza o limite repetidamente. A maioria dos triggers nunca precisa dele. A exceção são métricas de recursos que se movem lentamente, que podem precisar de um cooldown mais longo: um disco perto de 80% pode cruzar essa linha várias vezes antes de alguém liberar espaço, então sem um cooldown longo ele pode alertar de novo cada vez que o valor se move acima e abaixo do limite. Trinta a 60 minutos transformam várias notificações em um alerta que permanece aberto até ser resolvido.

Não aumente o cooldown de um uptime monitor

Aumentar o cooldown é a correção padrão para um trigger que abre e fecha repetidamente, mas aqui é a correção errada. Um uptime monitor falhando significa que o endpoint não respondeu. Suprimir a segunda notificação não torna a primeira menos precisa. Recorra ao warm-up. O AppSignal verifica seu endpoint a cada minuto a partir de quatro regiões e acompanha cada região separadamente, então uma única queda pode abrir até quatro alertas, e um problema de rede entre uma única região e seu endpoint abre um enquanto sua aplicação está saudável. Um warm-up de pelo menos um minuto filtra esse caso sem esconder uma queda real.

Torne cada notificação autoexplicativa

Fadiga de alertas não é só sobre quantas notificações chegam. É também sobre quanto trabalho cada uma exige para ser entendida. Três campos fornecem esse contexto: Nome. Diga o que está errado, não qual métrica se moveu. Um trigger de métrica personalizada começa chamado Custom metric, e uma lista de triggers todos com esse nome não pode ser triada. Descrição. Trate-a como o runbook. Curta está bem, mas o campo aceita vários parágrafos, comandos e links. As descrições mais úteis incluem a informação que quem responde teria que reconstruir de outro modo: o número que importa (“o limite do load balancer é 320”), os remédios em ordem, um passo de diagnóstico, quanto tempo a correção leva, e qual foi a causa na última vez. Dashboard. Vincule o dashboard que mostra a métrica ao lado de métricas relacionadas, para que a notificação dê a quem responde um ponto de partida para a investigação.

Revise seus triggers periodicamente

A configuração de alertas fica desatualizada. Triggers sobrevivem aos incidentes que os motivaram, limites definidos para o tráfego do ano passado não servem mais, e hosts nomeados em um trigger são substituídos. Aproximadamente a cada trimestre, pergunte de cada trigger: ele abriu nos últimos 90 dias, alguém agiu com base nele, ele abriu muitos alertas para um único incidente, e seu destino ainda é o correto? Um alerta que ninguém trata deve ser reajustado, redirecionado ou arquivado. Revisar o conjunto inteiro é mais rápido pelo terminal que abrindo cada trigger:

Shell

# Every trigger, as JSON you can diff, grep, or hand to an agent
appsignal-cli --output json triggers list --app "MyApp" --environment production

# Narrow to one metric or one kind when you are hunting duplicates
appsignal-cli triggers list --app "MyApp" --environment production --metric-name response_time

Reajustar é um único comando, mas atualizações exigem a definição completa do trigger. Comece pelos valores atuais em triggers list, altere os campos que quer reajustar, e inclua valores opcionais que quer manter, como IDs de notifier, tags e o link do dashboard:

Shell

appsignal-cli triggers update --id <TRIGGER_ID> --app "MyApp" --environment production \
  --name "Slow web requests" \
  --metric-name response_time --kind Advanced --field p95 \
  --comparison-operator ">" --condition-value 750 \
  --warmup-duration 5 --cooldown-duration 5 \
  --notifier-ids <NOTIFIER_ID>

Alterar configurações do trigger pode afetar o estado ativo do alerta, então evite reajustar um trigger enquanto usa um alerta aberto para responder a um incidente. Arquivar um trigger também fecha seus alertas e incidents, o que é útil para um trigger que ninguém trata:

Shell

appsignal-cli triggers archive --id <TRIGGER_ID> --app "MyApp" --environment production

O MCP server expõe o mesmo acesso de leitura e escrita a triggers, então você pode pedir a um agente que liste todo trigger que não abriu em 90 dias e proponha o que arquivar. Veja a referência da AppSignal CLI para todas as flags.

Como o AppSignal alerta sobre o AppSignal

Rodamos o AppSignal no AppSignal, e nosso time de operações vem ajustando essa configuração há anos. O formato dela é um alvo razoável a se buscar:

O que observamos	Condição	Warm-up	Cooldown	Destino
Uso de disco em `/`	Acima de 80%	10 minutos	60 minutos	Plantão
Memória livre	Abaixo de 100 MB	0	0	Plantão
Swap em uso	Acima de 50%	0	0	Plantão
Itens aguardando em uma fila, com tag por fila	Mais de 10.000	2 minutos	0	Plantão
Atraso de processamento, no `p95`	Acima de 2.000 ms	0	0	Plantão
Conexões a uma classe de host	Mais de 800	2 minutos	0	Apenas chat da equipe
Throughput em um namespace background	30.000 req/min ou mais	2 minutos	0	Plantão
Atraso de replicação	Acima de 60 segundos	2 minutos	0	E-mail e plantão

Cinco padrões nessa tabela são úteis para alertas de produção:

Warm-ups são curtos. A maioria vai de zero a dois minutos. O único longo é no uso de disco, e ele é combinado com uma hora de cooldown em vez de usado no lugar dele.
Cooldown é usado uma vez, deliberadamente. Só o uso de disco normalmente permanece acima do limite até alguém agir, então só ele precisa disso.
Não todo alerta notifica o plantão. O teto de conexões vai para o chat da equipe, porque prevê um problema de capacidade em vez de descrever uma queda.
E-mail é adicionado, não substituído. O atraso de replicação chega a uma ferramenta de plantão e ao e-mail juntos, porque e-mail é o único canal que continua lembrando enquanto um alerta permanece aberto.
Todo trigger carrega uma descrição. As mais úteis nomeiam o limite relevante, dão dois remédios em ordem, e registram qual foi a causa na última vez.

Os triggers mais difíceis de revisar são os que ficaram com o nome Custom metric. Nomear é uma tarefa pequena, mas tem grande efeito sobre revisão e triagem.

Próximos passos

Percorra as configurações em detalhe com ajuste seus alertas.
Verifique que nada importante está sem monitoramento com alerting em produção.
Encontre uma configuração inicial para um alerta específico nos guias para criar alertas.
Modele uma métrica para alertar no momento em que a envia, com métricas personalizadas.

Recursos

Integridade do aplicativo

Logs e métricas

Infraestrutura

Personalização do aplicativo

Escolha o destino pela rapidez com que alguém precisa agir

Restrinja cada trigger à série que você realmente pretende

Use filtros de tag exatos ou envie uma métrica de alerta dedicada

Mantenha os valores de tag em um conjunto pequeno e fixo

Alerte sobre taxas, não sobre contagens

Ajuste o warm-up conforme a métrica muda

Use cooldown quando uma métrica fica perto do seu limite

Não aumente o cooldown de um uptime monitor

Torne cada notificação autoexplicativa

Revise seus triggers periodicamente

Como o AppSignal alerta sobre o AppSignal

Próximos passos

​Escolha o destino pela rapidez com que alguém precisa agir

​Restrinja cada trigger à série que você realmente pretende

​Use filtros de tag exatos ou envie uma métrica de alerta dedicada

​Mantenha os valores de tag em um conjunto pequeno e fixo

​Alerte sobre taxas, não sobre contagens

​Ajuste o warm-up conforme a métrica muda

​Use cooldown quando uma métrica fica perto do seu limite

​Não aumente o cooldown de um uptime monitor

​Torne cada notificação autoexplicativa

​Revise seus triggers periodicamente

​Como o AppSignal alerta sobre o AppSignal

​Próximos passos

Escolha o destino pela rapidez com que alguém precisa agir

Restrinja cada trigger à série que você realmente pretende

Use filtros de tag exatos ou envie uma métrica de alerta dedicada

Mantenha os valores de tag em um conjunto pequeno e fixo

Alerte sobre taxas, não sobre contagens

Ajuste o warm-up conforme a métrica muda

Use cooldown quando uma métrica fica perto do seu limite

Não aumente o cooldown de um uptime monitor

Torne cada notificação autoexplicativa

Revise seus triggers periodicamente

Como o AppSignal alerta sobre o AppSignal

Próximos passos