> ## 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. # Alerting em produção > Configure alertas para um ambiente de produção em camadas, verifique lacunas na sua cobertura e decida com que rapidez você precisa saber de cada tipo de falha. Esta página trata de acertar os alertas de produção na primeira tentativa: o que configurar, em que ordem, como confirmar que funciona e como verificar que nada importante está sem monitoramento. Ela assume que você sabe sobre o que quer alertar. Se ainda não sabe, comece pelos [guias para criar alertas](/alerting/recipes). Se você já tem alertas e eles são ruidosos demais, vá para [ajuste seus alertas](/alerting/tuning). ## Antes de criar um trigger Três passos de configuração tornam mais útil cada alerta que vem depois, e todos os três são mais fáceis de fazer primeiro do que de adaptar depois. **Adicione seus notifiers.** Triggers referenciam notifiers, então criá-los primeiro significa que você pode direcionar cada alerta enquanto o constrói, em vez de revisar tudo mais tarde. Configure pelo menos dois destinos: um para o urgente, como uma ferramenta de plantão, e um para o não urgente, como um canal de chat da equipe. Notifiers são configurados uma vez para a organização e compartilhados entre apps. **Envie [deploy markers](/application/markers/deploy-markers).** A maioria dos incidentes em produção começa com um release. Um marker transforma “quando isso começou?” em uma pergunta que você responde em segundos, e é o que faz a [configuração de notificação **First in Deploy**](/application/notification-settings#first-in-deploy) funcionar. **Divida seu app em [namespaces](/application/namespaces).** Namespaces são a principal alavanca para alertar em diferentes severidades sem configurar cada alerta individualmente. Se o tráfego `web`, `background` e `admin` cai todo em um namespace, cada limite que você define precisa servir aos três ao mesmo tempo, o que normalmente significa que não serve a nenhum. ## Adicione alertas em camadas Adicionar todos os alertas de uma vez produz notificações demais no primeiro dia e ensina a equipe a ignorá-las. Adicione uma camada, conviva com ela por uma semana e então adicione a próxima. 1. **Acessibilidade.** Um [uptime monitor](/uptime-monitoring/setup) em um endpoint de health-check. Este é o único alerta que ainda funciona quando sua aplicação não consegue reportar nada. 2. **Sintomas visíveis ao usuário.** Taxa de erros e tempo de resposta no seu namespace voltado ao usuário. Esses alertas correspondem a erros ou tempos de resposta lentos vivenciados pelos usuários. 3. **Trabalho agendado e em background.** [Check-ins](/check-ins) para cron jobs e heartbeats de workers, e um alerta de ausência para qualquer fila que nunca deveria estar sem atividade. 4. **Saturação.** Disco, memória e swap do host. Estas são causas, não sintomas, então direcione-as para o chat em vez do plantão. 5. **Métricas de negócio.** [Métricas personalizadas](/metrics/custom) para a atividade específica da aplicação que só você pode medir, como pagamentos concluídos ou cadastros por minuto. As camadas um e dois cobrem a maioria dos incidentes reais. A camada cinco detecta falhas específicas da aplicação que outros alertas não conseguem detectar. ## Mantenha o ruído de staging e de testes fora da produção Os alertas de produção só continuam confiáveis se o ruído de ambientes que não são produção nunca chegar até eles. * Dê a cada ambiente seu próprio app no AppSignal, para que limites e notifiers sejam definidos por ambiente em vez de compartilhados. * Dê ao staging seu próprio canal de chat, ou deixe os triggers de staging sem nenhum notifier. Um trigger sem notifier ainda registra alertas que você pode revisar depois, sem notificar ninguém. * Use limites diferentes. O tráfego de staging é menor e muda mais do que o de produção, então um limite ajustado com dados de produção pode nunca abrir um alerta, ou pode abrir alertas com frequência excessiva. * Mantenha canais de teste pessoais fora dos apps de produção. Um notifier pode ser compartilhado por vários apps, e alertas de trigger são direcionados pelos notifiers selecionados em cada trigger. ## Verifique sua cobertura Notificações em excesso são a falha visível. A falha oculta é uma queda sobre a qual ninguém foi alertado. Percorra os modos de falha em vez dos recursos, e verifique se cada um tem um alerta: | Se isso acontecer | O que detecta | | ---------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------- | | A aplicação está completamente inacessível | [Uptime monitor](/uptime-monitoring/setup) | | A aplicação responde mas retorna erros, então ações como adicionar um item ao carrinho falham | Trigger de taxa de erros no namespace voltado ao usuário | | A aplicação responde lentamente | Trigger de desempenho `p90` ou `p95` | | As requisições param de chegar, porque algo upstream falhou antes de alcançarem o app | Piso de throughput, ou um trigger com throughput igual a `0` | | Um worker em background morre, então e-mails de confirmação ou faturas param de ser enviados | Alerta de ausência em um contador de jobs, ou um [check-in](/check-ins) de heartbeat | | Uma tarefa agendada não roda, então os dados de hoje estão faltando | [Check-in](/check-ins) de cron | | Uma fila acumula, então o trabalho é aceito mas leva horas para ser processado | Trigger de profundidade de fila ou de tempo de fila | | Um host fica sem disco, memória ou swap, então a aplicação para abruptamente | Triggers de métricas de host | | Uma dependência falha de forma intermitente mas os retries funcionam, como um provedor de pagamentos ou parceiro de entrega | [Log trigger](/logging/triggers), ou uma métrica extraída dessas linhas de log | | Um processo de negócio para sem que erros apareçam no AppSignal, como pedidos, pagamentos ou reservas que deixam de ser concluídos | Métrica personalizada igual a `0`, ou abaixo de um limite mínimo | | Um certificado TLS está perto de expirar, então navegadores avisam que o site não é seguro | Monitoramento de expiração de SSL, disponível como recurso do [AppSignal Labs](/labs) | | Uma métrica para de ser reportada por completo | Um trigger com **treat missing datapoints as 0** ativado | A última linha é a que mais costuma faltar. Todo outro alerta desta lista precisa que dados cheguem antes de poder abrir. Duas perguntas são úteis para revisar o conjunto inteiro. Primeiro, para cada linha que você cobriu, o alerta chega a alguém que pode agir no horário do dia em que ele tem mais chance de abrir? Segundo, dos seus últimos incidentes em produção, quantos foram relatados primeiro por uma pessoa em vez de por um alerta? Esse segundo número é uma medida útil de cobertura. ## Decida com que rapidez você precisa saber A detecção não é instantânea, e vale a pena decidir deliberadamente quanto atraso cada alerta pode carregar. Três fatores somam-se para formar o tempo entre o início de um problema e a chegada de uma notificação: * **Agregação.** Métricas são avaliadas uma vez por minuto, então sempre há até um minuto antes de o valor em questão ser considerado. * **[Processamento](/anomaly-detection#data-processing).** O AppSignal espera um minuto pelos dados de todos os seus servidores antes de avaliá-los. * **Warm-up.** O número de minutos que o AppSignal espera antes de abrir o alerta. O warm-up atrasa o alerta. Se um trigger tem warm-up de 2 minutos, a métrica precisa permanecer acima ou abaixo do limite por 2 minutos antes de o AppSignal abrir o alerta. Estes são alvos razoáveis para a rapidez com que você precisa saber de cada tipo de falha: * **Checkout ou pagamentos quebrados, então clientes não conseguem comprar, reservar ou transferir dinheiro.** O mais rápido possível, com pouco ou nenhum warm-up. * **Site ou app inacessível.** 1–2 minutos. * **Taxa de erros elevada, então clientes estão encontrando erros.** 1–2 minutos. * **Degradação do tempo de resposta, então requisições demoram mais que o normal.** 1–3 minutos. * **Fila acumulando, então o trabalho ainda é processado mas chega atrasado.** 1–3 minutos. * **Uso de disco se aproximando da capacidade total.** 10–60 minutos. Se um alerta é ruidoso mas também precisa ser rápido, não resolva isso com um warm-up mais longo. Em vez disso, restrinja o escopo ou mova o limite: ambos reduzem falsos alarmes sem custar tempo de detecção. Anomaly detection não pode dizer que algo não aconteceu dentro de uma janela mais curta que os dados que ela recebe. Não use um warm-up longo como substituto para [check-ins](/check-ins) ao monitorar trabalho agendado. ## Verifique um alerta antes de confiar nele Um trigger que não corresponde a nada pode parecer um sistema saudável. Antes de contar um alerta como cobertura, confirme tudo o seguinte: 1. **A prévia do gráfico mostra dados.** Uma prévia vazia no formulário do trigger significa que o trigger atualmente não corresponde a nada. 2. **O hostname é resolvido.** Se o campo hostname avisar que o host não foi encontrado, o trigger provavelmente está observando uma máquina que foi renomeada ou substituída. 3. **A combinação de tags é reconhecida.** O AppSignal avisa quando uma combinação de tags não foi vista na última hora. 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. 4. **Um notifier está anexado.** Um trigger sem notifier registra alertas sem enviar notificações. 5. **O notifier funciona.** Envie uma notificação de teste e confirme que ela chega no canal esperado, e não em um parecido. 6. **Alertas de ausência tratam dados faltantes.** Para qualquer trigger cujo limite seja zero ou um valor mínimo, confirme que **treat missing datapoints as 0** está ativado, ou ele não abrirá exatamente no caso para o qual você o criou. ## Mantenha os alertas após a configuração Alertar não termina quando a configuração está pronta. * **Escreva o runbook no trigger.** Um nome que diga o que está errado, uma descrição que diga o que fazer, e um dashboard vinculado. Coberto em [torne a notificação autoexplicativa](/alerting/tuning#make-the-notification-explain-itself). * **Evite reajustar durante um incidente.** Alterar configurações do trigger pode afetar o alerta que você está acompanhando, incluindo fechar ou substituir o estado ativo do alerta. * **Revise trimestralmente.** Os alertas se deterioram conforme hosts são substituídos, serviços renomeados e o tráfego cresce. A [checklist de revisão](/alerting/tuning#review-triggers-regularly) cobre o que observar. * **Adicione um alerta após cada incidente, e remova um também.** A revisão pós-incidente é o melhor momento para notar tanto o que faltava quanto o que abriu sem exigir ação. ## Próximos passos * Escolha configurações nos [guias para criar alertas](/alerting/recipes). * Reduza o volume com [ajuste seus alertas](/alerting/tuning). * Defina [padrões de notificação por namespace](/application/notification-settings#organization-and-app-namespace-defaults). * Configure [check-ins](/check-ins) para trabalho agendado.