Passer au contenu principal
Sidekiq est un processeur d’arrière-plan 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éera un Magic Dashboard vous permettant de surveiller visuellement les métriques principales.

​
Surveillance 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 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, AppSignal vous donnera des informations sur les performances via :

​
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 : Exemple de chronologie d'événements

​
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èvera 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. Exemple d'erreur sidekiq

​
Signaler les erreurs lors de l’abandon du 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é. Lisez la documentation Sidekiq pour en savoir plus sur la gestion des exceptions Sidekiq et les nouvelles tentatives de 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 tentatives d’Active Job épuisées, le système de nouvelles tentatives de Sidekiq prendra le relais. Désactivez le système de nouvelles tentatives Sidekiq si ce comportement n’est pas souhaité.

​
Regroupement d’incidents

Les noms de jobs sont automatiquement détectés en fonction du nom de classe du worker Sidekiq et suffixés par le nom de la méthode perform, ce qui donne quelque chose comme : MyWorker#perform. Exemple de regroupement d'incidents de performance

​
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

​
Magic dashboard

Lorsqu’AppSignal reçoit des métriques Sidekiq, il créera un magic dashboard Sidekiq, disponible dans la section dashboard de l’application AppSignal. Le magic dashboard Sidekiq contiendra les graphiques suivants :
GraphiqueMétriquesTags
Connection countsidekiq_connection_counthostname
Duration per workertransaction_duration
  • action
  • namespace
    • Job status per queuesidekiq_queue_job_count
  • status
  • queue
    • Overall job statussidekiq_job_count
  • status
  • hostname
    • Queue latencysidekiq_queue_latency
  • hostname
  • queue
    • Queue lengthsidekiq_queue_length
  • hostname
  • queue
    • Redis memory usage
  • sidekiq_memory_usage
  • sidekiq_memory_usage_rss
    		• hostname
    Throughput per workertransaction_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 :
    NomDescription
    actionLe nom de l’action depuis laquelle la métrique a été signalée (par exemple, YourWorker#perform).
    hostnameLe nom de l’hôte depuis lequel la métrique a été signalée.
    namespaceLe nom du namespace depuis lequel la métrique a été signalée.
    queueFile d’attente nommée dans laquelle les jobs sont traités, par exemple default ou mailer.
    statusStatut 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 : Exemple de dashboard Sidekiq

    ​
    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, vous donnant une vue d’ensemble des performances de Sidekiq et 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 avec une priorité montre le nombre de jobs qui ont été exécutés, regroupés par leur statut résultant, par la file d’attente dans laquelle ils ont été mis en file. Vous pouvez utiliser le graphique Job status per queue pour surveiller les nombres d’erreurs et les performances des jobs en fonction de la file d’attente, identifier les goulots d’étranglement et optimiser vos jobs en arrière-plan 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 file d’attente 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 rapporté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 files d’attente et comprendre la rapidité avec laquelle les jobs en arrière-plan démarrent.

    ​
    Graphique Queue length

    Le graphique Queue length montre la longueur des files d’attente Sidekiq par file et namespace. Vous pouvez utiliser le graphique Queue length pour surveiller les performances des files d’attente et repérer et résoudre les goulots d’étranglement Sidekiq.

    ​
    Graphique Redis memory usage

    Le graphique Redis memory usage affiche :
    • L’utilisation de la mémoire Virtual Memory Size de Redis (sidekiq_memory_usage_rss)
    • L’utilisation de la mémoire Resident Set Size de Redis (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 nom d’hôte

    AppSignal tente de détecter le nom d’hôte de l’instance Redis utilisée par votre instance Sidekiq pour stocker ses files d’attente. Si la détection n’est pas précise, il est possible de personnaliser la configuration du nom d’hôte 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 nom d’hôte. 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 nom d’hôte 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 sera imprimé et journalisé. Mettez à jour vers le nouveau nom de constante Appsignal::Probes::SidekiqProbe pour supprimer l’avertissement.