Contexte
Sommaire des checks
2 modèles d'hôtes sont inclus à ce pack, le modèle linux_by_snmp (pour les OS Linux) et le modèle windows_by_snmp (pour les OS Windows).
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 Linuxhôtes et
sesleurs 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.
| Panel |
|---|
|
| Panel |
|---|
|
Comment utiliser le pack snmp_checks
Le pack snmp_checks peut 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.
| Info | ||
|---|---|---|
| ||
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. |
| Info | ||
|---|---|---|
| ||
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)
| Code Block |
|---|
[root@linux-1 ~]# adduser -m -r user-service-shinken
[FACULTATIF] : [root@linux-1 ~]# passwd user-service-shinken |
| Info |
|---|
| 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 :
| Code Block | ||
|---|---|---|
| ||
[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. |
Côté client (machine ou serveur supervisé)
Linux
Sur votre serveur supervisé avec l'OS Linux, il vous faut installer les paquets net-snmp et net-snmp-utils :
| Code Block |
|---|
yum -y install net-snmp net-snmp-utils |
Ensuite, par précaution, faîtes une copie puis éditez le fichier de configuration de snmpd :
| Code Block |
|---|
cp /etc/snmp/snmpd.conf /etc/snmp/snmpd.conf.bak
vim /etc/snmp/snmp.conf |
La ligne suivante permet de changer la communauté public vers une communauté propre à votre réseau et plus ou moins complexe (remplacez public par la chaîne de caractères que vous souhaitez):
| Code Block |
|---|
####
# First, map the community name "public" into a "security name"
# sec.name source community
com2sec notConfigUser default public |
Par défaut, le fichier de configuration associe ensuite (étape 3 dans le fichier) le nom de sécurité ("notConfigUser") à une vue d'accès restreintes à certains OID ("systemview").
Pour un accès sur l'ensemble des OIDs du système, utilisez une nouvelle vue "all":
| Code Block |
|---|
####
# Third, create a view for us to let the group have rights to:
# Make at least snmpwalk -v 1 localhost -c public system fast again.
# name incl/excl subtree mask(optional)
#view systemview included .1.3.6.1.2.1.1
#view systemview included .1.3.6.1.2.1.25.1.1
view all included .1 |
Et par conséquent, remplacez la vue "systemview" par "all" dans la dernière étape de configuration du fichier :
| Code Block |
|---|
# group context sec.model sec.level prefix read write notif
access notConfigGroup "" any noauth exact all none none |
Vous pouvez maintenant démarrer le démon SNMPD :
| Code Block |
|---|
service snmpd start
|
Pensez à redémarrer le service snmpd à chaque modification du fichier de configuration snmpd.conf.
Pour un démarrage du service snmpd à chaque démarrage de votre machine, utilisez la commande :
| Code Block |
|---|
chkconfig snmpd on |
Vous pouvez tester votre service snmpd avec la commande snmpwalk (changez la communauté si besoin) :
| Code Block |
|---|
snmpwalk -v 1 -c public localhost |
Windows
Côté serveur Poller
Les scripts sont exécutés par le ou les serveurs Poller. Les commandes sont basées sur des scripts PERL.
Les prérequis sont déjà installés avec Shinken Enterprise, donc aucune action n'est censée être requise.
Pour information, les librairies Perl ainsi que net-snmp-utils et net-snmp-libs sont nécessaires pour le bon fonctionnement
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) :
| Code Block | ||
|---|---|---|
| ||
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
| Code Block | ||
|---|---|---|
| ||
[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:
| Code Block | ||
|---|---|---|
| ||
[root@linux-1 ~]# su - user-service-shinken
[-bash-4.1]$ vi .ssh/authorized_keys
-> collez la clé |
Test de connexion
| Code Block |
|---|
[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.
Répertoire de la clé générée sur votre serveur hébergeant le démon Poller
Mot de passe utilisé pour l'authentification de l'utilisateur ou pour utiliser la clé privée ("Passphrase") si nécessaire
Port de connexion SSH
Utilisateur pour la connexion SSH
| Info | ||
|---|---|---|
| ||
|
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.