A lista a seguir inclui todas as opções de configuração com o nome da variável de ambiente e o nome da chave no arquivo de configuração.Para mais informações sobre como configurar o AppSignal com um arquivo de configuração ou variáveis de ambiente do sistema, veja nosso tópico Configuração.
Observação: quando a variável de ambiente
APPSIGNAL_PUSH_API_KEY está definida, o padrão é true. Isso pode ser sobrescrito
definindo a variável de ambiente do sistema APPSIGNAL_ACTIVE como false:
APPSIGNAL_ACTIVE=false.
Configura o AppSignal para estar ativo ou não para um determinado ambiente. Mais comumente usado na configuração por arquivo por ambiente.
O ambiente do aplicativo que será reportado ao AppSignal. Esta opção de configuração será detectada automaticamente em aplicativos Rails. Para aplicativos Rails, a variável RAILS_ENV é usada para detectar o ambiente. Para aplicativos que usam outros frameworks ou nenhum, a variável de ambiente RACK_ENV é utilizada.Para sobrescrever essa detecção automática, defina a variável de ambiente APPSIGNAL_APP_ENV.
Shell
export APPSIGNAL_APP_ENV=stagingrackup
Esta opção será usada para carregar a configuração dos arquivos de configuração onde a configuração do AppSignal é armazenada.A opção de variável de ambiente é comumente usada em plataformas onde os aplicativos rodam no ambiente production por padrão, como o Heroku. Essa configuração permite uma substituição para definir o ambiente como staging, por exemplo.
Shell
heroku config:set APPSIGNAL_APP_ENV=staging
Se o ambiente for definido usando o helper Appsignal.configure, ele substituirá a variável de ambiente APPSIGNAL_APP_ENV.
Observação: alterar o nome ou o ambiente de um aplicativo
existente criará um novo aplicativo no AppSignal.com.
Observação: esta opção de configuração não tem equivalente como chave em arquivo de configuração. Para definir o
ambiente na inicialização do AppSignal, você precisará inicializar a
configuração
manualmente.
Ambientes personalizados no arquivo de configuração
Não existe uma chave env disponível no arquivo config/appsignal.yml. Se você deseja
definir dinamicamente o nome do ambiente para um aplicativo no arquivo de configuração,
é possível personalizar seu arquivo de configuração para usar a variável de ambiente para criar um
ambiente.
Se você usar outra variável de ambiente diferente de APPSIGNAL_APP_ENV, certifique-se de que o valor corresponda a algum dos nomes de variáveis de ambiente detectados automaticamente (RAILS_ENV e RACK_ENV) ou ao valor fornecido para Appsignal.configure.
Observação: alterar o nome ou o ambiente de um aplicativo
existente criará um novo aplicativo no AppSignal.com.
Nome da sua aplicação como deve ser exibido no AppSignal.com. Se você usar Ruby on Rails, a gem detectará automaticamente o nome e você pode deixar este campo vazio. Para outros frameworks, definir isso é obrigatório.
Nota: Alterar o nome ou o ambiente de uma aplicação existente
criará uma nova aplicação no AppSignal.com.
A chave de autenticação em nível de organização para autenticar com nossa Push API.Leia mais sobre a Push API key do AppSignal.
Nota: Quando a variável de ambiente do sistema APPSIGNAL_PUSH_API_KEY
está definida, a opção active terá como padrão true
em vez de false. Isso significa que o AppSignal será considerado
ativo para o ambiente carregado, mesmo se active estiver definido como false no
arquivo de configuração. Para mais informações, consulte a opção active.
Configura o relato de erros que ocorrem em jobs do Active Job. Esta opção permite desativar o relato de erros para jobs do Active Job, permitindo que um relato de erros personalizado seja adicionado.Valores aceitos:
all: Relata todos os erros para cada execução de jobs, incluindo retentativas.
discard: Relata erros quando o job é descartado devido ao erro. Use esta opção para relatar erros apenas quando todas as retentativas do job tiverem se esgotado.
none: Não relata nenhum erro para jobs, incluindo retentativas.
Observação: a opção discard só funciona no Active Job 7.1 e mais recente. Em
versões inferiores, discard é lido como all.
Um endereço IPv4 válido que o agente do AppSignal usa como binding para seus servidores TCP e UDP. Use um endereço específico se você quiser que o agente escute apenas as requisições feitas para esse endereço. Defina esta opção como 0.0.0.0 para permitir o recebimento de requisições de hosts usando qualquer endereço IP. Por padrão, ele escuta apenas as requisições feitas no mesmo host. Esta opção é aplicada a todos os servidores do agente (StatsD, OpenTelemetry e NGINX).
Configure o caminho do arquivo de certificado SSL. Por padrão, aponta para o arquivo cacert.pem empacotado na própria gem do AppSignal.Use esta opção para apontar para outro arquivo de certificado se houver um problema ao conectar à nossa API.
Nota: O caminho especificado não pode conter abstrações de sistema de arquivos
específicas do sistema operacional, como o símbolo de homedir ~ em sistemas *NIX.
Isso será interpretado como um caminho malformado.
A capacidade de CPU disponível do host, em número de CPUs. Isso é usado para calcular a porcentagem de uso de CPU nas métricas do host. Se não for definido, o agente tentará detectar isso automaticamente a partir dos cgroups.O número de CPUs pode ser uma fração, por exemplo, 0.5.
Aviso: Esta opção de configuração está obsoleta na gem Ruby 3.0.16. Use
a opção log_level em vez disso para a gem Ruby 3.0.16 e
versões mais recentes.
Habilita o log de depuração. Geralmente isso só é necessário a pedido do suporte. Com esta opção habilitada, o AppSignal registrará muito mais informações sobre decisões tomadas durante a coleta de métricas e quando os dados são enviados aos servidores do AppSignal.com.Habilitar o log de depuração pode ter um leve impacto no uso de disco e IO, especialmente em sites de alto tráfego. A sobrecarga de CPU é mínima com a opção de depuração habilitada.
Esta opção define o nível de severidade do logger interno do AppSignal. Esta
opção de configuração não afeta o recurso de logging.
Tags padrão que serão adicionadas a todas as transações. Tags específicas de transação definidas com Appsignal.add_tags substituirão as tags padrão com a mesma chave.
Configure os servidores DNS que o agente do AppSignal deve usar.
Appsignal.configure do |config| config.dns_servers = ["8.8.8.8", "8.8.4.4"]end
Se você for afetado por nossos timeouts de DNS, tente definir um servidor DNS manualmente usando esta opção, que não use mais de 4 pontos no nome do servidor.
Valores não aceitáveis: foo, my.awesome.custom.local.dns.server.
Se o servidor DNS não puder ser alcançado, o agente recorrerá à configuração de DNS do host e exibirá uma mensagem no arquivo appsignal.log: A problem occurred while setting DNS servers.
Habilita a integração de relatório estruturado de eventos do ActiveSupport::EventReporter.Quando habilitada, a integração do AppSignal se inscreve nos eventos emitidos pelo ActiveSupport::EventReporter e os reporta como logs.
Configura como o AppSignal é encerrado quando a aplicação é encerrada. Isso determinará se ele chama Appsignal.stop automaticamente, que fará flush dos dados para a extensão e o agente.Esta opção tem três valores possíveis:
always: Sempre chama Appsignal.stop quando o programa é encerrado. Em containers (Docker), é automaticamente definido para este valor.
never: Nunca chama Appsignal.stop quando o programa é encerrado. O valor padrão quando o programa não está sendo executado em um container (Docker).
on_error: Chama Appsignal.stop quando o programa é encerrado com erro.
Defina como true para reportar o último erro que causou o encerramento do processo. O erro reportado geralmente é o erro que faz o processo travar. Se a gem Ruby já reportou o erro, ela não o reportará novamente.Erros reportados por meio desse mecanismo são adicionados ao namespace “unhandled”.Adicione este código ao início da aplicação em containers de curta duração e funções serverless para garantir que o erro seja enviado antes que o sistema seja encerrado.
Habilita o sistema experimental de captura de erros de front-end. Isso adicionará uma rota à sua aplicação em /appsignal_error_catcher que pode ser usada para capturar erros de JavaScript e enviá-los ao AppSignal. Você pode configurar esta rota com frontend_error_catching_path.
Defina esta opção como false para desabilitar a instrumentação do timer global da GVL. Esta opção de configuração não tem efeito se o GVLTools não estiver instalado.
Defina esta opção como false para desabilitar a instrumentação de threads em espera da GVL. Esta opção de configuração não tem efeito se o GVLTools não estiver instalado.
Defina esta opção como false para desabilitar a coleta de métricas do host.No Heroku e no Dokku, as métricas do host são desabilitadas por padrão. Isso é feito porque esses sistemas reportarão métricas imprecisas a partir de dentro dos containers. A coleta de métricas do host nesses sistemas não pode ser habilitada. Para o Heroku, use o log drain do Heroku em vez disso.
Defina como true para habilitar o servidor de métricas do NGINX. Consulte a documentação de métricas do NGINX para mais detalhes.Quando habilitado, o agente do AppSignal escutará em um servidor vinculado a localhost na porta 27649. Se você estiver executando várias aplicações instrumentadas com AppSignal no mesmo servidor, esta opção de configuração só pode ser habilitada em uma delas.
Habilita o servidor StatsD no agente do AppSignal.Quando habilitado, o agente do AppSignal escutará em um servidor vinculado a localhost na porta 8125. Se você estiver executando várias aplicações instrumentadas com AppSignal no mesmo servidor, esta opção de configuração só pode ser habilitada em uma delas.
Se isso for definido como true, o diretório de trabalho do AppSignal que é criado é acessível para todos os usuários (permissões Unix 0666). Isso geralmente é necessário porque processos para a mesma aplicação são executados sob um usuário diferente. Defina como false para desabilitar esse comportamento (permissões Unix 0644).
A gem Ruby do AppSignal armazena metadados sobre requisições e jobs em background nas amostras por padrão, como caminho da requisição, método da requisição, id da requisição, fila do background job, id do job e contagem de tentativas do job. Esses valores de metadados serão exibidos na caixa de tags. Se algum desses valores de metadados contiver PII ou outros dados sensíveis, use esta opção de configuração para filtrar os metadados por chave.Defina a opção filter_metadata como uma lista de chaves de metadados que devem ser filtradas. Você pode configurar isso com uma lista de chaves no arquivo de configuração. Quando filtrados, os metadados não estarão visíveis na interface do AppSignal.
Appsignal.configure do |config| config.filter_metadata += ["path", "request_id"]end
Lista de chaves de parâmetros que devem ser ignoradas pela filtragem do AppSignal. Seus valores serão substituídos por [FILTERED] quando transmitidos ao AppSignal. Você pode configurar isso com uma lista de chaves no arquivo de configuração.
Appsignal.configure do |config| config.filter_parameters += ["password", "email", "api_token", "token"]end
Lista de chaves de dados de sessão que devem ser ignoradas pela filtragem do AppSignal. Seus valores serão substituídos por [FILTERED] quando transmitidos ao AppSignal. Você pode configurar isso com uma lista de chaves no arquivo de configuração.
Appsignal.configure do |config| config.filter_session_data += ["name", "email", "api_token", "token"]end
Agrupa hosts por função (role) e gera métricas baseadas nessa função. Uma dessas métricas é a métrica contadora reporting_hosts. Uma boa função indica qual é o papel principal do servidor, como “webserver”, “processor”, “api”, “database”, “loadbalancer”, etc.
Isso sobrescreve o hostname do servidor. Útil para quando você não consegue definir um hostname personalizado ou quando um id não descritivo é gerado para você em serviços de hospedagem.
Com esta opção de configuração você pode especificar uma lista de ações que serão ignoradas pelo AppSignal. Tudo o que acontecer, incluindo exceções, não será transmitido ao AppSignal. Isso pode ser útil para ignorar endpoints de health check ou outras ações que você não quer monitorar.Leia mais sobre ignorar ações.
Lista de classes de erro que serão ignoradas. Qualquer exceção lançada com esta classe de erro não será transmitida ao AppSignal.Leia mais sobre ignorar erros.
Lista de mensagens de log que serão ignoradas. Qualquer mensagem de log que contenha algum dos elementos da lista não será transmitida ao AppSignal. Um pequeno subconjunto da sintaxe de regex é suportado. Leia mais sobre isso em nosso guia Ignore Logs.
Lista de namespaces que serão ignorados. Qualquer erro lançado ou requisição lenta que ocorra neste namespace não será enviado ao AppSignal.Leia mais sobre namespaces.
Esta opção configura qual logger a funcionalidade interna de logging do AppSignal
usará e não afeta o recurso de logging.Nota: O agente do AppSignal,
que é usado pela integração, sempre escreverá no arquivo “appsignal.log”.
Selecione qual logger a integração do AppSignal usará. Os valores aceitos são
file e stdout. Veja também a configuração log_path.
file (padrão)
Escreve todos os logs do AppSignal no sistema de arquivos.
Esta opção define o nível de severidade do logger interno do AppSignal e não
afeta o recurso de logging.
Define o nível de severidade do logger interno do AppSignal. Se configurado como “info”, ele registrará todas as mensagens de erro, aviso e info, mas não registrará as mensagens de debug.Definir os níveis “debug” ou “trace” geralmente só é necessário a pedido do suporte. Definir o nível como “debug”/“trace” pode ter um leve impacto no uso de disco e IO, especialmente em sites de alto tráfego. A sobrecarga de CPU é mínima com a opção de debug habilitada.Valores aceitos:
Esta opção configura a localização do arquivo de logging interno do AppSignal e
não afeta o recurso de logging. Nota: O caminho especificado não pode conter abstrações de sistema de arquivos
específicas do sistema operacional, como o símbolo de homedir ~ em sistemas *NIX.
Isso será interpretado como um caminho malformado.
Sobrescreve a localização do caminho (diretório) onde o arquivo appsignal.log pode
ser escrito.
Configura a porta na qual o servidor de métricas do NGINX é exposto.Quando o AppSignal recebe métricas do NGINX, ele escuta em um servidor vinculado a localhost, por padrão na porta 27649. Se você estiver executando várias aplicações instrumentadas com AppSignal no mesmo servidor com métricas do NGINX habilitadas, use esta opção para configurar cada aplicação para escutar em uma porta diferente.
A opção de configuração request_headers contém uma lista de cabeçalhos HTTP de requisição que são lidos e armazenados pela gem AppSignal Ruby.Esta opção de configuração request_headers é uma allowlist (lista de permissões), o que significa que apenas os cabeçalhos especificados por esta opção de configuração serão considerados. Se esta opção de configuração não for definida, será usado o padrão do AppSignal.
Appsignal.configure do |config| # Add a request header config.request_headers << "PATH_INFO" # Remove a request header config.request_headers.delete("PATH_INFO")end
Observe que o AppSignal lê os cabeçalhos do seu aplicativo e eles podem não corresponder exatamente ao que está sendo enviado pelo navegador/cliente. Em aplicativos Rack (Rails, Sinatra, etc), todos os cabeçalhos personalizados são prefixados com a string HTTP_, todos os nomes de cabeçalhos são convertidos para maiúsculas e os hífens (-) são substituídos por sublinhados (_).Por exemplo, o cabeçalho X-Hub-Signature pode ser acessado pelo seu aplicativo e pelo AppSignal com o nome HTTP_X_HUB_SIGNATURE.Para configurar o AppSignal para não armazenar nenhum cabeçalho HTTP de requisição nas transações do AppSignal, configure a opção com um array vazio.
Appsignal.configure do |config| config.request_headers = []end
Define a revisão do aplicativo para reportar a versão do seu aplicativo que está em execução. O AppSignal criará um marcador de deploy quando este valor for alterado e marcará todos os dados recebidos com a revisão atual.Quando seu aplicativo é implantado usando Kamal, ou quando é implantado no Render, ou quando é implantado no Heroku e o recurso Heroku Labs: Dyno Metadata está habilitado, a integração do AppSignal detectará automaticamente o commit do Git do deploy atual e o usará como revisão.Você pode sobrescrever as revisões detectadas automaticamente no Heroku, Render ou Kamal definindo manualmente a opção de configuração revision com um valor personalizado.Leia mais sobre marcadores de deploy no tópico sobre marcadores de deploy.
O AppSignal espera estar executando na mesma máquina entre diferentes deploys. Defina esta chave como true se o aplicativo estiver rodando em um contêiner, como com o Docker.Versões mais recentes da integração do AppSignal detectam automaticamente o ambiente de contêiner, então nenhuma configuração manual é necessária. Se você estiver tendo problemas com a detecção automática, por favor entre em contato com o suporte.Esta opção é definida como true automaticamente no Heroku.
Define se o envio de parâmetros de requisição para o AppSignal deve ser ignorado.Para mais informações, leia sobre send_params na filtragem de parâmetros de requisição.
Defina esta opção como false para não enviar nenhum dado de sessão com rastros de exceção e amostras de problemas de desempenho.Para mais informações, leia sobre filtragem de dados de sessão de requisição.
Configure o relatório de erros que ocorrem em jobs do Sidekiq.Valores aceitos:
all: Reporta todos os erros para cada execução de jobs, incluindo retentativas.
discard: Reporta erros quando o job é descartado devido ao erro. Use esta opção para reportar erros somente quando todas as retentativas do job tiverem se esgotado.
none: Não reporta erros para jobs, incluindo retentativas. Útil para relatórios de erros personalizados.
Nota: A opção discard só funciona no Sidekiq 5.1 e superior. Em versões
anteriores, discard é interpretado como all.
Defina esta opção para configurar a porta do servidor HTTP StatsD do processo do agente AppSignal. Configure esta porta se outro processo já estiver em execução na máquina utilizando essa mesma porta, para evitar conflitos.
Aviso: Esta opção de configuração foi descontinuada na gem Ruby 3.0.16. Por favor, use
a opção log_level em vez disso para a gem Ruby 3.0.16 e
versões mais novas.
Habilita o modo de depuração de transações. Isso habilita um log muito detalhado de transações e eventos, o que é útil ao desenvolver integrações ou quando os eventos não são rastreados conforme o esperado. O log só é gravado se a opção geral debug também estiver ativada.
Esta opção define o nível de severidade do logger interno do AppSignal e não
afeta o recurso de logging.
Aviso: Esta opção de configuração foi descontinuada na gem Ruby 2.7.0. Por favor, use
a opção working_directory_path em vez disso
para a gem Ruby 2.7.0 e versões mais novas.
Sobrescreve o local onde o AppSignal para Ruby cria um diretório de trabalho.
Veja
working_directory_path
para entender o comportamento aplicável. Esta opção de configuração acrescenta /appsignal ao
caminho especificado, enquanto
working_directory_path
não acrescenta.
Nota: O caminho especificado não pode conter abstrações de sistema de arquivos
específicas do sistema operacional, como o símbolo de diretório home ~ para sistemas *NIX. Isso será
interpretado como um caminho malformado.
Sobrescreve o local onde o AppSignal para Ruby pode armazenar arquivos temporários. Use esta opção se o local padrão não for adequado. Veja nossa página como o AppSignal opera para mais informações sobre a finalidade deste diretório de trabalho.Se você estiver executando múltiplos aplicativos usando o AppSignal no mesmo servidor, use esta opção de configuração para selecionar diretórios de trabalho diferentes para cada instância do AppSignal, caso contrário, as duas instâncias podem entrar em conflito. Para mais informações sobre este cenário, veja nossa documentação executando múltiplos aplicativos em um host.
Appsignal.configure do |config| config.working_directory_path = "/tmp/project_1/"end
Nota: O caminho especificado não pode conter abstrações de sistema de arquivos
específicas do sistema operacional, como o símbolo de diretório home ~ para sistemas *NIX. Isso será
interpretado como um caminho malformado.
