Ruby agent release notesRSS

Bugfix: Resolve ArgumentError on multi-key operations with Dalli 5.1.0

This fix updates Dalli instrumentation to accept and forward optional request options arguments in multi and pipelined operations. Our thanks go to @dbackeus for contributing a fix! PR#3642

Bugfix: Async::HTTP requests no longer raise NoMethodError when a segment fails to start

If the agent encountered an internal error while creating the segment for an Async::HTTP request, the instrumentation went on to use that missing segment and could raise a NoMethodError. This is now fixed, thanks to @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

Fonctionnalité : les événements SpanLink sont désormais pris en charge pour l'agent hybride

Les spans créés par une API OpenTelemetry peuvent désormais avoir des liens de span qui leur sont associés. Des liens peuvent être ajoutés au début d'un span, en les passant à l'argument links, ou en appelant l'API OpenTelemetry::Trace::Span#add_link. PR#3586

Fonctionnalité : les événements SpanEvent sont désormais pris en charge pour l'agent hybride

Les spans créés par une API OpenTelemetry peuvent désormais avoir des événements SpanEvent qui leur sont associés via l’API OpenTelemetry::Trace::Span#add_event. Les événements SpanEvent capturent des annotations avec horodatage sur un span et sont envoyés à New Relic avec le span parent. PR#3587

Fonctionnalité : définir le type de span sur tous les spans de l'agent hybride

Auparavant, seuls les spans OpenTelemetry traduits en segments de requêtes externes ou en segments de datastore ajoutaient le type de span en tant qu’attribut. Désormais, l’agent ajoute le type de span à tous les spans OpenTelemetry où la valeur est disponible. PR#3589

Fonctionnalité : ajouter la prise en charge d’OpenTelemetry::Tracer#start_root_span

L'API OpenTelemetry::Tracer#start_root_span peut désormais être utilisée pour forcer le démarrage d'une transaction pour un span donné, à condition qu'il ait un type de span :server ou :consumer. Pour tous les autres types de spans, elle n'effectuera aucune opération. Cette méthode est le plus souvent utilisée dans l'instrumentation des tâches en arrière-plan. PR#3588

Correction de bug : correction de instrumentation.rails_event_logger: false qui ne désactive pas l'instrumentation

Auparavant, définir instrumentation.rails_event_logger sur false ne désactivait pas l'instrumentation Rails.event comme prévu ; elle était toujours installée lors du démarrage de Rails. Ce problème est maintenant résolu. PR#3564

Correction de bug : normaliser les valeurs de type booléen à disabled pour les clés de configuration d'instrumentation

Auparavant, seul disabled désactivait une clé de configuration instrumentation.*. Désormais, les valeurs de type booléen telles que false, no ou off se résolvent également en disabled et empêchent l'installation de l'instrumentation. PR#3579

Correction de bug : les métriques de supportabilité de logging par bibliothèque reflètent désormais l’état d’instrumentation de chaque bibliothèque

Auparavant, les métriques Supportability/Logging/Ruby/{library}/{enabled|disabled} signalaient la valeur du paramètre global application_logging.enabled pour chaque bibliothèque, plutôt que l'état réel de chaque bibliothèque. Par conséquent, la métrique signalait enabled même lorsque vous aviez désactivé l'instrumentation de logging pour une bibliothèque spécifique ou que vous n'utilisiez pas du tout le gem de cette bibliothèque. Désormais, la métrique de chaque bibliothèque reflète si sa propre instrumentation de logging est activée. PR#3571

Fonctionnalité : ajouter la prise en charge de Dalli 5.0 et corriger l'instrumentation du méta-protocole

L’agent prend désormais en charge Dalli 5.0+, qui a supprimé Dalli::Protocol::Binary au profit exclusif du méta-protocole. Pour Dalli 3.2.0+, L'instrumentation pipelined_get cible désormais correctement Dalli::Protocol::Base (où la méthode est définie) plutôt que Dalli::Protocol::Binary, corrigeant une lacune où les appels get_multi n'étaient pas instrumentés lors de l'utilisation du méta-protocole. Pour Dalli 5.0+, l’agent instrumente également Dalli::Protocol::Meta#read_multi_req, qui est invoqué par l’optimisation get_multi à serveur unique de Dalli. PR#3541

Fonctionnalité : ajouter une option de configuration active_record_use_table_name

Une nouvelle option de configuration, active_record_use_table_name, utilise le nom de table d'un modèle Active Record au lieu de son nom de classe pour nommer les métriques, les spans et les segments de trace de transaction. Cela peut être particulièrement utile pour réduire la cardinalité dans les applications utilisant l’héritage à table unique. L'option est définie par défaut sur false pour préserver le comportement existant. PR#3540

Fonctionnalité : masquer partiellement les clés de licence dans les logs de l'agent

Auparavant, l'agent masquait complètement les clés de licence New Relic dans les logs de l'agent. Maintenant, les 10 premiers caractères sont visibles tandis que le reste est remplacé par *. Cela préserve suffisamment d’informations pour résoudre les problèmes liés à la région sans exposer la partie secrète de la clé. PR#3547

Correctif : résolution de l'incompatibilité de l'instrumentation de l'enregistreur sémantique avec rails_semantic_logger

Auparavant, un ArgumentError était levé lorsqu'une exception atteignait ActionDispatch::DebugExceptions lors de l'utilisation de rails_semantic_logger. Ce problème est résolu. Merci à @jdelStrother de l’avoir signalé ! PR#3548

Fonctionnalité : ajout de l'instrumentation de Rails.event pour le logging structuré

L'agent prend désormais en charge Rails.event en tant qu'événements de log structurés. Lorsqu'ils sont activés, les événements publiés via Rails.event.notify sont capturés et transférés vers New Relic en tant qu'événements de log. Les charges d'événement, les tags, le contexte, les horodatages et les emplacements source sont automatiquement capturés en tant qu'attributs de log.

Cette instrumentation peut être configurée avec les options suivantes :

• instrumentation.rails_event_logger - Contrôle si l'instrumentation de Rails.event est activée. Utilise par défaut la valeur de application_logging.enabled.
• instrumentation.rails_event_logger.event_names - Un éventail de noms d'événements spécifiques à capturer. Si vide (par défaut), toutes les notifications Rails.event sont capturées. Utilisez ceci pour filtrer les événements par nom, par exemple : ['user.signup', 'payment.processed'].

PR#3526

Fonctionnalité : ajout de l'instrumentation pour les continuations Rails Active Job

L'agent instrumente désormais les continuations Rails Active Job, offrant une visibilité sur l'exécution des étapes individuelles au sein des tâches de longue durée. Les noms d’étapes sont inclus dans les métriques de segment (par exemple, Ruby/ActiveJob/default/MyJob/step/process_records) et des attributs spécifiques à l’étape tels que la position du curseur, le statut repris et le statut interrompu sont capturés. Une nouvelle option de configuration, disable_active_job_step_names, permet aux utilisateurs d'exclure les noms d'étapes des noms de métriques pour réduire la cardinalité des métriques si nécessaire (la valeur par défaut est false). PR#3493

Fonctionnalité : ajout de sidekiq.separate_transactions option de configuration

Une nouvelle option de configuration, sidekiq.separate_transactions, permet aux tâches Sidekiq exécutées pendant une transaction web de s'exécuter dans leur propre transaction séparée. Lorsqu'il est activé, cela empêche le temps d'exécution des jobs Sidekiq d'être inclus dans les métriques de transaction web, fournissant des données de performance plus précises. La fonctionnalité est optionnelle (par défaut : false) pour maintenir la rétrocompatibilité. Cela n'affecte que les tâches exécutées pendant des transactions web actives ; les tâches démarrant indépendamment ou imbriquées dans d'autres tâches d'arrière-plan ne sont pas affectées. Problème n° 3364 PR#3514

Correction de bug : mise à jour des regex qui auraient pu être vulnérables aux attaques ReDOS

Auparavant, l'agent avait quelques regex identifiées comme cibles possibles pour des attaques de complexité temporelle polynomiale (ReDOS). Ces regex sont maintenant mises à jour pour répondre aux préoccupations. PR#3520

Correction de bug : empêcher les plantages lors de la création de segments HTTPX

Auparavant, si start_external_request_segment rencontrait une erreur et renvoyait nil, l'agent déclenchait un NoMethodError en tentant d'ajouter des en-têtes au segment manquant. Nous avons ajouté un contrôle de sécurité pour garantir que l'instrumentation gère ces cas avec élégance.

Bravo à @thebravoman pour le rapport ! Issue#3509 PR#3510

Correctif : rendre Transaction#finish idempotent

Auparavant, si la méthode Transaction#finish était appelée plusieurs fois, plus d’une transaction pouvait être créée pour la même opération. Désormais, un mutex protège les appels à Transaction#finish pour s’assurer que les opérations de finalisation ne s’exécutent qu’une seule fois. PR#3513

Correction de bug : Avertissement unique de dépréciation de Log pour l'API Datastores.wrap

Auparavant, cet avertissement était logué lors de chaque appel à Datastores.wrap. Désormais, il fera l'objet d'un log uniquement lors du premier appel. De plus, la documentation a été mise à jour pour indiquer le statut obsolète des deuxième et troisième arguments de rappel. Issue#3516 PR#3519