Com o Anomaly detection, você pode configurar triggers para enviar notificações quando o valor de uma métrica sobe acima ou cai abaixo de um limite. Por exemplo: quando a taxa de erros de uma aplicação passa de 5% ou a memória livre cai abaixo de 100 MB.
O Anomaly detection verifica os valores das métricas uma vez por minuto. Quando uma métrica atinge uma condição de limite, o AppSignal abre um alerta e notifica os notifiers selecionados. O AppSignal os notifica novamente quando a condição de limite deixa de ser atendida.
Use as configurações de warm-up e cooldown para controlar quando um novo alerta abre e fecha.
Para orientação sobre escolher limites e manter o volume de alertas administrável, veja ajuste seus alertas e guias para criar alertas.
Estados do alerta
Alertas podem ter cinco estados:
Quando serei notificado?
O AppSignal notifica você em duas transições de estado: quando um alerta abre e quando ele é resolvido.
E-mail também pode enviar lembretes enquanto um alerta permanece aberto. Todos os outros canais, incluindo Slack, PagerDuty, Opsgenie e webhooks, são notificados apenas nas transições de abertura e de resolução.
Alertas são enviados aos notifiers selecionados no trigger, não a todos os notifiers configurados no app.
Silenciar um trigger
Diferente de incidentes de erro, alertas não têm opções de frequência de notificação. Não existe configuração Never Notify nem Every Nth per Hour, porque as notificações seguem a máquina de estados do alerta em vez de uma contagem de ocorrências.
Para impedir que um trigger notifique alguém, remova seus notifiers. Para impedir que ele produza alertas por completo, arquive-o.
O direcionamento de alertas de trigger é controlado no próprio trigger. Selecione os notifiers que devem receber alertas daquele trigger, ou remova todos os notifiers para manter o trigger ativo sem enviar notificações.
Alertas por e-mail
E-mails de alerta incluem uma visão geral de novos alertas, lembretes e o status de outros alertas que ainda não foram encerrados.
Criando e configurando triggers
Configure o Anomaly detection por app na seção “Anomaly detection” da navegação do app. A visão geral de alertas mostra os alertas mais recentes criados pelos triggers configurados para o app.
Abra a página de triggers para criar e editar triggers. Selecione Add trigger para abrir o seletor de métricas, e então escolha um tipo de trigger em Tracing, Host metrics ou Other. Triggers de métricas personalizadas estão listados em Other como Custom metrics.
Você pode configurar triggers com uma variedade de métricas:
- Taxas de erro
- Contagens de erro (absolutas)
- Throughput do app
- Desempenho de actions (actions lentas)
- Tempo de fila
- Métricas de host
- Carga de CPU
- I/O de disco
- Uso de disco
- Load averages
- Uso de memória
- Uso de rede
Warm-up e cooldown
Você pode configurar as opções de warm-up e cooldown para cada trigger. Essas configurações definem por quanto tempo o AppSignal espera antes de abrir e fechar um alerta.
Warm-up
Não use anomaly detection e warm-up para verificar se jobs de hora em hora, jobs diários ou cron jobs estão rodando.
Cooldown
Alertas abertos por um trigger são fechados automaticamente quando a condição de limite deixa de ser atendida. Para evitar notificações repetidas de abertura e fechamento para o mesmo problema, configure um período de cooldown.
Se você configurar um período de cooldown, o AppSignal não criará um novo alerta a menos que a condição do trigger seja atendida novamente após o período de cooldown expirar.
Por exemplo:
- Um alerta abre porque a taxa de erros está acima de 5%.
- A taxa de erros cai, então o alerta fecha.
- O trigger tem um período de cooldown de dois minutos.
- A taxa de erros sobe acima de 5% novamente.
- O AppSignal não cria um novo alerta a menos que a taxa de erros passe de 5% após o fim do período de cooldown.
Algumas métricas exigem que tags também sejam selecionadas. Por exemplo, se você está enviando ao AppSignal uma métrica personalizada que tem tags:
Ao criar um trigger para essa métrica, selecione tags também.
Quando você informa tags, o AppSignal lista as combinações de tags que viu para aquela métrica e avisa quando a combinação informada não foi vista na última hora. Esse aviso normalmente significa que o trigger não corresponderá a nenhum dado.
Use uma das combinações de chaves de tag que o AppSignal lista para a métrica, como namespace ou namespace, queue. Valores de tag podem ser valores exatos como namespace=web ou curingas como queue=*.
Um trigger pode abrir vários alertas
Um trigger abre um alerta por série correspondente, não um alerta no total. Um trigger que corresponde a 30 hosts abre 30 alertas quando todos os 30 cruzam o limite.
Triggers de métricas de host tornam isso fácil de passar despercebido, porque o campo hostname aceita curingas e seu valor padrão * corresponde a todo host que reporta ao app. Informe um hostname específico, ou um prefixo como web-*, para limitar quais hosts um trigger cobre.
O mesmo vale para tags em qualquer outra métrica. Quanto mais restrito o filtro de tags, mais específico o alerta, e menos notificações um único incidente produz.
Editando e arquivando triggers
Alterar ou arquivar um trigger pode afetar os alertas e incidentes vinculados a ele.
Editar ou arquivar um trigger pode ter estes efeitos:
- Alertas ainda em sua fase de warm-up são descartados.
- Alertas abertos são fechados e marcados como arquivados.
- Ao editar um trigger, incidentes de anomalia abertos do trigger anterior são vinculados ao novo trigger, para que o histórico do incidente e o logbook continuem disponíveis após a edição.
- Ao arquivar um trigger sem substituí-lo, incidentes de anomalia abertos daquele trigger são fechados.
Evite reajustar um trigger enquanto ainda acompanha um alerta ativo por meio dele.
Pontos de dados faltantes como 0
Por padrão, triggers assumem que um ponto de dados é enviado a cada minuto.
Isso pode não ser viável em situações como incrementar um contador apenas quando uma action específica ocorre. Nesses casos, ative Treat missing datapoints as 0. O AppSignal então trata um ponto de dados faltante como zero, o que ajuda um alerta a fechar quando nenhum dado chega no minuto seguinte. Isso também torna possíveis alertas de ausência, como alertar quando uma métrica chega a 0.
Processamento de dados
As métricas usadas pelos triggers para criar alertas não são processadas instantaneamente quando as métricas são enviadas da sua aplicação para o AppSignal.
Seus dados de métricas passam por vários sistemas antes de chegarem ao nosso processador. Os dados também podem ser enviados de vários servidores que enviam dados em intervalos diferentes.
O processador então espera* até que todos os dados de um minuto tenham chegado antes de processá-los e criar ou atualizar alertas.
Se você tiver problemas com as métricas que o AppSignal reporta para anomaly detection, garanta que os servidores da sua aplicação reportem simultaneamente configurando-os com NTP. Horários reportados incorretos ou diferentes por vários servidores do app podem impedir que alertas abram ou fechem.
Você pode saber mais sobre como o AppSignal processa dados para o Anomaly detection e o que isso significa para os alertas na nossa documentação do ciclo de vida dos dados.
*: Para mais informações sobre os tempos de espera, consulte nossa página do ciclo de vida dos dados.
Gerenciando incidentes
Você pode ver todos os incidentes de alerta na página Anomaly Issues do app AppSignal. A página Issues exibe uma visão geral de todos os incidentes de alerta abertos, ordenados pela última ocorrência, com colunas para a anomalia:
- Nome
- Status
- Responsáveis
- Estado
- Horário da última mudança de estado
Você também pode filtrar facilmente seus incidentes com base no estado deles.
Para investigar um incidente mais a fundo, você pode abrir o resumo do incidente. Ali você encontra todas as ferramentas e informações necessárias para investigar melhor a anomalia que disparou seu alerta. Na página de resumo, você tem acesso a:
- Informações do alerta: o nome da métrica, o estado do alerta e as tags do alerta.
- Gráfico de frequência de ocorrências: uma representação visual das ocorrências do alerta.
- Configurações do incidente: possibilidade de fechar o alerta, definir sua severidade e atribuí-lo a alguém da equipe.
- Informações do trigger: as condições necessárias para disparar o alerta.
- Últimas ocorrências: uma tabela das ocorrências mais recentes, com horário de início e fim, estado e valor de pico.
- Logbook: um logbook para registrar informações importantes sobre este alerta para sua equipe ou para você mesmo no futuro.
- Acesso ao Time Detective: use o Time Detective para ver o estado da sua aplicação na última vez que o alerta ocorreu.
Todos esses recursos são facilmente acessíveis na nossa interface intuitiva:
