Ruby agent release notesRSS

Recurso: reportar um nome do host exclusivo para os Worker Pools e Jobs do Google Cloud Run

O suporte ao nome do host do Cloud Run, adicionado no PR#3609, detectava o Cloud Run apenas por meio de K_REVISION, a variável de ambiente definida pelos Services do Cloud Run. O agente agora também reconhece CLOUD_RUN_REVISION (Worker Pools) e CLOUD_RUN_EXECUTION (Jobs), portanto, utilization.gcp_cloud_run.use_instance_as_host agora se aplica a todos os três tipos de recursos. Quando utilization.gcp_cloud_run.include_revision_in_host é true, o nome do host é criado a partir de qualquer uma dessas variáveis que esteja presente — por exemplo, {CLOUD_RUN_EXECUTION}-{instance id} para um Job. Issue#3651 PR#3652

Recurso: adicionar a opção de configuração browser_monitoring.version

Os clientes agora podem fixar a versão exata do loader do agente do browser que a New Relic injeta definindo a nova opção de configuração browser_monitoring.version. Consulte a política de EOL do agente do browser para ver quais versões estão atualmente disponíveis e suportadas. PR#3663

Recurso: adicionar span.kind às bibliotecas de trabalhos em segundo plano

Agora, o atributo span.kind será adicionado às operações produce e consume de bibliotecas de trabalhos em segundo plano. Isso inclui ActiveJob, Sidekiq, Resque e DelayedJob. PR#3636

Correção de bug: a instrumentação do DelayedJob não se reinstala mais em cada worker no modo prepend

Quando a instrumentação do DelayedJob é instalada via prepend (o padrão), criar mais de um Delayed::Worker no mesmo processo fazia com que o agente registrasse “Installing DelayedJob instrumentation” e reinicializasse o plug-in novamente para cada worker adicional. Isso era inofensivo, mas ruidoso; agora é feito apenas uma vez por processo, correspondendo ao comportamento existente da instrumentação de cadeia. PR#3654

Correção de bug: os valores de configuração na lista de permissões não diferenciam mais maiúsculas de minúsculas

Anteriormente, as opções de configuração permitidas exigiam uma correspondência exata de maiúsculas e minúsculas, de modo que um valor com uso inesperado de maiúsculas e minúsculas — como OBFUSCATED ou ObFuScAtEd para slow_sql.record_sql — reverteria silenciosamente para o padrão. As opções de configuração que são validadas em uma lista de permissões agora correspondem aos valores independentemente de maiúsculas e minúsculas, portanto, ambos são tratados da mesma forma que obfuscated. Issue#3613 PR#3645

Correção de bug: a instrumentação do Puma funciona quando o Puma é carregado sob demanda

Com gem "puma", require: false, o Puma ainda não estava carregado quando a verificação de dependência do agente era executada, portanto, a instrumentação do Puma falhava ao ser instalada. O agente agora reconhece Puma::RackHandler como evidência de que o Puma está presente, corrigindo esse problema. Issue#3641 PR#3650

Correção de bug: resolve ArgumentError em operações de múltiplas chaves com Dalli 5.1.0

Esta correção atualiza a instrumentação do Dalli para aceitar e encaminhar argumentos opcionais de opções de requests em operações múltiplas e em pipeline. Nossos agradecimentos a @dbackeus por contribuir com uma correção! PR#3642

Correção de bug: as requests de Async::HTTP não geram mais NoMethodError quando um segmento falha ao iniciar

Se o agente encontrasse um erro interno ao criar o segmento para uma solicitação Async::HTTP, a instrumentação continuava a usar esse segmento ausente e poderia gerar um NoMethodError. Isso agora está corrigido, graças a @ydah. PR#3640

Recurso: adicionar transaction_tracer.cap_segment_artifacts opção de configuração

Transações de longa duração com muitos segmentos podem causar o aumento contínuo do uso de memória durante a vida útil da transação. O agente agora oferece uma opção de configuração transaction_tracer.cap_segment_artifacts opcional (o padrão é false). Quando ativado, assim que transaction_tracer.limit_segments for atingido, o agente também para de registrar o tempo exclusivo para quaisquer segmentos criados posteriormente nessa transação, reduzindo o uso de memória à custa de dados de tempo menos precisos para a transação. PR#3615

Recurso: Adicionar instrumentação de estatísticas do servidor Puma

O agente agora faz a amostragem das estatísticas do servidor em todo o cluster do Puma e as relata como métricas de timeslice Ruby/Puma/*, incluindo backlog, running, pool_capacity, max_threads e requests_count. As estatísticas são amostradas no modo único e no modo em cluster quando preload_app! está habilitado. Esta instrumentação está desabilitada por padrão. Habilite-a definindo disable_puma_instrumentation como false. Quando habilitado, o agente inicia uma thread de relatório no processo mestre do Puma para entregar essas métricas, o que executa uma conexão adicional do agente junto com os workers do Puma. O intervalo de amostragem é configurável por meio da nova configuração puma.sample_rate (padrão de 60 segundos). Requer o Puma 6.6 ou posterior. Consulte nossos documentos para obter mais informações. PR#3578

Recurso: relatar um nome do host exclusivo para instâncias do Google Cloud Run

O agente agora detecta o Cloud Run e relata o ID da instância do GCP como o nome do host para que instâncias individuais possam ser distinguidas. Antes dessa alteração, todos os nomes do host do Google Cloud Run eram localhost. Esse recurso é controlado pela nova opção de configuração utilization.gcp_cloud_run.use_instance_as_host (padrão true). utilization.gcp_cloud_run.include_revision_in_host (padrão false) deve ser definido como true para, em vez disso, relatar o nome do host como {K_REVISION}-{instance id}, em que K_REVISION é o nome da revisão do Cloud Run. Issue n.º 3295 PR n.º 3609

Correção de bug: o SQL lento não é mais registrado após transaction_tracer.limit_segments excedido

Depois que uma transação excedia transaction_tracer.limit_segments, os segmentos de armazenamento de dados criados posteriormente ainda podiam ter seu SQL lento registrado. O agente agora para de registrar SQL lento para qualquer segmento criado após o limite ser atingido. PR#3615

Correção de bug: os planos de execução poderiam ter como destino o banco de dados errado em aplicativos Rails com vários bancos de dados (Rails >= 7.2)

No Rails 7.2+, o agente coletou planos de explicação usando uma conexão do pool padrão/compartilhado do aplicativo, em vez de uma dedicada. Isso afetou principalmente aplicativos com vários bancos de dados. Os planos de explicação poderiam ser gerados no banco de dados errado, e uma explicação com falha poderia deixar uma conexão compartilhada em um estado ruim, afetando requests não relacionados. O agente agora usa sua própria conexão dedicada para planos de explicação, como fazia antes do Rails 7.2, e redefine ou descarta essa conexão sempre que uma tentativa de explicação falha, para que uma conexão ruim nunca seja reutilizada. Issue#3610 PR#3612

Correção de bug: a instrumentação do monitoramento de Browser não falha mais com FrozenError

Quando o primeiro fragmento do corpo de uma resposta era um String congelado e havia vários fragmentos, a instrumentação do navegador atingia um FrozenError e o cabeçalho de tempo do navegador nunca era injetado. Isso começou a aparecer com o ERB 6.0.3+, que começou a congelar mais de suas strings compiladas. Esse problema já foi resolvido. Issue#3624 PR#3625

Correção de bug: normalizar valores de configuração booleanos para permitir qualquer formato de maiúsculas e minúsculas

Na versão 9.x, o agente aceitava valores booleanos em maiúsculas, como "FALSE", e valores com letras maiúsculas e minúsculas, como "True". A versão 10.0.0 incluiu o PR#3341, que removeu acidentalmente o requisito de não diferenciar maiúsculas de minúsculas. Isso fez com que os usuários que tivessem qualquer uso de maiúsculas e minúsculas além de todas minúsculas tivessem suas opções de configuração revertidas para os padrões. Agora, o agente usa verificações que não diferenciam maiúsculas de minúsculas novamente. Issue#3632 PR#3633

Recurso: eventos SpanLink agora são suportados para o agente Hybrid

Spans criados por uma API do OpenTelemetry agora podem ter Span Links associados a eles. Links podem ser adicionados no início de um span, passando-os para o argumento links, ou chamando a API OpenTelemetry::Trace::Span#add_link. PR#3586

Recurso: eventos SpanEvent agora são suportados para o agente Hybrid

Os spans criados por uma API do OpenTelemetry agora podem ter eventos SpanEvent associados a eles por meio da API OpenTelemetry::Trace::Span#add_event. Os eventos SpanEvent capturam anotações com timestamp em um span e são enviados para o New Relic junto com o span pai. PR#3587

Recurso: definir o tipo de span em todos os spans do agente Hybrid

Anteriormente, apenas os spans do OpenTelemetry traduzidos em segmentos de solicitação externa ou segmentos de armazenamento de dados adicionavam o tipo de span como um atributo. Agora, o agente adiciona o tipo de span a todos os spans do OpenTelemetry onde o valor está disponível. PR#3589

Recurso: adicionar suporte para OpenTelemetry::Tracer#start_root_span

A API OpenTelemetry::Tracer#start_root_span agora pode ser usada para forçar o início de uma transação para um determinado span, desde que ele tenha um tipo de span :server ou :consumer. Para quaisquer outros tipos de span, ela não executará nenhuma ação. Esse método é mais comumente usado na instrumentação de jobs em segundo plano. PR#3588

Correção de bug: corrigir instrumentation.rails_event_logger: false não desativando a instrumentação

Anteriormente, definir instrumentation.rails_event_logger como false não desativava a instrumentação de Rails.event como esperado; ela ainda era instalada durante a inicialização do Rails. O problema já foi resolvido. PR#3564

Correção de bug: normalizar valores semelhantes a booleanos para disabled em chaves de configuração de instrumentação

Anteriormente, apenas disabled desativaria uma chave de configuração instrumentation.*. Agora, valores do tipo booleano, como false, no ou off, também são resolvidos como disabled e impedem que a instrumentação seja instalada. PR#3579

Correção de bug: métricas de suportabilidade de logging por biblioteca agora refletem o estado de instrumentação de cada biblioteca

Anteriormente, as métricas Supportability/Logging/Ruby/{library}/{enabled|disabled} relatavam o valor da configuração global application_logging.enabled para cada biblioteca, em vez do estado real de cada biblioteca. Como resultado, a métrica relatava enabled mesmo quando você havia desativado a instrumentação de log para uma biblioteca específica ou não estava usando a gem dessa biblioteca. Agora, a métrica de cada biblioteca reflete se sua própria instrumentação de log está ativada. PR#3571