Skip to main content
Sempre que o AppSignal detecta um novo erro, ele abre um incidente. Você encontra incidentes na seção Errors. O AppSignal pode enviar notificações quando detecta um novo incidente ou uma nova ocorrência de um incidente existente. As notificações podem ser enviadas por e-mail ou por um dos nossos muitos notificadores.
Estas configurações se aplicam a incidentes de erro. O desempenho não é alertado por meio de incidentes. Para ser notificado quando uma action ficar lenta, configure um trigger como descrito na seção alertas de desempenho. Alertas de anomaly detection triggers são direcionados pelos notifiers selecionados em cada trigger.

Opções de notificação

Sempre que um novo incidente é criado, ele herda os padrões de notificação do app. Quando um incidente de Error é criado, suas configurações de notificação podem ser alteradas na própria página do incidente. Se um incidente foi fechado, ele será reaberto quando uma nova notificação for enviada. Há seis opções de notificação disponíveis: Novos incidentes de erro têm como padrão First in Deploy.

Every Occurrence

Uma notificação é enviada toda vez que um incidente é disparado. Essa opção tem um intervalo de 5 minutos. Isso significa que, se um incidente for disparado 20 vezes por minuto, durante 20 minutos, você receberá uma notificação nos minutos 0, 5, 10, 15 e 20.

First in Deploy

Uma notificação é enviada na primeira ocorrência de um incidente após o recebimento de um novo deploy marker. Você precisará configurar deploy markers para que o AppSignal detecte um deploy e saiba quando um incidente ocorreu pela primeira vez em um deploy.

First After Close

Uma notificação é enviada na primeira ocorrência de um incidente após o incidente ter sido fechado anteriormente. Incidentes podem ser abertos e fechados na barra lateral, na página de detalhes do incidente. Essa opção é uma boa escolha para incidentes que não são acionados por um bug de código, mas por uma fonte externa (por exemplo, um terceiro com problema de conexão) e não podem ser fechados fazendo deploy de uma nova versão do app.

Never Notify

Nenhuma notificação é enviada quando o incidente é disparado. Como um incidente só é reaberto quando o AppSignal envia uma notificação, um incidente definido como Never Notify permanece fechado mesmo quando ocorre novamente. Usado principalmente para erros que continuarão a acontecer e que você gostaria de acompanhar, mas que não serão corrigidos em breve. Se você não quiser receber o incidente de forma alguma, ignorar a action ou ignorar o erro pode ajudar.

Every Nth per Hour or Day

Uma notificação é enviada a cada n-ésima ocorrência por hora, ou por dia, dependendo das suas preferências. Há vários cenários em que isso pode ser benéfico:
  • Erro de cobrança: Imagine um erro de cobrança ocorrendo de vez em quando, fora do seu controle. Ele acontece, no máximo, 5 vezes ao dia, e você quer saber quando esse número aumenta de repente. Configurar para “every 10th time a day” enviará um alerta na 10ª, 20ª, 30ª ocorrência etc.
  • Erro de API: Você pode ter uma API que muita gente usa. Ao experimentar uma API, é comum cometer erros que disparam exceções. Você pode querer ser alertado apenas quando o número de erros atingir um limite. Você poderia, por exemplo, configurá-lo para notificar você a cada 1000ª ocorrência por hora, o que pode indicar que a API está falhando por motivos diferentes.
  • Durante um incidente: Imagine que algo está severamente quebrado. Centenas de erros por hora estão acontecendo, mas você está no controle. Pode não ser uma boa ideia ignorar todos os alertas completamente, mas receber cada um deles vai te afogar em notificações. Esse é o momento perfeito para gerenciar o número de notificações que você recebe, configurando temporariamente seus erros para Nth/hour.
Visualização de notificações a cada 100ª por hora A visualização mostra quando você receberia alertas. Neste cenário, as notificações estão configuradas para “Every 100th per hour”. Antes de escolher Every Nth per Hour, considere se o seu caso de uso depende do acúmulo de incidents entre limites de hora. A contagem é reiniciada no início de cada hora, portanto incidents que quase atingem o limite antes do fim da hora não são somados aos incidents da próxima hora.

Configurações de notificação para incidentes de erro

Incidentes de erro são identificados pelo nome (classe) do erro, como ActiveRecord::RecordNotFound e, se o erro ocorreu dentro de uma action, pelo nome da action. (Por exemplo, StandardError em BlogpostsController#show). Opções de notificação para incidentes de erro

Alertas de desempenho

As opções de notificação descritas nas seções anteriores se aplicam a incidentes de erro. O desempenho usa triggers em vez disso. Erros são binários: eles acontecem ou não, o que torna uma opção como First in Deploy significativa para eles. O desempenho se comporta de forma diferente. Se o seu banco de dados está sobrecarregado, fazer deploy de um novo código não vai mudar o tempo de resposta. Uma notificação sobre um único trace lento também diz pouco sobre a saúde da sua aplicação. Problemas de desempenho se desenrolam ao longo de um período, que é o que um trigger mede.

Criar um trigger para uma action lenta

Abra a action de desempenho que você quer observar, como run/shop.send_waitlist_notification, e então selecione Add new no painel Triggers. Painel Triggers em uma action de desempenho, com uma opção para adicionar um novo trigger Um formulário de trigger Slow action é aberto, com Namespace e Action Name já preenchidos. No formulário, você define:
  • Alert me when: o valor a ser alertado, como a duração média, e em Is above o limite que ele precisa superar. O padrão é 200 ms. Para actions que devem ser lentas por interagirem com terceiros, defina um limite mais alto do que definiria para a sua página inicial.
  • Alert warm-up e Alert cooldown: por quanto tempo a condição precisa se manter antes de um alerta abrir, e quanto tempo esperar antes de fechá-lo. Veja warm-up e cooldown.
  • Description e Notify me through: uma nota explicando o que o trigger observa, e os notifiers usados para alertar.
Uma pré-visualização do gráfico ao lado do formulário mostra valores recentes da action, o que ajuda você a escolher um limite adequado ao seu comportamento normal. Selecione Save trigger para criá-lo. Triggers criados dessa forma são listados junto com seus outros triggers na seção Anomaly detection, onde você também pode editá-los depois.

Padrões de organização e namespace do app

As configurações de notificação em um incidente só podem ser alteradas após ele ter ocorrido pelo menos uma vez. Isso pode ser um problema se você nunca quiser ser notificado. É possível configurar padrões de notificação por namespace do app ou até para a organização inteira. Isso facilita aplicar as configurações de notificação desejadas a todos os novos incidentes e a todos os incidentes existentes cujas configurações de notificação ainda não foram personalizadas.

Padrões de notificação do app

Cada aplicação tem seus próprios padrões por namespace para as configurações de notificação. Um novo incidente no namespace especificado herdará as configurações padrão definidas nesta página. Para mais informações, veja a seção herança dos padrões de notificação. Recomenda-se dividir a aplicação em namespaces que agrupem os incidentes potenciais por severidade. Dessa forma, você pode configurar as preferências de notificação para um grupo de incidentes, sem necessidade de configurar cada incidente separadamente. Por exemplo, para o painel de administração de um app, você poderia criar um namespace chamado admin com a configuração padrão de notificação “Never notify”, já que os erros que ocorrem nesse namespace têm menor prioridade.

Padrões de notificação da organização

Também é possível configurar padrões de notificação na sua organização. Esses padrões serão usados quando o AppSignal detectar e criar uma nova aplicação. Quando cria o novo app, ele aplicará os padrões de notificação da organização como padrões de notificação do app. Alterações nos padrões de notificação da organização não se aplicam a apps já existentes. Para mais informações, veja a seção herança dos padrões de notificação. Esses padrões de notificação no nível da organização podem ser configurados no painel de administração da organização. É possível configurar padrões para cada namespace detectado em qualquer uma das aplicações atuais da sua organização.

Herança dos padrões de notificação

As configurações de notificação se propagam dos ajustes do incidente para os ajustes do namespace do app. Se as configurações de notificação de um incidente não forem alteradas, os padrões do namespace do app são usados. Isso significa que você também pode alterar todas as configurações de notificação dos incidentes que não tiveram suas configurações personalizadas, mudando os padrões do app.
  • Quando um novo app é detectado pelo AppSignal, os padrões de namespace da organização são aplicados.
    • Quando os padrões de notificação por namespace da organização são alterados, eles se aplicam apenas a novos apps.
  • Quando os padrões de notificação por namespace de um app são alterados, eles se aplicam a todos os novos incidentes e aos incidentes existentes sem configurações de notificação personalizadas.
  • Quando um novo incidente é detectado pelo AppSignal, os padrões por namespace do app são usados.
  • Quando as configurações de notificação de um incidente são personalizadas, essas configurações personalizadas do incidente são usadas a partir desse momento.