Introduction
Dans Shinken Entreprise, les statuts des éléments supervisés sont observés au fil du temps pour permettre un calcul du taux de disponibilité de l'élément. Ces données de SLA sont mises à jour régulièrement et stockées par Shinken.
Les sections suivantes présentent comment visualiser ces SLA, leur méthode de stockage ainsi que les différentes options disponibles pour configurer la méthode de calcul de ces SLA.
Comment voir le SLA d'un élément
Le taux de disponibilité d'un élément peut être visualisé dans l'interface de Visualisation, de 2 manières différentes:
- Dans un tableau de bord, avec le Widget SLA
- Dans le détail de l'élément, via l'onglet Onglet Historique/SLA
- Avec Les rapports
Stockage des données
Les données nécessaires pour le calcul des SLA sont stockées dans une base Mongodb MongoDB locale au démons Broker avec le module SLA activé.
Configurer l'accès à la base MongoDB
Cette configuration s'effectue dans le fichier de configuration du module SLA concerné.
Dans Shinken Entreprise, la définition du module SLA se trouve dans /etc/shinken/modules/sla.cfg :
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
# Timeout in order to establish a connection, in seconds
# Default: 10
# mongo_timeout 10
# Which database is used to store sla data
database shinken
Comme pour les autres composants de Shinken Entreprise s'appuyant sur une base MongoDB, la communication entre le module SLA et la base MongoDB peut être sécurisée par l'intermédiaire d'un tunnel SSH. La mise en place de cette fonctionnalité, qui n'est pas activée par défaut, est décrite dans la documentation du Module SLA.
Options
.........}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:
- Connexion directe: Par défaut, mais non sécurisée.
- Tunnel SSH: Shinken se connecte au serveur Mongo au travers d'un module SSH pour plus de sécurité
Connexion directe au serveur Mongo
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.
/etc/shinken/modules/retention-mongodb.cfg
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é.
Connexion par SSH au serveur Mongo
Le module SLA 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:
bind_ip=127.0.0.1
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 $
| Info |
|---|
Si vous avez un serveur qui héberge à la fois le démon Broker et la base MongoDB (cas d'une installation standard), 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 SLA
- le paramètre "use_ssh_tunnel" doit être positionné à 1
- le paramètre "use_ssh_retry_failure" permet de spécifier le nombre supplémentaire de tentatives lors de l'établissement du tunnel SSH si ce dernier n'arrive pas à être établi.
- le paramètre "ssh_user" doit être positionné au user utilisé pour se connecter au serveur mongo (user_distant dans l'exemple précédent)
- le paramètre "ssh_keyfile" doit pointer vers la clé ssh privée sur le serveur Shinken (par défaut ~/.ssh/id_rsa)
disponibles pour le calcul des SLA
Le calcul du taux de disponibilité peut être configuré pour coller au mieux aux contraintes:
- Comment prendre en compte les statuts "Warning": font-ils monter ou descendre le SLA ?
- Comment prendre en compte les états inconnus, les périodes de maintenance, etc... ?
Ces options et leur configuration sont décrites de manières détaillée dans la page Calcul du taux de disponibilité (SLA).
Limiter le volume de données des SLAs
La taille des données de SLA dépend de 3 facteurs :
- Le nombre d'éléments supervisés
- La fréquence de changement d'état des élément supervisés et la taille des messages des Checks
- La durée pendant là quel est gardée les données
Vous ne pourrez pas contrôler le facteur de la fréquence de changement d'état des élément, et il n'est pas souhaitable de limité le nombre d'éléments en supervisions.
Donc il n'est pas possible de prédéterminer la taille de la base ce qui veux donc dire que vous devez superviser la base à l'aide du check 'Broker - $KEY$ - Module SLA Writer'.
Vous pouvez modifier les données STORAGE_WARNING et STORAGE_CRITICAL sur l'hôte pour que le check passe en CRITIQUE ou WARNING si il dépasse le seuil donnée en MB.
La métrique storage_size donne la taille en octet de la base pour suivre la progression de la taille de base.
Si votre base prend trop de place vous pouvez :
- Réduire le nombre de jour gardé en base (paramètre : nb_stored_days),
- Désactivé la sauvegarder des messages des Checks (paramètre : store_output / store_long_output / list_of_stored_output_status)
Puis compactée la base ( voir la page Gestion de la base MongoDB )
Une autre option influence la taille de la base : keep_raw_sla_day. Cette option permet de choisir combien de jours au format non archivé seront gardé. En effet on garde par sécurité par défaut 7 de données non archivé en cas de problème lors de l'archivage des données pour reconstruire les SLA.
Nous déconseillons de modifier ce paramètre sans consultation de votre support.