Fonctionnement du module - chapitre [ MONGO ]
Log de gestion de l'AutoReconnect
L'AutoReconnect est une erreur du driver MongoDB qui survient quand :
- Un nouveau PRIMARY est élu dans un Cluster MongoDB
- Le driver trouve une erreur réseau, comme un timeout de 20 s lors de l'établissement de la connexion à la base.
Dans ce cas, Shinken tente de refaire une connexion à la base.
( voir la page Module event-manager-writer )
Tentative en cours :
[YYYY-MM-DD HH:MM:SS] INFO : [ BROKER_NAME ] [ event-manager-writer ] [ MONGO ] Mongo asked an AutoReconnect on the operation OPERATION_NAME on COLLECTION_NAME. Operation failed : X/Y |
Toutes les tentatives on échouées :
[YYYY-MM-DD HH:MM:SS] ERROR : [ BROKER_NAME ] [ event-manager-writer ] [ MONGO ] Mongo asked an AutoReconnect on the operation OPERATION_NAME on COLLECTION_NAME. Operation failed : X/Y. We tried Y time but it kept failing. |
- X : est le nombre de fois où l'opération a été tenté
- Y : est le nombre de tentative maximal de l'opération
- OPERATION_NAME : nom de l'opération. Exemple : find, find_one, list_name_collections, save ...
- COLLECTION_NAME : nom de la collection MongoDB
Fonctionnement du module - chapitre [ MANAGE BROKS ]
Suivi du nombre de Broks en attente de traitement
Le Worker du module gère les Broks provenant du démon Broker de manière continue depuis une file d'attente. Le log suivant permet de surveiller sa taille au fil du temps et de vérifier qu'elle ne reste pas élevée pendant une période prolongée:
[YYYY-MM-DD HH:MM:SS] INFO : [ BROKER_NAME ] [ event-manager-writer ] [ MANAGE BROKS ] X pending Broks waiting to be managed. |
- X = nombre de broks en attentes d'être traités
Fonctionnement du module - chapitre [ DATABASE ]
Suivi du nombre de bulks vers la base de donnée
Pour suivre le nombre de "Bulks" (groupe d'écriture vers la base Mongodb) qui sont en attente d'envois, il faut suivre le log suivant. Il permet de vérifier que les écritures en base ne s'accumulent pas, et que donc la base de données est assez rapide :
[YYYY-MM-DD HH:MM:SS] INFO : [ BROKER_NAME ] [ event-manager-writer ] [ DATABASE ] X pending database Bulks ( MongoDB groups of insert+update ) waiting to be written ( Within these Bulks => Y inserts and Z updates ) |
- X = nombre de Bulks en attente
- Y = nombre de requêtes d'inserts présentes dans l'ensemble des Bulks
- Z = nombre de requêtes d'update présentes dans l'ensemble des Bulks
Fonctionnement du module - chapitre [ MISSING DATA ]
Suivi de la protection contre les fausses détections des MISSING DATA
La détection des MISSING DATA ( données manquantes ) sur les éléments permet de garantir que l'utilisateur est averti lorsque l'état d'un élément n'est plus à jour, notamment s'il n'est plus supervisé.
Un cas qui pouvait arriver est qu'un élément était détecté par le module comme n'étant pas mis à jour à temps, mais à cause du module qui avait pris du retard sur le traitement de ses Broks ( mise à jour des données des éléments ).
Le log suivant permet de suivre une protection contre ce problème. Le module n'enregistrera pas l'élément en tant que données manquantes s'il y a des données en attente de traitement pour cet élément.
Ainsi, le log affiche le nombre d'éléments protégés contre une détection erronée.
Ce log doit être restreint aux périodes normales de forte activité du module, telles que l'application d'une nouvelle configuration, et ne doit pas se produire le reste du temps.
[YYYY-MM-DD HH:MM:SS] WARNING : [ BROKER_NAME ] [ event-manager-writer ] [ MISSING DATA ] [ POSTPONED ] X elements should be in MISSING DATA ( on Y elements managed ), but Broks concerning them are awaiting to be read. Your worker might be late. |
- X = nombre d'éléments qui auraient dû être placés en MISSING DATA, car leur dernière donnée reçue est vieille, mais dont en fait le Worker n'a pas encore eu le temps de traiter une nouvelle donnée en attente
- Y = nombre d'éléments total (hôtes + checks+ clusters) que gère ce worker