Por que continuo recebendo e-mails de alerta depois de cancelar meu plano?
Esses e-mails são notificações operacionais de alerta, não e-mails de marketing. Eles normalmente vêm de um monitor ou trigger que ainda está configurado para o app. Por exemplo, um uptime monitor pode continuar verificando uma URL e enviar um alerta cada vez que a URL não puder ser acessada. Se sua conta estiver bloqueada ou cancelada, o e-mail pode dizer que o AppSignal ainda está monitorando o app, mas que você não tem mais acesso aos detalhes dos dados. Para parar as notificações:- Se você ainda consegue acessar o app, remova o notifier do trigger na página de triggers, ou do monitor na página de uptime monitoring.
- Arquive o trigger ou exclua o uptime monitor se não precisar mais dele.
- Se você não consegue acessar o app porque a conta está bloqueada ou cancelada, entre em contato com o suporte. Podemos ajudar a identificar e remover o monitor ou trigger que ainda está enviando alertas.
Como impedir que um trigger envie notificações sem excluí-lo?
Remova os notifiers do trigger na página de triggers. O trigger permanece ativo e continua registrando alertas, mas para de enviar notificações. Arquive o trigger apenas quando não quiser mais que o AppSignal avalie aquela condição. Arquivar um trigger também fecha seus alertas abertos. Para anomaly detection triggers, o direcionamento das notificações é controlado no próprio trigger. Configurações de frequência de notificação de incident, como Never Notify ou Every Nth per Hour, não se aplicam a alertas de anomaly detection triggers.Posso alertar quando containers do Kubernetes estão pendentes ou parados?
O AppSignal for Kubernetes reporta métricas de nodes e pods, e as exibe nas páginas de Cluster Metrics. Ele não oferece um trigger do Kubernetes para estados de container como pendente ou parado. Métricas do Kubernetes não estão disponíveis no momento para anomaly detection triggers, e a visão geral do Kubernetes não cria regras de alerta. Se você precisa de alertas para estados de container ou pod do Kubernetes, entre em contato com o suporte. Podemos ajudar a confirmar o que é possível na sua configuração e registrar o caso de uso, caso seja necessário trabalho de produto.Qual métrica alimenta o dashboard “Process memory usage”?
O dashboard “Process memory usage”, um dos dashboards do seu app, usa a métricaprocess_rss.
Essa métrica tem as seguintes tags:
hostname, o host que emitiu a métrica.process_name, o nome do processo reportado pelo processo do app.
process_rss e restrinja-o com tags. Por exemplo, use process_name=sidekiq* ou um nome de processo específico, se o seu app reportar um, e use o hostname relevante quando quiser alertar sobre um host ou dyno.
Para confirmar a métrica e as tags exatas por trás de um gráfico do dashboard, abra o menu do gráfico e selecione Edit chart. Use o nome da métrica, o campo e as tags desse gráfico como ponto de partida para o trigger.
Recebemos alertas, mas raramente abrimos o AppSignal. Isso é um problema?
Não necessariamente. Algumas equipes usam o AppSignal principalmente como sistema de alertas. Isso pode funcionar se os alertas forem específicos, direcionados ao lugar certo e tratados. Torna-se um problema quando as notificações chegam, mas ninguém as investiga. Isso normalmente significa que os alertas são ruidosos demais, não são claros o suficiente, ou são direcionados ao canal errado. Revise a configuração dos alertas:- Liste os triggers que abriram alertas nos últimos 90 dias na página de triggers.
- Verifique na visão geral de anomaly detection se alguém agiu em cada alerta.
- Remova notifiers de alertas que não deveriam notificar ninguém.
- Arquive alertas para condições que ninguém precisa mais.
- Direcione alertas urgentes para uma ferramenta de plantão, e alertas de menor prioridade para chat ou e-mail.
- Adicione um nome de trigger claro, uma descrição e um link para um dashboard, para que a notificação explique o que fazer em seguida.
Quais alertas devem enviar e-mail?
Use e-mail para alertas que devem continuar lembrando alguém enquanto permanecem abertos, ou para alertas de menor urgência que não exigem uma resposta imediata de plantão. Para problemas urgentes em produção, use um notifier de plantão como PagerDuty, Opsgenie ou outro notifier baseado em webhook. E-mail é fácil de perder quando uma equipe recebe muitos alertas. Conecte notifiers na página de Notifications e depois selecione-os em cada trigger. E-mail pode enviar lembretes enquanto um alerta de anomalia permanece aberto. Outros tipos de notifier, incluindo Slack, PagerDuty, Opsgenie e webhooks, recebem notificações quando o alerta abre e quando é resolvido.Com que frequência devemos revisar as configurações de alerta?
Revise os triggers aproximadamente a cada trimestre, e sempre que um canal de notificação começar a parecer ruidoso. Faça estas perguntas para cada trigger:- Este trigger abriu um alerta nos últimos 90 dias?
- Alguém agiu com base nele?
- Um único incidente gerou muitos alertas?
- O notifier ainda é o adequado?
- O nome e a descrição do trigger explicam qual ação tomar?
- O trigger ainda corresponde aos hosts, tags, filas ou nomes de processo atuais?