Bibliotecas de linguagem
As bibliotecas de linguagem do AppSignal (Ruby, Elixir, JavaScript para Front-end) coletam dados de transações e métricas. Transações são requisições HTTP, jobs em background e outras transações personalizadas. Os dados de métricas são baseados nos dados de transações, mas também podem ser definidos usando nossas métricas personalizadas. Cada requisição HTTP recebida, ou job em background, é envolvida em uma “transação”. Essa transação coleta toda a instrumentação que está sendo gerada durante a requisição, incluindo eventos, parâmetros, dados de sessão e tags. Quando seu app termina de atender a requisição, a transação é fechada e enviada ao nosso agente e colocada em uma fila. Essa fila consiste em dados de transações e métricas. O agente do AppSignal transmite esses dados de transações e métricas em payloads combinados a cada 30 segundos para a Push API. O intervalo de transmissão para as instâncias do app não ocorre todo exatamente ao mesmo tempo. Exatamente quando o agente transmite dados depende de quando, dentro de um minuto, o agente foi iniciado. Isso significa que dados do mesmo segundo em duas instâncias diferentes do app podem chegar com cerca de 30 segundos de diferença, sem contar retentativas. Esse é o motivo pelo qual o AppSignal é eventualmente consistente. Leia mais sobre como as bibliotecas de linguagem, nossa extensão e o agente trabalham juntos para levar os dados do seu app aos servidores do AppSignal na página Como nossas integrações operam.Push API
Nossa Push API tem apenas um propósito: receber dados dos apps e enviá-los para uma fila o mais rápido e eficientemente possível. A partir daí, nossos processadores começam a processar os dados de transações e métricas dos apps.Processamento
O processador do AppSignal armazenará novas amostras para erros e medições de desempenho com base nas transações, criará novos incidentes ou atualizará incidentes existentes, criará métricas com base nos dados das transações e processará métricas personalizadas. Durante esse processo, também detectamos mudanças em métricas especificadas em Triggers de detecção de anomalias para criar e notificar sobre alertas novos e em andamento. Leia mais sobre como isso é feito na seção Detecção de anomalias. Os dados processados são então armazenados em nossos buckets de dados. Isso é dividido entre buckets de métricas por minuto e por hora para sua organização. Armazenamos dados na resolução por minuto por até 12 horas, após o que ainda estão disponíveis na resolução por hora. Finalmente, quando todo o processamento é concluído, enviamos notificações para novos erros, novas medições de desempenho, deploys e alertas de Detecção de anomalias.Detecção de anomalias
Quando os dados de métricas chegam aos nossos processadores, ou são criados pelos nossos processadores, eles não são imediatamente usados para processar Triggers de Detecção de anomalias para criar ou atualizar alertas. Os processadores do AppSignal esperam até 180 segundos (3 minutos) antes de processar dados de um minuto. Esse atraso é aproximadamente o mesmo atraso máximo [1] que leva para as métricas aparecerem em gráficos no AppSignal.com. Continue lendo para saber por que esse atraso de processamento existe.Transmitindo os dados
Assim como os dados de transações das bibliotecas de linguagem, os dados de métricas passam por vários sistemas até chegarem aos nossos servidores. Esse processo leva tempo. Nosso processador precisa esperar o intervalo de transmissão do agente do AppSignal após a passagem de um minuto, antes de poder processar dados desse minuto.Desvio de relógio em servidores de aplicação
Leia mais sobre como o AppSignal lida com o tempo, o que é o desvio de relógio e como configurar a sincronização NTP em nossa página sobre tempo.Processamento dos dados de métricas
Após esperar até 180 segundos (3 minutos), o processador determina que todos os dados de um minuto estão presentes e começará a processar triggers e criar ou atualizar alertas. Ele olhará para trás 180 segundos (3 minutos) desde a última chegada de dados para uma aplicação. Dados mais antigos serão ignorados para o processamento de triggers e alertas naquele tick de processamento. Quando o processador termina de processar métricas de um minuto, ele começará a enviar notificações pouco depois para alertas novos, em andamento e fechados. Estender esse atraso por mais tempo significaria também que as notificações chegariam mais tarde. Reduzir esse atraso significaria que poderíamos perder dados de um minuto, fornecendo alertas e notificações sobre dados de métricas incompletos.Conclusão
Pode levar até 90 segundos para que dados de transações e métricas apareçam. Este é um cenário de pior caso. Se não tiver aparecido após esse tempo, algo deu errado em algum lugar no pipeline de transmissão ou processamento. Leva 180 segundos (3 minutos) para que gráficos de métricas e alertas de Detecção de anomalias sejam criados/atualizados. Estamos constantemente tentando minimizar esse tempo, mas precisamos equilibrar a quantidade de requisições que nossa Push API recebe e o tamanho dos dados de cada requisição com a velocidade de processamento. Se você quiser saber mais sobre esse assunto, não hesite em entrar em contato conosco![1] Esse tempo não considera retentativas de dados sendo transmitidos a partir dos servidores de aplicação. Dados que falharam em ser transmitidos, porque um servidor perdeu sua conexão com a internet, por exemplo, serão retentados por até 30 minutos pelo nosso agente. ↩