AdminSysGNULinux

Cette page est en lecture seule. Vous pouvez afficher le texte source, mais ne pourrez pas le modifier. Contactez votre administrateur si vous pensez qu'il s'agit d'une erreur.
{{tag>Brouillon SNMP}}

= SNMPd - Configuration et ajout d'IODs perso

Source : http://blog.gamb.fr/index.php?post/2012/10/23/Installation-et-configuration-de-snmpd

Quand la supervision doit récupérer des valeurs systèmes, il y a autant de solutions que d’administrateurs. On peut déployer un agent, ouvrir tous les ports, passer par une page web, faire du ssh, etc.
Le moyen le plus simple et efficace est de passer par le protocole SNMP. Il est donc nécessaire d'installer et de configurer un démon SNMP sur vos serveurs. Nous allons rapidement configurer le démon puis nous allons nous attarder sur l'ajout d'OID perso.


== Installation

Le démon SNMP est disponible pour quasiment toutes les distributions Linux, je l'avais même installé sur un Solaris 10. Sur un système Red Hat, il suffit de lancer une commande YUM.

<code bash>
yum install net-snmp
chkconfig snmpd on
service snmpd start
</code>


Si vous avez des iptables, pensez à ajouter une règle pour autoriser vos machines de supervision. Pour cela, éditer les règles Iptables :

<code bash>
vim /etc/sysconfig/iptables
</code>

Et ajouter la règle :
<code ->
-A INPUT -p udp -s <ip_serveur_supervision> --dport 161 -j ACCEPT
</code>

Puis relancer Iptables :
<code bash>
service iptables restart
</code>

== Configuration


Globalement, le fichier de configuration snmpd est constitué de quatre parties : Les machines autorisées à interroger SNMPd, les droits de lecture/écriture, les vues de la MIB et enfin les accès machines/vues. On édite le fichier :
<code bash>
vim /etc/snmp/snmpd.conf
</code>

Premièrement, on va autoriser notre serveur de supervision ainsi que localhost. On ne déclare qu'une seule communauté de sécurité (com2sec) :
<code ->
com2sec supervision      127.0.0.1                    public
com2sec supervision      <ip_serveur_supervision> public
</code>

On va donner des droits à cette communauté de sécurité sous forme de groupes, dans notre cas de la simple lecture :
<code ->
group   ReadOnly        v2c             supervision
</code>

J'ai pour habitude d'autoriser les requêtes en V1 et V2 du protocole SNMP mais vous pouvez activer seulement la V2.

On va ensuite déclarer des vues, c'est à dire des branches de la MIB qui seront consultables. Certains utilisent .1 pour rendre tout l'arbre consultable, pour ma part je préfère n'ouvrir que ce que j'ai besoin :
<code ->
view    systemInfo      included        .1.3.6.1.4.1.2021.10
</code>

Dans cet exemple, on expose que le load average de la machine. N'hésitez pas à faire un snmpwalk pour trouver l'OID des objets que vous souhaitez exposer. (Penser à tout autoriser pour le walk : view systemInfo all .1).

Pour conclure, on va associer les vues aux groupes d'accès (celui où on dit si c'est en lecture ou en écriture) :
<code ->
access  ReadOnly        ""              any     noauth          exact   systemInfo      none    none
</code>

Voila de façon très macroscopique les points importants de la configuration. Plutôt que de m'attarder sur cette partie, je vous fourni un modèle de configuration minimale dans la suite.

Modèle de fichier de configuration


Voici un fichier de conf mini-minimale, je vous conseille de vous faire un fichier équivalent avec les OID communs à tous vos serveurs.

<code - /etc/snmp/snmpd.conf>
#
# Fichier de conf minimale SNMPd
#

# Parametres globaux
syslocation <mon_serveur>.<mon_domaine>
syscontact <admin>@<mon_domaine>

# Declaration des machines autorisees
#       Nom             Source          Communaute
com2sec supervision      127.0.0.1           public
com2sec supervision      <ip_serveur_supervision>   public

# Declaration des groupes d'acces
#       Nom             Version         Com2sec
group   ReadOnly        v2c            supervision
group   ReadOnly        v1              supervision

# Declaration des vues
#       Nom             Incl/Excl       Subtree         Masque (optionnel)
view    systemInfo      included        .1.3.6.1.4.1.2021.10

# Association Group et View
#       GroupName       Contexte        Version SecLevel        Prefix  Read            Write   Notif
access  ReadOnly        ""              any     noauth          exact   systemInfo      none    none

# OID perso
</code>

Vous constatez à la fin que j'ai prévu une zone pour les OID perso, et oui on peut étendre la MIB suivant nos besoins ! Très pratique pour monitorer des valeurs systèmes spécifiques.

== Exécuter ses propres scripts

Il est possible d'étendre la MIB de plusieurs façons. Certains logiciels ajoutent leur OID via un agentx, par exemple cyrus-imap propose cela dans ses versions les plus récentes. Mais des fois, pour des besoins très spécifiques, on aimerait récupérer la sortie d'un script. La chose est faisable très simplement avec snmpd.

Plusieurs directives peuvent être utilisées dans le fichier de conf : pass, exec et extend. Visiblement, le net-snmp disponible sur les RHEL6, ne permet d’utiliser que extend, mais la syntaxe est identique à exec. Pass a un comportement différent, un script n'est pas égale à un OID mais à un ensemble, peut être pratique pour les scripts qui sortent plusieurs lignes de résultat.

Ici, on va mettre en œuvre extend pour exécuter un script sur le serveur supervisé et récupérer la valeur avec snmpget.

On édite le fichier de configuration principal :
<code bash>
vim /etc/snmp/snmpd.conf
</code>

A la fin de fichier, on ajoute un appel à notre script :
<code ->
extend  <oid_perso>   <nom_script_friendlyuser>     <chemin_script>/<script> <args>
</code>

Comment choisir un OID perso ? Il y a une branche de la MIB dédiée à cela, elle est préfixé ucdavis (un truc du genre) et son équivalent en numérique est : ''.1.3.6.1.4.1.2021''

Il suffit donc de choisir un suffixe pour votre script. Sur vos nombreux serveurs, faites en sorte de ne pas avoir des scripts qui répondent sur le même OID alors qu'ils ne font pas la même chose, ça sera plus simple à gérer.


== Exemple : Récupérer les infos d'un volume groupe LVM

Pour illustrer la puissance des OID perso, on va essayer de récupérer quelques infos concernant un volume group. Premièrement, dans un shell, essayons de trouver la commande qui va bien :
<code bash>
vgdisplay -s VolGroup00
</code>

Ce qui renvoi : 
<code ->
"VolGroup00" 136.12 GiB [75.97 GiB used / 60.16 GiB free]
</code>

Pour notre exemple, ça sera suffisant, on édite donc le fichier de conf snmp :
<code bash>
vim /etc/snmp/snmpd.conf
</code>

On ajoute une vue pour notre OID perso :
<code ->
view    systemInfo      included        .1.3.6.1.4.1.2021.900
</code>

Et on ajoute, à la fin du fichier, la ligne suivante :
<code ->
extend .1.3.6.1.4.1.2021.900    stats_vg0       /sbin/vgdisplay -s
</code>

J'ai choisi l'OID de façon arbitraire et avec une grosse valeur pour éviter d'éventuels conflits. De même, ayez le réflexe de toujours mettre le chemin complet des binaires.

On redémarre notre snmpd :
<code bash>
service snmpd restart
</code>

Maintenant, on test avec snmpwalk le résultat :
<code bash>
snmpwalk -c public -v2c localhost .1.3.6.1.4.1.2021.900
</code>

Et voici le résultat :
<code ->
UCD-SNMP-MIB::ucdavis.900.1.0 = INTEGER: 1
UCD-SNMP-MIB::ucdavis.900.2.1.2.9.115.116.97.116.115.95.118.103.48 = STRING: "/sbin/vgdisplay"
UCD-SNMP-MIB::ucdavis.900.2.1.3.9.115.116.97.116.115.95.118.103.48 = STRING: "-s"
UCD-SNMP-MIB::ucdavis.900.2.1.4.9.115.116.97.116.115.95.118.103.48 = ""
UCD-SNMP-MIB::ucdavis.900.2.1.5.9.115.116.97.116.115.95.118.103.48 = INTEGER: 5
UCD-SNMP-MIB::ucdavis.900.2.1.6.9.115.116.97.116.115.95.118.103.48 = INTEGER: 1
UCD-SNMP-MIB::ucdavis.900.2.1.7.9.115.116.97.116.115.95.118.103.48 = INTEGER: 1
UCD-SNMP-MIB::ucdavis.900.2.1.20.9.115.116.97.116.115.95.118.103.48 = INTEGER: 4
UCD-SNMP-MIB::ucdavis.900.2.1.21.9.115.116.97.116.115.95.118.103.48 = INTEGER: 1
UCD-SNMP-MIB::ucdavis.900.3.1.1.9.115.116.97.116.115.95.118.103.48 = STRING: "  \"VolGroup00\" 136.12 GiB [75.97 GiB used / 60.16 GiB free]"
UCD-SNMP-MIB::ucdavis.900.3.1.2.9.115.116.97.116.115.95.118.103.48 = STRING: "  \"VolGroup00\" 136.12 GiB [75.97 GiB used / 60.16 GiB free]"
UCD-SNMP-MIB::ucdavis.900.3.1.3.9.115.116.97.116.115.95.118.103.48 = INTEGER: 1
UCD-SNMP-MIB::ucdavis.900.3.1.4.9.115.116.97.116.115.95.118.103.48 = INTEGER: 0
UCD-SNMP-MIB::ucdavis.900.4.1.2.9.115.116.97.116.115.95.118.103.48.1 = STRING: "  \"VolGroup00\" 136.12 GiB [75.97 GiB used / 60.16 GiB free]"
</code>

On constate qu'il s'agit d'un arbre, votre outil de supervision n'a besoin que de la valeur de résultat, on modifie donc notre commande snmpwalk pour ne garder que le nécessaire :
<code bash>
snmpwalk -OQnv -c public -v2c localhost .1.3.6.1.4.1.2021.900.4.1.2.9.115.116.97.116.115.95.118.103.48.1 | tr -d "\""
</code>

Ce qui nous donne comme résultat :
<code ->
\VolGroup00\ 136.12 GiB [75.97 GiB used / 60.16 GiB free]
</code>

== Conclusion


SNMP peut servir pour toute la supervision, pas besoin d'ouvrir plus de port, d'installer des agents dédiés (nrpe, agent zabbix, etc). Pour les taches un peu plus complexes, déployer un script qui fait le boulot de collecte et de formatage sur votre serveur à superviser et récupérer simplement la valeur via SNMP. Pour info, dans les "data input methods" de Cacti, j'appelle directement une commande snmpget comme celle ci :
<code bash>
snmpget -OQnv -c <snmp_community> -v2c <hostname> <oid_perso> | tr -d "\""
</code>