v8.7.0

• Transfert de logs des logs en contexte APM activé par défaut

  Le transfert automatique de logs d’application est désormais activé par défaut. Cette version de l’agent enverra automatiquement des logs d’application enrichis à New Relic. Pour en savoir plus sur cette fonctionnalité, cliquez ici, et des options de configuration supplémentaires sont disponibles ici. Pour savoir comment activer ou désactiver l’ingestion de logs par compte, cliquez ici.

• Amélioration de la prise en charge asynchrone et de l'instrumentation des threads

  Auparavant, l’agent n’était pas en mesure d’enregistrer les événements, et les métriques dans les Threads créés au sein d’une transaction déjà en cours d’exécution. Cette sortie comprend 2 nouvelles options de configuration pour prendre en charge les applications multithreads afin d’instrumenter automatiquement les threads. Une nouvelle option de configuration,instrumentation.thread.tracing (désactivée par défaut), a été introduite, et, lorsqu’elle est activée, elle permettra à l’agent d’insérer le tracing New Relic dans tous les Threads créés par une application. Pour prendre en charge les applications qui souhaitent uniquement que certains threads soient instrumentés par New Relic, une nouvelle classe est disponible, NewRelic::TracedThread, qui créera un thread incluant l’instrumentation New Relic ; consultez notre documentation de l’API pour obtenir plus de détails.

  Nouvelles options de configuration incluses dans cette sortie :

  Nom de la configuration	Défaut	Comportement
  instrumentation.thread	auto (enabled)	Permet à l'agent d'imbriquer correctement les spans à l'intérieur d'une transaction asynchrone.
  instrumentation.thread.tracing	false (désactivé)	Ajouter automatiquement le tracing à tous les threads créés dans l’application. Cela pourrait être activé par défaut dans une sortie ultérieure.

  Nous tenons à remercier @mikeantonelli d’avoir partagé avec nous un gist qui a fourni à notre équipe un point d’entrée pour cette fonctionnalité.

• Dépréciation de la prise en charge de Ruby 2.2

  Ruby 2.2 a atteint sa fin de vie le 31 mars 2018. L’agent a déprécié la prise en charge de Ruby 2.2 et apportera des modifications majeures pour cette version lors de sa prochaine sortie majeure.

• Ajout d’options de configuration mises à jour pour les événements de transaction et dépréciation des configurations précédentes

  Cette sortie rend obsolète l’instrumentation suivante :

  Obsolète	Remplacement
  ActiveMerchant 1.64.0 ou version antérieure	ActiveMerchant 1.65.0 ou version ultérieure
  ActiveRecord 3.2.22.5 ou version inférieure	ActiveRecord 4.0.0 ou supérieur
  Acts As Solr (toutes les versions)	aucun
  Authlogic (toutes les versions)	aucun
  Bunny 2.6.7 ou inférieur	Bunny 2.7.0 ou version ultérieure
  Dalli 2.7.6 ou inférieur	Dalli 2.7.7 ou version ultérieure
  DataMapper (toutes les versions)	aucun
  Delayed Job 4.1.2 ou version antérieure	Delayed Job 4.1.3 ou supérieur
  Excon 0.55.0 ou version antérieure	Excon 0.56.0 ou version ultérieure
  Grape 0.19.1 ou version antérieure	Grape 0.19.2 ou version ultérieure
  HTTPClient 2.8.2.4 ou version antérieure	HTTPClient 2.8.3
  HTTP.rb 2.2.1 ou version antérieure	HTTP.rb 2.2.2 ou version ultérieure
  Mongo 2.4.0 ou version antérieure	Mongo 2.4.1 ou version ultérieure
  Padrino 0.14.4 ou inférieur	Padrino 0.15.0 ou version ultérieure
  Passenger 5.1.2 ou inférieur	Passenger 5.1.3 ou supérieur
  Puma 3.8.2 ou version inférieure	Puma 3.9.0 ou version ultérieure
  Rack 1.6.7 ou version antérieure	Rack 1.6.8 ou supérieur
  Rails 3.2.22.5 ou version antérieure	Rails 4.0.0, ou version ultérieure
  Rainbows (toutes les versions)	aucun
  Sequel 4.44.0 ou inférieur	Sequel 4.45.0 ou version ultérieure
  Sidekiq 4.2.10 ou version antérieure	Sidekiq 5.0.0 ou supérieur
  Sinatra 1.4.8 ou inférieur	Sinatra 2.0.0 ou supérieur
  Sunspot (toutes les versions)	aucun
  Typhœus 1.1.2 ou inférieur	Typhoeus 1.3.0 ou version ultérieure
  Unicorn 5.2.0 ou version antérieure	Unicorn 5.3.0 ou version ultérieure

  Pour les gems avec des versions obsolètes, nous ne testerons plus ces versions dans notre suite multiverse. Elles peuvent, cependant, toujours être compatibles avec l'agent. Nous ne traiterons plus les rapports de bugs pour les problèmes rencontrés avec ces versions de la gem.

• Exploiter en interne Object.const_get, et Object.const_defined?

  Lorsque vous recherchez dynamiquement une constante de classe à partir d’une chaîne, ou que vous en obtenez une référence, utilisez les méthodes intégrées de la classe Object dans la mesure du possible pour bénéficier d’opérations plus simples, et plus performantes. Tous les JRubies, et CRubies v2.5, et versions antérieures ont besoin d’un peu d’aide au-delà de ce que Object peut fournir, étant donné que ces Rubies peuvent renvoyer une constante indésirable provenant d’un espace de nommage différent de celui qui a été spécifié. Mais pour tous les autres Rubies, et même pour ces Rubies dans des contextes où nous pouvons faire confiance à 100 % à la valeur de la chaîne entrante, utilisez les méthodes de la classe Object, et profitez de leurs avantages.

• Clarifier la documentation pour la configuration de rake.tasks

  La description de rake.tasks dans le fichier newrelic.yml par défaut et la documentation de configuration de l’agent Ruby New Relic ont été mises à jour pour clarifier son comportement et son utilisation. La documentation indique désormais :

  Spécifiez un éventail de tâches Rake à instrumenter automatiquement. Cette option de configuration convertit l’éventail en une liste RegEx. Si vous souhaitez autoriser toutes les tâches par défaut, utilisez rake.tasks: [.+]. Les tâches Rake ne seront pas instrumentées à moins qu’elles ne soient ajoutées à cette liste. Pour plus d’informations, consultez la (documentation sur l’instrumentation New Relic Rake)[/docs/apm/agents/ruby-agent/background-jobs/rake-instrumentation].

  Nous remercions @robotfelix d’avoir suggéré ces modifications.

• Activez le paramètre des variables d’environnement permettant aux configurations d’éventail d’être converties en éventails

  Avant ce changement, lorsque des listes séparées par des virgules étaient passées comme variables d’environnement, une erreur était émise vers le newrelic_agent.log, et un String était défini comme valeur. Désormais, les éventails seront convertis avec précision.

• Correction de bug : permet aux TransactionEvents d’être échantillonnés au taux attendu

  La valeur de capacité transaction_events.max_samples_stored dans le TransactionEventAggregator ne correspondait pas à son intervalle de cycle de collecte attendu, provoquant un suréchantillonnage des TransactionEvents. Ce correctif s’appuie sur les mises à jour effectuées dans #952 afin que l’intervalle et la capacité se comportent comme prévu pour les options de configuration transaction_events* renommées.

• Correction de bug : attributs manquants pour les événements d’erreur créés en dehors d’une transaction

  Auparavant, l’agent n’attribuait pas de priorité aux événements d’erreur qui étaient créés en appelant notice_error en dehors de la portée d’une transaction. Cela causait des problèmes d’échantillonnage lorsque le tampon de l’événement d’erreur était plein, entraînant un NoMethodError: undefined method '<' for nil:NilClass dans le newrelic_agent.log. Cette correction de bug garantit qu’une priorité est toujours attribuée aux événements d’erreur afin que l’agent soit capable d’échantillonner correctement ces événements d’erreur. Nous remercions @olleolleolle d’avoir porté ce problème à notre attention.

Déclaration de soutien

New Relic recommande de mettre à jour l’agent régulièrement et au minimum tous les 3 mois. À partir de cette sortie, la plus ancienne version prise en charge est 5.7.0.350.