| Scroll Ignore | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||
|
Fonctionnement de la rétention
Dans Shinken Entreprise, lorsque des éléments sont en supervision, des vérifications régulières sont effectuées sur les hôtes, clusters et checks.
- Suite à ces vérifications, un statut ( OK, Attention, Critique, Inconnu ) ainsi qu’un ou plusieurs contextes ( Flapping, Période de maintenance, Prise en compte ) sont attribués à chaque élément.
- Sans rétention, lorsque Shinken doit être redémarré (maintenance du serveur de supervision, ou bien mise à jour de Shinken), ces statuts et contextes sont perdus, et les éventuelles notifications déclenchées sur un état non voulu seront envoyées !
- Activer la rétention permet de conserver les états des hôtes, clusters et checks entre les redémarrages de Shinken et ainsi bénéficier d'une vision claire de l'état des éléments supervisés à tout moment.
Cette rétention s'effectue au niveau du démon Scheduler qui est chargé d'ordonnancer la vérification des éléments et de récupérer et analyser les résultats de ces vérifications.
Type de données sauvegardées
Pour chaque élément activé dans la configuration ( hôte, check ou cluster ), les données suivantes sont sauvegardées entre autres:
Description
Le module MongodbRetention est un module de rétention qui permet de stocker dans une base mongo les différents statuts et contextes des éléments de Shinken. Après un redémarrage, les éléments récupèreront leurs statuts à partir de ce qui a été stocké par le module.
Pour plus d'explication sur le principe de la rétention, voir Rappel du fonctionnement de la rétention.
Activation du module
Ce module ne peut être activé que sur un Scheduler.
- L'activation du module s'effectue en ajoutant le nom de ce module dans le fichier de configuration du démon Scheduler.
- Pour se faire, ouvrez le fichier de configuration du Broker à l'emplacement /etc/shinken/schedulers/nom_du_scheduler.cfg, et ajoutez le nom de votre module "
MongodbRetention".
Exemple: par défaut, nous livrons un module dont le nom est "MongodbRetention".
| Code Block | ||
|---|---|---|
| ||
define scheduler {
[...]
modules MongodbRetention
[...]
} |
Pour prendre en compte le changement de configuration, redémarrez l'Arbiter:
| Code Block |
|---|
service shinken-arbiter restart |
| Anchor | ||||
|---|---|---|---|---|
|
Rappel du fonctionnement de la rétention
Dans Shinken Entreprise, lorsque des éléments sont en supervision, des vérifications régulières sont effectuées sur les hôtes, clusters et checks.
- Suite à ces vérifications, un statut ( OK, Attention, Critique, Inconnu ) ainsi qu’un ou plusieurs contextes ( Flapping, Période de maintenance, Prise en compte ) sont attribués à chaque élément.
- Sans rétention, lorsque Shinken doit être redémarré (maintenance du serveur de supervision, ou bien mise à jour de Shinken), ces statuts et contextes sont perdus, et les éventuelles notifications déclenchées sur un état non voulu seront envoyées !
- Activer la rétention permet de conserver les états des hôtes, clusters et checks entre les redémarrages de Shinken et ainsi bénéficier d'une vision claire de l'état des éléments supervisés à tout moment.
Cette rétention s'effectue au niveau du démon Scheduler qui est chargé d'ordonnancer la vérification des éléments et de récupérer et analyser les résultats de ces vérifications.
Pour plus d'informations sur le fonctionnement de la rétention dans Shinken voir La rétention des données des Schedulers.
Les données sauvegardées
Pour chaque élément activé dans la configuration ( hôte, check ou cluster ), les données suivantes sont sauvegardées entre autres:
| Type de donnée | Commentaire |
|---|---|
| Identifiant unique de l'élément | L'UUID est un champ interne à Shinken permettant d'identifier un élément ( hôte, check ou cluster ) de manière unique. |
| Données d'ordonnancement | Date de la dernière et de la prochaine vérification. |
| Statut actuel | Statut actuel de l'élément. |
| Dernier changement de statut | Date du dernier changement de statut et statut précédent. |
| Contexte | Indique si l'hôte est en Flapping, à une Prise en compte ou des périodes de maintenance. Dans le cas des Périodes de maintenance et des Prises en compte, l'auteur, date et commentaire sont également sauvegardés. |
| Résultat et résultat long | Résultat et résultat long de la dernière vérification. |
| Contacts | Ensemble des contacts ( identifiés par leur nom ) qui ont reçu une notification concernant l'élément. |
| Problèmes sources | Lorsque l'élément possède des liens avec d'autres éléments, lorsque cet élément est en erreur, l'identifiant unique des autres éléments affectés est également sauvegardé. Aussi, si un élément en erreur a affecté l'élément actuel, l'identifiant unique de l'élément source du problème est sauvegardé. |
Configuration
Exemple de fichier de configuration
| Code Block | ||
|---|---|---|
| ||
#===============================================================================
# MongodbRetention
#===============================================================================
# Daemons that can load this module:
# - scheduler
# This module save scheduler retention data (element state and scheduling) into a mongodb server
#===============================================================================
define module {
# Shinken Enterprise. Lines added by import core. Do not remove it, it's used by Shinken Enterprise to update your objects if you re-import them.
_SE_UUID |
Configurer le module de rétention de type "mongodb_retention"
Le module MongodbRetention se charge de sauvegarder la rétention dans une base de données Mongo. L'avantage de ce type de rétention est qu'il peut, contrairement à la rétention par fichiers plats, être utilisé dans un environnement distribué avec plusieurs Schedulers. Plus de détails sont disponibles sur les cas d'utilisations de ce type de rétention dans la page Configurer la rétention des données.
Activer le module
Pour l'utiliser, il faut activer ce module sur le Scheduler pour lequel on veut sauvegarder la rétention.
Cette configuration s'effectue dans le fichier de configuration du Scheduler concerné.
- la définition des Schedulers se trouve /etc/shinken/schedulers/.
- Il faut modifier la propriété modules :
- en ajoutant le nom du module que vous voulez utiliser.
- vous pouvez éventuellement, si la situation le nécessite mettre le nom de plusieurs modules ( généralement utilisé pour la migration d'une rétention à une autre )
| Code Block | ||
|---|---|---|
| ||
define scheduler { ... ... ... #======== Modules to enable for this daemon ========= # Available: core-module-d98ab73a5adb11e5a2df080027f08538 _SE_UUID_HASH c8c8f39897b928ee624da45934b38fd9 # End of Shinken Enterprise part # - PickleRetentionFile : (if you have only one scheduler into a realm) save retention data (element state and scheduling) into a file ======== Module identity ========= # Module name. Must be unique module_name MongodbRetention # Module type (to load module code). Do not edit. module_type mongodb_retention #======== Mongodb connection ========= # uri: to connect the mongodb server uri mongodb://localhost/?safe=false # If -you MongodbRetentionwant to securize your :mongodb (ifconnection you havecan moreenable thanthe one scheduler into a realm) save retention data (element state and scheduling) into a mongodb database ssh use_ssh_tunnel that will # allow all mongodb to be encrypted & authentificated with SSH # Should use a SSH tunnel (Default 0=False) # use_ssh_tunnel 0 # If the SSH connection goes wrong, then retry use_ssh_retry_failure time # Default: 1 modules # use_ssh_retry_failure 1 # SSH user/keyfile in order to connect to the MyMongodbRetention ... ... ... } |
Une fois la rétention Mongo activée sur les Schedulers concernés, il faut modifier potentiellement la configuration du module ( comme l'URI de la base Mongo pour que tous les modules de rétention pointent vers l'adresse de la base de données qui hébergera les données de rétention ).
- A noter que seuls les serveurs Mongo livrés par Shinken sont supportés. Il faut donc utiliser un serveur Shinken comme serveur pour la rétention.
- Un serveur Shinken sur une machine différente que les Schedulers peuvent également être utilisés pour sauvegarder la rétention.
Les paramètres
Le fichier de configuration livré à l'installation se trouve /etc/shinken/modules/retention-mongodb.cfg
- En fonction de votre architecture de supervision, vous aurez certainement besoin de faire plusieurs fichiers définissant des modules de rétention avec des paramètres différents.
- Pour avoir plusieurs modules de rétention mongo, copier le fichier, et à l'intérieur changer juste le nom du module, pour en avoir 2 distincts
Liste des paramètres
La liste des paramètres de ce module est :
Property
Default
Description
module_name
N/A
Nom du module
module_type
N/A
Doit être égal à mongodb_retention afin de définir un module de rétention Mongo.
uri
N/A
URI de connexion vers le serveur mongo. De la forme mongodb://adresse_du_serveur/?safe=false
use_ssh_tunnel
0
( 0 / 1 ) =>Permet d'activer l'utilisation d'un tunnel SSH pour la connexion vers le serveur Mongodb
use_ssh_retry_failure
1
Nombre de re-tentative d'ouverture du tunnel SSH en cas de problème
ssh_user
shinken
Nom de l'utilisateur utilisé pour l'authentification SSH
ssh_keyfile
~shinken/.ssh/id_rsa
Clé SSH ( privée ) utilisée pour l'authentification SSH ( note: la configuration par mot de passe n'est pas gérée ).
ssh_tunnel_timeout
2
Défini le temps, en seconde, pour que le tunnel réponde et soit considéré viable avant de lancer la connexion MongoDb à travers
mongo_timeout
10
Défini le temps maximum, en seconde, pour que l'établissement de la connexion, ainsi que pour les requêtes de lectures ou d'écritures.
mongo_max_connections_retry
3
Défini le nombre maximum de tentatives de connexions à la base MogoDB avant d'abandonner
mongo_wait_before_retry
1
Défini le temps, en seconde, entre les tentatives de connexions infructueuses
database
shinken
Nom de la base de données utilisée pour sauvegarder les données de rétention dans MongoDB
replica_set
N/A
Utilisé uniquement dans le cas d'un cluster MongoDB qui possède plusieurs replicat_sets ( espaces de stockage ).
max_number_of_workers
4
Nombre maximum de Worker de sauvegarde utilisée par le module. Le nombre de Workers sera égal au minimum entre le nombre de processeurs et ce paramètre.
worker_timeout
120
Défini le temps maximum autorisé pour que les workers d'écritures puisse travailler, y compris leurs temps de tentatives. Passé ce temps, la sauvegarde des données de rétention est considérée comme échouée.
worker_one_try_timeout
30
Défini le temps maximum, en seconde, autorisé pour qu'un worker écrive ses données de rétention dans la base MongoDB.
scheduler__retention_mongo__enable_sub_processes_memory_usage_protection
1
Cette variable permet d'activer le mécanisme de protection de surconsommation mémoire du processus: si activé, le module va attendre que la RAM (hors swap) soit disponible pour lancer un processus Worker, égal à la taille actuelle du démon Scheduler.
scheduler__retention_mongo__sub_process_memory_usage_system_reserved_memory
0
Utilisé dans le mécanisme de protection de la surconsommation mémoire, permet de définir une réserve de mémoire, en pourcentage, que le démon laisse au système.
scheduler__retention_mongo__sub_processes_memory_usage_protection_max_retry_time
5
Utilisé dans le mécanisme de protection de la surconsommation mémoire, permet de définir le temps maximum attendu par le module pour avoir la RAM disponible pour lancer un processus Worker.
nb_of_max_retention_day
7
Le module de rétention supprime automatiquement de la base les données de rétention plus âgées que ce nombre de jours. Les données âgées arrivent quand un élément ( hôte, check, cluster ) est supprimé ou désactivé de la supervision.
size_chunk_to_load
1000
( Nombre d'éléments ) => Taille d'un batch de récupération de données de rétention quand on charge la rétention
size_chunk_to_delete
1000
( Nombre d'éléments ) => Taille d'un batch de suppression des données de rétention âgées.
| Code Block | ||
|---|---|---|
| ||
define module {
#======== Module identity =========
# Module name. Must be unique
module_name MongodbRetention
# Module type (to load module code). Do not edit.
module_type mongodb_retention
#======== Mongodb connection =========
# uri: to connect the mongodb server
uri mongodb://addresse_du_serveur/?safe=false
use_ssh_tunnel 0
ssh_user shinken
ssh_keyfile ~/.ssh/id_rsa
# database: which mongodb database to use
database shinken
# Advanced option if you are running a cluster mongodb environnement
# replica_set
} |
Types de connexions vers la base de données
Pour se connecter au serveur Mongo utilisé pour la rétention, 2 méthodes sont disponibles:
- Connexion directe: Par défaut, mais non sécurisée.
- Tunnel SSH: Shinken se connecte au serveur Mongo au travers d'un tunnel SSH pour plus de sécurité
Connexion directe au serveur Mongo
Par défaut, le module de rétention se connecte de manière directe au serveur Mongo pour y lire et écrire les données de rétention.
Dans la configuration du module de rétention, on sait que la connexion se fait de manière directe lorsque le paramètre "use_ssh_tunnel" est à 0.
| Code Block | ||
|---|---|---|
| ||
define module {
#======== Module identity =========
# Module name. Must be unique
module_name MongodbRetention
...
use_ssh_tunnel 0
...
} |
Cette méthode de connexion a pour avantage d'être facile à configurer au niveau de Shinken.
- Par contre, elle oblige à permettre l'accès à la base Mongo au monde extérieur, et donc s'exposer à des problèmes de sécurité.
- La sécurisation de la base Mongo est bien sûr toujours possible ( voir Sécurisation des connexions aux bases MongoDB ), mais bien plus complexe à mettre en place.
- La méthode de connexion par SSH est donc préférable pour des raisons pratiques et de sécurité.
Connexion par SSH au serveur Mongo
Le module de rétention peut également se connecter par tunnel SSH au serveur Mongo, pour des raisons de sécurité.
Dans la configuration du serveur Mongo (/etc/mongod.conf), assurez-vous que le paramètre "bind_ip" est positionné pour n'écouter que sur l'interface locale :
| Code Block |
|---|
bind_ip=127.0.0.1 |
Depuis le serveur hébergeant le Scheduler, assurez-vous que les clés publiques SSH de l'utilisateur lançant le démon (par défaut "shinken") sont autorisées sur le serveur hébergeant Mongo :
| Code Block | ||
|---|---|---|
| ||
root@serveur_shinken # su - shinken
shinken@serveur_shinken $ ssh-keygen
shinken@serveur_shinken $ ssh-copy-id user_distant@serveur_mongo
[...]
shinken@serveur_shinken $ ssh user_distant@serveur_mongo
user_distant@serveur_mongo $ |
| Info | ||
|---|---|---|
| ||
Si vous avez un serveur qui héberge à la fois le démon Scheduler et la base MongoDB, il vous faudra également appliquer ces commandes pour autoriser l'utilisateur shinken à se connecter automatiquement sur lui-même en SSH |
Modifiez la configuration du module de rétention Mongo
mongodb server.
# Default: shinken
# ssh_user shinken
# Default: ~shinken/.ssh/id_rsa
# ssh_keyfile ~shinken/.ssh/id_rsa
# Timeout used to test if the SSH tunnel is viable or not
# Default: 2
# ssh_tunnel_timeout 2
# Timeout for reading 5000 item in second
# Default value : 10s
# mongo_timeout 10
# Number of retry if mongo is not accessible
# Default value : 3
# mongo_max_connections_retry 3
# Delay before next retry
# Default value : 1s
# mongo_wait_before_retry 1
# database: which mongodb database to use
database shinken
# Advanced option if you are running a cluster mongodb environnement
# replica_set
# Retention SAVE:
# the retention save will spawn process workers (max to 4) and
# such process can fail (timeout)
# Worker timeout: Global time for your workers to work. If a worker still
# runs after worker_timeout seconds (and so numerous try)), then it will be killed and the error will
# be raised into your monitoring
# Default: 120
# worker_timeout 120
# Worker try timeout: Time for a one try data save. If one worker process still runs after
# worker_one_try_timeout seconds, it will be killed and a new worker process will be spawn
# to replace it
# note: it must be lower than the worker_timeout
# Default: 30
# worker_one_try_timeout 30
# Max number of workers: if you want to limit the number of workers launched, you can change this parameter
# By default the number of workers will be the number of CPUs but no more than max_number_of_workers (by default 4)
# max_number_of_workers 4
#======== IMPORTANT =============
# Note that if the parameter "use_ssh_tunnel" is set to 1,
# the mongodb connection will be launched through a SSH tunnel
# opened from the scheduler server to the mongodb server.
# It will automatically parse the URI parameter to get the distant server
# and will create a SSH tunnel by using either the user defined by the "ssh_user" property
# or the shinken user.
# The SSH key used for this is the one that is automatically generated
# at the installation or the key defined by the parameter "ssh_keyfile".
# You can deploy it by launching on the scheduler server:
# ssh-copy-id -i ~shinken/.ssh/id_rsa.pub shinken@MONGODB-SERVER
#======== Memory protection =========
# Are the module worker process are waiting for enough
# memory to be available before being launch. Default: 1 (enabled)
scheduler__retention_mongo__enable_sub_processes_memory_usage_protection 1
# The sub process memory usage protection can have a system reserved memory
# that won't be used by theses sub process when launched
# By default: 0 (no reserved memory)
# Example: 10 (means 10% of the total memory is reserved for the system)
scheduler__retention_mongo__sub_process_memory_usage_system_reserved_memory 0
# If a sub process cannot be started because of the protection, how many seconds
# it will be retry and wait that the system memory is freed until it fail to start
# By default: 5 (seconds)
scheduler__retention_mongo__sub_processes_memory_usage_protection_max_retry_time 5
#======== INTERNAL options =========
#INTERNAL : DO NOT EDIT FOLLOWING PARAMETER WITHOUT YOUR DEDICATED SUPPORT
# == Number of day we conserve retention data, after this time, we will delete data. By default it is 7 days ==
#nb_of_max_retention_day 7
# == maximum number of elements load in one bulk pass ==
#size_chunk_to_load 1000
# == maximum number of elements delete in one bulk pass ==
#size_chunk_to_delete 1000
} |
Détails des sections composant le fichier de configuration
Identification du module
Il est possible de définir plusieurs instances de module de type "MongodbRetention" dans votre architecture Shinken.
- Chaque instance devra avoir un nom unique.
| Warning |
|---|
Il est conseillé de n'avoir plusieurs modules de rétention que dans le cas d'une migration. (Ex: passage d'une base de données base1 à une base2, on aura un module MongodbRetention avec la base1, un autre avec la base2, on désactivera alors le premier module pour le prochain redémarrage)) |
| Nom | Type | Unité | Défaut | Commentaire | ||
|---|---|---|---|---|---|---|
| Texte | --- | MongodbRetention | Nous vous conseillons de choisir un nom en fonction de l'utilisation du module pour que votre configuration soit simple à maintenir. Doit être unique. | ||
| Texte | --- | mongodb_retention | Ne peut être modifié. |
Accès à la base MongoDB
Cette configuration s'effectue dans le fichier de configuration du module.
Pour se connecter à la base MongoDB utilisée pour le stockage des données, 2 méthodes sont disponibles:
- Connexion directe : Par défaut, mais non sécurisée.
- Tunnel SSH : le module se connecte à la base MongoDB au travers d'un module SSH pour plus de sécurité
Paramètres communs
| Nom | Type | Unité | Défaut | Commentaire | ||
|---|---|---|---|---|---|---|
| Texte | URL | mongodb://localhost/?w=1&fsync=false | Vous pouvez trouver la syntaxe de l'uri de MongoDB à l'adresse https://docs.mongodb.com/manual/reference/connection-string/ | ||
| Texte | --- | shinken | Nom de la base de données où sont stockés les données de rétention | ||
| Entier | --- | 3 | Défini le nombre d'essai de reconnexion à la base mongo si celui-ci est inaccessible | ||
| Entier | secondes | 1 | Nombre de secondes à attendre entre chaque essai de connexion à la base mongo | ||
| Texte | --- | --- | Nom du replica-set. Utilisé uniquement dans le cas d'un cluster MongoDB qui possède plusieurs replica_sets ( espaces de stockage ). | ||
Connexion directe au serveur MongoDB
Par défaut, le module se connecte de manière directe à la base MongoDB, définie avec les paramètres communs listés ci-dessus, car le paramètre "use_ssh_tunnel" est à 0.
Connexion par SSH au serveur Mongo
Par défaut, le module se connecte de manière directe à la base MongoDB pour y lire et écrire les données.
Dans la configuration du module, on sait que la connexion se fait de manière directe lorsque le paramètre "use_ssh_tunnel" est à 0.
- Cette méthode de connexion a pour avantage d'être facile à configurer au niveau de Shinken.
- Par contre, elle oblige à permettre l'accès à la base MongoDB au monde extérieur, et donc s'exposer à des problèmes de sécurité.
La sécurisation de la base MongoDB est bien sûr toujours possible ( voir Sécurisation des connexions aux bases MongoDB ) mais bien plus complexe à mettre en place.
La méthode de connexion par SSH est donc préférable pour des raisons pratiques et de sécurité.
En effet, le paramétrage de MongoDB permet de définir sur quelle interface réseau ce dernier écoute les requêtes.
En n'autorisant seulement interface réseau avec l'adresse 127.0.0.1, cela évite d'ouvrir la base au monde extérieur.
Dans la configuration de la base MongoDB ( /etc/mongod.conf ), assurez-vous que le paramètre "bind_ip" est positionné pour n'écouter que sur l'interface locale:
bind_ip=127.0.0.1
Dans cette configuration la base MongoDB écoute que sur l'interface réseau local, pour que le module se connecte, il faut passer par un tunnel SSH. Pour ce faire activez les options suivantes :
| Nom | Type | Unité | Défaut | Commentaire | ||
|---|---|---|---|---|---|---|
| Booléen | --- | 0 |
| ||
| Entier | Nombre d'essais | 1 | Spécifie le nombre supplémentaire de tentatives lors de l'établissement du tunnel SSH si ce dernier n'arrive pas à être établi | ||
| Texte | utilisateur unix | shinken | L'utilisateur avec lequel le tunnel sera établi | ||
| Texte | chemin de fichier | ~shinken/.ssh/id_rsa | La clé SSH privée présente sur le serveur Shinken qui sera utilisé pour établir le tunnel. | ||
| Entier | secondes | 10 | Spécifie le timeout en secondes de la vérification du tunnel SSH avant que la connexion vers MongoDB soit effectuée |
Le tunnel SSH va permettre au module de se connecter comme si ses requêtes étaient locales à la base MongoDB ( en 127.0.0.1 )
- Connectez-vous avec l'utilisateur lançant le démon sur le serveur Shinken
- Générez la paire de clés SSH si nécessaire
Copiez la clé publique sur le serveur mongo
Code Block language bash title Copie de la clé SSH root@serveur_shinken # su - shinken shinken@serveur_shinken $ ssh-keygen shinken@serveur_shinken $ ssh-copy-id user_distant@serveur_mongo [...] shinken@serveur_shinken $ ssh user_distant@serveur_mongo user_distant@serveur_mongo $- Cette manipulation est aussi nécessaire dans le cas où la base MongoDB est sur le même serveur que le module, même si le tunnel est ouvert localement.
Utilisation des workers
Afin de répartir la tâche de sauvegarde de la rétention sur plusieurs processus, le module utilise des workers qui travailleront en parallèle. Il est possible de les configurer via les paramètres suivants :
| Nom | Type | Unité | Défaut | Commentaire | ||||
|---|---|---|---|---|---|---|---|---|
| Entier | --- | 4 | Nombre de workers maximum( nombre de clone du module ) qui traitent la sauvegarde de la rétention en parallèle. Un worker sera créé pour chaque CPU disponible sur la machine, mais jamais plus que la limite définie par ce paramètre.
| ||||
| Entier | secondes | 120 | Temps maximum d'exécution d'un worker. Si ce temps est dépassé le worker est éteint et une erreur est remontée. | ||||
| Entier | secondes | 30 | Temps maximum d'exécution d'une sauvegarde au sein d'un worker. Si ce temps est dépassé le worker est éteint et une erreur est remontée. (Ne doit pas être plus grand que le |
Protection de la mémoire
Au démarrage du module, des workers sont créés comme vu précédemment. Ces workers consomment de la mémoire RAM. Il est possible de configurer une protection pour éviter de créer des workers si ceux-ci seront en manque de mémoire RAM.
| Nom | Type | Unité | Défaut | Commentaire | ||
|---|---|---|---|---|---|---|
| Booléen | --- | 1 |
| ||
| Entier | pourcentage | 0 | Pourcentage de mémoire réservé au système (qui ne sera donc pas utilisé par le module et ses workers). Par défaut, 0, signifie que rien n'est réservé au système. | ||
| Entier | secondes | 5 | Si la protection mémoire est active, ce temps défini l'attente maximum du module avant de considérer que son démarrage est en échec si il n'y a pas assez de mémoire disponible. |
Paramètres de gestion de la rétention
Il est possible de définir certains paramètres de gestion de la rétention tel que le nombre de jours à garder
| Warning |
|---|
Cette partie ne doit pas être modifiée sans votre support |
| Nom | Type | Unité | Défaut | Commentaire | ||
|---|---|---|---|---|---|---|
| Entier | jours | 7 | Nombre de jours avant de supprimer une donnée de rétention | ||
| Entier | --- | 1000 | Nombre maximum d'éléments chargés depuis la base en une fois | ||
| Entier | --- | 1000 | Nombre maximum d'éléments qui peuvent être supprimés de la base en une fois |
| Code Block | ||
|---|---|---|
| ||
define module {
...
#======== Mongodb connection =========
# uri: to connect the mongodb server
uri mongodb://ip_du_serveur/?safe=false
use_ssh_tunnel 1
use_ssh_retry_failure 1
ssh_user user_distant
ssh_keyfile /chemin/vers/cle/ssh (par defaut ~/.ssh/id_rsa)
ssh_tunnel_timeout 2
...
} |
Vérifiez la configuration
Il se peut également que plusieurs royaumes veuillent définir une rétention Mongo sur un serveur différent pour chaque royaume. Dans ce cas, il faut faire plusieurs définitions de module de rétention.
| Info | ||
|---|---|---|
| ||
Même si ce n'est pas obligatoire, nous vous conseillons de faire un fichier séparé par définition de module nommé du nom du module de rétention ( dans un but de clarté de votre configuration ) |
| Note |
|---|
Ne pas utiliser "localhost" ou "127.0.0.1" comme URI de la base Mongo lorsqu'il y a plusieurs Schedulers dans le même royaume. Des explications détaillées sur ce problème sont présentes dans la page Configurer la rétention des données. |
Gestion de la reconnexions
Dans certains cas, il se peut que la connexion à mongo ait besoin de plusieurs tentatives (Ex. : coupures réseau, sauvegarde externe de la base en cours ...)
Afin de déterminer les options pour se reconnecter il faut utiliser les options suivantes :
- Le paramètre "mongo_max_connections_retry" permet de déterminer le nombre d'essais de connexions maximum qui sera tenté avant d'échouer. Par défaut, cette valeur est de 3.
- Le paramètre "mongo_wait_before_retry" permet de définir le temps d'attente entre deux tentatives de connexions. La valeur par défaut est de 1 seconde.
| Code Block | ||
|---|---|---|
| ||
define module {
#======== Module identity =========
# Module name. Must be unique
module_name MongodbRetention
# Module type (to load module code). Do not edit.
module_type mongodb_retention
...
# Number of retry if mongo is not acessible
# Default value : 3
mongo_max_connections_retry 3
# Delay before next retry
# Default value : 1s
mongo_wait_before_retry 1
...
} |
| Info | ||
|---|---|---|
| ||
Si ces options ne sont pas précisées, les valeurs par défaut seront utilisées. |
| Note |
|---|
La durée de la sauvegarde de la rétention ne peut excéder le délai d'extinction des démons (fixé à 120 secondes par défaut), quelle que soit la valeur des options précédemment définies. |
Gestion du nombre de sous processus de sauvegarde
Afin d'accélérer la sauvegarde de la rétention, cette dernière est faite par des processus Workers qui permettent d'utiliser plusieurs CPU pour sérialiser les données de rétention.
Le lancement des processus worker se fait en deux étapes:
- création d'un premier processus fils au Scheduler, qui va nettoyer sa mémoire au maximum afin que ses propres fils ( les workers ) prennent le moins de mémoire possible.
- lancement de N processus workers:
- N = minimum entre le nombre de CPU du serveur, et le paramètre max_number_of_workers
- chaque worker ne va gérer que 1/N des données de rétention à sauvegarder
- Le paramètre "worker_one_try_timeout" permet de définir le temps d'attente pour un seul sous-processus.
- S'il dépasse ce temps, le sous-processus est tué et relancé.
- La valeur par défaut est de 30 ( en secondes ).
- Le paramètre "worker_timeout" permet de déterminer le temps maximum laissé à tous les sous-sous-processus pour fonctionner ( comprenant leurs différentes relances ).
- Par défaut, cette valeur est de 120 ( en secondes ).
| Code Block | ||
|---|---|---|
| ||
define module {
#======== Module identity =========
# Module name. Must be unique
module_name MongodbRetention
# Module type (to load module code). Do not edit.
module_type mongodb_retention
...
# Worker timeout: Global time for your workers to work. If a worker still
# runs after worker_timeout seconds (and so numerous try)), then it will be killed and the error will
# be raised into your monitoring
# Default: 120
worker_timeout 120
# Worker try timeout: Time for a one try data save. If one worker process still runs after
# worker_one_try_timeout seconds, it will be killed and a new worker process will be spawn
# to replace it
# note: it must be lower than the worker_timeout
# Default: 30
worker_one_try_timeout 30
# Max number of workers: if you want to limit the number of workers launched, you can change this parameter
# By default the number of workers will be the number of CPUs but no more than max_number_of_workers (by default 4)
max_number_of_workers 4
...
} |
| Info | ||
|---|---|---|
| ||
Si ces options ne sont pas indiquées, les valeurs par défaut seront utilisées. |
Détails de l'emplacement des données de rétention
Les données de rétention via le module MongodbRetention sont donc sauvegardées via le moteur de base de données Mongodb.
La base utilisée par défaut pour la rétention est la base shinken.
Afin de distinguer les hôtes des checks, deux collections sont utilisées :
- pour les hôtes, la collection retention_hosts_raw
- pour les checks, la collection retention_services_raw
Voici la visualisation des collections via l'utilitaire RoboMongo permettant de se connecter aux bases Mongodb :
| Panel |
|---|