lua logoLoriotPro WEB site Documentation scripting LoriotPro
Extensions du language LUA

Table des matières    Liste de fonctions

Imprimer la page en cours Mail this  link UTUBE Channel

Supervision temps réel des infrastructures de Broadcast

Principes et mise en œuvre

Introduction

Une fonctionnalité innovante a été ajoutée au logiciel de supervision LoriotPro en juin 2012. Celle-ci   permet d’augmenter considérablement la performance des collectes SNMP et d’accroitre le rafraichissement de l’affichage des données et ceci sur des volumes important. Le nombre de collecte peut croitre, les délais de traitement des collectes peuvent augmenter, la capacité et la rapidité de traitement et d’affichage restera optimum. Le traitement parallèle (multithreading) des nombreuses tâches ainsi réalisées permet de monter en charge par l’ajout de nouveaux processus de traitement des collectes et éventuellement de plus de processeur dans le système.

RegieMonitoring.pngWAN simulation and Global object in LoriotPro

Grâce à la nouvelle architecture de LoriotPro des centaines de collecte SNMP peuvent être envisagées avec des périodes de l’ordre de la seconde, de même, les visuels (Active View) peuvent atteindre des fréquences de rafraichissement de cet ordre.

Il est donc désormais possible d’avoir des visuels Active View extrêmement dynamique pouvant vous alerter dans des délais très court d’un dysfonctionnement de votre régie de diffusion ou de votre système d’information.

Le concept technique

Pour rappel, Les collectes de données sur les équipements du système à superviser sont principalement réalisées grâce au protocole SNMP. Ce protocole permet de récupérer des indicateurs d’état et de performance grâce à des agents SNMP présents sur les équipements et systèmes. Les délais de réponse des agents à des requêtes sont assez imprévisibles, on ne peut donc prévoir réellement le temps qu’un processus de collecte de LoriotPro mettra pour obtenir une réponse. Chaque processus de collecte dispose d’une limite maximum d’attente (appelée Timeout) au-delà de laquelle il considère que l’agent ne répond pas. Si un processus unique est chargé de ces collectes qu’il réalise donc séquentiellement la performance peut ne pas être au rendez-vous sachant  qu’une centaine de collectes peut prendre de quelques secondes à quelques minutes.

Résumons le contexte : Nous savons que les collectes que nous appelons « tâches » ont des durées d’exécution très aléatoires pouvant aller de quelques millisecondes à plusieurs secondes. Par ailleurs nous souhaitons 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.

Principe mise en œuvre : Toutes les tâches (collectes) à réaliser sont regroupées au sein d’un programme unique. Celui-ci détaille pour chaque tâche le type de collecte à réaliser (GET SNMP sur un objet de MIB).  Pour l’exemple nous utilisons des objets SNMP mais d’autre type de collecte peuvent être faîtes, extrait de fichiers de log, requête sur des bases SQL, lecture de compteurs de TRAP, etc. A noter que les collectes peuvent provenir des variables globales déjà en mémoire, ce qui permet de traiter par corrélation.

Pour réaliser ces tâches, un nombre variable de processus peuvent y être attaché. 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écessaire (Plugin Audit Process de LoriotPro) pour assumer un traitement quasi parallèle.

Pour simplifier la configuration, un processus d'Audit (902) est fourni. Un ou plusieurs Audit peuvent être responsable du traitement des objets globaux qui sont définis dans un même groupe.

Audit Process for a Group of Objects

Voici un exemple simplifié avec deux processus en charge 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 job, ils parcourent la liste des collectes à faire et s’attribue la première dont la période d’interrogation (polling) est échue et qui n’est pas déjà attribuée.

Concept of Global Object of LoriotPro

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 un  bloc de variables globales directement en mémoire. Ces variables sont accessibles de partout au sein de LoriotPro et plus particulièrement au sein d’un visuel d’Active View.

Les composantes de l’architecture

Les composantes de l’architecture sont présentées dans le schéma ci-dessous

structure des processus de collecte de variable globales LUA

D’un coté les équipements sur lesquels les collectes sont faits, de l’autre un visuel   qui doit refléter le plus rapidement possible un ou des statuts de ces équipements.

Les processus de collecte (Audit Process) sont en recherche permanente de collectes à réaliser qu’ils prennent dans une sorte de « job liste ». La job liste est une liste des collectes à réaliser et qui décrit par programmation comment les réaliser. Les processus de collecte enregistrent les valeurs collectées sur les équipements mais pas seulement (Cf corrélation) en mémoire dans la variables globales correspondantes.

Les ActiveView de leur coté ont leur processus de collecte dédié et viennent chercher en fonction d’un intervalle de collecte positionné sur chaque objet graphique, les valeurs des variables globales. En fonction des valeurs, les objets graphiques sont modifiés (couleur de fond, texte, position, clipart, etc .) pour avertir l’administrateur d’un changement d’état.

Corrélation de variables

Nous utilisons le terme corrélation pour identifier une variable résultante d’un traitement de plusieurs autres variables. Il y a plusieurs niveaux de corrélation possibles dans la solution.

 La corrélation peut être réalisée par le processus de collecte en collectant séquentiellement plusieurs indicateurs SNMP par exemple, en les corrélant ensuite puis en stockant le résultat de cette corrélation dans une variable globale.

L’autre option consiste à reprendre des variables globales issues de collecte SNMP unitaires puis à les corréler pour stocker le résultat dans une autre variable globale.

La combinaison des deux options est aussi possible.

Le processus de corrélation est une tâche similaire à une tâche de collecte et vient s’inscrire dans la Job Liste. Contrairement à une collecte, le traitement est extrêmement rapide car il manipule des variables en mémoire et n’intègre pas de temps d’accès ou de traitement par des équipements distants.

Structure du programme de collecte

Le programme de collecte est multi-instance car il peut être exécuté simultanément par de nombreux processus d’audit (multi-tâche). Pour que chaque variable globale soit manipulée à un instant donné par un seul processus de collecte, un système de verrou est en place sur chacune d’elles. L’organigramme ci-dessous simplifié, reprend la logique du code. En premier les variables globales manipulées sont vérifiées une à une. Si elles n’existent pas elles sont alors initialisées avec les valeurs imposées.

Ensuite pour chaque variable le processus d’audit vérifie si un verrou est présent,  si c’est le cas il passe à la variable suivante de la liste sinon il pose un verrou sur celle-ci. Le verrou interdit de suite la manipulation de la variable par un autre processus. Le programme importe la variable (une structure) pour la manipuler. Il vérifie ensuite l’intervalle d’interrogation de cette variable, si celui-ci est échu il procède à la collecte de la valeur auprès de l’équipement (si SNMP). La variable est mise à jour puis le verrou libérée.

Le processus d’audit qui balaye la liste des jobs s’accapare ainsi tous les jobs dont les variables ne sont pas verrouillées.

logique de collecte

Les variables globales sont des structures contenant plusieurs informations.

En voici le détail

nom de la variable Description

name

Un nom qui doit être unique dans la liste et qui permet d’identifier facilement la variable.

string

La valeur de la variable quand celle-ci est une chaine de caractères

double

La valeur de la variable quand celle-ci est numérique

interval

De préférence utilisable pour définir l’intervalle de temps entre chaque collecte

time

La date et l’heure  à la seconde de la dernière mise à jour des variables double et string. Celle-ci est mise à jour automatiquement par LoriotPro. Valeur à 32 bits de type timestamp

clock

L'horloge système  à la milliseconde de la dernière mise à jour des variables double et string. Celle-ci est mise à jour automatiquement par LoriotPro. Valeur à 32 bits

param1

Paramètre utilisable par le processus de collecte, par exemple un objet SNMP, une adresse IP etc …

param2

Idem Param1, paramètre utilisable par le processus de collecte

Exemple de mise en œuvre.

Dans l’exemple de mise en œuvre, nous avons une Active View qui doit afficher les statuts de trois équipements et un élément de corrélation de ces trois statuts.

Trois couleurs sont retenues pour les statuts : normal/vert, majeur/orange, critique/rouge.

Classiquement la corrélation héritera de la couleur la plus critique d’un des trois équipements

La première étape consiste à créer le programme que devront exécuter les processus de collecte et de corrélation (audit process).

Pour créer un nouveau programme de collecte, sélectionnez dans LoriotPro par le menu l’option « Tools » l’option « Script Editor ».

Sauvegarder le programme script LUA sous un nouveau nom dans le répertoire proposé par défaut /bin/config/script/

La première partie du programme consiste pour chaque variable à en vérifier l’existence et si nécessaire à les initialiser.

Exemple de code pour l’initialisation de la variable Globale GlobVar1.

if (lp.isValue("GlobVar1"))==nil then

            lp.SetValueParam1("GlobVar1","ifoperstatus.6");

            lp.SetValueParam2("GlobVar1","10.1.0.252");

            lp.SetValueInterval("GlobVar1",5);

end

La function LUA  lp.isValue() vérifie l’existence de la variable (ici GlobVar1) en mémoire.

Si celle-ci n’existe pas on la crée et on initialise son contenu. Une variable Globale est une structure telle que définie précédemment. Param1 et Parma2 sont utilisés pour renseigner ici dans l’exemple, un nom d’objet SNMP et une adresse IP de host sur lequel faire la collecte de cet objet SNMP.

Les fonctions lp.SetValueParam1() et lp.SetValueParam2() permettent d’écrire dans ces champs de la structure GlobVar1.

Ensuite on initialise la période d’interrogation de la variable (polling period) par lp.SetValueInterval  à 5 secondes.

On répète cette structure de code pour les deux autres variables de collecte SNMP, GlobVar2 et GlobVar3.

A noter que la variable GlobVar4 qui est le résultat d’une corrélation reçoit les noms des autres variables comme valeur de Param2.

Les variables existants ayant étés initialisés, on peut ajouter le code pour les collectes. A chaque variable globale on associe une portion de code ayant une structure précise comme indiquée dans l’organigramme présenté dans le chapitre « Structure des programme de collecte ».

Voici la structure de code pour la variable GlobVar1.

if(lp.TriggerValueLock("GlobVar1")==1) then

       if(lp.StatusOfValue("GlobVar1","GlobVar1")) then --récup le tableau

            if (os.time()-GlobVar1.time>=GlobVar1.interval) then – si l'intervalle de polling est échu

                  val,buffer=lp.Get(GlobVar1.param2,GlobVar1.param1);

                  if val then

                   --traitement du job      pose les valeurs dans les variables globales

                   --un commentaire dans string et une valeur de status dans double           

                                        lp.SetValueString("GlobVar1",buffer);

                                     if (buffer=="") then

                                                         lp.SetValueDouble("GlobVar1",4));

                                   elseif 1 then --defaut

                                                        lp.SetValueDouble("GlobVar1",2);

                                   end

                  else

                              lp.SetValueDouble("GlobVar1",4);

                  end

            lp.Print(lp.GetValueString("GlobVar1"),"\n");           

            end

      end     

lp.SetValueLock("GlobVar1",0); --libére la value

end

Décomposons la structure de ce morceau de programme LUA.

On trouve en premier un test sur la Variable Globale.

lp.TriggerValueLock(…) – Cette fonction permet de savoir si une Variable Globale est verrouillée, de la verrouiller ou de la déverrouiller. Si la variable est verrouillée on quitte cette portion de code sans autre action.

 lp.StatusOfValue(…) -  Cette fonction récupère dans une table LUA, le contenu de la variable pour la manipuler dans le code par la suite. La première variable est le nom de la variable Globale, la seconde le nom de la variable dans le code LUA. Les noms peuvent être différents mais pour faciliter la lecture nous avons conservé le même (GlobVar1).

On vérifie ensuite par cette ligne de code si l’intervalle de temps de collecte pour cette Variable est échu, Si c’est le cas on va procéder à une nouvelle collecte.

            if (os.time()-GlobVar1.time>=GlobVar1.interval) then

On réalise ensuite la collecte proprement dite. Ce code est fonction de ce que l’on souhaite collecter. Dans notre exemple nous collectons une variable SNMP (objet de MIB) sur un équipement. La variable SNMP à collecter a été préalablement mémorisée comme valeur de Param1 dans la variable globale GlobVar1.

La fonction lp.Get permet de retrouver sur un host un objet de MIB unique.

val,buffer=lp.Get(GlobVar1.param2,GlobVar1.param1);

Si on remplace les variables par leur valeur on obtient une requête SNMP simple  :

val,buffer=lp.Get("10.1.0.254","ifoperstatus.6");

En retour de la collecte on dispose d’une valeur de type double « val » et d’une valeur de type chaine de caractère dans « buffer ».

Il faut effectivement connaitre les valeurs renvoyées par l’objet de MIB pour pouvoir coder la suite.

Nous avons extrait à cette fin  la description de l’objet présenté par LoriotPro. Pour l’obtenir, il faut sélectionner l’objet dans l’arbre des MIB puis par le menu contextuel prendre l’option « show object properties ».

Object Name          : [ ifOperStatus ]

Children of Object   : [ ifEntry ]

From MIB Description : [ IF-MIB ]

Registered in File   : [ IF-MIB-200006140000Z-rfc2863.mib ]

MIB File Directory   : [ C:\LORIOT~3\LO6D6E~1\bin/mibs/0_MIB_KERNEL ]

The File is loaded

---------------------------------------------------------------

Father Indexed By    :

                       [ IfIndex,INTEGER(6) ]

---------------------------------------------------------------

SYNTAX : [6] INTEGER,(INTEGER)

 INTEGER Sequence    :

                       [ up(1)]

                       [ down(2)]

                       [ testing(3)]

                       [ unknown(4)]

                       [ dormant(5)]

                       [ notPresent(6)]

                       [ lowerLayerDown(7)]

La connaissance des valeurs retournées sera indispensable ensuite pour la configuration de l’objet graphique du visuel ActiveView. Ici les valeurs peuvent être : up, down, testing, unknown, dormant, notPresent, lowerlayerdown.

Le buffer peut être simplement enregistré dans la Variable Globale  avec la commande :

lp.SetValueString("GlobVar1",buffer);

De la même manière, on enregistre des valeurs de statut par :

lp.SetValueDouble("GlobVar1",4);

Cette valeur pourra être utilisée si besoin dans l’ActiveView pour afficher un autre niveau de statut.

Ce même code peut être utilisé pour les autres Variables à collecter, GlobVar2 et GlobVar 3.

La variable globale GlobVar4 doit être traitée différemment puisqu’elle représente une corrélation des trois autres.

Par conception nous avons défini que :

GlobVar4 pourra avoir 3 valeurs numériques différentes :

1 : correspondant à l’état « UP » simultané des trois interfaces surveillées

2 : si un au moins des objets collectés ne répond pas au requêtes SNMP, valeur « error »

3 : dans tous les autres cas et principalement celui de la valeur  « down »

Le code de collecte et assignement de GlobVar4

                  state="1";

                  if (lp.GetValueString("GlobVar1")=="error") then state="2"

                                               elseif (lp.GetValueString("GlobVar1")~="up") then state="3"

                                               end

                  if (lp.GetValueString("GlobVar2")=="error") then state="2"

                                               elseif (lp.GetValueString("GlobVar2")~="up") then state="3"

                                               end

                  if (lp.GetValueString("GlobVar3")=="error") then state="2"

                                      elseif (lp.GetValueString("GlobVar3")~="up") then state="3"

                                               end                

                  lp.SetValueDouble("GlobVar4",state);

 Dans ce mode la Variable GlobVar4 reflétera toujours le plus mauvais état d’une des autres variables.

Le bon fonctionnement du programme peut être testé directement depuis par le menu de l’éditeur de script par la touche F5.

En cas d’anomalie dans le code les erreurs sont retournées directement dans la fenêtre de sortie ainsi que sous forme de message dans l’onglet SYSLOG.

Si vous n’avez pas d’erreur vous pouvez vérifier l’état de vos variables globales à partir de l’option Insert -> Insert Global Variable du menu de l’éditeur de script LUA de LoriotPro.

On constate que les trois collecte on bien renvoyé la valeur up et que la corrélation est bien à 1

La configuration de l’ActiveView peut commencer à ce stade.

Reportez vous à la documentation de LoriotPro chapitre Active View (menu Help) pour  les notions basiques consistant à insérer une nouvelle Active View dans l’annuaire, puis pour insérer des objets graphiques dans le visuel.

Une Active View possède des propriétés permettant de définir la fréquence de mise à jour des objets graphiques, (leur couleur de fond) ainsi que la fréquence de collecte des valeurs associées à ces objets. Pour un objectif de performance la mise à jour des objets graphique du visuel est contrôlée par un processus distinct de celui en charge de l’exécution des collectes (définie par une expression) de chaque objet.

On distingue donc deux paramètres important pour modifier les périodes de mise à jour et de collecte :

Refresh MAP Every : Intervalle de temps entre deux rafraichissement de tous les objets graphiques, les règles de colorisation sont balayées et la couleur ou la position de l’objet changés.

En fonction de l’édition de LoriotPro les valeurs minimales sont différentes :

LoriotPro Broadcast édition : 40 ms

LoriotPro FREE, LITE, STANDARD, EXTENDED, édition : 15 secondes

Run Thread Every : Intervalle de balayage des objets pour l’exécution de leur expression de collecte de la valeur associé à cet objet.

En fonction de l’édition de LoriotPro les valeurs minimales sont différentes :

LoriotPro Broadcast Edition : 40 ms

LoriotPro FREE,LITE,STANDARD,EXTENDED : 5 secondes

Pour modifier ces valeurs, dans le menu de l’Active View, sélectionner Edit puis ActiveView Options

Par principe, on choisira des valeurs légèrement inférieures à la fréquence de collecte la plus basse des processus d’audit (objet intervalle des Variables Globales).

Etape de configuration des objets graphiques correspondant à notre variable globale GlobVar1.

On sélectionne l’objet dans la vue et on appelle les « properties» par un click droit.

On sélectionne ensuite l’onglet Dynamic Aspect pour configurer l’objet.

On coche la case Activate Dynamic Aspect.

On sélectionne une période de collecte pour cet objet, 1 secondes dans notre exemple.

On sélectionne l’option Get Global Variable du menu déroulant.

Dans la liste on sélectionne GlobVar1

Ensuite on insère les règles de coloriage de l’objet en fonction de la valeur retournée par la variable globale et qui est dans ce cas les mêmes valeurs que  ce que retourne la requête SNMP sur l’objet de MIB ifoperstatus

Dans la seconde qui suit sa configuration l’objet prend la couleur verte correspondant à la valeur de la Variable Globale.

On répète le même principe de configuration pour les variables GlobVar2 et GlobVar3.

Pour la variable GlobVar4 il faut prendre en compte les valeur de retour (1,2,3) uniquement.

Attention, comme nous devons lire la valeur numérique de la variable la syntaxe de l’expression est légèrement différente

Nous disposons maintenant d’un visuel complet :

En déconnectant les ports ou en forçant les variables directement dans le Script, il est possible de vérifier le bon fonctionnement du visuel. Dans le visuel suivant on constate que la variable GlobVar3 impose son statut à la variable GlobaVar4.

Ajout des processus de collecte

Pour finaliser notre mise œuvre il faut maintenant ajouter les processus de collecte (Audit Process). Il faut au moins un processus de collecte d’actif pour avoir une collecte périodique des données. Ensuite le nombre de processus de collecte à ajouter et qui exécuteront ce même programme doit être évalué en fonction du nombre de collecte, de la durée d’exécution de chaque collecte et de la fréquence de collecte.

 

Un processus de collecte exécute simplement à intervalle régulier le programme de script LUA que nous avons créé précédemment. La fréquence d’exécution  doit être inférieure à la fréquence de polling la plus faible des variables globales.

Pour ajouter un processus (Audit Process), sélectionner dans l’annuaire l’objet LoriotPro, appeler le menu contextuel (click droit).Sélectionner « Insert Task » puis « Advanced TCP/Audit Polling ».

Une alternative consiste à sélectionner l’objet LoriotPro dans l’annuaire et ensuit appeler l’écran de Propriété.

La fenêtre de configuration est affichée.

Sélectionner « Audit Process » comme « Polling Type ».

Sélectionner la fréquence d’exécution (1 secondes)

S’assurer que la case « Enable Process » est cochée.

Dans la zone « Audit Process » sélectionner pour Audit ref la valeur 901. Ou utiliser le Wizard pour le sélectionner.

Dans le champ « Parameter », entrer le nom du fichier du programme de script créé dans les phases précédentes.

Les programmes de scripts sont situés dans le répertoire /bin/config/script/ de LoriotPro

Quitter par « OK », le processus s’exécute de suite

Contrôle de fonctionnement

Plusieurs outils existent pour contrôler le bon fonctionnement des processus de collecte (Audit process).

Une fenêtre est dédiée au contrôle de l’exécution. Elle est accessible par le menu principal, option « Configure » puis option « Audit Process ». Cette fenêtre permet aussi d’arrêter tous les processus d’audit actif.

Au sein de l’ActiveView, il est possible d’avoir un état de tous les objets dynamiques.

A partir du Menu de l’ActiveView, sélectionner l’option « Help », puis « Statistique ».

Un processus interne de l’Active View balaye chaque objet graphique séquentiellement pour le mettre à jour en fonction du résultat de son expression, ce qui détermine un temps X de traitement cyclique. L’option   Run Thread Every  définit simplement le temps entre chaque séquence de mise à jour. Ce paramètre ne définit pas le temps de traitement de l’AV mais juste le délai entre deux séquences de traitements (cycle). Si un objet doit être traité toute les 4s et que ce paramètre est configuré à 40ms, cela ne changera pas l’intervalle de collecte de 4s associé à l’objet de l’AV. Si un autre objet de la même séquence prend 5s pour être traité, l’objet avec un intervalle de 4s sera traité au mieux toute les 5s plus le délai configuré. La durée de traitement d’une séquence est égale à la somme des temps de traitement de l’ensemble des objets actifs d’une AV.  Le réglage des Timers peut être facilement réalisé en utilisant l’option du menu help/statistics. L’usage des variables globales dans une AV  permet de réduire le temps de traitement d’une séquence d’AV car le traitement est réalisé à l’extérieur et de façon massivement multitâches.  Une séquence composée d’une centaine de variables Globales sera traitée en 10-20ms ce qui est inférieur à 40ms.

Conclusion

Les visuels Active View de notre solution de supervision LoriotPro pour la réalisation de Map dynamique, de diagrammes et synoptiques fonctionnels et/ou technique, de schémas d’implantation, réagissent rapidement à un changement d’état de votre infrastructure réseau, de production ou de diffusion. Grâce à ce concept technique puissant que sont les Variables Globales en mémoire,  des centaines d’indicateurs de performance, SNMP entre autres,  peuvent être surveillés dans des cycles extrêmement courts de quelques centaines de millisecondes.


www.loriotpro.com