O que o AppSignal instrumenta para o Rails
Em apps Rails, o AppSignal instrumenta automaticamente estes componentes e eventos do Rails:- Requisições de controller (Action Controller): o AppSignal reporta samples de performance e exceptions, agrupados por controller action, por exemplo
UsersController#show. Os samples podem incluir parâmetros de requisição filtrados, dados de sessão, headers, caminho da requisição, método da requisição, ID da requisição, status da response e o queue time, quando disponível. - Renderização de views (Action View): o AppSignal reporta eventos para renderização de templates (
render_template.action_view) e de partials (render_partial.action_view) na timeline da requisição. - Consultas ao banco de dados e carregamento de models (Active Record): o AppSignal reporta eventos para queries SQL (
sql.active_record) e instanciação de models (instantiation.active_record) na timeline da requisição. - Background jobs (Active Job): o AppSignal reporta a execução do job, eventos de enqueue, queue time, argumentos do job, queue, priority, Active Job ID, provider job ID e métricas de status do job.
- Canais WebSocket (Action Cable): o AppSignal reporta actions de channel, callbacks de subscribe e callbacks de unsubscribe.
- Processamento de mailers (Action Mailer): o AppSignal reporta um counter
action_mailer_processpara cada eventoprocess.action_mailer, com tags de mailer e action. - Rails error reporter: o AppSignal reporta erros enviados através do
ActiveSupport::ErrorReporter, com tags de severity e source. - Rails runners: o AppSignal reporta erros de Rails runners. A performance requer instrumentation manual.
Rails::HealthController#show, são ignoradas por padrão através da opção ignore_actions.
Erros levantados enquanto a aplicação inicializa, antes de os initializers terem rodado, não são reportados por padrão. Veja Error reporting dos initializers.
Active Job
Veja nossa página do Active Job para mais informações sobre como nossa instrumentation do Active Job funciona.Action Cable
Veja nossa página do Action Cable para mais informações sobre como nossa instrumentation do Action Cable funciona.Configurar o AppSignal em um initializer
Recomendamos usar nosso arquivo de configuraçãoconfig/appsignal.rb ou variáveis de ambiente para configurar o AppSignal.
Por padrão, não é possível configurar o AppSignal a partir de um initializer do Rails, porque o AppSignal carrega antes dos initializers da sua aplicação, para conseguir reportar erros que ocorrem durante a inicialização.
Para configurar o AppSignal em um initializer do Rails, primeiro configure o Rails para iniciar o AppSignal depois que os initializers do app tiverem sido executados.
Appsignal.start nos initializers. A gem Ruby iniciará o AppSignal automaticamente quando o Rails tiver executado todos os initializers.
Quando um app Rails é configurado para iniciar o AppSignal depois que os initializers foram carregados, não é mais possível reportar erros dos initializers ao inicializar o app Rails.
Error reporting dos initializers
Por padrão, o AppSignal reporta erros que ocorrem em controllers, Rake tasks e jobs do Active Job. Ele não reporta erros que ocorrem quando a aplicação está inicializando, antes dos initializers do Rails. Para ser notificado quando esses erros ocorrem, adicione o seguinte ao seu arquivoconfig.ru, em torno da linha que requer o arquivo environment.rb.
Backtrace cleaner
Com a integração Rails, o AppSignal executará o backtrace de cada exception através do backtrace cleaner do Rails. Este cleaner dá a você a opção de modificar ou filtrar linhas indesejadas do backtrace, removendo desordem e ruído do backtrace. Você pode adicionar ou remover filters e silencers da configuração padrão. Filters mutarão a linha fornecida. Um exemplo seria remover o prefixoRails.root.
Silencers removerão a linha do backtrace se a expressão fornecida retornar true. Você pode adicionar essas regras adicionais do backtrace cleaner em um initializer.
Por exemplo:
Error reporter
O AppSignal reporta erros gerados viaActiveSupport::ErrorReporter por padrão. ActiveSupport::ErrorReporter foi introduzido no Rails 7.0 para padronizar o reporte de erros customizado.
Você pode desabilitar essa funcionalidade com a opção de configuração enable_rails_error_reporter.
Se uma transaction estiver ativa no contexto em que um erro é reportado através do Rails error reporter, ela incluirá os mesmos metadados e dados de sample que a transaction ativa: namespace, nome da action, tags, dados customizados, parâmetros, etc.
Namespace e action a partir da transaction atual
Ao reportar erros, determinamos o namespace e o nome da action em que ele ocorre, como um controller ou background job, em uma base de melhor esforço. O namespace do incident e o nome da action nem sempre serão definidos ou precisos. Se uma transaction do AppSignal estiver ativa (como em uma requisição web ou background job), o erro reportado comRails.error.handle/record terá o mesmo namespace, nome da action, tags, parâmetros, dados customizados, etc. que a transaction ativa. Se nenhuma transaction do AppSignal estiver ativa, nenhum namespace, nome da action, tags, etc. serão definidos por padrão.
Namespace e action a partir do contexto
Se você quiser mudar o namespace e o nome da action do erro reportado sem mudá-los na transaction do AppSignal já ativa, você pode personalizar isso na chamada do error reporter.Tags da transaction ativa
Por padrão, as tags de transaction da requisição/job são copiadas para a transaction do AppSignal do erro do error reporter a partir da transaction da requisição/job.Tags do contexto
Você pode adicionar tags a um erro reportado usandocontext na chamada Rails.error.handle/record. Essas tags serão definidas apenas no erro reportado com os métodos Rails.error.handle/record.
Appsignal.add_tags.
Comportamento legado da gem Ruby 3
Na gem AppSignal for Ruby versão 3, o comportamento do reporte de erro é diferente.- Erros reportados com o método
Rails.error.handlesão reportados ao AppSignal. - Erros reportados com
Rails.error.recordnão são reportados ao AppSignal para evitar reportar o erro duas vezes quando ele estiver sendo reportado pelo nosso middleware de error reporting do Rails.
Limitações de herança de contexto
Na gem Ruby 3, a herança de contexto da transaction ativa é limitada. Os metadados e alguns dos dados de sample são copiados apenas se estiverem definidos no momento em queRails.error.handle/record é chamado.
Na prática, isso significa que controllers Rails e jobs do Active Job serão reportados com precisão. Outras bibliotecas como jobs do Sidekiq não terão nome de action definido ao reportar erros com Rails.error.handle.
Tags definidas após Rails.error.handle/record ser chamado não são reportadas para o erro reportado usando este helper.
Runners
O AppSignal reportará automaticamente erros dentro de Rails runners. Alguma configuração manual também é necessária para instrumentar a performance de um runner. Recomendamos colocar o código do runner em um arquivo separado e envolvê-lo no helperAppsignal.monitor, como mostrado no exemplo abaixo.
Bash
enable_at_exit_hook esteja definida como true (o que deve ser o padrão em containers). Isso garantirá que os dados sejam descarregados para o agent do AppSignal antes do runner ser desligado.
Atributos de span
Somente no modo collector: isso se aplica quando o AppSignal para Ruby é executado no modo collector. Nos demais casos, não tem efeito.
http.request.method— o método da requisição.url.scheme,url.patheurl.query— o endereço requisitado.http.response.status_code— o status com o qual sua aplicação respondeu.
error.type, a classe do erro.
Cada query do Active Record registra seu próprio span, que contém:
db.system.name— o banco de dados no qual a query rodou, comopostgresqloumysql.db.query.text— a query, com seus valores removidos.
Rastreamento distribuído
Somente no modo collector: isso se aplica quando o AppSignal para Ruby é executado no modo collector. Nos demais casos, não tem efeito.
traceparent continua o trace que ele nomeia.
A requisição aparece dentro do trace do serviço que a chamou, sob a requisição que a causou. Você pode seguir uma requisição lenta desse serviço até esta aplicação sem trocar de trace.
Os clientes HTTP suportados pelo AppSignal iniciam o trace. Uma requisição sem o header inicia um novo.