Page History

Introduction

Ce pack contient quatre modèles d'hôte permettant de superviser des bases MongoDB sur les points suivants :

• Connexions à la base Mongo (durée et pourcentage de connexions utilisées par rapport aux connexions disponibles)
• Durée moyenne de l'écriture sur disque
• Durée de la dernière écriture sur disque
• Proportion d'échec lors de la recherche dans l'index
• Durée d'attente des verrous
• Statistiques sur les opérations sur les documents (suppressions, insertions, mises à joursjour, requêtes)
• Etat des replicaset
• Délai de réplication

Ce pack peut se connecter à une base Mongo de deux façons différentes :

• soit directement au serveur Mongo
• soit par l'intermédiaire d'un tunnel SSH, afin d'améliorer la sécurité en configurant le serveur Mongo pour n'écouter que sur l'interface réseau locale

Configuration de la connexion SSH

Avec la configuration par défaut, le pack Mongo se connecte en direct sur le serveur MongoDB.

Lorsque le mode "SSH" est activé (voir la section Dans la configuration de l'hôte), il essaie de se connecter au serveur Mongo par l'intermédiaire de SSH avec l'utilisateur "shinken" et la clé privée se trouvant dans ~shinken/.ssh/id_rsa.

Notez que si vous avez déjà effectué cette configuration pour le Pack Linux, vous pouvez réutiliser la même pour le pack MongoDB.

Dans la configuration de l'hôte

Dans l'onglet Général, ajoutez l'un des modèles d'hôte du pack MongoDB à la liste des modèles hérités.

Dans l'onglet "Données", dans la section consacrée au modèle d'hôte MongoDB hérité :

• Spécifiez la valeur "ssh" pour la donnée "MONGO_CONNECTION_METHOD"
• Assurez-vous que les données "MONGO_SSH_KEY" et "MONGO_SSH_USER" font référence à la clé SSH privée définie dans la section Côte Shinken et à l'utilisateur créé dans la section Côté client.

Côté client (serveur supervisé)

• Créez un utilisateur local "shinken" avec un dossier "home" et un mot de passe

  Code Block
  language text theme Emacs
  adduser -m -r shinken passwd shinken

Côté Shinken (serveur Poller)

Connectez-vous sur le serveur en tant qu'utilisateur "shinken" et copiez la clé SSH publique vers le serveur à superviser :

[root@shinken-poller ~]# su - shinken
[shinken@shinken-poller ~]#  ssh-copy-id  shinken@remote_host
The authenticity of host '192.168.1.19 (192.168.1.19)' can't be established.
RSA key fingerprint is 00:ff:ee:dd:cc:bb:aa:d6:d3:79:1d:f6:93:47:80:27.
Are you sure you want to continue connecting (yes/no)? yes
shinken@remote_host's password: XXXXXXXXXXX
Now try logging into the machine, with "ssh '192.168.1.19'", and check in:
  .ssh/authorized_keys
to make sure we haven't added extra keys that you weren't expecting.
 
[root@shinken-poller ~]# ssh shinken@remote_host -i ~shinken/.ssh/id_rsa

Cette copie de clé permet d'autoriser le Poller à se connecter sur la machine à superviser. Sur une architecture Shinken contenant plusieurs Pollers, il faudra effectuer cette opération sur chaque Poller pour lui permettre de se connecter en SSH sur le serveur à superviser.

Comment utiliser le pack MongoDB

Modèles d'hôtes fournis par le pack

Quatre modèles d'hôtes sont disponibles en fonction de votre configuration MongoDB :

• Mongodb
• Mongodb-no-replication si votre architecture Mongo n'utilise pas la réplication)

Ces deux modèles sont prévus pour être utilisés sur une version de Mongo antérieure à la version 3

• Mongodb3 et Mongodb3-no-replication sont prévus pour être utilisés avec les versions de Mongo ultérieures à la version 3.

Ces quatre modèles d'hôtes fournissent des checks identiques et se configurent de la même manière, mais seuls les checks compatibles avec la configuration choisie sont présents.

Via l'interface de configuration

Dans l'interface de configuration, créez et Editer un Hôte, et ajoutez le modèle d'hôte choisi dans la liste des modèles d'hôtes utilisés.

Via un fichier de configuration

Dans un fichier de configuration .cfg de votre choix, créer un hôte et définir la propriété "use" pour lui ajouter le nom du pack MongoDB choisi.

Ce fichier cfg doit ensuite être importé dans Shinken Entreprise via une source (plus d'informations sont disponibles dans la page de documentation sur la Syntaxe des fichiers d'imports).

Authentification de la base Mongo

Si la base mongo que vous souhaitez superviser a à une authentification, il est possible de paramétrer les données des modèles mongo pour y accéder.

• La donnée MONGO_USERNAME permet de définir le nom d'utilisateur à utiliser pour la connexion à la base
• La donnée MONGO_PASSWORD permet de définir le mot de passe à utiliser pour la connexion à la base

Résumé des checks

Personnaliser les seuils de Warning et Critique

Le pack MongoDB définit des seuils par défaut sur les checks qu'il utilise et que vous pouvez modifier.

Changer les seuils pour un seul hôte

Les modèles d'hôte livrés dans Shinken contiennent souvent des variables permettant de changer les seuils et options des checks.

Pour changer ces seuils sur un seul hôte en particulier, la manière la plus simple est de changer des variables via les données présentes sur l'hôte directement :

• Dans l'interface de Configuration, éditer l'hôte et aller dans l'onglet Données
  Par exemple, changer la donnée MONGO_CONNECT_CRIT à 10 aura pour effet de changer le seuil Critique du check "Mongodb-connection" à 10
• Via un fichier de configuration.
  Pour changer le seuil Critique du check "Mongodb-queries-stat-delete", éditer l'hôte et changer la donnée _MONGO DELETE_PER_SEC_CRIT_LEVEL

Changer les seuils pour tous les hôtes qui utilisent l'un des modèles du pack MongoDB

Pour changer le seuil sur tous les hôtes qui utilisent l'un des modèles d'hôte du pack MongoDB, on pourrait être tenté de modifier directement le modèle d'hôte et changer les données personnalisées de cet hôte.

Mais, dans la prochaine mise à jour de Shinken Entreprise, ces modèles d'hôtes/checks peuvent être modifiés, ce qui occasionne un changement de comportement et va probablement causer des problèmes dans votre configuration Shinken.

L'alternative conseillée est de cloner les éléments utilisés dans le pack MongoDB et de les renommer. On peut ensuite modifier sans aucun risque lié aux mises à jour de Shinken Entreprise.

Ce pack MongoDB cloné peut ensuite être modifié et personnalisé selon les besoins.

Par exemple, le changement des seuils s'effectue de la même manière en changeant les données comme décrit dans la section précédente, mais dans l'un des modèles d'hôte du pack MongoDB au lieu de faire cette modification directement dans les hôtes.

Supervision d'un cluster MongoDB

Voici les étapes à suivre pour superviser un cluster MongoDB avec Shinken :

• Assurez-vous qu'il existe un hôte dans Shinken pour chaque nœud de votre cluster MongoDB. Si ce n'est pas le cas, créez les hôtes nécessaires.
• Accrocher le modèle d'hôte mongodb3 sur chacun des hôtes du cluster.
• Modifiez les données des hôtes si nécessaire, par exemple en changeant le port d'écoute si votre cluster MongoDB n'est pas configuré sur le port par défaut.

Supervision d'un cluster MongoDB en SSL

Il est possible d'activer le chiffrement pour les communications au sein d'un cluster MongoDB ( voir la page  Activer le chiffrement ( SSL ) pour les communications d'un cluster MongoDB ). Dans ce cas, le cluster MongoDB refuse les connexions d'un serveur qui ne fournit pas un certificat qu'il reconnait. 

Le modèle mongodb3 ainsi que les machines de supervision Shinken nécessitent d'être paramétrés pour superviser un Cluster MongDB en SSL. 

Création des certificats nécessaires à la supervision d'un cluster MongoDB en SSL

Pour superviser un cluster MongoDB en SSL, il faut que les machines qui exécutent les check de supervision du pack disposent de certificats acceptés par le cluster MongoDB. Ces machines correspondent aux machines des Pollers et à la machine du Synchronizer.

• Si vous disposez déjà de certificats :
  • il faut vous assurer qu'ils ont été par la même autorité de certification que celle du cluster (  correspond à la clé CAFile dans le fichier de configuration du démon )

net:
  ssl:
    mode: requireSSL
    PEMKeyFile: /etc/shinken/certs/mongodb/NODEX.pem
    CAFile: /etc/shinken/certs/mongodb/ca-cert.pem

• • Pour afficher les détails d'un certificat :

openssl x509 -in /chemin/vers/le/fichier/certificat.crt -text -noout

• Si vous ne disposez pas de certificats et souhaitez en créer :

• • Pour chaque serveur qui exécute les checks, lancer les commandes suivantes :
    • En remplaçant nom_serveur par le nom du serveur Shinken, tel qu'il est connu par le serveur DNS.
    • En remplaçant Organization Inc. par la valeur utilisée pour le certificat de l'autorité de certification
    • ca-cert.pem et ca-key.pem correspondent à la clé de chiffrement et au certificat de votre autorité de certification

/opt/shinken/openssl/bin/openssl req -newkey rsa:2048 -nodes -days 365000 -keyout nom_serveur-key.pem -out nom_serveur-req.pem -subj "/C=FR/L=Paris/O=Organization Inc./OU=Shinken MongoDB Supervision/CN=nom_serveur"
/opt/shinken/openssl/bin/openssl x509 -req -days 365000 -set_serial "0x`openssl rand -hex 8`" -in nom_serveur-req.pem -out nom_serveur-cert.pem -CA ca-cert.pem -CAkey ca-key.pem
cat nom_serveur-key.pem nom_serveur-cert.pem > nom_serveur.pem

• Sur les machines qui exécutent les check de supervision, vous devez disposer des deux certificats suivants ( nous conseillons de mettre vos certificats dans le dossier /etc/shinken/certs/mongodb, dans tous les cas ils doivent être placés au même endroit pour toutes les machines qui executent les checks ) :
  • ca-cert.pem, contient le certificat de l'autorité de certification, qui permet de certifier l'authenticité du cluster. Ce certificat permet de s'assurer que le cluster est bien celui qu'il prétend être.
  • nom_serveur.pem, contient le certificat qui certifie l'authenticité du serveur de supervision vis-à-vis du cluster MongoDB. Ce certificat permet au cluster de s'assurer que le serveur de supervision est bien celui qu'il prétend être.

Paramétrage du modèle mongodb3

• Depuis l'interface de configuration, modifier les commandes de tous les checks sauf qui s'attachent au modèle d'hôte mongodb :

  • Ajouter à la fin de la ligne de chaque commande : 

    Code Block
    language text theme Emacs
    --ssl --ssl-cert-file "$_HOSTMONGO_SSL_CERT$" --ssl-ca-cert-file "$_HOSTMONGO_CA_CERT$"

    

  • Sur les hôtes de chaque noeud du cluster MongoDB, ajouter les données MONGO_CA_CERT et MONGO_SSL_CERT qui pointent vers les certificats qui correspondent :

    

Version des scripts livrés

check_mongodb.py : 2019-04-24