Versions Compared

Old Version 62

changes.mady.by.user Jean Gabes

Saved on

compared with

New Version Current

changes.mady.by.user Soubrié Grégoire

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Panel
titleSommaire

Table of Contents
stylenone

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

Messages d'erreurs possibles 

Erreur d'encodage dans les fichiers des modules

Ce log d'erreur indique qu'un fichier des modules de Shinken situé dans /etc/shinken n'est pas encodé en utf-8. Ce log d'erreur est suivi d'un log de warning indiquant le fichier en question dans l'exemple suivant c'est le fichier /etc/shinken/modules/webui.cfg qui ne respecte pas le bon encodage. The Arbiter master configuration was done in

Pour résoudre ce problème, il suffit de réencoder le fichier en utf-8:

Code Block
themeEmacs
[YYYY-MM-DD HH:MM:SS] ERROR  : [ arbiter-name ] [config] Some characters could not be read in utf-8 in these files :
[YYYY-MM-DD HH:MM:SS] WARNING: [ arbiter-name ] [config] - /etc/shinken/modules/webui.cfg

Paramètre obligatoire manquant dans les fichiers de configuration des modules

Le log ci-dessous apparaît au démarrage du démon Arbiter dans le fichier /tmp/bad_start_for_arbiter_instance_0 et indique qu'une propriété obligatoire est manquante dans le fichier de configuration d'un module.

Code Block
themeEmacs
[YYYY-MM-DD HH:MM:SS] ERROR  : [None arbiter          ] ********************************************************************************
[YYYY-MM-DD HH:MM:SS] ERROR  : [None   arbiter        ]
[YYYY-MM-DD HH:MM:SS] ERROR  : [None     arbiter      ] The "master_key" parameter for the synchronizer-import module (in file /etc/shinken/modules/synchronizer-import.cfg:11) is mandatory. It must be the same thanas the synchronizer one (in the synchronizer.cfg file) so only allowed arbiter can get the configuration.
[YYYY-MM-DD HH:MM:SS] ERROR  : [None arbiter          ]
[YYYY-MM-DD HH:MM:SS] ERROR  : [None arbiter          ] ********************************************************************************


Dans cet exemple, la propriété "master_key" est absente du fichier /etc/shinken/modules/synchronizer-import.cfg et empêche l'Arbiter de démarrer.


Pour résoudre ce problème, il vous suffit de rajouter le paramètre manquant dans le fichier indiqué par le message d'erreur.

Messages d'erreurs possibles sur la vérification des démons spares (pour l'instant seulement le broker)

Un master désigne un démon spare qui n'existe pas


Erreur à cause de caractères interdits dans le nom d'un royaume

Lorsque le nom d'un royaume contient un ( ou plusieurs ) caractère( s ) interdits, deux logs nous annoncent quels sont ces caractères ( ", ', < et > ), le nom du royaume en erreur ainsi que le fichier et la ligne dont il vient.Si un démon master pointe vers un démon spare inconnu, on a l'erreur suivante:

Code Block
themeEmacs
[YYYY-MM-DD HH:MM:SS] ERROR  : [ arbiter-name ] [item::broker-master-bad-3] Cannot find a broker with Forbidden characters ", ', < or > found in the name of realm "broker-spare-unknown<France>" for the property "spare_daemon"

Un master et son spare n'ont pas les mêmes types de modules

Un démon master et son spare doivent avoir les mêmes types de modules (et dans le même nombre). En cas de non-respect de cette règle, on a l'erreur de configuration suivante:
Code Block
themeEmacs
"/etc/shinken/realms/france.cfg:7
[YYYY-MM-DD HH:MM:SS] ERROR  : [ arbiter-name ] Items in <France> is incorrect

Dans l'exemple, le royaume présent dans le fichier /etc/shinken/realms/france.cfg possède le nom <france> qui contient des caractères interdits. ( < et > ).

Chemin des fichiers mal défini dans le fichier shinken.cfg

Si la définition des champs cfg_file ou cfg_dir donne des chemins de fichiers qui n'existe pas, on aura l'erreur suivante

Code Block
themeEmacs
[YYYY-MM-DD HH:MM:SS] ERROR  : [ arbiter-name ] [config] cannot open config file '/etc/shinken-user/configuration/daemons/arbiters/arbiter_cfg_overload_error.cfg' for reading: [Errno 2] No such file or directory: u'/etc/shinken-user/configuration/daemons/arbiters/arbiter_cfg_overload_error.cfg'

Messages d'erreurs possibles sur la vérification des démons spares ( Seulement le Broker, pour lequel on doit nommer le spare )

Un master désigne un démon spare qui n'existe pas

Si un démon master pointe vers un démon spare inconnu, on a l'erreur suivante:

Code Block
themeEmacs
[YYYY-MM-DD HH:MM:SS] ERROR : [ arbiter-name ] [item::broker-master-bad-3] Cannot find a broker with the name "broker-spare-unknown" for the property "spare_daemon"

Un master et son spare n'ont pas les mêmes types de modules

Un démon master et son spare doivent avoir les mêmes types de modules ( et dans le même nombre ).

En cas de non-respect de cette règle, on a l'erreur de configuration suivante:

Code Block
themeEmacs
  ]        [ SPARE MODULE NOT MATCHING ] The Broker master "broker-master-bad-4" and its spare "broker-spare-bad-4" do not have the same types of modules (cf "module_type" property in the .cfg):
[YYYY-MM-DD HH:MM:SS] ERROR  : [arbiter        ]        [ SPARE MODULE NOT MATCHING ]  +-------------+--------------------------------+------------------------------+
[YYYY-MM-DD HH:MM:SS] ERROR  : [ arbiter        -name ]        [ SPARE MODULE NOT MATCHING ] The |Broker Module type | Master [ master "broker-master-bad-4" ]and |its Sparespare [ "broker-spare-bad-4 ] |" do not have the same types of modules (cf "module_type" property in the .cfg):
[YYYY-MM-DD HH:MM:SS] ERROR  : [ arbiter        -name ]        [ SPARE MODULE NOT MATCHING ]  +-------------+--------------------------------+------------------------------+
[YYYY-MM-DD HH:MM:SS] ERROR  : [arbiter         arbiter-name ]        [ SPARE MODULE NOT MATCHING ]  | slaModule type | Master [     broker-master-bad-4 ] | Spare [ broker-spare-bad-4 ] |
[YYYY-MM-DD HH:MM:SS] ERROR  : [ arbiter-name ]   1                |              0               |
[YYYY-MM-DD HH:MM:SS] ERROR  : [arbiter        ]        [ SPARE MODULE NOT MATCHING ]  +-------------+--------------------------------+------------------------------+

Si deux démons masters pointent vers un même spare

On a alors l'erreur suivante:

Code Block
themeEmacs

[YYYY-MM-DD HH:MM:SS] ERROR  : [ arbiter-name ]        [ TWOSPARE MASTERSMODULE FORNOT ONEMATCHING SLAVE ] 2 daemons (broker-master-bad-1, broker-master-bad-2) have "broker-spare-bad-1" as spare_daemon. A daemon can be the spare of only one other.

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, vous aurez dans les logs l'entrée suivante:

Code Block
themeEmacs
[YYYY-MM-DD HH:MM:SS] WARNING : [ LOGGER ]
[YYYY-MM-DD HH:MM:SS] WARNING : [ LOGGER ] | sla         |               1                |              0               |
[YYYY-MM-DD HH:MM:SS] ERROR  : [ arbiter-name ]        [ SPARE MODULE NOT MATCHING ]  +-------------+--------------------------------+-------------------------------------------------+



Si deux démons masters pointent vers un même spare

On a alors l'erreur suivante:

Code Block
themeEmacs
-------------
[YYYY-MM-DD HH:MM:SS] WARNINGERROR : [ LOGGERarbiter-name ] [ WRITINGTWO ]MASTERS TheFOR logONE writeSLAVE time] is2 very highdaemons (broker-master-bad-1, broker-master-bad-2) have "broker-spare-bad-1" as spare_daemon. A daemon can be the spare of only one other.

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, vous aurez dans les logs l'entrée suivante:

Code Block
themeEmacs
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 ] ----------------------------------------------------------------------------------------------------
[YYYY-MM-DD HH:MM:SS] WARNING : [ LOGGER ]

Lancement de la phase d'envoi de la configuration de supervision, et de l'architecture aux autres démons

Phase de vérification initiale de l'architecture (INITIAL DAEMONS CHECK)

Une fois que l'Arbiter a compilé et vérifié la configuration de supervision, et l'architecture des démons, il passe dans la phase d'envoi. Pour cela, il va faire une première vérification de quels démons sont vivants/morts avant de commencer. Ces logs commencent par le bloc INITIAL DAEMONS CHECK.

Si un démon est vivant, il donnera une ligne suivante:

Code Block
themeEmacs
 [ WRITING ] The log writes time is very high (1.87s). Please look at your log disk performance.
[YYYY-MM-DD HH:MM:SS] INFOWARNING : [ arbiter-masterLOGGER ] [ scheduler-secondary ] [ INITIAL DAEMONS CHECK ] The daemon is ALIVE after initial daemon check, connection was OK----------------------------------------------------------------------------------------------------
[YYYY-MM-DD HH:MM:SS] WARNING : [ LOGGER ]

Lancement de la phase d'envoi de la configuration de supervision, et de l'architecture aux autres démons

Phase de vérification initiale de l'architecture (INITIAL DAEMONS CHECK)

Une fois que l'Arbiter a compilé et vérifié la configuration de supervision, et l'architecture des démons, il passe dans la phase d'envoi. Pour cela, il va faire une première vérification de quels démons sont vivants/morts avant de commencer. Ces logs commencent par le bloc INITIAL DAEMONS CHECK.

Si un démon est vivant, il donnera une ligne suivante:

Code Block
themeEmacs
[YYYY-MM-DD HH:MM:SS] INFO : [ arbiter-name ] [ scheduler-secondary ] [ INITIAL DAEMONS CHECK ] The daemon is ALIVE after initial daemon check, connection was OK

Si un démon est mort (n'a pas répondu pendant la période définie) alors on aura

Si un démon est mort (n'a pas répondu pendant la période définie) alors on aura:

Code Block
themeEmacs
[YYYY-MM-DD HH:MM:SS] ERROR  : [ arbiter-master  ]  [ scheduler-spare-bis    ] [ INITIAL DAEMONS CHECK  ] The daemon is set to DEAD after initial daemon check, port is closed: "Connexion error to http://localhost:10768/ : Failed connect to localhost:10768; Connection refused"

Cette phase se termine par la ligne de log suivante:

Code Block
themeEmacs
[YYYY-MM-DD HH:MM:SS] ERROR INFO : [ arbiter-master-name ]  [ scheduler-spare-bis    ] [ INITIAL DAEMONS CHECK  ] The daemon is set to DEAD after initial daemonsdaemon check, didport finishis in: 0.233sclosed: "Connexion error to http://localhost:10768/ : Failed connect to localhost:10768; Connection refused"

Cette phase se termine par la ligne de log suivante:

Code Block
themeEmacs
[YYYY-MM-DD HH:MM:SS] INFO : [ arbiter-name ] [ INITIAL DAEMONS CHECK ] The initial daemons check did finish in: 0.233s

Listing initial des démons de

Listing initial des démons de

l'architecture, et des royaumes qu'ils gèrent (DISPATCH)

Avant de procéder à la phase d'envoi, l'Arbiter va lister les différents démons présents dans l'architecture avec comme information:

  • le type du démon
  • son nom
  • s'il est vivant (ALIVE) ou mort (DEAD)
  • s'il est spare, et dans le cas du Broker qui/de qui il est spare
  • s'il gère les sous royaumes ou pas (paramètre manage_sub_realms des .cfg)
  • la liste des royaumes auquel il va se connecter

Ceci donne par exemple:

Code Block
themeEmacs
[YYYY-MM-DD HH:MM:SS] INFO   : [ arbiter-mastername  ]  [ REALM: All             ] [ DISPATCH ]   ==== Daemons listing of Realm All ====
[YYYY-MM-DD HH:MM:SS] INFO   : [ arbiter-mastername  ]  [ REALM: All             ] [ DISPATCH ]                          +-------------+----------------------+-------+--------------------------+-------------------+----------------+---------------------------+
[YYYY-MM-DD HH:MM:SS] INFO   : [ arbiter-master name ]  [ REALM: All             ] [ DISPATCH ]                          | Type        | Name                 | Ping  | Spare                    | Manage sub realms | Used in realms | Link to schedulers/shards |
[YYYY-MM-DD HH:MM:SS] INFO   : [ arbiter-master name ]  [ REALM: All             ] [ DISPATCH ]                          +-------------+----------------------+-------+--------------------------+-------------------+----------------+---------------------------+
[YYYY-MM-DD HH:MM:SS] INFO   : [ arbiter-master name ]  [ REALM: All             ] [ DISPATCH ]                          | Broker      | broker-master        | ALIVE | spare=>broker-spare      | True              | All            | No schedulers             |
[YYYY-MM-DD HH:MM:SS] INFO   : [ arbiter-master name ]  [ REALM: All             ] [ DISPATCH ]                          +-------------+----------------------+-------+--------------------------+-------------------+----------------+---------------------------+
[YYYY-MM-DD HH:MM:SS] INFO   : [ arbiter-mastername  ]  [ REALM: All             ] [ DISPATCH ]                          | Broker      | broker-spare-useless | ALIVE | UNUSED SPARE             | True              | All            | No schedulers             |
[YYYY-MM-DD HH:MM:SS] INFO   : [ arbiter-mastername  ]  [ REALM: All             ] [ DISPATCH ]                          +-------------+----------------------+-------+--------------------------+-------------------+----------------+---------------------------+
[YYYY-MM-DD HH:MM:SS] INFO   : [ arbiter-mastername  ]  [ REALM: All             ] [ DISPATCH ]                          | Broker      | broker-spare         | ALIVE | spare for=>broker-master | True              | All            | No schedulers             |
[YYYY-MM-DD HH:MM:SS] INFO   : [ arbiter-master name ]  [ REALM: All             ] [ DISPATCH ]                          +-------------+----------------------+-------+--------------------------+-------------------+----------------+---------------------------+
[YYYY-MM-DD HH:MM:SS] INFO   : [ arbiter-master name ]  [ REALM: All             ] [ DISPATCH ]                          | Broker      | broker-secondary     | ALIVE |                          | True              | All            | No schedulers             |
[YYYY-MM-DD HH:MM:SS] INFO   : [ arbiter-mastername  ]  [ REALM: All             ] [ DISPATCH ]                          +-------------+----------------------+-------+--------------------------+-------------------+----------------+---------------------------+
[YYYY-MM-DD HH:MM:SS] INFO   : [ arbiter-mastername  ]  [ REALM: All             ] [ DISPATCH ]                          | Poller      | poller-master        | ALIVE |                          | False             | All            | No schedulers             |
[YYYY-MM-DD HH:MM:SS] INFO   : [ arbiter-master name ]  [ REALM: All             ] [ DISPATCH ]                          +-------------+----------------------+-------+--------------------------+-------------------+----------------+---------------------------+
[YYYY-MM-DD HH:MM:SS] INFO   : [ arbiter-master name ]  [ REALM: All             ] [ DISPATCH ]                          | Reactionner | reactionner-master   | ALIVE |                          | False             | All            | No schedulers             |
[YYYY-MM-DD HH:MM:SS] INFO   : [ arbiter-mastername  ]  [ REALM: All             ] [ DISPATCH ]                          +-------------+----------------------+-------+--------------------------+-------------------+----------------+---------------------------+
[YYYY-MM-DD HH:MM:SS] INFO   : [ arbiter-master name ]  [ REALM: All             ] [ DISPATCH ]                          | Receiver    | receiver-master      | ALIVE |                          | True              | All            | No schedulers             |
[YYYY-MM-DD HH:MM:SS] INFO   : [ arbiter-mastername  ]  [ REALM: All             ] [ DISPATCH ]                          +-------------+----------------------+-------+--------------------------+-------------------+----------------+---------------------------+
[YYYY-MM-DD HH:MM:SS] INFO   : [ arbiter-mastername  ]  [ REALM: All             ] [ DISPATCH ]                          +---------------+---------------------+-------+-------+---------------+
[YYYY-MM-DD HH:MM:SS] INFO   : [ arbiter-master name ]  [ REALM: All             ] [ DISPATCH ]                          | State         | Name                | Ping  | Spare | Managed shard |
[YYYY-MM-DD HH:MM:SS] INFO   : [ arbiter-mastername  ]  [ REALM: All             ] [ DISPATCH ]                          +---------------+---------------------+-------+-------+---------------+
[YYYY-MM-DD HH:MM:SS] INFO   : [ arbiter-master name ]  [ REALM: All             ] [ DISPATCH ]                          | WAITING SPARE | scheduler-spare     | ALIVE | SPARE | no shard      |
[YYYY-MM-DD HH:MM:SS] INFO   : [ arbiter-master name ]  [ REALM: All             ] [ DISPATCH ]                          +---------------+---------------------+-------+-------+---------------+
[YYYY-MM-DD HH:MM:SS] INFO   : [ arbiter-mastername  ]  [ REALM: All             ] [ DISPATCH ]                          | WAITING SPARE | scheduler-spare-bis | ALIVE | SPARE | no shard      |
[YYYY-MM-DD HH:MM:SS] INFO   : [ arbiter-mastername  ]  [ REALM: All             ] [ DISPATCH ]                          +---------------+---------------------+-------+-------+---------------+

Chargement des broks initiaux par les modules Webui et Livestatus (regenerators) 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, les Schedulers jusqu'aux interfaces : webui / livestatus / livedata

Il existe 2 types de configuration_incarnation (représentation de la configuration) :

  • configuration_incarnation: id de configuration totale générée par l'Arbiter
  • part_configuration_incarnation: l'id de la partie de configuration gérée par un Scheduler

Quand l'Arbiter commence à donner sa configuration aux autres démons 

Code Block
themeEmacs
[2020YYYY-05MM-15DD 10HH:00MM:52SS] INFO : [ arbiter-name ] Begin to dispatch configurations [configuration: uuid=configuration_uuid date=creation_date author=arbiter_name ] to satellites
  • configuration_uuid:  uuid créé 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


Code Block
themeEmacs
titleExemple Arbiter
[YYYY-MM-DD HH:MM:SS] INFO   : [ arbiter-name ] Begin to dispatch configurations [configuration: uuid=a3a87842977a4255983db11cb46c2d87 date=15-05-2020 10:00:07 author=arbiter-master1] to satellites

L'Arbiter commence à envoyer les configurations aux Schedulers

Quand l'Arbiter commence à envoyer les configurations vers les Schedulers il va donner:

  • La liste des Schedulers des Schedulers MORTS (qui n'ont pas réussi à répondre à plus de max_retry pings).
  • La liste des Schedulers des Schedulers qui vont être contactés ce tour-ci pour avoir la configuration.
  • La liste des Schedulers en trop qui ne seront pas contactés tant que les précédents ne sont pas déclarés MORTS.


Code Block
themeEmacs
[YYYY-MM-DD HH:MM:SS] INFO : [ arbiter-mastername ] [DISPATCH][All] Dispatching 1 shards (total in realm=1) to schedulers
[YYYY-MM-DD HH:MM:SS] INFO : [ arbiter-mastername ] [DISPATCH][All] 1 Shards will be dispatched to 1 schedulers in this order: scheduler-master (realm=All, spare=False)
[YYYY-MM-DD HH:MM:SS] INFO : [ arbiter-mastername ] [DISPATCH][All] 1 schedulers are alive but will be used only when non spare schedulers will be DEAD: scheduler-sapre (realm=All, spare=True)


Avant et après l'envoi, l'Arbiter va afficher un état des Schedulers dans le royaume, afin de voir quels Schedulers gèrent quel shard.

  • Avant l'envoi il y aura un tag BEFORE DISPATCH
  • Après l'envoi ce sera AFTER DISPATCH
Code Block
themeEmacs
[YYYY-MM-DD HH:MM:SS] INFO   : [ arbiter-mastername  ]  [ REALM: All             ] [ DISPATCH ] AFTER DISPATCH =>        +---------------+---------------------+-------+-------+---------------+
[YYYY-MM-DD HH:MM:SS] INFO   : [ arbiter-master name ]  [ REALM: All             ] [ DISPATCH ] AFTER DISPATCH =>        | State         | Name                | Ping  | Spare | Managed shard |
[YYYY-MM-DD HH:MM:SS] INFO   : [ arbiter-master name ]  [ REALM: All             ] [ DISPATCH ] AFTER DISPATCH =>        +---------------+---------------------+-------+-------+---------------+
[YYYY-MM-DD HH:MM:SS] INFO   : [ arbiter-mastername  ]  [ REALM: All             ] [ DISPATCH ] AFTER DISPATCH =>        | WORKING       | scheduler-master    | ALIVE |       | 256           |
[YYYY-MM-DD HH:MM:SS] INFO   : [ arbiter-mastername  ]  [ REALM: All             ] [ DISPATCH ] AFTER DISPATCH =>        +---------------+---------------------+-------+-------+---------------+
[YYYY-MM-DD HH:MM:SS] INFO   : [ arbiter-master name ]  [ REALM: All             ] [ DISPATCH ] AFTER DISPATCH =>        | WORKING       | scheduler-secondary | ALIVE |       | 257           |
[YYYY-MM-DD HH:MM:SS] INFO   : [ arbiter-master name ]  [ REALM: All             ] [ DISPATCH ] AFTER DISPATCH =>        +---------------+---------------------+-------+-------+---------------+
[YYYY-MM-DD HH:MM:SS] INFO   : [ arbiter-master name ]  [ REALM: All             ] [ DISPATCH ] AFTER DISPATCH =>        | DEAD          | scheduler-spare-bis | DEAD  | SPARE | no shard      |
[YYYY-MM-DD HH:MM:SS] INFO   : [ arbiter-master name ]  [ REALM: All             ] [ DISPATCH ] AFTER DISPATCH =>        +---------------+---------------------+-------+-------+---------------+
[YYYY-MM-DD HH:MM:SS] INFO   : [ arbiter-mastername  ]  [ REALM: All             ] [ DISPATCH ] AFTER DISPATCH =>        | WAITING SPARE | scheduler-spare     | ALIVE | SPARE | no shard      |
[YYYY-MM-DD HH:MM:SS] INFO   : [ arbiter-mastername  ]  [ REALM: All             ] [ DISPATCH ] AFTER DISPATCH =>        +---------------+---------------------+-------+-------+---------------+

Les différents états sont:

  • AVAILABLE => le Scheduler est disponible pour avoir un shard
  • DEAD => le Scheduler est déclaré mort, un spare va prendre son shard
  • WAITING SPARE => c'est un spare qui ne travaille pas pour l'instant
  • WORKING => c'est un Scheduler (spare ou pas) qui gère une shard et travaille

L'Arbiter pousse la configuration d'un Scheduler ( avec ses hôtes, checks, et modules )

La configuration d'un Scheduler se décompose en plusieurs informations:

  • Les hôtes, checks et cluster qu'il gère (nommé "shard" dans les logs)
  • Les autres démons qu'il doit contacter si besoin (par exemple Poller ou Reactionner passifs)
  • Des informations diverses comme son nom et ses modules


Quand l'Arbiter lui envoie ces informations, on a ceci dans les logs:

Code Block
themeEmacs
[YYYY-MM-DD HH:MM:SS] INFO : [ arbiter-mastername  ]  [ scheduler-master       ] [ DISPATCH TO SCHEDULER  ] [ CONFIGURATION          ] SHARD ASSIGNED TO SCHEDULER   Shard [256/[configuration_uuid=aab163e2ecc34b428e812f70d9497628, arbiter=arbiter-master, date=22-10-2020 13:30:23]] is sent to scheduler, done in 0.09s (size=0.146MB speed=1.696MB/s)


Ici l'Arbiter a mis 0.09s pour envoyer un shard numéro 256 qui fait 146Ko au scheduler scheduler-master.

L'arbiter donne l'information du nouveau Scheduler aux autres démons ( Pollers, Reactionners, Brokers et Receivers )

Une fois qu'un Scheduler s'est vu assigner un shard, l'Arbiter va prévenir les autres démons (broker, Poller, Reactionner et Receiver) qu'il faut aller s'y connecter. De même si un Scheduler tombe et qu'il faut alors que ces mêmes démons passent sur le Scheduler spare.

L'Arbiter va afficher ces lignes de logs:

La première fois qu'il va contacter un démon, il va le mettre à jour en termes de configuration d'architecture (numéro de configuration, spare/non spare, liste de modules, etc.);

Code Block
themeEmacs
[YYYY-MM-DD HH:MM:SS] INFO   : [ arbiter-master name ]  [ reactionner-master     ] [ DISPATCH TO REACTIONNER ] [ CONFIGURATION          ] SATELLITE SENT OK  The daemon is now updateupdated to the new configuration incarnation ([configuration_uuid=060e70dfeb204a61be70f75c0622e118, arbiter=arbiter-master, date=20-10-2020 15:37:27])

Et ensuite pour chaque shard assigné, on aura:

Code Block
themeEmacs
[YYYY-MM-DD HH:MM:SS] INFO   : [ arbiter-master name ]  [ reactionner-master     ] [ DISPATCH TO REACTIONNER ] [ CONFIGURATION          ] SATELLITE SENT OK  Dispatch OK of shard assignation [256 => scheduler-master    ] to the reactionner

Ici le Reactionner reactionner-master s'est vu assigné le lien "shard 256"→ scheduler-master.


De même que pour le Scheduler, l'Arbiter va afficher un tableau avant et après mise à jour de l'architecture sur les démons, montrant vers qui pointent les différents démons du royaume:

Code Block
themeEmacs
[YYYY-MM-DD HH:MM:SS] INFO   : [ arbiter-mastername  ]  [ REALM: All             ] [ DISPATCH ] AFTER DISPATCH =>        +-------------+----------------------+-------+--------------------------+-------------------+----------------+-----------------------------------------------+
[YYYY-MM-DD HH:MM:SS] INFO   : [ arbiter-mastername  ]  [ REALM: All             ] [ DISPATCH ] AFTER DISPATCH =>        | Type        | Name                 | Ping  | Spare                    | Manage sub realms | Used in realms | Link to schedulers/shards                     |
[YYYY-MM-DD HH:MM:SS] INFO   : [ arbiter-mastername  ]  [ REALM: All             ] [ DISPATCH ] AFTER DISPATCH =>        +-------------+----------------------+-------+--------------------------+-------------------+----------------+-----------------------------------------------+
[YYYY-MM-DD HH:MM:SS] INFO   : [ arbiter-master name ]  [ REALM: All             ] [ DISPATCH ] AFTER DISPATCH =>        | Broker      | broker-master        | ALIVE | spare=>broker-spare      | True              | All            | scheduler-master/256, scheduler-secondary/257 |
[YYYY-MM-DD HH:MM:SS] INFO   : [ arbiter-master name ]  [ REALM: All             ] [ DISPATCH ] AFTER DISPATCH =>        +-------------+----------------------+-------+--------------------------+-------------------+----------------+-----------------------------------------------+
[YYYY-MM-DD HH:MM:SS] INFO   : [ arbiter-mastername  ]  [ REALM: All             ] [ DISPATCH ] AFTER DISPATCH =>        | Broker      | broker-spare-useless | ALIVE | UNUSED SPARE             | True              | All            | No schedulers                                 |
[YYYY-MM-DD HH:MM:SS] INFO   : [ arbiter-master name ]  [ REALM: All             ] [ DISPATCH ] AFTER DISPATCH =>        +-------------+----------------------+-------+--------------------------+-------------------+----------------+-----------------------------------------------+
[YYYY-MM-DD HH:MM:SS] INFO   : [ arbiter-master name ]  [ REALM: All             ] [ DISPATCH ] AFTER DISPATCH =>        | Broker      | broker-spare         | ALIVE | spare for=>broker-master | True              | All            | No schedulers                                 |
[YYYY-MM-DD HH:MM:SS] INFO   : [ arbiter-master name ]  [ REALM: All             ] [ DISPATCH ] AFTER DISPATCH =>        +-------------+----------------------+-------+--------------------------+-------------------+----------------+-----------------------------------------------+
[YYYY-MM-DD HH:MM:SS] INFO   : [ arbiter-mastername  ]  [ REALM: All             ] [ DISPATCH ] AFTER DISPATCH =>        | Broker      | broker-secondary     | ALIVE |                          | True              | All            | scheduler-master/256, scheduler-secondary/257 |
[YYYY-MM-DD HH:MM:SS] INFO   : [ arbiter-master name ]  [ REALM: All             ] [ DISPATCH ] AFTER DISPATCH =>        +-------------+----------------------+-------+--------------------------+-------------------+----------------+-----------------------------------------------+
[YYYY-MM-DD HH:MM:SS] INFO   : [ arbiter-master name ]  [ REALM: All             ] [ DISPATCH ] AFTER DISPATCH =>        | Poller      | poller-master        | ALIVE |                          | False             | All            | scheduler-master/256, scheduler-secondary/257 |
[YYYY-MM-DD HH:MM:SS] INFO   : [ arbiter-master name ]  [ REALM: All             ] [ DISPATCH ] AFTER DISPATCH =>        +-------------+----------------------+-------+--------------------------+-------------------+----------------+-----------------------------------------------+
[YYYY-MM-DD HH:MM:SS] INFO   : [ arbiter-master name ]  [ REALM: All             ] [ DISPATCH ] AFTER DISPATCH =>        | Reactionner | reactionner-master   | ALIVE |                          | False             | All            | scheduler-master/256, scheduler-secondary/257 |
[YYYY-MM-DD HH:MM:SS] INFO   : [ arbiter-mastername  ]  [ REALM: All             ] [ DISPATCH ] AFTER DISPATCH =>        +-------------+----------------------+-------+--------------------------+-------------------+----------------+-----------------------------------------------+
[YYYY-MM-DD HH:MM:SS] INFO   : [ arbiter-mastername  ]  [ REALM: All             ] [ DISPATCH ] AFTER DISPATCH =>        | Receiver    | receiver-master      | ALIVE |                          | True              | All            | scheduler-master/256, scheduler-secondary/257 |
[YYYY-MM-DD HH:MM:SS] INFO   : [ arbiter-master name ]  [ REALM: All             ] [ DISPATCH ] AFTER DISPATCH =>        +-------------+----------------------+-------+--------------------------+-------------------+----------------+-----------------------------------------------+

L'Arbiter enlève un lien vers un Scheduler qui a été supprimé/désactivé

Quand l'Arbiter s'apperçoit qu'un poller/reactionner/broker/receiver possède un lien vers un schedduler qui n'existe plus, il lui demande de le supprimer, avec une entrée log suivante:

Code Block
themeEmacs
[YYYY-MM-DD HH:MM:SS] INFO   : [ arbiter-master  ] [ receiver-master        ] [ DISPATCH TO RECEIVER   ] [ CONFIGURATION          ] [ DELETE / DISABLED SCHEDULER ] The scheduler "scheduler-secondary" is removed as it is no more used ( old scheduler managing the shard=257 that was either deleted or disabled ).--------------+

L'Arbiter enlève un lien vers un Scheduler

L'Arbiter désactive un démon

qui a été supprimé/désactivé

En plus d'enlever un démon supprimé/désactivé des autres démons, l'Arbiter va également se connecter à ce dernier pour lui demander d'arréter de travaille et se remettre en état d'attente. Ainsi, si on le remets dans la configuration, il sera prêt à travailler.

On aura dans les logs deux lignes pour chaque démon qu'on désactive de la sorte:

Il a identifié un tel démonQuand l'Arbiter s'aperçoit qu'un Poller/Reactionner/Broker/Receiver possède un lien vers un Scheduler qui n'existe plus, il lui demande de le supprimer, avec une entrée log suivant:

Code Block
themeEmacs
[YYYY-MM-DD HH:MM:SS] INFO   : [ arbiter-name ] [ receiver-master        ] [ DISPATCH TO RECEIVER   ] [ DO INACTIVE DELETED/DISABLED DAEMONSCONFIGURATION          ] [ DELETE / DISABLED SCHEDULER ] The schedulersscheduler "scheduler-secondary" is detectedremoved as disabled/deleted, and will be ask to go in inactive mode until we use it againit is no more used ( old scheduler managing the shard=257 that was either deleted or disabled ).

L'Arbiter désactive un démon qui a été supprimé/désactivé

En plus d'enlever un démon supprimé/désactivé des autres démons, l'Arbiter va également se connecter à ce dernier pour lui demander d'arrêter de travail et se remettre en état d'attente. Ainsi, si on le remet dans la configuration, il sera prêt à travailler.

On aura dans les logsIl a réussi à le désactiver:


Code Block
themeEmacs
[YYYY-MM-DD HH:MM:SS] INFO : [ arbiter-mastername ] [ DISPATCH ] [ DO INACTIVE DELETED/DISABLED DAEMONS ] SUCCESS The daemon "scheduler-secondary" [uri=http://localhost:8768/] was was set in inactive mode (sleep) until we are using it again.

Logs concernant l'envoi de la configuration de l'Arbiter master vers l'Arbiter spare - chapitre [ LATEST-MONITORING-CONFIGURATION ]

Intérêt et étapes de l'envoi de la configuration de l'Arbiter

master

MASTER vers l'Arbiter

spare

SPARE

L'

arbien

Arbiter spare devant être capable de reprendre la main en cas de faillite de l'Arbiter master, il lui faut la même configuration que ce dernier.

Pour cela:

Pour cela:

  • l'Arbiter master va lui envoyer dès qu'il démarre
  • il la sauvegarde localement dans un fichier ( le spare doit être capable d'être relancé sur la dernière configuration connue )
  • et il l'absorbe pour être prêt a démarré


Les différentes étapes de ce mécanisme sont:

  1. l'Arbiter master prépare cette configuration;
  2. l'Arbiter master
va lui envoyer dès qu'il démarre
  1. envoi cette configuration à l'Arbiter spare;
  2. l'Arbiter spare
va conserver
  1. réceptionne cette configuration
localement dans un fichier, car si
  1. ;
  2. l'Arbiter spare sauvegarde la configuration dans un fichier local;
  3. l'Arbiter spare charge la configuration et se tient prêt dans le cas où l'Arbiter master ne
démarre plus, le sapre doit être capable de redémarrer sur la dernière configuration connue

Les différentes étapes de ce mécanisme sont:

  1. l'Arbiter master prépare cette configuration
  2. l'Arbiter master envoi cette configuration à l'Arbiter spare
  3. l'Arbiter spare réceptionne cette configuration
  4. l'Arbiter spare sauvegarde la configiration dans un fichier local
  5. l'Arbiter spare charge la configuration et se tient prêt dans le cas où l'Arbiter master ne lui parle plus
  6. (suite à un redémarrage de l'Arbiter spare) l'Arbiter spare recharge la dernière configuration reçue de l'Arbiter master
  1. lui parle plus;
  2. Dans le cas d'un redémarrage de l'Arbiter spare, ce dernier recharge la dernière configuration reçue de l'Arbiter master.

draw.io Diagram
bordertrue
diagramNameEnvoi Arbiter MASTER to SPARE
simpleViewerfalse
width
linksauto
tbstyletop
lboxtrue
diagramWidth521
revision1

ETAPE 1: l'Arbiter MASTER prépare la configuration qu'il va envoyer à l'Arbiter SPARE

(tick)  L'Arbiter master va sérialiser sa configuration avant de l'envoyer à l'Arbiter spare.


Code Block
themeEmacs
[YYYY-MM-DD HH:MM:SS] INFO : [ arbiter-name ] [ CONFIGURATION ] [ LATEST-MONITORING-CONFIGURATION ] The NEW Monitoring Configuration was generated in: 0.10s, size: 0.485MB [configuration_uuid=c094ca56e1bc438e968349742caa10a4, arbiter=arbiter-master, date=13-01-2021 15:43:47]

ETAPE 2: l'Arbiter MASTER envoi la configuration à l'Arbiter SPARE

(tick)  Quand l'Arbiter master envoi la configuration à l'Arbiter spare, il met dans ses logs:

ETAPE 1: l'Arbiter master prépare la configuration qu'il va envoyer à l'Arbiter spare

(tick)  L'Arbiter master va sérialiser sa configuration avant de l'envoyer à l'Arbiter spare.

Info
titleATTENTION
Cette opération est malheureusement faite alors que l'Arbiter master n'a pas encore son log, on a donc pas encore l'entrée dans les log de l'arbiter.

Code Block
themeEmacs
[YYYY-MM-DD HH:MM:SS] INFO : [ arbiter-mastername ] [ CONFIGURATION ] [ LASTLATEST-ARBITER-MASTERMONITORING-CONFIGURATION ] The Arbiter master configuration was done in: 0.10s and Sending the NEW Monitoring Configuration to the configurationArbiter size is 0.485MB

ETAPE 2: l'Arbiter master envoi la configuration à l'Arbiter spare

SPARE "arbiter-spare"
(tick) 

Quand l'

Arbiter master envoi la configuration à l'Arbiter spare, il met dans ses

envoi est réussi, on aura dans les logs:

Code Block
themeEmacs
[YYYY-MM-DD HH:MM:SS] INFO : [ arbiter-mastername ] [ CONFIGURATION ] [ LASTLATEST-ARBITERMONITORING-MASTER-CONFIGURATION ] SendingThe theNEW ArbiterMonitoring master configurationConfiguration to the arbiterArbiter spareSPARE "arbiter-spare" ( size=0.485MB ) was sent in 0.051s

2.1 En cas d'erreur lors de l'envoi vers l'Arbiter

spare

SPARE

(error)  Si l'Arbiter master MASTER n'arrive pas à envoyer la configuration à l'Arbiter spare SPARE ( problème de connexion ou autre ), alors on aura dans les logs:les logs, mentionnant les informations d'identification de la configuration ( Configuration_uuid, nom de l'arbiter, date de création ).


Code Block
themeEmacs
[YYYY-MM-DD HH:MM:SS] ERROR : [ arbiter-mastername ] [ CONFIGURATION ] [ LASTLATEST-ARBITERMONITORING-MASTER-CONFIGURATION ] Fail to send the arbiterNEW masterMonitoring configurationConfiguration [configuration_uuid=c094ca56e1bc438e968349742caa10a4, arbiter=arbiter-master, date=13-01-2021 15:43:47] to the arbiterArbiter spareSPARE "arbiter-spare". We wilwill retry later.

ETAPE 3: l'Arbiter

spare

SPARE réceptionne la configuration

(tick)  Quand l'arbiter spare reçoit la configuration de l'arbiter master, il va logguer la réception, avec le plus important: l'incarnation de la configuration.master, il va logguer la réception.

Code Block
themeEmacs
[YYYY-MM-DD HH:MM:SS] INFO : [ arbiter-name ] [ CONFIGURATION ] [ LATEST-MONITORING-CONFIGURATION ] The NEW Arbiter MASTER send us the configuration: [configuration_uuid=c094ca56e1bc438e968349742caa10a4, Arbiter=arbiter-master, date=13-01-2021 15:43:47]


(tick) Une fois validée, il va le logger:

Code Block
themeEmacs
[YYYY-MM-DD HH:MM:SS] INFO : [ arbiter-sparename ] [ CONFIGURATION ] [ LASTLATEST-ARBITERMONITORING-MASTER-CONFIGURATION ] The arbiterNEW master send us the configuration: Monitoring Configuration [configuration_uuid=c094ca56e1bc438e968349742caa10a4, arbiterArbiter=arbiter-master, date=13-01-2021 15:43:47]
(coche) Une fois validée, il va le logger
 received from "arbiter-master" is valid

3.1 l'Arbiter MASTER n'est pas à jour par rapport à l'Arbiter spare

(error) Dans le cas où l'Arbiter MASTER n'est pas dans la même version que l'Arbiter SPARE, et que l'option *mismatch_version_error* est activé, ce dernier refusera de valider la configuration et lèvera une erreur:

Code Block
themeEmacs
[YYYY-MM-DD HH:MM:SS] INFOERROR : [ arbiter-spare ] [ CONFIGURATION name ] [ LASTLATEST-ARBITER-MASTERMONITORING-CONFIGURATION ] The arbiterArbiter masterMASTER configuration [configuration_uuid=c094ca56e1bc438e968349742caa10a4, arbiter=arbiter-master, date=13-01-2021 15:43:47] received from "arbiter-master" is valid

3.1 l'Arbiter master n'est pas à jour par rapport à l'Arbiter spare

Version ( VXX.XX.XX patch-cumulatif-XX ) is different from the Arbiter SPARE version ( VXX.XX.XX patch-cumulatif-XX ). The NEW Monitoring Configuration can't be loaded.

(warning) Dans le cas où l'Arbiter MASTER n'est pas dans la même version que l'Arbiter SPARE, et que l'option *mismatch_version_error* est désactivé

(error)  Dans le cas improbable où l'Arbiter master est plus vieux que l'Arbiter spare, ce dernier refusera de valider la configuration et lèvera une erreur

:

Code Block
themeEmacs
[YYYY-MM-DD HH:MM:SS] INFOWARNING : [ arbiter-sparename ] [ LASTLATEST-ARBITER-MASTERMONITORING-CONFIGURATION ] The configurationArbiter receivedMASTER fromVersion the arbiter master "arbiter-master"( VXX.XX.XX patch-cumulatif-XX ) is toodifferent old and cannot be loaded: from the Arbiter masterSPARE isversion too old and must be updated( VXX.XX.XX patch-cumulatif-XX ).

ETAPE 4: l'Arbiter

spare

SPARE sauvegarde la configuration dans un fichier local

(coche) (tick) Une fois validée, l'Arbiter spare SPARE va sauvegarder la configuration du master MASTER dans un ficheir fichier local, dans le cas où le spare devrait redémarrer dans le futur et que l'Arbiter master ne soit plus présent.

Code Block
themeEmacs
[YYYY-MM-DD HH:MM:SS] INFO : [ arbiter-sparename ] [ LASTLATEST-ARBITER-MASTERMONITORING-CONFIGURATION ] The configurationNEW Monitoring Configuration [configuration_uuid=f744101c332b4956a31e057794f9fb2f, arbiterArbiter=arbiter-master, date=30-03-2021 16:39:20] received from Arbiter masterMASTER "arbiter-master" [version=02.07.06-release_7_8.fr-Patched-07_B26] will be saved into file "/var/lib/shinken/arbiter_spare_last_conf.dat"

4.1 L'Arbiter

spare

SPARE n'arrive pas à écrire la configuration reçue de l'Arbiter

master

MASTER

(erreur) (error) Dans le cas où l'Arbiter spare SPARE n'arrive à écrire le fichier local, il aura une erreur:

Code Block
themeEmacs
[YYYY-MM-DD HH:MM:SS] ERROR : [ arbiter-sparename ] [ LASTLATEST-ARBITER-MASTERMONITORING-CONFIGURATION ] The configurationNEW Monitoring Configuration [configuration_uuid=f744101c332b4956a31e057794f9fb2f, arbiterArbiter=arbiter-master, date=30-03-2021 16:39:20] received from Arbiter masterMASTER "arbiter-master" [version=02.07.06-release_7_8.fr-Patched-07_B26] failed to save in file "/var/lib/shinken/arbiter_spare_last_conf.dat" because of a system error: no space left on device

ETAPE 5: l'Arbiter

spare

SPARE charge la configuration et se tient prêt dans le cas où l'Arbiter MASTER ne lui parle plus

(tick) Quand l'arbiter spare Arbiter SPARE a fini de charger la configuration du masterMASTER, il va afficher ce message:

Code Block
themeEmacs
[YYYY-MM-DD HH:MM:SS] INFO   : [ arbiter-sparename   ] [ CONFIGURATION ] [ LASTLATEST-ARBITER-MASTERMONITORING-CONFIGURATION ] The NEW configurationMonitoring incarnationConfiguration is loaded from the last Arbiter masterMASTER configuration. New incarnation: [configuration_uuid=8c7eb40b387743688f70a566a85f4b91, arbiterArbiter=arbiter-master, date=30-03-2021 10:04:35]

ETAPE 6:

(après

Dans le cas d'un redémarrage de l'Arbiter

spare) l'Arbiter spare

SPARE, ce dernier recharge la dernière configuration reçue de l'Arbiter

master

MASTER

Le chargement se passe bien

(tick) Quand l'Arbiter spare SPARE redémarre, il va charger la dernière configuration reçue de l'Arbiter master, ainsi, si l'Arbiter master ne redémarre jamais (s'il a pris feu par exemple) il pourra quand même déployer la configuration et faire son travailMASTER.

On aura un log quand on va tenter de lire le fichier:

Code Block
themeEmacs
[YYYY-MM-DD HH:MM:SS] INFO : [ arbiter-sparename ] [ CONFIGURATION ] [ LASTLATEST-ARBITER-MASTERMONITORING-CONFIGURATION ] Trying to reload the lastLATEST ArbiterMonitoring masterConfiguration configuration from file "/var/lib/shinken/arbiter_spare_last_conf.dat"

Quand on aura chargé la configuration, on aura la ligne suivante signifiant que le chargement s'est bien passé, et que le spare va désormais attendre d'avoir une nouvelle configuration de la part du master, ou bien prendre la main avec cette configuration chargée.

Code Block
themeEclipseEmacs
[YYYY-MM-DD HH:MM:SS] INFO : [ arbiter-sparename ] [ CONFIGURATION ] [ LASTLATEST-ARBITER-MASTERMONITORING-CONFIGURATION ] Using the lastLATEST ArbiterMonitoring master configurationConfiguration [configuration_uuid=f744101c332b4956a31e057794f9fb2f, arbiterArbiter=arbiter-master, date=30-03-2021 16:39:20] loaded from file "/var/lib/shinken/arbiter_spare_last_conf.dat", using it until we do receive a new one from the Arbiter master

6.1 L'Arbiter spare n'arrive pas à ouvrir le fichier de la dernière configuration à cause d'un problème système (droit ou autre) ou que le fichier n'a pas le bon format

Problème au chargement de la dernière configuration 
Le fichier ne peut être ouvert
(error) (erreur) Si le fichier /var/lib/shinken/arbiter_spare_last_conf.dat a un problème de droit, ou pas le bon format, on aura l'erreur suivante :
 Code Block
themeEclipseEmacs
[YYYY-MM-DD HH:MM:SS] INFO : [ arbiter-sparename ] [ CONFIGURATION ] [ LASTLATEST-ARBITER-MASTERMONITORING-CONFIGURATION ] Failed to load the last ArbiterMonitoring masterConfiguration configuration '"/var/lib/shinken/arbiter_spare_last_conf.dat'", because of a file error: void file
Le spare attendra alors une nouvelle configuration du master, qui lui fournira la configuration en cours.
Le fichier 
6.2 L'arbiter spare refuse de charger le fichier de la dernière configuration si elle 
 correspond à une autre version 
 que la sienne
de shinken
(error) (erreur) L'Arbiter spare SPARE refuse de charger une configuration qui ne corresponds correspond pas à sa version (patch inclu), car elle pourrait avoir des problèmes avec les données de la configuration qui ne seront pas à jour. 
 Info(warning) Il faut donc que suite à une mise à jour l'Arbiter master se connecte au moins une fois à l'Arbiter spare
Le spare attendra alors une nouvelle configuration du master.

On aura dans les logs:
 Code Block
themeEmacs
[YYYY-MM-DD HH:MM:SS] ERROR : [ arbiter-sparename ] [ CONFIGURATION ] [ LASTLATEST-ARBITER-MASTERMONITORING-CONFIGURATION ] Failed to load the lastLATEST ArbiterMonitoring masterConfiguration configuration '"/var/lib/shinken/arbiter_spare_last_conf.dat'", the saved version ( [02.07.06-release_7_8.fr] ) doesn't match with my current version [( 02.07.06-release_7_8.fr-Patched-07_B26] )
Et alors l'Arbiter spare attendra la configuration de la part de l'Arbiter master.
6.3 L'Arbiter spare n'arrive pas à charger les 
Les données de la dernière configuration 
 de l'Arbier master
ne peuvent pas être chargées
(error) (erreur) Dans le cas où il y a un problème de chargement de la configuration (probalement dû  probablement dû à un problème de code ), le spare attendra alors une nouvelle configuration du master et on aura l'erreur suivante:
 Code Block
themeEmacs
[YYYY-MM-DD HH:MM:SS] ERROR : [ arbiter-sparename ] [ CONFIGURATION ] [ LASTLATEST-ARBITERMONITORING-MASTER-CONFIGURATION ] Failed to load the lastLATEST ArbiterMonitoring masterConfiguration configuration '"/var/lib/shinken/arbiter_spare_last_conf.dat'" because of some elements loading error: KeyError on element
Logs concernant la prise de pouvoir de l'Arbiter 
 spare 
SPARE quand l'Arbiter 
 master 
MASTER ne lui parle plus 
Logs de prise en main de 
- Chapitre [ WAIT-FOR-MASTER-DEATH ]
L'Arbiter SPARE se tiens prêt à écouter l'Arbiter 
 spare
MASTER
L'arbiter spare Arbiter SPARE va tout d'abord afficher dans ses logs le temps qu'il accepte pour ne pas entendre l'arbiter master Arbiter MASTER ( qui doit lui parler toutes les secondes en temps normal ), dans le log suivant:
 Code Block
themeEmacs
[YYYY-MM-DD HH:MM:SS] INFO : [ arbiter-spare ] I'll wait master for 66 secondsSS] INFO   : [ arbiter-name ] [ WAIT-FOR-MASTER-DEATH ] The Arbiter spare will wait for the Arbiter master for 66 seconds (= master check_interval=22s * master max_check_attempts=3) until take over the master role
Quand l'Arbiter SPARE n'a plus de nouvelles de l'Arbiter MASTER
Quand l'arbiter master ne parle plus à l'arbiter spare, ce dernier va commencer à se plaindre et prévenir qu'il va prendre la main sous peu:
 Code Block
themeEmacs
[
2021
YYYY-MM-DD HH:MM:SS] WARNING: [ arbiter-name ] [ WAIT-FOR-MASTER-DEATH ] Arbiter Master doesn't speak to me since 22s. I'll take the master role after 66 seconds.
L'Arbiter SPARE prends la main sur la configuration
01-13 15:49:55] WARNING: [ arbiter-spare ] Arbiter Master don't speak to me since 22s. I'll take the master role after 66 seconds.Quand enfin le temps est écouleécoulé, il prends prend la main:
 Code Block
themeEmacs
[YYYY-MM-DD HH:MM:SS] INFO   : [ arbiter-sparename ] [ WAIT-FOR-MASTER-DEATH ] --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
[YYYY-MM-DD HH:MM:SS] INFO   : [ arbiter-spare  name ] [ CONFIGURATION    WAIT-FOR-MASTER-DEATH ] Arbiter Master is dead. The arbiter arbiter-spare take themaster leadrole with the configuration [configuration_uuid=c094ca56e1bc438e968349742caa10a4, arbiter=arbiter-master, date=13-01-2021 15:43:47]
[YYYY-MM-DD HH:MM:SS] INFO   : [ arbiter-sparename ] [ WAIT-FOR-MASTER-DEATH ] --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
L'Arbiter 
 master 
MASTER reprends la main
Si le spare avait pris la main et que le master revient, ce dernier l'Arbiter master reprends automatiquement la main.
Du côté de l'arbiter spare ceci provoque dans les logs l'entrée suivante:
 Code Block
themeEmacs
[YYYY-MM-DD HH:MM:SS] INFO   : [ arbiter-sparename ] [ WAIT-FOR-MASTER-DEATH ] --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
[YYYY-MM-DD HH:MM:SS] INFO   : [ arbiter-spare  name ] [ CONFIGURATION    WAIT-FOR-MASTER-DEATH ] The arbiter master taketakes over the configuration [configuration_uuid=c094ca56e1bc438e968349742caa10a4, arbiter=arbiter-master, date=13-01-2021 15:43:47]. Switching back to sleep move
[YYYY-MM-DD HH:MM:SS] INFO   : [ arbiter-sparename ] [ WAIT-FOR-MASTER-DEATH ] --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Du côté de l'arbiter master, on va avoir la ligne de log suivante (seulement disponible en DEBUG pour l'instant):
 Code Block
themeEmacs
[YYYY-MM-DD HH:MM:SS] DEBUG  : [ arbiter-name ]  [ arbiter---------
Du côté de l'arbiter master, on va avoir la ligne de log suivante (seulement disponible en DEBUG pour l'instant)
spare          ] [ IS ALIVE CHECK         ] Ping of [arbiter-spare] [uri=http://localhost:8770/] => OK

Logs concernant un master contacté par une architecture en conflit pour devenir spare
Suite à une erreur de configuration, l'arbiter master de notre architecture est contacté par l'arbiter master d'une architecture en conflit pour devenir son spare.
Un arbiter master n'est pas supposé devenir spare d'une architecture, ce refus génère les logs suivants :
 Code Block
themeEmacs
[YYYY-MM-DD HH:MM:SS] DEBUGERROR  : [ arbiter-mastername  ]  [ arbiter-spareCONFIGURATION ] Another Arbiter try to send us a configuration, ]but [we ISare ALIVEa CHECKMASTER so we are refusing it.
[YYYY-MM-DD HH:MM:SS] ERROR  ]: Ping[ of [arbiter-sparename ] [uri=http://localhost:8770/] => OK
 CONFIGURATION ] Received message not to run. I am the Master, ignore and continue to run.
Logs concernant les commandes externes relayées par l'Arbiter
Logs de réception d'une commande externe ( reçue depuis un démon Broker ou Receiver )
L'Arbiter peux peut recevoir des commandes externes de plusieurs sources:
  • un de ses modules qui lui est rataché rattaché (genre ws-arbiter), mais c'est déconseillé, c'est le rôle du receiver de faire ça plutôt que l'Arbiter
  • un démon Broker qui a reçu la commande externe d'un de ses modules (genre WebUI ou Livestatus)
  • un démon receiver qui n'est pas en direct routing, ou bien qui renoit reçoit une commande globale au système, pour tous les schedulers
L'Arbiter affichera cette commande de la manière suivante:
 Code Block
themeEmacs
[YYYY-MM-DD HH:MM:SS] INFO : [ arbiter-mastername ] [BUS COMMAND]: [1613640917] SCHEDULE_FORCED_SVC_CHECK;myhost;HttpsCertificate;1613640917
Avec ici par exemple:
  • [1613640917]: epoch de réception de la commande (dans le 1er démon qui l'a reçu)
  • SCHEDULE_FORCED_SVC_CHECK: nom de la commande externe
  • myhost: nom de l'hôte
  • HttpsCertificate: nom du check
  • 1613640917: argument de la commande, ici l'epoch où on doit relancer le Check (lancement immédiat ici)