Introduction à Net-SNMP - Notifications et Trap en version 1

ram-0000

Après un article général du protocole SNMP et un premier article traitant de SNMP version 1 sur Net-SNMP, je me lance dans un autre article toujours autour de SNMP mais cette fois-ci, j'aborderai la notion de notification (appelée aussi « trap » dans la littérature anglaise).

Votre avis et vos suggestions sur cet article m'intéressent ! Alors, après votre lecture, n'hésitez pas : Commentez ♪

- Titre : Introduction à Net-SNMP - Notifications et Trap en version 1

- Auteur : ram-0000

- Parution : 14 décembre 2012

- Licence : Copyright ® 2008-2012 ram-0000. Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.

Sommaire

- I. Introduction

- I-A. Les différents articles

- I-B. Un peu plus de dynamisme

- I-C. C'est quoi une notification (ou un trap) ?

- I-D. Les étapes de la supervision

- II. Le « où » , vers qui notifier ?

- II-A. Vers qui notifier ?

- II-B. Utilité du démon snmptrapd

- II-C. La syntaxe du fichier « /etc/snmp/snmptrapd.conf »

- II-C-1. La clause « authCommunity »

- II-C-2. La clause « forward »

- II-D. Modification du la configuration de snmptrapd

- II-E. Redémarrage de snmpd

- III. Le « quoi » et le « comment » , les prérequis

- III-A. La clause « monitor »

- III-A-1. EXPRESSION

- III-A-2. OPTIONS

- III-B. Création d'un utilisateur dédié

- IV. Le « quoi » et le « comment » , on peut y aller ?

- IV-A. L'état de certains processus

- IV-A-1. Le « quoi »

- IV-A-2. Le « comment »

- IV-A-3. Validation

- IV-B. Le taux de remplissage des disques

- IV-B-1. Le « quoi »

- IV-B-2. Le « comment »

- IV-B-3. Validation

- IV-C. La surveillance de la charge système

- IV-C-1. Le « quoi »

- IV-C-2. Le « comment »

- IV-C-3. 3.3.3 Validation

- IV-D. La surveillance de l'utilisation de la mémoire « swap »

- IV-D-1. Le « quoi »

- IV-D-2. Le « comment »

- IV-D-3. Validation

- IV-E. La surveillance de la taille de certains fichiers

- IV-E-1. Le « quoi »

- IV-E-2. Le « comment »

- IV-E-3. Validation

- IV-F. La surveillance du contenu de certains fichiers

- IV-F-1. Le « quoi »

- IV-F-2. Le « comment »

- IV-F-3. Validation

- IV-G. La surveillance des interfaces réseau

- IV-G-1. Le « quoi »

- IV-G-2. Le « comment »

- IV-G-3. Validation

- IV-H. La surveillance des erreurs d'authentification SNMP

- IV-H-1. Le « quoi »

- IV-H-2. Le « comment »

- IV-H-3. Validation

- V. Conclusions

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 :

1. 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 » :

Fichier de configuration de snmptrapd

1. authCommunity log,net public-trap

2. 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 :

Fichier de log de snmptrapd

1. 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

2. NET-SNMP-MIB::netSnmpNotificationPrefix Enterprise Specific Trap (NET-SNMP-AGENT-MIB::nsNotifyShutdown) Uptime: 0:00:06.37

4. 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

5. 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 :

Tcpdump d'un trap

1. root@debian:~# tcpdump port 162

3. tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

5. listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes

7. 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

9. 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 :

1. 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
-di 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.
Cette option implique l'option -D.

-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
-o 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.
Les notifications éventuellement générées par la première évaluation seront envoyées avant la notification de démarrage « coldStart ».

-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 » :

1. createUser InternalUser MD5 "MD5 password"

2. rouser InternalUser

3. 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 ».

1. root@debian:~# ps -e

2. ...

3. 841 ?        00:00:00 sshd

4. 843 pts/1    00:00:00 bash

5. 883 pts/0    00:00:00 sleep

6. 884 pts/1    00:00:00 ps

7. ...

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 :

1. ...

2. # processus a superviser

3. # proc <procname> [MAX] [MIN]

4. proc sleep 2 1

5. ...

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 » :

1. root@debian:~# snmptable -v 1 -c public localhost prTable

2. SNMP table: UCD-SNMP-MIB::prTable

4. prIndex prNames prMin prMax prCount prErrorFlag prErrMessage prErrFix prErrFixCmd

5. 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 :

1. root@debian:~# snmptable -v 1 -c public localhost prTable

2. SNMP table: UCD-SNMP-MIB::prTable

4. prIndex prNames prMin prMax prCount prErrorFlag                  prErrMessage prErrFix prErrFixCmd

5. 1   sleep     1     2       0       error Too few sleep running (# = 0)  noError

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 :

1. root@debian:~# snmptable -v 1 -c public localhost prTable

2. SNMP table: UCD-SNMP-MIB::prTable

4. prIndex prNames prMin prMax prCount prErrorFlag                   prErrMessage prErrFix prErrFixCmd

5. 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 :

1. 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 :

1. 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

2. DISMAN-EVENT-MIB::dismanEventMIBNotificationPrefix Enterprise Specific Trap (DISMAN-EVENT-MIB::mteTriggerFired) Uptime: 0:01:32.13

3. 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 :

1. 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

2. DISMAN-EVENT-MIB::dismanEventMIBNotificationPrefix Enterprise Specific Trap (DISMAN-EVENT-MIB::mteTriggerFired) Uptime: 0:03:32.20

3. 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 :

1. 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

2. DISMAN-EVENT-MIB::dismanEventMIBNotificationPrefix Enterprise Specific Trap (DISMAN-EVENT-MIB::mteTriggerFired) Uptime: 0:05:32.26

3. 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 :

1. 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

2. DISMAN-EVENT-MIB::dismanEventMIBNotificationPrefix Enterprise Specific Trap (DISMAN-EVENT-MIB::mteTriggerFired) Uptime: 0:07:02.31

3. 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 :

1. ...

2. # filesystem a superviser

3. # includeAllDisks <min>%

4. # disk <path> [<min kb> | <min>%]

5. includeAllDisks 80%

6. disk / 50%

7. ...

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 » :

1. root@debian:~# snmptable -v 1 -c public localhost dskTable

2. SNMP table: UCD-SNMP-MIB::dskTable

4. dskIndex      dskPath dskDevice dskMinimum dskMinPercent dskTotal dskAvail dskUsed dskPercent dskPercentNode dskTotalLow dskTotalHigh dskAvailLow dskAvailHigh dskUsedLow dskUsedHigh dskErrorFlag dskErrorMsg

5. 1            / /dev/sda1         -1            50  7867856  6417132 1051060         13              9     7867856            0     6417132            0    1051060           0      noError

6. 2 /lib/init/rw     tmpfs         -1            80   192316   192316       0          0              0      192316            0      192316            0          0           0      noError

7. 3         /dev      udev         -1            80   187880   187736     144          0              1      187880            0      187736            0        144           0      noError

8. 4     /dev/shm     tmpfs         -1            80   192316   192316       0          0              0      192316            0      192316            0          0           0      noError

9. 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 » :

1. root@debian:~# snmptable -v 1 -c public localhost dskTable

2. SNMP table: UCD-SNMP-MIB::dskTable

4. dskIndex      dskPath dskDevice dskMinimum dskMinPercent dskTotal dskAvail dskUsed dskPercent dskPercentNode dskErrorFlag                   dskErrorMsg

5. 1            / /dev/sda1         -1            50  7867856  2345796 5122396         69              8        error /: less than 50% free (= 69%)

6. 2 /lib/init/rw     tmpfs         -1            80   192316   192316       0          0              0      noError

7. 3        /proc      proc         -1            80        0        0       0          0            100      noError

8. 4         /sys     sysfs         -1            80        0        0       0          0            100      noError

9. 5         /dev      udev         -1            80   187880   187736     144          0              1      noError

10. 6     /dev/shm     tmpfs         -1            80   192316   192316       0          0              0      noError

11. 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 :

1. root@debian:~# snmptable -v 1 -c public localhost dskTable

2. SNMP table: UCD-SNMP-MIB::dskTable

4. dskIndex      dskPath dskDevice dskMinimum dskMinPercent dskTotal dskAvail dskUsed dskPercent dskPercentNode dskErrorFlag dskErrorMsg

5. 1            / /dev/sda1         -1            50  7867856  6544192  924000         12              8      noError

6. 2 /lib/init/rw     tmpfs         -1            80   192316   192316       0          0              0      noError

7. 3        /proc      proc         -1            80        0        0       0          0            100      noError

8. 4         /sys     sysfs         -1            80        0        0       0          0            100      noError

9. 5         /dev      udev         -1            80   187880   187736     144          0              1      noError

10. 6     /dev/shm     tmpfs         -1            80   192316   192316       0          0              0      noError

11. 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 :

1. 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 :

1. 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

2. DISMAN-EVENT-MIB::dismanEventMIBNotificationPrefix Enterprise Specific Trap (DISMAN-EVENT-MIB::mteTriggerFired) Uptime: 0:04:50.25

3. 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 :

1. 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

2. DISMAN-EVENT-MIB::dismanEventMIBNotificationPrefix Enterprise Specific Trap (DISMAN-EVENT-MIB::mteTriggerFired) Uptime: 0:17:46.72

3. 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 :

1. ...

2. # System Load Monitoring

3. # load MAX1 [MAX5 [MAX15]]

4. load 0.3 0.2 0.1

5. ...

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 :

1. root@debian:~# snmptable -v 1 -c public localhost latable

2. SNMP table: UCD-SNMP-MIB::laTable

4. laIndex laNames laLoad laConfig laLoadInt laLoadFloat laErrorFlag laErrMessage

5. 1  Load-1   0.16     0.30        16    0.160000     noError

6. 2  Load-5   0.19     0.20        19    0.190000     noError

7. 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 :

1. root@debian:~# snmptable -v 1 -c public localhost latable

2. SNMP table: UCD-SNMP-MIB::laTable

4. laIndex laNames laLoad laConfig laLoadInt laLoadFloat laErrorFlag                          laErrMessage

5. 1  Load-1   0.40     0.30        40    0.400000       error  1 min Load Average too high (= 0.40)

6. 2  Load-5   0.24     0.20        23    0.240000       error  5 min Load Average too high (= 0.24)

7. 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 :

1. 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 :

1. 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

2. DISMAN-EVENT-MIB::dismanEventMIBNotificationPrefix Enterprise Specific Trap (DISMAN-EVENT-MIB::mteTriggerFired) Uptime: 0:01:08.10

3. 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 :

1. 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

2. DISMAN-EVENT-MIB::dismanEventMIBNotificationPrefix Enterprise Specific Trap (DISMAN-EVENT-MIB::mteTriggerFired) Uptime: 0:02:48.14

3. 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 » :

1. root@debian:~# swapon -s

2. Filename                                Type            Size    Used    Priority

3. /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 :

1. ...

2. # swap <MIN kb>

3. swap 300000

4. ...

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 :

1. root@debian:~# snmpwalk -v 1 -c public localhost UCD-SNMP-MIB::memory

2. UCD-SNMP-MIB::memIndex.0 = INTEGER: 0

3. UCD-SNMP-MIB::memErrorName.0 = STRING: swap

4. UCD-SNMP-MIB::memTotalSwap.0 = INTEGER: 392184 kB

5. UCD-SNMP-MIB::memAvailSwap.0 = INTEGER: 380732 kB

6. UCD-SNMP-MIB::memTotalReal.0 = INTEGER: 384636 kB

7. UCD-SNMP-MIB::memAvailReal.0 = INTEGER: 355864 kB

8. UCD-SNMP-MIB::memTotalFree.0 = INTEGER: 736596 kB

9. UCD-SNMP-MIB::memMinimumSwap.0 = INTEGER: 16000 kB

10. UCD-SNMP-MIB::memBuffer.0 = INTEGER: 624 kB

11. UCD-SNMP-MIB::memCached.0 = INTEGER: 11320 kB

12. UCD-SNMP-MIB::memSwapError.0 = INTEGER: noError(0)

13. 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 :

1. #include <stdlib.h>

2. #include <stdio.h>

4. int main(int argc, char * argv[])

5. {

6. int nb = 65536;

7. if(argc != 1)

8. nb = atoi(argv[1]);

9. int boucle;

10. printf("allocating...\n");

11. for(boucle = 0; boucle != nb; boucle++)

12. {

13. malloc(1024);

14. }

15. printf("sleeping...\n");

16. for(;;) sleep(1);

17. }

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 :

1. root@debian:~# vmstat 1

2. procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----

3. r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa

4. 0  0   7412 363756    276  10148    4  480    44   590   38   22  3  3 94  0

5. 0  0   7412 363748    276  10172    0    0     0     0   22   20  0  0 100  0

6. 1  0   7404 312652    276  10172   32    0    32     0   70   23  5 15 80  0

7. 1  0   7404  18524    276  10172    0    0     0     0  274   12 33 67  0  0

8. 2  0  33408   4296     68   1476  192 26336  1364 26364  513  421  3 45  0 52

9. 2  0 118560   4208     64   1680  136 84932   940 84932 1738 1367  4 71  0 25

10. 0  0 186992   5192     84   2148   64 68440  1456 68440 1209  704  6 52 31 11

11. 0  0 186992   5200     84   2176    0    0    28     0   16   15  0  0 100  0

12. 0  0 186992   5200     84   2176    0    0     0     0   14   12  0  0 100  0

13. 0  0 188140   5188    108   3164   32 1148  1260  1148   74   92  0  2 87 11

14. 0  0 188140   5188    108   3164    0    0     0     0   14    9  0  0 100  0

15. 0  0 189152   5272    108   4048  164 1032  1468  1032   91  102  0  1 88 11

16. 0  0 189152   5272    112   4336    0    0   280     0   32   24  0  1 99  0

17. 0  0 189152   5272    112   4344    0    0     0     0   15   15  0  0 100  0

18. 0  0 189152   5272    120   4336    0    0     0    24   17   19  0  0 100  0

19. 0  0 189152   5272    120   4344    0    0     0     0   14    9  0  0 100  0

20. 0  0 189152   5272    120   4344    0    0     0     0   18   17  0  0 100  0

21. 0  0 189152   5272    120   4344    0    0     0     0   15   11  0  0 100  0

22. 0  0   7852 369436    124   5428  120    0  1212     0   57   54  0  3 97  0

23. 0  0   7852 369440    124   5432    0    0     0     0   13   11  0  0 100  0

24. 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 :

1. root@debian:~# snmpwalk -v 1 -c public localhost UCD-SNMP-MIB::memory

2. UCD-SNMP-MIB::memIndex.0 = INTEGER: 0

3. UCD-SNMP-MIB::memErrorName.0 = STRING: swap

4. UCD-SNMP-MIB::memTotalSwap.0 = INTEGER: 392184 kB

5. UCD-SNMP-MIB::memAvailSwap.0 = INTEGER: 235304 kB

6. UCD-SNMP-MIB::memTotalReal.0 = INTEGER: 384636 kB

7. UCD-SNMP-MIB::memAvailReal.0 = INTEGER: 4060 kB

8. UCD-SNMP-MIB::memTotalFree.0 = INTEGER: 239364 kB

9. UCD-SNMP-MIB::memMinimumSwap.0 = INTEGER: 300000 kB

10. UCD-SNMP-MIB::memBuffer.0 = INTEGER: 164 kB

11. UCD-SNMP-MIB::memCached.0 = INTEGER: 4400 kB

12. UCD-SNMP-MIB::memSwapError.0 = INTEGER: error(1)

13. 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 :

1. 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 :

1. 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

2. DISMAN-EVENT-MIB::dismanEventMIBNotificationPrefix Enterprise Specific Trap (DISMAN-EVENT-MIB::mteTriggerFired) Uptime: 0:00:50.14

3. 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 :

1. 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

2. DISMAN-EVENT-MIB::dismanEventMIBNotificationPrefix Enterprise Specific Trap (DISMAN-EVENT-MIB::mteTriggerFired) Uptime: 0:04:00.14

3. 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 :

1. ...

2. # file < filename > [SIZEMAX kb]

3. file /tmp/test.txt 1

4. ...

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 :

1. root@debian:~# snmptable -v 1 -c public localhost fileTable

2. SNMP table: UCD-SNMP-MIB::fileTable

4. fileIndex      fileName fileSize fileMax fileErrorFlag fileErrorMsg

5. 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 :

1. root@debian:~# snmptable -v 1 -c public localhost fileTable

2. SNMP table: UCD-SNMP-MIB::fileTable

4. fileIndex      fileName fileSize fileMax fileErrorFlag                            fileErrorMsg

5. 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 :

1. 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 :

1. 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

2. DISMAN-EVENT-MIB::dismanEventMIBNotificationPrefix Enterprise Specific Trap (DISMAN-EVENT-MIB::mteTriggerFired) Uptime: 0:00:25.14

3. 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 :

1. 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

2. DISMAN-EVENT-MIB::dismanEventMIBNotificationPrefix Enterprise Specific Trap (DISMAN-EVENT-MIB::mteTriggerFired) Uptime: 0:02:50.15

3. 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 :

1. ...

2. # logmatch <name> <filename> <every sec> <regex>

3. logmatch test /tmp/match.txt 1 hello

4. ...

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 :

1. root@debian:~# snmptable -v 1 -c public localhost logMatchTable

2. SNMP table: UCD-SNMP-MIB::logMatchTable

4. logMatchIndex logMatchName logMatchFilename logMatchRegEx logMatchGlobalCounter logMatchGlobalCount logMatchCurrentCounter logMatchCurrentCount logMatchCounter logMatchCount logMatchCycle logMatchErrorFlag logMatchRegExCompilation

5. 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 :

1. root@debian:~# snmptable -v 1 -c public localhost logMatchTable

2. SNMP table: UCD-SNMP-MIB::logMatchTable

4. logMatchIndex logMatchName logMatchFilename logMatchRegEx logMatchGlobalCounter logMatchGlobalCount logMatchCurrentCounter logMatchCurrentCount logMatchCounter logMatchCount logMatchCycle logMatchErrorFlag logMatchRegExCompilation

5. 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 :

1. root@debian:~# snmptable -v 1 -c public localhost logMatchTable

2. SNMP table: UCD-SNMP-MIB::logMatchTable

4. logMatchIndex logMatchName logMatchFilename logMatchRegEx logMatchGlobalCounter logMatchGlobalCount logMatchCurrentCounter logMatchCurrentCount logMatchCounter logMatchCount logMatchCycle logMatchErrorFlag logMatchRegExCompilation

5. 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 :

1. 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 :

1. 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

2. DISMAN-EVENT-MIB::dismanEventMIBNotificationPrefix Enterprise Specific Trap (DISMAN-EVENT-MIB::mteTriggerFired) Uptime: 0:00:55.08

3. 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 :

1. 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

2. DISMAN-EVENT-MIB::dismanEventMIBNotificationPrefix Enterprise Specific Trap (DISMAN-EVENT-MIB::mteTriggerFired) Uptime: 0:05:25.10

3. 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 :

1. ...

2. notificationEvent  linkUpTrap    linkUp   ifIndex ifDescr ifAdminStatus ifOperStatus

3. notificationEvent  linkDownTrap  linkDown ifIndex ifDescr ifAdminStatus ifOperStatus

4. ...

Le contenu de la table des interfaces réseau est visible avec la commande suivante :

1. root@debian:~# snmptable -v 1 -c public localhost ifTable

2. SNMP table: IF-MIB::ifTable

4. ifIndex ifDescr           ifType ifMtu    ifSpeed   ifPhysAddress ifAdminStatus ifOperStatus ifLastChange ifInOctets ifInUcastPkts ifInNUcastPkts ifInDiscards ifInErrors ifInUnknownProtos ifOutOctets ifOutUcastPkts ifOutNUcastPkts ifOutDiscards ifOutErrors ifOutQLen              ifSpecific

5. 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

6. 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

7. 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 :

1. monitor  -r 5 -e linkUpTrap   "linkUp trap" ifOperStatus != 2

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 :

1. 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

2. NET-SNMP-TC::linux Link Down Trap (0) Uptime: 0:00:10.07

4. 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 :

1. 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

2. NET-SNMP-TC::linux Link Up Trap (0) Uptime: 0:00:40.08

3. 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 :

1. ...

2. authtrapenable 1

3. ...

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 :

1. 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

2. 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