Ajuste seus alertas

Um alerta só é útil se alguém agir com base nele. Quando uma equipe recebe mais notificações do que consegue tratar, ela começa a ignorar todas, inclusive a que importava. Essa é a fadiga de alertas, e normalmente é um problema de configuração, não de monitoramento. Esta página cobre como ajustar um alerta que já existe. Se você ainda está decidindo sobre o que alertar, comece pelos guias para criar alertas. Se o seu problema é o conjunto inteiro em vez de um trigger, reduza o ruído dos alertas percorre primeiro as mudanças que removem mais notificações.

​

Sinais de que seus alertas precisam de ajuste

• Um canal recebe alertas que ninguém investiga.
• O mesmo alerta abre e fecha várias vezes por hora.
• Um único incidente produz muitas notificações de muitos hosts ou combinações de tags.
• O plantão recebe alertas que só podem ser tratados em horário comercial.
• Alguém desativou as notificações do canal de alertas.

Cada um desses casos corresponde a uma configuração específica descrita nas seções seguintes.

​

Limite, warm-up e cooldown

Todo anomaly detection trigger tem três configurações que controlam quando os alertas abrem e fecham. Ajustar quase sempre significa alterar uma delas.

​

Defina limites a partir do histórico da métrica

Antes de escolher um limite, plote a métrica ao longo de pelo menos duas semanas e observe sua faixa normal, incluindo os picos diários e semanais. Um limite definido abaixo de um pico rotineiro de segunda-feira vai notificar você toda segunda-feira. Um bom ponto de partida é o valor que a métrica alcança durante um período movimentado mas saudável, mais margem suficiente para que a variação normal não o cruze. Se você não conseguir descrever o que faria quando o limite fosse cruzado, provavelmente não é o limite certo.

​

Use warm-up para filtrar picos

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. Com um warm-up de 0, o AppSignal pode abrir um alerta assim que a métrica cruzar o limite. Use warm-up para evitar alertas de picos curtos de métrica, como um deploy lento, uma pausa de garbage collection ou um host reiniciando. Comece com zero a dois minutos para a maioria dos alertas de produção. Use um warm-up mais longo apenas quando a métrica costuma ter picos e se recuperar rapidamente. Defina o warm-up com base em quanto a métrica muda de minuto a minuto. Uma métrica que muda rapidamente muitas vezes precisa de warm-up. Uma métrica que muda gradualmente muitas vezes precisa de pouco ou nenhum. Warm-ups úteis normalmente são curtos. Acima de cerca de 10 minutos, você está mais atrasando a notificação do que melhorando-a. Se você precisa de 30 ou 60 minutos para reduzir notificações, revise o limite ou o escopo em vez disso.

​

Use cooldown quando alertas abrem e fecham repetidamente

Cooldown é o número de minutos que a métrica precisa permanecer recuperada antes de o alerta fechar e um novo alerta poder abrir. Para triggers de “maior que”, isso significa que a métrica permanece abaixo do limite. Para triggers de “menor que”, significa que a métrica permanece acima do limite. Sem cooldown, uma métrica que cruza repetidamente seu limite produz uma sequência de notificações de abertura e fechamento para um único incidente. Um cooldown curto transforma essa sequência em um único alerta. Defina-o ligeiramente mais longo que o período em que a métrica normalmente se move acima e abaixo do limite. Cooldown é uma correção pontual, não um padrão. A maioria dos triggers nunca precisa dele, porque a maioria das métricas não fica exatamente sobre seu limite. Deixe-o em 0 até ver um trigger abrir e fechar repetidamente para o que era claramente um único incidente, e então defina-o com base em quanto tempo esses intervalos realmente duraram.

​

Escopo: um trigger pode abrir muitos alertas

Esta é a causa mais comum de muitas notificações a partir de um único incidente. Um trigger não abre um alerta. Ele abre um alerta por série correspondente. Para triggers de host, isso significa um alerta por host. O campo hostname aceita um curinga, e seu valor padrão * corresponde a todo host que reporta ao app. Uma frota de 30 hosts cruzando um limite de CPU ao mesmo tempo produz 30 alertas. Restrinja o escopo para que a notificação diga exatamente o que foi afetado:

• Defina um hostname específico, ou um prefixo como web-*, em vez de deixar o padrão *.
• Adicione tags para que o trigger observe apenas as séries que importam para você, como mountpoint=/ para uso de disco ou region=eu para uma métrica personalizada.
• 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 notifiers diferentes.

Quando você adiciona tags, o AppSignal avisa se a combinação de tags não foi vista na última hora. Esse aviso normalmente significa que o trigger nunca corresponderá a dados. Use uma das combinações de chaves de tag listadas no formulário do trigger, e defina cada valor como um valor exato ou um curinga. Uptime monitors se comportam da mesma forma. Cada uma das quatro regiões é acompanhada separadamente, então um monitor pode abrir quatro alertas para uma única queda, e um alerta quando uma única região não consegue alcançar um endpoint que está saudável no resto.

​

Escolha uma métrica que reflita o impacto no usuário

Alterar configurações do trigger não corrige um trigger que observa a métrica errada. Prefira taxas a contagens. A contagem de erros cruza um limite fixo sempre que o tráfego cresce, então notifica você nos seus dias mais movimentados, independentemente de algo estar errado. A taxa de erros permanece estável conforme o tráfego muda. Use contagens apenas para métricas em que qualquer ocorrência importa, como erros em um fluxo de pagamento. Prefira percentis a médias. Um tempo de resposta médio esconde uma experiência lenta para parte do seu tráfego. Se 5% das requisições levam 8 segundos, a média quase não se move. Alerte em p90 ou p95. Prefira sintomas visíveis ao usuário a causas. Alerte sobre erros, latência, tráfego ou ações de negócio que falharam, e use dashboards para encontrar a causa. Uso alto de CPU não é em si um problema se os tempos de resposta estão bons. Isso mantém o número de alertas proporcional ao número de incidentes reais. Defina dados faltantes como zero deliberadamente. Um trigger assume que um ponto de dados chega a cada minuto. Para métricas que só reportam quando algo acontece, como um contador, ative treat missing datapoints as 0 para que o alerta feche quando a atividade parar. Deixe desativado quando uma lacuna nos dados significa “nenhuma informação” em vez de “zero”.

​

Direcione por severidade, não por hábito

Enviar tudo para um único canal causa fadiga de alertas. Cada trigger pode usar seu próprio notifier, então use isso para separar alertas urgentes dos que podem esperar. 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 uma das formas mais rápidas de ensinar uma equipe a ignorar aquele canal. Severidade não é a única divisão útil. Quando você tem mais que um punhado de triggers, canais de chat separados por domínio, como um para erros da aplicação e um para infraestrutura, mantêm cada canal pequeno o suficiente para que as pessoas que o acompanham reconheçam quando algo está incomum. Um único canal recebendo tudo torna as notificações importantes mais fáceis de perder.

​

Direcione incidents e triggers de formas diferentes

O direcionamento tem duas camadas, e elas se comportam de formas diferentes. Para anomaly detection triggers, escolha os notifiers no próprio trigger. Remover todos os notifiers deixa o trigger ativo e ainda registrando alertas, mas sem enviar notificações. Para incidents de erro e de desempenho, defina padrões de notificação por namespace em vez de configurar cada incident. Um namespace admin definido como Never Notify remove de uma vez toda uma categoria de notificações de baixo valor. Os padrões por namespace também são onde você direciona incidents web, background e admin para destinos diferentes. Notifiers são configurados uma vez para a organização e podem ser compartilhados entre apps, então um notifier usado por muitos apps exige cuidado. Verifique onde um notifier é usado antes de editá-lo.

​

Torne a 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. Um alerta que diz que um número cruzou um limite força quem responde a investigar o que aquele limite significa. Um alerta que se explica pode ser tratado imediatamente, ou ignorado corretamente. Três campos fornecem esse contexto, e vale a pena preencher todos os três em cada trigger. Nome. Diga o que está errado, não qual métrica se moveu. Uma lista de triggers em que muitas entradas se chamam Custom metric não pode ser revisada nem triada. Descrição. Trate-a como um runbook de uma linha. Declare o que a condição significa e o que quem responde deve fazer a respeito. Estas são as duas perguntas que quem responde precisa responder, e a descrição é o melhor lugar para respondê-las:

• “Este host está usando swap, então cada requisição que ele atende fica mais lenta. Verifique o que está consumindo a memória e avise o canal de operações.”
• “Menos de 100 MB de memória livre. Verifique o que está consumindo e adicione capacidade antes de o kernel começar a matar processos.”
• “Este serviço tem um vazamento de memória conhecido. A memória cresce até o kernel matar o processo, então reinicie-o e só escale se voltar dentro de uma hora.”

O terceiro exemplo merece atenção. Documentar uma causa conhecida no trigger evita que a mesma investigação seja repetida por quem estiver de plantão desta vez, e diz a quem responde quando não agir. Dashboard. Cada trigger pode vincular um dashboard, e o link é incluído na notificação. Vincule o dashboard que mostra a métrica em contexto, ao lado de métricas relacionadas. Isso dá a quem responde um ponto de partida para a investigação.

​

O que você não pode ajustar, e o que não deveria alertar

Duas coisas sobre alertas de trigger não podem ser ajustadas, e uma categoria de métrica não deveria alertar desde o início. Opções de frequência se aplicam a incidents e log triggers, não a alertas de anomaly detection triggers. Notificações de erro e de desempenho usam opções de notificação de incident, como Every Occurrence, First in Deploy, First After Close e Never Notify, definidas por namespace nos padrões de notificação. Log triggers têm opções de limite semelhantes. Alertas de anomaly detection triggers seguem a máquina de estados de alertas. Só o e-mail se repete enquanto um alerta de anomalia permanece aberto. Notifiers de e-mail têm um Reminder interval de 15 minutos, 30 minutos ou 1 hora. Slack, PagerDuty, Opsgenie e webhooks não têm equivalente. O que fazer em vez disso. Para impedir que um trigger notifique alguém, remova seus notifiers ou arquive-o. Se um alerta aberto precisa continuar enviando lembretes até alguém agir, combine e-mail com uma ferramenta de plantão que tenha sua própria política de escalonamento. Se um alerta de longa duração está enchendo um canal de chat, a causa é a abertura e o fechamento repetidos, não os lembretes, então a correção é um cooldown mais longo. Para outros casos, decida se a condição deve enviar notificação alguma.

• Alerte sobre uma taxa de erros acima de 5% em web por três minutos, não sobre cada exceção individual, por rara que seja.
• Alerte sobre o tempo de resposta p95 no checkout dobrando, não sobre uma média que passou de 180 ms para 200 ms.
• Alerte sobre throughput em zero quando normalmente é 400 req/min, não sobre tráfego caindo à metade durante a noite, como acontece toda noite.
• Alerte sobre um disco em 85% ganhando um ponto por hora, não sobre CPU tocando 100% por um minuto durante um deploy.
• Alerte sobre um job noturno de faturamento que nunca reportou, não sobre o mesmo job começando dois minutos atrasado.
• Alerte sobre um provedor de pagamentos com timeout 50 vezes em uma hora, não sobre uma requisição que deu timeout e teve sucesso no retry.

Se uma métrica é interessante mas não acionável, coloque-a em um dashboard em vez de enviar notificações sobre ela.

​

Revise os triggers regularmente

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. Revise seus triggers aproximadamente a cada trimestre e pergunte, para cada um:

1. Ele abriu um alerta nos últimos 90 dias? Se não, abra-o e verifique a prévia do gráfico. Nenhum dado, ou um aviso no campo hostname de que o host não foi encontrado, significa que ele está observando algo que não existe mais. Hosts renomeados ou substituídos são a causa usual, e o trigger não notifica você quando não corresponde a nada.
2. Alguém agiu com base nele? Um alerta que ninguém trata deve ser reajustado, redirecionado ou arquivado.
3. Ele abriu muitos alertas para um único incidente? Restrinja seu escopo.
4. O notifier dele ainda é o adequado? Enviar problemas não urgentes para o plantão é uma fonte principal de fadiga de alertas.
5. Ele se explica? Um trigger sem nome e sem descrição não pode ser triado, porque ninguém consegue dizer o que ele faz sem reconstruí-lo.
6. Ele é duplicado? Dois triggers com a mesma métrica, o mesmo limite e o mesmo notifier enviam duas notificações para um problema.
7. Alguém ainda é responsável por ele? Triggers criados por pessoas que saíram são os mais propensos a estar desatualizados e os menos propensos a serem revisados.

Você pode listar todos os triggers configurados com a AppSignal CLI ou pelo MCP server para revisá-los sem abrir cada um na interface.

​

Recapitulando: ajustar um trigger que envia notificações demais

Esta seção não introduz nada novo. Ela coloca as seções anteriores em ordem contra um exemplo: um trigger de uso de CPU do host acima de 80%, sem warm-up, sem cooldown e com o hostname padrão *, enviando várias notificações de plantão por noite quando não há problema visível ao usuário.

1. Verifique a métrica. Uso de CPU é uma causa, não um sintoma visível ao usuário, e tempo de resposta e taxa de erros estão saudáveis durante os picos de CPU.
2. Restrinja o escopo. Os picos vêm de workers em background, então o hostname passa a ser web-*.
3. Defina o limite a partir do histórico. Duas semanas de dados mostram hosts web alcançando rotineiramente 85% no pico da noite, então o limite vai para 95%.
4. Adicione um warm-up. Dois minutos, porque um pico curto de CPU é normal e não deveria notificar o plantão.
5. Adicione um cooldown. Defina um cooldown curto, para que um host perto do limite produza um alerta em vez de seis.
6. Redirecione-o. Saturação de CPU sustentada é um problema de capacidade, não uma queda, então vai para o chat da equipe e o notifier de plantão é removido.
7. Adicione o alerta que faltava. A equipe precisava de um alerta de impacto no usuário, então adiciona um trigger de tempo de resposta p95 no namespace web, direcionado ao plantão. Alerting em produção cobre como encontrar o resto.

O resultado é menos notificações, e as que restam descrevem algo sobre o que uma pessoa pode agir.

​

Próximos passos

• Escolha o que monitorar com os guias para criar alertas.
• Verifique a ordem de configuração e a cobertura com alerting em produção.
• Revise em detalhe como warm-up e cooldown funcionam.
• Configure as configurações de notificação para incidents de erro e de desempenho.
• Configure check-ins para trabalho agendado em vez de usar warm-ups longos.