Actions
As actions são o local no código onde uma requisição HTTP, job em background, cron job ou tarefa é iniciada. Para apps Ruby on Rails e Phoenix do Elixir, essa é a combinação de controller e action, comoBlogPostsController#create ou Api::UsersController#index. Para jobs em background, esse será o nome do worker/job, como UserMailer#sign_up_mail.
As actions são usadas para agrupar issues junto com o namespace e o error.
Agente
O AppSignal usa um “agente” para se comunicar com os servidores do AppSignal e instrumentar os hosts em que uma aplicação está sendo executada. Os dados do host são usados em nosso recurso de métricas de host. O agente é iniciado pela biblioteca específica da linguagem e roda como um processo UNIX separado no host da aplicação. A biblioteca de linguagem e o agente se comunicam por meio de um socket UNIX usando uma extensão. Os dados de instrumentação de transações coletados pelo agente são enviados aos servidores do AppSignal. Os dados de transações são processados e usados para detectar eventos que valem a pena alertar os usuários. Leia mais sobre como o agente do AppSignal opera e o ciclo de vida de uma requisição do AppSignal.Allocations
Durante uma requisição HTTP ou um job em background, uma aplicação usa memória. Cada estrutura de dados que é carregada e objeto que é instanciado ocupa memória. Quando uma requisição ou job lida com muitos dados, muito mais memória pode ser usada do que o normal. As bibliotecas de integração do AppSignal mantêm o controle de alocações por transação. A integração também mantém o controle de qual parte da aplicação aloca mais objetos de memória do que outras, então é possível ver se o ORM ou a biblioteca de templates da aplicação está consumindo mais memória. No AppSignal.com, o número de alocações é exibido em um Integer para uma action, grupos de eventos e eventos específicos. Esse número de alocação é o número de objetos que foram criados em memória durante uma action/grupo/evento. O tamanho do objeto criado não é rastreado.Detecção de anomalias
A detecção de anomalias é um recurso do AppSignal que permite aos usuários detectar anormalidades em seus apps. Uma anomalia pode ser algo como uma taxa de erro aumentada ou uma quantidade limitada de memória livre no host do app. A detecção de anomalias funciona com condições de limite de trigger que criam Alertas quando seu limite é atingido. Quando um Alerta é aberto, o AppSignal enviará notificações para quaisquer notificadores que foram selecionados para o trigger específico. Veja nossa documentação sobre Detecção de anomalias para mais informações.API
API é uma “Application Programming Interface”. O termo API é amplo e é usado de muitas formas. No contexto da nossa documentação, nos referimos à API HTTP REST do AppSignal ao usar “API”. A API do AppSignal é uma API HTTP REST que pode ser usada para recuperar dados dos servidores do AppSignal e enriquecer os dados existentes com mais informações, como Markers. A API difere da Push API em seu propósito. Enquanto a Push API é usada para enviar dados ao AppSignal pelo agente, a API HTTP REST é usada principalmente para recuperar dados do AppSignal. Isso permite que os usuários usem os dados disponíveis em outras ferramentas. Você pode ler mais sobre nossa API em nossa documentação da API.API key
Para se conectar com a API do AppSignal, é necessário estar autenticado. Cada usuário tem sua API key para se autenticar com o AppSignal. Sua API key pode ser encontrada no seu perfil de usuário. Essa chave não deve ser confundida com a Push API key, que é usada por aplicações com um agente do AppSignal instalado.Applications
Aplicações (anteriormente conhecidas como “sites”, também referidas como “apps”) são aplicações Ruby e Elixir monitoradas pelo AppSignal. Após instalar a biblioteca do AppSignal em uma aplicação, o AppSignal começa a monitorar essas aplicações. Uma vez que recebemos dados de uma aplicação, nós a registramos usando o nome da aplicação e o ambiente em que está sendo executada. Uma aplicação pode ter múltiplos ambientes desde que cada ambiente use o mesmo nome.- “Demo application” - Development
- “Demo application” - Production
- “Demo application” - Staging
- “Demo application” - Test
AppSignal vs Appsignal vs appsignal
Espera, são três grafias diferentes do nome AppSignal? Sim! Vamos explicar:| Grafia | Uso |
|---|---|
AppSignal | O nome da marca da empresa, da aplicação e de quase tudo mais relacionado ao AppSignal. Esta é a versão que você deve usar ao falar sobre o AppSignal como marca, produto ou serviço ou fornecedor de stroopwafels. |
Appsignal | O nome da biblioteca das nossas integrações AppSignal (integração Ruby, integração Elixir, integração Node.js, integração Front-end etc.). Usado apenas no contexto de código. |
appsignal | Os nomes de pacote das integrações AppSignal conforme publicados nos registros de gerenciadores de pacotes para a gem Ruby, pacote Elixir e prefixo de pacotes, prefixo de pacotes Node.js e prefixo de pacotes Front-end, etc. |
Blog
Nós temos um blog em blog.appsignal.com! Em nosso blog, postamos coisas relevantes para o AppSignal, como novos recursos, lançamentos de agentes principais, artigos Ruby Magic e outras histórias incríveis do nosso processo interno. Como como comer stroopwafels.Changelog
Mantemos um changelog completo do produto em appsignal.com/changelog. Todos os nossos novos recursos, lançamentos de agentes e outras mudanças no produto podem ser encontradas nessa lista organizada. Também temos um pequeno indicador na nossa navegação superior que notifica você se há uma nova entrada no changelog.Configuração
A configuração é parte das bibliotecas em execução nas aplicações. Ela diz às bibliotecas do AppSignal o que instrumentar em uma aplicação, qual aplicação ela é e em qual ambiente está sendo executada. As bibliotecas do AppSignal têm múltiplos métodos de configuração. O método mais comum de configuração é o uso de um arquivo de configuraçãoappsignal.yml.
O uso de variáveis de ambiente também é recomendado.
Para a configuração do agente Ruby, recomendamos que você leia o
tópico de configuração para começar.
Uso de CPU
Durante a operação de uma aplicação, o uso de CPU pode variar muito. Algumas operações de uma aplicação podem solicitar mais tempo de CPU do que outras. Outros fatores também podem afetar o uso de CPU. Se a aplicação monitorada não for o único processo na máquina host, outros processos também podem afetar a métrica de uso de CPU. Por exemplo, se um banco de dados em execução na mesma máquina precisar executar uma consulta complicada, ele solicitará mais tempo de CPU. No AppSignal.com, o uso de CPU de uma aplicação é exibido de duas maneiras. Para uma action onde ocorreu um erro/problema de desempenho e para métricas de host. Dessa forma, é possível ver se o desempenho de uma action foi diretamente afetado por uma CPU ocupada ou se o host inteiro foi afetado por períodos mais longos. Saiba mais sobre o que métricas de CPU significam em nosso blog.Cross-Site Request Forgery
Cross-Site Request Forgery (CSRF) é um ataque que força um usuário final a executar ações indesejadas em uma aplicação web onde está autenticado. Uma vítima pode clicar em um link enviado por e-mail ou chat na web, permitindo que o atacante roube e use as credenciais da vítima. A gravidade do ataque pode variar dependendo da aplicação e do acesso de autorização da conta da vítima. Um atacante pode ser capaz de fazer ações que alteram o estado de uma conta de usuário, como alterar suas credenciais de login, e pode comprometer uma aplicação inteira em casos graves, como quando uma vítima é um administrador.Elixir Alchemy
Quer aprender mais sobre Elixir? Em nossa série de e-mails Elixir Alchemy (1x por mês), mergulhamos mais fundo em Elixir e Erlang. Você pode se inscrever aqui: appsignal.com/elixir-alchemy.Ambientes
A maioria das aplicações pode ser executada em modos diferentes. Durante o desenvolvimento de uma aplicação, outras regras se aplicam e os erros geralmente não são mostrados na forma de uma página de “500 internal server error”, como acontece em “production”. O AppSignal também entende o conceito de um ambiente, permitindo que diferentes configurações sejam configuradas por ambiente. Para cada ambiente, uma aplicação separada é criada no AppSignal.com para ser configurada com seu próprio conjunto de regras de alerta e integrações de terceiros.Erros
Erros são problemas que ocorrem durante a execução de uma aplicação. Isso pode ser qualquer coisa, desde uma falha catastrófica que faz com que a aplicação trave até um simples erro de digitação que causa uma página de erro. Uma vez que um erro ocorre em uma aplicação, o AppSignal envia um alerta e registra os detalhes do erro para visualização posterior no AppSignal.com. Leia mais sobre o recurso de erros em nossa página de tour. Para saber mais sobre o tratamento de erros em Ruby, leia nosso tópico de Tratamento de exceções descrevendo como rastrear erros efetivamente com o AppSignal. Erros são reportados como issues. Saiba mais sobre o que são issues.Eventos
Um evento é algo que aconteceu. Esta é uma declaração muito vaga porque o conceito de um evento é algo muito de alto nível. Um erro é um evento, e um problema de desempenho também. O AppSignal monitora muitos eventos dentro de uma aplicação e em um servidor usando métricas de host. Coletando muitos tipos diferentes de eventos e combinando os dados, esperamos fornecer uma imagem o mais completa possível para obter mais insights sobre o desempenho das aplicações. Veja também a documentação de eventos de instrumentação.Extensão
As bibliotecas e o agente do AppSignal estão em constante comunicação um com o outro. As bibliotecas enviam dados ao agente por meio de um socket UNIX. Para fazer isso, as bibliotecas usam uma extensão para a linguagem de programação em que estão escritas. Essa extensão é escrita em C e Rust, e é instalada quando o agente específico da linguagem é instalado. Leia mais sobre como a extensão do AppSignal opera e o ciclo de vida de uma requisição do AppSignal.Impacto
O impacto de uma action em uma aplicação é baseado em seu uso em comparação com outras actions. Quando uma action de controller ou job leva mais tempo ou é executada mais frequentemente do que outras, seu impacto cresce. Por exemplo:- A Action A é acionada 1000 vezes com uma duração média de 0,5 segundos. A duração combinada é de 500 segundos.
- A Action B é acionada 500 vezes com uma duração média de 3 segundos. A duração combinada é de 1500 segundos.
- A Action A tem um impacto de 25% (500 / 2000).
- A Action B tem um impacto de 75% (1500 / 2000).
Instrumentação
A instrumentação é o que dá poder ao AppSignal. Sem ela, não saberíamos nada sobre o que está acontecendo dentro das aplicações. Instrumentação são hooks dentro ou ao redor de frameworks e bibliotecas que o AppSignal usa para monitorar o código da aplicação. Essa instrumentação reporta erros e código lento que é enviado ao AppSignal para análise. Uma vez que um problema é detectado, um alerta é enviado. Saiba mais sobre instrumentação Ruby.Eventos de instrumentação
Eventos são blocos de código que são executados. Podem ser métodos, funções ou partes menores deles. Eventos podem ser aninhados para mostrar hierarquia e a duração total das operações. Esses eventos individuais tornam possível ver quais partes do código são mais lentas do que outras. No topo das páginas de issues, também agrupamos as durações de eventos por nome de grupo, seguindo a nossa nomenclatura de eventos, para fornecer insights sobre qual parte do app demora mais. Alguns tipos de eventos que podem ser mostrados são consultas de banco de dados, parsing de JSON, renderização de views, requisições HTTP, instrumentação personalizada, etc. Cada evento é mostrado nas páginas de detalhes de problemas de desempenho na “linha do tempo de desempenho”. Se detectarmos que o mesmo evento é repetido mais de uma vez em sucessão, vamos marcá-los como potenciais eventos N+1, como consultas N+1. Veja também instrumentação.Issues
Sempre que o AppSignal detecta um novo erro, uma issue é criada. Sempre que o AppSignal detecta uma nova potencial requisição lenta, job em background, etc. uma nova issue é criada. Essa issue é agrupada por action, namespace e error. Issues de erro também suportam erros sem action, pois um erro pode ocorrer fora de uma action, como no framework do app antes de chegar ao código do próprio app. Problemas de desempenho sem uma action são silenciosamente ignorados. A action, o namespace e o tipo de erro são a forma como agrupamos issues. Se um erro de um novo tipo ocorre na mesma action no mesmo namespace que outra issue de erro, uma nova issue será criada para esse erro. Se outra potencial requisição lenta é detectada em outro endpoint ou job em background, uma nova issue será criada para esse endpoint/job. Por issue, é possível configurar configurações de notificação, atribuição, estado (aberto/fechado/em andamento) e severidade.Bibliotecas
O AppSignal usa bibliotecas específicas de linguagem para monitorar aplicações. Atualmente, temos uma gem Ruby e um pacote Elixir. Essas bibliotecas incluem hooks em frameworks e bibliotecas para instrumentar blocos de código, como chamadas de banco de dados, chamadas de sistema de arquivos e renderização de views. Cada biblioteca é especializada na instrumentação da linguagem de sua especialidade. A maioria das bibliotecas do AppSignal também inclui um “agente” que as bibliotecas usam para se comunicar com os servidores do AppSignal. Leia mais sobre como o agente do AppSignal opera e o ciclo de vida de uma requisição do AppSignal.Integrações de bibliotecas
As bibliotecas do AppSignal se integram com uma variedade de diferentes bibliotecas e frameworks específicos da linguagem de programação. A gem Ruby se integra com Ruby puro, Rails, Sinatra e outros frameworks disponíveis. O pacote Elixir se integra com Elixir puro e Phoenix. Essas integrações automáticas tornam mais fácil obter mais insights sobre as aplicações sem ter que adicionar instrumentação do AppSignal manualmente. Leia mais sobre quais integrações Ruby oferecemos.Markers
Markers são pequenos ícones usados em gráficos no AppSignal.com para indicar uma mudança. Isso pode ser um deploy de código usando um “Deploy marker” ou um evento especial com um “Custom marker”. Esses custom markers podem ser qualquer coisa, desde operações de escalonamento, picos repentinos de tráfego ou quando um banco de dados está enfrentando problemas. Leia mais sobre markers.Metadata
Metadata é dado que fornece informações sobre outros dados. Metadata são informações sobre um erro ou problema de desempenho que fornece mais contexto aos dados coletados. Ao enviar metadata extra em uma amostra, é mais fácil rastrear quais foram as circunstâncias em torno do problema específico. Por padrão, o metadata de uma requisição inclui o hostname no qual a issue ocorreu, a revisão SCM em que a aplicação está sendo executada e o ID da requisição da requisição da qual a amostra foi derivada. Também inclui dados como o caminho da requisição e o método da requisição para requisições web.Métricas
O AppSignal fornece dois tipos de métricas. Métricas personalizadas permitem a coleta de dados de praticamente qualquer coisa. Com algumas linhas de código, é possível rastrear e gerar gráficos de dados como o número de usuários registrados, visitas a uma página, tamanhos de banco de dados, etc. Métricas de host são sobre dados do servidor em que uma aplicação está sendo executada. Dados como uso de CPU, load averages, uso de memória, etc. dão mais insights sobre problemas de desempenho do que apenas o código em si. Talvez o espaço em disco esteja acabando, fazendo com que a aplicação rode muito mais lenta. Leia mais sobre métricas em nossa página de tour.Namespace
Namespaces são mecanismos de agrupamento usados pelo AppSignal para diferenciar entre diferentes partes da mesma aplicação. Por padrão, o AppSignal divide uma aplicação em dois namespaces: “Web” e “Background”. Requisições HTTP que estão sendo monitoradas pelo AppSignal serão adicionadas ao namespace “Web”, e jobs realizados por bibliotecas de jobs em background são adicionados ao namespace “Background”. Também é possível configurar seus namespaces para diferenciar entre requisições em uma aplicação e um painel de administração privado. Para mais informações sobre namespaces, consulte nossa documentação de namespaces.Notificações
O AppSignal envia notificações sempre que um problema é detectado em uma aplicação. Essas notificações podem ser mensagens de e-mail, mensagens no Slack, uma notificação do PagerDuty e mais, dependendo de quais integrações de terceiros estão configuradas. Enviamos notificações sobre erros, requisições lentas e alertas de Detecção de anomalias que ocorrem em uma aplicação usando uma biblioteca do AppSignal. Uma vez que um evento problemático é detectado, uma notificação é enviada para alertar os usuários sobre um problema.Organizações
Organizações são usadas para agrupar aplicações e usuários para um negócio. Um negócio pode ter muitos usuários e clientes que podem ser notificados sempre que houver um problema com suas aplicações. O Faturamento para aplicações é feito no nível da organização, em vez de por aplicação. A gestão de equipe é facilitada usando organizações. Equipes inteiras podem ser convidadas para uma organização, então não há necessidade de compartilhar detalhes de login. Leia mais sobre organizações em nossa documentação de Organizações.Owners
Organizações têm pessoas que gerenciam a organização. Esses owners decidem quem é membro de uma organização, em qual time eles pertencem ou não, e decidem como o faturamento é feito. Os owners da organização podem gerenciar tudo sobre uma organização e as aplicações que pertencem a ela. Se você não tem permissão para visualizar ou alterar algo, peça ao owner da sua organização para alterar para você ou dar a você mais permissão.Problemas de desempenho
Usando o monitoramento de desempenho, é possível mergulhar em requisições individuais e ver quais partes de uma aplicação são lentas. Com essas informações, é possível encontrar e melhorar áreas problemáticas. Quando o AppSignal detecta uma requisição web ou operação lenta, ele enviará notificações, porque código lento pode ser tão prejudicial quanto um erro aparecendo. Problemas de desempenho são agrupados por action e namespace. Nas páginas de detalhes de problemas de desempenho, mais informações estão disponíveis sobre cada action. Nem todas as issues são uma “issue”. Cabe a você determinar se uma requisição HTTP de 200ms é muito lenta. Potenciais requisições lentas e jobs em background são reportados como problemas de desempenho. Saiba mais sobre o que são issues. Leia mais sobre o recurso de desempenho em nossa página de tour.Push API
A “Push API” do AppSignal é o endpoint da API usado pelo agente do AppSignal para enviar os dados coletados. Isso é diferente da API normal do AppSignal, que é usada principalmente para ler dados e adicionar mais contexto aos dados enviados ao AppSignal. Essa Push API é a API onde a instrumentação da aplicação é enviada das aplicações usando a Push API key.Push API key
A “Push API key” é uma chave de API somente de escrita usada por aplicações para se autenticar ao enviar dados aos servidores do AppSignal. Apps reportam dados à Push API e se autenticam usando essa chave. Existem vários tipos de Push API keys que os apps podem usar para diferentes casos de uso. Todas as Push API keys podem ser encontradas na página de configurações de Push & deploy.- Push API key no nível da organização: A Push API key recomendada para integrações de back-end, como Ruby, Elixir, Node.js, Python e Go. Reconhecemos apps por uma combinação de Push API key, nome do app e ambiente do app, e criamos apps usando essas informações se ainda não existirem.
- Push API key no nível do app: Após a criação, um app também recebe sua Push API key no nível do app. Essa chave pode ser usada para enviar dados a um app específico, mesmo que o app esteja configurado para usar um nome de app ou ambiente de app diferente. Isso é usado ao mover apps entre organizações sem perda de dados, ou quando nenhum nome de app ou ambiente de app pode ser definido, como para a integração Vector.
- Front-end API key: Essa chave é usada por apps que usam nossa integração front-end para reportar dados e pode ser encontrada na seção “Front-end error monitoring”.