Ruby agent release notesRSS

v8.12.0

A versão 8.12.0 do agente Ruby oferece uma nova instrumentação do Elasticsearch. A versão 8.12.0 do agente Ruby também aumenta o número padrão de eventos personalizados registrados, anuncia a descontinuação do Ruby 2.3 e traz uma limpeza de código valiosa.

• Suporte para instrumentação do Elasticsearch

  Esta versão do agente Ruby adiciona suporte para instrumentar automaticamente a gem elasticsearch. As versões 7.x e 8.x são suportadas. PR#1525

  Nome da configuração	Padrão	Comportamento
  instrumentation.elasticsearch	auto	Controla a instrumentação automática da biblioteca elasticsearch na inicialização. Pode ser um de auto, prepend, chain, disabled.
  elasticsearch.capture_queries	verdadeiro	Se true, o agente captura a consulta do Elasticsearch no rastreamento da transação.
  elasticsearch.obfuscate_queries	verdadeiro	Se true, o agente ofusca a consulta do Elasticsearch no rastreamento da transação.

• Aumento do limite de eventos personalizados

  Esta versão do agente Ruby aumenta o limite padrão de eventos personalizados de 1.000 eventos por minuto para 3.000 eventos por minuto. Se os seus eventos personalizados estavam sendo limitados, essa alteração permitirá que mais eventos personalizados sejam enviados para a New Relic. Há também um novo limite máximo configurável de 100.000 eventos por minuto. Para alterar os limites, consulte a documentação para max_samples_stored. Para saber mais sobre a mudança e como determinar se eventos personalizados estão sendo descartados, consulte nossa postagem no Explorers Hub. PR#1541

• Descontinuar o suporte para Ruby 2.3

  O Ruby 2.3 atingiu o fim da vida útil em 31 de março de 2019. O agente Ruby descontinuou o suporte para o Ruby 2.3 e fará alterações de quebra para esta versão em sua próxima versão principal, v9.0.0 (data de lançamento ainda não planejada). Todas as versões 8.x.x do agente permanecerão compatíveis com o Ruby 2.3.

• Limpeza: remover código órfão

  Tanto no agente quanto nos testes de unidade, ocorreram mudanças ao longo dos anos que deixaram certos trechos de código inacessíveis. Esse código órfão pode complicar a manutenção e a refatoração do código, portanto, resolvê-lo pode ser muito útil. O membro da comunidade @ohbarye contribuiu com dois PRs de limpeza separados para esta versão; um para o agente e outro para os testes. PR#1537 PR#1548

  Agradecemos a @ohbarye por contribuir com esta limpeza útil!

Declaração de apoio

A New Relic recomenda atualizar o agente Ruby regularmente e, no mínimo, a cada 3 meses. A partir desta versão, a versão mais antiga suportada é a 6.7.0.359.

v8.11.0

Version 8.11.0 of the agent updates the newrelic deployments command to work with API keys issued to newer accounts, fixes a memory leak in the instrumentation of Curb error handling, further preps for Ruby 3.2.0 support, and includes several community member driven cleanup and improvement efforts. Thank you to everyone involved!

• Added support for New Relic REST API v2 when using newrelic deployments command

  Previously, the newrelic deployments command only supported the older version of the deployments api, which does not currently support newer license keys. Now you can use the New Relic REST API v2 to record deployments by providing your user API key to the agent configuration using api_key. When this configuration option is present, the newrelic deployments command will automatically use the New Relic REST API v2 deployment endpoint. PR#1461

  Thank you to @Arkham for bringing this to our attention!

• Cleanup: Performance tests, constants, rubocop-minitest assertions and refutations

  Community member @esquith contributed a whole slew of cleanup successes for our performance test configuration, orphaned constants in our code base, and RuboCop related improvements. PR#1406 PR#1408 PR#1409 PR#1411

  Thank you @esquith for these great contributions!

• CI: Notify on a change from failure to success

  A super handy, much beloved feature of certain CI and build systems is to not only notify when builds start to fail, but also to notify again when the builds once again start to go green. Community member @luigieai was able to figure out how to configure our existing complex, multiple-3rd-party-action based GitHub Actions pipeline to notify on a switch back to success from failure. PR#1519

  This is much appreciated! Thank you, @luigieai.

• Spelling corrections

  Community member @jsoref, author of the Check Spelling GitHub Action, contributed a significant number of spelling corrections throughout the code base. The intelligent issues that were flagged made for a more comprehensive review than a simple dictionary based check would have been able to provide, and the changes are much appreciated. PR#1508

  Thank you very much, @jsoref!

• Ruby 3.2.0-preview2 compatibility

  Ruby 3.2.0-preview1 introduced a change to the way that Ruby reports VM stats and the approach was changed yet again to a 3rd approach with the preview2 release. New Relic reports on Ruby VM stats and is keeping track of the Ruby 3.2 development process to help ensure our customers with a smooth and worthwhile upgrade process once Ruby 3.2.0 (non-preview) is released. PR#1436

• Bugfix: Fix memory leak in the Curb instrumentation

  Community member @charkost was able to rework the on_failure callback logic prepped via the agent's Curb instrumentation in order to avoid some nesting that was causing memory leaks. PR#1518

  Many thanks for both the heads up on the issue and the fix, @charkost!

Support statement

New Relic recommends that you upgrade the agent regularly and at a minimum every 3 months. As of this release, the oldest supported version is 6.7.0.359.

v8.10.1

• Bugfix: Missing unscoped metrics when instrumentation.thread.tracing is enabled

  Previously, when instrumentation.thread.tracing was set to true, some puma applications encountered a bug where a varying number of unscoped metrics would be missing. The agent now will correctly store and send all unscoped metrics.

  Thank you to @texpert for providing details of their situation to help resolve the issue.

• Bugfix: gRPC instrumentation causes ArgumentError when other Google gems are present

  Previously, when the agent had gRPC instrumentation enabled in an application using other gems (such as google-ads-googleads), the instrumentation could cause the error ArgumentError: wrong number of arguments (given 3, expected 2). The gRPC instrumentation has been updated to prevent this issue from occurring in the future.

  Thank you to @FeminismIsAwesome for bringing this issue to our attention.

Support statement

New Relic recommends that you upgrade the agent regularly and at a minimum every 3 months. As of this release, the oldest supported version is 6.5.0.357.

v8.10.0

• New gRPC instrumentation

  The agent will now instrument gRPC activity performed by clients and servers that use the grpc RubyGem. Instrumentation is automatic and enabled by default, so gRPC users should not need to modify any existing application code or agent configuration to benefit from the instrumentation. The instrumentation makes use of distributed tracing for a comprehensive overview of all gRPC traffic taking place across multiple monitored applications. This allows you to observe your client and server activity using any service that adheres to the W3C standard.

  The following new configuration parameters have been added for gRPC. All are optional.

  Configuration name	Default	Behavior
  instrumentation.grpc_client	auto	Set to 'disabled' to disable, set to 'chain' if there are module prepending conflicts
  instrumentation.grpc_server	auto	Set to 'disabled' to disable, set to 'chain' if there are module prepending conflicts
  instrumentation.grpc.host_denylist	""	Provide a comma delimited list of host regex patterns (ex: "private.com$,exception.*")

• Code-level metrics functionality is enabled by default

  The code-level metrics functionality for the Ruby agent's CodeStream integration is now enabled by default after we have received positive feedback and no open bugs for the past two releases.

• Performance: Rework timing range overlap calculations for multiple transaction segments

  Many thanks to GitHub community members @bmulholland and @hkdnet. @bmulholland alerted us to rmosolgo/graphql-ruby#3945. That Issue essentially notes that the New Relic Ruby agent incurs a significant perfomance hit when the graphql RubyGem (which ships with New Relic Ruby agent support) is used with DataLoader to generate a high number of transactions. Then @hkdnet diagnosed the root cause in the Ruby agent and put together both a proof of concept fix and a full blown PR to resolve the problem. The agent keeps track multiple segments that are concurrently in play for a given transaction in order to merge the ones whose start and stop times intersect. The logic for doing this find-and-merge operation has been reworked to a) be deferred entirely until the transaction is ready to be recorded, and b) made more performant when it is needed. GraphQL DataLoader users and other users who generate lots of activity for monitoring within a short amount of time will hopefully see some good performance gains from these changes.

• Performance: Make frozen string literals the default for the agent

  The Ruby frozen_string_literal: true magic source code comment has now been applied consistently across all Ruby files belonging to the agent. This can provide a performance boost, given that Ruby can rely on the strings remaining immutable. Previously only about a third of the agent's code was freezing string literals by default. Now that 100% of the code freezes string literals by default, we have internally observed some related performance gains through testing. We are hopeful that these will translate into some real world gains in production capacities.

• Bugfix: Error when setting the yaml configuration with transaction_tracer.transaction_threshold: apdex_f

  Originally, the agent was only checking the transaction_tracer.transaction_threshold from the newrelic.yml correctly if it was on two lines.

  Example:

  # newrelic.yml
  transaction_tracer:
    transaction_threshold: apdex_f

  コピー

  When this was instead changed to be on one line, the agent was not able to correctly identify the value of apdex_f.

  Example:

  # newrelic.yml
  transaction_tracer.transaction_threshold: apdex_f

  コピー

  This would cause prevent transactions from finishing due to the error ArgumentError: comparison of Float with String failed. This has now been corrected and the agent is able to process newrelic.yml with a one line transaction_tracer.transaction_threshold: apdex_f correctly now.

  Thank you to @oboxodo for bringing this to our attention.

• Bugfix: Don't modify frozen Logger

  Previously the agent would modify each instance of the Logger class by adding a unique instance variable as part of the instrumentation. This could cause the error FrozenError: can't modify frozen Logger to be thrown if the Logger instance had been frozen. The agent will now check if the object is frozen before attempting to modify the object. Thanks to @mkcosta for bringing this issue to our attention.

Support statement

New Relic recommends that you upgrade the agent regularly and at a minimum every 3 months. As of this release, the oldest supported version is 6.5.0.357.

v8.9.0

• Add support for Dalli 3.1.0 to Dalli 3.2.2

  Dalli versions 3.1.0 and above include breaking changes where the agent previously hooked into the gem. We have updated our instrumentation to correctly hook into Dalli 3.1.0 and above. At this time, 3.2.2 is the latest Dalli version and is confirmed to be supported.

• Bugfix: Infinite Tracing hung on connection restart

  Previously, when using infinite tracing, the agent would intermittently encounter a deadlock when attempting to restart the infinite tracing connection. This bug would prevent the agent from sending all data types, including non-infinite-tracing-related data. This change reworks how we restart Infinite Tracing to prevent potential deadlocks.

• Bugfix: Use read_nonblock instead of read on pipe

  Previously, our PipeChannelManager was using read which could cause resque jobs to get stuck in some versions. This change updates the PipeChannelManager to use read_nonblock instead to avoid this issue.

Support statement

New Relic recommends that you upgrade the agent regularly and at a minimum every 3 months. As of this release, the oldest supported version is 6.5.0.357.

v8.8.0

• Support Makara database adapters with ActiveRecord

  Thanks to a community submission from lucasklaassen with PR #1177, the Ruby agent will now correctly work well with the Makara gem. Functionality such as SQL obfuscation should now work when Makara database adapters are used with Active Record.

• Lowered the minimum payload size to compress

  Previously the Ruby agent used a particularly large payload size threshold of 64KiB that would need to be met before the agent would compress data en route to New Relic's collector. The original value stems from segfault issues that very old Rubies (older than 2.2) used to encounter when compressing smaller payloads. This value has been lowered to 2KiB (2048 bytes), which should provide a more optimal balance between the CPU cycles spent on compression and the bandwidth savings gained from it.

• Provide Code Level Metrics for New Relic CodeStream

  For Ruby on Rails applications and/or those with manually traced methods, the agent is now capable of reporting metrics with Ruby method-level granularity. When the new code_level_metrics.enabled configuration parameter is set to a true value, the agent will associate source-code-related metadata with the metrics for things such as Rails controller methods. Then, when the corresponding Ruby class file that defines the methods is loaded up in a New Relic CodeStream-powered IDE, the four golden signals for each method will be presented to the developer directly.

• Supportability Metrics will always report uncompressed payload size

  New Relic's agent specifications call for Supportability Metrics to always reference the uncompressed payload byte size. Previously, the Ruby agent was calculating the byte size after compression. Furthermore, compression is only performed on payloads of a certain size. This means that sometimes the value could have represented a compressed size and sometimes an uncompressed one. Now the uncompressed value is always used, bringing consistency for comparing two instances of the same metric and alignment with the New Relic agent specifications.

Support statement

New Relic recommends that you upgrade the agent regularly and at a minimum every 3 months. As of this release, the oldest supported version is 6.5.0.357.

v8.7.0

• Encaminhamento de logs do logs-in-context do APM ativado por padrão

  O encaminhamento automático de logs de aplicativo agora está habilitado por padrão. Esta versão do agente enviará automaticamente logs de aplicativo enriquecidos para o New Relic. Para saber mais sobre este recurso, consulte aqui, e opções adicionais de configuração estão disponíveis aqui. Para saber como ativar ou desativar a ingestão de logs por conta, consulte aqui.

• Suporte assíncrono aprimorado e instrumentação de Thread

  Anteriormente, o agente não era capaz de registrar eventos e métricas dentro de Threads criadas dentro de uma transação já em execução. Esta versão inclui 2 novas opções de configuração para oferecer suporte a aplicativos multithread para instrumentar threads automaticamente. Uma nova opção de configuração,instrumentation.thread.tracing (desativada por padrão), foi introduzida e, quando ativada, permitirá que o agente insira o rastreamento do New Relic dentro de todas as Threads criadas por um aplicativo. Para oferecer suporte a aplicativos que desejam apenas que algumas threads sejam instrumentadas pelo New Relic, uma nova classe está disponível, NewRelic::TracedThread, que criará uma thread que inclui a instrumentação do New Relic, consulte a nossa documentação da API para obter mais detalhes.

  Novas opções de configuração incluídas nesta versão:

  Nome da configuração	Padrão	Comportamento
  instrumentation.thread	auto (habilitado)	Permite que o agente aninhe spans corretamente dentro de uma transação assíncrona.
  instrumentation.thread.tracing	false (desabilitado)	Adicionar rastreamento automaticamente a todas as Threads criadas no aplicativo. Isso pode ser ativado por padrão em uma versão futura.

  Gostaríamos de agradecer ao @mikeantonelli por compartilhar um gist conosco que forneceu à nossa equipe um ponto de partida para este recurso.

• Descontinuar o suporte para Ruby 2.2

  O Ruby 2.2 chegou ao fim da vida útil em 31 de março de 2018. O agente descontinuou o suporte para o Ruby 2.2 e fará alterações que quebram a compatibilidade para esta versão em seu próximo lançamento principal.

• Adicionadas opções de configuração atualizadas para eventos de transação e preteridas as configurações anteriores

  Esta versão descontinua a seguinte instrumentação:

  Descontinuada	Substituição
  ActiveMerchant 1.64.0 ou inferior	ActiveMerchant 1.65.0 ou superior
  ActiveRecord 3.2.22.5 ou inferior	ActiveRecord 4.0.0 ou superior
  Acts As Solr (todas as versões)	nenhum
  Authlogic (todas as versões)	nenhum
  Bunny 2.6.7 ou inferior	Bunny 2.7.0 ou superior
  Dalli 2.7.6 ou inferior	Dalli 2.7.7 ou superior
  DataMapper (todas as versões)	nenhum
  Delayed Job 4.1.2 ou inferior	Delayed Job 4.1.3 ou superior
  Excon 0.55.0 ou inferior	Excon 0.56.0 ou superior
  Grape 0.19.1 ou inferior	Grape 0.19.2 ou superior
  HTTPClient 2.8.2.4 ou inferior	HTTPClient 2.8.3
  HTTP.rb 2.2.1 ou inferior	HTTP.rb 2.2.2 ou superior
  Mongo 2.4.0 ou inferior	Mongo 2.4.1 ou superior
  Padrino 0.14.4 ou inferior	Padrino 0.15.0 ou superior
  Passenger 5.1.2 ou inferior	Passenger 5.1.3 ou superior
  Puma 3.8.2 ou inferior	Puma 3.9.0 ou superior
  Rack 1.6.7 ou inferior	Rack 1.6.8 ou superior
  Rails 3.2.22.5 ou inferior	Rails 4.0.0 ou superior
  Rainbows (todas as versões)	nenhum
  Sequel 4.44.0 ou inferior	Sequel 4.45.0 ou superior
  Sidekiq 4.2.10 ou inferior	Sidekiq 5.0.0 ou superior
  Sinatra 1.4.8 ou inferior	Sinatra 2.0.0 ou superior
  Sunspot (todas as versões)	nenhum
  Typhoeus 1.1.2 ou inferior	Typhoeus 1.3.0 ou superior
  Unicorn 5.2.0 ou inferior	Unicorn 5.3.0 ou superior

  Para as gems com versões descontinuadas, não testaremos mais essas versões em nossa suíte multiverse. Elas podem, no entanto, ainda ser compatíveis com o agente. Não corrigiremos mais os relatórios de bugs para problemas com essas versões da gem.

• Utilizar internamente Object.const_get e Object.const_defined?

  Ao verificar dinamicamente ou obter uma referência para uma constante de classe a partir de uma string, aproveite os métodos integrados da classe Object sempre que possível para desfrutar de operações mais simples e com melhor desempenho. Todos os JRubies e CRubies v2.5 e anteriores precisam de um pouco de assistência além do que Object pode fornecer, visto que esses Rubies podem gerar uma constante indesejada de um namespace diferente daquele que foi especificado. Mas para todos os outros Rubies e até mesmo para aqueles Rubies em contextos onde podemos confiar 100% no valor da string recebida, aproveite os métodos da classe Object e colha os benefícios.

• Esclarecer a documentação para a configuração de rake.tasks

  A descrição de rake.tasks no arquivo newrelic.yml padrão e a documentação de configuração do agente Ruby da New Relic foram atualizadas para esclarecer seu comportamento e uso. A documentação agora diz:

  Especifique uma matriz de tarefas Rake para instrumentar automaticamente. Esta opção de configuração converte a matriz em uma lista RegEx. Se você desejar permitir todas as tarefas por padrão, use rake.tasks: [.+]. As tarefas Rake não serão instrumentadas, a menos que sejam adicionadas a esta lista. Para mais informações, visite a (documentação de instrumentação Rake do New Relic)[/docs/apm/agents/ruby-agent/background-jobs/rake-instrumentation].

  Agradecemos a @robotfelix por sugerir estas alterações.

• Habilitar a configuração de Variáveis de Ambiente para converter configurações de matriz em matrizes

  Antes dessa alteração, quando listas separadas por vírgulas eram passadas como variáveis de ambiente, um erro era emitido para o newrelic_agent.log e uma String era definida como o valor. Agora, as matrizes serão convertidas com precisão.

• Correção de bug: permitir que TransactionEvents sejam amostrados na taxa esperada

  O valor de capacidade transaction_events.max_samples_stored dentro do TransactionEventAggregator não correspondia ao intervalo esperado do seu ciclo de coleta, fazendo com que os TransactionEvents fossem superamostrados. Esta correção de bug se baseia nas atualizações feitas em #952 para que o intervalo e a capacidade se comportem conforme o esperado para as opções de configuração transaction_events* renomeadas.

• Correção de bug: eventos de erro sem atributos quando criados fora de uma transação

  Anteriormente, o agente não atribuía uma prioridade aos eventos de erro que eram criados ao chamar notice_error fora do escopo de uma transação. Isso causou problemas com a amostragem quando o buffer de eventos de erro estava cheio, resultando em um NoMethodError: undefined method '<' for nil:NilClass no newrelic_agent.log. Esta correção de bug garante que uma prioridade seja sempre atribuída a eventos de erro, para que o agente seja capaz de realizar amostras desses eventos de erro corretamente. Agradecemos a @olleolleolle por trazer este problema à nossa atenção.

Declaração de apoio

A New Relic recomenda que você atualize o agente regularmente e, no mínimo, a cada 3 meses. A partir desta versão, a versão mais antiga suportada é a 5.7.0.350.