Page History

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

Démarrage du broker

[YYYY-MM-DD HH:MM:SS] INFO: [ broker-name ] Using the local log file '/var/log/shinken/brokerd.log'
[YYYY-MM-DD HH:MM:SS] INFO: [ broker-name ] Printing stored debug messages prior to our daemonization
[YYYY-MM-DD HH:MM:SS] INFO: [ broker-name ] [ SYSTEM           ] System resource number of open files      is set to (soft:131070     / hard:131070    ) (set at system max values)
[YYYY-MM-DD HH:MM:SS] INFO: [ broker-name ] [ SYSTEM           ] System resource number of processprocesses/threads is set to (soft:unlimited  / hard:unlimited ) (set at system max values)
[YYYY-MM-DD HH:MM:SS] INFO: [ broker-name ] Starting HTTP daemon
[YYYY-MM-DD HH:MM:SS] INFO: [ broker-name ] |--------------------------------------------------------------------------------------------------|
[YYYY-MM-DD HH:MM:SS] INFO: [ broker-name ]                                                          broker is starting
[YYYY-MM-DD HH:MM:SS] INFO: [ broker-name ] |--------------------------------------------------------------------------------------------------|

Avec affichage:

• Du fichier de log défini dans sa configuration (broker.ini)
• Du nombre de processus/threads maximum autorisé par le système pour ce démon
• Du nombre de fichiers ouverts maximum autorisé par le système

Chargement d'une configuration

Début du chargement d'une configuration d'architecture (ou configuration de changement d'architectue)

Premier chargement de la configuration

Lorsque le Broker reçoit sa configuration pour la première fois deux logs INFO sont affichés.

• Le premier indiquant que nous rentrons dans la phase de chargement d'une nouvelle configuration.

• Code Block
  theme Emacs
  [YYYY-MM-DD HH:MM:SS] INFO : [ broker-

• name

• ] [ CONFIGURATION ] ----- Loading the new configuration from the arbiter

• Le deuxième indiquant que nous avons reçu la configuration de l'Arbiter.

  Code Block
  theme Emacs
  [YYYY-MM-DD HH:MM:SS] INFO : [ broker-

• name

• ] [ CONFIGURATION ]

• The arbiter send us a new configuration

Notification d'un nouveau démarrage d'arbiter

• : [configuration_uuid=configuration-uuid, arbiter=arbiter-name, architecture=architecture-name, date=YYYY-MM-DD HH:MM:SS]

• Dans le cas où le broker n'est pas de la même version que l'arbiter et que l'option *mismatch_version_error* est activé sur l'arbiter

• :

  Code Block
  theme Emacs
  [YYYY-MM-DD HH:MM:SS]

• ERROR : [ broker-

• name ] Incompatible

• daemon version

• :

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

• daemon

• is

• in

Cas d'un démon recevant un nouveau démon spare ou une assignation d'un démon master

• version [XX.XX.XX-release.fr culmulative-patch-YY]. Refusing this configuration.

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

  Code Block
  theme Emacs
  [YYYY-MM-DD HH:MM:SS] WARNING : [ broker-name ] Incompatible daemon 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].

Mise à jour de la configuration

Lorsque qu'il y a une mise à jour de la configuration, deux logs en INFO sont affichés.

• Le premier indiquant que nous rentrons dans la phase de chargement d'une nouvelle configuration.

Réception des liens vers d'autres démons (schedulers, arbiters, ...)

• Code Block
  theme Emacs
  [YYYY-MM-DD HH:MM:SS] INFO : [ broker-

• name   ] [ CONFIGURATION

• ] [ UPDATE ] ----- Loading a configuration update from the arbiter

• Le deuxième indiquant que nous avons reçu la nouvelle configuration de l'Arbiter.

  Code Block
  theme Emacs
  [YYYY-MM-DD HH:MM:SS] INFO : [ broker-

• name ] [ CONFIGURATION

• ] [

• UPDATE ]

• The arbiter send us a new

• configuration:

Ici par exemple:

• La shard 256 n'est plus gérée par le scheduler scheduler-master
• Mais désormais par son spare scheduler-spare

Application par le démon de la propriété satellitemap (remaping d'adresse pour gérer un VLan)

• [configuration_uuid=configuration-uuid, arbiter=arbiter-name, architecture=architecture-name, date=YYYY-MM-DD HH:MM:SS]

• Dans le cas où le broker n'est pas de la même version que l'arbiter et que l'option *mismatch_version_error* est activé sur l'arbiter

• :

  Code Block
  theme Emacs
  [YYYY-MM-DD HH:MM:SS]

• ERROR : [ broker-

• name ]

• Incompatible

• daemon

• version

• :

• Your Arbiter daemon

• is

• in

Ici le scheduler scheduler-secondary est passé de l'adresse localhost:8768 à 192.168.1.124:8768.

Un tour de boucle

Début d'un tour

• 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 broker n'est pas de la même version que l'arbiter et que l'option *mismatch_version_error* est désactivé sur l'arbiter:

  Code Block
  theme Emacs
  [YYYY-MM-DD HH:MM:SS] WARNING : [ broker-name ] Incompatible daemon 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].

Cas d'un démon recevant un nouveau démon spare ou une assignation d'un démon master

Dans le cas où un master reçoit le nom de son démon spare, on aura

Récupération des broks des Schedulers et Arbiters

:

[YYYY-MM-DD HH:MM:SS] INFO   : [ broker-master  ] [RECEIVE BROKS] [ arbiter            CONFIGURATION ] [PERF] [MASTER 0.000 ]s -My Addspare 1daemon is   broks into INTERNAL queue (new size=18) and the EXTERNAL queue (new size=18)
now "broker-spare"

Dans le cas où un spare reçoit le nom de son démon master, on aura:

[YYYY-MM-DD HH:MM:SS] INFO   : [ broker-master spare ] [RECEIVE CONFIGURATION BROKS] [ arbiterSPARE ] I am now the spare of the master   ]                   ----- 1    composed of: architecture_export_map=1

daemon "broker-master"

Par rapport au paramètre broker__manage_spare__spare_must_have_the_same_list_of_module_type , le démon va mettre dans le cas où le paramètre change:

• Dans le cas où désormais il en a besoin:

  Code Block
  theme Emacs
  [YYYY-MM-DD HH:MM:SS] INFO

• : [ broker-master

• ] [

• CONFIGURATION ] [ MASTER ]

• The spare daemon "broker-spare-useless" is now requiring the same modules types as the master

• Dans le cas où désormais le spare n'a pas besoin d'avoir les mêmes modules (s'affichera notamment au démarrage du démon si le paramètre est désactivé)

  Code Block
  theme Emacs
  [YYYY-MM-DD HH:MM:SS] INFO

• : [ broker-master

• ] [

• CONFIGURATION

• ] [

• MASTER ] The spare daemon "broker-spare-useless" is now NOT requiring the same modules types as

Avec pour les deux cas:

• Affichage du nombre de broks récupérés sur le démon, et affichage de la taille des files d'attente une fois rajoutés
• Affichage du type de broks récupérés, ainsi que leur nombre

• the master

Mise à jour des liens vers d'autres démons

Lorsque que l'Arbiter détecte un changement de lien entre les démons quatre logs en INFO seront affichés.

• Les deux premiers logs affichent le(les) lien(s) du(des) démon(s) supprimé(s).

[YYYY-MM-DD HH:MM:SS] INFO WARNING: [ broker-master ] [ GIVE BROKS ] CONFIGURATION ] The arbiter asked us to remove daemons: 
[YYYY-MM-DD HH:MM:SS] INFO : [ broker-master ] Did[ failCONFIGURATION to] transfert- broksREMOVED from the scheduler "scheduler-master": [[Connexion error to https://192.80.10.220:7768/ : Operation timed out after 120000 milliseconds with 802816 out of 22791250 bytes received]. THESES BROKS ARE LOST AND CANNOT BE RETRIEVED

Elle disparaitra quand on aura bien testé le mécanisme de reprise sur erreur dans une future version.

Envoie des broks aux modules externes

Statut des files d'envoi

name=scheduler1-name] [shard_id= XXX] [uri=http://scheduler_address:port/] 

• Les deux premiers logs affichent le(les) lien(s) du(des) démon(s) ajouté(s).

[YYYY-MM-DD HH:MM:SS] INFO : [ broker-master ] [ CONFIGURATION ] The arbiter send us new daemons: 
[YYYY-MM-DD HH:MM:SS] INFO : [ broker-master ] [ CONFIGURATION ] + ADDED scheduler : [name=scheduler2-name] [shard_id= XXX] [uri=http://scheduler_address:port/]

Application par le démon de la propriété satellitemap (remaping d'adresse pour gérer un VLan)

Quand un démon a un paramètre satellitemap, il va changer l’adresse d'un autre démon par une autre (pour par exemple gérer le cas où il tourne dans un vlan avec un plan d’adressage particulier). Cette application se voit via le log suivant:

[YYYY-MM-DD HH:MM:SS] INFO : [ broker-master ] [ CONFIGURATION ] [ SATELLITEMAP ] Replacing the daemon scheduler-secondary to address:port from localhost:8768 => 192.168.1.124:8768 as defined in our daemon .cfg file (satellitemap property)

Ici le Scheduler scheduler-secondary est passé de l'adresse localhost:8768 à 192.168.1.124:8768.

Un tour de boucle

Début d'un tour

[YYYY-MM-DD HH:MM:SS] INFO: [broker-master  ] [MANAGE BROKS ] [ EXTERNAL MODULE ] => Number of "Broks Sets" not eaten in MODULE queues (WebUI5-ha): 11 (WebUI3-ha): 11 (WebUI7-ha): 11 (WebUI4-ha): 11 (WebUI8-ha): 11 (WebUI1-ha): 11 (WebUI2-ha): 11 (WebUI6-ha): 11

À chaque tour de boucle, le broker envoie 1 ensemble de broks à chaque WebUI. 1 ensemble est composé d'autant de broks qu'il a reçus dans le tour.

Si le nombre est plus gros que 1, c'est que les WebUIs mettent du temps à digérer les ensembles.

• C'est courant au démarrage, car les broks initiaux sont longs à être traités
• Mais cela ne devrait pas arriver après

[YYYY-MM-DD HH:MM:SS] INFO: [ broker-master name ] [MANAGEBROKER BROKSTIME ] [ PREPARING=== BROKSLoop start ===  ] [PERF] [ 0.001 ]s, preparing broks lists for INTERNAL and EXTERNAL modules

Chaque tour de boucle le broker préparer les listes d'envoi avec les nouveaux broks reçus.

] ===-===-===-===-===-===-===-===-===-===-===-===-===

Récupération des broks des Schedulers et Arbiters

L'Arbiter envoie ses broks vers le broker:

[YYYY-MM-DD HH:MM:SS] INFO   : [ broker-master name ] [MANAGERECEIVE BROKS ] [ EXTERNALarbiter     MODULE    ] - PUSHED ] [PERF] [ 0.331s, limit=5.000s 000 ]s, EXTERNAL- queueAdd evolution:1 [   424broks broksinto =>INTERNAL queue (new size=18) and 0the broksEXTERNAL remainingqueue ] [   424 broks managed ] [ Push average speed =  1928 broks/s]

Le broker a envoyé 424 broks en 0.331s, et avait laissé une limite de temps de 5s pour cet envoi (calcul basé sur la vitesse moyenne des derniers envois, ici 1928 broks/s, et une marge de sécurité).

À noter: si le nombre de broks remaining est différent de zéro, ceci signifie que le broker a reçu des broks pendant la phase d'envoi, et qu'il les enverra le prochain tour.

Envoie des broks aux modules internes (sans leur propre processus)

(new size=18)
[YYYY-MM-DD HH:MM:SS] INFO   : [ broker-name ] [RECEIVE BROKS] [ arbiter            ]                   ----- 1    composed of: architecture_export_map=1

Le broker récupère les broks depuis un Scheduler:

[YYYY-MM-DD HH:MM:SS] INFO   : [ broker-master name ] [MANAGEGET BROKS ] [ INTERNAL MODULE] [ scheduler-master   ] - EXECUTED[PERF] [ 0.239007 ]s, - Add 16   broks into INTERNAL queue evolution: [   424 broks =>   238 broks remaining ] [   424 broks managed ]
 (new size=16) and the EXTERNAL queue (new size=16)
[YYYY-MM-DD HH:MM:SS] INFO   : [ broker-name ] [GET BROKS    ] [ scheduler-master   ]                   ----- 16   composed of: host_check_result=10, host_next_schedule=6

Avec pour les deux cas:

• Affichage du nombre de broks récupérés sur le démon, et affichage de la taille des files d'attente une fois rajoutés
• Affichage du type de broks récupérés, ainsi que leur nombre

Quand on a une erreur de transfert qui faisait perdre des broks dans le passé, on a cette entrée dans les logs:

[YYYY-MM-DD HH:MM:SS] WARNING: [ broker-name ] [ GIVE BROKS ] [ broker-master ] Did fail to transfer broks from the scheduler "scheduler-master": [[Connexion error to https://192.80.10.220:7768/ : Operation timed out after 120000 milliseconds with 802816 out of 22791250 bytes received]. THESES BROKS ARE LOST AND CANNOT BE RETRIEVED

Elle disparaitra quand on aura bien testé le mécanisme de reprise sur erreur dans une future version.

Envoie des broks aux modules externes

Statut des files d'envoi

[YYYY-MM-DD HH:MM:SS] INFO: [ broker-name ] [MANAGE BROKS ] [ EXTERNAL MODULE ] => Number of "Broks Sets" not eaten in MODULE queues (WebUI5-ha): 11 (WebUI3-ha): 11 (WebUI7-ha): 11 (WebUI4-ha): 11 (WebUI8-ha): 11 (WebUI1-ha): 11 (WebUI2-ha): 11 (WebUI6-ha): 11

À chaque tour de boucle, le broker envoie 1 ensemble de broks à chaque WebUI. 1 ensemble est composé d'autant de broks qu'il a reçus dans le tour.

Si le nombre est plus gros que 1, c'est que les WebUIs mettent du temps à digérer les ensembles.

• C'est courant au démarrage, car les broks initiaux sont longs à être traités
• Mais cela ne devrait pas arriver après

Préparation des Broks pour l'envoi

[YYYY-MM-DD HH:MM:SS] INFO: [ broker-name ] [MANAGE BROKS ] [ PREPARING BROKS    ] [PERF] [ 0.001 ]s, preparing broks lists for INTERNAL and EXTERNAL modules

Chaque tour de boucle le broker préparer les listes d'envoi avec les nouveaux broks reçus.

Envoi vers les modules externes

[YYYY-MM-DD HH:MM:SS] INFO: [ broker-name ] [MANAGE BROKS ] [ EXTERNAL MODULE    ] - PUSHED   [ 0.331s, limit=5.000s ]s, EXTERNAL queue evolution: [   424 broks =>     0 broks remaining ] [   424 broks managed ] [ Push average speed =  1928 broks/s]

Le broker a envoyé 424 broks en 0.331s , et avait laissé une limite de temps de 5s  pour cet envoi (calcul basé sur la vitesse moyenne des derniers envois, ici 1928 broks/s , et une marge de sécurité).

À noter: si le nombre de broks remaining est différent de zéro, ceci signifie que le broker a reçu des broks pendant la phase d'envoi, et qu'il les enverra le prochain tour.

Envoie des broks aux modules internes (sans leur propre processus)

[YYYY-MM-DD HH:MM:SS] INFO: [ broker-name ] [MANAGE BROKS ] [ INTERNAL MODULE    ] - EXECUTED [ 0.239 ]s, INTERNAL queue evolution: [   424 broks =>   238 broks remaining ] [   424 broks managed ]
[YYYY-MM-DD HH:MM:SS] INFO: [ broker-name ]                                        ----- Details of INTERNAL brok deserialization time:0.010s modules execution time: (Graphite-Perfdata=0.071s), (Simple-log=0.010s), (sla=0.086s)

Le broker a fourni  424 broks aux modules internes (ceux qui n'ont pas leur propre processus), en  0.239s  au total. Ici le nombre de broks remaining est différent de zéro, ceci signifie que le broker a reçu des broks pendant la phase d'envoi, et qu'il les enverra le prochain tour.

Il fournit ensuite le temps passé à désérialiser les broks ainsi que le détail de temps de chaque module interne.

Récupération des commandes (demande de prise en compte, demande pour relancer une vérification, etc)

[YYYY-MM-DD HH:MM:SS] INFO: [ broker-mastername  ] [MODULES      ] [ BUS COMMANDS  ] [PERF] [ 0.001 ]s                        ----- Details of INTERNAL modules execution time: (Graphite-Perfdata=0.071s), (Simple-log=0.010s), (sla=0.086s)

Le broker a fourni 424 broks aux modules internes (ceux qui n'ont pas leur propre processus), en 0.239s au total. Ici le nombre de broks remaining est différent de zéro, ceci signifie que le broker a reçu des broks pendant la phase d'envoi, et qu'il les enverra le prochain tour.

Il fournit ensuite le détail de temps de chaque module interne.

Did read 0 internal commands (like recheck, set acknowledge, etc) from modules

Le broker récupère les commandes (comme une création de périodes de maintenance, etc.) et le temps que ceci lui a demandé.

Cas d'erreur

Si le broker ne parvient pas à récupérer les commandes d'un de ses modules, le log suivant est produit :

[YYYY-MM-DD HH:MM:SS] INFOWARNING: [ broker-master name ] [MODULES      ] [ INTERNALBUS COMMANDS   ] [PERF] [ 0.001 ]s DidCannot read 0shinken externalinternal commands (like recheck, set acknowledge, etc) from modules

module [MODULE-NAME]. We will retry it.

Appel au modules internes chaque seconde

Chaque fin de tour, un appel est lancé vers les modules internes afin qu'ils puissent faire des actions spécifiques (par exemple vérifier un cache, vider leurs éléments pas encore envoyés, etc.)

[YYYY-MM-DD HH:MM:SS] INFO: [ broker-mastername  ] [MODULES      ] [ TIME IN BROKER     ] [PERF] [ 0.025 ]s All modules "ticks" are done. Execution times by modules: (Graphite-Perfdata=0.001s), (sla=0.024s)

Avec:

• Le temps total
• Le temps passé par chaque module

Fin d'un tour

[YYYY-MM-DD HH:MM:SS] INFO: [ broker-mastername  ] [BROKER TIME ] [ === Loop stop === ] [ Loop number=XX ] [PERF] [ 0.397 ]s

Le broker donne le temps qu'il a passé sur ce tour de boucle. Ce dernier doit rester sous la seconde sauf pendant la phase de réception d'une nouvelle configuration où il peut dépasser ce temps.

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 dans la mesure du possible, 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 lots l'entrée suivante:

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

Arrêt d'un module

Quand le broker doit éteindre un de ses modules, le log suivant est généré :

[YYYY--------------
2020-05-04 00:00:51 WARNINGMM-DD HH:MM:SS] INFO : [ LOGGER ]BROKER-NAME ] [MODULES ] [MODULE-NAME] Stopping module process pid=6505