Skip to main content
Active Job est un framework pour déclarer des jobs et les faire s’exécuter sur une variété de backends de queue livrés avec Rails. L’intégration Active Job suit l’exécution et les événements du job en cours d’exécution. Lorsqu’AppSignal détecte des métriques Active Job, il crée un Intelligence dashboard vous permettant de surveiller visuellement les métriques principales.

​
Adaptateurs pris en charge

L’intégration Active Job prend en charge tous les adaptateurs Active Job. Elle peut également offrir une prise en charge pour des adaptateurs non répertoriés sur cette page, accessibles via une gem séparée. Cependant, ces adaptateurs n’ont pas été testés. Les adaptateurs sans intégration AppSignal dédiée sont surveillés via l’instrumentation Active Job, comme GoodJob.

​
Intégration avec les bibliothèques prises en charge par AppSignal

Les bibliothèques de background jobs suivantes prises en charge par AppSignal sont automatiquement intégrées à Active Job, permettant à AppSignal de vous fournir des informations de performance plus approfondies :

​
Signaler les erreurs lors de l’abandon d’un job

Définissez l’option de configuration activejob_report_errors sur discard pour ne signaler les erreurs que lorsqu’un job est abandonné. Lorsqu’un job est abandonné, toutes les nouvelles tentatives ont été épuisées et le job n’est plus réessayé. Consultez la documentation Active Job pour en savoir plus sur la gestion des exceptions Active Job et les nouvelles tentatives des jobs échoués.
Certains adaptateurs Active Job (tels que Sidekiq, Delayed::Job, etc.) ont leur propre système de nouvelles tentatives. Une fois qu’Active Job a épuisé ses nouvelles tentatives, ces bibliothèques peuvent déclencher leur propre système de nouvelles tentatives des jobs.Cela réessaie les jobs même après qu’Active Job ait épuisé ses nouvelles tentatives et abandonné le job. Pour éviter de réessayer les jobs après qu’Active Job ait cessé de les réessayer, et qu’il signale des erreurs pour ces nouvelles tentatives, assurez-vous que le système de nouvelles tentatives de l’adaptateur est désactivé.Lorsque vous vous appuyez sur le système de nouvelles tentatives de Sidekiq, configurez-le également pour ne signaler les erreurs qu’en cas d’abandon, afin qu’il ne signale pas les erreurs plusieurs fois.

​
Instrumentation de mise en file d’attente

Mettre un job en file d’attente via Active Job enregistre un événement enqueue.active_job, intitulé d’après le job mis en file d’attente. Lorsqu’un job est mis en file d’attente via un adaptateur qu’AppSignal instrumente également, comme Sidekiq ou Resque, AppSignal supprime l’événement de mise en file d’attente propre à l’adaptateur et enregistre la mise en file d’attente une seule fois sous forme d’événement Active Job. AppSignal enregistre les événements de mise en file d’attente dans la chronologie des événements de la transaction active, par exemple lorsque vous mettez en file d’attente un job depuis une requête web ou depuis un autre job. Il ne les enregistre que lorsqu’une transaction est active, donc mettre en file d’attente un job en dehors d’une transaction n’enregistre rien. Pour arrêter d’enregistrer les événements de mise en file d’attente pour toutes les intégrations de jobs en arrière-plan, définissez l’option de configuration enable_job_enqueue_instrumentation sur false. Cela n’affecte pas l’instrumentation des jobs eux-mêmes.

​
Métadonnées

AppSignal collecte les métadonnées suivantes pour les jobs Active Job : *À partir de la version 6 de Rails, les queue times sont signalés pour le namespace depuis lequel ils sont signalés et peuvent être consultés dans les Performance Graphs d’AppSignal. AppSignal utilise les métadonnées Active Job pour vous donner des informations contextuelles plus approfondies sur les performances des jobs. Lors de l’inspection des traces Active Job dans AppSignal :
  • Le nom du job sera utilisé pour regrouper le job pour les incidents AppSignal :
Exemple d'aperçu des problèmes de performance
  • Les métadonnées (à l’exclusion du nom du job et des événements) seront disponibles sous forme de tags filtrables sur les traces d’incidents :
Exemple de tags Active Job
  • Les événements *.active_job seront affichés dans la chronologie des événements pour les traces de performance :
Exemple de chronologie d'événements

​
Intelligence dashboard

Lorsqu’AppSignal reçoit des métriques Active Job, il crée un Intelligence dashboard Active Job, disponible depuis la section dashboard de l’application AppSignal. Le Intelligence dashboard Active Job contiendra les graphiques suivants : Les tags vous offrent une décomposition contextuelle des informations de performance Active Job. AppSignal signale actuellement les tags suivants pour les jobs Active Job : Chaque tag sera représenté par une ligne colorée sur le graphique : Exemple de dashboard Active Job

​
Graphique Duration per job class

Le graphique Duration per job class montre le temps qu’il a fallu aux jobs pour s’exécuter, regroupés par la classe qui définit le job. Vous pouvez utiliser ce graphique pour surveiller les performances des jobs, par classe, en vous offrant une vue d’ensemble des performances des jobs et en vous permettant d’identifier et d’enquêter rapidement sur les pics de durée.

​
Graphique Job status per queue

Le graphique Job status per queue montre le nombre de jobs qui ont été exécutés, regroupés par leur statut résultant et par la queue dans laquelle ils ont été mis en file d’attente. Vous pouvez utiliser ce graphique pour surveiller le nombre d’erreurs des jobs et leurs performances en fonction de la queue, identifier les goulots d’étranglement et optimiser vos background jobs pour la mise à l’échelle.

​
Graphique Job status per queue with priority

Tous les adaptateurs Active Job ne prennent pas en charge la priorité des jobs. Si les jobs n’ont pas de valeurs de priorité, le graphique sera vide.
Le graphique Job status per queue with priority montre le nombre de jobs qui ont été exécutés, regroupés par leur statut résultant, par la queue dans laquelle ils ont été mis en file d’attente et par la priorité qui leur a été donnée. Vous pouvez utiliser ce graphique pour surveiller le nombre d’erreurs des jobs et leurs performances en fonction de la queue et de la priorité, identifier les goulots d’étranglement et optimiser vos background jobs pour la mise à l’échelle.

​
Graphique Throughput per job class

Le graphique Throughput per job class montre le nombre de jobs qui ont été exécutés, regroupés par la classe qui définit le job. Vous pouvez utiliser ce graphique pour surveiller combien de jobs sont exécutés, regroupés par la classe qui définit le job.

​
Attributs du span

Mode collector uniquement : ceci s’applique lorsqu’AppSignal pour Ruby s’exécute en mode collector. Cela n’a aucun effet dans les autres cas.
L’enqueue et le span propre au job portent tous deux :
  • messaging.system — la bibliothèque de mise en file d’attente.
  • messaging.destination.name — la queue sur laquelle le job a été placé.
  • messaging.operation.type — indique si le span correspond à la mise en file d’attente ou à l’exécution du job.
Un span pour un job qui a levé une erreur porte également error.type, la classe de l’erreur.

​
Tracing distribué

Mode collector uniquement : ceci s’applique lorsqu’AppSignal pour Ruby s’exécute en mode collector. Cela n’a aucun effet dans les autres cas.
Un job s’exécute dans la même trace que le code qui l’a mis en file d’attente, apparaissant sous la requête ou le job qui l’a programmé. Vous pouvez ainsi retracer un job lent jusqu’à sa cause. La trace est transportée dans les arguments sérialisés du job. Active Job s’exécute sur un adaptateur de queue. Lorsque cet adaptateur est un adaptateur qu’AppSignal instrumente également, comme Sidekiq ou Resque, son propre comportement s’applique aussi. En savoir plus sur le tracing distribué.