Contexte
Le module SLA peut être accroché à deux endroits : le Broker et la WebUI.
L'accrocher sur la WebUI permet :
- De récupérer les valeurs de SLA ( Service Level Agreement ) des éléments supervisés stockés dans la base de données MongoDB définie dans le fichier de configuration ci-dessous.
- De modifier la méthode de lecture de la tendance des SLA ( par exemple, choisir de considérer un statut "Attention" comme une période positive de SLA, ou encore d'exclure les périodes de maintenance dans l'interprétation de la tendance ).
Les deux modules étant complémentaires ( le module SLA sur le Broker étant l'écrivain et celui de la WebUI étant le lecteur ), Shinken fournit un seul fichier de configuration commun entre les deux, ceci permettant de garder une cohérence entre l'écriture et la lecture des SLA. Avoir le même fichier, évitera de répéter la même valeur dans deux fichiers de configuration dans le cas des paramètres communs. |
Activation du module
Les modules de type "sla" sont des modules qui doivent être activés sur un module de type "webui", qu'on appellera le module parent.
- L'activation du module s'effectue en ajoutant le nom du module dans la configuration du module parent.
- Pour cela, il faut ouvrir le fichier de configuration du module parent ( de type "
sla"), et ajouter dans le paramètre modules, le nom du module de type"sla".
- Pour cela, il faut ouvrir le fichier de configuration du module parent ( de type "
- Il est possible de faire plusieurs modules de type "
sla".- Cela permet, par exemple, d'avoir des configurations différentes en fonction des royaumes.
- S'il y a plusieurs modules de type
"présents dans l'architecture, il ne faut pas oublier d'activer le module de typewebui""dans la configuration de chacun d'eux.sla"
- Contraintes :
- Activable uniquement sur un module de type
"webui"( voir la page Module WebUI ). - Il ne peut y avoir qu'un seul module de type
"sla"sur un module de type "webui" ( voir la page Module WebUI ).
- Activable uniquement sur un module de type
Pour prendre en compte le changement de configuration, il faut redémarrer l'Arbiter :
service shinken-arbiter restart |
Exemple d'activation du module nommé "sla" sur le module nommé "WebUI" ( configuration livrée par défaut par Shinken )
L'exemple suivant
- active le module
"sla", - sur le module
"WebUI",dont la configuration est dans le fichier /etc/shinken/modules/webui.cfg.
Modification dans le fichier du module /etc/shinken/modules/webui.cfg :
define module {
[...]
modules Module 1, Module 2, Module 3, sla
[...]
} |
Puis redémarrage de l'Arbiter
service shinken-arbiter restart |
Créer un nouveau module de type livedata_module_sla_provider
Pour pouvoir configurer un module de type "sla", il faut faire un nouveau fichier de configuration grâce au fichier d'exemple fourni par défaut.
- Pour commencer, il faut choisir le nom du nouveau module.
- Pour l'exemple, on l'appelle "
Mon-Module-sla". - Remplacer dans l'exemple le mot "
Mon-Module-Livedata-Sla-Provider" par le nom qui a été choisi.
- Pour l'exemple, on l'appelle "
- Puis, il faut créer le fichier de configuration :
Copier le fichier de définition du module d'exemple : /etc/shinken-user-example/configuration/daemons/brokers/modules/sla/sla-example.cfg dans le répertoire de définition des modules /etc/shinken/modules/ .
( Exemple : /etc/shinken/modules/Mon-Module-sla.cfg )
cp /etc/shinken-user-example/configuration/daemons/brokers/modules/sla/sla-example.cfg /etc/shinken/modules/Mon-Module-sla.cfg
- Ensuite, il faut modifier le fichier nouvellement créé pour configurer le nouveau module.
Il faut vérifier que le fichier appartienne à l'utilisateur shinken et qu'il possède le droit d'édition. Si ce n'est pas le cas, il faut effectuer les commandes suivante :
chown -R shinken:shinken /etc/shinken/modules/Mon-Module-sla.cfg chmod u+w /etc/shinken/modules/Mon-Module-sla.cfg
On change le nom du module en
"Mon-Module-sla"dans le fichier /etc/shinken/modules/sla.cfg... # ─── Module name [ Must be unique ] [ MANDATORY ] ─── # ─── ─── module_name Mon-Module-sla ...
Ensuite, il faut ajouter le nouveau module dans le module de type
"broker_module_livedata"correspondant.Dans notre exemple, on ajoute le module
"Mon-Module-Livedata-Sla-Provider"au module"broker-module-livedata"définie dans le fichier /etc/shinken/modules/webui.cfgdefine module { [...] modules Module 1, Module 2, Module 3, Mon-Module-sla [...] }
Puis pour finir, il faut redémarrer l'Arbiter pour que le Broker puisse prendre en compte ce nouveau module.
service shinken-arbiter restart
Configuration
La configuration du module se trouve par défaut dans le fichier : /etc/shinken/modules/sla.cfg
- Un exemple de configuration est également disponible dans /etc/shinken-user-example/configuration/daemons/brokers/modules/sla/sla-example.cfg
Exemple de fichier de configuration
# CFG_FORMAT_VERSION 1 ( SHINKEN : DON'T TOUCH THIS LINE )
#================================================================================
# sla
#================================================================================
# Daemons that can load this module:
# - broker (to save sla information into a mongodb database)
# Modules that can load this module:
# - WebUI (to display sla data to the users)
# This module compute and save SLA values into a mongodb database
#================================================================================
define module {
# ┌─────────────────────────────────────────────────────────────────────────────────────────────────────┐ #
# │ ────────────────────────────────────── MODULE IDENTITY ────────────────────────────────────── │ #
# └─────────────────────────────────────────────────────────────────────────────────────────────────────┘ #
# ─── Module name [ Must be unique ] [ MANDATORY ] ───
# ─── ───
module_name sla
# ─── Module type [ Do not edit ] [ MANDATORY ] ───
# ─── ───
module_type sla
# ┌─────────────────────────────────────────────────────────────────────────────────────────────────────┐ #
# │ ────────────────────────────────────── MODULE OPTIONS ─────────────────────────────────────── │ #
# └─────────────────────────────────────────────────────────────────────────────────────────────────────┘ #
# ─── Duration in day to keep SLA info. ───
# ─── If value is -1 (kept forever) the MongoDB database will grow endlessly. ───
# ───
# Default : -1 => kept forever ( days ) ───
# ─── -> Recommended : 547 ( corresponds to 18 months ) ───
# ───
# nb_stored_days 547
# ─── Time of day when cleanup of SLA is performed ───
# ─── When nb_stored_days is set : daily cleanup is done at requested time ───
# ───
# Default : 03:02 ───
# ─── -> format is HH:MM with ───
# ─── -> HH: are the hour of the day (an integer between 0 and 23) ───
# ─── -> MM: are the minutes (an integer between 0 and 59) ───
# ───
# time_when_delete_old_SLA 03:02
# ─── Days to keep raw SLA. ───
# ─── In case of issue, these data will be used to re-perform SLA computation. ───
# ─── The drawback of this feature is that it takes more disk space. ───
# ───
# Default : 7 ( days ) ───
# ─── ───
# keep_raw_sla_day 7
# ┌─────────────────────────────────────────────────────────────────────────────────────────────────────┐ #
# │ ────────────────────────────────────── SLA CALCULATION ────────────────────────────────────── │ #
# └─────────────────────────────────────────────────────────────────────────────────────────────────────┘ #
# ─── Some status can impact ───
# ─── -> positively (counted as OK/UP) ───
# ─── -> negatively (counted as CRITICAL/DOWN) ───
# ─── -> not impact the SLA ───
# ─── (is not counted, meaning the period of study is reduced by the period that is not counted). ───
# ─── This configuration aims at giving Shinken administrators a way to configure ───
# ─── how the SLA are calculated. ───
# ─── SLA are computed on a daily basis. ───
# ─── SLA of the current day are always recomputed after a configuration change. ───
# ─── SLA from days before are by default not recomputed. ───
# ───
# Default : 0 => Disable ( old SLA will not be recalculated ) ───
# ... : 1 => Enable ( old SLA will be recomputed with current settings ) ───
# ─── ───
# recompute_old_sla 0
# ─── Warning periods ───
# ───
# Default : 0 => Warning counts as DOWN ───
# ... : 1 => Warning counts as UP ───
# ─── ───
# warning_counts_as_ok 0
# ─── Unknown periods ───
# ───
# Default : include => "Unknown" status is counted negatively in the SLA. ───
# ... : exclude => "Unknown" are not counted from SLA considered period. ───
# ... : ok => "Unknown" are considered as UP periods ───
# ─── ───
# unknown_period include
# ─── No_data periods ( "Missing data" and "Shinken inactive" status ) ───
# ───
# Default : include => Only status is considered. "Missing data" and "Shinken inactive" ───
# status are counted negatively in the SLA. ───
# ... : exclude => No_data are not counted from SLA considered period. ───
# ... : ok => No_data are considered as UP periods. ───
# ─── ───
# no_data_period include
# ─── Downtime periods ───
# ───
# Default : include => Only status is considered. ───
# ... : exclude => Downtimes are not counted from SLA considered period. ───
# ... : ok => Downtimes are considered as UP periods. ───
# ... : critical => Downtimes are considered as DOWN periods. ───
# ─── ───
# downtime_period include
# ┌─────────────────────────────────────────────────────────────────────────────────────────────────────┐ #
# │ ───────────────────────────────────── SLA STORED OUTPUT ───────────────────────────────────── │ #
# └─────────────────────────────────────────────────────────────────────────────────────────────────────┘ #
# ─── This option enables or disables storing sla outputs. ───
# ───
# Default : 1 => Enable ( the output will be stored ) ───
# ... : 0 => Disable ( the output and long output will not be stored ───
# downtime and acknowledge will still be stored ) ───
# ─── ───
# store_output 1
# ─── This option enables or disables storing sla long outputs. ───
# ───
# Default : Enable => 1 ( the long output will be stored ) ───
# ... : Disable => 0 ( the long output will not be stored ───
# output, downtime and acknowledge will still be stored ) ───
# ─── ───
# store_long_output 1
# ─── This option will be used to filter which outputs and long outputs ───
# ─── to store depending on the status of the sla. ───
# ───
# Default : empty => ( all output states are stored ) ───
# ... : list of status => ( format is State1, State2, ... ) ───
# ─── -> State ok :OK ───
# ─── -> State warning :WARNING ───
# ─── -> State critical:CRITICAL ───
# ─── -> State unknown :UNKNOWN ───
# ─── Example : OK, UNKNOWN ───
# ───
# list_of_stored_output_status
# ┌─────────────────────────────────────────────────────────────────────────────────────────────────────┐ #
# │ ──────────────────────────────────── DATABASE CONNECTION ──────────────────────────────────── │ #
# └─────────────────────────────────────────────────────────────────────────────────────────────────────┘ #
# ───────────────── MongoDB parameters ──────────────────────────────────────────────────────────────── #
# ─── MongoDB uri definition . You can find the mongodb uri syntax at ───
# ─── https://docs.mongodb.com/manual/reference/connection-string/ ───
# ───
# Default : mongodb://localhost/?w=1&fsync=false ───
# ─── ───
# uri mongodb://localhost/?w=1&fsync=false
# ─── Which database contains sla data ───
# ───
# Default : shinken ───
# ─── ───
# database shinken
# ─── username/password to authenticate to MongoDB. ───
# ─── Both parameters must be provided for authentication to function correctly. ───
# ─── ───
# database__username
# ─── ───
# database__password
# ─── SSH tunnel activation to secure your mongodb connection ───
# ─── That will allow all mongodb to be encrypted & authenticated with SSH ───
# ───
# Default : 0 => Disable ( disable ssh tunnel ) ───
# ... : 1 => Enable ( enable ssh tunnel ) ───
# ─── ───
# use_ssh_tunnel 0
# ─── If the SSH connection goes wrong, then retry use_ssh_retry_failure time before_shinken_inactive ───
# ───
# Default : 1 ( number of retry ) ───
# ─── ───
# use_ssh_retry_failure 1
# ─── SSH user to connect to the mongodb server. ───
# ───
# Default : shinken ───
# ─── ───
# ssh_user shinken
# ─── SSH keyfile to connect to the mongodb server. ───
# ───
# Default : ~shinken/.ssh/id_rsa ───
# ─── ───
# ssh_keyfile ~shinken/.ssh/id_rsa
# ─── SSH Timeout used to test if the SSH tunnel is viable or not, in seconds. ───
# ───
# Default : 10 ( seconds ) ───
# ─── ───
# ssh_tunnel_timeout 10
# ────────────── AutoReconnect Management ───────────────────────────────────────────────────────────── #
# ─── When MongoDB require you to reconnect ( For example, It can occur when a new PRIMARY is elected ───
# ─── in a MongoDB cluster ), it will raised the MongoDB AutoReconnect exception. ───
# ─── How many try to reconnect before module go in error ───
# ───
# Default : 4 ( number of try ) ───
# ─── ───
# auto_reconnect_max_try 4
# ─── Time between each try ───
# ───
# Default : 3 ( seconds ) ───
# ─── ───
# auto_reconnect_sleep_between_try 3
# ─── NOTE: Change these values only if you have a MongoDB cluster and you change the ───
# ─── heartbeatTimeoutSecs of your MongoDB replica set ───
# ─── The value of auto_reconnect_max_try * auto_reconnect_sleep_between_try must be higher than ───
# ─── heartbeatTimeoutSecs in the rs.conf(); of your MongoDB replica set. ───
# ┌─────────────────────────────────────────────────────────────────────────────────────────────────────┐ #
# │ ─────────────────────────────────── WORKERS IN THE BROKER ─────────────────────────────────── │ #
# └─────────────────────────────────────────────────────────────────────────────────────────────────────┘ #
# ─── This module will use workers in the broker, each worker will manage a shard of all hosts/checks. ───
# ─── This parameter is used by the broker to set the number of workers. ───
# ─── Each worker will use one CPU, which will balance the sla processing load among CPUs. ───
# ───
# Default : 1 => X workers ───
# ─── ───
# broker_module_nb_workers 1
# ┌─────────────────────────────────────────────────────────────────────────────────────────────────────┐ #
# │ ───────────────────────────────────── INTERNAL OPTIONS ────────────────────────────────────── │ #
# └─────────────────────────────────────────────────────────────────────────────────────────────────────┘ #
# ─── INTERNAL : DO NOT EDIT FOLLOWING PARAMETER WITHOUT YOUR DEDICATED SUPPORT ───
# ─── Broker idle time before considering that Shinken is inactive. ───
# ─── Use this if you have Broker loop time that exceeds 30 seconds ───
# ───
# Default : 30 ( seconds ) ───
# ─── ───
# time_before_shinken_inactive 30
# ─── Maximum number of elements archived in one bulk pass. ───
# ─── Use this if at 00:05 (archive time) your MongoDB is saturated ───
# ───
# Default : 10 000 ( number of elements ) ───
# ─── ───
# size_chunk_to_archive 10000
# ─── Time between two chunk to archive. ───
# ─── Use this if at 00:05 (archive time) your MongoDB is saturated ───
# ───
# Default : 0.1 ( seconds ) ───
# ─── ───
# time_between_two_chunks 0.1
# ─── Max number of sla remove each daily_clean_pause_time. ───
# ─── Use if nb_stored_days is not -1. ( Daily clean time is activated ) ───
# ─── Use this if at 03:02 (daily clean time) your MongoDB is saturated. ───
# ───
# Default : 10 000 ( number of sla ) ───
# ─── ───
# daily_clean_batch_size 10000
# ─── Delay between 2 sla clean. ───
# ─── Use if nb_stored_days is not -1. ( Daily clean time is activated ) ───
# ─── Use this if at 03:02 (daily clean time) your MongoDB is saturated. ───
# ───
# Default : 2 ( seconds ) ───
# ─── ───
# daily_clean_pause_time 2
# ─── Max number of sla archive migrate save at same time. ───
# ─── Use this if after an Shinken update your MongoDB is saturated. ───
# ───
# Default : 1 000 ( sla ) ───
# ─── ───
# broker_module_sla_migration_batch_size 1000
# ─── Delay between 2 migrating batch save. ───
# ─── Use this if after an Shinken update your MongoDB is saturated. ───
# ───
# Default : 0.1 ( seconds ) ───
# ─── ───
# broker_module_sla_migration_pause_time 0.1
# ─── Split historical sla_archive collection in daily archive collections ───
# ─── As this may require extra disk space to run, you can disable it here in order to delay it until ───
# ─── more disk space is available. ───
# ─── After completion, performance and disk space management will be greatly improved ───
# ───
# Default : 1 => Enable ───
# ... : 0 => Disable ───
# ─── ───
# broker__module_sla__enable_migration_sla_archive_in_daily_collections 1
}
|
Détails des sections composant le fichier de configuration
Identification du module
# ┌─────────────────────────────────────────────────────────────────────────────────────────────────────┐ #
# │ ────────────────────────────────────── MODULE IDENTITY ────────────────────────────────────── │ #
# └─────────────────────────────────────────────────────────────────────────────────────────────────────┘ #
# ─── Module name [ Must be unique ] [ MANDATORY ] ───
# ─── ───
module_name sla
# ─── Module type [ Do not edit ] [ MANDATORY ] ───
# ─── ───
module_type sla
|
Il est possible de définir plusieurs instances de module de type sla dans une architecture Shinken.
- Chaque instance devra avoir un nom unique.
|
Suppression des anciennes entrées dans la base d'archives du module SLA ( Inutilisé sur la WebUI )
# ─── Duration in day to keep SLA info. ───
# ─── If value is kept forever the MongoDB database will grow endlessly. ───
# ───
# Default : -1 => kept forever ( days ) ───
# ─── -> Recommended : 547 ( corresponds to 18 months ) ───
# ───
# nb_stored_days 547
# ─── Time of day when cleanup of SLA is performed ───
# ─── When nb_stored_days is set : daily cleanup is done at requested time ───
# ───
# Default : 03:02 ───
# ─── -> format is HH:MM with ───
# ─── -> HH: are the hour of the day (an integer between 0 and 23) ───
# ─── -> MM: are the minutes (an integer between 0 and 59) ───
# ───
# time_when_delete_old_SLA 03:02 |
Les entrées dans la base d'archives du module SLA sont supprimées et archivées toutes les 24 h.
|
Si le Broker ( et donc la WebUI ) est éteint et que la suppression n'est pas faite depuis plus de 24 h, elle se fera automatiquement au démarrage du Broker. |
S'il n'y a aucune trace du dernier nettoyage ou que le dernier nettoyage date de plus de 24 heures, le nettoyage de la base d'archives du module SLA s'exécutera de nouveau. |
Sauvegarde des SLA brut ( inutilisé sur la WebUI )
# ─── Days to keep raw SLA. ───
# ─── In case of issue, these data will be used to re-perform SLA computation. ───
# ─── The drawback of this feature is that it takes more disk space. ───
# ───
# Default : 7 ( days ) ───
# ───
# keep_raw_sla_day 7 |
Afin de gérer le flux de données, Shinkenn enregistre sous un format brut ( raw_sla ) les informations de SLA. Toutes les nuits, ces données sont agrégées dans un nouveau format ( sla_archive ) pour accélérer la lecture et réduire l'espace de stockage nécessaire.
S’il y a une erreur lors du passage entre les deux formats, des données peuvent être irrémédiablement perdues. Afin d'éviter de perdre des données lorsque survient ce type d'erreur, il est possible de conserver les données brutes quelque temps.
Le paramètre "keep_raw_sla_day" permet de choisir combien de temps garder ces données.
Il est possible de diminuer ce paramètre si l'espace disque est contraint et que les données SLA ne sont pas primordiales. Inversement, si les données SLA sont critiques augmenter ce nombre permet de limiter la perte de données SLA.
|
La récupération est possible qu'avec l'aide du support dédié. |
Option de lecture du taux de SLA
# ┌─────────────────────────────────────────────────────────────────────────────────────────────────────┐ #
# │ ────────────────────────────────────── SLA CALCULATION ────────────────────────────────────── │ #
# └─────────────────────────────────────────────────────────────────────────────────────────────────────┘ #
# ─── Some status can impact ───
# ─── -> positively (counted as OK/UP) ───
# ─── -> negatively (counted as CRITICAL/DOWN) ───
# ─── -> not impact the SLA ───
# ─── (is not counted, meaning the period of study is reduced by the period that is not counted). ───
# ─── This configuration aims at giving Shinken administrators a way to configure ───
# ─── how the SLA are calculated. ───
# ─── SLA are computed on a daily basis. ───
# ─── SLA of the current day are always recomputed after a configuration change. ───
# ─── SLA from days before are by default not recomputed. ───
# ───
# Default : 0 => Disable ( old SLA will not be recalculated ) ───
# ... : 1 => Enable ( old SLA will be recomputed with current settings ) ───
# ───
# recompute_old_sla 0
# ─── Warning periods ───
# ───
# Default : 0 => Warning counts as DOWN ───
# ... : 1 => Warning counts as UP ───
# ───
# warning_counts_as_ok 0
# ─── Unknown periods ───
# ───
# Default : include => "Unknown" status is counted negatively in the SLA. ───
# ... : exclude => "Unknown" are not counted from SLA considered period. ───
# ... : ok => "Unknown" are considered as UP periods ───
# ───
# unknown_period include
# ─── No_data periods ( "Missing data" and "Shinken inactive" status ) ───
# ───
# Default : include => Only status is considered. "Missing data" and "Shinken inactive" ───
# status are counted negatively in the SLA. ───
# ... : exclude => No_data are not counted from SLA considered period. ───
# ... : ok => No_data are considered as UP periods. ───
# ───
# no_data_period include
# ─── Downtime periods ───
# ───
# Default : include => Only status is considered. ───
# ... : exclude => Downtimes are not counted from SLA considered period. ───
# ... : ok => Downtimes are considered as UP periods. ───
# ... : critical => Downtimes are considered as DOWN periods. ───
# ───
# downtime_period include |
|
Plus de détails sur ces paramètres et sur le fonctionnement des SLA sur cette page : Calcul du taux de SLA |
Option de stockage des Resultats et Resultats longs ( Inutilisé sur la WebUI )
# ┌─────────────────────────────────────────────────────────────────────────────────────────────────────┐ #
# │ ───────────────────────────────────── SLA STORED OUTPUT ───────────────────────────────────── │ #
# └─────────────────────────────────────────────────────────────────────────────────────────────────────┘ #
# ─── This option enables or disables storing sla outputs. ───
# ───
# Default : 1 => Enable ( the output will be stored ) ───
# ... : 0 => Disable ( the output and long output will not be stored ───
# downtime and acknowledge will still be stored ) ───
# ───
# store_output 1
# ─── This option enables or disables storing sla long outputs. ───
# ───
# Default : Enable => 1 ( the long output will be stored ) ───
# ... : Disable => 0 ( the long output will not be stored ───
# output, downtime and acknowledge will still be stored ) ───
# ───
# store_long_output 1
# ─── This option will be used to filter which outputs and long outputs ───
# ─── to store depending on the status of the sla. ───
# ───
# Default : empty => ( all output states are stored ) ───
# ... : list of status => ( format is State1, State2, ... ) ───
# ─── -> State ok :OK ───
# ─── -> State warning :WARNING ───
# ─── -> State critical:CRITICAL ───
# ─── -> State unknown :UNKNOWN ───
# ─── Example : OK, UNKNOWN ───
# ───
# list_of_stored_output_status |
Afin de limiter l'espace pris par la base des SLA il est possible de filtrer les résultats et les résultats longs sauvegardés dans la base.
Il est possible de monitorer l'espace pris par la base grâce au modèle d'hôte ( voir la page Modèle shinken-broker-module-sla-writer ).
Les résultats et les résultats longs des sondes ne sont que les textes donnés par la commande de vérification.
Exemple : PING CRITICAL - Packet loss = 100%
|
Shinken conseille pour limiter l'espace pris par la base des SLA de limiter le nombre de jours sauvegardés via l'option "nb_stored_days" plutôt que de ne pas sauvegarder les résultats et les résultats longs qui sont un véritable atout lors de l'analyse d'incident. |
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 : Shinken se connecte à la base MongoDB au travers d'un module SSH pour plus de sécurité
Configuration de l'URI de connexion et de l'authentification par mot de passe
# ───────────────── MongoDB parameters ──────────────────────────────────────────────────────────────── #
# ─── MongoDB uri definition . You can find the mongodb uri syntax at ───
# ─── https://docs.mongodb.com/manual/reference/connection-string/ ───
# ───
# Default : mongodb://localhost/?w=1&fsync=false ───
# ─── ───
# uri mongodb://localhost/?w=1&fsync=false
# ─── Which database contains sla data ───
# ───
# Default : shinken ───
# ─── ───
# database shinken
# ─── username/password to authenticate to MongoDB. ───
# ─── Both parameters must be provided for authentication to function correctly. ───
# ─── ───
# database__username
# ─── ───
# database__password |
|
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 MongoDB
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, ceci correspond au paramètre "use_ssh_tunnel" à 0.
C'est la méthode de connexion par défaut lorsque la base est sur la même machine que le démon ( quand l'URL de la base est localhost ).
Si la base est sur une autre machine, il faudra alors se connecter à la base via un tunnel SSH.
Cela permet à la base distance de rester en écoute réseau sur l'interface réseau local, ce qui la sécurise des accès extérieurs ( voir la page Sécurisation des connexions aux bases MongoDB ).
# ─── SSH tunnel activation to secure your mongodb connection ───
# ─── That will allow all mongodb to be encrypted & authenticated with SSH ───
# ───
# Default : 0 => Disable ( disable ssh tunnel ) ───
# ... : 1 => Enable ( enable ssh tunnel ) ───
# ───
# use_ssh_tunnel 0
# ─── If the SSH connection goes wrong, then retry use_ssh_retry_failure time before_shinken_inactive ───
# ───
# Default : 1 ( number of retry ) ───
# ───
# use_ssh_retry_failure 1
# ─── SSH user to connect to the mongodb server. ───
# ───
# Default : shinken ───
# ───
# ssh_user shinken
# ─── SSH keyfile to connect to the mongodb server. ───
# ───
# Default : ~shinken/.ssh/id_rsa ───
# ───
# ssh_keyfile ~shinken/.ssh/id_rsa
# ─── SSH Timeout used to test if the SSH tunnel is viable or not, in seconds. ───
# ───
# Default : 10 ( seconds ) ───
# ───
# ssh_tunnel_timeout 10 |
Le module peut se connecter à la base MongoDB via un tunnel SSH, pour des raisons de sécurité.
En effet, le paramétrage du serveur MongoDB permet de définir sur quelle interface réseau ce dernier écoute les requêtes.
En n'autorisant seulement l'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 ), s'assurer 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 n'écoute que sur l'interface réseau locale, pour que le module se connecte, il faut passer par un tunnel SSH. Pour cela, il faut activer les options suivantes :
|
En cas de connexion via un tunnel SSH il est nécessaire de bien configurer les clés ( voir la page Création automatique et gestion de la clé SSH de l'utilisateur shinken ).
Gestion de l'auto-reconnexion
# ────────────── AutoReconnect Management ───────────────────────────────────────────────────────────────
# ─── When MongoDB require you to reconnect ( For example, It can occur when a new PRIMARY is elected ───
# ─── in a MongoDB cluster ), it will raised the MongoDB AutoReconnect exception. ───
# ─── How many try to reconnect before module go in error ───
# ───
# Default : 4 ( number of try ) ───
# ───
# auto_reconnect_max_try 4
# ─── Time between each try ───
# ───
# Default : 3 ( seconds ) ───
# ───
# auto_reconnect_sleep_between_try 3
# ─── NOTE: Change these values only if you have a MongoDB cluster and you change the ───
# ─── heartbeatTimeoutSecs of your MongoDB replica set ───
# ─── The value of auto_reconnect_max_try * auto_reconnect_sleep_between_try must be higher than ───
# ─── heartbeatTimeoutSecs in the rs.conf(); of your MongoDB replica set. ─── |
Primaire : nom de MongoDB pour désigner un serveur maître, le serveur sur lequel il est possible de faire des requêtes d'écriture dans la base. Élection : processus de MongoDB pour choisir un nouveau membre Primaire si le membre Primaire devient inaccessible. ( voir la page Haute disponibilité de la base MongoDB (mise en place d'un cluster) ) |
Dans le cas de l'utilisation d'un cluster MongoDB, lorsque le membre Primaire devient inaccessible une nouvelle élection est déclenchée ce qui provoque une coupure temporaire de l'accès à la base.
Dans le but de ne pas interrompre le service, le module SLA va se reconnecter automatiquement au cluster MongoDB.
Pour ce faire il va faire un nombre d'essais égal au paramètre "auto_reconnect_max_try " avec une pause de X secondes entre chaque essai ( correspondant au paramètre "auto_reconnect_sleep_between_try"
).
Par défaut pour MongoDB le temps maximum avant qu'un membre Primaire soit considéré comme indisponible et qu'une nouvelle élection ait lieu est de 10 secondes.
Voir : "heartbeatTimeoutSecs" donné par la commande rs.conf(); dans un shell de MongoDB.
|
Il est conseillé de ne pas modifier ces valeurs. |
Utilisation des workers du module SLA ( Inutilisé sur la WebUI )
# ┌─────────────────────────────────────────────────────────────────────────────────────────────────────┐ #
# │ ─────────────────────────────────── WORKERS IN THE BROKER ─────────────────────────────────── │ #
# └─────────────────────────────────────────────────────────────────────────────────────────────────────┘ #
# ─── This module will use workers in the broker, each worker will manage a shard of all hosts/checks. ───
# ─── This parameter is used by the broker to set the number of workers. ───
# ─── Each worker will use one CPU, which will balance the sla processing load among CPUs. ───
# ───
# Default : 1 => X workers ───
# ───
# broker_module_nb_workers 1 |
Le paramètre "broker_module_nb_workers" va déterminer combien de fois le module SLA va se cloner pour gérer le flux de donnée à enregistrer afin de répartir cette charge sur plusieurs CPU.
Il est possible de changer ce paramètre si l’utilisation CPU du processus : "NOM DU BROKER [ - Module: sla ][ Worker: 0 ]" est trop élevée.
|
Ne pas dépasser le nombre de core CPU de la machine : cela serait contre-productif pour les performances. |
Options internes
Ces paramètres sont dédiés au fonctionnement interne au module, il est déconseillé de les modifier sans le support dédié. |
# ┌─────────────────────────────────────────────────────────────────────────────────────────────────────┐ #
# │ ───────────────────────────────────── INTERNAL OPTIONS ────────────────────────────────────── │ #
# └─────────────────────────────────────────────────────────────────────────────────────────────────────┘ #
# ─── INTERNAL : DO NOT EDIT FOLLOWING PARAMETER WITHOUT YOUR DEDICATED SUPPORT ───
# ─── Broker idle time before considering that Shinken is inactive. ───
# ─── Use this if you have Broker loop time that exceeds 30 seconds ───
# ───
# Default : 30 ( seconds ) ───
# ───
# time_before_shinken_inactive 30
# ─── Maximum number of elements archived in one bulk pass. ───
# ─── Use this if at 00:05 (archive time) your MongoDB is saturate ───
# ───
# Default : 10 000 ( elements numbers ) ───
# ───
# size_chunk_to_archive 10000
# ─── Time between two chunk to archive. ───
# ─── Use this if at 00:05 (archive time) your MongoDB is saturate ───
# ───
# Default : 0.1 ( seconds ) ───
# ───
# time_between_two_chunks 0.1
# ─── Max number of sla remove each daily_clean_pause_time. ───
# ─── Use if nb_stored_days is not -1. ( Daily clean time is activated ) ───
# ─── Use this if at 03:02 (daily clean time) your MongoDB is saturate. ───
# ───
# Default : 10 000 ( numbers of sla ) ───
# ───
# daily_clean_batch_size 10000
# ─── Delay between 2 sla clean. ───
# ─── Use if nb_stored_days is not -1. ( Daily clean time is activated ) ───
# ─── Use this if at 03:02 (daily clean time) your MongoDB is saturate. ───
# ───
# Default : 2 ( seconds ) ───
# ───
# daily_clean_pause_time 2
# ─── Max number of sla archive migrate save at same time. ───
# ─── Use this if after an Shinken update your MongoDB is saturate. ───
# ───
# Default : 1 000 ( sla ) ───
# ───
# broker_module_sla_migration_batch_size 1000
# ─── Delay between 2 migrating batch save. ───
# ─── Use this if after an Shinken update your MongoDB is saturate. ───
# ───
# Default : 0.1 ( seconds ) ───
# ───
# broker_module_sla_migration_pause_time 0.1 |
|
Erreurs dans le Module
Afin de ne pas casser la base et les données de SLA, si le module à une erreur inattendue comme un crash, alors le module s’arrête et n'est pas automatiquement redémarré.
Lancer la commande shinken-healthcheck pour trouver l'erreur Fatale
|
