> ## 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.

# Alertas no AppSignal

> Aprenda qual recurso de alerta do AppSignal usar, com quais alertas as equipes costumam começar e como evitar alertas ruidosos.

Alertas ajudam sua equipe a perceber comportamentos que precisam de atenção antes que os clientes precisem avisar você. No AppSignal, os alertas mais úteis são específicos, direcionados às pessoas certas e urgentes apenas quando um humano precisa agir.

O AppSignal tem cinco sistemas de alertas:

| Sistema                                                                           | Use para                                                                              | Exemplo                                                                                                                                     |
| --------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- |
| <Icon icon="heart-pulse" /> [Uptime monitoring](/uptime-monitoring/setup)         | Uma verificação externa de que seus endpoints públicos ainda respondem                | Alertar quando um endpoint de health-check para de retornar `2xx` a partir de qualquer região                                               |
| <Icon icon="bell" /> [Incident notifications](/application/notification-settings) | Erros e incidentes de desempenho que o AppSignal já detecta no seu app                | Notificar a equipe na primeira vez que um erro aparece após um deploy, ou quando um incident fechado começa a acontecer de novo             |
| <Icon icon="gauge-high" /> [Anomaly detection triggers](/anomaly-detection)       | Alertas de limite em métricas internas e [métricas personalizadas](/metrics/custom)   | Alertar quando a taxa de erros permanece acima de `5%`, o tempo de resposta `p95` sobe, o throughput cai ou o uso de disco ultrapassa `85%` |
| <Icon icon="file-lines" /> [Log triggers](/logging/triggers)                      | Padrões em logs que devem alertar mesmo quando nunca se tornam um incident ou métrica | Alertar quando um provedor de pagamentos começa a registrar timeouts repetidos                                                              |
| <Icon icon="clock" /> [Check-in triggers](/check-ins)                             | Cron jobs, heartbeats e outros processos que devem reportar no horário                | Alertar quando uma tarefa noturna não termina, ou um worker para de enviar heartbeats                                                       |

O Uptime monitoring verifica seus endpoints a partir dos servidores do AppSignal em várias regiões pela internet pública; os outros quatro alertam com base em dados que seu app já envia ao AppSignal. Muitas equipes o configuram primeiro, porque ele detecta uma queda mesmo quando o app não consegue enviar nada.

## O que são alertas

Alertas transformam telemetria em ação. Eles ajudam você a responder perguntas como:

* O app está fora do ar?
* Os usuários estão vendo mais erros do que o normal?
* O tráfego caiu porque algo upstream falhou antes das requisições chegarem ao app?
* Uma fila em background está acumulando?
* Uma tarefa agendada parou de rodar?

Uma boa regra é alertar sobre os sintomas que os usuários sentem, não sobre cada causa interna. Essa é a ideia por trás dos [“quatro sinais de ouro”](https://sre.google/sre-book/monitoring-distributed-systems/) da SRE: latência, tráfego, erros e saturação. No AppSignal, eles correspondem a tempo de resposta, throughput, taxa de erros, métricas de host e crescimento de fila.

## Escolha o sistema de alerta certo

Use incident notifications quando o AppSignal já tem um incident e você quer controlar quem é notificado e com que frequência. Este é um bom padrão para exceções e ações lentas que você já sabe que importam.

Use anomaly detection triggers quando quiser alertas baseados em limite sobre métricas. Esta é a opção mais flexível para cobertura no estilo SRE, incluindo taxa de erros, percentis de tempo de resposta, throughput, tempo de fila, métricas de host e métricas personalizadas.

Use log triggers quando o sinal existe nos logs, mas ainda não como um incident ou métrica dedicada. Eles funcionam bem para falhas específicas de integração, como um banco ou provedor apresentando timeout enquanto o restante do sistema parece saudável.

Use check-in triggers quando sucesso significa “este processo reportou no horário”. Eles são a ferramenta certa para cron jobs, heartbeats, workers e tarefas agendadas.

## Um conjunto inicial prático

Para a maioria dos apps em produção, um conjunto inicial útil tem esta aparência:

1. Uma verificação de uptime para seu endpoint público de health-check.
2. Um anomaly trigger para a taxa de erros do `web`.
3. Um anomaly trigger para o tempo de resposta `p90` ou `p95` no tráfego crítico voltado ao usuário.
4. Um anomaly trigger para quedas de throughput.
5. Um anomaly trigger para tempo de fila, profundidade de fila ou backlog de jobs em background.
6. Triggers de métricas de host para CPU, memória e disco.
7. Check-ins para cron jobs, tarefas agendadas e workers de longa duração.

## Alertas populares para começar

Estes são alertas iniciais comuns para equipes que querem cobertura ampla sem muito ruído:

| Alerta                                               | Por que ajuda                                                                                                 | Recurso do AppSignal                            |
| ---------------------------------------------------- | ------------------------------------------------------------------------------------------------------------- | ----------------------------------------------- |
| Taxa de erros no namespace `web`                     | O sinal mais rápido de que os usuários estão encontrando falhas                                               | [Anomaly detection trigger](/anomaly-detection) |
| Tempo de resposta `p90` ou `p95` para ações críticas | Médias escondem uma experiência lenta para parte do seu tráfego                                               | [Anomaly detection trigger](/anomaly-detection) |
| Queda de throughput                                  | Uma queda acentuada muitas vezes significa que algo upstream falhou antes das requisições chegarem ao seu app | [Anomaly detection trigger](/anomaly-detection) |
| Crescimento de tempo de fila ou backlog              | Aviso antecipado antes que os usuários percebam atrasos                                                       | [Anomaly detection trigger](/anomaly-detection) |
| Uso de CPU, memória e disco                          | Alerta de infraestrutura para problemas de saturação e capacidade                                             | [Anomaly detection trigger](/anomaly-detection) |
| Endpoint de health-check falhando                    | Confirma que o app está inacessível de fora da sua infraestrutura                                             | [Uptime monitoring](/uptime-monitoring/setup)   |
| Heartbeat de cron job ou worker ausente              | Confirma que o trabalho em background esperado continua rodando                                               | [Check-in trigger](/check-ins)                  |

## O que os SREs costumam querer cobrir

Se você está criando cobertura de alertas do zero, estas são prioridades comuns:

* Erros visíveis ao usuário
* Requisições lentas de usuários, especialmente em `p90` ou `p95`
* Quedas de tráfego e mudanças incomuns de throughput
* Crescimento de filas em background e jobs atrasados
* Saturação de host, como CPU, memória e disco
* Tarefas agendadas que falham em iniciar, terminar ou reportar
* Problemas de dependências externas, como APIs de banco lentas, timeouts ou tempestades de retry

É também por isso que deploy markers importam, mesmo que não sejam um tipo de alerta por si só. Eles ajudam você a responder se o alerta começou logo após um release.

## Configure alertas com sucesso

Um bom sistema de alertas trata principalmente de escopo e roteamento:

* Adicione notifiers primeiro nas páginas [Integrations](/application/integrations) e [Notifications](https://appsignal.com/redirect-to/app?to=notifiers). Cada trigger pode usar um notifier diferente, então você pode rotear por severidade.
* Envie alertas urgentes de produção para uma ferramenta on-call como [PagerDuty](/application/integrations/pagerduty), [Opsgenie](/application/integrations/opsgenie) ou outro webhook notifier.
* Envie avisos e degradações para chat ou e-mail, como o [Slack](/application/integrations/slack). Dê ao staging seu próprio canal ou silencie-o.
* Defina [padrões de notificação por namespace](/application/notification-settings#organization-and-app-namespace-defaults) para que `web`, `background` e `admin` possam notificar equipes diferentes por padrão.
* Comece com alertas ligados ao impacto no usuário, depois adicione verificações operacionais mais restritas conforme perceber o que é útil.

## Evite alertas ruidosos

Esta é a parte que separa um alerta útil de um que a equipe aprende a ignorar:

* Defina limites a partir do histórico real, não por suposição. Revise algumas semanas da tendência da métrica antes de escolher um limite.
* Use [janelas de warm-up](/anomaly-detection#warm-up-and-cooldown) para que uma condição precise se manter por vários minutos antes que o alerta abra. Três a cinco minutos é um ponto de partida comum, e a maioria dos falsos alarmes são picos de um único minuto.
* Use pelo menos um warm-up de um minuto em uptime monitors para tolerar pequenas oscilações de rede.
* Adicione um [cooldown](/anomaly-detection#warm-up-and-cooldown) para que um sinal instável se torne um alerta mais longo, em vez de abrir e fechar repetidamente.
* Prefira taxas em vez de contagens absolutas quando o tráfego muda ao longo do dia. A taxa de erros geralmente é mais útil que a contagem bruta de erros.
* Prefira `p90` ou `p95` para alertas sensíveis à latência, em vez de depender de médias.
* Restrinja o escopo dos alertas por namespace, ação ou tags para que a notificação diga exatamente o que está afetado.
* Um bom alerta sustentado supera cinco nervosos. Envie apenas alertas urgentes voltados ao cliente para o on-call, e o restante para o chat.

## Configurar uptime monitoring

1. Crie um endpoint dedicado de health-check se ainda não tiver um.
2. Adicione um [uptime monitor](/uptime-monitoring/setup) para esse endpoint.
3. Escolha um notifier para notificações de downtime.
4. Defina pelo menos um warm-up de um minuto para que pequenas oscilações de rede não abram alertas.
5. [Ignore o endpoint de health-check](/uptime-monitoring/setup#plans-and-requests) no seu app do AppSignal se não quiser que essas requisições sejam contabilizadas no volume mensal de requisições.

Use uptime monitoring para “o app está acessível de fora?” Use check-ins para “este processo agendado ou em background reportou no horário?”

## Exemplos

### Exemplo de incident notification

Use incident notifications quando o AppSignal já criou um incident de erro ou desempenho e você precisa principalmente do comportamento de notificação correto.

Por exemplo:

1. Use **First in Deploy** para erros de produção que devem alertar apenas uma vez por release.
2. Use **First After Close** para incidents causados por sistemas externos que podem se recuperar sem um deploy.
3. Use **Every Nth per Hour** ou **Every Nth per Day** para erros conhecidos e ruidosos onde o volume importa mais do que cada ocorrência individual.

Combinar incident notifications com [deploy markers](/application/markers/deploy-markers) torna muito mais fácil responder: “Isso começou após nosso último deploy?”

### Exemplo de log trigger

Use log triggers quando os logs contêm o sinal que você precisa. Por exemplo, um fluxo de pagamento ou cadastro pode fazer retry quando uma API de banco está lenta, então uma única falha pode não merecer uma notificação urgente, mas um padrão sustentado sim.

```sql SQL theme={null}
severity=error provider=bank-a message:timeout
```

Um trigger como este pode notificar a equipe quando um provedor começa a apresentar timeouts. Se retries são comuns, use **First After Close** ou **Nth in an hour** em vez de alertar em cada linha de log correspondente.

### Exemplo de alerta de métrica personalizada

Se você envia métricas personalizadas, pode alertar sobre elas com [anomaly detection](/anomaly-detection).

Por exemplo, você pode enviar:

* Um counter para pagamentos ou cadastros bem-sucedidos
* Um gauge para profundidade de fila ou contagem de workers ativos
* Uma measurement para o tempo de resposta do provedor

Depois que a métrica aparecer no AppSignal:

1. Faça o gráfico primeiro e revise seu histórico recente.
2. Escolha o campo que corresponde à pergunta que você está fazendo: `gauge`, `counter`, `count`, `mean`, `p90` ou `p95`.
3. Filtre por tags como `provider=bank-a` ou `region=eu` quando precisar de um alerta mais restrito.
4. Adicione o notifier certo para a severidade do problema.
5. Adicione warm-up e cooldown antes de depender do alerta em produção.

## Próximos passos

* Revise as [notification settings](/application/notification-settings) para alertas baseados em incidents.
* Crie [anomaly detection triggers](/anomaly-detection) para métricas e limites.
* Configure [uptime monitoring](/uptime-monitoring/setup) para uma verificação externa de saúde.
* Crie [process monitors and check-ins](/check-ins/create) para cron jobs e heartbeats.
* Use [log triggers](/logging/triggers) para alertas baseados em logs.