Contexte
Lorsque vous installez Shinken enterprise, un certain nombre de modèles et de commandes sont inclus dans votre configuration.
Le pack "snmp_checks", comme son nom l'indique, permet de superviser des hôtes sur lesquels est installé un système d'exploitation basé sur Linux ou Windows (serveur ou client) via le protocole SNMP.
Il contient 17 commandes, 17 modèles de checks dédiés à 2 modèles d'hôte spécifiques (nommés "linux" et "linux-advanced").
Toutes les commandes de ce pack se basent sur des scripts présents dans le répertoire des scripts shinken /var/lib/shinken/libexec (ou $PLUGINSDIR$ depuis l'interface de configuration).
Le protocole SSH (Secure Shell) est utilisé par chacun des 15 scripts du pack linux. Les scripts communiqueront avec votre machine directement par un invite de commande après s'être connecté avec les identifiants SSH que vous aurez paramétré.
Nous allons ici détailler ces checks associés au modèle Linux de ce pack.
Sommaire des checks
Modèle linux_by_snmp
Modèle windows_by_snmp
| Check Name | Description |
|---|---|
| CPU | Récupère et vérifie le Load Average du CPU |
| Disks | Récupère et vérifie les informations de taille des disques |
| Memory | Récupère et vérifie les informations concernant la RAM |
| Process | Récupère et vérifie les informations concernant les processus du système |
| Check Name | Description |
|---|---|
| CPU | Récupère et vérifie le Load Average du CPU |
| Disks | Récupère et vérifie les informations de taille des disques |
| Memory | Récupère et vérifie les informations concernant la RAM |
| Process | Récupère et vérifie les informations concernant les processus du système |
| Windows Services | Récupère et vérifie les informations concernant les services Windows du système |
Les modèles d'hôte Linux et ses données héritées
Les modèles d'hôtes windows_by_snmp et linux_by_snmp, sur lesquels sont accrochés les différents checks dédiés, contiennent des données (locales) qui seront utilisés par les checks. Ces données seront invoquées par les checks et commandes via $_HOST suivi du nom de la variable.
Exemple : $_HOSTSNMP_PROCESS$ utilisera la donnée nommée SNMP_PROCESS (quelle soit locale ou héritée d'un modèle).
Pour un hôte qui hérite par exemple du modèle windows_by_snmp ou linux_by_snmp de notre pack, ces données seront donc héritées également, mais elles pourront aussi être surchargées directement sur l'hôte (attention aux conflits de nom des données).
Si vous souhaitez modifier de manière globale ces données, ou en rajouter, faites le directement sur le modèle voulu, ceci s'appliquera alors à tous vos hôtes utilisant ce modèle.
Pour plus d'information, veuillez consulter la page sur les Remplacement dynamique de contenu.
|
|
Comment utiliser le pack snmp_checks
Le pack snmp_checks peut être utilisé en appliquant le modèle souhaité à un hôte. Il existe deux manières de procéder :
En utilisant l'interface de Configuration
Dans l'interface de Configuration, créez ou éditez un Hôte, et ajoutez le modèle windows_by_snmp ou linux_by_snmp grâce au menu déroulant.
En éditant les fichiers de configuration
Dans un fichier de configuration, créez ou éditez votre définition d'hôte en ajoutant, dans le propriété "use", la valeur "windows_by_snmp " ou "linux_by_snmp" selon les besoins.
Le fichier de configuration devra alors être importé avec une source (plus d'information sur cette page: Import de fichier de configuration).
Configuration de la connexion SNMP
Pour l'exécution correcte des commandes, vous aurez besoin du service SNMP sur l'hôte supervisé.
Quelques informations au préalable sont nécessaires pour la bonne compréhension de cette partie.
D'une part, du côté de l'architecture Shinken, l'exécution des commandes sont réalisées par les Pollers, en tant qu'utilisateur "shinken". Comme pour tous les serveurs hébergeant Shinken, cet utilisateur est un utilisateur sans mot de passe par défaut. (les connexions SSH vers les serveurs Shinken via cet utilisateur ne sont donc possibles qu'avec une clé SSH)
D'autre part, du côté des machines Linux supervisées, un nom d'utilisateur, et une clé SSH ou mot de passe sont requis. Dans le modèle Linux, des données sont prévues à cet effet.
Nous conseillons l'utilisation d'un utilisateur spécifique (pour le service de supervision) ainsi que l'utilisation d'une connexion via clé SSH, afin d'éviter l'utilisation du super utilisateur root qui n'est pas requis par les checks.
Si vous utilisez le pack linux pour superviser vos serveurs hébergeant Shinken, vous pouvez utiliser l'utilisateur déjà créé et utilisé par Shinken Entreprise : shinken. Si vous choisissez cet utilisateur, vous n'aurez pas besoin de données particulières pour vos modèles d'hôte linux ou linux-advanced car les valeurs par défaut à l'installation de shinken suffiront (voir le tableau de données plus bas dans cette page). Il faudra par contre réaliser les autorisations manuelles via clé SSH. |
Par défaut, vos serveurs Shinken autorisent les connexions SSH émises par l'utilisateur shinken de leur propre serveur. Donc dans le cas d'une installation rapide, le Poller pourra exécuter avec succès les requêtes SSH envoyées sur lui même, sans que vous ne fassiez de manipulations avec les clés. |
Côté client (machine ou serveur linux supervisé)
- Si votre utilisateur de supervision n'est pas déjà créé sur votre linux à superviser, depuis un terminal de la machine supervisée "linux-1" (en root), il faut créer un nouvel utilisateur local avec mot de passe (dans cet exemple user-service-shinken mais vous pouvez créer un autre utilisateur)
[root@linux-1 ~]# adduser -m -r user-service-shinken [FACULTATIF] : [root@linux-1 ~]# passwd user-service-shinken |
| Notez que la mise en place d'un mot de passe pour cet utilisateur n'est pas obligatoire, mais il vous faudra copier la clé SSH via la méthode manuelle expliquée plus bas car la commande automatique ssh-copy-id requiert un mot de passe pour l'utilisateur du système de destination. |
Côté serveur Poller
Copie de la clé SSH de votre utilisateur de supervision "user-service-shinken" depuis le serveur Poller "shinken-poller" (pour cet exemple), vers le serveur supervisé "linux-1" (dans cet exemple, ip 192.168.1.19)
Copie clé SSH via commande ssh-copy-id
- Soit via la méthode "automatique" via la commande ssh-copy-id en se connectant au préalable via l'utilisateur shinken sur le ou les serveurs pollers :
[root@shinken-poller ~]# su - shinken [shinken@shinken-poller ~]# ssh-copy-id -i ~/.ssh/id_rsa user-service-shinken@linux-1 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 user-service-shinken@linux-1's password: XXXXXXXXXXX Now try logging into the machine, with "ssh 'user-service-shinken@linux-1'", and check in: .ssh/authorized_keys to make sure we haven't added extra keys that you weren't expecting. |
Copie clé SSH via commande ssh
- Soit via une commande SSH depuis le serveur Poller, il s'agit d'ajouter la clé publique au fichier "authorized_keys" du serveur supervisé (ici vm2) :
cat /var/lib/shinken/.ssh/id_rsa.pub | ssh root@vm2 "cat >> /var/lib/shinken/.ssh/authorized_keys" |
Ici la connexion se fait via l'utilisateur root du serveur vm2 (mais vous pouvez utiliser votre propre utilisateur), le but étant de rajouter, en une commande SSH, la clé de l'utilisateur shinken du Poller /var/lib/shinken/.ssh/id_rsa.pub à la fin du fichier /var/lib/shinken/.ssh/authorized_keys du serveur supervisé.
Copie clé SSH manuellement
- Soit via méthode "manuelle" via rajout de la clé dans le fichier authorized_keys
- Récupérez la clé publique de l'utilisateur qui va établir la connexion SSH, et la copier
[root@shinken-poller ~]# su - shinken [-bash-4.1]$ less .ssh/id_rsa.pub -> copiez la clé |
- Connectez vous sur le serveur linux supervisé avec votre utilisateur de supervision et collez cette clé dans le fichier "authorized_keys" de l'utilisateur de supervision:
[root@linux-1 ~]# su - user-service-shinken [-bash-4.1]$ vi .ssh/authorized_keys -> collez la clé |
Test de connexion
- Test de connexion au serveur "remote-host" en tant qu'utilisateur user-service-shinken via l'utilisateur du Poller (shinken) :
[root@shinken-poller ~]# su - shinken [shinken@shinken-poller ~]# ssh user-service-shinken@linux-1 -i .ssh/id_rsa |
La connexion doit s'établir avec succès.
Côté interface de configuration
Dans chaque hôte héritant du modèle d'hôte linux ou linux-advanced, vous aurez 4 données concernant la connexion SSH, ces 4 données seront par la suite utilisées par tous les checks linux et linux-advanced. Contrairement aux autres données, les valeurs par défaut de celles-ci sont configurées dans un certain fichier en central (serveur hébergeant l'Arbiter) /etc/shinken/resource.d/ssh.cfg.
| Donnée | Description | Valeur par défaut | Valeur par défaut à l'installation de shinken |
|---|---|---|---|
| SSH_KEY | Répertoire de la clé générée sur votre serveur hébergeant le démon Poller | $SSH_KEY$ | ~/.ssh/id_rsa |
| SSH_KEY_PASSPHRASE | Mot de passe utilisé pour l'authentification de l'utilisateur ou pour utiliser la clé privée ("Passphrase") si nécessaire | $SSH_KEY_PASSPHRASE$ | '' |
| SSH_PORT | Port de connexion SSH | $SSH_PORT$ | 22 |
| SSH_USER | Utilisateur pour la connexion SSH | $SSH_USER$ | shinken |
|
Par exemple, voici le paramétrage d'une connexion via clé SSH par défaut :
Par exemple, voici le paramétrage d'une connexion via Utilisateur/Mot de passe :
Commandes additionnelles
Dans l'idée d'apporter un service personnalisé certaines commandes n'ont volontairement pas été ajoutées en tant que check dans le pack-linux. En effet des scripts permettent au cas par cas de rajouter des options spécifiques à votre supervision et ne sont donc pas compatible avec tous les types de machines. Pour éviter donc de vous proposer un service qui ne vous sera peut-être pas utile nous avons mis à votre disposition la commande simple que vous pourrez utiliser en créant un check. Pour plus d'informations rendez-vous sur la page Commandes additionnelles.