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 des événements
Suivi des erreurs
Regroupement d’incidents
Décomposition des échantillons

Chronologie des événements

Les événements perform_job.sidekiq seront affichés dans la chronologie des événements sur la page de détail de l’incident de performance :

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.

Performances de l’échantillon

Les décompositions d’échantillons vous permettent d’examiner rapidement les performances de Sidekiq et de repérer les problèmes de performances sans avoir à plonger dans les détails.

Exemple d'échantillon de performance Sidekiq

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	`transaction_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	`transaction_duration`	`action` `namespace`
Worker/processes count	`sidekiq_worker_count` `sidekiq_process_count`	`hostname`

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 nom de l’hôte depuis lequel la métrique a été signalée.
`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, soit `processed`, soit `failed`. 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 connexions Sidekiq par hôte. Vous pouvez utiliser le graphique Connection count pour surveiller les connexions Sidekiq par hôte, 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 attendus par statut et namespace. Vous pouvez utiliser le graphique Overall job status pour surveiller les jobs échoués et suivre la distribution des jobs entre les namespaces.

Graphique Queue latency

Le graphique Queue latency montre la latence subie par la queue au moment de la mesure. Sidekiq calcule cela en soustrayant l’heure à laquelle le dernier job a été mis en file d’attente de l’heure de la mesure. 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 namespace. 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 hostname. Vous pouvez utiliser ce graphique pour surveiller les performances des workers, regroupées par la classe qui définit le job.

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.

AppSignal pour Ruby

AppSignal pour Elixir

AppSignal pour Node.js

AppSignal pour front-end

AppSignal pour Python

AppSignal pour Go

AppSignal pour Java

AppSignal pour PHP

OpenTelemetry

Wrap

Collector

Agent autonome

Surveillance de Sidekiq pour les applications Ruby on Rails

Surveillance de Sidekiq pour les applications Ruby