v9.13.0

La version 9.13.0 améliore la prise en charge des fonctions AWS Lambda, ajoute l’instrumentation expérimentale d’OpenSearch, met à jour la détection du framework, masque un avertissement d’obsolescence de Bundler, corrige la détection du répartiteur Falcon, corrige un bug lors de l’installation de l’instrumentation de Redis, et résout un problème de simultanéité spécifique à JRuby.

• Fonctionnalité : améliorer l’instrumentation de la fonction AWS Lambda

Lorsqu’il est utilisé via la dernière couche Ruby New Relic pour AWS Lambda, l’agent offre désormais une prise en charge améliorée de l’instrumentation de la fonction Lambda AWS.

• L’instrumentation de l’agent pour les fonctions AWS Lambda prend désormais en charge le tracing distribué.

• Les invocations déclenchées par le web sont désormais identifiées comme étant basées sur le "web" lorsqu’un appel API Gateway est impliqué, avec la prise en charge des versions 1.0 et 2.0 d’API Gateway.

• La méthode HTTP, l’URI, et le code d’état des appels web sont enregistrés.

• L’agent reconnaît et crée désormais des rapports sur 12 ressources AWS distinctes capables de déclencher l’invocation d’une fonction Lambda : ALB, API Gateway V1, API Gateway V2, CloudFront, CloudWatch Scheduler, DynamoStreams, Firehose, Kinesis, S3, SES, SNS, et SQS.

• Le type de la ressource de déclenchement et son ARN seront enregistrés pour chaque ressource, et pour nombre d’entre elles, des attributs supplémentaires spécifiques à la ressource seront également enregistrés. Par exemple, les invocations de fonction Lambda déclenchées par l’activité d’un bucket S3 entraîneront désormais l’enregistrement du nom du bucket S3. PR#2811

• Fonctionnalité : Ajout de l’instrumentation expérimentale OpenSearch

  L'agent va désormais automatiquement instrumenter le gem opensearch-ruby. Nous marquons cette instrumentation comme expérimentale, car davantage de travail est nécessaire pour la tester entièrement. L'instrumentation d'OpenSearch fournit une télémétrie similaire à Elasticsearch. Merci, @Earlopain d'avoir signalé le problème, et @praveen-ks pour un brouillon initial de l'instrumentation. Problème n° 2228 PR n° 2796

• Fonctionnalité : améliorer la précision de la détection du framework pour Grape et Padrino

  Auparavant, les applications utilisant le framework Grape définissaient ruby comme leur framework dans le Rapport d’environnement. Désormais, les applications Grape seront définies sur grape. De même, les applications utilisant le framework Padrino étaient définies sur sinatra. Désormais, elles seront définies sur padrino. Cela facilitera les vérifications de compatibilité d’agent de sécurité New Relic. Merci à @prateeksen d’avoir apporté cette modification. Issue#2777 PR#2789

• Fonctionnalité : masquer l’avertissement d’obsolescence de Bundler all_specs

  Bundler.rubygems.all_specs a été dépréciée au profit de Bundler.rubygems.installed_specs dans les versions 2+ de Bundler, ce qui a conduit l'agent à émettre des avertissements de dépréciation. La méthode a été mise à jour lorsque Bundler 2+ est détecté, et les avertissements sont désormais masqués. Merci à @jcoyne d'avoir signalé ce problème. Problème n° 2733 PR n° 2823

• Correction de bug : correction de la détection du répartiteur Falcon

  Auparavant, nous avons essayé d’utiliser l’espace d’objets pour déterminer si le serveur web Falcon était utilisé. Cependant, Falcon n’est ajouté à l’espace d’objets qu’après la génération du rapport d’environnement, ce qui donne un répartiteur nil. À présent, nous revenons à une stratégie antérieure qui découvrait le répartiteur en utilisant File.basename. Nous vous remercions, @prateeksen, d’avoir signalé ce problème, et d’avoir effectué des recherches sur le sujet. Problème n° 2778 PR n° 2795

• Correction de bug : résolution d’une erreur d’instrumentation Redis lorsque Redis::Cluster::Client est présent

  L’instrumentation de Redis contenait auparavant un bug qui générait une erreur lorsque Redis::Cluster::Client était présent, en raison de l’utilisation d’un return Ruby en dehors d’une méthode. Nous vous remercions vivement, @jdelStrother, non seulement pour avoir signalé ce bug, mais aussi pour nous en avoir indiqué la cause profonde. Problème n° 2814 PR n° 2816

• Correction de bug : résolution du problème de simultanéité de JRuby lors de l'accès au hacher de configuration

  La classe de configuration interne de l’agent maintient un hacher qui est occasionnellement reconstruit. Lors de la reconstruction, certaines valeurs d’instrumentation déterminées dynamiquement au préalable sont préservées au profit de l’ agent de sécurité New Relic Ruby. Après des rapports de clients JRuby concernant des problèmes de simultanéité liés à l’accès au hacher pendant sa modification, deux correctifs distincts ont été intégrés précédemment dans la logique de reconstruction du hacher : une opération Hash#dup et un bloc synchronize do. Mais des erreurs ont encore été signalées. Nous restons nous-mêmes incapables de reproduire ces erreurs de simultanéité malgré l’utilisation des mêmes versions exactes de JRuby et de tous les logiciels signalés. Après avoir confirmé que le code d’accès au hacher en question n’est nécessaire que pour l’agent de sécurité Ruby (qui fonctionne uniquement dans des environnements de test de sécurité dédiés de non-production), nous avons introduit un nouveau correctif pour les clients JRuby qui ignorera tout simplement le code problématique lorsque JRuby est en jeu, mais pas l’agent de sécurité. PR#2798