Sidekiq

Sidekiq est un background processor simple et efficace pour Ruby. C’est également le processeur que nous utilisons pour traiter les jobs dans AppSignal. Lorsqu’AppSignal détecte des métriques Sidekiq, il crée un Intelligence dashboard vous permettant de surveiller visuellement les métriques principales.

Surveillance de Sidekiq pour les applications Ruby on Rails

La gem AppSignal Ruby insère automatiquement un listener dans la pile de middlewares du serveur Sidekiq si le module Sidekiq est présent et si vous utilisez Rails. Aucune autre action n’est requise. L’intégration Sidekiq est compatible avec Active Job.

Surveillance de Sidekiq pour les applications Ruby

L’ajout de cette configuration ne devrait être nécessaire que lorsque Sidekiq ne charge pas automatiquement AppSignal via le framework de l’application, comme Rails. Ajoutez ce snippet à votre configuration Sidekiq avec le bon environnement et le bon nom :

require 'appsignal'

Sidekiq.configure_server do |config|
  config.on(:startup) do
    # Start AppSignal
    Appsignal.start
  end

  config.on(:shutdown) do
    # Stop the agent
    Appsignal.stop('Sidekiq shutdown')
  end
end

Surveillance des performances

Une fois qu’AppSignal commence à signaler les métriques Sidekiq, il vous fournit des informations sur les performances via :

Chronologie de la trace
Suivi des erreurs
Regroupement d’incidents
Répartition de la trace

Chronologie de la trace

Les spans perform_job.sidekiq apparaissent dans la chronologie de la trace sur la page de trace :

Suivi des erreurs

Suivez les exceptions qui se produisent lors de l’exécution des jobs Sidekiq. Lorsque Sidekiq rencontre un problème avant ou après le traitement d’un job, comme l’analyse de JSON depuis Redis, il lève une erreur. Cette erreur est signalée sous l’action SidekiqInternal dans le namespace background, car le contexte du job est inconnu au moment où l’erreur se produit.

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

Définissez l’option de configuration sidekiq_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 Sidekiq pour en savoir plus sur la gestion des exceptions Sidekiq et les nouvelles tentatives des jobs échoués.

Lorsque vous utilisez Sidekiq avec le système de nouvelles tentatives d’Active Job, configurez-le pour ne signaler les erreurs qu’à l’abandon, afin qu’il ne signale pas les erreurs plusieurs fois.Une fois les nouvelles tentatives d’Active Job épuisées, le système de nouvelles tentatives de Sidekiq prend le relais. Désactivez le système de nouvelles tentatives Sidekiq si ce comportement n’est pas souhaité.

Regroupement d’incidents

AppSignal détecte les noms de jobs à partir du nom de classe du worker Sidekiq, suffixé par le nom de la méthode perform, ce qui donne quelque chose comme : MyWorker#perform.

Jobs Sidekiq regroupés par nom de classe de worker sur la page Performance

Répartition de la trace

La répartition de la trace sur une page de trace montre comment le temps d’un job s’est réparti entre les groupes d’événements, comme sidekiq et active_record, pour repérer les problèmes de performances sans parcourir toute la chronologie.

Instrumentation de mise en file d’attente

La mise en file d’attente d’un job Sidekiq enregistre un événement enqueue.sidekiq, 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.

Intelligence dashboard

Lorsqu’AppSignal reçoit des métriques Sidekiq, il crée un Intelligence dashboard Sidekiq, disponible dans la section dashboard de l’application AppSignal. Le Intelligence dashboard Sidekiq contiendra les graphiques suivants :

Graphique	Métriques	Tags
Connection count	`sidekiq_connection_count`	`hostname`
Duration per worker	`trace_duration`	`action` `namespace`
Job status per queue	`sidekiq_queue_job_count`	`status` `queue`
Overall job status	`sidekiq_job_count`	`status` `hostname`
Queue latency	`sidekiq_queue_latency`	`hostname` `queue`
Queue length	`sidekiq_queue_length`	`hostname` `queue`
Redis memory usage	`sidekiq_memory_usage` `sidekiq_memory_usage_rss`	`hostname`
Throughput per worker	`trace_duration`	`action` `namespace`
Worker/processes count	`sidekiq_worker_count` `sidekiq_process_count`	`hostname`

Les graphiques Duration per worker et Throughput per worker utilisent trace_duration pour les comptes qui sont passés aux métriques de trace. Pour les comptes qui n’y sont pas encore passés, ces graphiques utilisent plutôt transaction_duration.

Les tags vous offrent une décomposition contextuelle des informations de performance de Sidekiq. AppSignal signale les tags suivants pour les jobs Sidekiq :

Nom	Description
`action`	Le nom de l’action depuis laquelle la métrique a été signalée (par exemple, `YourWorker#perform`).
`hostname`	Le hostname du serveur Redis utilisé par Sidekiq, ou la valeur de `hostname` définie dans la configuration de la sonde.
`namespace`	Le nom du namespace depuis lequel la métrique a été signalée.
`queue`	Queue nommée dans laquelle les jobs sont traités, par exemple `default` ou `mailer`.
`status`	Statut de chaque job. Pour Job status per queue : `processed` ou `failed`. Pour Overall job status : `processed`, `failed`, `retry_queue`, `died`, `scheduled` ou `enqueued`. Les jobs `failed` sont également comptés comme `processed`.

Chaque tag sera représenté par une ligne colorée sur le graphique :

Graphique Connection count

Le graphique Connection count montre le nombre de clients connectés au serveur Redis utilisé par Sidekiq, par hôte Redis. Vous pouvez utiliser le graphique Connection count pour repérer les tendances et goulots d’étranglement de connexion, et optimiser les ressources.

Graphique Duration per worker

Le graphique Duration per worker montre le temps qu’il a fallu aux jobs pour s’exécuter, regroupés par namespace et action. Vous pouvez utiliser le graphique Duration per worker pour surveiller les performances des workers par action et namespace, en vous offrant une vue d’ensemble des performances de Sidekiq 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 le graphique Job status per queue pour surveiller les nombres d’erreurs et les performances des jobs en fonction de la queue, identifier les goulots d’étranglement et optimiser vos background jobs pour la mise à l’échelle.

Graphique Overall job status

Le graphique Overall job status montre le nombre de jobs Sidekiq par statut et hôte Redis. Vous pouvez utiliser le graphique Overall job status pour surveiller les jobs échoués, morts, en nouvelle tentative, planifiés et mis en file d’attente.

Graphique Queue latency

Le graphique Queue latency montre la latence subie par la queue au moment de la mesure. Sidekiq calcule cela comme le temps écoulé depuis la mise en file d’attente du job le plus ancien dans la queue. Cette valeur est signalée en millisecondes. Vous pouvez utiliser le graphique Queue latency pour repérer les retards dans le traitement des jobs, détecter la congestion des queues et comprendre la rapidité avec laquelle les background jobs démarrent.

Graphique Queue length

Le graphique Queue length montre la longueur des queues Sidekiq par queue et hôte Redis. Vous pouvez utiliser le graphique Queue length pour surveiller les performances des queues et repérer et résoudre les goulots d’étranglement Sidekiq.

Graphique Redis memory usage

Le graphique Redis memory usage affiche :

La mémoire totale allouée par Redis (sidekiq_memory_usage)
Le resident set size, la mémoire physique utilisée par Redis telle que vue par le système d’exploitation (sidekiq_memory_usage_rss)

Vous pouvez utiliser le graphique Redis memory usage pour surveiller l’utilisation de la mémoire de Sidekiq, améliorer la gestion des ressources et optimiser les jobs intensifs en mémoire.

Graphique Throughput per worker

Le graphique Throughput per worker montre le nombre de jobs qui ont été exécutés, regroupés par namespace et action. Vous pouvez utiliser ce graphique pour voir combien de jobs chaque classe de worker traite et repérer les workers dont le volume change de manière inattendue.

Graphique Worker/processes count

Le graphique Worker/processes count montre le nombre de workers Sidekiq et de processus exécutés. Vous pouvez utiliser le graphique Worker/processes count pour gérer la distribution de la charge de travail, optimiser l’allocation des ressources et identifier les problèmes de performances.

Configuration du hostname

AppSignal tente de détecter le hostname de l’instance Redis utilisée par votre instance Sidekiq pour stocker ses queues. Si la détection n’est pas précise, il est possible de personnaliser la configuration du hostname en remplaçant la sonde Sidekiq par défaut. Tout d’abord, vous devrez remplacer la sonde Sidekiq par défaut en enregistrant une nouvelle sonde avec le même nom (:sidekiq). Cette sonde aura besoin d’un hash de configuration, comprenant la clé :hostname, avec la nouvelle valeur du hostname. En spécifiant l’option de configuration :hostname dans la sonde minute par minute Sidekiq, les métriques seront marquées avec la valeur de hostname donnée. La valeur de l’option de configuration :hostname n’est pas utilisée pour établir une connexion Redis ou Sidekiq. Par exemple :

# config/initializers/appsignal.rb or a file that's loaded on boot

# Ruby gem 2.11.0 and newer
Appsignal::Minutely.probes.register(
  :sidekiq, # Use the same key as the default Sidekiq probe to override it
  Appsignal::Probes::SidekiqProbe.new(:hostname => "my_sidekiq_hostname")
)

# Ruby gem 2.10.x and older
Appsignal::Minutely.probes.register(
  :sidekiq, # Use the same key as the default Sidekiq probe to override it
  Appsignal::Hooks::SidekiqProbe.new(:hostname => "my_sidekiq_hostname")
)

Dans la version 2.11.0 de la gem Ruby, la constante SidekiqProbe a été déplacée vers son propre module. Lors de l’appel à la constante, un avertissement est imprimé et journalisé. Mettez à jour vers le nouveau nom de constante Appsignal::Probes::SidekiqProbe pour supprimer l’avertissement.

Attributs de 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. Il apparaît sous la requête ou le job qui l’a planifié, ce qui permet de remonter d’un job lent jusqu’à ce qui l’a déclenché. La trace est transportée sur le job lui-même, avec ses autres données. En savoir plus sur le tracing distribué.

Voir aussi

Batches Sidekiq : exécuter des jobs en parallèle, puis agir : répartit une unité de travail entre plusieurs jobs, puis exécute un callback une fois que chaque job a réussi. Explique pourquoi le callback a besoin de sa propre classe, et comment enchaîner un batch au suivant.

SDK & télémétrie

SDK de langage

Outils de télémétrie

Surveillance de Sidekiq pour les applications Ruby on Rails

Surveillance de Sidekiq pour les applications Ruby