Skip to main content
Shoryuken est un processeur de messages basé sur les threads pour AWS SQS. AppSignal instrumente automatiquement Shoryuken lorsque la gem Shoryuken est détectée au démarrage. Aucune installation manuelle n’est requise si Shoryuken fait partie d’une application Rails. Si vous utilisez une application Shoryuken autonome, consultez notre guide d’intégration.

​
Surveillance des performances

​
Chronologie des événements

Les jobs Shoryuken apparaissent dans la chronologie des événements des actions de performance de votre application sous forme d’événements perform_job.shoryuken.

​
Regroupement d’incidents

AppSignal détecte les noms de jobs à partir du nom de classe du worker Shoryuken, suffixé par le nom de la méthode perform, ce qui donne quelque chose comme : MyWorker#perform. AppSignal regroupe les jobs par ce nom pour la surveillance des performances et les notifications.

​
Instrumentation de mise en file d’attente

La mise en file d’attente d’un job Shoryuken enregistre un événement enqueue.shoryuken, intitulé d’après le job mis en file d’attente. 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.

​
Prise en charge des lots

Si une application utilise un worker avec l’option :batch => true, ce worker traite plusieurs messages dans le même tick. Cela nécessite la version 2.11.3 ou supérieure de la gem Ruby, qui ajoute la prise en charge de l’option batch.

​
Exemple d’application

Nous avons un exemple d’application pour une application Shoryuken autonome disponible dans notre dépôt d’exemples sur GitHub.

​
Attributs des spans

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, et apparaît sous la requête ou le job qui l’a planifié. Vous pouvez ainsi remonter d’un job lent jusqu’à ce qui l’a déclenché. La trace est transportée dans les attributs de message SQS du message. SQS en autorise au maximum dix par message, donc un message qui utilise déjà les dix est envoyé sans trace. Les messages reçus par lots ne poursuivent pas une trace. Un lot est traité comme une seule unité, il n’y a donc pas de trace unique à laquelle il pourrait appartenir. En savoir plus sur le tracing distribué.