Guide de migration de l'agent Ruby 7.x vers 8.x

Résumé

Ce guide couvre les principaux changements entre les séries 7.x et 8.x de l'agent Ruby, les problèmes qui peuvent être rencontrés lors de la mise à niveau et comment migrer avec succès vers la version 8.x.

Les principaux changements incluent :

• Modifications apportées à la méthode API add_method_tracer
• Le tracing distribué est activé par défaut
• Le traçage inter-applications est obsolète
• Suppression des méthodes d'API obsolètes et legacy instrumentation

Consultez le jalon de la version 8.0 pour plus d'informations.

Modifications apportées à la add_method_tracer

Le paramètre de nom de métrique accepte les procédures ; les chaînes ne sont plus interpolées

Le deuxième argument de add_method_tracer est le nom de la métrique utilisée pour enregistrer les appels à la méthode trace.

Auparavant, cette chaîne pouvait inclure une interpolation de style Ruby pour permettre au nom métrique d'inclure des variables de la méthode Récepteur. Par exemple:

# old (<= 7.2)
add_method_tracer :foo, 'metric_#{args[0]}'

À partir de la version 8.0, cette chaîne ne sera plus interpolée. Pour conserver le comportement décrit ci-dessus, passez plutôt une procédure :

# new (8.0+)
add_method_tracer :foo, -> (*args) { "metric_#{args[0]}" } # note the double-quotes

Notez que l'arité de la procédure passée à add_method_tracer doit correspondre à l'arité de la méthode de trace d'origine (ou utiliser un splat compatible).

:code_header et les paramètres :code_footer n'acceptent que les procédures

Similaires aux noms métriques, les options :code_header et :code_footer à add_method_tracer étaient auparavant données sous forme de chaînes qui seraient interpolées dans le contexte de la méthode Récepteur.

Dans l'agent Ruby 8.0, :code_header et :code_footer ne seront invoqués que s'ils sont donnés en tant que procédures, comme dans l'exemple ci-dessus.

Appeler add_method_tracer une fois par méthode

L'appel de add_method_tracer plusieurs fois sur la même méthode écrasera tout traceur de méthode précédemment défini pour cette méthode. Il ne doit y avoir qu'une seule ligne add_method_tracer pour chaque méthode de trace.

Auparavant, l'agent permettait d'ajouter plusieurs métriques à la même méthode en appelant add_method_tracer une fois pour chacune de ces métriques. Cela peut toujours être fait, mais les noms métriques doivent être passés comme deuxième argument de add_method_tracer sous la forme d'un éventail de chaînes ou de procédures.

# old
add_method_tracer :foo, 'metric1'
add_method_tracer :foo, 'metric2', push_scope: false
add_method_tracer :foo, 'metric3', push_scope: false

# new
add_method_tracer :foo, ['metric1', 'metric2', 'metric3']

Notez que le premier nom de métrique sera créé en tant que métrique à portée limitée, sauf si push_scope: false est spécifié. Les métriques nommées suivantes ne seront pas couvertes. Chaque méthode de trace ne peut avoir qu'une seule métrique délimitée.

NoMethodError: super: no superclass method 'instance_method' for <ExampleClass>

Le tracing distribué est activé par défaut

L'option de configuration par défaut pour distributed_tracing.enabled est définie sur vrai pour les versions 8.0 ou supérieures. Pour désactiver le tracing distribué, définissez cette option configuration sur false dans votre newrelic.yml.

distributed_tracing:
  enabled: false

Le traçage inter-applications est obsolète

Le traçage inter-applications est obsolète dans la version 8.0 et sera supprimé dans une future sortie.

cross_application_tracing:
  enabled: true

distributed_tracing:
  enabled: false

Suppression des méthodes d'API obsolètes et legacy instrumentation

Les méthodes suivantes étaient auparavant obsolètes et sont désormais supprimées.