> ## Documentation Index
> Fetch the complete documentation index at: https://docs.appsignal.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Detecção de anomalias
Com a [Detecção de anomalias](https://appsignal.com/redirect-to/app?to=alerts), 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](#warm-up-and-cooldown) para controlar quando um novo alerta é aberto.
## Estados do alerta
Os alertas podem ter cinco estados diferentes:
| Estado | Descrição |
| ---------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Aquecendo | O 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. |
| Aberto | O alerta ficou ativo porque atingiu sua condição de limite. |
| Fechado | O alerta não está mais ativo e foi fechado. |
| Resfriando | O 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. |
| Encerrado | O 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. |
### 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"](https://appsignal.com/redirect-to/app?to=alerts) 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](https://appsignal.com/redirect-to/app?to=triggers) para criar novos triggers e editar os existentes.
Você pode criar e gerenciar Triggers a partir da [seção "Detecção de anomalias"](https://appsignal.com/redirect-to/app?to=triggers) do menu de navegação da sua aplicação.
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:
```ruby Ruby theme={null}
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.
## 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](/appsignal/how-appsignal-operates#agent).
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](https://en.wikipedia.org/wiki/Network_Time_Protocol). 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][data life cycle].
\*: Para mais informações sobre os detalhes do tempo de espera, consulte nossa [página de ciclo de vida dos dados][data life cycle].
[data life cycle]: /appsignal/data-life-cycle.html
## 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](#alert-states).
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:
