• /
  • EnglishEspañolFrançais日本語한국어Português
  • Se connecterDémarrer

Cette traduction automatique est fournie pour votre commodité.

En cas d'incohérence entre la version anglaise et la version traduite, la version anglaise prévaudra. Veuillez visiter cette page pour plus d'informations.

Créer un problème

Important

Nous vous recommandons de mettre à jour vers la dernière version de l'agent dès qu'elle est disponible. Si vous ne pouvez pas effectuer la mise à niveau vers la dernière version, mettez à jour vos agents vers une version datant de moins de 90 jours. En savoir plus sur la façon de tenir les agents informés.

Consultez la politique EOL de l'agent New Relic Ruby pour obtenir des informations sur la sortie de l'agent et les dates de support.

v10.7.0

  • 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

Droits d'auteur © 2026 New Relic Inc.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.