Les journaux Open Source JobScheduler

De SOS Paris
Aller à : navigation, rechercher


Open Source JobScheduler fournit de nombreuses informations utiles en cas de diagnostic, ces informations sont stockées dans les différents niveaux d'exécution d'un traitement.

Les journaux sont les suivants:

  • au niveau du moteur
  • à l'exécution de la chaine
  • à l'exécution du job
  • à l'exécution de la tâche
  • à l'exécution du batch

On distinguera 3 types de logs:

  • les logs du moteur: il ne devraient jamais être modifiés sauf cas exceptionnel pour du debug par exemple mais seulement sur un environnement de test et par l'administrateur de la plateforme.
  • les logs de l'exécution: aucun changement en production mais le niveau de debug peut être modifié lors de la phase de développement
  • les logs du batch: ce sont les logs générés par le concepteur du script et certainement les plus utiles pour le suivi du traitement.

Important : les logs peuvent prendre de la place sur un système, il est donc important de mettre en place un système de purge dès l'installation du système. Arii comporte un job de rotation de log qu'il suffit de paramétrer selon ses besoins et de démarrer.

Journaux utilisateur

Les journaux du script sont ceux que l'on consulte en cas de dysfonctionnement, le fond et la forme dépendent du concepteur du script qui se plient généralement aux normes du site.

Il existe 3 manières d'historiser les informations:

  • créer un ou plusieurs fichiers qui serviront à historiser les informations
  • envoyer les informations sur la sortie standard, (commande echo pour le shell, ou print pour des langages plus évolués)
  • envoyer les erreurs sur la sortie d'erreur

Fonctionnement par défaut

JobScheduler reprend les sorties standards et les sorties d'erreur pour n'en faire qu'un seul fichier. A la fin de l'exécution, ce fichier est compressé et envoyé dans la base de données afin de le centraliser avec les journaux de l'ensemble des moteurs. Le fichier resté en local sera alors écrasé par l'exécution suivante.

Cette solution toute prête permet:

  • d'avoir un journal exhaustif avec l'ensemble des informations (standard, erreur et information JobScheduler)
  • de centraliser les informations sur une base de données pour une visualisation globale et dans le temps
  • de pouvoir publier cette information par une requête sql même pour un jobscheduler distant
  • de ne gérer ni purge, ni rotation de journaux car il n'existe qu'un fichier par traitement

Journaux déportés

Si le fonctionnement par défaut est en conflit avec les normes du site, il est possible de mettre en place une nouvelle organisation en modifiant le processus. Cela arrive généralement lorsqu'on veut prolonger un existant, par exemple dans le cas où les journaux sont vérifiés pour extraire des messages d'erreurs qui ne sont pas remontés par un code retour (cas de requêtes SQL ou de transfert FTP).

De même, si les sorties d'erreurs sont dissociées des sorties standards pour des traitements ultérieurs il faudra dissocier ces canaux avant la construction du log par JobScheduler.

Exécution

Journaux de l'ordre

Journaux du traitement

Journaux du batch

Moteur OJS

Les logs des moteurs sont par défaut placés dans le répertoire logs et peuvent être déplacés en modifiant le paramètre log_dir au lancement du moteur. Le nom du journal est le suivant: scheduler-<date>.log

Les moteurs créent de nombreux types de fichiers de logs qu'on peut répartir en deux groupes : les logs pérennes  : activité journalisée et le log des paramètres les logs à durée de vie courte : pour chaque job, chaîne, tâche, ordre....OJS crée un log qui sera écrasé lors de la prochaine itération du job, de la chaîne, de la tâche, l'ordre...

Nous vous déconseillons fortement de modifier ces journaux, cela ne pourrait que complexifier le travail du support.