Pular para o conteúdo principal
Não existe pergunta boba. Nesta página você encontrará as respostas para as perguntas que mais recebemos. Se precisar de mais suporte, confira nossa página de suporte

​
Conteúdo

​
Começando

​
Preciso de ajuda para começar. Por onde eu começo?

Se você é novo no AppSignal ou quer saber mais sobre como configurar os recursos do AppSignal, leia nossos guias

​
Bibliotecas do AppSignal

​
Quais linguagens de programação o AppSignal suporta?

O AppSignal suporta as linguagens de programação Node.js, Ruby e Elixir. Também temos pacotes JavaScript para capturar erros no lado do cliente em navegadores suportados.

​
Filtrando dados

​
Como ignoro actions na minha aplicação?

Você pode ignorar actions para parar de registrar dados de actions, requisições, jobs em segundo plano, etc. específicos.

​
Como ignoro erros na minha aplicação?

Você pode ignorar erros (com base no nome) para evitar que o AppSignal os reporte e te notifique sobre eles.

​
Como filtro os dados enviados ao AppSignal?

Para aprender como filtrar os dados enviados ao AppSignal, leia um dos seguintes guias:

​
Qual sintaxe de regex o ignore_logs suporta?

ignore_logs suporta um subconjunto limitado da sintaxe de expressões regulares: ^ (início da string), $ (fim da string) e .* (curinga). Construções completas de regex, como classes de caracteres ([.]), não são válidas e são silenciosamente ignoradas. Para corresponder a uma linha de log exata, ancore-a com ^ e $. Para corresponder a um prefixo, use ^ seguido pelo texto literal. Para corresponder em qualquer lugar da mensagem, use .* ao redor dela. Consulte o guia de ignore logs para a referência completa da sintaxe.

​
Como suprimo logs enviados pelo appsignal-wrap?

appsignal-wrap encaminha stdout e stderr para o AppSignal por padrão. A opção de configuração ignore_logs não se aplica ao appsignal-wrap. Para suprimir a saída, passe --no-stdout e/ou --no-stderr para o comando appsignal-wrap: 
appsignal-wrap --no-stdout --no-stderr your-api-key -- your-command
Essas são flags exclusivas da CLI e não podem ser definidas via variáveis de ambiente. Consulte a documentação do appsignal-wrap para a lista completa de opções.

​
Como adiciono instrumentação adicional à minha aplicação?

Instrumentação adicional pode ser adicionada à sua aplicação para te dar mais insights sobre como ela está se comportando, medindo a duração de eventos separados. Aprenda como na documentação do nosso Ruby Gem e Pacote Elixir.

​
Qual é a diferença entre setRootName e setName?

setName e setRootName renomeiam spans, mas em níveis diferentes. setName define o nome de um span individual como ele aparece na linha do tempo da amostra de desempenho, enquanto setRootName define o nome da transação raiz — o que você vê na visão geral de desempenho e na lista de transações. Um bom padrão é chamar setRootName uma vez no seu handler mais externo (por exemplo, `${request.method} ${pattern}` para produzir um título como GET /users/:id) e usar setName junto com setCategory em spans internos, como middlewares, loaders e actions, para que apareçam como eventos claramente identificados no detalhamento da linha do tempo. Para mais informações sobre nomeação e adição de spans, consulte o guia de instrumentação do Node.js.

​
Como rodo várias aplicações em um único host?

Por padrão, o AppSignal é configurado assumindo que uma aplicação roda em um host. Se você executar mais de uma aplicação em um host, alguns comportamentos inesperados podem ocorrer, como dados sendo reportados para uma aplicação diferente. Para configurar o AppSignal para várias aplicações em um único host, o Working Directory do AppSignal precisa ser configurado. Leia mais sobre como configurar o working directory no nosso Guia para rodar várias aplicações em um único host

​
Quais sistemas operacionais o AppSignal suporta?

Leia nossa página Sistemas operacionais para a lista completa de sistemas operacionais suportados e quaisquer pacotes necessários.

​
Como depuro um problema com a integração do AppSignal?

Leia nosso Guia de depuração para um guia completo de depuração de problemas com a integração do AppSignal. Você também pode conferir nossa página Problemas conhecidos para problemas que podem estar presentes na sua versão da integração do AppSignal.

​
O AppSignal suporta Windows?

O AppSignal não suporta Windows e não há planos para adicionar suporte ao Windows. No entanto, tentamos fazer com que as bibliotecas do AppSignal sejam instaláveis no Microsoft Windows sem erros ou problemas de build.

​
Por que instalar o AppSignal Ruby Gem falha com um erro JSON::Fragment?

Esse erro ocorre ao instalar o appsignal 4.x com Ruby 3.0 ou anterior. O gem json empacotado como dependência no AppSignal 4.x introduziu JSON::Fragment, uma constante disponível apenas no Ruby 3.1 e versões posteriores. Em versões mais antigas do Ruby, o build da extensão nativa falha com: 
uninitialized constant JSON::Fragment (NameError)
A correção recomendada é atualizar o Ruby para a versão 3.1 ou posterior, o que te permite usar a versão atual do AppSignal 4.x sem restrições. Se você não puder atualizar o Ruby imediatamente, pode fixar a versão no AppSignal 3.x como solução temporária: adicione gem "appsignal", "~> 3.0" ao seu Gemfile e execute bundle update appsignal. O AppSignal 3.x funciona com Ruby 2.7 e Ruby 3.0, mas não recebe novos recursos da linha 4.x, então planeje atualizar o Ruby assim que possível.

​
Como configuro o AppSignal em uma aplicação Hanami?

O AppSignal não é configurado automaticamente no Hanami como acontece no Rails. Use um arquivo de configuração Ruby (config/appsignal.rb) em vez do arquivo YAML legado (config/appsignal.yml) — o formato YAML está obsoleto e será removido na próxima versão major do gem. Crie config/appsignal.rb com: 
Appsignal.configure do |config|
  config.activate_if_environment(:development, :staging, :production)
  config.name = "Your App Name"
  config.push_api_key = "your-key-here"
end
Em seguida, garanta que o config.ru carregue a integração depois do Hanami: 
require "appsignal"
require "hanami/boot"

Appsignal.load(:hanami)
Appsignal.start

run Hanami.app
Se você tiver um config/appsignal.yml existente, remova-o ou adicione uma seção development com active: true — ter os dois arquivos causa conflitos. O AppSignal não inicia no ambiente development por padrão; activate_if_environment o ativa explicitamente. Consulte a documentação de integração com o Hanami para a configuração completa.

​
Por que os erros em Phoenix LiveComponent não são capturados pelo AppSignal?

O AppSignal captura erros do Phoenix escutando eventos de telemetria do Phoenix. Quando um LiveComponent trata eventos de formulário diretamente, o Phoenix usa um caminho interno que não emite esses eventos de telemetria, então o erro nunca é reportado. Para reportar erros do LiveComponent, use Appsignal.send_error/2 para enviá-los manualmente: 
rescue e ->
  Appsignal.send_error(e, __STACKTRACE__)
  reraise e, __STACKTRACE__
end
Como alternativa, mova a lógica que pode gerar uma exceção do template do componente para os callbacks handle_event/3 ou update/2, onde a telemetria do Phoenix é disparada. Essa lacuna foi corrigida no upstream do phoenix_live_view. Atualizar para a versão mais recente permite que o AppSignal capture esses erros automaticamente.

​
Conta de usuário

​
Como ativo a autenticação de dois fatores (2FA) para o app do AppSignal?

Consulte nossa página Autenticação de dois fatores para mais informações sobre como ativar a 2FA.

​
Por que meus códigos de autenticação de dois fatores (2FA) não estão funcionando?

Se os códigos do seu app autenticador são rejeitados ao fazer login, a causa mais comum é o desvio de relógio no dispositivo que os gera. Os códigos de autenticação de dois fatores são baseados em tempo (TOTP), então o relógio desse dispositivo precisa estar preciso — isso costuma quebrar após mudanças de fuso horário. Ative a data e hora automáticas (de rede) no dispositivo e tente o código recém-gerado. Se ainda não conseguir fazer login, use um dos cinco códigos de recuperação que você salvou ao ativar a 2FA para contornar a autenticação de dois fatores. Veja Autenticação de dois fatores para mais informações sobre códigos de recuperação.

​
Quais endereços IP o AppSignal usa?

Atualmente, a Push API do AppSignal usa os seguintes endereços IP: 
185.191.3.93
185.191.3.94
185.191.3.125
185.191.3.126
Atualmente, os webhooks do AppSignal são originados dos seguintes endereços IP: 
185.191.3.107
185.191.3.72
185.191.3.116
185.191.3.84
Não recomendamos colocar endereços IP específicos em uma allowlist. Eles podem mudar e mais endereços podem ser adicionados no futuro, por exemplo, quando precisamos rotacionar nossos load balancers ou adicionar servidores rapidamente. Se você decidir adicionar nossos endereços IP a uma allowlist, envie um e-mail para nossa equipe de suporte; faremos o possível para notificar você sobre mudanças futuras.

​
Erros e desempenho

​
Por que meu problema de desempenho está sempre marcado como fechado?

O status Aberto ou Fechado de um issue é determinado pelas suas configurações de notificação, não por se o problema subjacente ainda está ocorrendo. O AppSignal marca um issue como Aberto quando envia uma notificação para ele. Issues de desempenho usam a configuração “Never Notify” por padrão, então nenhuma notificação é enviada — por isso eles permanecem Fechados. Para que um issue de desempenho seja aberto em novas ocorrências, altere sua configuração de notificação, seja por issue ou atualizando o padrão no nível da organização. Veja Configurações de notificação para saber como configurar isso.

​
Como vejo a contagem de erros por namespace?

Para ver a contagem de erros por namespace, crie um gráfico Number que use a métrica transaction_exception_count (a contagem de erros registrados em uma aplicação pelo AppSignal), filtrada pela tag namespace:
  1. Abra a aplicação que você quer medir, vá em Dashboards e adicione um novo gráfico.
  2. Selecione a aba Number.
  3. Defina a métrica como transaction_exception_count.
  4. Adicione a tag namespace e digite o nome do namespace (por exemplo, web ou background).
  5. Defina o tipo de agregação como Total value.
  6. Crie o gráfico.
O gráfico mostra a contagem total de erros para aquele namespace ao longo do período que você selecionar ao visualizá-lo. O AppSignal armazena os dados de erro separadamente por aplicação, então não há um único total entre todas as aplicações — crie um gráfico por namespace por aplicação e some as contagens manualmente se precisar de um valor geral.

​
Por quanto tempo os dados do monitoramento de uptime são retidos?

O monitoramento de uptime armazena métricas por minuto por 30 dias e métricas por hora por 5 anos. Para visualizar tendências diárias de uptime em um período mais longo — por exemplo, um ano inteiro — use o seletor de data na visualização de monitoramento de uptime para selecionar um intervalo de datas personalizado.

​
Como encontro a causa de requisições de API lentas?

Comece em Performance → Slow API requests. As requisições são ordenadas por impacto — a combinação de duração e frequência — então as entradas no topo são as mais prováveis culpadas. Selecionar uma requisição mostra sua duração média, gráfico de tempo de resposta, throughput e a lista de actions que a contêm. Para queries de banco de dados, confira Performance → Slow queries. Cada query é ordenada por impacto e selecionar uma mostra quais actions a disparam. Para encontrar queries N+1, abra Performance → Issue list. Actions sinalizadas com a tag N+1 contêm chamadas repetidas ao banco de dados. Abra uma amostra e veja a linha do tempo de desempenho — eventos marcados como x2, x5 e assim por diante indicam a mesma query repetida dentro de uma única requisição. Para um passo a passo guiado, veja Encontrar queries lentas no banco de dados e Encontrar requisições HTTP lentas.