Ruby agent release notesRSS

Fonctionnalité : profilage continu (aperçu)

Le profilage continu est une nouvelle fonctionnalité qui n’est pas encore disponible pour une utilisation générale. Le code du composant côté agent est désormais présent dans l’agent, mais pour l’utiliser réellement avant la sortie de la disponibilité générale, vous devrez contacter votre représentant commercial New Relic pour rejoindre l’aperçu de manière anticipée.

Le profilage continu échantillonne de manière répétée les call stack Ruby de votre application en cours d’exécution et les signale à New Relic, afin que vous puissiez voir quelles méthodes consomment le plus de temps CPU (ou allouent le plus d’objets) en production, sans ajouter de code à votre application.

Pour l’activer, ajoutez les gems stackprof et google-protobuf au Gemfile de votre application, puis définissez profiling.enabled sur true:

profiling.enabled: true

Avec seulement profiling.enabled défini, l’agent échantillonne le temps CPU toutes les 10 millisecondes pendant toute la durée de vie du processus. Ces options vous permettent d’ajuster ce comportement :

PR#3617

Fonctionnalité : Ajout de la prise en charge de Dalli 5.1.1

Dalli 5.1.1 a ajouté des arguments à certaines des méthodes que l’agent instrumente, ce qui pourrait déclencher une ArgumentError sur les opérations à clés multiples ou entraîner l’abandon silencieux des options de requête. Désormais, l’agent accepte et transmet un nombre variable d’arguments positionnels et de mots-clés pour ces méthodes. PR#3683

Fonctionnalité : signaler un nom d’hôte unique pour les Worker Pools et les Jobs Google Cloud Run

La prise en charge du nom d’hôte Cloud Run, ajoutée dans la PR n° 3609, détectait Cloud Run uniquement via K_REVISION, la variable d’environnement définie par les Services Cloud Run. L’agent reconnaît désormais également CLOUD_RUN_REVISION (Worker Pools) et CLOUD_RUN_EXECUTION (Jobs), de sorte que utilization.gcp_cloud_run.use_instance_as_host s’applique désormais aux trois types de ressources. Lorsque utilization.gcp_cloud_run.include_revision_in_host est true, le nom d’hôte est construit à partir de celle de ces variables qui est présente, par exemple, {CLOUD_RUN_EXECUTION}-{instance id} pour un Job. Problème n° 3651 PR n° 3652

Fonctionnalité : ajouter l’option de configuration browser_monitoring.version

Les clients peuvent désormais épingler la version exacte du chargeur de l’agent de navigateur que New Relic injecte en définissant la nouvelle option de configuration browser_monitoring.version. Consultez la politique de fin de vie de l’agent de navigateur pour connaître les versions actuellement disponibles et prises en charge. PR#3663

Fonctionnalité : ajouter span.kind aux bibliothèques de tâches en arrière-plan

Désormais, l’attribut span.kind sera ajouté aux opérations produce et consume des bibliothèques de tâches en arrière-plan. Cela inclut ActiveJob, Sidekiq, Resque, et DelayedJob. PR#3636

Correction de bug : l’instrumentation DelayedJob ne se réinstalle plus sur chaque worker en mode prepend

Lorsque l’instrumentation DelayedJob est installée via prepend (par défaut), la création de plus d’un Delayed::Worker dans le même processus amenait l’agent à écrire dans le log « Installing DelayedJob instrumentation » et à réinitialiser le plug-in pour chaque worker supplémentaire. Cela était inoffensif mais bruyant ; cela n’est désormais effectué qu’une seule fois par processus, ce qui correspond au comportement existant de l’instrumentation de chaîne. PR#3654

Correction de bug : les valeurs de configuration autorisées ne sont plus sensibles à la casse

Auparavant, les options de configuration sur liste d’autorisation nécessitaient une correspondance exacte de la casse, de sorte qu’une valeur avec une casse inattendue, comme OBFUSCATED ou ObFuScAtEd pour slow_sql.record_sql, revenait silencieusement à la valeur par défaut. Les options de configuration validées par une liste d’autorisation correspondent désormais aux valeurs indépendamment de la casse, de sorte que les deux sont traitées de la même manière que obfuscated. Problème n° 3613 PR n° 3645

Correction de bug : l’instrumentation Puma fonctionne lorsque Puma est chargé de manière différée

Avec gem "puma", require: false, Puma n’était pas encore chargé lors de l’exécution de la vérification de dépendance de l’agent, l’instrumentation de Puma ne parvenait donc pas à s’installer. L’agent reconnaît désormais Puma::RackHandler comme preuve de la présence de Puma, ce qui résout ce problème. Issue#3641 PR#3650

Correction de bug : résolution de ArgumentError sur les opérations à clés multiples avec Dalli 5.1.0

Ce correctif met à jour l’instrumentation de Dalli pour accepter et transférer les arguments d’options de requête facultatifs dans les opérations multi et pipeline. Nos remerciements vont à @dbackeus pour avoir apporté un correctif ! PR#3642

Correction de bug : les requests Async::HTTP ne lèvent plus NoMethodError lorsqu'un segment ne parvient pas à démarrer

Si l'agent rencontrait une erreur interne lors de la création du segment pour une requête Async::HTTP, l'instrumentation continuait à utiliser ce segment manquant et pouvait lever une NoMethodError. C'est désormais corrigé, merci à @ydah. PR#3640

Fonctionnalité : ajouter transaction_tracer.cap_segment_artifacts option de configuration

Les transactions de longue durée avec de nombreux segments peuvent entraîner une augmentation continue de l’utilisation de la mémoire pendant toute la durée de vie de la transaction. L’agent propose désormais une option de configuration transaction_tracer.cap_segment_artifacts facultative (la valeur par défaut est false). Lorsqu’elle est activée, une fois que transaction_tracer.limit_segments est atteint, l’agent arrête également d’enregistrer le temps exclusif pour tous les segments créés par la suite dans cette transaction, ce qui réduit l’utilisation de la mémoire au prix de données temporelles moins précises pour la transaction. PR#3615

Fonctionnalité : ajout de l'instrumentation des statistiques du serveur Puma

L’agent échantillonne désormais les statistiques du serveur à l’échelle du cluster de Puma et les signale sous forme de métriques de tranche de temps Ruby/Puma/*, notamment backlog, running, pool_capacity, max_threads et requests_count. Les statistiques sont échantillonnées en mode unique et en mode cluster lorsque preload_app! est activé. Cette instrumentation est désactivée par défaut. Activez-la en définissant disable_puma_instrumentation sur false. Lorsqu’elle est activée, l’agent démarre un thread de rapport dans le processus maître Puma pour fournir ces métriques, ce qui exécute une connexion d’agent supplémentaire aux côtés des workers Puma. L’intervalle d’échantillonnage est configurable via le nouveau paramètre puma.sample_rate (60 secondes par défaut). Nécessite Puma 6.6 ou une version ultérieure. Consultez notre documentation pour plus d’informations. PR#3578

Fonctionnalité : signaler un nom d’hôte unique pour les instances Google Cloud Run

L’agent détecte désormais Cloud Run et signale l’ID d’instance GCP en tant que nom d’hôte afin de pouvoir distinguer chaque instance. Avant cette modification, tous les noms d’hôte Google Cloud Run étaient localhost. Cette fonctionnalité est contrôlée par la nouvelle option de configuration utilization.gcp_cloud_run.use_instance_as_host (par défaut true). Définissez utilization.gcp_cloud_run.include_revision_in_host (par défaut false) sur true pour signaler le nom d’hôte en tant que {K_REVISION}-{instance id} à la place, où K_REVISION est le nom de révision Cloud Run. Problème n° 3295 PR n° 3609

Correction de bug : le SQL lent n'est plus enregistré après transaction_tracer.limit_segments dépassé

Une fois qu'une transaction a dépassé transaction_tracer.limit_segments, les segments de datastore créés par la suite pouvaient toujours voir leur SQL lent enregistré. L'agent arrête désormais d'enregistrer le SQL lent pour tout segment créé après que la limite est atteinte. PR#3615

Correction de bug : les plans d’exécution pouvaient cibler la mauvaise base de données dans les applications Rails multi-bases de données (Rails >= 7.2)

Sur Rails 7.2+, l’agent recueillait les plans d’exécution à l’aide d’une connexion provenant du pool par défaut/partagé de l’application plutôt que d’une connexion dédiée. Cela a principalement affecté les applications multi-bases de données. Les plans d’exécution pouvaient être générés sur la mauvaise base de données, et un échec d’exécution pouvait laisser une connexion partagée dans un mauvais état, affectant des requests non liées. L’agent utilise désormais sa propre connexion dédiée pour les plans d’exécution, comme il le faisait avant Rails 7.2, et réinitialise ou supprime cette connexion chaque fois qu’une tentative d’exécution échoue, de sorte qu’une mauvaise connexion n’est jamais réutilisée. Problème n° 3610 PR n° 3612

Correction de bug : l'instrumentation du monitoring de navigateurs n'échoue plus avec FrozenError

Lorsqu’un premier fragment du corps de la réponse était un String gelé et qu’il y avait plusieurs fragments, l’instrumentation du navigateur rencontrait un FrozenError et l’en-tête de synchronisation du navigateur n’était jamais injecté. Cela a commencé à apparaître avec ERB 6.0.3+, qui a commencé à geler davantage de ses chaînes compilées. Ce problème est maintenant résolu. Issue#3624 PR#3625

Correction de bug : normaliser les valeurs de configuration booléennes pour autoriser toutes les casses

Dans la version 9.x, l'agent acceptait les valeurs booléennes en majuscules, comme « FALSE », et les valeurs à casse mixte comme « True ». La version 10.0.0 incluait la PR#3341, qui a supprimé involontairement l'exigence d'insensibilité à la casse. Cela a conduit les utilisateurs qui avaient une casse autre que des minuscules à voir leurs options de configuration revenir aux valeurs par défaut. Désormais, l’agent utilise à nouveau des vérifications insensibles à la casse. Issue#3632 PR#3633