Tous les équipements de réseau, les serveurs, presque tout avec un connexion IP support le management par protocole SNMP. L'idée c'est que chaque appareil a une arbre de donnés, structuré dans la base de données MIB, et avec messages SNMP GET et SET on peut consulter le status et modifier la configuration des appareils.

La MIB est structuré en arbre, chaque nœud de l'arbre est decrit par un numéro. Alors, pour arriver a n'importe quel nœud de la MIB, il faut seulement mettre les numeros des nœud du chemin séparé par (.), on appelle ça le OID.

Example: le OID 1.3.6.1.2.1.1.1.0 c'est le nœud que tiens la valeur SystemDescription, l'OID 1.3.6.1.2.1.25.1.1.0 c'est le nœud que tiens la valeur SystemUptime

Alors, pour sécuriser un peu… un peu, on doit mettre une espèce de password dans le message SNMP. La COMMUNITY est une clé partagé par l'appareil et le manager. Cette COMMUNITY peut donner accès de Read-Only ou Read-Write

Pour bien découvrir cette arbre d'information, on est équipé des outils:

• snmpwalk -c {community} {host} {oid} A partir d'un OID, tout l'arbre est exploré
• snmpget -c {community} {host} {oid} Prendre la valeur de l'OID
• Outils GUI pour faire MIB Browsing

Dans le Zabbix, pour ne pas configurer tous les éléments de monitoring dans chaque host (s'il y a 10 switches, chaque un avec 24 ports, ce son 240 items a configurer!), on peut créer un Template, où on met les prototypes de tous les items qu'on veut monitorer dans les hosts que ont appliqué le Template.

Example: Le Template Template_Switch a tous les items [Items, Graphs, Triggers, DiscoveryRules] qu'on monitore dans tous les Switches. Alors, pour créer un nouveau Graph (ou un nouveau Item) pour tous les Switches, on change le Template. Pour créer un nouveau Item seulement pour un Host particulier, on change le Host.

Les Templates peuvent avoir quelques MACROS, que sont des valeurs que le system remplace. Exemple, le macro {$SNMP_COMMUNITY} peut contenir le string COMMUNITY pour tous les Hosts qu'utilisent le Template.

Pour l'agent SNMPv2, les Items Zabbix doivent avoir les valeurs:

• Key = Valeur unique pour reconnaitre le Item. Peut être numéro ou string.
• OID = Valeur de la MIB que est mis dans le Item. Un snmpget peut montrer si ça c'est valide.
• Community = SNMP Community pour le host. On peut utiliser la MACRO {$SNMP_COMMUNITY}
• Type de donnés = Quel type de donnés va repondre l'OID, soit Numerique, String, Octetc, etc.

Les Graphs simplement prennent les Items déjà défini et les mettent dans un beau Graphique. Un Graph peut avoir différent Items, mais attention a ne pas mélanger les types de donnés dans le Graph.

Le Graph peut avoir un titre dynamique, si on met quelques variables dans le texte. Les variables ont la forme {{HOSTNAME}:Item.function()}''. **{HOSTNAME}** est remplacé par le texte du Hostname, **Item** c'est un Item définie dans le Host auquel on aplique une **function()** comme ''last(), max(), min(), diff()''. Les **Trigger** sont expressions que évalués TRUE causent une alerte. Les **Trigger** sont évalués quand les Items son actualisés. Ils ont une formula ''[>,=,<]'' pour les valeurs ''[max(), avg(), min(), last()]'' d'un Item déjà définis. Example ''{Template_DD-WRT:icmpping.max(180)}=0'' Les **Trigger** peuvent avoir des titres dynamiques, de la meme maniere que les **Graphs**. ==== Discovery Rules ==== Les **DiscoveryRules** sont la magique et la malédiction de Zabbix. Une **DiscoveryRule** est exécuté régulièrement pour découvrir nouveau Items, Graphs ou Triggers. Comme ça, on a une **DiscoveryRule** qui va chercher tous les ports d'un Switch. Si le port n'existe pas encore, la rule va cree automatiquement le Item, le Graph et le Trigger définis. Si le **Item** n'existe plus, la DiscoveryRule va efacer le **Item**. <WRAP center round alert > ** Attention** Analiser la frequence (update time) des DiscoveryRules, des Items et Triggers. On doit demander updates selon la frequence de changement des informations, selon ce qu'on va monitorer, et d'autre choses. </WRAP> Pour creer une **DiscoveryRule** dans un ''Template'' Zabbix avec SNMP, on commence pour définir quel est le OID que Zabbix va faire ''snmpwalk'' pour trouver les **Items**. Typiquement les **DiscoveryRules** servent pour trouver **Items** qui sont organisés dans **Tables** dans la MIB. On met cet OID dans la config de la **DiscoveryRule**. <code> OID.1.[ColIndex].[RowIndex] OID.1.1.1 = "Valeur1" OID.1.1.2 = "Valeur2" OID.1.1.3 = "Valeur3" OID.1.2.1 = "Valeur1Col2" OID.1.2.2 = "Valeur2Col2" OID.1.etc </code> On fait ''snmpwalk'' sur l'OID initial pour trouver le **Index** et la **Valeur** que va servir pour identifier les différents **Items**. Alors le macro ''{#SNMPINDEX}'' est le numéro [RowIndex], et la valeur est dans le macro ''{#SNMPVALUE}''. Les macros **{#SNMPVALUE}** et **{#SNMPINDEX}** peuvent être filtrés avec une expression régulière, pour limiter les Items qu'on va créer. Example, le Filtre ''^Vlan'' appliqué sur **{#SNMPVALUE}** fait que seulement les Items qui commence par "Vlan*" soient considérés. Après, il faudra créer les **ItemPrototype**, ça veut dire, les **Items** que la règle va créer chaque fois qu'il y a nouveaux réponses a l'OID de la **DiscoveryRule**. C'est bien similaire a la création d'un **Item**, mais ici il s'agit d'un __array__ de **Items** où l'index est le valeur ''{#SNMPVALUE}''. * KEY = keyDescription[{#SNMPVALUE}] * OID = OIDBase.{#SNMPINDEX} * Community = SNMP Community pour le host. On peut utiliser la MACRO ''{$SNMP_COMMUNITY}'' * Type de donnés = Quel type de donnés va répondre l'OID, soit Numérique, String, Octetc, etc. Dans le Titre de l'Item, on peut avoir aussi le Index si on utilise dans le text le macro ''{#SNMPVALUE}''. Une fois qu'on a creé les **ItemPrototypes**, on peut les mettre dans les **TriggerPrototypes** et **GraphPrototyes**. Ce sont exactement comme les **Trigger** et **Graph**, mais cette fois ci on choisi **ItemPrototypes** pour metre donnés dedans. La DiscoveryRule va creer automatiquement les **Graphs** et **Triggers** si nouveaux **Items** sont trouvés. Le **GraphPrototype** et **TriggerPrototype** peuvent avoir un titre dynamique, si on met quelques variables dans le texte. Les variables ont la forme ''{{HOSTNAME}:Item[{#SNMPVALUE}].function()}''. **{HOSTNAME}** est remplacé par le texte du Hostname, **Item[#SNMPVALUE]** c'est le Item juste crée, auquel on applique une **function()** comme ''last(), max(), min(), diff()''. == Example == D'abord, on fait un ''snmpwalk'' sur l'**OID** des ''IfDesc(1.3.6.1.2.1.2.2.1.2)'', selon la documentation de la MIB qu'on peut trouver en Internet et partout. <code> :~$ snmpwalk {...} 1.3.6.1.2.1.2.2.1.2 iso.3.6.1.2.1.2.2.1.2.1 = STRING: "lo" iso.3.6.1.2.1.2.2.1.2.2 = STRING: "eth0" iso.3.6.1.2.1.2.2.1.2.3 = STRING: "eth1" iso.3.6.1.2.1.2.2.1.2.4 = STRING: "eth2" </code> Cet **OID** sera utilisé dans la **DiscoveryRule**, ou ''{#SNMPVALUE}'' c'est le nome de l'interface. On met un **Filtre** ''^eth'' pour prendre seulement les interfaces Ethernet. Après, on va créer **ItemPrototypes** pour les différents **OIDs** de la table SNMP. Par exemple, on fait un ''snmpwalk'' sur l'OID des ''InOctets(1.3.6.1.2.1.2.2.1.10)'' <code> tamayo_j@vpn1:~$ snmpwalk {...} 1.3.6.1.2.1.2.2.1.10 iso.3.6.1.2.1.2.2.1.10.1 = Counter32: 552 iso.3.6.1.2.1.2.2.1.10.2 = Counter32: 2374203546 iso.3.6.1.2.1.2.2.1.10.3 = Counter32: 106847793 iso.3.6.1.2.1.2.2.1.10.4 = Counter32: 2129603 </code> Le **ItemPrototype** a: Name = "Description of Item for {#SNMPVALUE}" KEY = ifInOctects[{#SMMPVALUE}] OID = 1.3.6.1.2.1.2.2.1.10.{#SNMPINDEX} Avec le **ItemPrototype**, on fait les **GraphPrototype** et les **TriggerPrototype** de la même manière que les **Graphs** et **Triggers**. Le titre peut être dynamique pour s'ajuster au valeurs de l'ItemPrototype. Name = "Graph pour {#SNMPVALUE} ( {{HOSTNAME}.Items[{#SNMPVALUE}].funcion()} )" ==== Zabbix Templates for Switches / Bornes / WLC ==== Il y a 6 Templates basiques pour les Switches sur le Zabbix Minet, basés plutôt sur les Discovery rules, "to make live easier". Ils utilisent SNMP OIDs partout. * **Template Switch Discovery**: Ce template c'est la base, hérité par les autres. Ici on monitore CPU/Memory/Temperature/Ping et tous les interfaces. Il y a un *Discovery Rule* pour les description et débits des ports, et un autre pour les PortChannels. Bien sur, il y a *Triggers* basiques. Ici on découvre tous les ports des SW * **Template_Cisco_Discovery_{x}f_{y}g**: Ces templates ont déjà inclus le *Template Switch Discovery*. Ce qu'ils ont ajoutés c'est de monitoring et triggers pour les ports Uplinks (les {Y} ports a la fin du SW). Peu importe le modèle de Switch, il faut faire le match entre {X} ports pour les users et {Y} ports uplink (SFPs). Alors le monitoring avancé c'est pour les ports uplinks. * **Template Switch Discovery WeatherMap**: Ce template est une reduction du *Template Switch Discovery*, pour seulement prend les débit IN/OUT, CPU/MEM et faire ces Graphs là, pour le WeatherMap. Les hosts appelés *-map* a la fin sont utilisés par le Weathermap, ce sont les seuls a être lis par le user *guest*. *Attention...* * **Template Router Discovery**: Ce template est une version advanced du *Template Switch Discovery*, qui monitore les interfaces Vlans et son état. Comme ca, on me perde pas de monitorer tous les VLANS. C'est différent parce que les OID pour le Routeur changent un peu par comparaison au Switch. * **Template DD-WRT Discovery**: C'est un template hyper-cool qui se base sur les données collectés par un script bash manuel sur les bornes *dd-wrt* (pour l'instant, sur le bornes U2). On prends plein de données sur la qualité de l'air, channel/power et quantité de clients. Le plus proche du Cisco, quoi. Utilise *Discovery rules* pour suivre les changements sur les bornes * **Template Cisco WLC Discovery**: C'est le template que explose le SNMP du WLC pour prendre données sur le SSID, Controller et chaque AP. Attention, il y a de *Discovery rules* qui sont inhabilités parce qu'il cause trop de données (genre, client's MAC or AP's status). Le fait d'utiliser *Discovery rules* fait facile suivre les changements sur la config du WLC. Attention, quelques **Triggers** sont inhabilités pendant L’été. ==== References ==== [[Cisco SNMP Object Navigator|http://tools.cisco.com/Support/SNMP/do/BrowseOID.do]] AIRESPACE-WIRELESS-MIB , CISCO-WIRELESS-IF-MIB, IF-MIB [[DD-WRT SNMP values|http://www.dd-wrt.com/wiki/index.php/Simple_Network_Management_Protocol#Wireless_Rate_Via_SNMP]]