v10.4.0

• 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