I. Introduction▲
I-A. Les différents articles▲
Initialement, je voulais tout mettre dans un seul article, mais comme il y a énormément de choses à dire au sujet de SNMP et du paquetage Net-SNMP, j'ai préféré simplifier votre tâche de compréhension (et aussi ma tâche de rédaction) en scindant cette étude en plusieurs articles :
- le premier article présente quelques généralités sur SNMP et ne parle que de SNMP en version 1 ;
- le deuxième article, celui-ci, présente les notifications et la supervision toujours en SNMP version 1 ;
- le contenu des articles suivants n'est pas encore connu.
Bien sûr, ces différents articles s'appuieront sur de vrais exemples et pour cela, j'utiliserai une machine virtuelle sous Linux. La distribution que j'utiliserai tout au long de ces articles est une distribution « Debian » parce que j'ai l'habitude de cette distribution. En ce qui concerne l'implémentation SNMP, j'utiliserai le paquetage Net-SNMP.
La majeure partie de la documentation est issue des pages du manuel Unix (man pages) ou alors du site WWW de Net-SNMP. Le but de ces articles n'est pas non plus d'expliquer le rôle de tous les OID de la MIB. Pour cela, on se référera aux RFC ou alors aux documents des constructeurs.
I-B. Un peu plus de dynamisme▲
Si vous avez suivi scrupuleusement l'article précédent, vous devez maintenant avoir un agent SNMP opérationnel. Certes, il est opérationnel, vous pouvez l'interroger, mais il est un peu passif. Pour l'instant, il ne sert que pour mettre à disposition des informations génériques du système, les tables de routages, des statistiques sur les interfaces réseau, le nombre de paquets envoyés et reçus. C'est bien, mais c'est peu.
L'objectif de cet article est de rendre votre agent SNMP un peu plus dynamique et de le faire participer un peu plus activement à la supervision de votre système et surtout plus spécifiquement à votre besoin. L'agent Net-SNMP est très configurable et il permet de s'adapter à quasiment tous les besoins spécifiques.
Pour cela, l'agent SNMP va littéralement surveiller votre système en s'appuyant sur la définition de ce que vous lui demandez de surveiller, c'est-à-dire votre besoin spécifique. En cas d'anomalie, il va pouvoir envoyer une notification à son manager SNMP.
I-C. C'est quoi une notification (ou un trap) ?▲
Une notification (ou trap SNMP en langage anglais) est un message SNMP envoyé par un agent SNMP à son superviseur pour l'informer qu'un événement exceptionnel vient de survenir.
Ce message est asynchrone, c'est-à-dire que le superviseur n'a normalement aucune idée de quand l'agent va envoyer une notification. C'est l'agent, et lui seul, qui décide d'envoyer une notification parce que des événements exceptionnels, gérés ou connus par l'agent, doivent être signalés.
I-D. Les étapes de la supervision▲
Pour mettre en place cette supervision, il y a trois choses à faire :
- la première étape consiste à définir vers qui l'on va envoyer les notifications. C'est le « où » ;
- la deuxième étape consiste à déclarer ce que l'on veut superviser sur la machine. C'est le « quoi » ;
- et enfin la dernière étape consiste à définir comment on va traiter les informations supervisées. C'est le « comment ».
Les éléments d'un système que Net-SNMP peut superviser sont :
- les événements d'arrêt et de redémarrage du système ;
- l'état de certains processus ;
- le taux de remplissage des disques ;
- la charge CPU système ;
- le taux d'utilisation de la mémoire « swap » ;
- la taille de certains fichiers ;
- le contenu de certains fichiers.
Comme ont peut le voir, tous ces événements ne sont pas forcément la cause principale (dans le domaine de la supervision, on parle de « root cause ») du vrai problème (la perte d'une interface réseau peut être liée à l'arrêt d'un switch réseau par exemple), mais ils permettent à un opérateur devant sa console qui reçoit ces événements, de fournir un diagnostic plus élaboré. Si l'opérateur reçoit simultanément des événements « perte d'interface réseau » depuis plusieurs machines, il lui sera alors plus facile d'envisager un problème sur le switch qui connecte toutes ces machines au réseau.
II. Le « où » , vers qui notifier ?▲
Dans ce paragraphe nous allons voir la première étape de la supervision, c'est-à-dire définir vers qui envoyer les notifications.
II-A. Vers qui notifier ?▲
L'adresse IP vers qui notifier, l'adresse IP du manager donc, se spécifie avec la clause « trapsink HOST [COMMUNITY [PORT]] » comme ceci dans le fichier /etc/snmp/snmpd.conf :
trapsink 127.0.0.1 public-trap
Comme vous pouvez le voir, nous configurons l'agent SNMP pour envoyer les traps SNMP en utilisant la communauté « public-trap » (pourquoi pas, cette valeur en vaut bien une autre) vers « localhost », c'est-à-dire lui-même, quelle drôle d'idée ?
II-B. Utilité du démon snmptrapd▲
Je ne sais pas si vous vous rappelez, mais dans l'article précédent nous avons aussi configuré un démon « snmptrapd » qui est lancé lors du démarrage de la machine. Le rôle de ce démon est de recevoir des notifications SNMP (en UDP sur le port 162) et de les traiter.
Vous me direz, pourquoi utiliser un démon snmptrapd qui va renvoyer les notifications plutôt que de configurer directement l'agent snmpd pour envoyer les notifications au bon endroit ? Pour plusieurs raisons :
- tout d'abord, pour la journalisation. En effet, le démon « snmptrapd » journalise dans le fichier /var/log/snmptrapd.log les notifications reçues ;
- ensuite pour des raisons de configuration. Vous pouvez avoir sur la machine plusieurs agents SNMP différents sur plusieurs ports différents. Tous vont vouloir envoyer des notifications SNMP au superviseur, ce qui fait que l'adresse IP du superviseur sera inscrite plusieurs fois dans chacun des fichiers de configuration de ces agents SNMP. En cas de changement d'adresse du superviseur ou d'ajout d'un nouveau superviseur, c'est autant de fichiers de configuration à modifier et autant d'erreurs potentielles. L'idée alors, est de configurer tous ces agents pour envoyer leurs notifications SNMP à la machine locale, donc localhost, et donc au démon snmptrapd. C'est lui qui se charge ensuite de renvoyer les notifications vers le, ou les bons destinataires. Une modification est ainsi plus rapide ;
- et pour finir, le démon « snmptrapd » dispose de différentes options de configuration qui permettent, par exemple, d'exécuter une action sur réception d'une notification ou bien de filtrer les notifications superflues.
C'est pour toutes ces raisons que j'aime bien utiliser le démon « snmptrapd ».
II-C. La syntaxe du fichier « /etc/snmp/snmptrapd.conf »▲
Il y a deux clauses intéressantes dans la configuration du démon « snmptrapd », la clause « authCommunity » et la clause « forward ».
II-C-1. La clause « authCommunity »▲
La clause « authComunnity » permet de spécifier que faire lors de la réception d'une notification. Sa syntaxe est : « authCommunity TYPES COMMUNITY [SOURCE [OID | -v VIEW ]] ».
Cette clause autorise les notifications (et aussi les requêtes SNMPv2c INFORM), dont la communauté est spécifiée, à générer une action. Par défaut, cela autorise toutes les notifications avec cette communauté à être traitées. Le champ SOURCE peut être utilisé pour indiquer que seules les notifications provenant de cette source doivent être traitées.
Les actions qui peuvent être exécutées sont :
- log : enregistre les détails de la notification soit dans le fichier de log, soit sur la sortie standard (stdout), soit sur la sortie d'erreurs (stderr), soit dans Syslog, suivant la configuration de journalisation du démon ;
- execute : appelle un programme externe en lui passant les détails de la notification (voir par exemple le script /usr/local/bin/trap2email) ;
- net : transmets la notification à un autre récepteur de notification par le réseau.
II-C-2. La clause « forward »▲
La clause « forward » permet de transférer une notification à un autre récepteur de notification par le réseau. Sa syntaxe est : « forward OID|default DESTINATION ».
OID permet de mettre en place un filtre sur les notifications à transférer, default permet de transférer toutes les notifications.
II-D. Modification du la configuration de snmptrapd▲
Nous allons modifier la configuration de notre démon « snmptrapd » afin qu'il enregistre toutes les notifications qu'il reçoit et qu'il les transfère par le réseau à notre superviseur.
Pour cela, nous allons mettre dans le fichier « /etc/snmp/snmptrapd.conf » :
2.
authCommunity log,net public-trap
forward default 10.10.10.10
Pour l'instant, j'utilise une adresse arbitraire (10.10.10.10) vers qui envoyer les notifications. Il faut mettre l'adresse IP de votre superviseur SNMP. Il faut ensuite redémarrer le démon « snmptrapd » (mais vous savez faire maintenant).
II-E. Redémarrage de snmpd▲
Après la modification de la configuration de snmptrapd, faites un redémarrage du démon snmpd. Vous verrez dans les log du démon snmptrapd les lignes suivantes :
2.
3.
4.
5.
2012-12-12 15:22:57 192.168.1.204(via UDP: [127.0.0.1]:43516->[127.0.0.1]:162) TRAP, SNMP v1, community public-trap
NET-SNMP-MIB::netSnmpNotificationPrefix Enterprise Specific Trap (NET-SNMP-AGENT-MIB::nsNotifyShutdown) Uptime: 0:00:06.37
2012-12-12 15:22:57 192.168.1.204(via UDP: [127.0.0.1]:55862->[127.0.0.1]:162) TRAP, SNMP v1, community public-trap
NET-SNMP-TC::linux Cold Start Trap (0) Uptime: 0:00:00.08
Ce sont 2 notifications envoyées lors de l'arrêt du démon « snmpd » (la notification NET-SNMP-AGENT-MIB::nsNotifyShutdown) et lors du redémarrage de celui-ci (la notification NET-SNMP-TC::linux Cold Start). C'est le signe que :
- notre démon « snmpd » envoie bien des notifications ;
- notre démon « snmptrapd » reçoit et traite ces notifications.
Et même si l'on fait une trace réseau avec tcpdump, on voit aussi la retransmission de la notification vers 10.10.10.10 :
2.
3.
4.
5.
6.
7.
8.
9.
root@debian:~# tcpdump port 162
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
15:29:05.442428 IP 192.168.1.204.51594 > 10.10.10.10.snmp-trap: C=public-trap Trap(28) E:8072.4 192.168.1.204 enterpriseSpecific s=2 1170
15:29:05.556475 IP 192.168.1.204.37794 > 10.10.10.10.snmp-trap: C=public-trap Trap(29) E:8072.3.2.10 192.168.1.204 coldStart 9
III. Le « quoi » et le « comment » , les prérequis▲
Ce paragraphe va s'attacher à définir ce qu'il faut superviser et comment le superviser. Tout d'abord, nous allons examiner la syntaxe de la clause « monitor » et ensuite nous verrons les différents éléments que l'on peut superviser sur notre système et comment le faire.
III-A. La clause « monitor »▲
La clause monitor est une clause que l'on trouve dans le fichier de configuration du démon « snmpd ». Elle sert à définir comment superviser, une fois que l'on sait ce que l'on veut superviser. Je l'avoue, sa syntaxe et sa compréhension ne sont pas simples. Nous verrons dans les exemples comment on l'utilise.
Le monitoring d'un objet est activé à l'aide de la clause « monitor ». Sa syntaxe est la suivante :
monitor [OPTIONS] NAME EXPRESSION
NAME est le nom logique pour cette entrée. Ce nom logique est utilisé pour indexer la table mteTriggerTable (et celles en relation avec cette table).
Si la condition « EXPRESSION” est remplie (voir ci-dessous), cela déclenche l'événement correspondant et envoie une notification ou applique une commande « SET » (ou les deux). Notez que l'événement ne sera déclenché qu'une seule fois, quand l'expression est vraie pour la première fois. Cette entrée ne se déclenchera à nouveau que quand l'expression sera d'abord fausse puis ensuite vraie.
III-A-1. EXPRESSION▲
Il y a trois types de tests supportés :
- le test d'existence ;
- le test booléen ;
- le test d'intervalle.
Le test d'existence : « OID ou ! OID ou != OID » définit un test existence (0).
- Un OID nu spécifie un test de présence (0) qui est vrai quand l'OID surveillé est créé.
- Une expression de la forme « ! OID » spécifie un test d'absence (1) qui est vrai quand l'OID surveillé est supprimé ou absent. Il doit y avoir un espace entre le signe « ! » et l'OID.
- Une expression de la forme « != OID » spécifie un test de changement (2) qui est vrai quand l'OID surveillé est modifié. Il doit y avoir un espace entre le signe « != » et l'OID.
Le test booléen : « OID OP VALUE » définit un test booléen (1).
- OP doit être un des opérateurs de comparaison (!=, ==, <, <=, >, >=). Il doit y avoir des espaces autour de l'opérateur de comparaison.
- VALUE doit être une valeur entière.
Le test d'intervalle : « OID MIN MAX [DMIN DMAX] » définit un opérateur d'intervalle (2).
- MIN et MAX sont des valeurs entières qui spécifient les bornes inférieures et supérieures de l'intervalle. Si la valeur de l'OID surveillé tombe en dessous de la valeur MIN ou monte au-dessus de la valeur MAX alors l'événement correspondant est déclenché. Notez que l'événement de seuil montant ne sera réarmé que lorsque la valeur surveillée passera en dessous de la limite inférieure (MIN). De même, l'événement de seuil descendant ne sera réarmé que lorsque la valeur surveillée passera au-dessus de la limite supérieure (MAX).
- Les paramètres optionnels DMIN et DMAX configurent une paire de seuils semblables, mais travaillant avec les différences entre échantillons successifs.
III-A-2. OPTIONS▲
Les options qui contrôlent le comportement de la clause monitor sont :
|
-D |
Indique que l'expression doit être évaluée en utilisant les différences entre les valeurs de l'échantillon (plutôt que les valeurs elles-mêmes). |
|
-d OID |
Spécifie un marqueur de discontinuité pour valider les différences. A -di OID sera utilisé exactement comme indiqué. A -d OID aura les sous identifiants ajoutés à l'OID lui-même. Si l'option -i est spécifiée, alors il n'y aura aucune différence entre ces deux options. |
|
-e EVENT |
Spécifie l'événement à invoquer lorsque cette entrée de moniteur est déclenchée. Si cette option n'est pas indiquée, l'entrée du moniteur va générer l'une des notifications standard définies dans DISMAN-EVENT-MIB. |
|
-I |
Indique que l'expression contrôlée doit être appliquée à l'OID comme une instance unique. Par défaut, l'OID sera traité comme un objet avec des « wildcard » et le moniteur étendu pour couvrir toutes les instances correspondantes. |
|
-i OID |
Définit des variables supplémentaires à ajouter à la notification lors de son déclenchement. |
|
-r FREQUENCY |
Spécifie la fréquence de monitoring de l'expression en secondes. Par défaut, cette expression est évaluée toutes les 600 secondes (10 minutes). |
|
-S |
Indique que cette expression ne doit pas être évaluée lors du démarrage de l'agent. |
|
-s |
Indique que cette expression doit être évaluée lors du démarrage de l'agent. C'est le comportement par défaut. |
|
-u SECNAME |
Spécifie le nom d'utilisateur pour récupérer les informations à la place de celui spécifié par « iquerySecName ». Encore une fois, cet utilisateur doit être créé explicitement et avoir un droit de lecture adéquat. |
III-B. Création d'un utilisateur dédié▲
Si l'on regarde dans le fichier /var/log/snmp/snmpd.log, on peut remarquer qu'à chaque lancement du démon SNMP, il y a le message d'erreur suivant :
iquerySecName has not been configured - internal queries will fail
Ce message signifie qu'il n'y a pas de nom d'utilisateur associé aux requêtes internes et donc qu'elles vont échouer.
Ces requêtes internes sont utilisées lorsque l'agent SNMP veut lire de manière asynchrone des informations dans l'arbre SNMP. Il faut bien voir que ces requêtes internes sont exécutées périodiquement et en tâche de fond, donc pas forcément sur demande externe. Comme ces requêtes ne sont pas faites sur demande externe (et ne sont donc pas liées à une communauté ou un utilisateur explicite), il faut les lier à un utilisateur interne.
C'est ce que nous allons faire dans ce paragraphe, créer et utiliser une identité interne pour exécuter des requêtes internes. Cela se traduit par les modifications suivantes dans le fichier « /etc/snmp/snmpd.conf » :
2.
3.
createUser InternalUser MD5 "MD5 password"
rouser InternalUser
iquerySecName InternalUser
Ces 3 lignes vont créer un utilisateur nommé « InternalUser » avec un mot de passe MD5, lui donner des privilèges de lecture seule sur l'arbre des OID et enfin, associer cet utilisateur pour tout ce qui concerne les requêtes internes.
Lorsque l'on relance l'agent SNMP, le message d'erreur à disparu.
Attention, une fois que le mot de passe est fixé et l'agent SNMPD redémarré, il n'est plus possible de changer le mot de passe de l'utilisateur (enfin vous ne savez pas encore comment faire). Nous verrons dans le prochain article comment faire pour modifier ce mot de passe, car cela concerne la gestion des utilisateurs.
Toutefois, à ce niveau, si vous voulez modifier le mot de passe de cet utilisateur, il faut passer par le paragraphe « Suppression des données persistantes » de l'article précédent.
IV. Le « quoi » et le « comment » , on peut y aller ?▲
Voilà, les bases sont posées, les notifications sont envoyées à notre démon « snmptrapd », l'utilisateur interne SNMP est créé et vous savez utiliser la commande « monitor », on peut donc y aller.
Les éléments que l'on peut superviser sont :
- l'état de certains processus ;
- le taux de remplissage des disques ;
- la charge CPU système ;
- le taux d'utilisation de la mémoire « swap » ;
- la taille de certains fichiers ;
- le contenu de certains fichiers ;
- l'état des interfaces réseau ;
- les erreurs d'authentification SNMP.
Et c'est ce que nous allons voir, dans cet ordre, dans les paragraphes suivants.
IV-A. L'état de certains processus▲
IV-A-1. Le « quoi »▲
Dans ce paragraphe, nous allons voir comment superviser l'état de quelques processus. Tout d'abord, le nom du processus à surveiller est celui donné par la commande « ps -e ».
Pour nos essais, il n'est pas possible d'utiliser le processus « sshd » (ce que je voulais faire au début), car sshd est le nom du serveur ssh de la machine, mais aussi le nom des processus lorsque l'on établit une connexion en ssh. Le nom ne permet pas de discriminer entre le processus serveur et les processus fils lancés par le serveur lors d'une connexion, tant pis, il faut un plan « B ».
Pour nos tests, nous allons donc superviser un processus que nous allons créer de toute pièce afin de pouvoir le lancer et l'arrêter sans que cela ne perturbe le système. Nous allons donc utiliser la commande « sleep 1000 » qui crée un processus qui ne fait rien, il dort pendant 1000 secondes (presque 20 minutes, on devrait avoir le temps de s'amuser), mais qui présente l'énorme avantage de s'appeler « sleep » dans le résultat de la commande « ps -e ».
2.
3.
4.
5.
6.
7.
root@debian:~# ps -e
...
841 ? 00:00:00 sshd
843 pts/1 00:00:00 bash
883 pts/0 00:00:00 sleep
884 pts/1 00:00:00 ps
...
Bon, pour le processus, c'est réglé, maintenant, il faut modifier la configuration de snmpd afin que ce processus soit supervisé. Cela se fait en modifiant le fichier « /etc/snmp/snmpd.conf » et en ajoutant cette partie :
2.
3.
4.
5.
...
# processus a superviser
# proc <procname> [MAX] [MIN]
proc sleep 2 1
...
Le chiffre « 2 » signifie qu'il doit y avoir au maximum deux instances de « sleep » qui doivent tourner et le chiffre « 1 » signifie qu'il doit y avoir au minimum une seule instance. Autrement dit, cela signifie qu'une ou deux instances de « sleep » correspondent à un fonctionnement nominal, toute autre valeur doit être considérée comme une erreur. Les chiffres « 1 » et « 2 » dans le fichier de configuration sont facultatifs. Si aucun des deux n'est spécifié (ou si leurs valeurs valent zéro), les valeurs par défaut sont « infini » pour max et 1 pour min.
Une fois cette modification faite, il ne faut pas oublier de redémarrer l'agent snmpd avec la commande « /etc/init.d/snmpd restart » afin que ces modifications soient prises en compte.
Bien, nous venons de modifier la configuration, regardons maintenant comment se comporte l'agent SNMP. Pour cela, nous allons regarder la table prTable dont l'OID est « .1.3.6.1.4.1.2021.2 » ou encore « .iso.org.dod.Internet.private.enterprises.ucdavis.prTable ». C'est dans cette table que sont enregistrés les processus supervisés par l'agent SNMPD. Regardons donc un peu cette table avec la commande « snmptable » :
2.
3.
4.
5.
root@debian:~# snmptable -v 1 -c public localhost prTable
SNMP table: UCD-SNMP-MIB::prTable
prIndex prNames prMin prMax prCount prErrorFlag prErrMessage prErrFix prErrFixCmd
1 sleep 1 2 1 noError noError
Ce résultat montre que le processus « sleep » est supervisé, que le nombre d'instances minimum est 1, que le nombre maximum d'instances est 2 et que pour l'instant, il n'y a pas d'erreurs. Arrêtons donc notre processus et regardons de nouveau le résultat :
Ha ! Le résultat n'est plus le même et il y a une condition d'erreur. Refaisons la même mesure, mais avec cette fois-ci trois instances de notre processus sleep :
2.
3.
4.
5.
root@debian:~# snmptable -v 1 -c public localhost prTable
SNMP table: UCD-SNMP-MIB::prTable
prIndex prNames prMin prMax prCount prErrorFlag prErrMessage prErrFix prErrFixCmd
1 sleep 1 2 3 error Too many sleep running (# = 3) noError
Encore une fois, la condition d'erreur est détectée.
IV-A-2. Le « comment »▲
Pour indiquer comment superviser les processus, nous allons rajouter ceci dans le fichier de configuration de l'agent SNMP :
monitor -r 5 -o prNames -o prErrMessage "table des processus" != prErrorFlag
Cette ligne « monitor » a pour effet de surveiller la table des processus toutes les deux secondes (c'est rapide, mais c'est pour un test) et d'envoyer une notification lorsque le nombre de processus est en dehors des bornes indiquées par les différentes clauses « proc ».
IV-A-3. Validation▲
La procédure de test est la suivante :
- Tous les processus « sleep » sont arrêtés.
- Le démon « snmpd » est relancé et on attend cinq à dix secondes.
- On démarre un processus sleep par la commande « sleep 1000 & » et on attend cinq à dix secondes.
- Une première notification « no error » est alors envoyée, qui indique qu'il n'y a pas d'erreur :
2.
3.
2012-12-12 16:21:42 192.168.1.204(via UDP: [127.0.0.1]:41597->[127.0.0.1]:162) TRAP, SNMP v1, community public-trap
DISMAN-EVENT-MIB::dismanEventMIBNotificationPrefix Enterprise Specific Trap (DISMAN-EVENT-MIB::mteTriggerFired) Uptime: 0:01:32.13
DISMAN-EVENT-MIB::mteHotTrigger.0 = STRING: table des processus DISMAN-EVENT-MIB::mteHotTargetName.0 = STRING: DISMAN-EVENT-MIB::mteHotContextName.0 = STRING: DISMAN-EVENT-MIB::mteHotOID.0 = OID: UCD-SNMP-MIB::prErrorFlag.1DISMAN-EVENT-MIB::mteHotValue.0 = INTEGER: 0 UCD-SNMP-MIB::prNames.1 = STRING: sleep UCD-SNMP-MIB::prErrMessage.1 = STRING:
- On démarre deux autres processus sleep par la commande « sleep 1000 & » et on attend cinq à dix secondes.
- Une nouvelle notification « too many process » est alors envoyée :
2.
3.
2012-12-12 16:23:43 192.168.1.204(via UDP: [127.0.0.1]:41597->[127.0.0.1]:162) TRAP, SNMP v1, community public-trap
DISMAN-EVENT-MIB::dismanEventMIBNotificationPrefix Enterprise Specific Trap (DISMAN-EVENT-MIB::mteTriggerFired) Uptime: 0:03:32.20
DISMAN-EVENT-MIB::mteHotTrigger.0 = STRING: table des processus DISMAN-EVENT-MIB::mteHotTargetName.0 = STRING: DISMAN-EVENT-MIB::mteHotContextName.0 = STRING: DISMAN-EVENT-MIB::mteHotOID.0 = OID: UCD-SNMP-MIB::prErrorFlag.1DISMAN-EVENT-MIB::mteHotValue.0 = INTEGER: 1 UCD-SNMP-MIB::prNames.1 = STRING: sleep UCD-SNMP-MIB::prErrMessage.1 = STRING: Too many sleep running (# = 3)
- On tue un des processus sleep et on attend cinq à dix secondes.
- Une nouvelle notification « no error » est alors envoyée :
2.
3.
012-12-12 16:25:43 192.168.1.204(via UDP: [127.0.0.1]:41597->[127.0.0.1]:162) TRAP, SNMP v1, community public-trap
DISMAN-EVENT-MIB::dismanEventMIBNotificationPrefix Enterprise Specific Trap (DISMAN-EVENT-MIB::mteTriggerFired) Uptime: 0:05:32.26
DISMAN-EVENT-MIB::mteHotTrigger.0 = STRING: table des processus DISMAN-EVENT-MIB::mteHotTargetName.0 = STRING: DISMAN-EVENT-MIB::mteHotContextName.0 = STRING: DISMAN-EVENT-MIB::mteHotOID.0 = OID: UCD-SNMP-MIB::prErrorFlag.1DISMAN-EVENT-MIB::mteHotValue.0 = INTEGER: 0 UCD-SNMP-MIB::prNames.1 = STRING: sleep UCD-SNMP-MIB::prErrMessage.1 = STRING:
- On tue tous les processus sleep encore actifs et on attend cinq à dix secondes.
- Une nouvelle notification « not enougth process » est alors envoyée :
2.
3.
2012-12-12 16:27:13 192.168.1.204(via UDP: [127.0.0.1]:41597->[127.0.0.1]:162) TRAP, SNMP v1, community public-trap
DISMAN-EVENT-MIB::dismanEventMIBNotificationPrefix Enterprise Specific Trap (DISMAN-EVENT-MIB::mteTriggerFired) Uptime: 0:07:02.31
DISMAN-EVENT-MIB::mteHotTrigger.0 = STRING: table des processus DISMAN-EVENT-MIB::mteHotTargetName.0 = STRING: DISMAN-EVENT-MIB::mteHotContextName.0 = STRING: DISMAN-EVENT-MIB::mteHotOID.0 = OID: UCD-SNMP-MIB::prErrorFlag.1DISMAN-EVENT-MIB::mteHotValue.0 = INTEGER: 1 UCD-SNMP-MIB::prNames.1 = STRING: sleep UCD-SNMP-MIB::prErrMessage.1 = STRING: No sleep process running
IV-B. Le taux de remplissage des disques▲
IV-B-1. Le « quoi »▲
Nous allons maintenant superviser le taux remplissage nos disques. Enfin dans un environnement Unix/Linux, nous parlerons plutôt de « file system ». Pour cela, nous allons encore une fois modifier le fichier « /etc/snmp/snmpd.conf ». Pour cela, il y a deux directives disponibles, « includeAllDisks » et « disk ».
La clause « includeAllDisks » permet de superviser tous les filesystem de la machine en indiquant à partir de quel pourcentage de remplissage il faut réagir.
La clause « disk » permet de superviser un filesystem particulier (en indiquant son path, ou chemin) et en indiquant soit le minimum d'espace (en kilo-octets), soit le pourcentage de remplissage à partir duquel il faut réagir.
Cela se fait en modifiant le fichier « /etc/snmp/snmpd.conf » et en ajoutant cette partie :
2.
3.
4.
5.
6.
7.
...
# filesystem a superviser
# includeAllDisks <min>%
# disk <path> [<min kb> | <min>%]
includeAllDisks 80%
disk / 50%
...
Une fois cette modification faite, il ne faut pas oublier de redémarrer l'agent snmpd avec la commande « /etc/init.d/snmpd restart » afin que ces modifications soient prises en compte.
Nous venons de modifier la configuration et de redémarrer l'agent SNMP, voyons maintenant les résultats. Pour cela, nous allons regarder la table dskTable dont l'OID est « .1.3.6.1.4.1.2021.9 » ou encore « .iso.org.dod.Internet.private.enterprises.ucdavis.dskTable ». C'est dans cette table que sont enregistrés les filesystem supervisés par l'agent SNMPD. Regardons donc un peu cette table avec la commande « snmptable » :
2.
3.
4.
5.
6.
7.
8.
9.
root@debian:~# snmptable -v 1 -c public localhost dskTable
SNMP table: UCD-SNMP-MIB::dskTable
dskIndex dskPath dskDevice dskMinimum dskMinPercent dskTotal dskAvail dskUsed dskPercent dskPercentNode dskTotalLow dskTotalHigh dskAvailLow dskAvailHigh dskUsedLow dskUsedHigh dskErrorFlag dskErrorMsg
1 / /dev/sda1 -1 50 7867856 6417132 1051060 13 9 7867856 0 6417132 0 1051060 0 noError
2 /lib/init/rw tmpfs -1 80 192316 192316 0 0 0 192316 0 192316 0 0 0 noError
3 /dev udev -1 80 187880 187736 144 0 1 187880 0 187736 0 144 0 noError
4 /dev/shm tmpfs -1 80 192316 192316 0 0 0 192316 0 192316 0 0 0 noError
5 / /dev/sda1 -1 50 7867856 6417132 1051060 13 9 7867856 0 6417132 0 1051060 0 noError
Ce résultat montre les systèmes de fichiers supervisés (sur ma machine) ainsi que l'espace disque occupé et disponible (en kilo-octets et en pourcentage). Pour l'instant, il n'y a pas d'erreur, nous allons donc remplir l'espace en utilisant la commande « dd if=/dev/zero of=filename bs=1024k count=<size ko> », qui permet de créer un fichier de la taille indiquée. Une fois que le système de fichiers est un peu rempli, voyons le résultat avec la commande « snmptable » :
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
root@debian:~# snmptable -v 1 -c public localhost dskTable
SNMP table: UCD-SNMP-MIB::dskTable
dskIndex dskPath dskDevice dskMinimum dskMinPercent dskTotal dskAvail dskUsed dskPercent dskPercentNode dskErrorFlag dskErrorMsg
1 / /dev/sda1 -1 50 7867856 2345796 5122396 69 8 error /: less than 50% free (= 69%)
2 /lib/init/rw tmpfs -1 80 192316 192316 0 0 0 noError
3 /proc proc -1 80 0 0 0 0 100 noError
4 /sys sysfs -1 80 0 0 0 0 100 noError
5 /dev udev -1 80 187880 187736 144 0 1 noError
6 /dev/shm tmpfs -1 80 192316 192316 0 0 0 noError
7 /dev/pts devpts -1 80 0 0 0 0 100 noError
Si j'efface le fichier généré à l'instant et que je relance la commande snmptable, j'obtiens à nouveau le résultat précédent :
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
root@debian:~# snmptable -v 1 -c public localhost dskTable
SNMP table: UCD-SNMP-MIB::dskTable
dskIndex dskPath dskDevice dskMinimum dskMinPercent dskTotal dskAvail dskUsed dskPercent dskPercentNode dskErrorFlag dskErrorMsg
1 / /dev/sda1 -1 50 7867856 6544192 924000 12 8 noError
2 /lib/init/rw tmpfs -1 80 192316 192316 0 0 0 noError
3 /proc proc -1 80 0 0 0 0 100 noError
4 /sys sysfs -1 80 0 0 0 0 100 noError
5 /dev udev -1 80 187880 187736 144 0 1 noError
6 /dev/shm tmpfs -1 80 192316 192316 0 0 0 noError
7 /dev/pts devpts -1 80 0 0 0 0 100 noError
Voilà, c'est terminé, nous savons maintenant superviser le taux de remplissage des systèmes de fichiers.
IV-B-2. Le « comment »▲
Pour indiquer comment superviser le remplissage des systèmes de fichiers, nous allons rajouter ceci dans le fichier de configuration de l'agent SNMP :
monitor -r 5 -o dskPath -o dskErrorMsg "table des file system" != dskErrorFlag
Cette ligne « monitor » a pour effet de surveiller la table des systèmes de fichiers toutes les deux secondes et d'envoyer une notification lorsque le taux de remplissage d'un système de fichiers est en dehors des bornes indiquées par les différentes clauses « disk » ou « includeAllDisks ».
IV-B-3. Validation▲
La procédure de test est la suivante :
- Tous les fichiers de grande taille sont supprimés, notre système de fichier est rempli normalement.
- Le démon « snmpd » est relancé et on attend cinq à dix secondes.
- On crée un fichier de grande taille « dd if=/dev/zero of=filename bs=1024k count=<size ko> » (pour moi, 5 GO) et on attend cinq à dix secondes.
- Une notification « disk is full » est alors envoyée :
2.
3.
2012-12-13 17:44:08 192.168.1.204(via UDP: [127.0.0.1]:33934->[127.0.0.1]:162) TRAP, SNMP v1, community public-trap
DISMAN-EVENT-MIB::dismanEventMIBNotificationPrefix Enterprise Specific Trap (DISMAN-EVENT-MIB::mteTriggerFired) Uptime: 0:04:50.25
DISMAN-EVENT-MIB::mteHotTrigger.0 = STRING: table des file system DISMAN-EVENT-MIB::mteHotTargetName.0 = STRING: DISMAN-EVENT-MIB::mteHotContextName.0 = STRING: DISMAN-EVENT-MIB::mteHotOID.0 = OID: UCD-SNMP-MIB::dskErrorFlag.5 DISMAN-EVENT-MIB::mteHotValue.0 = INTEGER: 1 UCD-SNMP-M IB::dskPath.5 = STRING: / UCD-SNMP-MIB::dskErrorMsg.5 = STRING: /: less than 50% free (= 49%)
- On supprime le fichier de grande taille et on attend cinq à dix secondes.
- Une nouvelle notification « disk is empty » est alors envoyée :
2.
3.
2012-12-13 17:57:05 192.168.1.204(via UDP: [127.0.0.1]:33934->[127.0.0.1]:162) TRAP, SNMP v1, community public-trap
DISMAN-EVENT-MIB::dismanEventMIBNotificationPrefix Enterprise Specific Trap (DISMAN-EVENT-MIB::mteTriggerFired) Uptime: 0:17:46.72
DISMAN-EVENT-MIB::mteHotTrigger.0 = STRING: table des file system DISMAN-EVENT-MIB::mteHotTargetName.0 = STRING: DISMAN-EVENT-MIB::mteHotContextName.0 = STRING: DISMAN-EVENT-MIB::mteHotOID.0 = OID: UCD-SNMP-MIB::dskErrorFlag.5 DISMAN-EVENT-MIB::mteHotValue.0 = INTEGER: 0 UCD-SNMP-MIB::dskPath.5 = STRING: / UCD-SNMP-MIB::dskErrorMsg.5 = STRING:
IV-C. La surveillance de la charge système▲
IV-C-1. Le « quoi »▲
Nous allons maintenant nous intéresser à la supervision de la charge système. Cela se configure avec la clause « load ». Cette clause permet de spécifier la moyenne maximum de la charge sur la dernière minute, sur les cinq dernières minutes et enfin sur les quinze dernières minutes. La syntaxe de cette clause est « load MAX1 [MAX5 [MAX15]] ».
Cela se fait en modifiant le fichier « /etc/snmp/snmpd.conf » et en ajoutant cette partie :
2.
3.
4.
5.
...
# System Load Monitoring
# load MAX1 [MAX5 [MAX15]]
load 0.3 0.2 0.1
...
Une fois cette modification faite, il ne faut pas oublier de redémarrer l'agent snmpd avec la commande « /etc/init.d/snmpd restart » afin que ces modifications soient prises en compte.
Nous venons de modifier la configuration et de redémarrer l'agent SNMP. Voyons maintenant les résultats. Pour cela, nous allons regarder la table laTable dont l'OID est « .1.3.6.1.4.1.2021.10 » ou encore « .iso.org.dod.Internet.private.enterprises.ucdavis.laTable ». C'est dans cette table que sont enregistrées les moyennes de la charge CPU sur la dernière minute, les cinq dernières minutes et enfin sur les quinze dernières minutes. Voyons un peu cette table sur notre système :
2.
3.
4.
5.
6.
7.
root@debian:~# snmptable -v 1 -c public localhost latable
SNMP table: UCD-SNMP-MIB::laTable
laIndex laNames laLoad laConfig laLoadInt laLoadFloat laErrorFlag laErrMessage
1 Load-1 0.16 0.30 16 0.160000 noError
2 Load-5 0.19 0.20 19 0.190000 noError
3 Load-15 0.08 0.10 8 0.080000 noError
Maintenant, nous allons tester cette configuration en faisant monter la charge CPU de notre machine. Pour cela nous allons utiliser la commande « while : ; do true; done » qui va tenter de consommer 100% de la CPU. Si on laisse tourner notre consommateur de CPU, voici le résultat obtenu :
2.
3.
4.
5.
6.
7.
root@debian:~# snmptable -v 1 -c public localhost latable
SNMP table: UCD-SNMP-MIB::laTable
laIndex laNames laLoad laConfig laLoadInt laLoadFloat laErrorFlag laErrMessage
1 Load-1 0.40 0.30 40 0.400000 error 1 min Load Average too high (= 0.40)
2 Load-5 0.24 0.20 23 0.240000 error 5 min Load Average too high (= 0.24)
3 Load-15 0.10 0.10 10 0.100000 error 15 min Load Average too high (= 0.10)
IV-C-2. Le « comment »▲
Pour indiquer comment superviser la charge système, nous allons rajouter ceci dans le fichier de configuration de l'agent SNMP :
monitor -r 5 -o laNames -o laErrMessage "laTable" != laErrorFlag
Cette ligne « monitor » a pour effet de surveiller la charge CPU du système toutes les deux secondes et d'envoyer une notification lorsque cette charge CPU est en dehors des bornes indiquées par les différentes clauses « load ».
IV-C-3. 3.3.3 Validation▲
La procédure de test est la suivante :
- La charge CPU du système est normale.
- Le démon « snmpd » est relancé et on attend cinq à dix secondes.
- On créé de la charge CPU avec la commande « while : ; do true; done » et on attend la notification.
- Une notification « CPU overload » est alors envoyée :
2.
3.
2012-12-13 18:21:10 192.168.1.204(via UDP: [127.0.0.1]:46956->[127.0.0.1]:162) TRAP, SNMP v1, community public-trap
DISMAN-EVENT-MIB::dismanEventMIBNotificationPrefix Enterprise Specific Trap (DISMAN-EVENT-MIB::mteTriggerFired) Uptime: 0:01:08.10
DISMAN-EVENT-MIB::mteHotTrigger.0 = STRING: charge CPU systeme DISMAN-EVENT-MIB::mteHotTargetName.0 = STRING: DISMAN-EVENT-MIB::mteHotContextName.0 = STRING: DISMAN-EVENT-MIB::mteHotOID.0 = OID: UCD-SNMP-MIB::laErrorFlag.1 DISMAN-EVENT-MIB::mteHotValue.0 = INTEGER: 1 UCD-SNMP-MIB::laNames.1 = STRING: Load-1 UCD-SNMP-MIB::laErrMessage.1 = STRING: 1 min Load Average too high (= 0.53)
- On arrête la tâche qui génère de la charge CPU et on attend que les valeurs de charge se stabilisent.
- Une nouvelle notification « CPU normal » est alors envoyée :
2.
3.
2012-12-13 18:22:50 192.168.1.204(via UDP: [127.0.0.1]:46956->[127.0.0.1]:162) TRAP, SNMP v1, community public-trap
DISMAN-EVENT-MIB::dismanEventMIBNotificationPrefix Enterprise Specific Trap (DISMAN-EVENT-MIB::mteTriggerFired) Uptime: 0:02:48.14
DISMAN-EVENT-MIB::mteHotTrigger.0 = STRING: charge CPU systeme DISMAN-EVENT-MIB::mteHotTargetName.0 = STRING: DISMAN-EVENT-MIB::mteHotContextName.0 = STRING: DISMAN-EVENT-MIB::mteHotOID.0 = OID: UCD-SNMP-MIB::laErrorFlag.3 DISMAN-EVENT-MIB::mteHotValue.0 = INTEGER: 0 UCD-SNMP-MIB::laNames.3 = STRING: Load-15 UCD-SNMP-MIB::laErrMessage.3 = STRING:
IV-D. La surveillance de l'utilisation de la mémoire « swap »▲
IV-D-1. Le « quoi »▲
Pour surveiller l'utilisation de la mémoire « swap », c'est une « Lapalissade », il faut d'abord que la mémoire « swap » soit utilisée sur votre système. Cela se vérifie avec la commande « swapon -s » :
2.
3.
root@debian:~# swapon -s
Filename Type Size Used Priority
/dev/sda5 partition 392184 11740 -1
Si elle n'est pas utilisée, il faut l'activer avec la commande « swapon -a » et éventuellement créer une partition de swap avec la commande « mkswap ».
La clause dans le fichier « /etc/snmp/snmpd.conf » qui permet de surveiller la quantité de mémoire « swap » disponible est la clause « swap MIN » que nous allons aussi rajouter dans le fichier de configuration SNMP comme cela :
2.
3.
4.
...
# swap <MIN kb>
swap 300000
...
Nous venons de modifier la configuration et de redémarrer l'agent SNMP. Voyons maintenant les résultats. Pour cela, nous allons regarder la structure memory dont l'OID est « .1.3.6.1.4.1.2021.4 » ou encore « .iso.org.dod.Internet.private.enterprises.ucdavis.memory ». Comme il ne s'agit pas d'une table, mais d'une structure, nous n'allons pas pouvoir utiliser la commande « snmptable », nous utiliserons la commande « snmpwalk » comme ceci :
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
root@debian:~# snmpwalk -v 1 -c public localhost UCD-SNMP-MIB::memory
UCD-SNMP-MIB::memIndex.0 = INTEGER: 0
UCD-SNMP-MIB::memErrorName.0 = STRING: swap
UCD-SNMP-MIB::memTotalSwap.0 = INTEGER: 392184 kB
UCD-SNMP-MIB::memAvailSwap.0 = INTEGER: 380732 kB
UCD-SNMP-MIB::memTotalReal.0 = INTEGER: 384636 kB
UCD-SNMP-MIB::memAvailReal.0 = INTEGER: 355864 kB
UCD-SNMP-MIB::memTotalFree.0 = INTEGER: 736596 kB
UCD-SNMP-MIB::memMinimumSwap.0 = INTEGER: 16000 kB
UCD-SNMP-MIB::memBuffer.0 = INTEGER: 624 kB
UCD-SNMP-MIB::memCached.0 = INTEGER: 11320 kB
UCD-SNMP-MIB::memSwapError.0 = INTEGER: noError(0)
UCD-SNMP-MIB::memSwapErrorMsg.0 = STRING:
Cette commande nous montre la quantité de mémoire conventionnelle, la quantité de mémoire utilisée ainsi que l'usage de la mémoire « swap ».
Afin de tester notre configuration, nous allons créer un programme qui va consommer énormément de mémoire afin de faire monter la mémoire swap utilisée. Pour cela, je vous propose de créer le fichier « main.c » suivant :
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
#include <stdlib.h>
#include <stdio.h>
int main(int argc, char * argv[])
{
int nb = 65536;
if(argc != 1)
nb = atoi(argv[1]);
int boucle;
printf("allocating...\n");
for(boucle = 0; boucle != nb; boucle++)
{
malloc(1024);
}
printf("sleeping...\n");
for(;;) sleep(1);
}
Comme vous pouvez le voir, ce programme est très efficace en termes de consommation mémoire, il ne fait qu'allouer sans jamais libérer. Sa compilation se fait avec la commande suivante « gcc main.c -o main » et enfin de le lancer avec la commande « ./main ».
Si on exécute ce programme dans une fenêtre (ne vous inquiétez pas s'il se crashe, c'est qu'il n'y a plus assez de mémoire) et que l'on surveille la consommation mémoire dans une autre fenêtre avec la commande « vmstat 1 », on peut voir l'augmentation de la mémoire utilisée :
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
root@debian:~# vmstat 1
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
0 0 7412 363756 276 10148 4 480 44 590 38 22 3 3 94 0
0 0 7412 363748 276 10172 0 0 0 0 22 20 0 0 100 0
1 0 7404 312652 276 10172 32 0 32 0 70 23 5 15 80 0
1 0 7404 18524 276 10172 0 0 0 0 274 12 33 67 0 0
2 0 33408 4296 68 1476 192 26336 1364 26364 513 421 3 45 0 52
2 0 118560 4208 64 1680 136 84932 940 84932 1738 1367 4 71 0 25
0 0 186992 5192 84 2148 64 68440 1456 68440 1209 704 6 52 31 11
0 0 186992 5200 84 2176 0 0 28 0 16 15 0 0 100 0
0 0 186992 5200 84 2176 0 0 0 0 14 12 0 0 100 0
0 0 188140 5188 108 3164 32 1148 1260 1148 74 92 0 2 87 11
0 0 188140 5188 108 3164 0 0 0 0 14 9 0 0 100 0
0 0 189152 5272 108 4048 164 1032 1468 1032 91 102 0 1 88 11
0 0 189152 5272 112 4336 0 0 280 0 32 24 0 1 99 0
0 0 189152 5272 112 4344 0 0 0 0 15 15 0 0 100 0
0 0 189152 5272 120 4336 0 0 0 24 17 19 0 0 100 0
0 0 189152 5272 120 4344 0 0 0 0 14 9 0 0 100 0
0 0 189152 5272 120 4344 0 0 0 0 18 17 0 0 100 0
0 0 189152 5272 120 4344 0 0 0 0 15 11 0 0 100 0
0 0 7852 369436 124 5428 120 0 1212 0 57 54 0 3 97 0
0 0 7852 369440 124 5432 0 0 0 0 13 11 0 0 100 0
0 0 7852 369440 124 5432 0 0 0 0 13 8 0 0 100 0
Et si on relance notre commande « snmpwalk » pendant que le programme consommateur de mémoire est actif, nous obtenons le résultat suivant :
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
root@debian:~# snmpwalk -v 1 -c public localhost UCD-SNMP-MIB::memory
UCD-SNMP-MIB::memIndex.0 = INTEGER: 0
UCD-SNMP-MIB::memErrorName.0 = STRING: swap
UCD-SNMP-MIB::memTotalSwap.0 = INTEGER: 392184 kB
UCD-SNMP-MIB::memAvailSwap.0 = INTEGER: 235304 kB
UCD-SNMP-MIB::memTotalReal.0 = INTEGER: 384636 kB
UCD-SNMP-MIB::memAvailReal.0 = INTEGER: 4060 kB
UCD-SNMP-MIB::memTotalFree.0 = INTEGER: 239364 kB
UCD-SNMP-MIB::memMinimumSwap.0 = INTEGER: 300000 kB
UCD-SNMP-MIB::memBuffer.0 = INTEGER: 164 kB
UCD-SNMP-MIB::memCached.0 = INTEGER: 4400 kB
UCD-SNMP-MIB::memSwapError.0 = INTEGER: error(1)
UCD-SNMP-MIB::memSwapErrorMsg.0 = STRING: Running out of swap space (235304)
Ce test et surtout le paramètre à passer au programme de consommation mémoire sont à adapter en fonction de la quantité de mémoire réelle dont vous disposez et aussi de la taille de la mémoire « swap » spécifiée pour le système. Les quantités de mémoire affichées ici sont petites, voire même dérisoires, mais rappelez-vous, je travaille sur une machine virtuelle donc forcément limitées.
IV-D-2. Le « comment »▲
Pour indiquer comment superviser la mémoire swap, nous allons rajouter ceci dans le fichier de configuration de l'agent SNMP :
monitor -r 5 -o memErrorName -o memSwapErrorMsg "memory" != memSwapError
Cette ligne « monitor » a pour effet de surveiller l'utilisation de la mémoire swap toutes les deux secondes et d'envoyer une notification lorsque cette mémoire est occupée plus que ce qui est spécifié par la clause« swap ».
IV-D-3. Validation▲
La procédure de test est la suivante :
- Le taux d'occupation de la mémoire swap est normal.
- Le démon « snmpd » est relancé et on attend cinq à dix secondes.
- On utilise la mémoire avec la commande « ./main 500000 » et on attend cinq à dix secondes.
- Une notification « out of SWAP memory » est alors envoyée :
2.
3.
2012-12-13 18:35:24 192.168.1.204(via UDP: [127.0.0.1]:58289->[127.0.0.1]:162) TRAP, SNMP v1, community public-trap
DISMAN-EVENT-MIB::dismanEventMIBNotificationPrefix Enterprise Specific Trap (DISMAN-EVENT-MIB::mteTriggerFired) Uptime: 0:00:50.14
DISMAN-EVENT-MIB::mteHotTrigger.0 = STRING: utilisation de la SWAP DISMAN-EVENT-MIB::mteHotTargetName.0 = STRING: DISMAN-EVENT-MIB::mteHotContextName.0 = STRING: DISMAN-EVENT-MIB::mteHotOID.0 = OID: UCD-SNMP-MIB::memSwapError.0 DISMAN-EVENT-MIB::mteHotValue.0 = INTEGER: 1 UCD-SNMP-MIB::memErrorName.0 = STRING: swap UCD-SNMP-MIB::memSwapErrorMsg.0 = STRING: Running out of swap space (222928)
- On arrête la tâche qui consomme la mémoire et on attend cinq à dix secondes.
- Une nouvelle notification « SWAP memory normal » est alors envoyée :
2.
3.
2012-12-13 18:38:34 192.168.1.204(via UDP: [127.0.0.1]:58289->[127.0.0.1]:162) TRAP, SNMP v1, community public-trap
DISMAN-EVENT-MIB::dismanEventMIBNotificationPrefix Enterprise Specific Trap (DISMAN-EVENT-MIB::mteTriggerFired) Uptime: 0:04:00.14
DISMAN-EVENT-MIB::mteHotTrigger.0 = STRING: utilisation de la SWAP DISMAN-EVENT-MIB::mteHotTargetName.0 = STRING: DISMAN-EVENT-MIB::mteHotContextName.0 = STRING: DISMAN-EVENT-MIB::mteHotOID.0 = OID: UCD-SNMP-MIB::memSwapError.0 DISMAN-EVENT-MIB::mteHotValue.0 = INTEGER: 0 UCD-SNMP-MIB::memErrorName.0 = STRING: swap UCD-SNMP-MIB::memSwapErrorMsg.0 = STRING:
IV-E. La surveillance de la taille de certains fichiers▲
IV-E-1. Le « quoi »▲
Nous allons maintenant surveiller la taille de certains fichiers. La clause à utiliser dans le fichier « /etc/snmp/snmpd.conf » est « file <filename> [SIZEMAX] », comme ceci :
2.
3.
4.
...
# file < filename > [SIZEMAX kb]
file /tmp/test.txt 1
...
Après redémarrage de l'agent SNMPD, si nous lisons la table « fileTable » dont l'OID est « .1.3.6.1.4.1.2021.15 » ou encore « .iso.org.dod.Internet.private.enterprises.ucdavis.fileTable », nous obtenons le résultat suivant :
2.
3.
4.
5.
root@debian:~# snmptable -v 1 -c public localhost fileTable
SNMP table: UCD-SNMP-MIB::fileTable
fileIndex fileName fileSize fileMax fileErrorFlag fileErrorMsg
1 /tmp/test.txt 0 kB 1 kB noError
Si maintenant, nous faisons grossir le fichier au-delà de la limite autorisée avec la commande « dd if=/dev/zero of=/tmp/test.txt bs=1024 count=2 », nous obtenons le résultat suivant :
2.
3.
4.
5.
root@debian:~# snmptable -v 1 -c public localhost fileTable
SNMP table: UCD-SNMP-MIB::fileTable
fileIndex fileName fileSize fileMax fileErrorFlag fileErrorMsg
1 /tmp/test.txt 2 kB 1 kB error /tmp/test.txt: size exceeds 1kb (= 2kb)
Attention, il y a une limitation à 20 sur le nombre de fichiers que l'on peut surveiller.
IV-E-2. Le « comment »▲
Pour indiquer comment superviser la taille des fichiers, nous allons rajouter ceci dans le fichier de configuration de l'agent SNMP :
monitor -r 5 -o fileName -o fileErrorMsg "table des tailles de fichiers" != fileErrorFlag
Cette ligne « monitor » a pour effet de surveiller la taille des fichiers indiqués par les clauses « file » toutes les deux secondes et d'envoyer une notification lorsque la taille d'un fichier dépasse la borne spécifiée.
IV-E-3. Validation▲
La procédure de test est la suivante :
- Le taux « /tmp/test.txt » est supprimé.
- Le démon « snmpd » est relancé et on attend cinq à dix secondes.
- On créé le fichier /tmp/test.txt avec la commande « dd if=/dev/zero of=/tmp/test.txt bs=1024 count=2 » et on attend cinq à dix secondes.
- Une notification « file size exceeded » est alors envoyée :
2.
3.
2012-12-14 09:45:47 192.168.1.204(via UDP: [127.0.0.1]:33180->[127.0.0.1]:162) TRAP, SNMP v1, community public-trap
DISMAN-EVENT-MIB::dismanEventMIBNotificationPrefix Enterprise Specific Trap (DISMAN-EVENT-MIB::mteTriggerFired) Uptime: 0:00:25.14
DISMAN-EVENT-MIB::mteHotTrigger.0 = STRING: table des tailles de fichiers DISMAN-EVENT-MIB::mteHotTargetName.0 = STRING: DISMAN-EVENT-MIB::mteHotContextName.0 = STRING: DISMAN-EVENT-MIB::mteHotOID.0 = OID: UCD-SNMP-MIB::fileErrorFlag.1 DISMAN-EVENT-MIB::mteHotValue.0 = INTEGER: 1 UCD-SNMP-MIB::fileName.1 = STRING: /tmp/test.txt UCD-SNMP-MIB::fileErrorMsg.1 = STRING: /tmp/test.txt: size exceeds 1kb (= 2kb)
- On vide le fichier /tmp/test.txt avec la commande « echo > /tmp/test.txt » et on attend cinq à dix secondes.
- Une nouvelle notification « file size normal » est alors envoyée :
2.
3.
2012-12-14 09:48:12 192.168.1.204(via UDP: [127.0.0.1]:33180->[127.0.0.1]:162) TRAP, SNMP v1, community public-trap
DISMAN-EVENT-MIB::dismanEventMIBNotificationPrefix Enterprise Specific Trap (DISMAN-EVENT-MIB::mteTriggerFired) Uptime: 0:02:50.15
DISMAN-EVENT-MIB::mteHotTrigger.0 = STRING: table des tailles de fichiers DISMAN-EVENT-MIB::mteHotTargetName.0 = STRING: DISMAN-EVENT-MIB::mteHotContextName.0 = STRING: DISMAN-EVENT-MIB::mteHotOID.0 = OID: UCD-SNMP-MIB::fileErrorFlag.1 DISMAN-EVENT-MIB::mteHotValue.0 = INTEGER: 0 UCD-SNMP-MIB::fileName.1 = STRING: /tmp/test.txt UCD-SNMP-MIB::fileErrorMsg.1 = STRING:
IV-F. La surveillance du contenu de certains fichiers▲
IV-F-1. Le « quoi »▲
Pour surveiller le contenu d'un fichier, la clause à utiliser est « logmatch <name> <filename> <every sec> <regex> » dans lequel « name » est le nom de l'instance, « filename » est le chemin complet du fichier à surveiller, « every » représente le nombre de secondes entre deux contrôles et « regex » représente l'expression régulière à rechercher dans le fichier.
Nous allons modifier le fichier « /etc/snmp/snmpd.conf » comme ceci :
2.
3.
4.
...
# logmatch <name> <filename> <every sec> <regex>
logmatch test /tmp/match.txt 1 hello
...
Après redémarrage de l'agent SNMPD, si nous lisons la table « logMatchTable » dont l'OID est « .1.3.6.1.4.1.2021.16.2 » ou encore « .iso.org.dod.Internet.private.enterprises.ucdavis.logMatch.logMatchTable », nous obtenons le résultat suivant :
2.
3.
4.
5.
root@debian:~# snmptable -v 1 -c public localhost logMatchTable
SNMP table: UCD-SNMP-MIB::logMatchTable
logMatchIndex logMatchName logMatchFilename logMatchRegEx logMatchGlobalCounter logMatchGlobalCount logMatchCurrentCounter logMatchCurrentCount logMatchCounter logMatchCount logMatchCycle logMatchErrorFlag logMatchRegExCompilation
1 test /tmp/match.txt hello 0 0 0 0 0 0 1 noError Success
Si maintenant, nous écrivons la chaine de caractères « hello » dans le fichier avec la commande « echo hello >> /tmp/match.txt », nous obtenons le résultat suivant :
2.
3.
4.
5.
root@debian:~# snmptable -v 1 -c public localhost logMatchTable
SNMP table: UCD-SNMP-MIB::logMatchTable
logMatchIndex logMatchName logMatchFilename logMatchRegEx logMatchGlobalCounter logMatchGlobalCount logMatchCurrentCounter logMatchCurrentCount logMatchCounter logMatchCount logMatchCycle logMatchErrorFlag logMatchRegExCompilation
1 test /tmp/match.txt hello 1 1 1 1 1 0 1 noError Success
Si nous réécrivons dedans, le résultat va évoluer :
2.
3.
4.
5.
root@debian:~# snmptable -v 1 -c public localhost logMatchTable
SNMP table: UCD-SNMP-MIB::logMatchTable
logMatchIndex logMatchName logMatchFilename logMatchRegEx logMatchGlobalCounter logMatchGlobalCount logMatchCurrentCounter logMatchCurrentCount logMatchCounter logMatchCount logMatchCycle logMatchErrorFlag logMatchRegExCompilation
1 test /tmp/match.txt hello 2 2 2 2 1 0 1 noError Success
Attention, il y a une limitation à 250 sur le nombre de fichiers dont on peut surveiller le contenu.
IV-F-2. Le « comment »▲
Pour indiquer comment superviser le contenu des fichiers, nous allons rajouter ceci dans le fichier de configuration de l'agent SNMP :
monitor -r 5 -o logMatchFilename -o logMatchGlobalCounter "contenu des fichiers" != logMatchGlobalCounter
Cette ligne « monitor » a pour effet de surveiller le contenu des fichiers indiqués par les clauses « logmatch » toutes les cinq secondes et d'envoyer une notification lorsque le fichier contient ce qui est spécifié.
IV-F-3. Validation▲
La procédure de test est la suivante :
- Le taux « /tmp/match.txt » est supprimé.
- Le démon « snmpd » est relancé et on attend cinq à dix secondes.
- On remplit le fichier /tmp/match.txt avec la commande « echo hello > /tmp/match.txt » et on attend cinq à dix secondes.
- Une notification « file match » est alors envoyée avec un compteur d'occurrences à 1 :
2.
3.
2012-12-14 09:58:23 192.168.1.204(via UDP: [127.0.0.1]:59456->[127.0.0.1]:162) TRAP, SNMP v1, community public-trap
DISMAN-EVENT-MIB::dismanEventMIBNotificationPrefix Enterprise Specific Trap (DISMAN-EVENT-MIB::mteTriggerFired) Uptime: 0:00:55.08
DISMAN-EVENT-MIB::mteHotTrigger.0 = STRING: contenu des fichiers DISMAN-EVENT-MIB::mteHotTargetName.0 = STRING: DISMAN-EVENT-MIB::mteHotContextName.0 = STRING: DISMAN-EVENT-MIB::mteHotOID.0 = OID: UCD-SNMP-MIB::logMatchGlobalCounter.1 DISMAN-EVENT-MIB::mteHotValue.0 = Wrong Type (should be INTEGER): Counter32: 1 UCD-SNMP-MIB::logMatchFilename.1 = STRING: /tmp/match.txt UCD-SNMP-MIB::logMatchGlobalCounter.1 = Counter32: 1
- On réécrit dans le fichier /tmp/match.txt avec la commande « echo autre_chaine >> /tmp/match.txt » et on attend cinq à dix secondes.
- Il n'y a pas de nouvelle notification envoyée.
- On continue de remplir le fichier /tmp/match.txt avec la commande « echo hello >> /tmp/match.txt » et on attend cinq à dix secondes.
- Une notification « file match » est alors envoyée avec un compteur d'occurrences à 2 :
2.
3.
2012-12-14 10:02:53 192.168.1.204(via UDP: [127.0.0.1]:59456->[127.0.0.1]:162) TRAP, SNMP v1, community public-trap
DISMAN-EVENT-MIB::dismanEventMIBNotificationPrefix Enterprise Specific Trap (DISMAN-EVENT-MIB::mteTriggerFired) Uptime: 0:05:25.10
DISMAN-EVENT-MIB::mteHotTrigger.0 = STRING: contenu des fichiers DISMAN-EVENT-MIB::mteHotTargetName.0 = STRING: DISMAN-EVENT-MIB::mteHotContextName.0 = STRING: DISMAN-EVENT-MIB::mteHotOID.0 = OID: UCD-SNMP-MIB::logMatchGlobalCounter.1 DISMAN-EVENT-MIB::mteHotValue.0 = Wrong Type (should be INTEGER): Counter32: 2 UCD-SNMP-MIB::logMatchFilename.1 = STRING: /tmp/match.txt UCD-SNMP-MIB::logMatchGlobalCounter.1 = Counter32: 2
IV-G. La surveillance des interfaces réseau▲
IV-G-1. Le « quoi »▲
Pour surveiller les interfaces réseau, nous allons créer deux nouvelles notifications avec la clause « notificationEvent ». Cette clause permet de définir des notifications ainsi que leur contenu.
Nous allons modifier le fichier « /etc/snmp/snmpd.conf » comme ceci :
2.
3.
4.
...
notificationEvent linkUpTrap linkUp ifIndex ifDescr ifAdminStatus ifOperStatus
notificationEvent linkDownTrap linkDown ifIndex ifDescr ifAdminStatus ifOperStatus
...
Le contenu de la table des interfaces réseau est visible avec la commande suivante :
2.
3.
4.
5.
6.
7.
root@debian:~# snmptable -v 1 -c public localhost ifTable
SNMP table: IF-MIB::ifTable
ifIndex ifDescr ifType ifMtu ifSpeed ifPhysAddress ifAdminStatus ifOperStatus ifLastChange ifInOctets ifInUcastPkts ifInNUcastPkts ifInDiscards ifInErrors ifInUnknownProtos ifOutOctets ifOutUcastPkts ifOutNUcastPkts ifOutDiscards ifOutErrors ifOutQLen ifSpecific
1 lo softwareLoopback 16436 10000000 up up 0:0:00:00.00 16168 217 0 0 0 0 16168 217 0 0 0 0 SNMPv2-SMI::zeroDotZero
2 eth0 ethernetCsmacd 1500 1000000000 8:0:27:1:bc:e2 up up 0:0:00:00.00 134297 1341 0 0 0 0 147382 1067 0 0 0 0 SNMPv2-SMI::zeroDotZero
3 eth1 ethernetCsmacd 1500 0 8:0:27:d9:5a:79 up up 0:0:00:36.02 0 0 0 0 0 0 3276 42 0 0 0 0 SNMPv2-SMI::zeroDotZero
IV-G-2. Le « comment »▲
Pour indiquer comment superviser les interfaces réseau, nous allons rajouter ceci dans le fichier de configuration de l'agent SNMP :
2.
monitor -r 5 -e linkUpTrap "linkUp trap" ifOperStatus != 2
monitor -r 5 -e linkDownTrap "linkDown trap" ifOperStatus == 2
Ces lignes « monitor » ont pour effet de surveiller le statut opérationnel des interfaces réseau et d'envoyer une notification (« linkUpTrap » ou « linkDownTrap ») lorsque leur état change.
IV-G-3. Validation▲
La procédure de test est la suivante :
- Les interfaces réseau sont toutes opérationnelles.
- Le démon « snmpd » est relancé et on attend cinq à dix secondes.
- On désactive une interface réseau avec la commande « ifdown eth1 » et on attend cinq à dix secondes.
- Une notification « link down » est alors envoyée :
2.
3.
4.
2012-12-14 10:28:52 192.168.1.204(via UDP: [127.0.0.1]:44696->[127.0.0.1]:162) TRAP, SNMP v1, community public-trap
NET-SNMP-TC::linux Link Down Trap (0) Uptime: 0:00:10.07
IF-MIB::ifIndex.3 = INTEGER: 3 IF-MIB::ifDescr.3 = STRING: eth1 IF-MIB::ifAdminStatus.3 = INTEGER: down(2) IF-MIB::ifOperStatus.3 = INTEGER: down(2) SNMPv2-MIB::snmpTrapEnterprise.0 = OID: NET-SNMP-TC::linux
- On réactive l'interface réseau avec la commande « ifup eth1 » et on attend cinq à dix secondes.
- Une notification « link up » est alors envoyée :
2.
3.
2012-12-14 10:29:22 192.168.1.204(via UDP: [127.0.0.1]:44696->[127.0.0.1]:162) TRAP, SNMP v1, community public-trap
NET-SNMP-TC::linux Link Up Trap (0) Uptime: 0:00:40.08
IF-MIB::ifIndex.3 = INTEGER: 3 IF-MIB::ifDescr.3 = STRING: eth1 IF-MIB::ifAdminStatus.3 = INTEGER: up(1) IF-MIB::ifOperStatus.3 = INTEGER: up(1)SNMPv2-MIB::snmpTrapEnterprise.0 = OID: NET-SNMP-TC::linux
IV-H. La surveillance des erreurs d'authentification SNMP▲
IV-H-1. Le « quoi »▲
Cette surveillance a pour but de surveiller les échecs d'authentification (mauvaise communauté). Il n'y a rien à faire, dans le fichier de configuration c'est un fonctionnement par défaut. En cas de mauvaise authentification, le démon SNMPD ne répond pas. Si l'authentification est correcte, le démon répond.
IV-H-2. Le « comment »▲
Pour envoyer une notification lors des échecs d'authentification, il faut modifier le fichier de configuration comme ceci :
2.
3.
...
authtrapenable 1
...
IV-H-3. Validation▲
La procédure de test est la suivante :
- Le démon « snmpd » est relancé et on attend cinq à dix secondes.
- On exécute la commande suivante « snmpget -v 1 -c ublic localhost sysDescr.0 » avec un mauvais nom de communauté et on attend cinq à dix secondes.
- Une notification « bad authentication » est alors envoyée :
2.
2012-12-14 10:38:16 192.168.1.204(via UDP: [127.0.0.1]:49907->[127.0.0.1]:162) TRAP, SNMP v1, community public-trap
NET-SNMP-TC::linux Authentication Failure Trap (0) Uptime: 0:00:21.82
V. Conclusions▲
Voilà, c'en est fini avec ce deuxième module concernant SNMP version 1, les notifications et Net-SNMP. À l'issue de cet article, vous devriez avoir un démon SNMP opérationnel qui fait de la supervision de votre machine et qui envoie des notifications à un manager SNMP. C'est à vous de jouer maintenant afin de superviser exactement ce dont vous avez besoin.
Je voudrais toutefois vous mettre en garde, la supervision par SNMP n'est pas une supervision « temps réel ». Il ne sert absolument à rien de mettre des temps de « pooling » pour vos moniteurs avec des valeurs aussi faibles que cinq secondes (comme lors de nos essais).
A mon sens, une bonne valeur d'intervalle, c'est plutôt dix ou quinze minutes. D'abord, cela laisse le temps au système de se remettre tout seul (après tout, cela arrive qu'une CPU monte à 100% durant quelques minutes lors d'un backup par exemple), s'il se remet tout seul, c'est une action que vous n'avez pas à faire. Si le problème persiste au bout de dix à quinze minutes, là, vous avez un réel problème et une intervention est probablement nécessaire.
De plus, il est inutile de noyer l'opérateur sous un flot de notifications. S'il a trop de notifications, il les ignorera, car il n'aura pas le temps de les traiter. Il faut envoyer les « bonnes » notifications. Si le processus « machin » n'est pas rigoureusement utile, n'envoyez pas de notification s'il s'arrête.
Envoyer une notification pour dire que la sauvegarde s'est bien déroulée n'apporte strictement rien, envoyez plutôt une notification pour dire que la sauvegarde s'est mal déroulée. Si la sauvegarde se déroule mal toutes les nuits, une notification est envoyée toutes les nuits, il faut alors voir pourquoi la sauvegarde se passe mal ou alors arrêter les notifications sur mauvaise sauvegarde, c'est que vous n'en avez pas besoin.
Lorsque vous mettez en place une notification sur une erreur quelconque, tâchez aussi de mettre en place une notification lorsque le problème disparait. Cela permet au programme de supervision de fermer automatiquement la notification d'erreur lorsqu'il reçoit la notification de fin d'erreur. De plus, tâchez de mettre à disposition dans ces deux notifications un élément discriminant qui puisse faire le lien entre elles et uniquement elles.
Si vous voulez intégrer une machine dans un périmètre de supervision, pas de problème, et au contraire même. Par contre, il y a des choses à faire et des informations à fournir :
- l'adresse IP du manager vue de l'agent (il peut y avoir des dispositifs de translation d'adresse entre l'agent et le manager) ;
- l'adresse IP de l'agent vue du manager ;
- les noms, téléphones du, ou des administrateurs de la machine qui héberge l'agent. Attention, ces informations peuvent changer dans le temps, prévoir aussi une procédure de mise à jour ;
- la version SNMP utilisée par l'agent ;
- les paramètres d'identification et d'authentification du manager vers l'agent (pour les requêtes) ;
- les paramètres d'identification et d'authentification de l'agent vers le manager (pour les notifications) ;
- le dictionnaire des alarmes de l'agent, quelle notification, quel contenu, sous quelles conditions (c'est probablement la chose la plus dure à obtenir) ;
- pour chacune des alarmes, les actions correctives qui doivent, ou peuvent être entreprises par l'opérateur (redémarrer la machine, appeler l'administrateur…).
Avec toutes ces informations, cela devrait être un « plaisir » que d'intégrer une machine dans le périmètre de supervision.
Dans le prochain article, c'est promis, on parlera de SNMP en version 2, de ce qu'il apporte et de son implémentation dans Net-SNMP. Votre avis et vos suggestions sur cet article m'intéressent ! Alors, après votre lecture, n'hésitez pas : Commentez 
Je tiens à remercier mumen pour son aide lors de la relecture orthographique de cet article.
Votre avis et vos suggestions sur cet article m'intéressent ! Alors, après votre lecture, n'hésitez pas : Commentez