|
|
Manuel de l'administrateur | Table des matières |
|
|
Utilisation de Global Objects et de LUA dans les vues actives (Active View)
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.
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.
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 Global Objects 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.
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.
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 Global Objects 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 sont présentées dans le schéma ci-dessous
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 Global Objects 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 Global Objects. 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.
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 Global Object.
L’autre option consiste à reprendre des Global Objects issues de collecte SNMP unitaires puis à les corréler pour stocker le résultat dans une autre Global Object.
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.
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 Global Object 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 Global Objects 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.
Les Global Objects 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 |
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 Global Object 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 Global Object 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 Global Object 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 Global Object.
lp.TriggerValueLock(…) – Cette fonction permet de savoir si une Global Object 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 Global Object, 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 Global Object 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 Global Object 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 Global Object 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 Global Objects à 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 Global Objects).
Etape de configuration des objets graphiques correspondant à notre Global Object 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 Global Object 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 Global Object.
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.
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 Global Objects.
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
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 ».
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.
|
