Le module SLA permet de calculer les valeurs de SLA (Service Level Agreement) des éléments supervisés et les stocker dans la base de données Mongodb définie dans le fichier de configuration ci dessous. Il est également possible, via ce fichier, de modifier la méthode de calcul des SLA (par exemple, choisir de considérer un Warning comme une période positive de SLA, ou encore d'exclure les périodes de maintenance dans le calcul).
Afin de ne pas casser la base et vos données de SLA, si le module à une erreur inattendu comme un crash alors le module s’arrête et n'est pas automatiquement redémarré. Vous trouverez une erreur FATAL avec la commande shinken-healthcheck.

Voici le fichier CFG de configuration présent dans : /etc/shinken/modules/sla.cfg
#===============================================================================
# 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 {
# 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 core-module-d05cd3505adb11e5884b080027f08538
_SE_UUID_HASH 05d3d1d1cce1f5e03b43936aad25e68f
# End of Shinken Enterprise part
#======== Module identity =========
# Module name. Must be unique
module_name sla
# Module type (to load module code). Do not edit.
module_type sla
#======== Database connection =========
# mongodb uri definition for connecting to the mongodb database. You can find the mongodb uri
# syntax at https://docs.mongodb.com/manual/reference/connection-string/
uri mongodb://localhost/?w=1&fsync=false
# If you want to securize your mongodb connection you can enable the 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 before_shinken_inactive
# Default: 1
# use_ssh_retry_failure 1
# SSH user/keyfile in order to connect to the mongodb server.
# Default: shinken
# ssh_user shinken
# 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: 5
# ssh_tunnel_timeout 5
# Which database is used to store sla data
database shinken
#======== Module options =========
# Raw SLA can be kept during X days. 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.
# keep_raw_sla_day 7 ;optional, defaults to 7
# Duration in day to keep SLA info,
# Default value, if not set, is -1. It means that SLA are kept forever ; in this case the mongo database will grow endlessly.
# Minimal value is 7 day
# If SLA are not meant to be kept forever, the following value is recommended (corresponds to 18 months)
# nb_stored_days 547
# Time of day the SLA archive cleanup is performed
# Default value, if unset, is 03:02
# Daily cleanup is done at requested time when nb_stored_days is set
# format is HH:MM with
# - HH is 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
# 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.
# If 1, old SLA will be recomputed with current settings.
# If 0, old SLA will not be recalculated [default]
# recompute_old_sla 0
#======== SLA calculation ========
# Some status can impact positively (counted as OK/UP), negatively (counted as CRITICAL/DOWN) or 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.
# If 1, Warning counts as UP
# If 0, Warning counts as DOWN [default]
# warning_counts_as_ok 0
# == Unknown periods ==
# - include: Only status is considered. "Unknown" status is counted negatively in the SLA. [default]
# - 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) ==
# - include: Only status is considered. "Missing data" and "Shinken inactive" status are counted negatively in the SLA. [default]
# - exclude: No_data are not counted from SLA considered period
# - ok: No_data are considered as UP periods
# no_data_period include
# == Downtime periods ==
# - include: Only status is considered. [default]
# - 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.
# If 1, the output will be stored (Default value)
# If 0, 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.
# If 1, the long output will be stored (Default value)
# If 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.
# Possible values are : OK, WARNING, CRITICAL, UNKNOWN
# Seperator is : ,
# Default value : empty (all output states are stored)
# Example to only store OK and UNKNOWN outputs : list_of_stored_output_status OK,UNKNOWN
# list_of_stored_output_status
#======== 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
broker_module_nb_workers 1
#======== INTERNAL options =========
#INTERNAL : DO NOT EDIT FOLLOWING PARAMETER WITHOUT YOUR DEDICATED SUPPORT
# == time of inactivation of the broker before considering that shinken is inactive (in sec) ==
#time_before_shinken_inactive 30
# == maximum number of elements archived in one bulk pass ==
#size_chunk_to_archive 10 000
# == time between two chunk to archive ==
#time_between_two_chunks 0.1
# == default value of the interval check (in minutes) ==
#default_check_interval 5
# == delay before the creation of missing data period (in check intervale) ==
#margin_create_new_range 1.5
# == max delay before creating missing data period (in minutes) ==
#margin_create_new_range_max 10
# == max number of sla remove each daily_clean_pause_time. Use if nb_stored_days is not -1. ==
#daily_clean_batch_size 10000
# == delay between 2 sla clean. Use if nb_stored_days is not -1. (in second) ==
#daily_clean_pause_time 2
# == max number of sla archive migrate save at same time. ==
#broker_module_sla_migration_batch_size 1000
# == delay between 2 migrating batch save. ==
#broker_module_sla_migration_pause_time 0.1
# Explanatory example of the property margin_create_new_range
# For an element with a check interval at 1min and margin_create_new_range at 1.5 which equals 1min30s of time delay.
# If the interval check is at 1h the delay would be at 1h30 but the delay is limited by margin_create_new_range_max which limits the delay to 10min.
#
# An OK status is given by the scheduler at 12h30
# A new OK status is given by the scheduler at 12h40
# The scheduler should have given a new status at 12h31 but it gave it at 12h40 which is 9min of time delay.
# So that 9min > 1min30s a missing data period is created.
} |
Cette configuration s'effectue dans le fichier de configuration du module SLA
define module{
...
...
...
#======== Database connection =========
# mongodb uri definition for connecting to the mongodb database. You can find the mongodb uri
# syntax at https://docs.mongodb.com/manual/reference/connection-string/
uri mongodb://localhost/?w=1&fsync=false
# If you want to securize your mongodb connection you can enable the 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 before_shinken_inactive
# Default: 1
# use_ssh_retry_failure 1
# SSH user/keyfile in order to connect to the mongodb server.
# Default: shinken
# ssh_user shinken
# 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: 5
# ssh_tunnel_timeout 5
# Which database is used to store sla data
database shinken
...
...
...
} |
Les données SLA sont stockées dans la base Mongo locale au Broker
Pour se connecter au serveur Mongo utilisé pour le stockage des données SLA, 2 méthodes sont disponibles:
Par défaut, le module SLA se connecte de manière directe au serveur Mongo pour y lire et écrire les données SLA.
Dans la configuration du module SLA, on sait que la connexion se fait de manière directe lorsque le paramètre "use_ssh_tunnel" est à 0.
define module {
...
... ...
#======== Module identity =========
# Module name. Must be unique
module_name sla
...
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 sur 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é.
Le module SLA peut également se connecter par tunnel SSH au serveur Mongo, pour des raisons de sécurité.
bind_ip=127.0.0.1
| Nom du paramètre | Description |
|---|---|
use_ssh_tunnel | Activation du tunnel ou non (0 ou 1 ). Par défaut, il n'est pas activé ( à 1 ) |
use_ssh_retry_failure | Spécifie le nombre supplémentaire de tentatives lors de l'établissement du tunnel SSH si ce dernier n'arrive pas à être établi |
ssh_user | L'utilisateur avec lequel le tunnel sera établit |
ssh_keyfile | une clé ssh privée présent sur le serveur Shinken (par défaut ~/.ssh/id_rsa) qui sera utilisé pour établir le tunnel. |
| ssh_tunnel_timeout | Spécifie le timeout de la vérification du tunnel SSH avant que la connexion vers mongo soit effectuée |
root@serveur_shinken # su - shinkenshinken@serveur_shinken $ ssh-keygenshinken@serveur_shinken $ ssh-copy-id user_distant@serveur_mongo[...]shinken@serveur_shinken $ ssh user_distant@serveur_mongouser_distant@serveur_mongo $
#======== 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
broker_module_nb_workers 1 |
Ce paramètre va déterminer combien de fois le module SLA va se cloner pour gérer le flux de donnée à enregistrer afin de repartir 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 élever. Note : ne pas dépassé le nombre de core cpu de la machine cela serais contre productif pour les performances.
Les entrées dans la base d'archives du module SLA sont supprimées toutes les 24h.
| Nom du paramètre | Description | Valeur par défaut |
|---|---|---|
| nb_stored_days | Détermine le nombre de jours à garder dans la base d'archives du module SLA. La valeur minimal correspond à 7 jours. La valeur -1 signifie qu'on veut garder toutes les entrées dans la base d'archives du module SLA. | -1 |
| time_when_delete_old_SLA | Heure à laquelle les entrées dans la base d'archives du module SLA seront supprimées. Les données gardées correspondent aux jours définis par la valeur de la propriété nb_stored_days | 03:02 |
Si le Broker 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 de la base d'archives du module SLA, le nettoyage s'exécutera. |