Surveillance SNMP dans Odoo 19 : seuil dépassé, ticket ouvert
Serveurs, commutateurs, onduleurs, sondes de température dans la salle serveur : presque tout ce qui est connecté à un réseau parle SNMP et peut renseigner sur son état. La question est seulement de savoir qui écoute – et ce qui se passe lorsqu'une valeur sort des limites.
Pour l'infrastructure dont nous assurons la maintenance pour nos clients, nous avons maintenant regroupé cette chaîne en un seul endroit : notre Odoo 19 interroge les appareils, compare les valeurs aux seuils, et lorsqu'une limite est atteinte, il ouvre un ticket dans le helpdesk – chez le client auquel appartient l'appareil. Pas de système de surveillance distinct qui écrit par e-mail dans le helpdesk, mais le même système dans lequel client, appareil et ticket sont de toute façon liés.
Nous avons développé le module pour notre propre exploitation. Ce n'est pas une publication communautaire comme nos modules pour les relevés bancaires ou les factures électroniques, mais une partie de notre plateforme interne de maintenance – tout comme la localisation, dont nous avons parlé récemment.
De la valeur mesurée au ticket
Le déroulement est volontairement simple :
- Un appareil est créé avec son adresse et ses identifiants d'accès (SNMP v1, v2c ou v3 avec authentification et chiffrement). Lors de l'enregistrement, Odoo récupère la description du système, le nom du système et l'uptime – la confirmation la plus honnête que l'adresse et les identifiants sont corrects.
- Des points de données sont définis sur l'appareil : un OID, une unité, une affectation à un client.
- Une planification interroge tous les points de données actifs. Pour chaque appareil, on se connecte une seule fois, et non pour chaque point de données – avec vingt OID sur un commutateur, c'est la différence entre une et vingt sessions.
- Chaque point de données peut surveiller des seuils : une limite supérieure, une limite inférieure ou les deux.
- Lorsqu'une limite est dépassée, un ticket helpdesk est créé.
Un ticket par incident, pas par mesure
Le point le plus important de la logique d'alarme : seul le changement d'état compte. Qui crée un ticket à chaque mesure a, après une nuit avec un capteur coincé ou instable, trois cents tickets – ce n'est pas de l'alerte, c'est du brouillard.
Le module mémorise donc pour chaque point de données s'il se trouve à l'état « Normal » ou « Alarme ». Au premier dépassement de la limite, l'état change, un message arrive dans le chatter de l'appareil et un ticket est ouvert – avec le client concerné comme partenaire, avec le point de données, l'appareil, la valeur mesurée et la limite enfreinte dans le texte. Tant que la valeur reste hors de la limite, rien d'autre ne se passe : le ticket est ouvert, nos techniciens sont informés.
Lorsque la valeur revient dans la plage normale, le module écrit une levée d'alerte dans le même ticket et supprime le lien. Que le ticket soit ensuite fermé reste décidé par un humain – une valeur qui repasse brièvement sous la limite ne signifie pas encore que la cause est résolue.
Les seuils sont vérifiés à chaque mesure, indépendamment du fait que la valeur soit enregistrée ou non. Une valeur constamment trop élevée reste une alarme. Et une alarme ne doit jamais échouer parce qu'un ticket ne peut pas être créé – si la création échoue, le journal et le message sur l'appareil subsistent malgré tout.
Ne stocker que ce qui change
Un point de données interrogé toutes les cinq minutes fournit 105 000 valeurs par an. Pour cent points de données, cela représente plus de dix millions de lignes – pour des valeurs qui, la plupart du temps, n'ont pas changé du tout.
On ne stocke donc que ce qui diffère de la dernière valeur enregistrée de plus d'un seuil défini – par point de données sous forme d'écart absolu (par exemple 0,5 °C), d'écart en pourcentage ou à chaque changement. La valeur actuelle et l'heure de la dernière interrogation figurent néanmoins toujours sur le point de données ; seul l'historique est allégé.
La destination d'écriture des valeurs est également configurable : dans la base de données Odoo, dans une MongoDB ou sous forme de fichiers CSV dans le filestore Odoo. Nous gardons ainsi les valeurs mesurées hors de la base de données ERP – même principe que pour les données de position de la localisation. L'historique peut dans tous les cas être affiché sous forme de graphique, avec, en cas de regroupement par heure, la moyenne et non la somme.
Taux de remplissage en pourcentage plutôt qu'en octets
Certaines grandeurs ne sont pas disponibles telles quelles dans l'appareil. Le taux de remplissage d'une partition doit être calculé à partir de l'espace utilisé et de la taille totale ; les capteurs de température fournissent souvent des entiers mis à l'échelle – 235 pour 23,5 degrés.
Un point de données peut donc reprendre la valeur telle que signalée, la multiplier par un facteur ou la calculer comme pourcentage d'un second OID. C'est décisif pour les seuils : une limite de 90 % s'applique à toute taille de disque. Une limite en gigaoctets devrait être mise à jour pour chaque lecteur.
Personne n'a besoin de connaître les OID par cœur
Pour les serveurs Windows et Linux, la HOST-RESOURCES-MIB est normalisée : les lecteurs et la mémoire vive se trouvent à un emplacement connu. Une détection d'appareil lit la table, convertit les taux de remplissage en pourcentage et crée les points de données avec leur seuil d'alarme en un clic.
Pour tout le reste, il existe un navigateur SNMP qui parcourt l'arborescence des OID et affiche chaque OID trouvé avec sa valeur actuelle – et, s'il est connu dans le catalogue, avec son nom, sa description et son unité issus de la MIB du fabricant importée. Il suffit de cocher.
Ce que nos clients en retirent
Les appareils et les points de données sont affectés à des clients. Dans le portail client, vous trouvez sous Mes valeurs SNMP les valeurs mesurées actuelles de vos appareils et l'historique des dernières 24 heures, 7 jours, 30 jours ou 12 mois sous forme de graphique – les mêmes valeurs que nous voyons aussi. Seul est visible ce qui est affecté à votre entreprise.
Et lorsqu'un seuil est dépassé, vous n'avez rien à faire : le ticket est déjà chez nous, avec l'appareil, la valeur et l'heure, avant même que vous ne le remarquiez.
Ce que le module n'est volontairement pas
Ce n'est pas un remplacement pour une surveillance complète avec contrôles de disponibilité, chaînes d'escalade et arbres de dépendances. Il ne reçoit pas de traps SNMP, mais interroge activement. Et il ne ferme aucun ticket automatiquement – la levée d'alerte est un message, pas un changement de statut.
Il s'agit d'un seul trajet : de la valeur mesurée, via le seuil, jusqu'au technicien qui s'en occupe. Ce trajet est désormais aussi court qu'il peut l'être.
Si vous souhaitez intégrer vos serveurs, vos équipements réseau ou vos capteurs à cette surveillance, contactez-nous.