Perguntas frequentes - AppSignal Documentation

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?
Bibliotecas do AppSignal
Conta de usuário
Erros e desempenho

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, background jobs, 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.

Por que as requisições de Uptime monitor contam no meu orçamento e como as excluo?

Os Uptime monitors fazem polling do seu endpoint em uma programação regular e, se o AppSignal estiver instalado, essas requisições contam como transactions no seu orçamento mensal de requisições. Para impedir que elas sejam contadas, adicione a action do health-check em ignore_actions na sua configuração do AppSignal — o AppSignal então deixa de registrar essas transactions por completo. Para Ruby:

config.ignore_actions += ["GET /health"]

Para Node.js:

new Appsignal({ ignoreActions: ["GET /health"] })

Para Python (Django ou outros frameworks), defina ignore_actions em appsignal.py:

from appsignal import Appsignal
appsignal = Appsignal(
    ignore_actions=["GET /health"]
)

Para encontrar o nome exato da action, abra Performance → Issue list e copie-o da coluna Action name. Consulte o guia de ignore actions para a referência completa de configuração.

Como ignoro uma mensagem de erro específica no front-end JavaScript?

Para ignorar erros que correspondam a um padrão de mensagem específico na integração JavaScript do AppSignal, passe um array ignoreErrors ao inicializar o Appsignal. Cada item do array é uma expressão regular comparada com a mensagem de erro.

import Appsignal from "@appsignal/javascript";
export const appsignal = new Appsignal({
  key: "<YOUR_FRONTEND_API_KEY>",
  ignoreErrors: [/Converting circular structure to JSON/],
});

Erros cujas mensagens correspondam a algum padrão em ignoreErrors não são enviados ao AppSignal. Outros erros da mesma classe continuam sendo reportados. Veja as opções de configuração de front-end para a lista completa de opções de inicialização.

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 roteio o tráfego do agente do AppSignal através de um proxy HTTP?

Defina a opção de configuração http_proxy (ou a variável de ambiente APPSIGNAL_HTTP_PROXY) com o endereço completo do seu proxy. O agente do AppSignal roteia todo o tráfego de saída — transactions, erros, métricas e logs — através desse proxy. Para Ruby:

Appsignal.configure do |config|
  config.http_proxy = "http://<PROXY_HOST>:<PROXY_PORT>"
end

Ou como uma variável de ambiente:

APPSIGNAL_HTTP_PROXY=http://<PROXY_HOST>:<PROXY_PORT>

Para Node.js, defina httpProxy na sua configuração:

new Appsignal({ httpProxy: "http://<PROXY_HOST>:<PROXY_PORT>" })

A opção está disponível para as integrações Ruby, Elixir, Node.js e Python. Seu proxy precisa conseguir estabelecer conexões de saída para os endpoints do AppSignal para que os dados sejam encaminhados. Consulte as opções de configuração do Ruby e as opções de configuração do Elixir para a referência completa.

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 transaction raiz — o que você vê na visão geral de desempenho e na lista de transactions. 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. A gem json empacotada 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 da 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 exception 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

Posso enviar notificações por e-mail para um membro específico da equipe?

As notificações por e-mail não podem ser enviadas para um membro específico da equipe. Cada membro controla suas próprias preferências de notificação. Para atualizá-las, vá em Account Settings → Email Settings e ative ou desative as notificações para cada app. Veja configurações de notificação para as opções disponíveis.

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.

Como faço para reinscrever meu dispositivo de autenticação de dois fatores?

Para configurar a 2FA em um novo app autenticador ou dispositivo, vá em Account Settings → Security → Two-factor authentication, desabilite a 2FA e habilite-a novamente. Um novo QR code aparece para você escanear com seu app autenticador. Para chegar à opção de desabilitar, você primeiro precisa se autenticar com um código atual ou um código de recuperação. Veja Autenticação de dois fatores para instruções completas de configuração.

Quais endereços IP o AppSignal usa?

Atualmente, a Push API do AppSignal usa os seguintes endereços IP:

191.3.93
191.3.94
191.3.125
191.3.126

Atualmente, os webhooks do AppSignal são originados dos seguintes endereços IP:

191.3.107
191.3.72
191.3.116
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:

Abra a aplicação que você quer medir, vá em Dashboards e adicione um novo gráfico.
Selecione a aba Number.
Defina a métrica como transaction_exception_count.
Adicione a tag namespace e digite o nome do namespace (por exemplo, web ou background).
Defina o tipo de agregação como Total value.
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 Uptime monitoring são retidos?

O Uptime monitoring 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 Uptime monitoring 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.

Como altero a estratégia de agrupamento de erros de front-end?

Por padrão, o AppSignal agrupa erros de front-end pelo nome do erro. Quando vários erros não capturados compartilham um nome genérico, eles são colapsados em um único issue mesmo que suas mensagens e stack traces sejam diferentes. Para separar erros de front-end excessivamente agrupados pelo local de origem no seu código, vá até a página Settings da sua aplicação e defina Front-end error grouping strategy como Relevant backtrace line strategy. Isso agrupa erros pela primeira linha do seu próprio código no backtrace em vez de pelo nome do erro. Para isso funcionar, envie source maps para a sua aplicação — sem eles o AppSignal não consegue resolver o backtrace para os seus arquivos de origem. Veja Source maps de front-end para saber como configurá-los. Você precisa de acesso de owner na organização para alterar essa configuração. Se a opção não estiver visível, peça a um owner para fazer a alteração.

Como pesquiso erros por mensagem?

Para pesquisar erros pelo texto da mensagem, use a tag message: na barra de pesquisa do AppSignal. Por exemplo, digitar message:"could not connect" retorna todas as amostras de erro em que a mensagem de erro contém essa frase. A barra de pesquisa aparece no cabeçalho do dashboard do AppSignal.

Como recebo notificações de anomaly via webhook?

As notificações de anomaly via webhook são configuradas no anomaly trigger, e não na tela de configurações de webhook. Crie ou edite um anomaly trigger, role até Notify me through e selecione o webhook que você configurou no AppSignal. A tela de configurações de webhook lista apenas eventos de Deploys, Errors e Performance — a conexão com o anomaly fica no próprio trigger. Veja Triggers de Anomaly detection para saber como configurar e editar triggers.

Por que meu app Elixir mostra um pico repentino no uso de requisições?

Um pico repentino no uso de requisições após um deploy costuma ser causado por um grande número de erros gerados pela sua aplicação. Erros contam como requisições no AppSignal. Se o throughput de erros exibido no seu dashboard parecer muito menor que o aumento na contagem de requisições, você pode estar rodando uma versão mais antiga da integração Elixir do AppSignal. Em versões mais antigas, apenas erros amostrados aparecem nas métricas de throughput de erros, mas todas as requisições de erro contam para o seu uso total de requisições. Essa discrepância faz o pico parecer maior do que a contagem de erros sugere. Para resolver a discrepância, atualize o pacote Elixir appsignal para a versão mais recente. Depois de atualizar, as métricas de throughput de erros refletem a contagem completa, correspondendo ao que o AppSignal registra para faturamento. Para encontrar os erros que causam o pico, vá em Errors e filtre pela data do deploy. Veja o guia de instalação do Elixir para instruções de atualização.

Terminologia

⌘I

​Conteúdo

​Começando

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

​Bibliotecas do AppSignal

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

​Filtrando dados

​Como ignoro actions na minha aplicação?

​Como ignoro erros na minha aplicação?

​Como filtro os dados enviados ao AppSignal?

​Qual sintaxe de regex o ignore_logs suporta?

​Por que as requisições de Uptime monitor contam no meu orçamento e como as excluo?

​Como ignoro uma mensagem de erro específica no front-end JavaScript?

​Como suprimo logs enviados pelo appsignal-wrap?

​Como roteio o tráfego do agente do AppSignal através de um proxy HTTP?

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

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

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

​Quais sistemas operacionais o AppSignal suporta?

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

​O AppSignal suporta Windows?

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

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

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

​Conta de usuário

​Posso enviar notificações por e-mail para um membro específico da equipe?

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

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

​Como faço para reinscrever meu dispositivo de autenticação de dois fatores?

​Quais endereços IP o AppSignal usa?

​Erros e desempenho

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

​Como vejo a contagem de erros por namespace?

​Por quanto tempo os dados do Uptime monitoring são retidos?

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

​Como altero a estratégia de agrupamento de erros de front-end?

​Como pesquiso erros por mensagem?

​Como recebo notificações de anomaly via webhook?

​Por que meu app Elixir mostra um pico repentino no uso de requisições?