| Scroll Ignore | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||
|
Concept
Le module de type "livedata_module_sla_provider" est un module qui permet au module de type "broker_module_livedata" du Broker de fournir une API de consultation des données SLA archivées.
- /api/v2/sla
- Il récupère les données SLAs présentes dans la base de données Shinken, les .
- Les données SLA sont calculées à la fin de la journée, donc la dernière donnée disponible est celle
- de la veille.
Pour plus de détails sur cette API ( voir la page V2 - ( READ ) /api/v2/sla -- OPTIONNEL -- )
Activation du module
Les modules de type "livedata_module_sla_provider" sont des modules qui doivent être activés sur un module de type "broker_module_livedata", qu'on appellera le module parent.
- L'activation du module s'effectue en ajoutant le nom de ce du module dans le fichier de la configuration du module de type
"broker_module_livedata"correspondantparent.- Pour cela, il faut ouvrir le fichier de configuration du module parent ( de type "
broker_module_livedata"), et ajouter dans le paramètre modules, le nom du module de type"livedata_module_sla_provider"
- .
- Pour cela, il faut ouvrir le fichier de configuration du module parent ( de type "
- Il est possible de faire plusieurs modules de type
"livedata_module_sla_provider".- Cela permet, par exemple, d'avoir des configurations différentes en fonction des royaumes.
- Cela permet, par exemple, d'avoir des configurations différentes en fonction des royaumes.
- S'il y a plusieurs modules de type
"broker_module_livedata"présents dans l'architecture, il ne faut pas oublier d'activer le module de type"livedata_module_sla_provider"dans la configuration de chacune chacun d'elleseux.
Pour prendre en compte le changement de configuration, il faut redémarrer l'Arbiter:
| Code Block | ||||
|---|---|---|---|---|
| ||||
service shinken-arbiter restart |
- Contraintes :
- Activable uniquement sur un module de type
"broker_module_livedata"( voir la page Configuration du broker-module-livedata ). - Il ne peut y avoir qu'un seul module de type
"livedata_module_sla_provider"
- Activable uniquement sur un module de type
- sur un module de type
"broker_module_livedata".
- sur un module de type
Pour prendre en compte le changement de configuration, il faut redémarrer l'Arbiter :
| Excerpt Include | ||||||
|---|---|---|---|---|---|---|
|
Exemple d'activation du module nommé "livedata-module-sla-provider" sur le module nommé "broker-module-livedata" ( configuration livrée par défaut par Shinken )
L'exemple suivant :
- active le module
"livedata-module-sla-provider", - sur le module
"broker-module-livedata",dont la configuration est dans le fichier /etc/shinken/modules/broker-module-livedata.cfg.
Modification dans le fichier du module /etc/shinken/modules/broker-module-livedata.cfg :
| Code Block | ||||
|---|---|---|---|---|
| ||||
define module {
[...]
modules Module 1, Module 2, Module 3, livedata-module-sla-provider
[...]
} |
Puis redémarrage de l'Arbiter
| Code Block | ||||
|---|---|---|---|---|
| ||||
service shinken-arbiter restart |
| Excerpt Include | ||||||
|---|---|---|---|---|---|---|
|
Créer un
Configurer unnouveau module de type livedata_module_sla_provider
Pour pouvoir configurer un module de type "livedata_module_sla_provider", il faut faire créer 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-Livedata-Sla-Provider". - 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/broker-module-livedata/modules/livedata-module-sla-provider/livedata-module-sla-provider-example.cfg dans le répertoire de définition des modules /etc/shinken/modules/ .
( Exemple : /etc/shinken/modules/livedata-module-sla-provider__Mon-Module-Livedata-Sla-Provider.cfg )
Scroll Title title Code Block language text theme Emacs cp /etc/shinken-user-example/configuration/daemons/brokers/modules/broker-module-livedata/modules/livedata-module-sla-provider/livedata-module-sla-provider-example.cfg /etc/shinken/modules/livedata-module-sla-provider__Mon-Module-Livedata-Sla-Provider.cfg
- Ensuite, il faut ajouter modifier le fichier nouvellement créé pour configurer 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/broker-module-livedata.cfg.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 suivantes :
Code Block language
text theme
Emacs
chown shinken:shinken /etc/shinken/modules/livedata-module-sla-provider__Mon-Module-Livedata-Sla-Provider.cfg chmod u+w /etc/shinken/modules/livedata-module-sla-provider__Mon-Module-Livedata-Sla-Provider.cfgOn change le nom du module en
"Mon-Module-Livedata-Sla-Provider"dans le fichier /etc/shinken/modules/livedata-module-sla-provider__Mon-Module-Livedata-Sla-Provider.cfgCode Block language js theme Confluence ... # ─── Module name [ Must be unique ] [ MANDATORY ] ─── # ─── ─── module_name
Mon-Module-Livedata-Sla-Provider ...
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
.cfgAjouter le nom du nouveau module "au module"broker-module-livedata
en modifiant le paramètre modules du fichier "défini dans le fichier /etc/shinken/modules/broker-module-livedata
.cfg ( ou le .cfg
qui est utilisé pour définir les options du broker-module-livedata ).Code Block language js theme Confluence define module { [...] modules Module 1, Module 2, Module 3, Mon-Module-Livedata-Sla-Provider [...] }
Redémarrez Puis pour finir, il faut redémarrer l'Arbiter pour que
le Broker puisse prendre en compte ce nouveau module.
Une fois que le fichier a été édité, vérifiez que le fichier possède comme droits utilisateurs shinken. Si ce n'est pas le cas, effectuez la commande suivante :
| language | text |
|---|---|
| theme | Emacs |
| Code Block | ||||
|---|---|---|---|---|
| ||||
service shinken-arbiter restart |
Configuration
les modifications apportées à la configuration soient appliquées.
Excerpt Include Fichier de configuration ( shinken.cfg ) Fichier de configuration ( shinken.cfg ) nopanel true
Configuration
Par défaut, La configuration du module se trouve dans
Voici le détail de fichier de configuration du module qui se trouve :
Soitle fichier /etc/shinken/modules/livedata-module-sla-provider.cfg
- ( livré par défaut )Soit dans le fichier qui vient d'être créé en ajoutant le module ( par exempleUn exemple de configuration est également disponible dans /etc/shinken-user-example/configuration/daemons/brokers/modules/broker-module-livedata/modules/livedata-module-sla-provider__Module-Livedata-Sla-Provider.cfg)/livedata-module-sla-provider-example.cfg
Exemple de fichier de configuration
| Code Block | ||||
|---|---|---|---|---|
| ||||
# CFG_FORMAT_VERSION 1 ( SHINKEN : DON'T TOUCH THIS LINE )
#================================================================================
# livedata_module_sla_provider
#================================================================================
# Modules that can load this module:
# - broker-module-livedata (to add new route to this module)
# This module is an API providing information on SLA of monitored elements
#================================================================================
define module {
# ┌─────────────────────────────────────────────────────────────────────────────────────────────────────┐ #
# │ ────────────────────────────────────── MODULE IDENTITY ────────────────────────────────────── │ #
# └─────────────────────────────────────────────────────────────────────────────────────────────────────┘ #
# ─── Module name [ Must be unique ] [ MANDATORY ] ───
# ─── ───
module_name livedata-module-sla-provider
# ─── Module type [ Do not edit ] [ MANDATORY ] ───
# ─── ───
module_type livedata_module_sla_provider
# ┌─────────────────────────────────────────────────────────────────────────────────────────────────────┐ #
# │ ──────────────────────────────────── 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 ───
# ─── ───
# broker__module_livedata__module_sla_provider__database__uri mongodb://localhost/?w=1&fsync=false
# ─── Which database contains sla data ───
# ───
# Default : shinken ───
# ─── ───
# broker__module_livedata__module_sla_provider__database__name shinken
# ─── username/password to authenticate to MongoDB. ───
# ─── Both parameters must be provided for authentication to function correctly. ───
# ─── ───
# broker__module_livedata__module_sla_provider__database__username
# ─── ───
# broker__module_livedata__module_sla_provider__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 ) ───
# ─── ───
# broker__module_livedata__module_sla_provider__use_ssh_tunnel 0
# ─── SSH user to connect to the mongodb server. ───
# ───
# Default : shinken ───
# ─── ───
# broker__module_livedata__module_sla_provider__ssh_user shinken
# ─── SSH keyfile to connect to the mongodb server. ───
# ───
# Default : ~shinken/.ssh/id_rsa ───
# ─── ───
# broker__module_livedata__module_sla_provider__ssh_keyfile ~shinken/.ssh/id_rsa
# ─── SSH Timeout used to test if the SSH tunnel is viable or not, in seconds. ───
# ───
# Default : 10 ( seconds ) ───
# ─── ───
# broker__module_livedata__module_sla_provider__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 ) ───
# ─── ───
# broker__module_livedata__module_sla_provider__database__retry_connection_X_times_before_considering_an_error 4
# ─── Time between each try ───
# ───
# Default : 3 ( seconds ) ───
# ─── ───
# broker__module_livedata__module_sla_provider__database__wait_X_seconds_before_reconnect 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 ───
# ─── retry_connection_X_times_before_considering_an_error * wait_X_seconds_before_reconnect ───
# ─── must be higher than heartbeatTimeoutSecs in the rs.conf(); of your MongoDB replica set. ───
# ┌─────────────────────────────────────────────────────────────────────────────────────────────────────┐ #
# │ ────────────────────────────────────── SLA CALCULATION ────────────────────────────────────── │ #
# └─────────────────────────────────────────────────────────────────────────────────────────────────────┘ #
# ─── 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. ───
# ─── ───
# broker__module_livedata__module_sla_provider__no_data_period include
}
|
Détails des sections composant le fichier de configuration
Identification du module
Il est possible de définir plusieurs instances de module de type livedata-module-sla-provider dans l'architecture Shinken .
- Chaque instance devra avoir un nom unique.
| Scroll Title | |||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| |||||||||||||||||||
|
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
| Code Block | ||||
|---|---|---|---|---|
| ||||
# ───────────────── 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 ───
# ─── ───
# broker__module_livedata__module_sla_provider__database__uri mongodb://localhost/?w=1&fsync=false
# ─── Which database contains sla data ───
# ───
# Default : shinken ───
# ─── ───
# broker__module_livedata__module_sla_provider__database__name shinken
# ─── username/password to authenticate to MongoDB. ───
# ─── Both parameters must be provided for authentication to function correctly. ───
# ─── ───
# broker__module_livedata__module_sla_provider__database__username
# ─── ───
# broker__module_livedata__module_sla_provider__database__password |
| Scroll Title | |||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| |||||||||||||||||||||||||||||||||
|
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 ).
| Code Block | ||||
|---|---|---|---|---|
| ||||
# ─── 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 ) ───
# ───
# broker__module_livedata__module_sla_provider__use_ssh_tunnel 0
# ─── SSH user to connect to the mongodb server. ───
# ───
# Default : shinken ───
# ───
# broker__module_livedata__module_sla_provider__ssh_user shinken
# ─── SSH keyfile to connect to the mongodb server. ───
# ───
# Default : ~shinken/.ssh/id_rsa ───
# ───
# broker__module_livedata__module_sla_provider__ssh_keyfile ~shinken/.ssh/id_rsa
# ─── SSH Timeout used to test if the SSH tunnel is viable or not, in seconds. ───
# ───
# Default : 10 ( seconds ) ───
# ───
# broker__module_livedata__module_sla_provider__ssh_tunnel_timeout 10 |
| Scroll Title | |||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| |||||||||||||||||||||||||||||||||
|
Gestion de la reconnexion automatique avec un cluster MongoDB
| Code Block | ||||
|---|---|---|---|---|
| ||||
# ────────────── 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 ) ───
# ───
# broker__module_livedata__module_sla_provider__database__retry_connection_X_times_before_considering_an_error 4
# ─── Time between each try ───
# ───
# Default : 3 ( seconds ) ───
# ───
# broker__module_livedata__module_sla_provider__database__wait_X_seconds_before_reconnect 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 ───
# ─── retry_connection_X_times_before_considering_an_error * wait_X_seconds_before_reconnect ───
# ─── must be higher than heartbeatTimeoutSecs in the rs.conf(); of your MongoDB replica set. ─── |
| Info | ||
|---|---|---|
| ||
( 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 "event-manager-reader" va se reconnecter automatiquement au cluster MongoDB.
Pour ce faire, il va faire un nombre d' essais égaux 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.
| Scroll Title | |||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| |||||||||||||||||||
|
Les valeurs par défauts du fichier laissent 12 secondes, ce qui est amplement suffisant avec la configuration par défaut de MongoDB.
| Warning |
|---|
Il est conseillé de ne pas modifier ces valeurs. |
Paramétrage des états Données manquantes ( Missing data ) et Shinken inactif ( Shinken inactive )
| Code Block | ||||
|---|---|---|---|---|
| ||||
# ┌─────────────────────────────────────────────────────────────────────────────────────────────────────┐ #
# │ ────────────────────────────────────── SLA CALCULATION ────────────────────────────────────── │ #
# └─────────────────────────────────────────────────────────────────────────────────────────────────────┘ #
# ─── 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. ───
# ───
# broker__module_livedata__module_sla_provider__no_data_period include |
Les états Données manquantes ( Missing data ) et Shinken inactif ( Shinken inactive ) ont été regroupés dans un paramètre. Ce paramètre correspond à la période durant laquelle Shinken n'a pas effectué les vérifications pour un check ( plateforme Shinken éteinte, ou vérification du check désactivé grâce aux Périodes de temps, voir la page Périodes de temps ). Le statut de ces checks est donc Données manquantes ( Missing data ) ou Shinken inactif ( Shinken inactive ).
| Scroll Title | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||
|