Page History

Les fichiers de log du Scheduler sont situés dans le dossier /var/log/shinken/. Pour plus d'informations, consultez la page Fichiers Logs.

Démarrage du démon

Lors du démarrage du démon, une ligne est disponible:

Au démarrage et tous les jours à minuit, ce log indique la version ainsi que le numéro de patch cumulatif du démon.

[YYYY-MM-DD HH:MM:SS] INFO   : [daemon scheduler-name ] [START-DAEMON] The daemon (version=02.08.01Daemon version is: XX.XX.XX-release.fr culmulative-patch-YY

Lors du démarrage du démon, une ligne est disponible:

) is now started as a daemon (detached from any shell) with pid=15412
[YYYY-MM-DD HH:MM:SS] INFO   : [daemon scheduler-mastername ] [START-DAEMON] SYSTEMThe daemon (version=02.08.02-release.fr) is now started as a daemon (detached from any shell) with pid=15412
[YYYY-MM-DD HH:MM:SS] INFO   : [ scheduler-name ] [ SYSTEM           ] System resource number of open files is set to      (soft:1024       / hard:1024      ) (from parameter max_file_descriptor_limit)
[YYYY-MM-DD HH:MM:SS] INFO   : [daemon scheduler-mastername ] [ SYSTEM           ] System resource number of processprocesses/threads is set to (soft:unlimited  / hard:unlimited ) (set at system max values)

Avec comme informations principales:

• Sa version
• Son numéro de PID
• Ses limites systèmes en nombre de fichiers/socket ouvrables, et le nombre max de processus/threads

Surcharge serveur en activité disque, ralentissant l'écriture des logs

• Sur quelle(s) interface(s) le démon écoute

S'il écoute sur toutes les interfaces:

Si le serveur hébergeant le démon est surchargé en termes d'IO disques sur le volume qui héberge le fichier de log, alors ce dernier va mettre du temps à s'écrire et va ralentir tout le démon. Il faut alors si c'est faisable isoler le volume des disques sur un disque moins chargé pour ne pas ralentir le démon.

En cas de soucis, vous aurez dans les logs l'entrée suivante:

[YYYY-MM-DD HH:MM:SS] WARNINGINFO   : [ LOGGER ]
scheduler-name ] [schedulerdeamon] The daemon listens on all network interfaces.

S'il écoute sur une interface précise:

[YYYY-MM-DD HH:MM:SS] WARNINGINFO :  : [ scheduler-name LOGGER] [schedulerdeamon] ----------------------------------------------------------------------------------------------------
[YYYY-MM-DD HH:MM:SS] WARNING : [ LOGGER ] [ WRITING ] The log write time is very high (1.87s). Please look at your log disk performance.
[YYYY-MM-DD HH:MM:SS] WARNING : [ LOGGER ] ----------------------------------------------------------------------------------------------------
[YYYY-MM-DD HH:MM:SS] WARNING : [ LOGGER ]

Chargement des broks initiaux par un regenerator ( créateur d'objets des modules de broker ) et vérifier que c'est bien la même configuration charger entre les regenerators / scheduler / arbiter

Les logs suivants permettent de suivre le chargement de la configuration de supervision entre l'Arbiter et les Schedulers jusqu'aux interfaces : webui / livestatus / livedata.

Il existe 2 types d'identifiants de configuration ( représentation de la configuration ).

• configuration_uuid:  uuid de configuration total généré par l'Arbiter
• configuration_part_id: id de la partie de configuration géré par un Scheduler

Quand un Scheduler reçoit une nouvelle configuration de l'arbiter, il log

Chargement des broks initiaux par un regenerator ( créateur d'objets des modules de broker ) et vérifier que c'est bien la même configuration charger entre les regenerators / scheduler / arbiter

Les logs suivants permettent de suivre le chargement de la configuration de supervision entre l'Arbiter et les Schedulers jusqu'aux interfaces : webui / livestatus / livedata.

Il existe 2 types d'identifiants de configuration ( représentation de la configuration ).

• configuration_uuid:  uuid de configuration total généré par l'Arbiter
• configuration_part_id: id de la partie de configuration géré par un Scheduler

Quand un Scheduler reçoit une nouvelle configuration de l'Arbiter, il logue

[YYYY-MM-DD HH:MM:SS] INFO : [ scheduler-name ] [ CONFIGURATION ] The arbiter send us a new configuration: [ configuration_part_id=configuration_part_id, configuration_uuid=configuration_uuid, arbiter=arbiter_name, architecture=architecture_name, date=creation_date]

• configuration_part_id: id de la partie de configuration spécifiquement gérée par ce Scheduler ( unique pour chaque Scheduler )
• configuration_uuid: uuid créé lors du démarrage de l'Arbiter qui correspond donc à l'id de la configuration géré par l'Arbiter
• arbiter_name:  nom de l'Arbiter qui a créé cette configuration
• architecture_name : nom de l'architecture
  
• creation_date:  date du démarrage de l'Arbiter

[YYYY-MM-DD HH:MM:SS] INFOERROR : [ scheduler]-name [schedulerdeamon] [Incompatible CONFIGURATIONdaemon ] [ NEW ] Configuration received [ configuration_part_id=configuration_part_id, configuration_uuid=configuration_uuid, arbiter=arbiter_name, date=creation_date, ]

• configuration_part_id: id de la parti de configuration spécifiquement gérée par ce Scheduler ( unique pour chaque Scheduler )
• configuration_uuid: uuid crée lors du démarrage de l'Arbiter qui correspond donc à l'id de la configuration géré par l'Arbiter
• creation_date: date du démarrage de l'Arbiter
• arbiter_name: nom de l'Arbiter qui a créé cette configuration

version : Your Arbiter daemon is in version [XX.XX.XX-release.fr culmulative-patch-YY] while this daemon is in version [XX.XX.XX-release.fr culmulative-patch-YY]. Refusing this configuration.

Dans le cas où le scheduler n'est pas de la même version que l'arbiter et que l'option *mismatch_version_error* est désactivé sur l'arbiter:

[YYYY-MM-DD HH:MM:SS] INFO WARNING  : [ scheduler]-name [schedulerdeamon] [Incompatible CONFIGURATIONdaemon ]version [: NEWYour ] Configuration received [ configuration_part_id=1280, configuration_uuid=e551f7f93f2d45bfafae77fc302db7a2, arbiter=arbiter-master1, date=15-05-2020 15:13:38 ]

Quand un Scheduler a fini de charger la nouvelle configuration reçu, il log 

Quand un Scheduler est en train de charger sa nouvelle configuration, il logue

Le log suivant apparaît si le Scheduler n'a pas fini de charger sa configuration est qu'il reçoit une demande de statut

[YYYY-MM-DD HH:MM:SS] INFO   : [ scheduler-master1name ] [schedulerdeamonscheduler] [ CONFIGURATION 0] [Someone NEWasks ]to Loadedget in [loading_time]s => [ configuration_part_id=configuration_part_id, configuration_uuid=configuration_uuid, date=creation_date, author=arbiter_name ]the raw stats (deamon Health) but the scheduler is not initialized

Quand un Scheduler a fini de charger la nouvelle configuration reçu, il logue

[YYYY-MM-

• configuration_part_id: id de la parti de configuration gérée par ce Scheduler (unique pour chaque Scheduler)
• configuration_uuid:  uuid crée lors du démarrage de l'Arbiter qui correspond donc à l'id de la configuration géré par l'Arbiter
• creation_date: date du démarrage de l'Arbiter
• arbiter_name: nom de l'Arbiter qui a créé cette configuration
• loading_time:  temps de chargement de la configuration

[YYYY-MM-DD HH:MM:SS] INFO   : [ scheduler-master1]name [schedulerdeamon] [ CONFIGURATION ] [ NEW ] Loaded in [1.31168293953]s => [ configuration_part_id=1280 configuration_uuid=e551f7f93f2d45bfafae77fc302db7a2, author=arbiter-master1, date=15-05-2020 15:13:38]

Logs DEBUG des escalades

The configuration [ shard_id=shard_id, scheduler=scheduler, configuration_uuid=configuration_uuid, arbiter=arbiter_name, architecture=architecture, date=creation_date, active=active] was loaded in [loading_time]s

• shard_id: id de la partie de configuration gérée par ce Scheduler (unique pour chaque Scheduler)
  
• scheduler:  Nom du Scheduler qui reçoit la configuration
• configuration_uuid:   uuid crée lors du démarrage de l'Arbiter qui correspond donc à l'id de la configuration géré par l'Arbiter
• arbiter_name:  nom de l'Arbiter qui a créé cette configuration
• achitecture: nom de l'architecture de l'Arbiter
• creation_date: date du démarrage de l'Arbiter
• active: définit si le démon est mis en tant que spare ou non
• loading_time:   temps de chargement de la configuration

[

Choix de l'escalade

Savoir quelle notification est prise, on a ce log. Attention, seule la dernière ligne sera utile (une escalade ayant pris le pas sur la précédente):

[YYYY-MM-DD HH:MM:SS] INFO DEBUG : ESCALATION: [NOM HOTE/CHECK scheduler-name ] The[ escalationCONFIGURATION NOM_ESCALADE give us a] validThe start time (TEMPS). Looking if other escalations are giving us earlier time.'

Choix de l'intervalle

Demande et génération des broks initiaux

Les modules de Broker ont besoin des Broks dit "initiaux" afin d'avoir une image complète des éléments de supervision (hôtes, checks, mais aussi timeperiod et commandes). Quand une nouvelle configuration est chargée par le scheduler, le Broker le détecte et demande une génération des broks initiaux. Ceci est visible par la log suivant:

Savoir quel intervalle de notification est pris, il faut là encore prendre la dernière ligne (si plusieurs escalades sont possibles au même moment):

[YYYY-MM-DD HH:MM:SS] DEBUGINFO :  ESCALATION: [NOM HOTE/CHECK scheduler-name ] The[ escalation NOM_ESCALADE is eligible and with a short notification interval, so we are using its interval: VALEUR_INTERVAL_ESCALADE.

Escalade avec un intervalle de notification à 0

La génération va commencer.

Quand une escalade n'a pas d'intervalle de notification (ceci va envoyer une seule notification), on est mis au courant par cette ligne:

[YYYY-MM-DD HH:MM:SS] DEBUGINFO :  ESCALATION: [NOM HOTE/CHECK] The escalation NOM_ESCALADE have no notification interval, so disabling next notification.

Logs de chargement des modules

Les démons ont une phase de chargement des modules qui est décrite dans la page HIDDEN - Logs de chargement des modules

Erreur de cohérence des périodes de maintenance

Pendant ce temps, d'autres demandes vont se rajouter à la première si on a plusieurs Brokers.

Une fois la génération finie, on aura le log suivant:

Les périodes de maintenance ont une incohérence entre non identifiée qui consiste à ce qu'une période de maintenance va être démarrée deux fois, ce qui va poser soucis lors de son arrêt (l'hôte/check sera dans un état incohérent). Pour l'instant, nous n'avons pas trouvé la source de l'incohérence, mais nous avons mis des protections pour les éviter et corriger.

Au chargement de la rétention, on aura une entrée "ERROR":

[YYYY-MM-DD HH:MM:SS] ERRORINFO   : [ scheduler-mastername ] [ DOWNTIME-INCOHERENCYINITIAL ]BROKS The  host ] moi[ hasGENERATING bad] downtime[ valuesDONE (saved] number[ ofElapsed downtimetime=1, actual=0).042s We] are241 fixinginitial thebroks values.are Pleasegenerated reportfor it to the support.

Lors du second démarrage de la période de maintenance:

[YYYY-MM-DD HH:MM:SS] ERROR2 brokers:
[YYYY-MM-DD HH:MM:SS] INFO   : [ scheduler-mastername ] [ DOWNTIME-INCOHERENCYINITIAL ]BROKS The  downtime ] [Downtime id=1596532528600972 active=active type=fixed start=Tue Aug 4 11:16:06 2020 - end=Tue Aug 4 12:15:06 2020] on moi got activated twice. This is a bug and MUST be reported to support for investigation. Thanks.

Dans les deux cas, il faut récupérer les logs du Scheduler, et les donner en analyse au support Shinken.

Exécution de commandes externes reçues d'un Receiver

Et les Brokers seront prévenus qu'ils peuvent désormais revenir télécharger les broks:

Logs de chargement des modules

Les démons ont une phase de chargement des modules qui est décrite dans la page GLOBAL - Les logs de gestion des modules - chapitre [ MODULES-MANAGER ]

Communication entre Schedulers

Quand un Scheduler distant n'a pas reçu de configuration de l'Arbiter

Quand un Scheduler distant reçoit une configuration de l'Arbiter

[YYYY-MM-DD HH:MM:SS] INFO   : [ scheduler-name ] [ CONFIGURATION ] The scheduler-distant change it's configuration from configuration_uuid to new_configuration_uuid

• configuration_uuid: uuid créé lors du démarrage de l'Arbiter qui correspond donc à l'id de la configuration géré par l'Arbiter
• new_configuration_uuid: uuid créé lors du démarrage de l'Arbiter qui correspond donc au nouvel id la configuration géré par l'Arbiter

[YYYY-MM-DD HH:MM:SS] INFO   : [ scheduler-name ] [ CONFIGURATION ] The scheduler-distant change it's configuration from 6ddbcbd9260e40d9a8a48e1eabc875a5 to 32ab5f3457fb4c3fbe2415d873ae199e

Quand un Scheduler distant reçoit une nouvelle configuration de l'Arbiter

Requête d'export des données

La commande shinken-scheduler-export-data invoquée depuis le serveur de l'Arbiter permet de questionner les Schedulers pour extraire des données sur les éléments supervisés.
Lorsque cette commande est utilisée, les logs qui suivent permettent de voir la nature de la réponse faite par un Scheduler.

Avec les noms des éléments

Sans les noms des éléments

Erreurs possibles

Le Scheduler est en phase de démarrage

Le Scheduler ne gère pas encore de configuration

La configuration interdit l'export de données

Impossible d'exporter les noms des éléments car le mot de passe d'accès n'a pas été configuré

Accès refusé suite à l'utilisation d'un mauvais mot de passe

Erreur de cohérence des périodes de maintenance

Les périodes de maintenance ont une incohérence entre non identifiée qui consiste à ce qu'une période de maintenance va être démarrée deux fois, ce qui va poser soucis lors de son arrêt (l'hôte/check sera dans un état incohérent). Pour l'instant, la source de l'incohérence n'a pas été trouvée, mais des protections ont été mises en place pour les éviter.

Au chargement de la rétention, on aura une entrée "ERROR":

[YYYY-MM-DD HH:MM:SS] ERROR : [ scheduler-name ] [ DOWNTIME-INCOHERENCY ] The host Linux has bad downtime values (saved number of downtime=1, actual=0). We are fixing the values. Please report it to the support.

Lors du second démarrage de la période de maintenance:

[YYYY-MM-DD HH:MM:SS] ERROR : [ scheduler-name ] [ DOWNTIME-INCOHERENCY ] The downtime [Downtime id=1596532528600972 active=active type=fixed start=Tue Aug 4 11:16:06 2020 - end=Tue Aug 4 12:15:06 2020] on moi got activated twice. This is a bug and MUST be reported to support for investigation. Thanks.

Dans les deux cas, il faut récupérer les logs du Scheduler, et les donner en analyse au support Shinken.

Exécution de commandes externes reçues d'un Receiver

Lorsque le Receiver envoie des commandes externes au Scheduler, il est possible que ce dernier n'ait pas reçu de configuration de la part de l'Arbiter et qu'il ne soit pas en capacité d'exécuter ces commandes. Dans ce cas-là, cette entrée est renvoyé :

[YYYY-MM-DD HH:MM:SS] INFO   : [ scheduler-name ] [ BUS COMMANDS      ] Get external commands (like recheck, set acknowledge, etc) from the Receiver receiver-master but i am not ready. Waiting for configuration from Arbiter.

Dans le cas où, les commandes ont pu être exécutées :

[YYYY-MM-DD HH:MM:SS] INFO   : [ scheduler-name ] [ BUS COMMANDS      ] Running 200 external commands (like recheck, set acknowledge, etc) received from the Receiver receiver-master

Les commandes externes différentes des mise à jour de statut sont également listées :

[YYYY-MM-DD HH:MM:SS] INFO   : [ scheduler-name ] [ EXTERNAL COMMAND ] received command [ COMMAND_NAME ] on [ ELEMENT ] with args [ OPTIONAL_PARAMETERS ]

Les valeurs les plus courantes pour COMMAND_NAME sont les suivantes :

Check acknowledge

Check acknowledge deletion

Create check downtime

Delete check downtime

Schedule immediate check

Host acknowledge

Host acknowledge deletion

Create host downtime

Delete host downtime

Schedule immediate host

Exemples

Exécution de commandes par les gestionnaires d'évènements

Pour le gestionnaire d'évènements d'un hôte : 

[YYYY-MM-DD HH:MM:SS] INFO: [ NOM DU SCHEDULER ] SERVICE EVENT HANDLER: NOM DE L'HÔTE; NOM DU SERVICE; STATUT DU SERVICE; CONFIRMATION DU STATUT; NOMBRE DE TENTATIVES DE CONFIRMATION DE STATUT; NOM DE LA COMMANDE

Pour le gestionnaire d'évènements d'un check : 

[YYYY-MM-DD HH:MM:SS] INFO: [ NOM DU SCHEDULER ] HOST EVENT HANDLER: NOM DE L'HÔTE; STATUT DE L'HÔTE; CONFIRMATION DU STATUT; NOMBRE DE TENTATIVES DE CONFIRMATION DE STATUT; NOM DE LA COMMANDE 

Échanges par paquet de taille limité des Broks avec le Broker

Quand le broker demande les broks au Scheduler, ce dernier va avoir dans ses logs:

[YYYY-MM-DD HH:MM:SS] INFO : [ scheduler-name ] [ GIVE BROKS ] [ broker-master ] Sending 5 broks (1.3kB)

Si on se retrouve dans un cas où la limite du broks_packet_size est atteinte (sur les broks initiaux par exemple), on va avoir la ligne suivante:

[YYYY-MM-DD HH:MM:SS] INFO : [ scheduler-name ] [ GIVE BROKS ] [ broker-master3 ] Sending 2588 broks (413.4kB) [chunk, still 1698 to send]

En cas de problème de communication, il se peut qu'un paquet de broks soit perdu, dans ce cas, une réémission est faite pour éviter cette perte, on aura un WARNING suivant:

[YYYY-MM-DD HH:MM:SS] WARNING: [ scheduler-name ] [ GIVE BROKS ] [ broker-master ] Packet number did mismatch "100d0ccf12de4665bf04f2150dcc97d5" != "0ca27bc3ea5440358c1194b5b7c3b4f4" : Re-sending broks (6.3kB)

Log de performance de la boucle du scheduler

Dans la boucle du Scheduler, les logs ci-dessous permettent de connaître le temps d'exécution passé pour chaque action. 

[YYYY-MM-DD HH:MM:SS] INFO   : [ scheduler-name ] [ SCHEDULER TIME   ] [ === Loop start === ] [ Loop number=7885  ] ===-===-===-===-===-===-===-===-===-===-===-===-===
[YYYY-MM-DD HH:MM:SS] INFO   : [ scheduler-name ] [ SCHEDULER TIME   ] took [ 0.005 ]s to schedule checks, consume results and create broks
[YYYY-MM-DD HH:MM:SS] INFO   : [ scheduler-name ] [ SCHEDULER TIME   ] took [ 0.005 ]s to update items context ( downtimes, acknowledge, flapping, root_problems, business values )
[YYYY-MM-DD HH:MM:SS] INFO   : [ scheduler-name ] [ SCHEDULER TIME   ] took [ 0.005 ]s to clean data ( cache, zombies, proxy, stats, notifications list )
[YYYY-MM-DD HH:MM:SS] INFO   : [ scheduler-name ] [ SCHEDULER TIME   ] took [ 0.005 ]s to check environment and update stats ( satellite_thread, time, retention, orphan, modules )
[YYYY-MM-DD HH:MM:SS] INFO   : [ scheduler-name ] [ SCHEDULER TIME   ] [ === Loop stop  === ] [ Loop number=7884  ] [PERF] [ 0.082 ]s

Afin d'avoir toutes les informations de DEBUG sur les performances du Scheduler (boucle principale), il faut le lancer avec:

SHINKEN_LOG_SCHEDULER_RECURRENT_TIMES_FLAG=1 /etc/init.d/shinken-scheduler -d start

Surcharge serveur en activité disque, ralentissant l'écriture des logs

Si le serveur hébergeant le démon est surchargé en termes d'IO disques sur le volume qui héberge le fichier de log, alors ce dernier va mettre du temps à s'écrire et va ralentir tout le démon. Il faut alors si c'est faisable isoler le volume des disques sur un disque moins chargé pour ne pas ralentir le démon.

En cas de soucis, il y aura les logs l'entrée suivant:

[YYYY-MM-DD HH:MM:SS] WARNING : [ LOGGER ]
[YYYY-MM-DD HH:MM:SS] WARNING : [ LOGGER ] ----------------------------------------------------------------------------------------------------
[YYYY-MM-DD HH:MM:SS] WARNING : [ LOGGER ] [ WRITING ] The log writes time is very high (1.87s). Please look at your log disk performance.
[YYYY-MM-DD HH:MM:SS] WARNING : [ LOGGER ] ----------------------------------------------------------------------------------------------------

Lorsque le Receiver envoie des commandes externes au Scheduler, il est possible que ce dernier n'ait pas reçu de configuration de la part de l'Arbiter et qu'il ne soit pas en capacité d'exécuter ces commandes. Dans ce cas-là, nous renvoyons cette entrée :

[YYYY-MM-DD HH:MM:SS] INFO   : [scheduler] [ BUS COMMANDS      ] Get external commands from the Receiver receiver-master but i am not ready. Waiting for configuration from Arbiter.

Dans le cas où, les commandes ont pu être exécutées :

[YYYY-MM-DD HH:MM:SS] INFO  WARNING : [scheduler-master] [ BUS COMMANDS      ] Running 200 external commands received from the Receiver receiver-master

Échanges par packet de taille limité des Broks avec le Broker

Logs d'erreur concernant des objets d'éxécution de check qui restent en mémoire dans le Scheduler

Dans le cas où le Scheduler détecte que des objets d'exécution de checks ne sont pas bien nettoyés dans l'index de lancement ( par rapport au temps ).

Ceci peut résulter en deux logs d'ERROR :

• Signifie qu'un objet a été consommé, mais qu'il est peut-être encore présent dans l'index

Quand le broker demande les broks au Scheduler, ce dernier va avoir dans ses logs:

[YYYY-MM-DD HH:MM:SS] INFO : [scheduler-master] [ GIVE BROKS ] [ broker-master ] Sending 5 broks (1.3kB)

Si on se retrouve dans un cas où la limite du broks_packet_size est atteinte (sur les broks initiaux par exemple), on va avoir la ligne suivante:

 ERROR : [ scheduler-name ] [ SCHEDULING ] [ JOB-EXECUTION FAST INDEX ] The check XXXX is zombie without being cleaned (name=YYYY, was indexed at SSSSSS). Please report to your support.

• Suite au premier dans la minute suivante, le Scheduler corrigera l'objet en trop.
  
  

[YYYY-MM-DD HH:MM:SS] INFOERROR : [ scheduler4-master1scheduler-name ] [ JOB-EXECUTION FAST INDEX ] [ SCHEDULING ] [ JOB-EXECUTION FAST INDEX ] [ GIVE BROKS ] [ broker-master3 ] Sending 2588 broks (413.4kB) [chunk, still 1698 to send]

En cas de problème de communication, il se peut qu'un paquet de broks soit perdu, dans ce cas, une réémission est faite pour éviter cette perte, on aura un WARNING suivant:

[YYYY-MM-DD HH:MM:SS] WARNING: [scheduler-master] [ GIVE BROKS ] [ broker-master ] Packet number did mismatch "100d0ccf12de4665bf04f2150dcc97d5" != "0ca27bc3ea5440358c1194b5b7c3b4f4" : Re-sending broks (6.3kB)

Les logs de la retention mongo

Connexion à une base de donnée

PERF: lock aquired in 0.000s, done in 0.001s] Did remove 9 forgotten execution from 2 past seconds indexed (total number of seconds inside=63).

Cette situation ne devrait pas être présente, donc il est conseillé d'activer des logs de debug plus détaillés concernant ce mécanisme via la variable d'environnement SHINKEN_LOG_SCHEDULER_JOB_EXECUTION_FAST_INDEX_FLAG

SHINKEN_LOG_SCHEDULER_JOB_EXECUTION_FAST_INDEX_FLAG=1 /etc/init.d/shinken-scheduler -d restart

Il est conseillé de fournir ces logs détaillés au support pour analyse.

Logs de WARNING concernant la suppression d'objets "notification" défectueux

Sur des installations datant d'avant la 02.03.03-U01, des objets "notifications" pouvaient rester indéfiniment en mémoire dans le Scheduler, mais sans être lancés.

• Ces objets de notification sont anciens et défectueux et ils sont vus comme "late" par le check du Scheduler.
• Une mise à jour via une version ou un patch, permet de supprimer ces objets.
• Ceci sera visible sur le premier démarrage du Scheduler avec le log suivant:

Quand le module mongo se connecte à une base de données, on va avoir le log suivant:

[YYYY-MM-DD HH:MM:SS] INFO WARNING: [ scheduler-mastername ] [ MongodbRetention ]RETENTION] [myhost] The notification [ SAVE WORKER 1 ] We are creating mongo connection [uri=mongodb://127.0.0.1/?safe=false] [database=shinken_retention] [ssh=False]

Il y indique donc:

• L'URL utilisée
• La base de données (peut être différente du défaut "shinken" comme ici)
• Si un tunnel SSH va être utilisé ou pas

Log de performance de la boucle du scheduler

Logs de WARNING concernant les notifications qui ne sont pas envoyées à cause des périodes de notification

[YYYY-MM-DD HH:MM:SS] WARNING: [ scheduler-name ] [ NOTIFICATION     ] The notification for NOM DE L'HOTE OU DU CHECK was not send because notification_period NOM DE LA PERIODE DE TEMPS do not provide a date in the next 366 days ( either in the past or nothing is defined, or days are excluded ).

Ce log sera affiché qu'une fois par jour au max par éléments afin d'évité de stature les logs.

Logs d'ERROR concernant l'arrêt du démon s'il n'arrive pas à charger les données de rétention

Si le démon n'arrive pas à charger les données de rétention, il va potentiellement perdre des données comme les notifications actuelles, les downtimes ou les acknowledge, ce qui est très visible pour les utilisateurs.

En l'état, on préfère tuer le démon afin qu'un spare puisse prendre le relai et fonctionner normalement.

Quand un scheduler s'arrête pour cette raison, il loggue:

Logs d'erreur concernant des objets d'éxécution de check qui restent en mémoire dans le Scheduler

Par rapport au ticket SEF-7705 on a rajouté des logs au scheduler dans le cas où il détecte que des objet exécution de checks ne sont pas bien netoyés dans l'index de lancement (par rapport au temps). Ceci peux résulter en deux logs d'ERROR qui doivent alors immédiatement générer un bug:

[YYYY-MM-DD HH:MM:SS] ERROR : [ scheduler-master ] [ SCHEDULING ] [ JOB-EXECUTION FAST INDEX ] The check XXXX is zombie without being cleaned (name=YYYY, was indexed at SSSSSS). Please report to support.

Signifie qu'un objet a été consommé MAIs qu'il est peut être encore présent dans l'index

[YYYY-MM-DD HH:MM:SS] ERROR  : [ scheduler-master ] [ JOB-EXECUTION FAST INDEX RETENTION        ] [Failed SCHEDULINGto ]load [the JOB-EXECUTION FAST INDEX ] [PERF: lock aquired in 0.000s, done in 0.001s] Did remove 9 forgotten execution from 2 past seconds indexed (total number of seconds inside=63).

Peux (mais pas obligatoirement) faire suite au premier dans la minute suivante: le scheduler a corrigé l'objet en trop, mais dans tout le cas on aurait pas dû se retrouver dans cette situation.

Dans le cas où ça arrive, il faut activer des logs plus verbeux concernant ce mécanisme pour le chercher via le flag SHINKEN_LOG_SCHEDULER_JOB_EXECUTION_FAST_INDEX_FLAG

SHINKEN_LOG_SCHEDULER_JOB_EXECUTION_FAST_INDEX_FLAG=1 /etc/init.d/shinken-scheduler -d restart

Logs de WARNING concernant la suppression d'objets notifications défectueux

Log d'ERROR quand on charge depuis la retention un nombre trop important de vérifications sur les hôtes ou les checks

Afin d'éviter un crash du Scheduler après le chargement d'une mauvaise rétention avec un check ou un hôte qui possède trop de vérifications, on ignore les vérifications et on log le message suivant : 

[YYYY-MM-DD HH:MM:SS] ERROR  : [ scheduler-name ] [ RETENTION ] [ ANALYSE ] [ CHECKS_IN_PROGRESS ] [ monhote/check The check have too much executions (503 > warning limit=100). This can be a bug, please contact your support with a backup of your retention for verification. [ uuid=b3e7d3307d2211eca52d080027940ca8-f9c118de7d2311ec80c7080027940ca8 ]

Options du support Shinken

Forcer l'étalement des checks au démarrage

Si, suite à une demande du support, l'option pour forcer l'étalement des checks a été activée, le log suivant apparaîtra lors du premier chargement d'une configuration par le Scheduler:

[YYYY-MM-DD HH:MM:SS] INFO   : [ scheduler-name ] [ MAINTENANCE ] [ CHECK SPREAD OUT ] Scheduler will force all check spread out

Si une installation date d'une 02.03.03-U01 (2016), alors il est possible que des objets notifications soient défectueux, et soit vus comme "late" par le check du scheduler. Une mise à jour permet de supprimer ces objets. Ceci sera visible sur le premier démarrage du scheduler avec le log suivant:

[YYYY-MM-DD HH:MM:SS] WARNING: [ scheduler-master ] [RETENTION] [myhost] The notification [Notification 557481183 status:scheduled command:VOID ref:unknown t_to_go:Tue Feb 2 07:49:19 2021 (creation=Fri Apr 28 02:19:56 2017) (is_master=False) (on myhost)] was detected as invalid (bug from old code), and was droped.