{{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.
yum install net-snmp
chkconfig snmpd on
service snmpd start
Si vous avez des iptables, pensez à ajouter une règle pour autoriser vos machines de supervision. Pour cela, éditer les règles Iptables :
vim /etc/sysconfig/iptables
Et ajouter la règle :
-A INPUT -p udp -s --dport 161 -j ACCEPT
Puis relancer Iptables :
service iptables restart
== 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 :
vim /etc/snmp/snmpd.conf
Premièrement, on va autoriser notre serveur de supervision ainsi que localhost. On ne déclare qu'une seule communauté de sécurité (com2sec) :
com2sec supervision 127.0.0.1 public
com2sec supervision public
On va donner des droits à cette communauté de sécurité sous forme de groupes, dans notre cas de la simple lecture :
group ReadOnly v2c supervision
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 :
view systemInfo included .1.3.6.1.4.1.2021.10
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) :
access ReadOnly "" any noauth exact systemInfo none none
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.
#
# Fichier de conf minimale SNMPd
#
# Parametres globaux
syslocation .
syscontact @
# Declaration des machines autorisees
# Nom Source Communaute
com2sec supervision 127.0.0.1 public
com2sec 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
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 :
vim /etc/snmp/snmpd.conf
A la fin de fichier, on ajoute un appel à notre script :
extend /