Pular para o conteúdo principal
Com a Detecção de anomalias, você pode configurar Triggers para enviar notificações quando o valor de uma métrica ultrapassa ou cai abaixo de um valor limite. Por exemplo: quando a taxa de erros de uma aplicação ultrapassa 5% ou a memória livre cai abaixo de 100MB. A detecção de anomalias funciona detectando alterações nos valores das métricas a cada minuto. Quando uma condição de limite é atingida, vamos notificá-lo sobre o novo alerta criado por esse evento e notificá-lo novamente quando o limite não estiver mais sendo alcançado. Para garantir que você seja alertado em um momento que lhe convém, é possível definir aquecimentos e resfriamentos para controlar quando um novo alerta é aberto.

Estados do alerta

Os alertas podem ter cinco estados diferentes:
EstadoDescrição
AquecendoO alerta está em sua fase de aquecimento. Você pode configurar por Trigger que uma condição precise ser verdadeira por um determinado período antes de ser alertado.
AbertoO alerta ficou ativo porque atingiu sua condição de limite.
FechadoO alerta não está mais ativo e foi fechado.
ResfriandoO alerta não está mais acima da sua condição de limite, mas não será encerrado nem reaberto até o fim da duração do resfriamento.
EncerradoO alerta foi encerrado. Nenhum outro alerta será enviado. Se as condições do trigger forem acionadas novamente, um novo alerta entrará na fase de aquecimento.
Estados do alerta

Quando serei notificado?

Depois de configurar as notificações, você será notificado quando um alerta passar para a fase aberta. Você será notificado por quaisquer lembretes que tenha configurado durante essa fase e quando o alerta for fechado.

Alertas por e-mail

Os e-mails de alerta incluirão uma visão geral dos novos alertas, lembretes e o status de outros alertas que ainda não foram encerrados.

Criando e configurando triggers

A detecção de anomalias pode ser configurada por aplicação na seção “Detecção de anomalias” na navegação da aplicação. Por padrão, você verá os alertas mais recentes criados pelos triggers que configurou para a aplicação. Na navegação superior, você pode alternar para a página de triggers para criar novos triggers e editar os existentes. Você pode criar e gerenciar Triggers a partir da seção “Detecção de anomalias” do menu de navegação da sua aplicação. Criando um trigger Você pode configurar Triggers com uma variedade de métricas:
  • Taxas de erro
  • Contagens (absolutas) de erros
  • Throughput da aplicação
  • Performance de actions (slow actions)
  • Tempo de fila
  • Métricas de host
    • Carga de CPU
    • I/O de disco
    • Uso de disco
    • Médias de carga
    • Uso de memória
    • Uso de rede

Aquecimento e resfriamento

Você pode configurar definições de aquecimento e resfriamento para cada trigger, permitindo definir o tempo que o sistema espera antes de abrir e fechar um alerta.

Aquecimento

Não é recomendado usar a Detecção de anomalias e o recurso de aquecimento para verificar se serviços como jobs horários/diários e cronjobs estão em execução.
Normalmente, quando a condição de limite de um Trigger é atingida, ele abre um alerta; por exemplo, a taxa de erros é superior a 5%. Quando um período de aquecimento é configurado no Trigger, o AppSignal só abrirá um alerta depois que esse tempo passar e se o limite do trigger ainda estiver sendo atingido; por exemplo, a taxa de erros é maior que 5% por mais de 3 minutos. Quando um trigger tem um período de aquecimento configurado, o alerta só será aberto após o término do tempo de aquecimento. A condição de limite deve ser atendida durante todo o período de aquecimento para que o alerta seja aberto. O AppSignal vai notificá-lo quando o status do alerta passar de aquecimento para aberto.

Resfriamento

Os alertas abertos por um Trigger são automaticamente fechados quando a condição de limite não é mais atendida. Para evitar ser notificado em excesso, você pode configurar períodos de resfriamento. Se você configurou um período de resfriamento para um Trigger, um novo alerta não será criado a menos que as condições do Trigger sejam atendidas após o término do período de resfriamento. Por exemplo:
  1. Um alerta é aberto porque a taxa de erros é superior a 5%
  2. A taxa de erros cai, então o alerta é fechado automaticamente.
  3. O trigger do alerta tem um período de resfriamento de dois minutos.
  4. A taxa de erros ultrapassa 5% novamente.
  5. O AppSignal não criará um novo alerta a menos que a taxa de erros exceda 5% após o fim do período de resfriamento.

Tags

Algumas métricas exigem que tags também sejam selecionadas. Por exemplo, se você estiver enviando uma métrica personalizada para o AppSignal que tenha tags:
Appsignal.set_gauge("my_metric_name", 100, :namespace => "web", :action => "hello")
Então, ao criar um Trigger para essa métrica, você também precisa selecionar tags. Trigger com tags

Pontos de dados ausentes como 0

Por padrão, os Triggers presumem que um ponto de dados é enviado a cada minuto. Isso pode não ser viável em certas situações, como incrementar um contador apenas se uma ação específica ocorrer. Nesses casos, você pode usar a opção "When checked, we will treat missing datapoints as a value of 0". Habilitar essa opção fará com que o sistema assuma que um ponto de dados ausente tem o valor zero. Isso ajudará a garantir que o alerta seja fechado conforme esperado se nenhum dado for recebido no minuto seguinte.

Processamento de dados

As métricas usadas pelos triggers para criar alertas não são processadas instantaneamente quando enviadas da sua aplicação para o AppSignal. Seus dados de métricas passarão por vários sistemas antes de chegar ao nosso processador. Os dados também podem ser enviados de vários servidores que enviam dados em intervalos diferentes. O processador então aguarda* até que todos os dados de um minuto cheguem antes de processar esses dados e criar ou atualizar alertas. Se você tiver problemas com as métricas relatadas pelo AppSignal para a Detecção de anomalias, certifique-se de que todos os servidores da sua aplicação estejam relatando simultaneamente, configurando-os via NTP. Horários relatados incorretos ou diferentes para dados enviados por vários servidores de aplicação podem fazer com que os alertas nunca sejam abertos ou fechados. Você pode saber mais sobre como o AppSignal processa dados para Detecção de anomalias e o que isso significa para os alertas em nossa documentação do ciclo de vida dos dados. *: Para mais informações sobre os detalhes do tempo de espera, consulte nossa página de ciclo de vida dos dados.

Gerenciando incidentes

Você pode visualizar todos os incidentes de alerta na página de Anomaly Issues no aplicativo AppSignal. A página de Issues mostra 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
  • Hora da última mudança de estado
Você também pode filtrar facilmente seus incidentes com base em seu estado. Visão geral dos incidentes de alerta Para investigar um incidente mais a fundo, você pode abrir o resumo do incidente. Aqui você encontrará todas as ferramentas e informações necessárias para investigar mais a fundo a anomalia que disparou o alerta. Na página de resumo, você terá 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 da ocorrência do alerta.
  • Configurações do incidente: possibilidade de fechar o alerta, definir sua severidade e atribuí-lo a um membro da equipe.
  • Informações do Trigger: as condições necessárias para acionar o alerta.
  • Últimas ocorrências: uma tabela das ocorrências mais recentes, com horário de início/fim, estado e valor de pico.
  • Logbook: um diário para registrar informações importantes deste alerta para sua equipe ou para você no futuro.
  • Acesso ao Time Detective: use a ferramenta Time Detective para visualizar o estado da sua aplicação quando o alerta ocorreu pela última vez.
Todos esses recursos estão facilmente acessíveis em nossa interface intuitiva: Visão geral da página do incidente de alerta