Gérer Sidekiq en production : jobs planifiés, débogage et nettoyage

Sidekiq est facile à faire tourner et facile à perdre de vue une fois qu'une application Rails est en production depuis un ou deux ans et compte quarante classes de jobs différentes. Quelques pratiques le gardent maîtrisable bien après la mise en place initiale.

Des queues par priorité, pas par fonctionnalité

Une erreur fréquente consiste à nommer les queues d'après les fonctionnalités (invoices, emails, exports) sans réfléchir à ce qui se passe quand l'une d'elles s'engorge. Nous organisons plutôt les queues selon l'urgence d'exécution : critical pour tout ce qu'un utilisateur attend activement, default pour le reste, low pour les exports et rapports qui peuvent attendre une heure. Les workers sont pondérés pour vider critical en premier, de sorte qu'une rafale de génération de rapports ne retarde jamais un email de réinitialisation de mot de passe.

-q critical,5 -q default,2 -q low,1

Les jobs planifiés ont besoin de leur propre visibilité

Un job récurrent qui cesse silencieusement de s'exécuter est l'une des pannes les plus difficiles à remarquer, car rien ne lève d'erreur, rien ne déclenche d'alerte : les choses cessent simplement de se produire. Nous associons chaque job planifié à un contrôle de heartbeat : le job notifie un endpoint de monitoring en cas de succès, et une alerte se déclenche si cette notification n'arrive pas dans la fenêtre attendue.

Les jobs morts sont une file, pas un cimetière

L'ensemble des jobs morts se remplit discrètement et reste ignoré jusqu'à ce que quelqu'un remarque qu'un client n'a jamais reçu une facture émise trois semaines plus tôt. Nous le passons en revue à intervalles réguliers, pas seulement quand quelqu'un se plaint, et nous considérons qu'un job qui meurt de façon répétée est le signe que le job ou son nombre de retries doit changer, et non quelque chose à remettre en file puis à oublier de nouveau.

Le gonflement mémoire est généralement la faute d'un seul job

Un processus worker dont la mémoire grossit lentement jusqu'à ce qu'il soit tué est presque toujours causé par un job précis qui charge trop de données en mémoire d'un coup, la requête sans batch qui charge une table entière étant le coupable le plus courant. Un chargement par lots avec une taille de page raisonnable règle la majorité de ces cas, et une métrique de mémoire par job dans votre monitoring rend le coupable évident au lieu d'en faire un mystère.