instrumentationde sauvetage

En plus de votre application Web elle-même, l'agent Ruby New Relic peut également instrumenter vos tâches Resque.

Capturer les arguments de l'emploi

À partir de la version 3.6.9 de l'agent Ruby, vous pouvez éventuellement configurer l'agent Ruby pour capturer les arguments du travail Resque dans la trace de transaction et les erreurs de trace. Cela peut être particulièrement utile pour tenter de reproduire des tâches ayant échoué. Par défaut, cette fonctionnalité est désactivée au cas où vos arguments de travail contiennent des informations sensibles. Pour activer cette fonctionnalité, modifiez votre newrelic.yml en fonction de la version de votre agent :

• Pour newrelic_rpm 3.12.0 ou supérieur : attributes.include: job.resque.args.*
• Pour newrelic_rpm 3.6.9 à 3.11.X : resque.capture_params: true

Cette fonctionnalité est distincte du paramètre générique de niveau supérieur capture_params, qui contrôle si les paramètres de requête HTTP sont capturés lors du suivi des transactions et des erreurs de suivi pour requests Web. Vous pouvez configurer ces deux paramètres indépendamment.

Resque versions 1.23.1 ou supérieures

Si vous exécutez Resque 1.23.1 ou une version supérieure, vous ne devriez pas avoir besoin d'apporter de modifications de code en dehors des procédures d'installation normales de l'agent pour que l'instrumentation Resque de New Relic fonctionne.

Exception: S'il vous reste des appels aux méthodes NewRelic::Agent de vos hooks Resque before_first_fork, before_fork ou after_fork de l'époque où vous exécutiez une ancienne version de Resque, assurez-vous de remove ces appels après la mise à niveau vers Resque 1.23.1 ou supérieur.

Modes de forking alternatifs

Les gems resque-multi-job-forks ou resque-jobs-per-fork modifient le comportement de forking de Resque afin qu'il ne forke pas pour chaque tâche individuelle, mais plutôt une fois par lot de tâches. De même, vous pouvez définir la variable d’environnement FORK_PER_JOB sur false afin de désactiver complètement le fork dans Resque.

Si vous utilisez l’un de ces modes de forking alternatifs dans votre application, assurez-vous que vous exécutez l’agent Ruby version 3.9.7 or higher. Les versions antérieures de l'agent Ruby ne fonctionnent pas correctement avec ces modes de fork alternatifs. Si vous effectuez une mise à niveau vers la version 3.9.7 ou supérieure, assurez-vous de supprimer tous les appels directs aux méthodes NewRelic::Agent telles que manual_start ou after_fork que vous avez peut-être utilisées auparavant afin que l'agent fonctionne dans ces environnements.

Anciennes versions de Resque (< 1.23.1)

Il est possible d'utiliser l'agent Ruby de New Relic avec des versions de Resque antérieures à 1.23.1. Cependant, New Relic vous recommande de mettre à niveau vers Resque 1.23.1 ou une version supérieure pour de meilleurs résultats.

De nombreuses applications utilisent les hooks exposés par Resque (before_fork, after_fork, etc.) afin d'injecter du code personnalisé à des points critiques pendant la durée de vie des tâches Resque. L'agent Ruby New Relic doit également utiliser ces crochets afin de pouvoir placer son instrumentation.

Les versions de Resque antérieures à 1.23.1 ne permettent pas de définir les hooks plusieurs fois ; la dernière définition aura la priorité. Si vous ne pouvez pas effectuer de mise à niveau vers une version Resque >= 1.23.1 (qui permet de définir des hooks plusieurs fois sans s'écraser les uns les autres), vous pouvez modifier vos hooks Resque personnalisés en ajoutant le code New Relic nécessaire. Voici un exemple.

Example: Modifying custom Resque hooks

Vous pouvez omettre les définitions de tous les hooks pour lesquels vous n'avez pas de code personnalisé. Ils seront automatiquement installés par l'agent dans ce cas.

Resque.before_first_fork do
  # ... your custom hook code ...
  NewRelic::Agent.manual_start(:dispatcher => :resque,
                               :sync_startup => true,
                               :start_channel_listener => true)
end
    
Resque.before_fork do |job|
  # ... your custom hook code ...
  NewRelic::Agent.register_report_channel(job.object_id)
end
    
Resque.after_fork do |job|
  # ... your custom hook code ...
  NewRelic::Agent.after_fork(:report_to_channel => job.object_id,
                             :report_instance_busy => false)
end

Emplois bloqués

Certains clients (en particulier ceux avec un débit de travail très élevé) ont signalé des blocages intermittents dans leurs processus de travail Resque avec l'agent Ruby activé. Ces blocages sont dus à une mauvaise interaction entre le thread d'arrière-plan que l'agent Ruby utilise pour envoyer des données aux serveurs New Relic et le comportement de fork de Resque.

Utilisez l’une de ces options pour résoudre ces problèmes :

• Désactivez le comportement de duplication de Resque en définissant la variable d'environnement FORK_PER_JOB sur false lors du lancement des processus Resque.
• Utilisez la bibliothèque resolv-replace de la bibliothèque standard de Ruby pour remplacer le code de résolution DNS natif de Ruby par une version Ruby pure.

L'agent Ruby utilise un thread d'arrière-plan dans le processus maître Resque pour envoyer des données au collecteur New Relic. Dans certains environnements, ce thread acquerra un verrou natif lors de la résolution DNS (lors de la résolution du nom d'hôte du collecteur New Relic).

Si ce verrou natif est détenu par le thread d'arrière-plan tandis que le thread principal du processus maître Resque appelle fork pour créer un processus enfant, il sera toujours marqué comme détenu dans le processus enfant forké. Cependant, étant donné que fork copie uniquement le thread appelant, le thread d'arrière-plan qui détenait le verrou natif n'existera pas dans le processus enfant et, par conséquent, le verrou natif ne sera jamais supprimé. Si le processus enfant tente d'effectuer une résolution DNS, il tentera d'acquérir le même verrou natif et le même blocage. Pour éviter ce problème Github, utilisez resolv-replace au lieu du chemin de résolution DNS par défaut de Ruby.