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

Si le serveur hébergeant le daemon est surchargé en terme 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 daemon. Il faut alors si c'est faisable isoler le volume des disques sur un disque moins chargé pour ne pas ralentir le daemon.

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

2020-05-04 00:00:51 WARNING : [ LOGGER ]
2020-05-04 00:00:51 WARNING : [ LOGGER ] ----------------------------------------------------------------------------------------------------
2020-05-04 00:00:51 WARNING : [ LOGGER ] [ WRITING ] The log write time is very high (1.87s). Please look at your log disk performance.
2020-05-04 00:00:51 WARNING : [ LOGGER ] ----------------------------------------------------------------------------------------------------
2020-05-04 00:00:51 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 suivant permet de suivre le chargement de la configuration de supervision entre l'arbiter les schedulers jusqu'au interface : webui / livestatus / livedata

Il existe 2 type d'identifiant 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 :

[1589548527] INFO : [scheduler] [schedulerdeamon] [ CONFIGURATION ] [ NEW ] Configuration received [ configuration_part_id : configuration_part_id, configuration_uuid=configuration_uuid, author=arbiter_name, date=creation_date, ]

• configuration_part_id -> id de la parti de configuration spécifiquement géré par ce Scheduler ( unique par 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ée cette configuration

[1589548527] INFO   : [scheduler] [schedulerdeamon] [ CONFIGURATION ] [ NEW ] Configuration received [ part configuration: part=1280, configuration_uuid=e551f7f93f2d45bfafae77fc302db7a2, date=15-05-2020 15:13:38, author=arbiter-master1 ]

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

[2020-05-15 15:15:30] INFO : [scheduler-master1] [schedulerdeamon] [ CONFIGURATION ] [ NEW ] Loaded in [1.31168293953]s => [ configuration_part_id : configuration_part_id, configuration_uuid=configuration_uuid, date=creation_date, author=arbiter_name ]

• configuration_part_id -> id de la partit de configuration géré par ce Scheduler (unique par 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ée cette configuration
• loading_time -> temps de chargement de la configuration

[2020-05-15 15:15:30] INFO   : [scheduler-master1] [schedulerdeamon] [ CONFIGURATION ] [ NEW ] Loaded in [1.31168293953]s => [ part configuration: part=1280 configuration_uuid=e551f7f93f2d45bfafae77fc302db7a2 date=15-05-2020 15:13:38 author=arbiter-master1]