LoriotPro
LoriotPro est un logiciel de supervision d’infrastructures en réseau développé et commercialisé par la société française LUTEUS depuis 2002. Plus communément appelé: Network Management System (NMS), ce type de logiciel assiste les administrateurs à maintenir la disponibilité et la performance des services fournis par le réseau. Il est disponible sur plateforme Microsoft Windows™ exclusivement.
Le logiciel est aussi un environnement de développement complet dédié à la création d'applications de supervision et d'automatisation. Le logiciel intègre les outils de développement et de test ainsi qu’une librairie de fonctions en langage de script LUA. Les fonctions permettent de manipuler par codage les agents SNMP, les objets de l’annuaire, les objets graphiques des visuels dynamiques, etc.
Une édition gratuite du produit est disponible pour des usages pédagogiques ou pour la surveillance de quelques unités, les éditions commerciales sont disponibles pour les professionnels des technologies de l’information, les opérateurs de télécommunications, les fournisseurs ou diffuseurs de contenu de l'audiovisuel.
Principes
Le bon fonctionnement d’équipements connectés à un réseau de communication IP peut être surveillé à distance par le protocole SNMP. Ce protocole est maintenant implémenté dans les équipements les plus divers tels que des ordinateurs, des serveurs, des routeurs, des commutateurs, des PDU, les onduleurs, équipements de studio, équipements de télédiffusion, équipement de radiodiffusion, etc., mais aussi dans les applications telles que des moteurs de base de données, des annuaires, les messageries électroniques, les machines virtuelles, etc.
Le protocole SNMP définit deux types entités, les agents et les managers. Les agents sont des logiciels présents sur les équipements à surveiller tandis que le manager est le logiciel chargé de la collecte des informations auprès des agents ou de la réception d’informations émises par ces mêmes agents. Le logiciel LoriotPro a le rôle de Manager SNMP.
Les données collectées en SNMP par le logiciel sont ensuite utilisées pour informer les administrateurs de l’infrastructure, des anomalies de fonctionnement et/ou de l’utilisation des ressources. La qualité de l’interface homme-machine ou GUI est un facteur clé pour aider les opérateurs à identifier rapidement tout défaut de fonctionnement pouvant créant une indisponibilité de service ou une perte de performance dans l’accès au service. À cette fin, des visuels dynamiques affichent les statuts de fonctionnement avec les codes couleur habituels (vert : tout va bien, rouge : il y a un problème !). Un signal sonore, un E-mail ou un SMS sont aussi des moyens d’alerter les opérateurs.
Par l’intermédiaire des agents SNMP, le logiciel accède à une vision globale sur toutes les couches du modèle ISO. Suivant le type d’équipement interrogé, des informations très variées sont accessibles. Dans un commutateur Ethernet par exemple, on pourra identifier le type de connexion physique (Couche 1 physique) reliant l’équipement au réseau, mais par interrogation d’un serveur (couche 7 Application) on pourra connaitre le nom d’un utilisateur connecté.
Pour les éditions Extended et Broadcast du produit, le logiciel intègre une plate forme de développement d’applications basées sur le langage de script intégré LUA. L’intégration native des outils de développement et l’ajout de fonctions LUA dédiées à la supervision permettent l’automatisation des collectes de données, le multitâche temps réel ainsi que l’interaction avec les interfaces graphiques.
La problématique de la surveillance de milliers de systèmes en temps réel La surveillance des équipements est principalement réalisée grâce au protocole SNMP mais aussi avec d’autres types d’accès tels que TCP, HTTP, SQL, SOAP, etc. Les délais de réponse à des requêtes sont assez imprévisibles, on ne peut donc prévoir réellement le temps qu’un processus de collecte mettra pour obtenir une réponse. Par ailleurs, Il est parfois nécessaire de réaliser les collectes périodiquement et à intervalles serrés (période de polling), de l’ordre de la seconde pour certains indicateurs de performance.
On conclut que si un processus unique est chargé des collectes et qu’il réalise celles-ci séquentiellement, elles ne seront pas honorées dans les intervalles de temps programmé et le logiciel de supervision ne pourra informer l’administrateur de ces dysfonctionnements.
Le multitâche apporte la solution à cette problématique. Dans le logiciel, pour réaliser les tâches de collecte, un nombre variable de processus peuvent y être dédié. Par principe, plus le nombre de tâches à réaliser est important et plus leur fréquence de répétition est élevée, plus le nombre de processus devra être grand. Les processus en question sont instanciés autant que nécessaires (Plugin Audit Process) pour assumer un traitement parallélisé.
Voici un exemple simplifié avec deux processus chargés de trois collectes. Les collectes sont réalisées à des intervalles de temps différents, les durées de collecte sont aussi supposées variables. Les deux processus (Audit Process) prennent en charge les collectes en fonction de leur disponibilité. Dès qu’ils ont fini leur travail, ils parcourent la liste des collectes à faire et s’attribuent la première dont la période d’interrogation (polling) est échue et qui n’est pas déjà attribuée.
Cet exemple présente des ratios entre période d’interrogation et durée de traitement disproportionné. Habituellement le rapport entre celle-ci est de 1 à 100 environ. Dans le cas ou un agent SNMP fonctionne correctement une collecte est de l’ordre de quelques dizaines de millisecondes et les intervalles d’interrogation entre 1 et 15 secondes. Des retards dans les traitements peuvent survenir si les délais de collecte augmentent ou si le nombre de collectes est augmenté. Idéalement il faut que la somme des rapports entre la durée d’exécution et la période interrogation de toutes les collectes soit inférieure au nombre de processus de collecte disponible pour leur traitement.
Les valeurs des collectes sont ensuite stockées dans des variables globales directement en mémoire. Ces variables sont accessibles de partout au sein du logiciel et plus particulièrement au sein d’un visuel d’Active View.
Respect du standard FCAPS
Le logiciel de supervision respecte la norme FCAPS de l’ISO (Organization for Standardization) et de ITU (Union Internationale des Télécommunication). L'ITU a défini l'architecture TMN (Telecomunication Management Network) in 1988. Dans l'objectif de fournir une modèle efficace pour la gestion des systèmes d'information, l'International (ISO) en se basant sur TMN a développé le modèle FCAPS. Ce modèle identifie 5 domaines qui constitue l'arrête dorsale du système de gestion.
- Fault Management (Gestion des anomalies)
- Configuration Management (Gestion des configurations)
- Accounting Management (Gestion des consommations)
- Performance Management (Gestion de la performance)
- Security Management (Gestion de la sécurité)
Ce modèle couvre tous les domaines transversaux nécessaires à une administration complète d’une infrastructure en réseau. L'architecture TMN est constituée des 5 couches horizontales suivantes :
- BML - Business Management Layer (Couche de gestion des affaires)Couche application orienté métier et assurant le retour sur les investissements, parts de marché, satisfaction des employés, objectifs communautaires et gouvernementaux.
- SML - Service Management Layer (Couche de gestion des services)Gestion des services offerts aux clients et aux utilisateurs internes, fourniture de qualité et de niveau de service, gestion des couts et des délais de commercialisation
- NML - Network Management Layer (Couche de gestion du réseau) Gestion des réseaux et des systèmes qui délivre les services des couches supérieures, dimensionnement des équipements, gestion des congestions
- EML - Element Management Layer (Couche de gestion des éléments) Gestion des éléments qui composent les réseaux et les systèmes
- NEL - Network Element Layer (Couche de gestion des équipements réseaux) Commutateurs et routeurs, équipement de transmission, de distribution
Produits
La société LUTEUS, éditeur du logiciel LoriotPro propose les produits suivant :
- LoriotPro Free Edition (Gratuiciel limité à 10 adresses IP)
- LoriotPro Lite Edition (version commerciale, limitée à 100 adresses IP)
- LoriotPro Standard Edition (version commerciale, sans limite d’adresses IP)
- LoriotPro Extended Edition (version commerciale, sans limite d’adresses IP, automation par script LUA)
- LoriotPro Broadcast Edition (version commerciale, sans limite d’adresses IP, automation par script LUA, collecte SNMP temps réel)
- Syslog Collector (version commerciale)
- SMS Manager (version commerciale
Principales fonctionnalités
Le logiciel LoriotPro est architecturé autour de 7 fonctions majeures
- La découverte intelligente de l'infrastructure du réseau et des équipements connectés et l’enrichissement et le maintient d’un annuaire des ressources ainsi découvertes.
- La Surveillance de la disponibilité et des performances des indicateurs critiques de performance et de disponibilité
- L’affichage dynamique des statuts des équipements surveillés par tableaux de bord, des cartes et des synoptiques.
- La génération de graphiques de charge de l’utilisation des ressources en temps réel et en tendance
- L’envoi d’alarmes et de notifications par message sonore, par E-Mail, par SMS, GPIO
- L’archivage des historiques d’anomalies et la génération de rapports d’utilisation
- L’automatisation de toutes les fonctions précédentes: la découverte, la surveillance, les visuels dynamiques, les alarmes, les rapports.
Découverte de l'infrastructure du réseau
L’étape préliminaire pour mettre en place la surveillance d’une infrastructure réseau ou système consiste à enrichir un annuaire ou une base de données des équipements et des ressources présentes. Avec le logiciel LoriotPro, la découverte est automatisée dans un processus fonctionnant en tâche de fond qui signale tout nouvel équipement se raccordant au réseau. De nombreuses options de paramétrage permettent un contrôle fin de la manière dont la découverte est réalisée. La découverte utilise les protocoles au standard IP tels TCP, SNMP et ICMP PING, pour enrichir de manière exhaustive l’annuaire interne du produit.
Le processus de découverte se comporte comme un système expert dédié à l’identification des équipements connectés au réseau. Il réalise de façon autonome un balayage des réseaux disponibles, découvre les équipements IP, puis les analyse pour déterminer leurs fonctions (Routeur, Serveur, stations, imprimante, etc). Les machines découvertes sont ajoutées à l'annuaire de LoriotPro avec une configuration automatique de surveillance. Dans les éditions commerciales, un système expert basé sur des stratégies de découverte applicables individuellement à chaque système pour une analyse avancée de leur configuration matérielle et logicielle. Les stratégies de découverte sont basées sur des scripts LUA et peuvent être facilement étendues par les utilisateurs en fonctions de leurs besoins et du type d'équipement à découvrir.
Surveillance de la disponibilité et des performances
La surveillance périodique consiste à mettre en place des processus en boucle réalisant des requêtes sur les équipements ou les applications pour s’assurer qu’ils sont disponibles et opérationnels. Ce type de surveillance repose sur plusieurs programmes internes au logiciel en fonction des objectifs: vérification de disponibilité pas simple Ping ou requêtes avancées (SNMP, HTTP, SQL etc.) vers un serveur et ses applications.
Pour le contrôle de la disponibilité simple des équipements IP, LoriotPro dispose d’un processus d'interrogation asynchrone (polling) qui génère des requêtes Ping ou SNMP à intervalles réguliers vers les équipements présents dans l'annuaire. Grâce à ce processus, le logiciel informe en permanence l’administrateur de la réelle disponibilité des équipements connectés au réseau par le truchement de l’environnement graphique et par les alarmes. Dans le GUI, les icônes dans l’annuaire reflètent leur statut par leur couleur ainsi que dans les cartes de topologie réseau et dans le centre de santé (Health Control Center).
Pour la surveillance d’application réseau ou de tout type d’applications présentes dans un équipement, l’utilisation d’Audits dédiés à chaque cas est nécessaire. Ces Audits sont des programmes en script LUA qui peuvent être créés et modifiés à volonté. Les Audits sont gérés par un moteur dédié qui assigne des Thread d’exécution à discrétion, ce qui permet d’exploiter les fonctionnalités Multithreading du système d’exploitation Windows™ et de garantir le traitement de plusieurs milliers de collectes.
Affichage dynamique
La cartographie de réseau est un moyen incontournable dans le domaine de la supervision pour afficher des informations sur le statut de fonctionnement du réseau, des équipements qui y sont raccordés et des applications disponibles sur ces mêmes équipements.
La terminologie utilisée dans LoriotPro pour désigner ces visuels est (Active View) que l’on traduit en Visuel Dynamique. Ces visuels sont adaptés à la représentation de cartes de topologie réseau, vues symboliques d’états et synoptiques, d’équipements informatiques, de cartes géographiques de cartes d’implantation. Le contenu des visuels, la couleur des éléments graphiques, les textes, etc. peuvent évoluer dynamiquement en fonction de valeurs collectées et indiquer ainsi à l’administrateur les changements d’état dans son infrastructure. Les Active View sont construites de toutes pièces ou à partir de modèles avec un éditeur dédié. Cet éditeur dispose d'outils graphiques de dessin ainsi que l’accès à la bibliothèque de dessins clipart ou d’images. Les Active View contiennent des objets graphiques, dont les caractéristiques : position, contenu, couleur, taille, dépendent d'une expression conditionnelle. Cette expression est capable d'évaluer par exemple:
- la disponibilité d’un équipement Ping IP ou TCP,
- des valeurs collectées par SNMP (température, une charge CPU, etc.),
- des compteurs d’erreurs,
- des compteurs d'événement reçus ou filtrés
- des compteurs de Trap SNMP filtrés
- les charges en % d'interface réseau
- des scripts LUA.
Les objets graphiques d’une Active View ont une propriété de couleur de fond modifiable par l’utilisation d’expressions logiques booléennes. Les expressions conditionnelles attachées aux objets graphiques sont aussi capables de générer des évènements et des alarmes afin de déclencher des actions diverses, alarmes sonores, envoi d’e-mail. Les objets d’une Active View disposent d’une action sur double clic de souris et d’un menu contextuel extensible. Les scripts LUA sont aussi utilisables pour contrôler l’aspect des objets ainsi que leur position dans les vues.
Graphiques de charge et temps de réponse
Le logiciel peut réaliser des collectes et l’affichage de graphes en temps réel ou en tendance. Ces graphes peuvent représenter des variations de charge ou d'utilisation de ressources réseau et systèmes (trafic réseau, erreurs, utilisation, CPU, disque, files d'attente, etc.). Quand un réseau est découvert, le logiciel positionne par défaut des graphes de charge en tendance sur toutes les interfaces réseau des routeurs. L'affichage en tendance montre une vue synthétique de l'évolution de charge sur une période d'un an. Quatre graphiques MRTG sont produits systématiquement.
- Les graphiques journaliers affichent la tendance des 24 dernières heures avec des intervalles de 5 min.
- Les graphiques hebdomadaires affichent la tendance de la dernière semaine avec des intervalles de 30 min.
- Les graphiques mensuels affichent la tendance du dernier mois avec des intervalles de 2 heures.
- Les graphiques annuels affichent la tendance de la dernière année avec des intervalles de 24 heures.
D’autres modules de génération de graphes sont aussi disponibles, le module RRD Collector pour la collecte des données, le stockage en base RRD et leur visualisation, le module RRD Manager pour la manipulation avancée des bases RRD et leur maintenance. Les graphiques sont entièrement paramétrables à partir d'une interface graphique Windows™. Ils permettent de suivre l'évolution d'un ou plusieurs indicateurs SNMP, de temps de réponse PING d'un ou plusieurs hosts distants, et de valeurs issues de l'exécution de script LUA.
Alarmes et notifications
La gestion d’évènement permet de mettre en place des filtres et des actions sur seuil. La supervision est chargée de collecter des variables SNMP sur les équipements et de les comparer à des seuils critiques nécessitant le déclenchement d’une action, par exemple l’envoi d’un SMS, à un administrateur ou l'exécution d'un programme ou d'un script.
Le logiciel supporte 3 types de messages d'alerte ou de notification.
- Les évènements propriétaires, appelés « Events ». Ils sont générés par LoriotPro en interne, par les modules (plugins), par un autre LoriotPro, par un produit tiers ou par des scripts LUA.
- Les Traps SNMP V1 et Notifications V2c ou V3 émis par les équipements du réseau intégrant le support de SNMP (authentifiées ou non en fonction du profil de l'équipement émetteur).
- Les messages Syslog (RFC3164). Le logiciel intègre un serveur Syslog capable de recevoir les messages Syslog envoyés par les systèmes Unix/Linux, les routeurs, les firewalls. Les messages Syslog reçus sont filtrables en fonction de diverses conditions. Les filtres satisfaits déclenchent des actions immédiates pour alerter l’administrateur de défauts de fonctionnement ou de tentatives d’intrusion.
Deux outils de génération d’évènements et de TRAP SNMP permettent, une fois les filtres définis, de vérifier leur bon fonctionnement en simulant des alarmes.
Historiques et rapports
Le logiciel conserve des historiques de toutes les alarmes dans des fichiers journaliers. Un navigateur des fichiers d’historique des évènements reçus (Event Message Browser) permet de visualiser les évènements reçus et d’effectuer des recherches par critères. Les critères de recherche offrent la recherche par fourchette de dates, ou pour une date donnée, par fichier individuellement, par numéro d’événement, par sévérité d’événement, par adresse source, par nom d’équipement, etc. Un outil similaire est disponible pour les fichiers d’historique des messages syslog. La génération de rapport est en format WEB et directement accessible à partir de l’interface WEB du produit.
Automatisation et extension
L'environnement de développement de script intégré au logiciel permet d’écrire des applications dédiées à la supervision et à l’audit des ressources d’un système d’information. Les applications aident à automatiser des tâches d’administration fastidieuses et récurrentes. Le logiciel utilise le langage de script Open Source LUA complété de centaines de fonctions dédiées à la supervision : fonctions du protocole SNMP, fonctions de cartographie et de création symbolique dans les Active View, fonctions de corrélation d’évènements et d’alarmes. Un environnement graphique de développement (LSDE) de dispose des fonctions nécessaires pour écrire, modifier, debugger et tester les programmes de scripts LUA. Le langage de script est aussi supporté par le serveur WEB intégré au produit ce qui permet de développer des pages dynamiques en mode WEB avec les standards HTML/CSS/JAVASCRIPT du marché.
Annuaire des ressources
L’annuaire est une base de données interne au logiciel où sont déclarés les équipements et systèmes IP présents dans l’infrastructure réseau. Il permet de classer hiérarchiquement les ressources dans la logique la mieux adaptée à l’activité et à l’organisation de l’administrateur.
L'annuaire est constitué d'objets de type :
- country: un conteneur définissant un pays
- organization: un conteneur définissant une organisation, une entreprise
- organization unit: un conteneur définissant un département, une structure, un ensemble d'éléments
- network: un conteneur définissant un réseau IP ou un sous-réseau IP avec son masque associé
- host: un objet définissant un équipement ou un système par une de ses adresses IP
- alias: un objet lié à un autre objet de l'annuaire
L'annuaire est dynamique, car il affiche en permanence le statut de connectivité entre le manager SNMP et les équipements connectés au réseau en IP.
Cinq couleurs distinctes sont utilisées pour cela :
- Violet: l’équipement/système n'est pas surveillé
- Bleu: l’équipement/système répond aux interrogations de type IP Ping (ICMP echo request and ICMP echo reply)
- vert: l’équipement/système répond aux requêtes SNMP (l'objet sysname)
- Jaune: l’équipement/système ne répond pas temporairement aux requêtes IP Ping et SNMP
- Rouge: l’équipement/système ne répond plus aux requêtes IP Ping et SNMP
Un outil de recherche permet de sélectionner un objet dans l’annuaire. Les critères disponibles sont: nom, adresse IP, adresse MAC ainsi que trois variables personnalisables (par exemple un numéro de prise ou de local).
Sur les éléments d'annuaire de type host, il est possible d’attacher un ou plusieurs modules de collecte (voir Directory Plugins).
L’ajout d’éléments dans l’annuaire peut être manuel ou automatique. Le programme de découverte réseau, le programme IP scanner, le Plugin TraceRoute ou des applications en script LUA peuvent peupler l’annuaire automatiquement.
L’annuaire est accessible aussi à partir de l’interface WEB.
Interrogation asynchrone (Polling)
Le service de base que le logiciel procure est une information permanente sur l’état de la connexion IP des équipements au réseau. Pour cela, un processus interne du logiciel (Polling process) assure l’interrogation programmée à intervalles réguliers des équipements et systèmes déclarés dans l'annuaire. Le processus d’interrogation génère des requêtes simples en SNMP ou par ICMP (Ping IP).
L’administrateur est informé des pertes de connexion par des visuels et des statuts de couleur, mais aussi par les évènements générant des alarmes diverses (sonore, email, etc.). Les états de couleur sont modifiés en respectant la logique de l’organigramme ci-joint.
Le logiciel utilise une méthode d'interrogation asynchrone. L’envoi des requêtes et la prise en compte des réponses sont assurés par des processus distincts. L’interrogation de milliers d’adresses IP peut être réalisée de façon massivement parallèle et en quelques millisecondes. Les temps de réponse correspondant au délai entre les requêtes et les réponses constaté par le logiciel, sont conservés.
Attention, les temps de réponse ou RTT (Round Trip Time) ne permettent pas avec certitude de déduire l’origine de ceux-ci (voir schéma ci-dessous sur le RTT).
De nombreux paramètres sont ajustables pour le contrôle des interrogations, parmi lesquels :
- Période d’interrogation de chaque équipement (Suivant les éditions intervalle entre 1 et 15 secondes minimum)
- Mode d’interrogation : Ping, SNMP ou les deux
- Interrogation conditionnée par la connexion d’un autre équipement (cascade)
- Alarme sur état ou changement d’état
- Arrêt en période de maintenance
Gestion des MIB
Le logiciel intègre la gestion des MIB nativement au sein des tous ses composants et modules. La MIB (Management Information Base) est une base de données interne au logiciel qui contient l’ensemble des objets qui peuvent être demandés à un agent SNMP par un manager SNMP. Cette base est construite à la mise en service du logiciel par compilation de fichier de MIB.
Un fichier de MIB (format texte) contient des définitions d’objets utilisant le langage ASN1. Le document RFC 1155 définit les règles d’écriture en SMI V1 d’un fichier de MIB et le document RFC 1213 contient la définition des objets minimum à implémenter dans un agent. Les objets de MIB sont organisés hiérarchiquement dans une structure d’arbre et en respect des standards RFC (Request For Comments). Il existe actuellement deux versions possibles pour l’écriture des MIB, la version SMI V1 et la version SMI V2 (Structure of Management Information). Il existe aussi des MIB propriétaires attachées à la branche « private » de l’arbre, réservées pour les entreprises et organisations souhaitant concevoir leur agent SNMP.
Dans le logiciel, la manipulation des objets de MIB se fait par l’intermédiaire de l’arbre des MIB (MIB tree) qui est disponible dans l’interface graphique ou comme assistant au sein des modules logiciels. Les objets peuvent être appelés par leur nom ou par leur OID. Les OID identifient de manière unique un objet par rapport à la racine de l’arbre des MIB. Ils sont utilisés pour la construction des paquets SNMP échangés entre le manager et l’agent.
L’ajout de nouveaux objets de MIB dans la base est réalisé par l’intermédiaire du programme de compilation (MIB Compiler). Celui-ci insère dans l’arbre des MIB les nouveaux objets présents dans les fichiers.
L’arbre des MIB peut être parcouru pour générer des requêtes SNMP vers un agent (SNMP WALK). Parcourir l’arbre consiste à interroger successivement tous les objets présents dans une branche sélectionnée en incluant toutes les branches filles. Le programme SNMP WALKER réalise cette tâche et permet ainsi l'identification des MIB supportées.
Les noms des nœuds de l'arbre des MIB peuvent être affichés soit:
- en utilisant le nom de l'objet seul (exemple : sysname)
- en utilisant son numéro d'OID et son nom (exemple : (0005) sysname )
- en utilisant le nom de sa MIB et son nom (exemple : RFC1213-MIB:sysname)
- en utilisant les trois modes (exemple : (0005) RFC1213-MIB:sysname)
Les objets de MIB propriétaire dont le nom est dupliqué par rapport à un objet de MIB standard ou à un autre objet de MIB propriétaire sont détectés et ajoutés sous la forme de nom complet (MibDescription:NomObjet). Le menu contextuel des objets offre un accès direct aux fonctions de graphique de GET et SET SNMP, d'affichage des tables, d'affichage de la description de l'objet dans sa MIB, etc.
Composants logiciels
Les modules enfichables (Plugins) sont des librairies de fonctions liées dynamiquement (DLL Windows™) chacun contenant des jeux de fonctions leur permettant de communiquer avec les composants internes du logiciel comme l’annuaire par exemple. Les Plugins peuvent s’exécuter en occurrences multiples, ils utilisent des threads distincts participant ainsi aux traitements multitâches. On distingue trois types de Plugins :
- Direct Plugins : utilisés pour réaliser des tâches ponctuelles sur des équipements ou systèmes
- Directory Plugins : Utilisés pour réaliser des tâches récurrentes (polling) sur des équipements situés dans l'annuaire
- Service Plugins : Utilisé pour fournir des services génériques et communs (Serveur WEB, envoi d'E-Mail, envoie de SMS, , etc.)
Liste des Plugins
Modules directs (Direct Plugins)
- Active View Box: Affichage virtuelle de commutateurs et de routeurs
- MRTG Style Graphic: Graphique temporel de charge en tendance
- LoriotPro Style Graph: Graphique temporel de charge en temps réel
Modules d'annuaire (Directory Plugins)
- Advanced TCP/Audit polling: Surveillance de la disponibilité et de la performance d’applications en réseau par TCP et par script LUA
- Active View: Cartographie dynamique pour la représentation de topologie réseau, de vues symboliques, de synoptiques, etc.
- Bulk Threshold Control: Surveillance en masse de valeurs SNMP avec envoi d'alarmes sur seuil
- Bulk TCP Polling: Surveillance en masse de serveurs d'applications réseau par TCP avec envoi d'alarmes sur état
- Cisco ISDN Call History: Collecte de l'historique des appels au standard RNIS sur équipements Cisco
- Cisco Configuration Surveyor: Surveillance des configurations d'équipements Cisco) avec envoi d'alarmes sur changement de configuration
- Network Interface Monitor: Mesure d'utilisation d'interfaces réseaux, graphique de charge et alarme sur seuil d'utilisation
- Process Surveyor: Surveillance des statuts des processus sur les ssystèmes Windows&trade,Linux,Unix
- RRD Collector: Générateur de graphique en tendance avec RRD
- SLA Report Center: Contrôle de la qualité de service, disponibilité et performance - SLA Report Center
- Spanning Tree Monitor: Représentation graphique de l'arbre de Spanning Tree de commutateurs Ethernet ou de Bridges 802.1d
- RMON GUI: Affiche des compteurs et des statistiques de trafics réseau Ethernet et TCP/IP par RMON V1 et RMON V2.
- SNMP Table Auditor: Audit et représentation visuelle des évolutions des variables SNMP dans les tables SNMP
- Trend View: Graphique d'utilisation en tendance et collecte de variable SNMP avec MRTG
Modules de service (Service Plugins)
- HTTP Server: Serveur WEB pour les accès console à distance par le protocole HTTP
- Email event scheduler: gestionnaire d'envoi des mails générés par les filtres d'évènements et de TRAP SNMP
- SMS Dispatch Manager: gstionnaire d'envoi et de reception de SMS, multidestinataires avec escalade et acquitement et contrôle à distance
- RRD Manager: Gestionnaire des bases et des graphiques RRD - A utiliser avec RRD Collector
- Inter Network Path: Calculateur de chemin de routage IP
- MIB Object Description: Affiche l'arbre des MIB et leur description
- Netbios Name Resolver: Resolution des adresses IP en nom Netbios Windows™
- Netflow Collector: Collecteur de flux Netflow Cisco en base SQL)
- Trap Simulator: Simulateur de TRAP SNMP V1 et notification SNMP v2c
- SNMP OID Cache: Gestionnaire de cache d'objets SNMP
- Statistic Dashboard: Affiche les charges réseaux des flux SNMP, EVENTS, TRAP, SYSLOG
- Syslog Collector Manager: Gestionnaire des politiques des agents Syslog Collector
- Text To Speech: Convertisseur texte en voix (TTS) pour les alarmes
- Transparent window manager: Gestionnaire de la transparence des fenêtres
- User Task: Contrôle d'accès console par utilisateur
- Advanced Trace Route: TraceRoute graphique avec valeurs en tendance
- Cisco ISDN call statistics: Statistiques sur les durées d'appels RNIS sur équipements Cisco
- Dynamic DNS To IP: Gestionnaires des adresses IP dynamiques
- Event Trap Script Queue Manager: Gestionnaire de file d'attente des scripts LUA
- Event Correlator: Corrélateur d'évènements et d'alarmes
L'environnement de développement LUA
Le logiciel intègre le langage open source LUA et le complète par des dizaines de fonctions dédiées à la supervision et d'un éditeur d'application en LUA. LUA est un language de programmation interprété (scripts). Le langage de programmation LUA existe depuis 1993 et fait l’objet d’un nombre important de communications. Comme tout langage de programmation, le langage LUA dispose nativement de nombreuses fonctions nécessaires aux développements d’applications génériques. Les fonctionnalités natives ont été étendues par l’ajout de fonctions spécifiques à la gestion et à la supervision de systèmes d’information. On distingue:
- Echange avec les équipements SNMP du système d’information. Lecture ou écriture (GET,SET) de variables uniques ou de tables complètes dans les modes supportés SNMPv1, V2c, V3. Par ailleurs, des fonctions particulières aux environnements de commutation en Multi VLAN viennent compléter les requêtes SNMP courantes.
- Gestion de l’annuaire LoriotPro, accès aux objets de l’annuaire, lecture ou écriture de leurs attributs. Création d’objets dans l’annuaire et création des processus d’interrogation attachés aux hosts (polling)
- Accès aux objets de la base des MIB
- Manipulation des Global Object de la base de donnée interne pour le stokage des collectes et leur corrélation
- Gestion graphique des objets d’Active View. Modification de leur couleur et de leur position en fonction des valeurs de retour du script LUA.
- Conversions pour le support de valeurs SNMP 64 bits
- Accès et contrôle des compteurs d’événements, de filtres d’événements et de filtre de Trap SNMP.
- Accès aux modules complémentaires (plugin) de LoriotPro pour en assurer le contrôle ou pour échanger de l’information.
- Accès à l’information de disponibilité et de performance (SLA) pour la génération de rapports personnalisé de qualité de service.
- Envoi de messages événement, de message SYSLOG ou de Trap SNMP vers LoriotPro ou vers d’autre station de management du réseau.
- Accès aux assistants graphiques de LoriotPro, sélection d’objet ou de table SNMP, sélection de numéro d’événement, d’objets dans l’annuaire, de sélection de valeur texte.
- Accès aux serveurs WEB en mode HTTP ou HTTPS.
- Accès aux outils LoriotPro (plugin direct).
- Génération de document en format WEB html.
- Manipulation des unités de temps et de période, conversion des valeurs SNMP de type sysuptime.
Domaines d’applications
Personnalisation du processus de découverte du réseau et analyse des ressources par des routines en script LUA. Par exemple : identifier une application installée, les unités de disques présentes, les versions des logiciels et du matériel, les types d’interface réseau, etc. Les systèmes et équipements découverts peuvent être ajoutés à l’annuaire interne du logiciel et les paramètres de leur configuration assigné. Par l’auto-configuration à la découverte, les processus de surveillance complémentaires (Plugins) sont mis en place lors de celle-ci.
Manipulation des objets graphiques des Active View. L’aspect dynamique des objets, leurs caractéristiques (couleur, texte, position etc.) peuvent être contrôlées par programmation. Cela permet de réaliser des visualisations dynamiques d’équipements, de reconnaissance et de construction automatique de carte réseaux et de visuels systèmes, des cartes de géo positionnement de mobiles, etc. Le contenu graphique d’une Active View peut être créé dynamiquement à l’ouverture de celle-ci par un script LUA.
Exécution de script sur réception de Trap SNMP. Les équipements et logiciels ont la capacité d’envoyer des alarmes de disfonctionnement (Trap et notification SNMP) vers le NMS. Les Trap SNMP informent d’un changement d’état, à titre d’exemple le (link down) prévient d’une perte de lien d’une interface réseau. Le système de collecte et de filtres intercepte les Trap et déclenche le lancement d’un programme script. Dans le cas du trap « link down » le programme de script peut par exemple réaliser des vérifications complémentaires auprès de l’équipement en défaut, s’assurer de l’état réel de l’interface réseau, tenter une réactivation et notifier l’administrateur en cas d’échec.
Collecte des compteurs d’événements et des compteurs des filtres. L’accès aux compteurs d’événement et de filtres satisfaits par des fonctions LUA permet d’écrire des programmes de corrélation et d’analyse. L’incrément en cascade d’une série de compteurs d’événements peut être utilisé pour déterminer l’origine (root cause) réel d’un dysfonctionnement d’un service.
Génération d’alarmes ou de notification par envoi d’événement, de syslog ou de Trap SNMP. Le logiciel s’intègre dans un système distribué d’administration réseau utilisant des produits de marques différentes. Les dysfonctionnements détectés peuvent générer par l’intermédiaire de script LUA des envois de messages respectant les standards SYSLOG ou de TRAP SNMP. Les événements (EVENT) étant propriétaires à cet environnement, ils ne peuvent être envoyés que vers une autre plateforme de management.
Audits de fonctionnement, audit de parc ciblés en fonction du type de l’équipement ou système à auditer. Des scripts d’audit peuvent être attachés aux différents systèmes et équipements pour la réalisation d’audit d’état de fonctionnement ou d’audit de parc. Les audits sont exécuté sur action de l’administrateur ou à intervalle programmé. Les audits de fonctionnement ont pour objectif par exemple d’analyser l’ensemble du parc de serveurs pour recenser les unités de disques, leur statuts de fonctionnement, leurs taux de charge et d’occupation. Au cas où des valeurs de seuil sont dépassées, les alertes sont envoyées vers les administrateurs. Les audits de fonctionnement peuvent être aussi utilisés pour le contrôle d’environnement, vérifier l’état de charge des batteries d’onduleurs, les températures des salles informatiques, les niveaux de toner dans les imprimantes, etc. Les audits d’états ou de parc ont pour objectif le recensement des ressources d’un système d’information et l’identification de celle-ci pour la génération de rapport au format WEB. Les audits sont réalisés à la demande et disposent ainsi d’une information à jour issue de collectes en temps réel réalisées par SNMP lors de la génération du rapport. Ceux-ci permettent par exemple d’avoir un état des versions matérielles et logicielles d’un parc de commutateurs Ethernet, obtenir la liste des logiciels installés sur des stations Windows, connaitre le nombre d’utilisateurs connectés sur une application, etc.
Développement d'objets de MIB virtuels. Les objets de MIB virtuels apportent à l’ensemble des modules Plugin, un accès direct à des routines de script LUA. Les routines de script sont accédées par l’intermédiaire d’objets de MIB déclarés dans des fichiers de MIB créé à cette fin.
Collecte et traitement de multiples variables SNMP. Un jeu de fonctions LUA sont dédié à la collecte SNMP et permettent toutes les manipulations mathématiques de celles-ci et plus particulièrement les compteurs 64 bits disponibles en SNMP. Ces compteurs sont entre autres utilisés pour les mesures de trafics sur les interfaces réseaux à haut débit (Giga bits).
Éditeur de script LUA
Le développement de programmes quel que soit le langage est facilité par l’environnement de développement. L’éditeur de script LUA du logiciel intègre les fonctionnalités suivantes :
- Éditeur graphique et contextuel avec coloration syntaxique.
- Numérotation et indentation des lignes de code
- Interpréteur avec localisation des erreurs de syntaxe.
- Aides contextuelles (Wizards) pour la sélection d’adresses IP, d’objet de MIB, etc.
- Fenêtre de simulation d’ActiveView
- Exécution pas à pas
- Point d’arrêt pour la recherche d’erreurs de codage (Debug).
- Complétion des syntaxes de fonction
- Recherche et remplacement
- Aide en ligne intégré au format CHM
Exemple de code en LUA
Voici un exemple de code LUA avec appel à des fonctions propriétaires à l'environnement LoriotPro. Ces fonctions sont préfixées de "lp."
LUA est un langage extensible, les fonctions propriétaires LUA sont en règle générale des fonctions C++ encapsulées (Wrapper).
<source lang="lua"> -- Ce programme balaye l'ensemble des équipements du réseau, identifie les équipements SNMP, collecte leur nom par SNMP, affiche l'adresse IP et le nom HostIP = lp.GetFirstIP(); -- Obtient l'adresse IP du premier Host de l'annuaire if HostIP ~= nil then
while HostIP ~= nil do -- tant qu'il y a des Hosts dans l'annuaire, on les traite
oknok = lp.GetIPInformation(HostIP,'HostInfos') -- On collecte les paramètres de configuration et d'état de ce Host dans une table
if oknok ~= nil then
if HostInfos.status == 2 then -- Si le Host répond en SNMP (statut vert dans l'annuaire)
oknok,sysName = lp.Get(HostIP,"sysName") -- Collecte de données SNMP sur le Host)
lp.Trace(HostIP,"/",sysName,"\n") -- On affiche les données
HostIP =lp.GetNextIP(HostIP )-- On sélectionne le Host suivant de l'annuaire
end
end
end
end </source>
Liens externes
- Site officiel LoriotPro
- dvbmon.com - Luteus
Article publié sur Wikimonde Plus
Portail des réseaux informatiques 
Portail de l’informatique 
Portail des télécommunications 
Portail du logiciel