Skip to main content
Esta página dá uma configuração inicial para cada alerta que a maioria das aplicações em produção precisa. Cada guia lista o que o trigger mede, quando vale a pena configurá-lo, e valores para começar. Trate os valores como pontos de partida. Plote a métrica ao longo de pelo menos duas semanas antes de fixar um limite, e então ajuste usando a orientação de ajuste seus alertas. Qualquer que seja o guia pelo qual você comece, dê ao trigger um nome que diga o que está errado, uma descrição que diga o que fazer a respeito, e um dashboard vinculado. Esses três campos são o que transforma a notificação resultante em algo sobre o que quem responde pode agir, e são cobertos em torne a notificação autoexplicativa.

​
Os quatro alertas para configurar primeiro

Se você está configurando alertas do zero, estes quatro cobrem a maioria dos incidentes reais:
  1. Um uptime monitor em um endpoint de health-check.
  2. Um trigger de taxa de erros no seu namespace web.
  3. Um trigger de tempo de resposta p95 no tráfego voltado ao usuário.
  4. Check-ins para jobs agendados.
Adicione alertas de host e de saturação quando esses estiverem estáveis. Adicionar todos os guias desta página de uma vez é uma forma confiável de criar fadiga de alertas.

​
O app está acessível?

Use: Uptime monitoring Uma verificação externa de que seu endpoint ainda responde. É o único alerta que continua funcionando quando seu app não consegue enviar nada ao AppSignal, e é por isso que a maioria das equipes o configura primeiro. O AppSignal requisita a URL a cada minuto a partir de quatro regiões e reporta uma falha quando a resposta não está na faixa 2xx ou não chega em 30 segundos. Cada região é acompanhada separadamente, então um monitor abre um alerta por região que falha. Uma queda real abre até quatro alertas, e um problema de rede entre uma região e seu endpoint abre um alerta enquanto sua aplicação está bem. Esta é a principal razão para definir um warm-up em uptime monitors: uma falha em uma única região que se resolve em um minuto não envia notificação. Um uptime monitor também produz métricas com tags por região e nome do monitor, então você pode adicionar anomaly detection triggers sobre o tempo de resposta por região se precisar de alertas mais finos que “no ar ou fora do ar”. O monitoramento de expiração de certificados SSL está disponível como recurso do AppSignal Labs. Depois de habilitado, você o ativa em um monitor https:// individual em vez de construir um trigger à mão, e o AppSignal notifica você quando o certificado tem menos de 14 dias restantes, usando os mesmos notifiers do monitor. A expiração de certificado é um problema de evolução lenta, então direcione-a para e-mail ou chat em vez do plantão.

​
Os usuários estão encontrando erros?

Use: Um anomaly detection trigger sobre a taxa de erros, restrito a um namespace A taxa de erros é o indicador mais rápido de que usuários estão vivenciando erros, e ela permanece significativa conforme o tráfego muda. O trigger sugerido no AppSignal começa em 20%, o que é deliberadamente conservador para que um app novo não produza alertas imediatamente. Reduza-o quando conhecer sua linha de base. Crie um trigger separado e mais tolerante para background. Falhas de jobs normalmente têm retry, então raramente justificam a mesma urgência de requisições web que falham. Manter dois triggers de taxa de erros em limites diferentes funciona bem, desde que cada um tenha um destino diferente. Um trigger no seu limite normal de degradação vai para o chat, e um segundo em um limite muito mais alto, como 50%, significa que há um problema sério e deve notificar o plantão. Dois limites apontando para o mesmo notifier só dobram as notificações.

​
Quando usar contagem de erros em vez disso

A contagem de erros cruza um limite fixo sempre que o tráfego cresce, então notifica você em dias movimentados, independentemente de algo estar errado. Use-a apenas onde qualquer ocorrência importa e o volume é naturalmente baixo, como um namespace de pagamento ou de cadastro. Restrinja-a bem e defina um limite baixo.

​
As requisições estão ficando lentas?

Use: Um anomaly detection trigger sobre desempenho, medido em milissegundos Médias escondem requisições lentas para parte do seu tráfego. Se uma requisição em 20 leva 8 segundos enquanto o resto é rápido, a média quase não se move, mas 5% dos usuários vivenciam uma requisição lenta. Percentis resolvem isso. Um p95 de 400 ms significa que 95 de cada 100 requisições terminaram em até 400 ms, e as cinco mais lentas levaram mais tempo. Alerte em p90 ou p95 em vez da média, para notar um problema que afeta parte do seu tráfego. O trigger sugerido pelo AppSignal usa uma média acima de 500 ms, o que é um primeiro alerta razoável, mas deixará passar degradação parcial. Passe para p95 quando tiver uma linha de base. Para observar um caminho crítico específico em vez de um namespace inteiro, use um trigger de desempenho restrito a uma action. Checkout, login e busca são candidatos comuns. Dê a cada um um limite que lhe sirva: uma página que chama uma API de terceiros pode razoavelmente levar 10 segundos, enquanto uma página inicial não.

​
O tráfego desapareceu?

Use: Um anomaly detection trigger sobre throughput, medido em requisições por minuto Uma queda acentuada no throughput normalmente significa que uma falha ocorreu antes de as requisições chegarem ao seu app: um domínio expirado, um load balancer mal configurado, ou uma queda de CDN. Essa falha é invisível para seus outros alertas, porque um app que não recebe tráfego não reporta erros nem requisições lentas. Defina o limite com base no seu período mais tranquilo, não na sua média, ou o trigger notificará você toda noite. Se o seu tráfego varia demais para um piso fixo funcionar, alerte quando o tráfego chegar exatamente a zero, como descrito na seção seguinte.

​
Alertar sobre tráfego alto demais

Tráfego muito acima do seu pico normal também pode precisar de um trigger. Pode vir de crescimento esperado, como uma campanha bem-sucedida, ou de um problema, como um bot raspando seu catálogo ou um cliente fazendo retry em laço. Nos dois casos, o alerta ajuda você a responder antes de o tráfego esgotar sua capacidade. Defina a comparação como More than, com um limite bem acima da sua hora normal mais movimentada, e direcione-o para o chat. Raramente é urgente o bastante para notificar o plantão, mas explica muitos outros alertas que chegam pouco depois.

​
A atividade parou?

Use: Um anomaly detection trigger com limite de exatamente zero Alguns dos alertas mais valiosos são sobre ausência em vez de excesso. Um consumidor de fila que para de consumir, um namespace que para de receber tráfego, ou um estágio de pipeline que para de produzir saída podem não mostrar erros, nem requisições lentas, nem saturação. A atividade que falta é o problema. Ativar treat missing datapoints as 0 é o que faz isso funcionar. Sem essa opção, uma métrica que para de reportar por completo não envia pontos de dados, então o trigger não tem nada para avaliar e o alerta nunca abre. Com ela, o AppSignal trata dados faltantes como zero e o alerta abre como pretendido. Bons candidatos são throughput por namespace, um contador de jobs processados com sucesso, ou uma contagem de processos que nunca deveria cair a zero. Esse padrão também é a forma confiável de notar um worker que morreu em vez de ficar mais lento.
Use isso para trabalho contínuo que deveria estar sempre acontecendo. Para trabalho que roda conforme um agendamento, use check-ins, que são feitos para isso e não precisam de um warm-up longo o suficiente para cobrir o intervalo entre execuções.

​
O trabalho está acumulando?

Use: Um anomaly detection trigger sobre tempo de fila, medido em milissegundos O tempo de fila mede quanto tempo uma requisição ou job esperou antes de seu app começar a processá-lo. Tempo de fila crescente é um aviso antecipado de que a capacidade está curta, normalmente antes de tempos de resposta ou taxas de erro reagirem. Seu app pode não reportar erros nem requisições lentas enquanto usuários ainda esperam: um pedido confirmado horas depois de ser feito, ou um relatório que chega um dia atrasado. Na prática, a profundidade de fila costuma ser o sinal mais fácil de alertar. Se você já acompanha a contagem de jobs pendentes ou de mensagens não processadas como métrica personalizada, um limite de profundidade é concreto, fácil de raciocinar e fácil de definir a partir do histórico. Use uma tag por nome de fila para que um backlog em uma fila não pareça uma queda geral. Use os dois quando puder. A profundidade diz que o backlog está crescendo; o tempo de fila diz que ele já está afetando alguém.

​
Os hosts estão ficando sem recursos?

Use: Triggers de métricas de host Alertas de host descrevem causas em vez de sintomas visíveis ao usuário, então direcione-os para canais de menor urgência que os alertas voltados ao usuário. Um host com 95% de CPU e tempos de resposta saudáveis não é um incidente. Alertas de host são úteis porque avisam antes de um recurso se esgotar completamente, que é quando um app pode parar abruptamente e outros alertas podem começar a abrir todos de uma vez. Todo trigger de host aceita um hostname, e seu valor padrão * corresponde a todo host. Defina um nome específico ou um prefixo como web-*, a menos que você realmente queira um alerta por host da frota.

​
Uso de disco

Este é o alerta de host mais claro de configurar, porque um disco cheio causa falhas de forma confiável e o uso de disco muitas vezes cresce de forma previsível. Defina o limite pela velocidade com que o disco enche, não por quão cheio ele está. Um host de uso geral que ganha um ponto percentual por semana está bem em 80%. Um host de banco de dados ou de fila que pode ganhar 20 pontos em uma hora precisa avisar você em 60%, porque o tempo restante importa mais que o espaço restante. Isso normalmente significa vários triggers de disco em vez de um, cada um restrito a um grupo de hosts com um curinga, como db-* em 60% e web-* em 80%. Defina também um trigger por mountpoint que importe para você. Um trigger sem tag de mountpoint corresponde a todo sistema de arquivos montado, incluindo montagens efêmeras de containers.

​
Uso de memória

Porcentagem normalmente é mais fácil de reutilizar entre hosts de tamanhos diferentes. Valores absolutos são melhores quando você sabe quanta capacidade livre uma carga de trabalho específica precisa.

​
Uso de swap

Quando um servidor fica com pouca memória, ele começa a mover dados para o disco, que é muito mais lento que a memória. A aplicação continua funcionando, então pode não ocorrer erro, mas as requisições podem ficar mais lentas. Vale alertar sobre isso porque o impacto pode ser gradual e fácil de passar despercebido. O trigger sugerido no AppSignal notifica você quando um host usa qualquer swap, o que é uma forma razoável de descobrir se seus hosts usam swap. Normalmente é sensível demais para manter no longo prazo: muitos hosts saudáveis alocam um pouco de swap e nunca mais o tocam. Quando conhecer sua linha de base, passe para um limite percentual, para que o alerta abra por pressão real de memória e não por alguns megabytes alocados no boot.

​
Uso de CPU e load average

O agente reporta CPU por estado em vez de um total único, então escolha o estado que descreve o trabalho que importa para você, e use iowait quando suspeitar que o host está esperando o disco em vez de computando. Aumentos curtos de CPU são normais. Só uso de CPU alto e sustentado normalmente precisa de notificação, e mesmo então pertence ao chat em vez do plantão, a menos que já esteja afetando os tempos de resposta. Load average frequentemente é o mais útil dos dois em hosts de banco de dados e de workers, porque conta processos esperando disco assim como CPU. Ele não é comparável entre máquinas, porém: um load average de 60 é saturação em um host de 16 núcleos e saudável em um de 128. Restrinja um trigger de load average a uma classe de host com um curinga e defina o limite pela contagem de núcleos daquela máquina, em vez de rodar um único trigger sobre uma frota mista.

​
Throughput de disco e de rede

Os triggers de I/O de disco e de tráfego de rede cobrem dados lidos e escritos em cada disco, e dados recebidos e transmitidos por cada interface de rede. Para a maioria das equipes, esses rendem melhores gráficos de dashboard que alertas, porque um limite significativo depende muito da carga de trabalho. Alerte sobre eles quando você tem um teto conhecido, como um limite de IOPS provisionado.

​
O trabalho agendado rodou?

Use: Check-ins Anomaly detection não pode dizer de forma confiável que um trabalho agendado não aconteceu, porque um trigger só avalia dados que chegam. Use check-ins para isso.
  • Check-in de cron, para jobs que rodam conforme um agendamento. Sua configuração principal é a expressão cron, mais um fuso horário.
  • Check-in de heartbeat, para workers e processos que devem continuar rodando. Sua configuração principal é a duração máxima desde o último heartbeat.
Ambos usam uma Maximum duration em minutos em vez de um warm-up. Para um process monitor de cron, o AppSignal reporta uma falha quando nenhum evento chega entre o horário de início definido pelo agendamento e o fim daquela duração. Para um heartbeat, ele reporta uma falha quando nenhum evento chega dentro daquela duração após o último. Defina-a mais longa que a variação normal do job em horário de início e tempo de execução, para que um job que ocasionalmente roda alguns minutos atrasado não notifique ninguém. Bons candidatos são rotinas noturnas de faturamento, backups, exportações de dados, rotinas de pré-aquecimento de cache, e qualquer consumidor de longa duração.

​
Uma dependência está falhando?

Use: Log triggers Algumas falhas nunca se tornam um incident nem uma métrica. Um provedor de pagamentos que dá timeout e depois tem sucesso no retry não deixa erro nem pico de latência grande o bastante para ser notado, mas um padrão sustentado vale conhecer. Comece pela query que encontra as linhas. Se você já as está olhando no terminal, essa query é a que você tem:
Shell
Quando a query encontrar apenas as linhas esperadas, crie o trigger a partir dela. O mesmo texto de query é reutilizado:
Shell
Para fazer o mesmo na interface, filtre a página de Logs para as linhas que importam, selecione uma para abrir Log details, e crie o trigger a partir da seção Actions, que leva sua query, severity e origem. Veja log triggers para o fluxo completo. Log triggers funcionam de forma diferente de triggers de métrica, e a diferença importa para o ruído. Um log trigger é avaliado contra linhas de log individuais conforme elas chegam, então não tem as configurações de warm-up e cooldown dos triggers de anomalia. Controle o volume de notificações com a configuração de limite:
  • First After Close para um problema que se recupera sozinho, para que você receba uma notificação cada vez que o problema volta depois de fechar.
  • Nth in an hour para um padrão de log que corresponde de forma intermitente por design, em que o número de linhas correspondentes é o sinal importante.
  • Every Occurrence apenas onde uma única linha realmente importa.
Use Never Notify para padrões que você quer acompanhar e contar sem notificar ninguém.

​
Obtendo warm-up e cooldown em dados de log

Quando um padrão de log é ruidoso demais para qualquer um desses limites, converta-o em métrica em vez de alertar diretamente nas linhas. Extraia uma métrica baseada em logs das linhas correspondentes, e então aponte um anomaly detection trigger para essa métrica. São dois comandos. Primeiro, conte as linhas correspondentes em uma métrica. Um counter não precisa de campo, porque está contando linhas em vez de ler um valor delas:
Shell
Então alerte sobre essa métrica, que é onde warm-up e cooldown ficam disponíveis:
Shell
Isso dá aos dados derivados de logs a máquina de estados completa: um limite, um warm-up para que um aumento breve seja ignorado, e um cooldown para que um problema recorrente produza um alerta. Esta é a abordagem recomendada para uma dependência que falha em períodos curtos várias vezes ao dia.

​
Uma métrica de negócio está errada?

Use: Um anomaly detection trigger sobre uma métrica personalizada Métricas personalizadas são a única forma de alertar sobre valores específicos da aplicação que o AppSignal não consegue inferir, como pagamentos bem-sucedidos por minuto, cadastros, ou o tamanho de uma fila de trabalho. Esta é a única falha que nenhum outro alerta desta página pode detectar. Se uma mudança no seu provedor de pagamentos começar a rejeitar todas as transações, seu app continua no ar, rápido e sem erros enquanto nada é vendido, então só uma métrica que você mesmo envia pode detectar isso. Plote a métrica primeiro, e então defina o limite a partir do que você vê. Para verificar uma métrica personalizada na interface de alertas, abra Anomaly detection, vá em Triggers, selecione Add trigger, e então escolha Custom metrics em Other. Informe o nome da métrica e use a prévia do gráfico e as combinações de tags para confirmar que o AppSignal recebeu a métrica.

​
Próximos passos