Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Make by tools (01.00.01) - action=same_as_next_version
Scroll Ignore
scroll-pdftrue
scroll-officetrue
scroll-chmtrue
scroll-docbooktrue
scroll-eclipsehelptrue
scroll-epubtrue
scroll-htmltrue
Panel
titleSommaire

Table of Contents
stylenone

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 État des replicaset ;
  • Délai de réplicationÉditer un Hôte ;

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.

La configuration pour le Pack Linux, est similaire et peut être réutilisée.

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"
  • Vérifier 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
    languagetext
    themeEmacs
    adduser -m -r shinken
    passwd shinken

Côté Shinken (serveur Poller)

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

Code Block
languagetext
themeEmacs
[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 pour superviser MongoDB :

  • Mongodb
  • Mongodb-no-replication ( si l'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éer et éditer un hôte et ajouter le modèle d'hôte choisi dans la liste des modèles d'hôtes utilisés ( voir la page Éditer un Hôte ).

Via un fichier de configuration

Dans un fichier de configuration .cfg, 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 ( voir la page Syntaxe des fichiers d'imports ).

Authentification de la base Mongo

Si l'authentification avec mot de passe est activée sur le MongoDB à superviser, 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 ;
  • La donnée MONGO_AUTH_DATABASE permet de définir la base où l'utilisateur utilisé été crée ( défaut : admin ) ;

Utilisation de SSL avec la base Mongo

Si Mongodb est configuré pour utiliser ssl, il est possible de paramétrer les données des modèles Mongo pour pouvoir superviser la base de données :


  • La donnée MONGO_USE_SSL permet d'indiquer s'il faut ou non utiliser ssl pour superviser Mongo. Valeurs possibles :
    • true pour activer le ssl.
    • false pour ne pas utiliser ssl.
  • La donnée MONGO_SSL_CA_FILE permet d'indiquer le chemin absolu ( sur le serveur du poller ) vers le fichier .pem de l'autorité de certification ( CA ) pour la vérification du certificat présenté par l'instance mongod ou mongos.
  • La donnée MONGO_SSL_PEM_KEY_FILE permet d'indiquer le chemin absolu ( sur le serveur du poller ) vers le fichier .pem qui contient le certificat et la clé à présenter à l'instance mongod ou mongos.
  • La donnée MONGO_SSL_PEM_KEY_PASSWORD permet d'indiquer le mot de passe ( s'il y en a un ) pour pouvoir déchiffrer la clé et le certificat à présenter à l'instance mongod ou mongos
  • La donnée MONGO_SSL_ALLOW_INVALID_HOSTNAMES permet d'indiquer si on vérifie ou non que le nom d'hôte sur le certificat de l'instance mongod ou mongos que l'on contacte correspond au nom utilisé pour contacter le serveur. Si la vérification est activée et que les noms ne correspondent pas une erreur sera remontée et la supervision ne pourra pas être effectuée. Valeurs possibles :
    • true pour activer la vérification
    • false pour désactiver la vérification
  • La donnée MONGO_SSL_ALLOW_INVALID_CERTIFICATES permet d'indiquer si on vérifie ou non la validité du certificat de l'instance mongod ou mongos que l'on contacte. Si la vérification est activée et que le certificat n'est pas valide ( par exemple s'il a expiré ) une erreur sera remontée et la supervision ne pourra pas être effectuée. Valeurs possibles :
    • true pour activer la vérification
    • false pour désactiver la vérification
  • La donnée MONGO_SSL_CRL_FILE permet d'indiquer le chemin absolu ( sur le serveur du poller ) vers le fichier .pem qui contient la liste de révocation des certificats ( Certificate Revocation List )


Info

Pour les données indiquant des chemins de fichiers, à savoir :

  • MONGO_SSL_CA_FILE
  • MONGO_SSL_PEM_KEY_FILE
  • MONGO_SSL_CRL_FILE

Le chemin indiqué doit être le chemin absolu ( depuis la racine ) du fichier sur le serveur du Poller pour pouvoir superviser Mongodb, mais pour pouvoir tester les checks mongodb depuis l'interface de configuration, les fichiers doivent également être présents sur le Synchronizer et leurs chemins être identiques à ceux sur le Poller.

Résumé des checks


Nom du checkDescriptionSeuil Warning par défautSeuil Critique par défautDisponible dans les modèles
1Mongodb-connectionVérifie le temps d'établissement d'une connection (en secondes)MONGO_CONNECT_WARN >2MONGO_CONNECT_CRIT > 4
  • mongodb
  • mongodb3
  • mongodb-no-replication
  • mongodb3-no-replication
2Mongodb-flush-timeVérifie le temps moyen d'écriture des données sur disque (en ms)MONGO_FLUSHING_WARN > 100MONGO_FLUSHING_CRIT > 200
  • mongodb
  • mongodb3
  • mongodb-no-replication
  • mongodb3-no-replication
3Mongodb-index-miss-ratioVérifie le pourcentage d'échec lors de recherches dans les index. Si ce pourcentage est trop haut, cela peut signifier qu'il faut ajouter d'autres index.MONGO_INDEX_MISS_RATION_WARN > 0.005MONGO_INDEX_MISS_RATION_CRIT > 0.01
  • mongodb
  • mongodb-no-replication
4Mongodb-last-flushVérifie le dernier temps d'écriture des données sur disque (en ms) ; si ce temps devient trop élevé cela pourrait signifier qu'il faut des disques plus rapides ou qu'il est temps  de répartir les données entre plus de serveurs (sharding)MONGO_LAST_FLUSH_TIME_WARN > 200MONGO_LAST_FLUSH_TIME_CRIT > 400
  • mongodb
  • mongodb3
  • mongodb-no-replication
  • mongodb3-no-replication
5Mongodb-lock-timeVérifie le pourcentage du temps passé à attendre la libération de verrous. Un pourcentage trop important signifie la plupart du temps que le serveur est surchargé.MONGO_LOCK_WARN > 5MONGO_LOCK_CRIT > 10
  • mongodb
  • mongodb-no-replication
6Mongodb-open-connections

Vérifie le pourcentage de connexions utilisées dans le serveur Mongo.

MONGO_CONNECTIONS_WARN > 70MONGO_CONNECTIONS_CRIT > 80
  • mongodb
  • mongodb3
  • mongodb-no-replication
  • mongodb3-no-replication
7Mongodb-queries-stat-deleteVérifie le nombre de suppressions par secondeMONGO_DELETE_PER_SEC_WARN_LEVEL > 10000MONGO_DELETE_PER_SEC_CRIT_LEVEL > 20000
  • mongodb
  • mongodb3
  • mongodb-no-replication
  • mongodb3-no-replication
8Mongodb-queries-stat-insertVérifie le nombre d'insertions par secondeMONGO_INSERT_PER_SEC_WARN_LEVEL > 10000MONGO_INSERT_PER_SEC_CRIT_LEVEL > 20000
  • mongodb
  • mongodb3
  • mongodb-no-replication
  • mongodb3-no-replication
9Mongodb-queries-stat-queryVérifie le nombre de requêtes par secondeMONGO_QUERY_PER_SEC_WARN_LEVEL > 10000MONGO_QUERY_PER_SEC_CRIT_LEVEL > 20000
  • mongodb
  • mongodb3
  • mongodb-no-replication
  • mongodb3-no-replication
10Mongodb-queries-stat-updateVérifie le nombre de mises à jour par secondeMONGO_UPDATE_PER_SEC_WARN_LEVEL > 10000MONGO_UPDATE_PER_SEC_CRIT_LEVEL > 20000
  • mongodb
  • mongodb3
  • mongodb-no-replication
  • mongodb3-no-replication
11Mongodb-replicasetVérifie le statut des noeuds dans un replicaset. Selon le statut renvoyé le check est en WARNING (statuts 0, 3, 5) CRITIQUE (statuts 4,6,8) ou OK (statuts 1, 2, 7)

  • mongodb
  • mongodb3
12Mongo-replication-lag

Délai de réplication entre les serveurs Mongo (en secondes).

Le check utilise la métrique "optime" renvoyée par rs.status(). Cette valeur peut être supérieure au délai réel car les requêtes ne sont effectuées qu'à intervalles de plusieurs secondes. Ainsi, une valeur inférieure à 10 peut ne correspondre à aucun délai réel, mais au délai entre deux requêtes

MONGO_REPLICATION_LAG_WARN > 15MONGO_REPLICATION_LAG > 30
  • mongodb
  • mongodb3

Personnaliser les seuils de Warning et Critique

Le pack MongoDB définit des seuils par défaut sur les checks qu'il utilise. Ses seuils peuvent être modifiés.

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 la 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.



Version des scripts livrés


check_mongodb.py : 2019-04-24