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.
Démarrage
Lors du démarrage du démon, une ligne est disponible:
[2020-05-18 05:19:18] INFO : [daemon ] [START-DAEMON] The daemon (version=02.08.01-release.fr) is now started as a daemon (detached from any shell) with pid=15412 [2020-05-18 05:19:18] INFO : [daemon] [ SYSTEM ] System resource number of open files is set to (soft:1024 / hard:1024 ) (from parameter max_file_descriptor_limit) [2020-05-18 05:19:18] INFO : [daemon] [ SYSTEM ] System resource number of process/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
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.
[2019-12-03 16:35:40] ERROR : [arbiter] [config] Some characters could not be read in utf-8 in these files : [2019-12-03 16:35:40] WARNING: [arbiter] [config] - /etc/shinken/modules/webui.cfg |
Pour résoudre ce problème, il vous suffit de réencoder le fichier au format UTF-8
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.
[2020-02-04 16:25:01] ERROR : [None ] ******************************************************************************** [2020-02-04 16:25:01] ERROR : [None ] [2020-02-04 16:25:01] ERROR : [None ] 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 than the synchronizer one (in the synchronizer.cfg file) so only allowed arbiter can get the configuration. [2020-02-04 16:25:01] ERROR : [None ] [2020-02-04 16:25:01] ERROR : [None ] ******************************************************************************** |
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
Si un démon master pointe vers un démon spare inconnu, on a l'erreur suivante:
ERROR : [arbiter ] [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 daemon 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:
ERROR : [arbiter ] [ 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): ERROR : [arbiter ] [ SPARE MODULE NOT MATCHING ] +-------------+--------------------------------+------------------------------+ ERROR : [arbiter ] [ SPARE MODULE NOT MATCHING ] | Module type | Master [ broker-master-bad-4 ] | Spare [ broker-spare-bad-4 ] | ERROR : [arbiter ] [ SPARE MODULE NOT MATCHING ] +-------------+--------------------------------+------------------------------+ ERROR : [arbiter ] [ SPARE MODULE NOT MATCHING ] | sla | 1 | 0 | ERROR : [arbiter ] [ SPARE MODULE NOT MATCHING ] +-------------+--------------------------------+------------------------------+ |
Si deux démons masters pointent vers un même spare
On a alors l'erreur suivante:
ERROR : [arbiter ] [ TWO MASTERS FOR ONE 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éberge le daemon 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 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 logs 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 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 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 à donnée sa configuration au autres daemons
[2020-05-15 10:00:52] INFO : [arbiter] Begin to dispatch configurations [configuration: uuid=configuration_uuid date=creation_date author=arbiter_name ] to satellites |
- 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
[2020-05-15 10:00:52] INFO : [arbiter] 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 MORTS (qui n'ont pas réussi à répondre à plus de max_retry pings)
- La liste 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
[2020-07-13 17:43:06] INFO : [arbiter-master ] [DISPATCH][All] Dispatching 1 shards (total in realm=1) to schedulers [2020-07-13 17:43:06] INFO : [arbiter-master ] [DISPATCH][All] 1 Shards will be dispatched to 1 schedulers in this order: scheduler-master (realm=All, spare=False) [2020-07-13 17:43:06] INFO : [arbiter-master ] [DISPATCH][All] 1 schedulers are alive but will be used only when non spare schedulers will be DEAD: scheduler-sapre (realm=All, spare=True) |
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 envoi ces informations, on a ceci dans les logs:
[2020-09-16 11:18:19] INFO : [arbiter-master ] [DISPATCH][All] [scheduler-master] SENT TIME Shard [256] sent time is 0.52s (size=0.224MB speed=0.434MB/s) [2020-09-16 11:18:19] INFO : [arbiter-master ] [DISPATCH][All] [scheduler-master] SHARD SENT TO SCHEDULER Dispatch OK of shard [256/[configuration_uuid=add3f68515f34b9e87ccbf5b0cc09cd7, arbiter=arbiter-master, date=16-09-2020 11:17:43]] |
Ici l'arbiter a mis 0.52s pour envoyer la shard numéro 256 qui fait 224Ko 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 assigné 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:
[2020-09-16 11:18:19] INFO : [arbiter-master ] [DISPATCH][All] SATELLITE ORDER Dispatching reactionner satellite with be done in this order: reactionner-master (spare:False), [2020-09-16 11:18:19] INFO : [arbiter-master ] [DISPATCH][All] SATELLITE SENT START Trying to send shard assignation [256=>scheduler-master] to reactionner reactionner-master |
Ici le reactionner reactionner-master s'est vu assigné le lien "shard 256"→ scheduler-master.
L'arbiter envoi l'inventaire aux brokers et receivers
Quand l'arbiter envoi l'inventaire à un broker ou un receiver, on a la ligne suivante:
[2020-07-07 17:17:22] INFO : [arbiter-master ] [INVENTORY ] [PUSH ] [realm=All] Inventory OK [ broker broker-spare ] [hash=c036910d4f546611e9af4b5303e4ab88b9364492] [1 hosts/clusters] |
Avec le royaume de l'inventaire et combien d'hôtes/clusters sont compris dedans.
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