| Scroll Ignore | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||
|
Les logs propres au module
Erreurs lors du lancement du module WebUI
Le port de la WebUI est déjà ouvert
Si une autre WebUI utilise déjà le port ( sûrement un problème de configuration ), alors on aura les WARNING suivants:
| Code Block | ||||
|---|---|---|---|---|
|
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 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 totale générée par l'Arbiter
- configuration_part_id: id de la partie de configuration géré par un Scheduler
Quand un module de broker avec un regenerator charge une nouvelle configuration :
[2020-05-15 16:29:49] INFO : [WebUI3] [ CONFIGURATION ] [ NEW ] [ REGENERATOR ] configuration part retrieved: [ configuration_part_id=configuration_part_id, scheduler=scheduler_name configuration_uuid=configuration_uuid, arbiter=arbiter_name date=creation_date ]
- configuration_part_id: id de la partie de configuration gérée par le Scheduler (unique par Scheduler)
- scheduler_name: nom du Scheduler qui gère cette partie de la configuration
- configuration_uuid: uuid créée lors du démarrage de l'Arbiter qui correspond donc à l'id de la configuration gérée 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 | ||||
|---|---|---|---|---|
| ||||
[YYYY-MM-DD HH:MM:SS] INFOWARNING: [ WebUI-name :] [WebUI3TRY 1/10] [The CONFIGURATIONwebui ]named [ NEWWebUI-name ] [can REGENERATORnot ]start configurationbecause partthe retrieved : [ configuration_part_id=8, scheduler=scheduler-master configuration_uuid=fe5982b29bfb48cdadb35523799f7cec, arbiter=arbiter-master1 date=15-05-2020 16:13:40 ] |
Quand un module de broker avec un regenerator rejette une configuration :
Dans le cas où la configuration d'un Scheduler est déjà gérée par un regenerator (cas qui arrive si par exemple un module crash) on redemande les broks initiaux. Tous les modules vont recevoir la nouvelle configuration, mais ceux qui la gère déjà ne vont pas la recharger et vont loguer :
| Code Block | ||
|---|---|---|
| ||
address 0.0.0.0:7767 is already in use [YYYY-MM-DD HH:MM:SS] WARNING: [ WebUI-name ] [TRY 2/10] The webui named [ WebUI-name ] can not start because the address 0.0.0.0:7767 is already in use [YYYY-MM-DD HH:MM:SS] INFO WARNING: [WebUI3] [ CONFIGURATIONWebUI-name ] [ NEW ]TRY 3/10] The webui named [ REGENERATORWebUI-name ] Nocan neednot tostart reloadbecause the configuration part because I already handle it [ configuration_part_id=configuration_part_id, scheduler=scheduler_name configuration_uuid=configuration_uuid, arbiter=arbiter_name date=creation_date ] |
- configuration_part_id: id de la partie de configuration gérée par le Scheduler (unique par Scheduler)
- scheduler_name: nom du Scheduler qui gère cette partie de la configuration
- configuration_uuid: uuid créée lors du démarrage de l'Arbiter qui correspond donc à l'id de la configuration gérée 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 | ||||
|---|---|---|---|---|
| ||||
[YYYYaddress 0.0.0.0:7767 is already in use [YYYY-MM-DD HH:MM:SS] WARNING: [ WebUI-name ] [TRY 4/10] The webui named [ WebUI-name ] can not start because the address 0.0.0.0:7767 is already in use [YYYY-MM-DD HH:MM:SS] WARNING: [WebUI3] [WebUI-name CONFIGURATION ] [ NEW ]TRY 5/10] The webui named [ REGENERATORWebUI-name ] Nocan neednot tostart reloadbecause the configuration part because I already handle it [ configuration_part_id=8, scheduler=scheduler-master configuration_uuid=fe5982b29bfb48cdadb35523799f7cec, arbiter=arbiter-master1 date=15-05-2020 16:13:40 ] |
Temps de locks trop long entre la consommation des Broks et les requêtes des utilisateurs
address 0.0.0.0:7767 is already in use
[YYYY-MM-DD HH:MM:SS] WARNING: [ WebUI-name ] [TRY 6/10] The webui named [ WebUI-name ] can not start because the address 0.0.0.0:7767 is already in use
[YYYY-MM-DD HH:MM:SS] WARNING: [ WebUI-name ] [TRY 7/10] The webui named [ WebUI-name ] can not start because the address 0.0.0.0:7767 is already in use
[YYYY-MM-DD HH:MM:SS] WARNING: [ WebUI-name ] [TRY 8/10] The webui named [ WebUI-name ] can not start because the address 0.0.0.0:7767 is already in use
[YYYY-MM-DD HH:MM:SS] WARNING: [ WebUI-name ] [TRY 9/10] The webui named [ WebUI-name ] can not start because the address 0.0.0.0:7767 is already in use |
Puis lors du dernier essai une ERROR (le module s'arrête):
| Code Block | ||||
|---|---|---|---|---|
| ||||
[YYYY-MM-DD HH:MM:SS] ERROR : [ WebUI-name ] [ CRASH - INSIDE MODULE PROCESS ] [TRY 10/10] The webui named [ WebUI-name ] can not start because the address 0.0.0.0:7767 is already in use |
Enfin l'erreur sera rapportée par le Broker qui va s'assurer que le module est éteint, et tenter de le relancer plus tard:
| Code Block | ||||
|---|---|---|---|---|
| ||||
[YYYY-MM-DD HH:MM:SS] ERROR : [ broker-name ] [ MODULES-MANAGER ] [ MODULE-INSTANCE-CRASH ] [ WebUI-name ] [ module_type=webui ] The module WebUI2 just stopped. Last ERROR received:
[YYYY-MM-DD HH:MM:SS] ERROR : [ broker-name ] [ MODULES-MANAGER ] [ MODULE-INSTANCE-CRASH ] [ WebUI-name ] [ module_type=webui ] [TRY 10/10] The webui named [ WebUI-name ] can not start because the address 0.0.0.0:7767 is already in use |
Erreurs issues d'un problème de changement dans le code de l'interface de visualisation
Si le fichier index.html est cassé chez un client, ou qu'un développeur a changé ce fichier sans faire attention, on aura des erreurs spécifiques.
Si le fichier index.html est manquant:
| Code Block | ||||
|---|---|---|---|---|
| ||||
[YYYY-MM-DD HH:MM:SS] ERROR : [ WebUI-name ] [ CRASH - INSIDE MODULE PROCESS ] The file /var/lib/shinken/modules/webui/htdocs/ui/index.html is missing: there is a critical error with your installation. Please open a ticket to your support. |
Si le fichier index.html n'a pas les bons droits (l'utilisateur shinken ne peux pas l'ouvrir):
| Code Block | ||||
|---|---|---|---|---|
| ||||
[YYYY-MM-DD HH:MM:SS] ERROR : [ WebUI-name ] [ CRASH - INSIDE MODULE PROCESS ] Cannot open the file /var/lib/shinken/modules/webui/htdocs/ui/index.html with the error "ERROR": there is a critical error with your installation. Please open a ticket to your support. |
Si le fichier index.html n'a pas la bonne variable de langue
| Code Block | ||||
|---|---|---|---|---|
| ||||
[YYYY-MM-DD HH:MM:SS] ERROR : [ WebUI-name ] [ CRASH - INSIDE MODULE PROCESS ] The __shinken_lang__ variable was not found in the file /var/lib/shinken/modules/webui/htdocs/ui/index.html: there is a critical error with your installation. Please open a ticket to your support. |
Erreurs de paramétrage
Si certains paramètres sont mal définis, la WebUI ne peut pas démarrer et va s'arrêter sur une erreur critique, qui sera affichée dans le check du Broker ainsi que dans le healthcheck.
Si son paramètre "lang" n'est pas dans la liste autorisé ( fr, en ), on aura l'erreur suivante:
| Code Block | ||||
|---|---|---|---|---|
| ||||
[YYYY-MM-DD HH:MM:SS] ERROR : [ WebUI-name ] [ CRASH - INSIDE MODULE PROCESS ] For the parameter "lang" the value "XXX" is not allowed. Values can be : "fr, en" |
La configuration des Graphite backends
Erreur de format du graphite_backends
Lors du démarrage de la WebUI, une vérification est lancée sur le format de son paramètre graphite_backends. En fonction de la nature de l'erreur, le message d'erreur peut varier selon les logs suivants.
| Note |
|---|
Il est possible que plusieurs de ces logs apparaissent en même temps si plusieurs de ces erreurs sont détectées en même temps. |
Pas de nom de royaume détecté
| No Format |
|---|
[YYYY-MM-DD HH:MM:SS] ERROR : [ WEBUI_NAME ] [ CONFIGURATION ] Graphite Backend [ BACKEND ] format error. No realm name found. Expected format : <REALM>=<PROTOCOL>://<HOSTNAME>:<PORT> |
Cette erreur arrive lorsque le caractère de séparation du royaume et de l'adresse ( = ) n'est pas trouvé :
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
graphite_backends http://localhost:80 |
Trop de séparateur de royaume détectés
| No Format |
|---|
[YYYY-MM-DD HH:MM:SS] ERROR : [ WEBUI_NAME ] [ CONFIGURATION ] Graphite Backend [ BACKEND ] format error. Too much realm separators found ( = ). Expected format : <REALM>=<PROTOCOL>://<HOSTNAME>:<PORT> |
Cette erreur arrive lorsque le caractère de séparation du royaume et de l'adresse ( = ) est présent plus d'une fois dans un backend :
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
graphite_backends France==http://localhost:80, Bordeaux=Toulouse=http://192.168.1.25:8080, Bordeaux=http://192.168.1.25:8080?param=value |
Pas de protocol détecté
| No Format |
|---|
[YYYY-MM-DD HH:MM:SS] ERROR : [ WEBUI_NAME ] [ CONFIGURATION ] Graphite Backend [ BACKEND ] format error. No protocol found ( http:// ). Expected format : <REALM>=<PROTOCOL>://<HOSTNAME>:<PORT> |
Cette erreur arrive lorsque aucun protocole n'a été trouvé dans le backend ( ou que la chaîne "://" n'est pas présente ) :
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
graphite_backends France=localhost:80, Bordeaux=http:192.168.1.25:8080 |
Port HTTP non précisé
| No Format |
|---|
[YYYY-MM-DD HH:MM:SS] ERROR : [ WEBUI_NAME ] [ CONFIGURATION ] Graphite Backend [ BACKEND ] format error. No HTTP port found. Expected format : <REALM>=<PROTOCOL>://<HOSTNAME>:<PORT> |
Cette erreur arrive lorsque aucun port HTTP n'est précisé dans le backend :
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
graphite_backends France=http://localhost |
Pas de nom d'hôte détecté
| No Format |
|---|
[YYYY-MM-DD HH:MM:SS] ERROR : [ WEBUI_NAME ] [ CONFIGURATION ] Graphite Backend [ BACKEND ] format error. No hostname or IP address found. Expected format : <REALM>=<PROTOCOL>://<HOSTNAME>:<PORT> |
Cette erreur est présente si aucune adresse IP ou nom d'hôte n'est présente dans un backend :
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
graphite_backends France=http://:80 |
Création des index en base de données au démarrage
Au démarrage du module, les index permettant d'assurer de bonnes performances pour les requêtes à la base de données sont créés s'ils n'existent pas.
Le temps pris pour la mise en place de chaque index est également détaillé.
| No Format |
|---|
[YYYY-MM-DD HH:MM:DD] INFO : [ WebUI-name ] [ Index ] Need to ensure indexes are present in Mongodb ( 2 indexes )
[YYYY-MM-DD HH:MM:DD] INFO : [ WebUI-name ] [ Index ] 1 - COLLECTION_NAME1::FIELD2 ( INDEX_NAME ) was created/checked in X.XXXXs
[YYYY-MM-DD HH:MM:DD] INFO : [ WebUI-name ] [ Index ] 2 - COLLECTION_NAME2::FIELD1,FIELD2 ( INDEX_NAME ) was created/checked in X.XXXXs
[YYYY-MM-DD HH:MM:DD] INFO : [ WebUI-name ] [ Index ] All Mongodb indexes were created/checked in X.XXXs |
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
[2021-11-25 16:38:47] INFO : [ WebUI ] [ Index ] Need to ensure indexes are present in Mongodb ( 1 indexes )
[2021-11-25 16:38:47] INFO : [ WebUI ] [ Index ] 1 - dashboard::uuid ( uuid_1 ) was created/checked in 0.0005s
[2021-11-25 16:38:47] INFO : [ WebUI ] [ Index ] All Mongodb indexes were created/checked in 0.0005s |
Cas d'erreur
Si une erreur survient lors de la tentative d'indexation, le module essaiera à nouveau lors de son prochain démarrage, et le log suivant est généré
| No Format |
|---|
[YYYY-MM-DD HH:MM:SS] WARNING: [ WebUI-name] Mongodb ERREUR PYTHON
[YYYY-MM-DD HH:MM:SS] WARNING: [ WebUI-name] Mongodb index building could not be done, will retry at next restart |
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
[2021-10-21 17:05:52] WARNING: [ WebUI ] Mongodb ERROR stack : Traceback (most recent call last):
[2021-10-21 17:05:52] WARNING: [ WebUI ] Mongodb File "/var/lib/shinken/modules/webui/module.py", line 379, in main
[2021-10-21 17:05:52] WARNING: [ WebUI ] Mongodb raise IOError
[2021-10-21 17:05:52] WARNING: [ WebUI ] Mongodb IOError
[2021-10-21 17:05:52] WARNING: [ WebUI ] Mongodb index building could not be done, will retry at next restart |
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 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 totale générée par l'Arbiter
- shard_id: id de la partie de configuration géré par un Scheduler
Quand un module de broker avec un regenerator charge une nouvelle configuration :
| Code Block | ||||
|---|---|---|---|---|
| ||||
[ YYYY-MM-DD HH:MM:SS ] INFO : [ WebUI-name ] [ REGENERATOR ] [ scheduler=scheduler_name ] Creating new configuration for [shard_id= shard_id , scheduler= scheduler_name , configuration_uuid= configuration_uuid , arbiter= arbiter_name , architecture= architecture_name , date= creation_date , active= active ] |
- shard_id: id de la partie de configuration gérée par le Scheduler (unique par Scheduler)
- scheduler_name: nom du Scheduler qui gère cette partie de la configuration
- configuration_uuid: uuid crée lors du démarrage de l'Arbiter qui correspond donc à l'id de la configuration gérée par l'Arbiter
- creation_date: date du démarrage de l'Arbiter
- arbiter_name: nom de l'Arbiter qui a créé cette configuration
- architecture_name: nom de l'architecture, unique par installation de Shinken
- active: Est a False si le Scheduler est pas actif (en attente d'une configuration)
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
[2022-01-26 13:01:43] INFO : [ WebUI3 ] [ REGENERATOR ] [ scheduler=scheduler-dev2 ] Creating new configuration for [shard_id=256, scheduler=scheduler-dev2, configuration_uuid=a549db11b51d4aeb8548b43b088112e9, arbiter=arbiter-dev2, architecture=Shinken-dev2, date=26-01-2022 13:00:28, active=True] |
Quand un module de broker avec un regenerator rejette une configuration :
Dans le cas où la configuration d'un Scheduler est déjà gérée par un regenerator ( cas qui arrive si par exemple un module crash ) on redemande les broks initiaux. Tous les modules vont recevoir la nouvelle configuration, mais ceux qui la gère déjà, ne vont pas la recharger et vont loguer :
| Code Block | ||||
|---|---|---|---|---|
| ||||
[YYYY-MM-DD HH:MM:SS] INFO : [WebUI-name] [ CONFIGURATION ] [ NEW ] [ REGENERATOR ] No need to reload the configuration part because I already handle it [shard_id=shard_id, scheduler=scheduler_name, configuration_uuid=configuration_uuid, arbiter=arbiter_name, architecture=architecture_name, date=creation_date, active=active] |
- shard_id: id de la partie de configuration gérée par le Scheduler (unique par Scheduler)
- scheduler_name: nom du Scheduler qui gère cette partie de la configuration
- configuration_uuid: uuid crée lors du démarrage de l'Arbiter qui correspond donc à l'id de la configuration gérée par l'Arbiter
- creation_date: date du démarrage de l'Arbiter
- arbiter_name: nom de l'Arbiter qui a créé cette configuration
- architecture_name: nom de l'architecture, unique par installation de Shinken
- active: Est a False si le Scheduler est pas actif (en attente d'une configuration)
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
[YYYY-MM-DD HH:MM:SS] WARNING: [WebUI3] [ CONFIGURATION ] [ NEW ] [ REGENERATOR ] No need to reload the configuration part because I already handle it [shard_id=256, scheduler=scheduler-dev2, configuration_uuid=a549db11b51d4aeb8548b43b088112e9, arbiter=arbiter-dev2, architecture=Shinken-dev2, date=26-01-2022 13:00:28, active=True] |
Quand un module de broker avec un regenerator fini de charger une configuration :
Quand un Scheduler a fini d'envoyer une configuration, le regenerator charge cette configuration les log suivant montre les étapes de ce chargement.
Le début du chargement est montré par le log suivant :
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
[2022-01-26 13:01:43] INFO : [ WebUI3 ] [ REGENERATOR ] [ scheduler=scheduler-dev2 ] [ LOADING ] Loading configuration part : [shard_id=256, scheduler=scheduler-dev2, configuration_uuid=a549db11b51d4aeb8548b43b088112e9, arbiter=arbiter-dev2, architecture=Shinken-dev2, date=26-01-2022 13:00:28, active=True] |
Les différentes étapes avec les logs suivants :
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
[2022-01-26 13:01:43] INFO : [ WebUI3 ] [ REGENERATOR ] [ scheduler=scheduler-dev2 ] [ LOADING ] [ PERF ] Merging incoming hostgroup with already existing ones --------------------- : 0.00
[2022-01-26 13:01:43] INFO : [ WebUI3 ] [ REGENERATOR ] [ scheduler=scheduler-dev2 ] [ LOADING ] [ PERF ] Linking hosts => hostgroups / command / timeperiod / contacts ------------- : 0.00
[2022-01-26 13:01:43] INFO : [ WebUI3 ] [ REGENERATOR ] [ scheduler=scheduler-dev2 ] [ LOADING ] [ PERF ] Merging incoming service groups with already existing ones ---------------- : 0.00
[2022-01-26 13:01:43] INFO : [ WebUI3 ] [ REGENERATOR ] [ scheduler=scheduler-dev2 ] [ LOADING ] [ PERF ] Linking services => host / servicegroups / command / timeperiod / contact - : 0.00
[2022-01-26 13:01:43] INFO : [ WebUI3 ] [ REGENERATOR ] [ scheduler=scheduler-dev2 ] [ LOADING ] [ PERF ] Linking service groups => services ---------------------------------------- : 0.00
[2022-01-26 13:01:43] INFO : [ WebUI3 ] [ REGENERATOR ] [ scheduler=scheduler-dev2 ] [ LOADING ] [ PERF ] Linking hostgroups => hosts ----------------------------------------------- : 0.00
[2022-01-26 13:01:43] INFO : [ WebUI3 ] [ REGENERATOR ] [ scheduler=scheduler-dev2 ] [ LOADING ] [ PERF ] Build realm list ---------------------------------------------------------- : 0.00
[2022-01-26 13:01:43] INFO : [ WebUI3 ] [ REGENERATOR ] [ scheduler=scheduler-dev2 ] [ LOADING ] [ PERF ] Linking host => host & check dependencies ( parents / childs ) ------------ : 0.00
[2022-01-26 13:01:43] INFO : [ WebUI3 ] [ REGENERATOR ] [ scheduler=scheduler-dev2 ] [ LOADING ] [ PERF ] Linking checks => host & check dependencies ( parents / childs ) ---------- : 0.00
[2022-01-26 13:01:43] INFO : [ WebUI3 ] [ REGENERATOR ] [ scheduler=scheduler-dev2 ] [ LOADING ] [ PERF ] Linking timeperiod => excluded timeperiod --------------------------------- : 0.00
[2022-01-26 13:01:43] INFO : [ WebUI3 ] [ REGENERATOR ] [ scheduler=scheduler-dev2 ] [ LOADING ] [ PERF ] Merging incoming contactgroups with already existing ones ----------------- : 0.00
[2022-01-26 13:01:43] INFO : [ WebUI3 ] [ REGENERATOR ] [ scheduler=scheduler-dev2 ] [ LOADING ] [ PERF ] Linking contactgroups => contacts ----------------------------------------- : 0.00 |
Puis lors que le chargement est fini l'on donne la taille de la configuration total chargé dans le regenerator et le temps pris pour ce chargement.
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
[2022-01-26 13:01:43] INFO : [ WebUI3 ] [ REGENERATOR ] [ scheduler=scheduler-dev2 ] [ LOADING ] Configuration size
[2022-01-26 13:01:43] INFO : [ WebUI3 ] [ REGENERATOR ] [ scheduler=scheduler-dev2 ] [ LOADING ] - hosts -------------- : 1
[2022-01-26 13:01:43] INFO : [ WebUI3 ] [ REGENERATOR ] [ scheduler=scheduler-dev2 ] [ LOADING ] - checks ------------- : 27
[2022-01-26 13:01:43] INFO : [ WebUI3 ] [ REGENERATOR ] [ scheduler=scheduler-dev2 ] [ LOADING ] - contacts ----------- : 1
[2022-01-26 13:01:43] INFO : [ WebUI3 ] [ REGENERATOR ] [ scheduler=scheduler-dev2 ] [ LOADING ] - notificationways --- : 1
[2022-01-26 13:01:43] INFO : [ WebUI3 ] [ REGENERATOR ] [ scheduler=scheduler-dev2 ] [ LOADING ] - hostgroups --------- : 0
[2022-01-26 13:01:43] INFO : [ WebUI3 ] [ REGENERATOR ] [ scheduler=scheduler-dev2 ] [ LOADING ] - servicegroups ------ : 0
[2022-01-26 13:01:43] INFO : [ WebUI3 ] [ REGENERATOR ] [ scheduler=scheduler-dev2 ] [ LOADING ] - contactgroups ------ : 1
[2022-01-26 13:01:43] INFO : [ WebUI3 ] [ REGENERATOR ] [ scheduler=scheduler-dev2 ] [ LOADING ] - timeperiods -------- : 1
[2022-01-26 13:01:43] INFO : [ WebUI3 ] [ REGENERATOR ] [ scheduler=scheduler-dev2 ] [ LOADING ] - commands ----------- : 219
[2022-01-26 13:01:43] INFO : [ WebUI3 ] [ REGENERATOR ] [ scheduler=scheduler-dev2 ] [ LOADING ] - realms ------------- : 1
[2022-01-26 13:01:43] INFO : [ WebUI3 ] [ REGENERATOR ] [ scheduler=scheduler-dev2 ] [ LOADING ] The configuration with shard_id=256 was fully load in 0.004s |
Il y aura une série de log comme ca pour chaque Scheduler contactés par le Broker.
Temps de locks trop long entre la consommation des Broks et les requêtes de l'interface de Visualisation
Actuellement on ne sait pas consommer les broks et répondre aux requêtes de l'interface de Visualisation en même temps. On a donc une concurrence entre deux parties:
- Récupération, consommation des broks depuis le broker et mise à jour des hôtes/checks/clusters (et tous les autres objets) depuis les informations des broks
- Réponses aux requêtes de l'interface de Visualisation ( parcours des hôtes, checks, clusters ... )
Un des principaux risques est une famine d'un des deux groupes d'actions:
- Si on ne fait qu'avaler des broks et ne jamais répondre à l'interface, ceci va poser problème
- Symétriquement, si on ne fait que répondre aux utilisateurs, et jamais avaler des broks, on va avoir des informations périmées, voir, on ne finira jamais de consommer de nouvelles configurations
Le gestionnaire de lock essaie de partager au mieux le temps d'exécution entre les deux groupes, en cas de forte charge, des logs vont remonter les lenteurs observées.
Quand on a trop de requêtes de lectures, et qu'elles ne rendent pas la main pendant plus de 30 sec aux broks, on aura un log suivant ( Brok BLOQUE par les requêtes ):
| Code Block | ||||
|---|---|---|---|---|
| ||||
ERROR: [ ITEMS ACCESS ORDONNANCER ] [ LONG LOCK ] Broks management are waiting (1 thread) since 30s (> log error limit=30s) because HTTP requests (20 threads) has the LOCK |
Quand on a trop de consommation de Broks, et que les requêtes sont bloquées ( Requêtes de l'interface BLOQUÉES par les Broks )
| Code Block | ||||
|---|---|---|---|---|
| ||||
ERROR: [ ITEMS ACCESS ORDONNANCER ] [ LONG LOCK ] HTTP requests are waiting (5 threads) since 30s (> log error limit=30s) because Broks management (1 thread) has the LOCK |
Quand les requêtes en lecture mettent trop de temps à rendre la main au consommateur de Broks et que d'autres requêtes en lecture attendent de pouvoir s'exécuter depuis trop longtemps :
| Code Block | ||||
|---|---|---|---|---|
| ||||
ERROR: [ ITEMS ACCESS ORDONNANCER ] [ LONG LOCK ] Still have 9 running tasks ongoing (HTTP requests). => ( 1 ) Broks management and then ( 11 ) HTTP requests are waiting since 30s (>= log error limit:30s) |
Quand la consommation de Broks met trop de temps à rendre la main pour la gestion de requêtes en lecture, et que d'autres consommateurs attendent de s'exécuter depuis trop longtemps ( cas théorique, n'est pas supposé survenir en fonctionnement normal ) :
| Code Block | ||||
|---|---|---|---|---|
| ||||
ERROR: [ ITEMS ACCESS ORDONNANCER ] [ LONG LOCK ] Still have 1 running tasks ongoing (Broks management). => ( 12 ) HTTP requests then ( 1 ) Broks management are waiting since 30s (>= log error limit:30s) |
Gestion des broks
Information sur l'absorption des broks
Statistiques sur un traitement
Des broks ont été traités, affichage de statistiques :
- nombre de broks traités
- temps d'attente du premier brok set
- nombre de brok set en retard récupérés, et le temps que ça a pris de les récupérer
- temps passé à désérialiser les broks
- temps d'attente du lock avant de traiter les broks
- temps passé pour traiter les broks
- temps total
| Code Block | ||||
|---|---|---|---|---|
| ||||
[YYYY-MM-DD HH:MM:SS] INFO : [ WebUI-name ] [ MANAGE BROKS ] [PERF] [ XXXX broks ] [ wait and get first set on queue=X.XXXs ] [ get 0 late sets on=X.XXXs ] [ unserialize=X.XXXs ] [ wait write lock=X.XXXs ] [ manage broks=X.XXXs ] [ total=X.XXXs ] |
Nature des broks traités
Affichage du type des broks traités : en quantité et en temps
| Code Block | ||||
|---|---|---|---|---|
| ||||
[YYYY-MM-DD HH:MM:SS] INFO : [ WebUI-name ] [ MANAGE BROKS ] [PERF] => handled broks -> count by types : [brok_type_1=XXXX] [brok_type_2=XX] [...] |
| Code Block | ||||
|---|---|---|---|---|
| ||||
[YYYY-MM-DD HH:MM:SS] INFO : [ WebUI-name ] [ MANAGE BROKS ] [PERF] => handled broks -> time by types : [brok_type_1=XXXX] [brok_type_2=XX] [...] |
Exemple de log
| Code Block | ||||
|---|---|---|---|---|
| ||||
[2022-01-26 13:01:43] INFO : [ WebUI ] [ MANAGE BROKS ] [ PERF ] => handled broks -> count by types : [initial_command_status=219] [update_broker_status=3] [update_program_status=1] [program_status=1] [initial_contact_status=1] [...]
[2022-01-26 13:01:43] INFO : [ WebUI ] [ MANAGE BROKS ] [ PERF ] => handled broks -> time by types : [initial_command_status=0.022] [update_broker_status=0.000] [update_program_status=0.000] [program_status=0.001] [initial_contact_status=0.000] [...] |
L'absorption des broks a pris du retard
En cas de forte charge sur le serveur ou lorsque des requêtes HTTP durent trop longtemps, le module peut prendre du retard sur la gestion des broks.
L'algorithme d'absorption des broks peut être paramétré via les paramètres webui_broks_getter_XXX du fichier de configuration du Module WebUI ( voir la page Module WebUI )
Le mode de rattrapage pour récupérer les broks en retard s'active
Activation du rattrapage des broks en retard, on prend un brok set supplémentaire à traiter, on affiche :
- le nombre de broks dans le brok set
- le temps passé pour récupérer le brok set sur la queue
- le nombre actuel de broks à traiter
- le nombre maximal de broks qu'on peut récupérer avant de les traiter
- le nombre de brok set encore en attente
| Code Block | ||||
|---|---|---|---|---|
| ||||
[YYYY-MM-DD HH:MM:SS] INFO : [ WebUI-name ] [ MANAGE BROKS ] [PERF] [LATE BROKS SETS] Getting brok set with XX broks in X.XXXs [time for read queue size=X.XXXs]. Total broks to process= XXX/max:XXXX. Broks sets in queue: X. |
Le mode rattrapage a suffisamment de broks à traiter
Rattrapage des broks en retard en cours, on a atteint/dépassé le nombre maximal de broks à récupérer, on les traite :
| Code Block | ||||
|---|---|---|---|---|
| ||||
[YYYY-MM-DD HH:MM:SS] INFO : [ WebUI-name ] [ MANAGE BROKS ] [PERF] [LATE BROKS SETS] Late brok taken => limit reach : XX / limit: XXXXXX. |
Après avoir traiter des broks, il en reste encore trop en attente
Après avoir traité des broks, il reste trop de brok set en attente, on garde le lock et on continue l'absorption des broks en retard :
| Code Block | ||||
|---|---|---|---|---|
| ||||
[YYYY-MM-DD HH:MM:SS] INFO : [ WebUI-name ] [ MANAGE BROKS ] [PERF] Number of Broks sets still in queue after managing broks is XX. We keep the lock and continue the brok managing. |
Demande des broks initiaux lors du redémarrage d'un module externe du Broker
Lors du redémarrage d'un module externe du broker, une demande est envoyée par le Broker aux Schedulers pour récupérer de nouveaux broks initiaux ( une demande par Scheduler ).
| Code Block | ||||
|---|---|---|---|---|
| ||||
[YYYY-MM-DD HH:MM:SS] INFO : [ broker-name ] [ GET BROKS ] [ NEED DATA ] [ scheduler-name ] I ask for a initial broks generation to the scheduler with new daemon incarnation {u'shard_id': XXXX, u'configuration_incarnation_uuid': UUID} (old incarnation was {}) |
Log du chargement de la configuration par la WebUI
Ces logs permettent de suivre le chargement de la configuration envoyée par les Schedulers et chargée par la WebUI.
Au début du chargement d'une nouvelle configuration :
| Code Block | ||||
|---|---|---|---|---|
| ||||
[YYYY-MM-DD HH:MM:SS] INFO : [ MODULE-NAME ] [ LOADING CONFIGURATION ] The configuration 〖 UUID 〗 from the arbiter 〖 DAEMON-NAME 〗 must be loaded with 〖 X 〗 monitoring configuration parts. |
A chaque réception d'une nouvelle partie de la configuration envoyée par un Scheduler :
| Code Block | ||||
|---|---|---|---|---|
| ||||
[YYYY-MM-DD HH:MM:SS] INFO : [ MODULE-NAME ] [ LOADING CONFIGURATION ] A new monitoring configuration part from the scheduler 〖 DAEMON-NAME 〗 have been received. Monitoring configuration part 〖 XXXX 〗-〖 UUID 〗from scheduler:〖 DAEMON-NAME 〗 provided by arbiter:〖 DAEMON-NAME 〗 at:〖YYYY-MM-DD HH:MM:SS〗 |
Lorsque le chargement de la partie de la configuration envoyée par un Sheduler est complète:
| Code Block | ||||
|---|---|---|---|---|
| ||||
[YYYY-MM-DD HH:MM:SS] INFO : [ MODULE-NAME ] [ LOADING CONFIGURATION ] The monitoring configuration part from the scheduler 〖 DAEMON-NAME 〗 have been processed. Monitoring configuration part 〖 XXXX 〗-〖 UUID 〗from scheduler:〖 DAEMON-NAME 〗provided by arbiter:〖 DAEMON-NAME 〗 at:〖YYYY-MM-DD HH:MM:SS〗 |
A chaque nouveau chargement d'une partie de la configuration :
Si la configuration chargée par la WebUI est désormais complète :
| Code Block | ||||
|---|---|---|---|---|
| ||||
[YYYY-MM-DD HH:MM:SS] INFO : [ MODULE-NAME ] [ LOADING CONFIGURATION ] All 〖 X 〗 monitoring configuration parts from schedulers have been handled |
Une partie de morceau de la configuration a été reçu, mais pas la totalité :
| Code Block | ||||
|---|---|---|---|---|
| ||||
[YYYY-MM-DD HH:MM:SS] INFO : [ MODULE-NAME ] [ LOADING CONFIGURATION ] 〖 X 〗 / 〖 X 〗 monitoring configuration parts from schedulers have been loaded |
Par défaut, si on ne dispose pas de l'information du nombre total de partie de la configuration :
| Code Block | ||||
|---|---|---|---|---|
| ||||
[YYYY-MM-DD HH:MM:SS] INFO : [ MODULE-NAME ] [ LOADING CONFIGURATION ] 〖 X 〗 monitoring configuration parts from schedulers have been handled |
Log d'indisponibilité de la WebUI au démarrage
Si la configuration envoyée par les Schedulers est volumineuse, la WebUI peut être indisponible pendant son chargement. Ces logs permettent de suivre la durée d'indisponibilité accumulée de la WebUI durant le chargement des différentes parties de la configuration.
Le log suivant s'affiche juste avant le chargement de la partie de la configuration envoyée par un Scheduler :
| Code Block | ||||
|---|---|---|---|---|
| ||||
[YYYY-MM-DD HH:MM:SS] INFO : [ MODULE-NAME ] [ UNAVAILABILITY ] The module may be unavailable while the new monitoring configuration part is being loaded. Monitoring configuration part 〖 XXXX 〗-〖 UUID 〗 from scheduler:〖 DAEMON-NAME 〗 provided by arbiter:〖 DAEMON-NAME 〗 at:〖YYYY-MM-DD HH:MM:SS〗 |
Le log suivant s'affiche à la fin du chargement de la partie de la configuration envoyée par un Scheduler :
| Code Block | ||||
|---|---|---|---|---|
| ||||
[YYYY-MM-DD HH:MM:SS] INFO : [ MODULE-NAME ] [ UNAVAILABILITY ] The module [ MODULE-NAME ] is now available. Unavailability started at 〖YYYY-MM-DD HH:MM:SS〗 took:〖X.XXXs〗 for loading 〖X〗/〖X〗 part of configuration Monitoring incarnation 〖 UUID 〗provided by arbiter:〖 DAEMON-NAME 〗 at:〖YYYY-MM-DD HH:MM:SS〗. |
log de performance de la liste
Ce log s'affichera si l'appel à la liste prend plus de 1s :
| Code Block | ||||
|---|---|---|---|---|
| ||||
[YYYY-MM-DD HH:MM:SS] WARNING : [ WebUI-name ] [ CP Server Thread-74 ] [ user=user-uuid ] [ get_data_visualisation_list ] [ PERF ] [ X.XXXs ] elements:[ in broker= XX filtered= XX total= XX in page= XX ] page:[ 1 / 1 ] filter:[ ] sort:[ ] |
Les appels à Graphite
Voici le log, dans le cas ou graphite ne réponde pas avec un message json valide.
Cela peux arrivé notamment si il y a une redirection de configurerez sur le serveur Apache.
| Code Block | ||||
|---|---|---|---|---|
| ||||
[YYYY-MM-DD HH:MM:SS] ERROR : [ WebUI ] Graphite server response is not a valid json format. We get b'MESSAGE DE GRAPHITE' |
Les logs des sous-modules
Les logs du module MongoDB
Erreurs
Si le module MongoDB n'arrive pas à se connecter à la base mongo définit dans son fichier cfg :
| Code Block | ||||
|---|---|---|---|---|
| ||||
[YYYY-MM-DD HH:MM:SS] ERROR : [ WebUI-name ] Mongodb Module: Error : [ WebUI-name ] [ MONGODB ] - mongo connection failure to 192.168.1.87:27017 |
Les logs du module SLA
Initialisation du module SLA - CHAPITRE [ INITIALISATION ]
Création du module
| Code Block | ||||
|---|---|---|---|---|
| ||||
[YYYY-MM-DD HH:MM:SS] INFO : [ WebUI-name ] [ sla ] [ INITIALISATION ] ============= Starting module initialisation ==============
[YYYY-MM-DD HH:MM:SS] INFO : [ WebUI-name ] [ sla ] [ INITIALISATION ] Reading configuration for sla archive building
[YYYY-MM-DD HH:MM:SS] INFO : [ WebUI-name ] [ sla ] [ INITIALISATION ] - time_before_shinken_inactive ----------------------------------:〖 30 〗
[YYYY-MM-DD HH:MM:SS] INFO : [ WebUI-name ] [ sla ] [ INITIALISATION ] - minimal_time_before_an_element_become_missing_data ------------:〖 0 〗
[YYYY-MM-DD HH:MM:SS] INFO : [ WebUI-name ] [ sla ] [ INITIALISATION ] - minimal_time_before_an_element_become_missing_data_at_startup -:〖 0 〗
[YYYY-MM-DD HH:MM:SS] INFO : [ WebUI-name ] [ sla ] [ INITIALISATION ] Reading module configuration
|
Paramètre de connexion à la base mongo
| Code Block | ||||
|---|---|---|---|---|
| ||||
[YYYY-MM-DD HH:MM:SS] INFO : [ WebUI-name ] [ sla ] [ INITIALISATION ] [ MONGO ] Creating connection to sla database [shinken]
[YYYY-MM-DD HH:MM:SS] INFO : [ WebUI-name ] [ sla ] [ INITIALISATION ] [ MONGO ] Parameter load for database connection
[YYYY-MM-DD HH:MM:SS] INFO : [ WebUI-name ] [ sla ] [ INITIALISATION ] [ MONGO ] - database ------------------------- :〖 shinken 〗
[YYYY-MM-DD HH:MM:SS] INFO : [ WebUI-name ] [ sla ] [ INITIALISATION ] [ MONGO ] - uri ------------------------------ :〖 mongodb://localhost/?w=1&fsync=false 〗
[YYYY-MM-DD HH:MM:SS] INFO : [ WebUI-name ] [ sla ] [ INITIALISATION ] [ MONGO ] - replica_set ---------------------- :〖 〗
[YYYY-MM-DD HH:MM:SS] INFO : [ WebUI-name ] [ sla ] [ INITIALISATION ] [ MONGO ] - use_ssh_tunnel ------------------- :〖 False 〗
[YYYY-MM-DD HH:MM:SS] INFO : [ WebUI-name ] [ sla ] [ INITIALISATION ] [ MONGO ] - ssh_keyfile ---------------------- :〖 ~shinken/.ssh/id_rsa 〗
[YYYY-MM-DD HH:MM:SS] INFO : [ WebUI-name ] [ sla ] [ INITIALISATION ] [ MONGO ] - ssh_user ------------------------- :〖 root 〗
[YYYY-MM-DD HH:MM:SS] INFO : [ WebUI-name ] [ sla ] [ INITIALISATION ] [ MONGO ] - ssh_tunnel_timeout --------------- :〖 2 〗
[YYYY-MM-DD HH:MM:SS] INFO : [ WebUI-name ] [ sla ] [ INITIALISATION ] [ MONGO ] - use_ssh_retry_failure ------------ :〖 1 〗
[YYYY-MM-DD HH:MM:SS] INFO : [ WebUI-name ] [ sla ] [ INITIALISATION ] [ MONGO ] - auto_reconnect_max_try ----------- :〖 3 〗
[YYYY-MM-DD HH:MM:SS] INFO : [ WebUI-name ] [ sla ] [ INITIALISATION ] [ MONGO ] - auto_reconnect_sleep_between_try - :〖 3 〗
[YYYY-MM-DD HH:MM:SS] INFO : [ WebUI-name ] [ sla ] [ INITIALISATION ] [ MONGO ] Try to open a Mongodb connection to mongodb://localhost/?w=1&fsync=false:shinken
[YYYY-MM-DD HH:MM:SS] INFO : [ WebUI-name ] [ sla ] [ INITIALISATION ] [ MONGO ] Mongo connection established in 2.59ms
[YYYY-MM-DD HH:MM:SS] INFO : [ WebUI-name ] [ sla ] [ INITIALISATION ] [ MONGO ] Ensure mongo index done in 2.15ms |
Fin de l'initialisation du module
| Code Block | ||||
|---|---|---|---|---|
| ||||
[YYYY-MM-DD HH:MM:SS] INFO : [ WebUI-name ] [ sla ] [ INITIALISATION ] Load from collection 28 elements info in cache done in 0.65ms
[YYYY-MM-DD HH:MM:SS] INFO : [ WebUI-name ] [ sla ] [ INITIALISATION ] ============= Module initialized in 16.38ms ==============
[YYYY-MM-DD HH:MM:SS] INFO : [ WebUI-name ] [ sla ] [ INITIALISATION ] Found first element monitoring at 03-08-2020 10:16:38 |
Erreurs - La connexion au serveur Mongo n'est pas établie
Avec Tunnel SSH
| Code Block | ||||
|---|---|---|---|---|
| ||||
[YYYY-MM-DD HH:MM:SS] ERROR : [ WebUI-name ] [ sla ] [ INITIALISATION ] Initialisation Module: Error : [ WebUI -sla ] [ SSH TUNNEL ] [ MONGODB ] - mongo connection failure : localhost:43577 ==(ssh tunnel)==> 192.168.1.87:22 ==(mongodb)==> 192.168.1.87:27017. |
Sans Tunnel SSH
| Code Block | ||||
|---|---|---|---|---|
| ||||
[YYYY-MM-DD HH:MM:SS] ERROR : [ WebUI-name ] [ sla ] [ INITIALISATION ] Initialisation Module: Error : [ WebUI -sla ] [ MONGODB ] - mongo connection failure to 192.168.1.87:27017 |
Les logs du module event-manager-reader
Erreurs
Dans le cas où un utilisateur demande une requête trop grande aux évents ( en tapant un filtre trop large dans le nom, matchant plus de 50000 hosts/checks/clusters ), alors la WebUI va générer un log de WARNING alertant que la recherche est trop large, et que MongoDB risque de refuser la requête si elle est effectuée avec des uuids. Elle sera donc faite avec des regexp côté base de données, ce qui est très lent.
| Code Block | ||||
|---|---|---|---|---|
| ||||
[YYYY-MM-DD HH:MM:SS] WARNING: [ WebUI-name ] [ event_container ] [ FAST-SEARCH ] [user=admin] [filter=type:check^^host~host_name:BiBi] The filter match too much uuids to query mongodb (101 > 100000) we must fallback to the slower regexp based query. |
log de performance du conteneur d'événements
Note
- ce log s'affichera si l'appel à la liste prend plus de 1s :
- ces logs sont désactivés par défaut voir la page : Activation/Désactivation des parties de log pour les activer.
| Code Block | ||||
|---|---|---|---|---|
| ||||
[YYYY-MM-DD HH:MM:SS] WARNING: [ WebUI-name ] [ event-manager-reader ] [ user=user-id] [ get_events ] [ PERF ] [ XX.XXXs ] 100 events returned with filter:[{"filter0":"type:host","filter1":"event_since:latest|3600~type:check~realm:All"}] |
Les logs du module SLA
Création du sous-module
| Code Block | ||||
|---|---|---|---|---|
| ||||
[YYYY-MM-DD HH:MM:SS] INFO : [ WebUI-name ] [ sla ] [ INITIALISATION ] ============= Starting module initialisation ==============
[YYYY-MM-DD HH:MM:SS] INFO : [ WebUI-name ] [ sla ] [ INITIALISATION ] Reading configuration for sla archive building
[YYYY-MM-DD HH:MM:SS] INFO : [ WebUI-name ] [ sla ] [ INITIALISATION ] - time_before_shinken_inactive ----------------------------------:〖 30 〗
[YYYY-MM-DD HH:MM:SS] INFO : [ WebUI-name ] [ sla ] [ INITIALISATION ] - minimal_time_before_an_element_become_missing_data ------------:〖 0 〗
[YYYY-MM-DD HH:MM:SS] INFO : [ WebUI-name ] [ sla ] [ INITIALISATION ] - minimal_time_before_an_element_become_missing_data_at_startup -:〖 0 〗
[YYYY-MM-DD HH:MM:SS] INFO : [ WebUI-name ] [ sla ] [ INITIALISATION ] Reading module configuration |
Paramètre de connexion à la base mongo
| Code Block | ||||
|---|---|---|---|---|
| ||||
[2021-04-13 15:50:24] INFO : [ WebUI-name ] [ sla ] [ INITIALISATION ] [ MONGO ] Creating connection to sla database [shinken]
[2021-04-13 15:50:24] INFO : [ WebUI-name ] [ sla ] [ INITIALISATION ] [ MONGO ] Parameter load for database connection
[2021-04-13 15:50:24] INFO : [ WebUI-name ] [ sla ] [ INITIALISATION ] [ MONGO ] - database ------------------------- :〖 shinken 〗
[2021-04-13 15:50:24] INFO : [ WebUI-name ] [ sla ] [ INITIALISATION ] [ MONGO ] - uri ------------------------------ :〖 mongodb://localhost/?w=1&fsync=false 〗
[2021-04-13 15:50:24] INFO : [ WebUI-name ] [ sla ] [ INITIALISATION ] [ MONGO ] - replica_set ---------------------- :〖 〗
[2021-04-13 15:50:24] INFO : [ WebUI-name ] [ sla ] [ INITIALISATION ] [ MONGO ] - use_ssh_tunnel ------------------- :〖 False 〗
[2021-04-13 15:50:24] INFO : [ WebUI-name ] [ sla ] [ INITIALISATION ] [ MONGO ] - ssh_keyfile ---------------------- :〖 ~shinken/.ssh/id_rsa 〗
[2021-04-13 15:50:24] INFO : [ WebUI-name ] [ sla ] [ INITIALISATION ] [ MONGO ] - ssh_user ------------------------- :〖 root 〗
[2021-04-13 15:50:24] INFO : [ WebUI-name ] [ sla ] [ INITIALISATION ] [ MONGO ] - ssh_tunnel_timeout --------------- :〖 2 〗
[2021-04-13 15:50:24] INFO : [ WebUI-name ] [ sla ] [ INITIALISATION ] [ MONGO ] - use_ssh_retry_failure ------------ :〖 1 〗
[2021-04-13 15:50:24] INFO : [ WebUI-name ] [ sla ] [ INITIALISATION ] [ MONGO ] - auto_reconnect_max_try ----------- :〖 3 〗
[2021-04-13 15:50:24] INFO : [ WebUI-name ] [ sla ] [ INITIALISATION ] [ MONGO ] - auto_reconnect_sleep_between_try - :〖 3 〗
[2021-04-13 15:50:24] INFO : [ WebUI-name ] [ sla ] [ INITIALISATION ] [ MONGO ] Try to open a Mongodb connection to mongodb://localhost/?w=1&fsync=false:shinken
[2021-04-13 15:50:24] INFO : [ WebUI-name ] [ sla ] [ INITIALISATION ] [ MONGO ] Mongo connection established in 4.09ms
[2021-04-13 15:50:24] INFO : [ WebUI-name ] [ sla ] [ INITIALISATION ] [ MONGO ] Ensure mongo index done in 3.35ms
[2021-04-13 15:50:24] INFO : [ WebUI-name ] [ sla ] [ INITIALISATION ] Load from collection 28 elements info in cache done in 0.85ms |
Fin de l'initialisation du module
| Code Block | ||||
|---|---|---|---|---|
| ||||
[YYYY-MM-DD HH:MM:SS] INFO : [ WebUI-name ] [ sla ] [ INITIALISATION ] ============= Module initialized in 24.19ms ==============
[YYYY-MM-DD HH:MM:SS] INFO : [ WebUI-name ] [ sla ] [ INITIALISATION ] Found first element monitoring at 17-06-2020 10:42:52 |
Actuellement on ne sait pas consommer les broks, et répondre aux utilisateurs en même temps. On a donc une concurrence entre deux parties:
- Récupération et consommation des broks depuis le broker, et mise à jour des hôtes/checks/clusters (et tous les autres objets) depuis les informations des broks
- Réponses aux requêtes des utilisateurs (parcours des hôtes, checks, clusters ...)
Un des principaux risques est une famine d'un des deux groupes d'actions:
- Si on ne fait qu'avaler des broks et ne jamais répondre aux utilisateurs, ceci va poser problème
- Symétriquement, si on ne fait que répondre aux utilisateurs, et jamais avaler des broks, on va avoir des informations périmées, voir, on ne finira jamais de consommer de nouvelles configurations
Quand on a trop de requêtes de lectures, et qu'elles ne rendent pas la main pendant plus de 30s aux broks, on aura un log suivant (Brok BLOQUE par les requêtes):
| Code Block | ||
|---|---|---|
| ||
ERROR: [ITEMS ACCESS ORDONNANCER] [LONG LOCK] Broks management are waiting (1 threads) since 30s (> log error limit=30s) because HTTP resquests (20 threads) has the LOCK |
Quand on a trop de consommation de Broks, et que les requêtes sont bloquées (Requêtes utilisateurs BLOQUÉES par les Broks)
| Code Block | ||
|---|---|---|
| ||
ERROR: [ITEMS ACCESS ORDONNANCER] [LONG LOCK] HTTP resquests are waiting (5 threads) since 30s (> log error limit=30s) because Broks management (1 threads) has the LOCK |