FR2802663A1 - Procede de correlation d'alarmes dans un systeme d'administration hierarchisee - Google Patents

Abstract

Le procédé illustré est mis en oeuvre dans un système (10) d'administration hiérarchisée d'au moins une ressource, le système d'administration comprenant au moins un gestionnaire (17a) recevant (en 70) d'objets de la ressource des premières alarmes initiales (80) et incorporant des moyens de corrélation (63) générateurs de premières alarmes corrélées (81) incluant une marque distinctive des premières alarmes initiales, au moins un supra-gestionnaire (17b) recevant des secondes alarmes initiales (80) issues d'objets d'au moins la ressource (18c) et des premières alarmes corrélées (81) issues d'au moins ledit gestionnaire et incorporant des moyens de corrélation (63) générateurs de secondes alarmes corrélées (82) distinctives des secondes alarmes initiales, et des moyens (90) pour modifier la marque des premières alarmes corrélées (81) pour être traitées dans le supra-gestionnaire comme les secondes alarmes initiales.

Description

<Desc/Clms Page number 1>

Titre.

Procédé de corrélation d'alarmes dans un système d'administration hiérarchisée.

Description.

Domaine technique.

L'invention se rapporte à la corrélation d'alarmes dans un système d'administration hiérarchisée. Les alarmes sont issues d'au moins une ressource quelconque, matérielle et/ou logicielle. La ressource qui sera prise comme exemple dans la description qui suit est une ressource informatique pouvant être tout ou partie d'un système informatique, telle qu'une machine d'un système informatique, un réseau informatique et/ou une application en cours d'exécution dans le système. Les alarmes sont représentatives d'états de fonctionnement dans la ressource, les états étant déterminés notamment à partir de dysfonctionnements détectés dans la ressource. Elles peuvent ou non être normalisées, telles que celles correspondant à la norme ISO destinées à l'administration.

L'invention a pour objets un procédé de corrélation d'alarmes dans un système d'administration hiérarchisée, un système d'administration hiérarchisée mettant en #uvre ce précédé et un système incluant une ressource gérée par le système d'administration hiérarchisée.

L'art antérieur.

Dans un système d'administration hiérarchisée ou non, les alarmes sont enregistrées dans un journal d'alarmes. Un utilisateur administrateur du système dispose ordinairement d'applications d'administration spécifiques pour être averti de l'arrivée d'une alarme, consulter les alarmes du journal et les gérer en fonction de leur origine et leur gravité, notamment. Une corrélation d'alarmes est une option avantageuse qui synthétise les alarmes reçues pour fournir à l'administrateur une information précise et rapidement utilisable. Notamment, la corrélation inclut un filtrage sophistiqué des alarmes reçues, la suppression des alarmes

<Desc/Clms Page number 2>

répétitives et une combinaison complexe entre les alarmes. Elle fournit à l'administrateur une information synthétique et organisée, identifiant la cause et la gravité d'un problème et suggérant des actions correctrices. Dans un système d'administration hiérarchisée, les alarmes corrélées dans un gestionnaire subordonné à au moins un gestionnaire de niveau supérieur, appelé supra-gestionnaire, sont de préférence transmises au (x) gestionnaire (s) y être corrélées. Les corrélations successivement faites dans la hiérarchie des gestionnaires donnent une vue synthétique de plus en plus globale des ressources gérées et traduisent mieux l'importance des problèmes.

La corrélation successive d'alarmes dans un système d'administration hiérarchisée est le suivant. Le système d'administration comprend au moins un gestionnaire recevant d'au moins une ressource des premières alarmes initiales et les corrélant pour former des premières alarmes corrélées incluant une marque distinctive des premières alarmes initiales, et au moins un supra-gestionnaire recevant des secondes alarmes initiales issues d'au moins une ressource et des premières alarmes corrélées, jointes optionnellement à des premières alarmes initiales, issues d'au moins ledit gestionnaire et les corrélant pour former des secondes alarmes corrélées distinctives des secondes alarmes initiales. Dans le cas où les premières alarmes initiales sont conformes à la norme ISO, la marque est incluse dans un attribut, relatif au type d'événement et nommé "eventType", de chaque alarme. L'attribut "eventType" a une valeur désignant le type de l'alarme. Cet attribut est de type identifieur d'objet "ObjectIdentifier", signifiant que sa valeur est globalement unique et s'exprime sous une forme décimale pointée, par exemple sous la forme "2.9.3.2.10.2". La marque est souvent faite d'un mot accolé à la valeur de l'attribut et de préférence suggestif d'une corrélation pour un administrateur. La marque correspond à un nouvel identifieur d'objet "eventType" unique. Par exemple, si une alarme se rapporte à une erreur de traitement détectée dans la ressource, la valeur normalisée de l'alarme initiale est "ProcessingErrorAlarm" et la marque est ordinairement "correlated", de sorte que les premières alarmes corrélées correspondantes

<Desc/Clms Page number 3>

auront la valeur "correlatedProcessingErrorAlarm". La distinction entre les alarmes initiales et les alarmes corrélées est nécessaire pour éviter tout bouclage qui rendrait les alarmes corrélées inexploitables.

Le supra-gestionnaire reçoit ces alarmes corrélées, mais aussi des secondes alarmes initiales issues d'au moins une ressource gérée par le supra-gestionnaire et pouvant être différente ou non de celle (s) gestionnaire. Dans le cas le plus courant d'une administration normalisée, les secondes alarmes initiales ont les mêmes attributs "eventType" que ceux des premières alarmes initiales. Dans les autres cas spécifiques, elles peuvent avoir des attributs différents, mais ne pouvant évidemment pas être confondues avec des alarmes corrélées. Par conséquent, le supra-gestionnaire ne peut pas corréler les secondes alarmes initiales avec les premières alarmes corrélées issues d'au moins un gestionnaire.

La solution courante part du postulat général que les alarmes corrélées doivent être distinctives des alarmes initiales. Les alarmes corrélées reçues par le supra-gestionnaire sont donc considérées comme des alarmes initiales, de sorte que les secondes alarmes initiales reçues par le supragestionnaire sont modifiées pour être mises au niveau des alarmes corrélées reçues. Selon l'exemple précité, la valeur initiale normalisée "ProcessingErrorAlarm" des secondes alarmes initiales est donc modifiée pour correspondre à celle des premières alarmes corrélées. La corrélation dans le supra-gestionnaire consiste donc à distinguer encore les alarmes reçues des alarmes corrélées en y incluant une autre marque. Par exemple, la marque peut être faite du mot "Bis" pour suggérer une seconde corrélation, de telle sorte que les alarmes corrélées produites par le supra-gestionnaire auront la valeur "correlatedProcessingErrorAlarmBis" de façon qu'elles soient associées à un nouvel identifieur d'objet "eventType" unique et différent.

Cette solution présente deux principaux inconvénients. D'une part, il faut modifier les services et les applications d'administration qui traitent des alarmes dans le supra-gestionnaire, de façon qu'ils reconnaissent les alarmes reçues et les alarmes corrélées. Les alarmes normalisées définissant cinq valeurs pour l'attribut "eventType", la modification doit

<Desc/Clms Page number 4>

porter sur les cinq valeurs des alarmes reçues et les cinq valeurs des alarmes corrélées. Cette modification entraîne un long et coûteux travail, qui doit être repris à chaque nouvelle version conçue pour tout gestionnaire et introduite dans le supra-gestionnaire. D'autre part, une corrélation à un niveau hiérarchique supérieur nécessite la modification des alarmes initiales reçues par le supra-gestionnaire correspondant et l'inclusion d'une marque supplémentaire. Une hiérarchie à au moins trois niveaux est courante, par exemple départemental, régional et national, continental, mondial. Par conséquent, les modifications faites à un niveau supra-gestionnaire sont différentes de celles à faire sur un autre niveau supra-gestionnaire. Par conséquent, les services et les applications d'administration à un niveau de supra-gestionnaire sont propres à celui-ci et ne sont pas interchangeables avec ceux d'un supra-gestionnaire de niveau supérieur. Il en est de même pour l'interface et ses paramètres de configuration dans le supra-gestionnaire avec un supra-gestionnaire de niveau supérieur puisque à chaque niveau l'interface est à l'écoute d'alarmes corrélées ayant des attributs "eventType" propres à ce niveau. En pratique, à cause de toutes ces difficultés, la corrélation est ordinairement limitée deux ou trois niveaux. En outre, une vue synthétique globale ne peut être obtenue qu'à ces niveaux, ce qui peut avoir de graves répercussions sur l'administration générale de tout un grand système de ressources.

Sommaire de l'invention.

Un premier but de l'invention est de présenter un procédé de corrélation d'alarmes permettant de réduire au minimum possible les modifications à faire dans chaque niveau hiérarchique d'administration. Ce but offre l'avantage de réduire fortement le coût de la corrélation.

Un second but est de rendre répétitif le procédé de corrélation d'alarmes à chaque niveau hiérarchique. Ce but offre l'avantage de rendre les alarmes corrélées interchangeables entre niveaux hiérarchiques successifs et de pouvoir obtenir ainsi au moindre coût, cumulé avec l'avantage précédent, une synthèse à tous les niveaux hiérarchiques.

<Desc/Clms Page number 5>

L'invention a pour objet un procédé de corrélation d'alarmes dans un système d'administration hiérarchisée d'au moins une ressource, le système d'administration comprenant au moins un gestionnaire recevant d'objets d'au moins ladite ressource des premières alarmes initiales et les corrélant pour former des premières alarmes corrélées incluant une marque distinctive des premières alarmes initiales, et au moins un supra-gestionnaire recevant des secondes alarmes initiales issues d'objets d'au moins ladite ressource et des premières alarmes corrélées issues d'au moins ledit gestionnaire et les corrélant pour former des secondes alarmes corrélées distinctives des secondes alarmes initiales, caractérisé en ce qu'il comprend la modification de la marque des premières alarmes corrélées pour être traitées dans le supra-gestionnaire comme les secondes alarmes initiales.

L'invention a pour premier objet corollaire un système d'administration hiérarchisée d'au moins une ressource, le système d'administration comprenant au moins un gestionnaire recevant d'objets d'au moins ladite ressource des premières alarmes initiales et incorporant des moyens de corrélation générateurs de premières alarmes corrélées incluant une marque distinctive des premières alarmes initiales, et au moins un supra-gestionnaire recevant des secondes alarmes initiales issues d'objets d'au moins ladite ressource et des premières alarmes corrélées issues d'au moins ledit gestionnaire et incorporant des moyens de corrélation générateurs de secondes alarmes corrélées distinctives des secondes alarmes initiales, caractérisé en ce qu'il comprend des moyens pour modifier la marque conformément au procédé défini précédemment.

L'invention a pour second objet corollaire un système, tel qu'un système informatique, incluant au moins une ressource gérée par un système d'administration hiérarchisée tel que défini précédemment.

Présentation des dessins.

# La figure 1 est une vue synoptique d'un exemple de système d'administration hiérarchisée d'au moins une ressource, en l'occurrence un système informatique, le système d'administration incluant un gestionnaire

<Desc/Clms Page number 6>

et un supra-gestionnaire qui mettent en #uvre un procédé conforme à l'invention de corrélation d'alarmes issues du système informatique.

# La figure 2 est une vue synoptique détaillée d'un exemple de structure d'une plate-forme d'administration présente dans le gestionnaire du système d'administration représenté sur la figure 1, la figure 2 illustrant aussi sous forme synoptique les agents servant d'interfaces avec les ressources informatiques et illustrant seulement en un bloc le supragestionnaire, étant entendu que le supra-gestionnaire illustré présente une structure similaire à celle du gestionnaire, seule l'interface avec ses agents et avec le gestionnaire étant représentée.

# La figure 3 est une vue schématique et très partielle d'un arbre représentatif d'une base d'informations d'administration, dite base MIB (Management Information Base), relative aux objets gérés par le gestionnaire représenté sur les figures 1 et 2.

# La figure 4 est une vue synoptique d'un exemple de système d'administration hiérarchisée étendue à trois niveaux et incluant le gestionnaire et le supra-gestionnaire représentés sur les figures 1 et 2, la figure 4 illustrant par des flèches à double trait un exemple de hiérarchie verticale et par des flèches en trait gras et discontinu un exemple de hiérarchie horizontale.

# Et la figure 5 est une vue schématique d'un exemple de moyens mis en #uvre par le gestionnaire et le supra-gestionnaire représentés sur les figures 1,2 et 4 pour la corrélation d'alarmes et illustrant par des lettres entre parenthèses des étapes d'un exemple d'exécution du procédé conforme à l'invention.

Description détaillée d'exemples illustrant l'invention.

La figure 1 représente un système d'administration 10 d'un système informatique 11. L'exemple qui suit se rapporte au système d'administration et de sécurité connu sous le nom de marque déposée OpenMaster du demandeur. Sa conception est conforme aux normes ISO de l'administration de systèmes et réseaux. Dans ces conditions, les termes

<Desc/Clms Page number 7>

utilisés seront conformes à cette norme, qui sont de langue anglaise, notamment les sigles et acronymes. D'autre part, les verbes "administrer" et "gérer" et leurs dérivés qui seront employés ici traduisent tous deux indifféremment le verbe anglais "manage" et ses dérivés. L'homme du métier connaît bien ces normes. Compte tenu de leur masse informative, on ne donnera ici que les éléments nécessaires à la compréhension de l'invention.

Le système informatique illustré 11 est distribué et se compose de machines 12, en l'occurrence cinq machines 12a-12e, organisées en un ou plusieurs réseaux 13 correspondant à un ou plusieurs protocoles quelconques, de préférence dédiés à l'administration et normalisés. Dans l'exemple illustré, le réseau 13 comprend deux réseaux 13a et 13b. Le réseau 13a utilise le protocole SNMP (Simple Network Management Protocol). Le réseau 13b utilise le protocole CMIP (Common Management Information Protocol) reposant sur la norme ISO définissant des services pour le transfert des informations d'administration, appelés services CMIS (Common Management Information Services). Bien sûr, le réseau internet de la Toile pourrait aussi être utilisé avec, par exemple, le modèle normalisé CIM (Common Information Model) défini par le consortium DMTF (Desktop Management Task Force). Il n'existe pas encore de protocole normalisé pour le modèle CIM, le protocole pouvant par exemple être celui connu sous le nom DCOM (Distributed Component Object Model) de Microsoft.

Une machine est une unité conceptuelle très large, de nature matérielle et logicielle, pouvant être les moyens impliqués pour exécuter une application donnée, des moyens pour exécuter une fonction donnée, un ordinateur, ainsi qu'un système informatique dans une architecture à systèmes en cascade. Les machines 12 peuvent être donc très diverses, telles que stations de travail, serveurs, routeurs, machines spécialisées et passerelles entre réseaux.

Le système informatique 11 est ordinairement un système comprenant plusieurs processeurs 14, un processeur 14 étant par exemple illustré dans chaque machine 12, des moyens de mémoire 15 pour contenir les logiciels et les données du système, et des moyens d'entrée-sortie 16 servant

<Desc/Clms Page number 8>

pour la communication entre machines par l'intermédiaire du réseau 13, ainsi que pour une ou plusieurs communications extérieures, par exemple pour l'impression, la télécopie, etc. Un tel système peut par exemple gérer des données à distance, distribuer des données dans le cas d'un système de réservation, commander l'exécution de programmes à distance sur des machines spécialisées, partager localement des ressources physiques ou logicielles, et communiquer. Plus généralement, le système 11 se compose de ressources matérielles et/ou logicielles, réelles ou virtuelles, telles que machines, imprimantes, circuits virtuels, réseaux et applications. Le système d'administration 10 utilise au moins l'une de ces ressources selon une technologie orientée objets, bien connue de l'homme du métier.

Le système d'administration 10 choisi a une architecture de type client-serveur. La partie serveur gère et la partie cliente comprend la ou les ressources à gérer. Dans l'exemple illustré, la partie serveur comprend deux gestionnaires 17 (17a, 17b) inclus dans les machines respectives 12a et 12b, dites machines gestionnaires, tandis que la partie cliente comprend trois agents 18 (18a-18c) permettant l'accès aux ressources à gérer incluses dans les machines respectives 12c-12e, dites machines gérées. Les ressources gérées dans les machines 12c-12e sont identifiées sous forme d'objets organisés dans des sous-arbres respectifs 19 (19a-19c). Un gestionnaire 17 analyse et agit sur l'environnement à gérer. Il répond aux requêtes des utilisateurs en les envoyant à la ressource gérée concernée. Un agent 18 est une interface réactive affectée à un protocole donné de communication avec au moins un gestionnaire 17 par l'intermédiaire du réseau associé 13 (13a, 13b). Il attend et traite les requêtes qu'un gestionnaire lui adresse. Il gère et met à jour les données contenues dans le sous-arbre correspondant 19 de la machine gérée 12. D'autre part, une ressource peut émettre une réponse à une requête d'un gestionnaire. Cette réponse est transmise au gestionnaire par un agent. En outre, un objet géré dans une ressource peut émettre des notifications à un agent pour un gestionnaire. Selon la norme ISO, une notification est un message non sollicité par un gestionnaire. La norme définit un événement comme un type de notification, et une alarme comme un

<Desc/Clms Page number 9>

type d'événement. Pour des raisons de simplification de la description et des dessins, les trois machines gérées 12c-12e sont seulement pourvues de trois agents respectifs 18a-18c. Selon une option courante et avantageuse du système d'administration 10, un gestionnaire 17 gère aussi la machine gestionnaire 12 correspondante ou gère tout ou partie des machines gestionnaires. Cela peut se faire de façon similaire à celle illustrée, plus ou moins adaptée à cette option. L'exemple illustré offre le double avantage de faciliter la lecture des dessins tout en permettant à l'homme du métier de faire une généralisation du système décrit et illustré.

La figure 2 illustre la structure d'une plate-forme d'administration 30 du système d'administration 10. La plate-forme 30 peut être limitée à une machine gestionnaire ou être distribuée parmi plusieurs machines gestionnaires. Pour des raisons de commodité, la plate-forme illustrée dans la figure 2 sera limitée à la machine gestionnaire 12a et correspond ainsi au gestionnaire 17a. Le gestionnaire 17b illustré a une structure similaire à celle de la plate-forme 30 mais il a un rôle additionnel de servir de supra-gestionnaire pour le gestionnaire 17a. La plate-forme 30 se compose de deux ensembles 40 et 50. L'ensemble 40 contient un bloc 41 contenant un ensemble d'applications de base (core applications) 42 connectées à un tableau de bord 43. Les applications peuvent être écrites dans un ou plusieurs langages, le langage SML (System Management Language) étant le langage choisi dans la suite du texte et étant en pratique accompagné du langage Java dans la plate-forme OpenMaster du demandeur. Le tableau de bord 43 est classique et inclut une partie graphique et un lanceur de requêtes. Une station graphique 44, extérieure à la plate-forme 30, est connectée au tableau de bord 43 pour visualiser les applications, lancer les requêtes et visualiser les résultats contenus dans les réponses. Elle permet à un utilisateur de se connecter à la machine 12a pour démarrer et arrêter comme il le désire ses propres copies des applications 42.

L'ensemble 40 comporte des moyens 45 d'interface. L'ensemble 40 peut former une unité autonome délimitée par un trait fantôme et constitutive d'une station d'administration.

<Desc/Clms Page number 10>

Dans le cas où l'ensemble 40 constitue une station d'administration, l'ensemble 50 forme un serveur d'administration. Le serveur 50 utilise un seul protocole donné, ici le protocole CMIP. Il comprend quatre blocs fonctionnels : un bloc de communication 51 aussi appelé courtier CMIP ou distributeur de services CMIS (CMIS Dispatcher) ; un bloc 52 d'interface avec au moins un autre gestionnaire et/ou avec un supra- gestionnaire, en l'occurrence le supra-gestionnaire 17b au travers du réseau CMIP 13b, l'interface 52 étant aussi appelée interface SMI (Super-Manager Interface) ; un bloc 60 de services CMIS ; un bloc 70 d'interface de la plate- forme 30 avec les agents 18 des ressources gérées par la plate-forme. Le courtier 51 est connecté aux moyens d'interface 45 de la station 40, ainsi qu'au blocs 52,60 et 70 du serveur 50, pour traiter les requêtes et leurs réponses éventuelles, ainsi que les notifications en provenance des agents 18a et 18b. Le courtier 51 contient l'objet racine ROOT à laquelle sont attachés tous les objets gérés par la plate-forme 30. Le bloc 60 contient tous les services communs aux applications 42, notamment : une base CMIS-DB 61 de données CMIS ; un service 62 de schémas d'informations d'administration, appelé MISS (Management Information schéma Service) contenant les schémas, aussi dits classes ou modèles, des objets gérés par la plate-forme ; un service 63 de corrélation comprenant un service 64 de traitement des événements (Event Processor) connecté à un système expert 65 ; service 66 d'alarmes incorporant un journal 67 d'alarmes (Alarm Log) ; un service 68 de statistiques et performances utilisées pour les applications 42 de performances. Le bloc 70 illustré inclut deux interfaces 71a et 71b reliées respectivement aux agents 18a et 18b par l'intermédiaire des réseaux 13a et 13b et ordinairement nommées intégrateurs (d'agents) ou AI (Agent Integrators). Plusieurs ensembles d'agents 18a et 18b extérieurs à la plate- forme 30 sont illustrés pour indiquer qu'en pratique tout ou partie des agents peuvent gérer des objets distribués dans le système informatique et se trouver dans plusieurs machines 12 du système informatique 11, une machine pouvant incorporer plusieurs agents utilisant des protocoles différents.

<Desc/Clms Page number 11>

La figure 3 illustre de façon schématique et très partielle un exemple de structure d'une base MIB des objets gérés par la plate-forme 30 constituant le gestionnaire 17a du système d'administration 10 et représentatifs d'au moins une ressource du système informatique 11. Les ressources gérées sont converties en classes d'objets organisées hiérarchiquement dans une base d'informations d'administration MIB (Management Information Base). Cette base n'est pas une base de données proprement dite, mais est assimilable à un catalogue de caractéristiques puisqu'elle contient la description et le contenu de toutes les classes gérées par le système d'administration 10. Une classe est définie par des caractéristiques nommées attributs, tels qu'un nom d'un composant du système et un état d'impression. Un objet d'une classe est une instance de la classe. L'organisation des classes dans l'exemple choisi du système d'administration 10 est hiérarchique. On distingue entre l'arbre des classes, une classe étant définie en subordination à une ou plusieurs classes mères, et l'arbre des instances, une instance étant attachée à une ou plusieurs instances mères. L'arbre des classes est contenu dans le service MISS 62, tandis que l'arbre des instances est l'arbre correspondant à la base MIB telle que représentée sur la figure 3. Dans la base MIB, les objets sont divisés en classes d'objets gérés, dites classes MOC (Managed Object Class). Un objet géré est une vue abstraite, définie pour les besoins de la gestion, d'une ressource logique ou physique d'un système. Chaque classe MOC représente un type donné desdits moyens du système 11. À chaque classe MOC peuvent être attachées une ou plusieurs instances d'objets gérés, appelées instances MOI (Managed Object Instance) et représentant des occurrences actuelles desdits moyens.

Tous les objets de la base MIB dans la figure 3 sont placés sous la racine ROOT et sont répartis en sous-MIB. La racine ROOT est contenue dans le courtier 51 et les racines des sous-MIB sont appelées sous-racines (rootlets). La figure 3 illustre deux sous-MIB représentatives des deux machines gérées 12c et 12d par le gestionnaire 17a et correspondant aux deux sous-arbres respectifs 19a et 19b. Sous la racine ROOT de la base MIB est

<Desc/Clms Page number 12>

aussi attachée une sous-racine (non illustrée) pour chaque service du bloc 60. Dans ce bloc, le service CMIS-DB 61 fournit une base de données des objets gérés MOI destinée à leur persistance une fois que le gestionnaire a été mis hors fonctionnement. Il supporte toutes les classes MOC des services CMIS qui sont stockées localement dans une base de données. En outre, il fournit un ensemble de services ou fonctions de base, appelées aussi primitives, disponibles pour toutes les applications 42. Ces fonctions sont bien adaptées à la structure hiérarchique de la base MIB. Elles incluent notamment les fonctions : M-GET pour lire une ou plusieurs instances, M-SET pour mettre à jour une ou plusieurs instances, M-CREATE pour créer une instance, MACTION pour activer une opération spécifique sur une ou plusieurs instances et M-EVENT pour envoyer un événement. Le service CMIS-DB supporte aussi des notifications d'enrôlement et désenrôlement ENROL/DE-ENROL après une fonction M-CREATE/M-DELETE sur une sous-racine.

Une instance dans la base MIB a un nom distinctif relatif RDN (Relative Distinguished Name) sous forme d'une liste d'assertions sur valeur d'attribut appelées assertions AVA (Attribute Value Assertion). Chaque assertion AVA est un couple <attribut de nommage> <valeur>, l'attribut de nommage étant celui qui, dans la classe, permet l'identification unique d'une instance par rapport à son instance mère. Dans un gestionnaire 17a de l'exemple illustré, un nom RDN est composé d'une seule assertion AVA, donc d'un seul couple <attribut de nommage> <valeur>. D'une manière générale, il est cependant possible qu'un nom distinctif RDN ait plusieurs assertions AVA. Chaque instance dans la base MIB est identifiée de façon unique par son nom distinctif DN (Distinguished Name), qui est la suite des noms RDN sur le chemin entre la racine et l'instance dans l'arbre des instances. Un sousarbre d'une instance correspond à l'ensemble formé par l'instance elle-même et les instances qui lui sont subordonnées dans l'arbre des instances.

La figure 2 illustre aussi un exemple de configuration hiérarchique du système d'administration distribué 10. Selon cet exemple, le gestionnaire 17b a la même structure que celle du gestionnaire 17a. Il est donc suffisant pour la compréhension que le bloc 70 du gestionnaire 17b soit

<Desc/Clms Page number 13>

illustré, incorporant un intégrateur CMIP 71b similaire à celui du gestionnaire 17a. Le gestionnaire 17b gère directement ses propres objets dans le sous-arbre 19c (figure 1) par l'intermédiaire de l'intégrateur 71b et des agents CMIP 18c, plusieurs agents CIM 18c étant illustrés comme pour les agents 18a et 18b de la figure 2. En outre, le gestionnaire 17b a son intégrateur CMIP 71b connecté à l'interface SMI 52 du serveur CMIP 50 du gestionnaire 17a pour gérer aussi le gestionnaire 17a et est donc appelé supra-gestionnaire. Dans ce cas, le gestionnaire 17a est dit subordonné. Il ressort de la liaison par l'intégrateur 71b du supra-gestionnaire 17b qu'un supra-gestionnaire voit un subordonné comme un simple agent 18. Un supragestionnaire est aussi appelé "gestionnaire distant" par le gestionnaire subordonné.

La figure 4 est une vue synoptique du système d'administration distribué et hiérarchisé 10 incluant les deux gestionnaires 17a et 17b et étendu à quatre autres gestionnaires similaires 17c-17f. Seuls les blocs SMI 52 et les intégrateurs CMIP 71b sont impliqués dans la description qui suit et sont illustrés. La figure 4 illustre par des flèches à trait double une configuration hiérarchique de type vertical. Selon ce type, un supragestionnaire coordonne le travail d'un ou de gestionnaires ou supragestionnaires de niveau inférieur, appelés subordonnés, qui lui sont directement rattachés. Ainsi, le gestionnaire 17a est le subordonné du supragestionnaire 17b, qui est lui même subordonné au supra-gestionnaire 17c. De même, le gestionnaire 17f est le subordonné du supra-gestionnaire 17d, luimême subordonné au supra-gestionnaire 17c. Le gestionnaire 17e est le subordonné des deux supra-gestionnaires 17b et 17d, de sorte que, d'une manière générale, dans une telle hiérarchie, un utilisateur administrateur peut définir des domaines régionaux ou administratifs en répartissant la gestion de ces domaines entre différents administrateurs du système. Un domaine représente ici un sous-ensemble géré parmi l'ensemble des ressources selon une répartition géographique, organisationnelle, ou autre. A un niveau donné, un administrateur peut n'avoir à gérer qu'une partie limitée du domaine global, alors qu'à un plus haut niveau, un administrateur gérera

<Desc/Clms Page number 14>

plusieurs domaines, voire la totalité des domaines. De plus, il est possible d'appliquer des filtres au domaine géré par un subordonné. Cela permet à l'utilisateur administrateur d'un supra-gestionnaire de ne se consacrer qu'aux informations de gestion et aux tâches que l'administrateur juge utiles. La figure 4 illustre aussi par des flèches à trait épais et discontinu une configuration de type horizontal des gestionnaires, appelée aussi "peer-to-peer connection". L'intégrateur 71b de l'un des supra-gestionnaires peut être connecté au bloc SMI 52 de l'autre pour établir deux liaisons croisées du réseau CMIP 13a. Cependant, la liaison peut aussi être unidirectionnelle.

Selon ce type de configuration, une subordination existe entre supragestionnaires homologues, 17b et 17d dans l'exemple illustré. Par exemple, la subordination du supra-gestionnaire 17d au supra-gestionnaire 17b permet à ce dernier de gérer le supra-gestionnaire 17d et ses subordonnés 17e et 17f.

Chaque gestionnaire 17 a un service de traitement des événements reçus directement de ses agents respectifs 18 et, dans le cas d'un supra-gestionnaire, par l'intermédiaire de ou des interfaces SMI 52. Parmi les événements, deux types sont notamment impliqués dans l'exemple illustré, à savoir les alarmes pour le service 66 des alarmes et pour une application 42 d'alarme nommée Alarm dans OpenMaster, et les créations d'instances MOI de sous-racines d'objets gérés dans un sous-arbre 19. La plate-forme 30 utilise ce dernier type d'événement pour obtenir dynamiquement la connaissance de la base MIB qu'elle peut gérer. Ce type est appelé "ENROL" dans le produit OpenMaster de l'exemple illustré. Entre l'interface SMI et le supragestionnaire, il est traduit en une notification OSI nommée "objectCreation".

Il existe dans chaque interface SMI de l'exemple illustré une fonction de gestion des notifications d'événements conforme à la recommandation ISO [ISO IS 10164-5]. Elle permet de lancer, contrôler et arrêter le filtrage et la transmission des notifications d'événements. Cette fonction de gestion est représentée par la classe MOC "eventForwardingDiscriminator" (EFD). Les différents attributs de l'EFD spécifient les caractéristiques de la fonction de gestion des notifications d'événements. Ces caractéristiques sont notamment les suivantes :

<Desc/Clms Page number 15>

# l'attribut "discriminatorConstruct" définit les critères de filtrage des notifications d'événements.

# l'attribut "destinationAddress" est la liste des titres des entités d'application AET (Application Entity Title) auxquelles les notifications d'événements doivent être transmises.

# l'attribut "administrativeState" permet la suspension et la reprise du filtrage et de la transmission des notifications d'événements.

# l'attribut "startTime" spécifie la date et l'heure de lancement de l'EFD.

# l'attribut "stopTime" spécifie la date et l'heure d'arrêt de l'EFD.

# l'attribut "weekMask" définit un jeu de composants de masque spécifiant chacune des tranches horaires (sur la base d'une horloge de vingt-quatre heures) applicables à certains jours de la semaine. Cet attribut permet ainsi de configurer pour l'EFD une périodicité de fonctionnement d'une semaine.

# l'attribut "availabilityStatus" indique si l'EFD fonctionne ou non.

À chaque commande de la fonction de gestion des notifications d'événements correspond une opération CMIS effectuée sur une instance de la classe MOC "eventForwardingDiscriminator".

L'interface SMI 52 inclut une fonction constitutive d'un service de notification d'événements et une fonction de comptes rendus d'événements.

En s'abonnant au service de notification d'événements et en précisant les objets gérés autorisés à notifier leur création, un supra-gestionnaire 17 peut configurer dynamiquement les parties de la base MIB gérée par le gestionnaire subordonné qu'il veut voir, et indiquer celles qu'il veut ignorer.

Pour mettre en #uvre le service de notification d'événements, l'interface SMI 52 utilise la fonction de comptes rendus d'événements, qui est une fonction de gestion définie par la normalisation OSI. Elle commande le filtrage et la transmission des notifications. L'objet géré "eventForwardingDiscriminator" qui est mis en oeuvre dans ce but par l'interface SMI représente les abonnements du gestionnaire distant au service de notification d'événements, avec le filtrage à effectuer avant notification.

<Desc/Clms Page number 16>

Le filtrage est pris en charge par l'interface SMI dans l'exemple illustré. L'attribut "discriminatorConstruct" spécifie les critères de filtrage à appliquer pour éliminer certaines notifications d'événements. Un attribut "discriminatorConstruct" est un ensemble d'une ou plusieurs assertions sur la présence ou la valeur des attributs. Si le discriminant comporte plusieurs assertions, elles sont liées par des opérateurs logiques. La syntaxe ASN1 de l'attribut "discriminatorConstruct" est de type CMISFilter. L'attribut "discriminatorConstruct" peut comporter un test d'égalité ou d'inégalité des informations de notification d'événements et un test de présence des arguments de notification d'événements et la négation logique de n'importe laquelle de ces conditions. Il est possible de combiner ces conditions au moyen des opérateurs logiques AND ou OR. Un discriminant vide est toujours évalué vrai, quels que soient l'information et les paramètres d'événement. Outre le filtrage spécifié par les normes OSI, l'interface SMI de l'exemple illustré met en #uvre deux types de filtrage présentant des critères qui permettent de simplifier la configuration d'une hiérarchie de gestionnaires. Le premier type est un filtrage par sous-arbre. Pour recevoir les notifications de toutes les instances MOI appartenant au même sous-arbre 19, il est possible de ne spécifier que la sous-racine du sous-arbre dans l'attribut "discriminatorConstruct" en utilisant, comme assertion à évaluer, un opérateur logique "lessOrEqual" sur la sous-racine MOI du sous-arbre. Le second type est un filtrage par branche. Pour recevoir les notifications des seules instances MOI appartenant à une même branche d'un sous-arbre 19 d'instances d'objets gérés, il suffit de spécifier uniquement cette branche dans l'attribut "discriminatorConstruct" en utilisant, comme assertion à évaluer, un opérateur logique "GreaterOrEqual" sur l'instance MOI à l'extrémité de la branche.

Une interface SMI 52 de l'exemple illustré a, en bref, les fonctions suivantes. Elle gère les éléments d'association ACSE (Association Control Service Element) constitutifs du sous-ensemble de la couche n 7 du modèle OSI normalisé par l'ISO, pour fournir des services courants de mise en correspondance avec les gestionnaires distants. Elle gère aussi ses propres

<Desc/Clms Page number 17>

instances MOI des classes "system" et "eventForwardingDiscriminator". Elle traite les demandes d'opérations de gestion entrantes (M-CREATE, MDELETE, M-SET, M-GET, M-ACTION) en traduisant ces demandes pour le protocole interne du courtier 51, ici CMIP. Elle les transmet ensuite soit aux intégrateurs d'agents, soit aux services du bloc 60 qui sont liés localement à ce courtier, les demandes M-CANCEL-GET étant exécutées localement par l'interface SMI. Elle reçoit les confirmations d'opérations de gestion soit de la part des intégrateurs d'agents, soit de la part des services du bloc 60. Elle traduit ensuite ces confirmations pour le protocole OSI CMIP et les transmet au gestionnaire distant. Enfin, elle donne la possibilité de s'abonner à la notification de tous les événements détectés par les gestionnaires d'objets locaux. Elle accepte les notifications (M-EVENT-REPORT d'une alarme, ENROL, DE-ENROL, etc. ) en provenance soit des intégrateurs d'agents, soit des services du bloc 60 qui sont liés au même courtier qu'elle. Elle traduit ensuite ces notifications suivant le protocole OSI CMIP, les filtre au besoin, et les transmet au gestionnaire distant.

L'option d'utiliser le protocole CMIP offre l'avantage de mettre en #uvre les normes OSI de ce protocole CMIP pour assurer l'interopérabilité dans un environnement ouvert. L'interopérabilité entre une interface SMI et un gestionnaire distant est possible si ce dernier utilise les normes OSI : CMIP [ISO. IS 9596-1]) ; system management overview [ISO IS 10040] ; structure of management information [ISO IS 10165-1 et ISO. IS 10165-4] ; et system management functions [ISO IS 10164-1 et ISO IS 10164-5].

Cependant, certaines informations de gestion fournies par l'interface SMI peuvent ne pas être conformes à ces normes lors de l'écriture de ces informations, certains objets gérés ne présentant pas les caractéristiques OSI et restant inchangés quand ils sont transmis via l'interface SMI, qui n'est pas conçue pour mettre toutes ces informations au format OSI. Toutefois, sont conformes aux normes OSI les informations de gestion utilisées par l'interface SMI pour la hiérarchisation et les informations de gestion provenant d'un véritable agent OSI ou d'un gestionnaire d'objets OSI.

<Desc/Clms Page number 18>

Dans l'exemple illustré, un intégrateur AI CMIP 71b prend en charge les entités administratives OSI ayant le rôle d'agent. L'intégrateur CMIP effectue la traduction entre le protocole de gestion interne du serveur 50 et le protocole CMIP (couche supérieure de la pile de protocoles OSI). Ceci permet aux applications 42 de lancer des opérations de gestion sur les instances MOI appartenant aux agents administratifs OSI distants et de recevoir les notifications d'événement relatives aux objets gérés. Un intégrateur CMIP 71b peut avoir plusieurs fonctions. C'est un multiplexeur qui dialogue avec plusieurs agents CMIP 18. Il est responsable de l'établissement d'une association ACSE entre le serveur 50 et les agents CMIP 18. Il assure le routage des requêtes CMIS vers les agents CMIP concernés en analysant le nom distinctif des instances d'objets gérés désignés par ces demandes. Chaque fois qu'un des agents CMIP 18 crée une instance MOI constitutive d'un sous-racine possédée par l'agent, l'intégrateur envoie une notification au courtier 51 pour le routage des messages CMIS parmi les composants internes de la plate-forme 30.

La figure 5 est une vue schématique des moyens impliqués pour la gestion par le système d'administration 10 de dysfonctionnements dans le système informatique 11. Dans l'exemple illustré, les moyens se rapportent à ceux du gestionnaire 17a et du supra-gestionnaire 17b. Dans chacun d'eux, la gestion est faite par une plate-forme 30 similaire à celle illustrée dans la figure 2, et plus particulièrement en exécutant une application monitrice 42a, appelée Monitor dans le produit OpenMaster parmi les applications de base 42 disponibles dans le bloc 41 de la plate-forme 30 représentée sur la figure 2.

L'application monitrice 42a définit les objets gérés, dits aussi objets surveillés, dans la base MIB et permet de naviguer dans cette base. Les objets surveillés peuvent être prédéfinis ou définis par l'utilisateur à l'aide du tableau de bord 43.

Lors de la surveillance des objets ainsi déterminés, des dysfonctionnements relatifs à ces objets dans une machine gérée se traduisent par des signaux de dysfonctionnement envoyés à l'agent 18 correspondant. En réponse, l'agent envoie des événements de

<Desc/Clms Page number 19>

dysfonctionnement, dont le nom et la définition correspondent au type de l'agent. Par exemple, selon le type d'agent, les événements de dysfonctionnement sont appelés diversement, par exemple traps de type SNMP et alarms de type CMIP. La plate-forme 30 utilisant le type CMIP, les événements de dysfonctionnement seront donc appelés des alarmes. En d'autres termes plus généraux, les intégrateurs AI 71 peuvent recevoir différents types d'événements de dysfonctionnement et, si ces événements ne sont pas du type CMIP, les intégrateurs AI 71 correspondants les convertissent en alarmes. Chaque alarme correspond donc à une occurrence d'un problème spécifique.

Il existe, dans la norme ISO/IEC 10165-2, cinq types d'alarmes, à savoir les alarmes : Communication, Environmental, Equipment, ProcessingError et QualityOfService. Une alarme peut être définie notamment par : - son instance d'origine (sourceObjectInstance), - son type d'alarme (eventType), - sa cause probable (probableCause), - son problème spécifique (specificProblems), - sa gravité (perceivedSeverity), qui peut prendre 6 valeurs énumérées :
0 : indéterminée (Indeterminate)
1 : critique (Critical)
2 : majeure (Major)
3 : mineure (Minor)
4 : avertissement (Warning)
5 : R. A.S. (rien à signaler) (Cleared) Selon la norme, le problème spécifique specificProblems est une caractéristique optionnelle de l'alarme, alors que les quatre autres citées cidessus sont toujours présentes. Les quatre caractéristiques "sourceObjectInstance", "eventType", "probableCause" et "specificProblems" permettent d'identifier de façon unique un problème donné.

<Desc/Clms Page number 20>

Ainsi, par exemple, quand l'intégrateur CMIP détecte qu'un des agents CMIP pris en charge ne répond pas aux demandes d'opération de gestion, il envoie une notification au courtier 51 au moyen d'une alarme de type "communicationsAlarm". Quand l'agent en cause recommence à répondre, l'intégrateur CMIP envoie une terminaison d'alarme "Cleared". Cette détection n'est effectuée que s'il y a une demande d'opération de gestion en attente à traiter par l'agent distant.

Une alarme ISO a toujours parmi ses caractéristiques la classe d'objet d'origine "sourceObjectClass"et peut avoir les autres caractéristiques suivantes : - sa date d'origine "eventTime", - son état de sauvegarde "backedUpStatus", - l'objet sauvegardé "backUpObject", - son indication de tendance "trendIndication", - son information de seuil "thresholdInfo", - son identifieur de notification "notificationIdentifier", - ses notifications corrélées "correlatedNotifications", - sa définition de changement d'état "stateChangeDefinition", - les attributs qu'elle surveille "monitoredAttributes", - ses actions de dépannage proposées "proposedRepairActions", - un texte additionnel "additionalText", et - une information additionnelle "additionalInformation".

De manière classique, en référence au gestionnaire 17a de la figure 2, les alarmes émises par ses agents 18a et 18b sont reçues par les intégrateurs respectifs 71a et 71b, qui les transmettent selon le protocole CMIP dans le courtier 51. Elles peuvent être dirigées et traitées directement par le service 66, où elles sont stockées dans le journal 67 d'alarmes. Elles peuvent être aussi visualisées sur l'écran de la station graphique 44 et traitées par une application 42 propre aux alarmes. Elles peuvent aussi subir un traitement appelé corrélation, qui est concerné par l'invention. La corrélation des alarmes est une approche avancée qui ne se contente pas de répertorier la liste des alarmes actives. Une corrélation d'alarmes permet de

<Desc/Clms Page number 21>

signaler à un utilisateur des informations synthétiques et précises. La corrélation permet ainsi notamment de : # réduire et condenser les informations relatives aux alarmes, en supprimant les alarmes répétitives et en temporisant les alarmes avant de les rapporter à un utilisateur ; # filtrer de manière sophistiquée les alarmes reçues, en faisant des combinaisons complexes entre ces alarmes ; # améliorer la qualité des informations transmises aux opérateurs, en résumant les données connues sur un problème, notamment sa gravité, en identifiant la cause primaire et d'un problème et en suggérant des actions correctrices qui permettent d'améliorer le temps de réparation et de restauration du service en panne ; # analyser l'impact sur la qualité globale du service, en indiquant quelle partie de l'entreprise ou quelle application sera affectée par la panne détectée ; # et mettre en place des scénarios qui s'appuient sur l'expérience des opérateurs de réseau et du personnel de maintenance, en réalisant une corrélation automatisée équivalente.

La figure 5 illustre la structure impliquée dans la mise en oeuvre du procédé de corrélation d'alarmes dans le gestionnaire 17a et le supragestionnaire 17b. Dans chacun d'eux, la structure comprend le bloc 70 d'interface d'agents, le courtier CMIP 51 connecté à l'application monitrice 42a (appelée Monitor dans le produit OpenMaster), une application 42b d'alarmes (appelée Alarm), une application 42c de traitement d'événements (appelée Event Processor) permettant notamment de lancer des actions dès réception d'alarmes, et une application 42d d'édition de règles. Les applications communiquent à travers le courtier 51. L'application 42b communique avec le service 66 d'alarmes, l'application 42c avec le service 64 d'événements et l'application 42d avec le système expert 65 du bloc 60 de services CMIS. L'ensemble formé par le service 64 et le système expert 65 constitue le service 63 de corrélation d'alarmes.

<Desc/Clms Page number 22>

La figure 5 illustre par des lettres entre parenthèses des étapes du procédé de corrélation d'alarmes dans le gestionnaire 17a. On a vu que les alarmes sont émises comme événements par les agents 18a et 18b et sont reçues par le bloc 70, qui les traduit toutes au protocole CMIP. Lors d'une étape (a), des alarmes 80 sont émises par le bloc 70 et envoyées en temps réel, par l'intermédiaire du courtier 51, au service 64 de traitement des événements. Les alarmes émises par le bloc 70 sont appelées alarmes initiales 80. Le service 64 reçoit les alarmes initiales 80 et les transmet en temps réel au système expert 65 lors d'une étape (b). Le service 64 crée une nouvelle instance de la classe "Alarm" dans une mémoire de travail 65a du système expert 65, chaque fois qu'il reçoit une nouvelle alarme du courtier 51. Le système expert 65 est automatiquement démarré et arrêté respectivement au démarrage et à l'arrêt du service 64. Le système expert 65, également appelé "moteur de règles", incorpore un algorithme optimisé pour appliquer efficacement des milliers de règles par seconde de façon à corréler les alarmes initiales 80. Un filtrage des règles existantes est fait pour extraire les règles nécessaires à la corrélation, qui sont stockées dans un agenda de la mémoire de travail 65a du système expert 65. Selon les scénarios de corrélation définis sous forme de règles, le système expert demande à l'application 42c de traitement des événements d'émettre des alarmes corrélées 81. L'application 42c commande l'activation ou la désactivation des règles. Le système expert 65 choisi dans l'exemple réalisé est un composant de corrélation reposant sur la technologie orientée objets et utilisant des objets (classes) comme "Alarm", "CorrelatedAlarm", "Filter", "Timer" et "StateChange". Les règles qui mettent en oeuvre la corrélation des alarmes s'appliquent aux instances de ces classes.

La corrélation des alarmes bénéficie des avantages inhérents à la technologie en matière d'intelligence artificielle, à savoir : # Les règles sont exprimées pour reproduire un processus de réflexion en vue de la résolution d'un problème.

# Les règles peuvent être facilement lues et comprises.

# Les scénarios de corrélation peuvent être développés et testés de manière incrémentale.

<Desc/Clms Page number 23>

# Le système prend en charge les décisions en temps réel.

# Les corrélations complexes peuvent être exprimées à l'aide de conditions, pour permettre l'automatisation de processus complexes.

Les règles sont créées et éditées par l'application 42d et utilisées par le système expert 65. Un langage de haut niveau reposant sur des règles est disponible dans l'application 42d, qui forme dans l'exemple choisi un éditeur interactif de règles de façon à mettre en #uvre n'importe quel scénario de corrélation. L'éditeur de règles 42d permet à un utilisateur de la plate-forme 30 de définir ses propres règles et de personnaliser les règles prédéfinies qui lui sont fournies, afin de mettre en #uvre ses propres scénarios de corrélation.

Selon les scénarios de corrélation définis sous forme de règles, le système expert 65 génère ainsi des alarmes corrélées 81 et les envoie au service 64 de traitement des événements lors d'une étape (c). Le système expert 65 demande aussi au service 64 d'envoyer les alarmes corrélées 81 au courtier 51 pour que ce dernier les stocke dans le journal 68 d'alarmes lors d'une étape (d). L'application 42b d'alarmes peut ainsi visualiser les alarmes corrélées et les traiter pour animer, en fonction de leur gravité, des icônes représentatives d'objets surveillés. D'une manière générale, ce type d'architecture permet de visualiser de manière cohérente, à l'aide de n'importe quelle application 42, l'état des alarmes de toutes les ressources gérées par le système d'administration 10.

L'état d'une alarme enregistrée dans la mémoire de travail 65a du système expert 65 est représenté par l'attribut "alarmStatus" de l'objet "Alarm". L'état peut prendre les valeurs suivantes : # "initial" : état de l'alarme initiale 80.

# "terminated" : état terminé, signifiant qu'une nouvelle occurrence de l'alarme associée à la gravité "cleared" a été reçue, ou l'alarme a été terminée manuellement par un utilisateur. Le problème est considéré comme résolu. L'alarme n'est donc pas corrélée.

<Desc/Clms Page number 24>

# "correlated" : état corrélé, signifiant que l'alarme initiale 80 a été corrélée en une alarme 81, mais que l'alarme initiale peut toujours être utilisée dans une règle qui compte les alarmes.

# "nonSignificant" : état non significatif signifiant que l'alarme initiale 80 a été déclarée non significative par une règle, par exemple par la règle "ContainedAlarms" qui ignore les alarmes initiales associées aux ressources qui sont enfants d'une instance d'un module de base MIB qui est déjà mis en alarme.

# "removeDelayReached" : état signifiant qu'au bout d'un certain délai, l'alarme initiale 80 est supprimée de la mémoire de travail du système expert.

En sortie, le système expert 65 peut créer une nouvelle instance de la classe d'alarme corrélée "CorrelatedAlarm" dans sa mémoire de travail 65a, chaque fois qu'une alarme corrélée 81 doit être transmise. Un paquet utilitaire interne "Send Correlated Alarm Packet" (envoi d'un paquet d'alarmes corrélées) transfère les instances de la classe "CorrelatedAlarm" au service 64, qui les transmet au courtier CMIP 51. Lorsqu'elles deviennent inutiles, les instances des classes "Alarm" ou "CorrelatedAlarm" sont supprimées de la mémoire de travail du système expert, automatiquement ou manuellement si l'utilisateur décide qu'une alarme initiale ne doit plus faire partie du processus de corrélation.

Une classe "Filter" représente un filtre d'alarmes ainsi que des paramètres temporels. Cette classe permet de créer des règles qui réfèrent à des filtres (c'est-à-dire une liste d'expressions ET/OU sur des attributs d'alarmes), plutôt que d'écrire de manière explicite ces expressions plusieurs fois dans les règles du système expert. Les filtres et paramètres utilisés pour les objets "Filter" sont définis à l'aide de l'interface graphique 44 et sont chargés par le système expert à son lancement. Le système expert a donc deux grands rôles. D'abord, il analyse le contenu de sa mémoire de travail 65a et les règles afin de déterminer les règles à placer dans ou à supprimer de l'agenda de la mémoire de travail. Il décide aussi de la règle de l'agenda à

<Desc/Clms Page number 25>

exécuter et, comme conséquence du lancement de n'importe quelle règle, il réorganise le contenu de sa mémoire de travail.

On a vu plus haut que le type d'une alarme est donné par la valeur de l'attribut "eventType". Cet attribut est de type "ObjectIdentifier", signifiant que sa valeur est globalement unique et s'exprime sous une forme décimale pointée. Par exemple, le type "eventType" d'une alarme "communicationsAlarm" pourrait avoir la valeur 2. 9.3.2.10.2. Les alarmes corrélées, également au format ISO (c'est à dire qu'elles contiennent les mêmes attributs que les alarmes entrantes, mais évidemment avec des contenus éventuellement différents) sont distinguées des alarmes entrantes par la valeur de l'attribut "eventType". Il est important de différencier les alarmes initiales 80 des alarmes corrélées 81 par le biais de l'attribut "eventType", car le mécanisme de corrélation attend des alarmes initiales 80 et génère des alarmes corrélées 81. Sans cette distinction, si le mécanisme de corrélation générait des alarmes corrélées 81 avec les mêmes attributs "eventType" que les alarmes initiales 80, un phénomène de bouclage rendrait les alarmes corrélées inexploitables. Le demandeur a défini cinq nouvelles valeurs de l'attribut "eventType", pour chaque alarme corrélée 81 correspondant aux alarmes entrantes 80, conformément à la Table A de l'annexe. Les cinq valeurs pour les alarmes corrélées sont définies par une marque ajoutée aux valeurs correspondantes des alarmes initiales. La marque illustrée est le mot "correlated" accolé au début de l'attribut correspondant d'une alarme initiale.

Tout ou partie des alarmes qui sont corrélées au niveau subordonné, par exemple par le gestionnaire 17a, peuvent avantageusement être remontées à un niveau supérieur, le supra-gestionnaire 17b en l'occurrence. Ceci permet, à chaque niveau de la hiérarchie, de réaliser une synthèse des alarmes les plus importantes et de les faire remonter à un niveau supérieur. Au niveau supérieur, on pourra alors corréler des alarmes en provenance des subordonnés et réaliser ainsi un niveau de corrélation encore plus synthétique. Ainsi l'alarme corrélée 81 est transmise dans une étape (e), sous la commande du service 64, à l'interface SMI du gestionnaire

<Desc/Clms Page number 26>

17a qui, dans une étape (f), la transmet à l'intégrateur CMIP 71b du bloc 70 du supra-gestionnaire 17b. L'intégrateur 71b du supra-gestionnaire 17b reçoit aussi des alarmes de ses agents CMIP 18c et les émet sous le protocole CMIP sous forme d'alarmes initiales 80. Les alarmes dans le système d'administration choisi étant normalisées, les alarmes initiales 80 sont toutes du même type. Cependant, les attributs "eventType" des alarmes corrélées 81 issues du gestionnaire 17a sont différents de ceux des alarmes initiales 80 issues du bloc 70, comme cela ressort de la Table A en annexe. Par conséquent, les alarmes corrélées 81 issues du gestionnaire 17a ne peuvent être traitées par le service de corrélation 63 du supra-gestionnaire 17b.

La solution connue consiste à définir deux nouveaux groupes correspondants de cinq attributs "eventType", l'un pour les alarmes initiales 80 reçues par le bloc 70 du supra-gestionnaire et l'autre pour les alarmes corrélées 82 (figure 4) par le supra-gestionnaire, comme indiqué par exemple à la Table B en annexe. Les cinq nouveaux attributs "eventType" pour une alarme initiale 80 correspondent à ceux d'une alarme corrélée 81 (voir Table A) et les cinq nouveaux attributs pour une alarme corrélée 82 reprennent les nouveaux attributs respectifs de l'alarme initiale 80 et y ajoutent une même marque, en l'occurrence "Bis" accolée en fin d'attribut et suggérant une nouvelle corrélation. On a vu en introduction que cette solution présente le double inconvénient de modifier les services du bloc 60 et les applications 42 qui traitent des alarmes dans le supra-gestionnaire et de ne pas être reproductible à chaque niveau hiérarchique.

La solution proposée est de modifier la marque des premières alarmes corrélées 81 pour que celles-ci soient traitées dans le supragestionnaire comme les alarmes initiales qu'il reçoit de ses agents. En l'occurrence, les alarmes initiales étant toutes normalisées, elles sont toutes du même type. Dans ce cas, la modification correspond à une suppression de la marque ou démarquage des alarmes corrélées. La modification correspond donc à une "réinitialisation" ou une "décorrélation" des alarmes corrélées pour les rendre semblables aux alarmes initiales. Bien entendu, le contenu des alarmes corrélées 81 reste inchangé. Pour éviter toute confusion, une alarme

<Desc/Clms Page number 27>

corrélée sera dite alarme réinitialisée 80' quand elle reprend l'attribut "eventType" d'une alarme initiale 80. La Table C indique que les valeurs de l'attribut "eventType" d'une alarme corrélée 81 sont celles de la colonne de droite de la Table A et que les valeurs correspondantes d'une alarme réinitialisée 80' sont celles de la colonne de droite de la Table A.

En principe, la réinitialisation d'une alarme corrélée peut se faire indifféremment au niveau de l'émission, ici le gestionnaire 17a, ou au niveau de la réception, ici le supra-gestionnaire 17b. Cependant, la réinitialisation peut être plus avantageuse lorsqu'elle est faite au niveau de la réception. Notamment, une réinitialisation faite au niveau du gestionnaire 17a pourrait être dommageable pour son bon fonctionnement, du fait que les alarmes réinitialisées pourraient être confondues avec les alarmes initiales.

Une telle confusion pourrait même exister au cas où la réinitialisation des alarmes corrélées était faite dans l'interface SMI 52. C'est le cas par exemple lorsque l'attribut "discriminatorConstruct" de l'interface SMI peut être configuré pour ne laisser remonter vers un supra-gestionnaire que les alarmes corrélées et pour bloquer les alarmes initiales. Ainsi, le fait de garder dans l'interface SMI du gestionnaire 17a les deux types d'alarmes offre l'avantage de faire remonter vers le supra-gestionnaire 17b, avec ou sans filtrage, des alarmes initiales 80 indépendamment des alarmes corrélées 81.

Une remontée avec ou sans filtrage des alarmes initiales 80 vers le supragestionnaire 17b présente notamment l'avantage de permettre une corrélation différente aux deux niveaux 17a et 17b et basée sur des mêmes alarmes initiales. Un autre avantage est de soulager le traitement des alarmes au niveau du gestionnaire 17a. Grâce à l'invention, les critères de filtrage de l'attribut "discriminatorConstruct" du SMI portent sur les mêmes valeurs de l'attribut "eventType", quel que soit le niveau considéré dans la hiérarchie du système d'administration.

La figure 5 se place dans le cas d'une réinitialisation faite dans le supra-gestionnaire 17b par des moyens 90 de modification de la marque des alarmes corrélées 81 qui forment, dans le cas présent, un démarqueur d'alarmes corrélées. Le démarqueur 90 est, dans l'exemple choisi, placé dans

<Desc/Clms Page number 28>

le bloc 70 d'intégrateurs d'agents. Il reçoit les alarmes corrélées 81 du gestionnaire 17a et, lors d'une étape (g) du procédé, les démarque pour fournir des alarmes réinitialisées 80'. Elles sont alors confondues par les services du bloc 70 et les applications 42a-42c avec les alarmes initiales 80 reçues des agents 18c. Elles sont donc traitées dans le supra-gestionnaire 17b de la même façon que celle décrite précédemment (étapes (a) -(d), pour fournir des alarmes corrélées 82 indiquées aussi à la figure 4.

Cette solution offre beaucoup d'avantages. La réinitialisation des alarmes corrélées est une opération automatique simple et peu coûteuse. Elle évite toute modification des services du bloc 60 et des applications 42, puisqu'elles voient toutes les alarmes réinitialisées 80' comme des alarmes initiales 80. Elle est reproductible à tout niveau de hiérarchie. Il devient donc possible de faire des corrélations successives et d'obtenir ainsi à peu de frais des alarmes de plus en plus synthétiques et utiles.

Les figures 4 et 5 vont servir de référence pour montrer l'efficacité de la solution. Cela ressort de l'exemple de scénario de corrélation qui suit. On suppose que les gestionnaires 17a, 17e 17f sont de niveaux départementaux, les supra-gestionnaires 17b et 17d sont de niveaux de régions R1 et R2 et le supra-gestionnaire 17c est de niveau national. On suppose aussi que parmi les ressources gérées 19c dans la région R1 se trouve une base de données 20b à laquelle accèdent des applications d'utilisateurs de base de données (autres que les applications d'administration 42) et que parmi les ressources gérées dans la région R2 se trouve une base de données 20d miroir de celle de la région R1, servant de base de données de secours lorsque la base principale 20b est en panne. En utilisant une corrélation classique, on a vu en introduction que son coût prohibitif limitait en pratique son usage à deux niveaux, qui sont évidemment aux niveaux les plus bas qui sont le plus générateurs d'alarmes. On sacrifiait donc la corrélation aux niveaux supérieurs. L'exemple qui suit va révéler l'avantage permis par l'invention de pouvoir faire des corrélations successives. La description de cet exemple est fait en référence aux Tables D-J de l'annexe.

<Desc/Clms Page number 29>

Dans la région RI, on suppose que trois applications utilisatrices demandent une extension des tables de mémoire de la base de données principale 20b. Ces demandes ne pouvant être satisfaites, trois alarmes initiales 80 sont générées par les trois applications respectives ayant fait la requête d'extension. La Table D en annexe indique les valeurs des attributs de ces trois alarmes. Le service de corrélation 63 réalise une corrélation par comptage : lorsque trois alarmes de l'attribut "probableCause" ayant la valeur "softwareError" sont reçues, il génère une alarme corrélée 82 de gravité mineure ayant les caractéristiques indiquées à la Table E en annexe. Dans la région RI, cette alarme corrélée 82 est exploitée notamment par une application 42b de visualisation des alarmes. L'utilisateur n'est par conséquent sollicité par une alarme corrélée que lorsque trois alarmes initiales se sont produites, car on considère que le problème n'est pas significatif en deçà de trois alarmes. L'alarme corrélée est également transmise à un logiciel de suivi d'incidents (HelpDesk) pour informer une équipe de maintenance sur le problème rencontré.

L'interface SMI du supra-gestionnaire 17b de la région R1 est programmée de telle sorte que son attribut "discriminatorConstruct" laisse remonter vers le supra-gestionnaire national 17c uniquement les notifications des fonctions ENROL/DE-ENROL et d'alarmes corrélées dont l'attribut "eventType" a comme valeurs :
OR
EventType == objectCreation
EventType == objectDeletion
EventType == correlatedCommunicationsAlarm
EventType == correlatedEnvironmentalAlarm
EventType correlatedEquipmentAlarm
EventType == correlatedProcessingErrorAlarm
EventType == correlatedQualityofServiceAlarm L'alarme corrélée 82 émise par le service de corrélation 63 de la région R1 est donc transmise au supra-gestionnaire national 17c.

<Desc/Clms Page number 30>

Dans la région R2, on suppose qu'une application utilisatrice ne peut atteindre la base de données miroir 20d de cette région. Une alarme initiale 80 de gravité majeure est donc émise. La Table F de l'annexe indique un exemple de caractéristiques de cette alarme. Dans le même temps, on suppose aussi que l'agent 18 relatif à la base de données émet lui-même une alarme initiale 80 de gravité majeure, indiquant un problème matériel sur la machine 17d qui héberge la base 20d. La Table G indique les caractéristiques de l'alarme initiale qui en résulte. Le service de corrélation 63 du supragestionnaire 17d réalise une corrélation par combinaisons : il détecte que l'alarme d'application relative à une connexion impossible est une conséquence de l'alarme primaire d'équipement, qui est la cause principale du problème. Par conséquent, il n'émet qu'une seule alarme corrélée 82 concernant la panne matérielle, dont le contenu est indiqué à la Table H.

Dans la région R2, cette alarme corrélée est exploitée notamment par une application 42b de visualisation des alarmes. Elle est également transmise à un logiciel de suivi d'incidents (HelpDesk) pour informer une équipe de maintenance sur l'équipement à réparer et l'origine probable de la panne.

L'interface SMI du supra-gestionnaire de la région R2 est également programmée de telle sorte que son attribut "discriminatorConstruct" laisse remonter vers le supra-gestionnaire 17c uniquement les notifications des fonctions ENROL/DE-ENROL et d'alarmes corrélées dont l'attribut "eventType" a comme valeurs :
OR
EventType == objectCreation
EventType == objectDeletion
EventType correlatedCommunicationsAlarm
EventType == correlatedEnvironmentalAlarm
EventType == correlatedEquipmentAlarm
EventType == correlatedProcessingErrorAlarm
EventType correlatedQualityofServiceAlarm

<Desc/Clms Page number 31>

L'alarme corrélée 82 émise par le service de corrélation 63 du supra- gestionnairel7b de la région R2 est donc transmise au supra-gestionnaire national 17c.

Le supra-gestionnaire national 17c reçoit les alarmes 82 qui ont été corrélées dans les régions RI et R2. Ces alarmes corrélées y sont réinitialisées et transmises au service de corrélation 63 en tant qu'alarmes initiales. La corrélation dans le supra-gestionnaire national est appelée interdomaines, car elle corrèle des alarmes provenant de domaines n'ayant pas connaissance les uns des autres, en l'occurrence les régions RI et R2. Le supra-gestionnaire national corrèle d'une part l'alarme réinitialisée de panne matérielle, de gravité majeure, du domaine R2 en une alarme corrélée 83 de gravité majeure, comme indiqué à la Table I de l'annexe. D'autre part, il corrèle l'alarme réinitialisée d'extension de mémoire, de gravité mineure, du domaine R1 en une alarme corrélée 83 de gravité critique, comme indiqué à la Table J de l'annexe. En effet, le service de corrélation 63 a compris que, sachant que la base miroir 20d est inaccessible, l'alarme mineure sur la base principale identifie une situation pouvant dégénérer rapidement, sans solution de secours en l'absence de base miroir. Elle lui affecte donc une gravité critique, indiquant que ce problème est le plus urgent à traiter et qu'il doit passer avant le problème d'accès à la base de données miroir. Seul un mécanisme de corrélation inter-domaines est en mesure de définir ces priorités. La priorité sera aussi modifiée dans le logiciel de suivi d'incidents pour faire passer la priorité du problème de gravité mineure à la gravité critique, afin que l'équipe de maintenance s'attache à traiter l'extension de la mémoire de la base de données principale 20b avant de réparer l'équipement en panne dans la base miroir 20d. En l'absence de corrélation aux deux niveaux régional et national, un utilisateur aurait reçu cinq alarmes : trois alarmes redondantes de gravité mineure en provenance de la région RI, et deux alarmes redondantes de gravité majeure en provenance de la région R2 qui auraient été traitées en premier lieu.

De nombreuses variantes peuvent être apportées par l'homme du métier au procédé décrit et illustré. De telles variantes ont été évoquées lors

<Desc/Clms Page number 32>

de la description. Il ressort ainsi clairement de ce qui précède que, d'une manière générale, l'invention a pour objet un procédé de corrélation d'alarmes dans un système 10 d'administration hiérarchisée d'au moins une ressource, trois ressources 19a-19c dans l'exemple illustré, le système d'administration 10 comprenant au moins un gestionnaire 17a recevant d'objets d'au moins l'une des ressources, en l'occurrence 19a, 19b, des premières alarmes initiales 80 et les corrélant pour former des premières alarmes corrélées 81 incluant une marque ("correlated") distinctive des premières alarmes initiales, et au moins un supra-gestionnaire 17b recevant des secondes alarmes initiales 80 issues d'objets d'au moins une des ressources, en l'occurrence la ressource 19c, et des premières alarmes corrélées 81 issues d'au moins ledit gestionnaire et les corrélant pour former des secondes alarmes corrélées 82 distinctives des secondes alarmes initiales. Selon le procédé, la marque des premières alarmes corrélées est modifiée pour que ces premières alarmes corrélées soient traitées dans le supra-gestionnaire comme les secondes alarmes initiales.

Il est à noter de la figure 4 qu'une même ressource peut être partagée par deux gestionnaires. Dans le cas minimal, le système 10 pourrait servir à l'administration d'une seule ressource, comme cela peut ressortir de la formulation précédente.

Selon l'option choisie dans l'exemple illustré, les premières et secondes alarmes initiales ne sont pas distinctives les unes des autres et la modification est alors une suppression de la marque incluse dans les premières alarmes corrélées traitées par le supra-gestionnaire.

Accessoirement, les secondes alarmes corrélées sont distinguées des secondes alarmes initiales par une marque identique ou non à la marque incluse dans les premières alarmes corrélées. Dans le cas particulier où l'ensemble des alarmes issues de la ressource étant du type défini par la norme ISO, la marque est incluse dans la valeur d'un attribut normalisé nommé "eventType" de ces alarmes.

La description a aussi mis en relief l'avantage de l'option de faire la modification de la marque dans le supra-gestionnaire.

<Desc/Clms Page number 33>

Le procédé peut être mis en #uvre seul dans un système 11.

Cependant, il est plus courant de le mettre en #uvre comme partie d'un ensemble de gestion de ressource (s) celui décrit à titre d'exemple. Il en résulte que l'invention a pour premier objet corollaire un système 10 d'administration hiérarchisée d'au moins une ressource 19a-19c, le système d'administration comprenant au moins un gestionnaire 17a recevant d'objets d'au moins l'une (19a, 19b) des ressources 19a-19c des premières alarmes initiales 80 et incorporant des moyens de corrélation 63 générateurs de premières alarmes corrélées 81 incluant une marque ("correlated") distinctive des premières alarmes initiales, au moins un supra-gestionnaire 17b recevant des secondes alarmes initiales 80 issues d'objets d'au moins ladite ressource et des premières alarmes corrélées 81 issues d'au moins ledit gestionnaire et incorporant des moyens de corrélation 63 générateurs de secondes alarmes corrélées 82 distinctives des secondes alarmes initiales, et des moyens 90 pour modifier la marque conformément au procédé défini précédemment.

Selon l'option choisie dans l'exemple illustré, les moyens de modification 90 sont placés dans un bloc 70 d'au moins un intégrateur d'agents 18c en liaison avec au moins ladite ressource correspondante 19c.

L'invention a aussi pour second objet corollaire un système 11, tel qu'un système informatique, incluant au moins une ressource 19a-19c gérée par un système d'administration hiérarchisée 10 tel que défini précédemment.

<Desc/Clms Page number 34>

ANNEXE TABLE A

<tb>
<tb> gestionnaire
<tb> EventType <SEP> EventType
<tb> d'une <SEP> alarme <SEP> initiale <SEP> d'une <SEP> alarme <SEP> corrélée
<tb> communicationsAlarm <SEP> correlatedCommunicationsAlarm
<tb> environmentalAlarm <SEP> correlatedEnvironmentalAlarm
<tb> equipmentAlarm <SEP> correlatedEquipmentAlarm
<tb> processingErrorAlarm <SEP> correlatedProcessingErrorAlarm
<tb> qualityofServiceAlarm <SEP> correlatedQualityofServiceAlarm
<tb>
TABLE B

<tb>
<tb> supra-gestionnaire <SEP> (art <SEP> antérieur)
<tb> EventType <SEP> EventType
<tb> d'une <SEP> alarme <SEP> initiale <SEP> d'une <SEP> alarme <SEP> corrélée
<tb> correlatedCommunicationsAlarm <SEP> correlatedCommunicationsAlarmBis
<tb> correlatedEnvironmentalAlarm <SEP> correlatedEnvironmentalAlarmBis
<tb> correlatedEquipmentAlarm <SEP> correlatedEquipmentAlarmBis
<tb> correlatedProcessingErrorAlarm <SEP> correlatedProcessingErrorAlarmBis
<tb> correlatedQualityofServiceAlarm <SEP> correlatedQualityofServiceAlarmBis
<tb>
TABLE C

<tb>
<tb> supra-gestionnaire
<tb> eventType <SEP> eventType <SEP> d'une <SEP> alarme <SEP> corrélée
<tb> d'une <SEP> alarme <SEP> corrélée <SEP> réinitialisée
<tb> correlatedCommunicationsAlarm <SEP> communicationsAlarm
<tb> correlatedEnvironmentalAlarm <SEP> environmentalAlarm
<tb> correlatedEquipmentAlarm <SEP> EquipmentAlarm
<tb> correlatedProcessingErrorAlarm <SEP> ProcessingErrorAlarm
<tb> correlatedQualityofServiceAlarm <SEP> QualityofServiceAlarm
<tb>

<Desc/Clms Page number 35>

TABLE D

<tb>
<tb> supra-gestionnaire <SEP> 17b <SEP> de <SEP> la <SEP> région <SEP> RI
<tb> attributs <SEP> de <SEP> chaque <SEP> alarme <SEP> valeurs <SEP> des <SEP> attributs
<tb> initiale
<tb> SourceObjectClass <SEP> snmpSystem
<tb> SourceObjectInstance <SEP> snmpSystemId=primaryDB
<tb> eventType <SEP> processingErrorAlarm
<tb> ProbableCause <SEP> softwareError
<tb> severity <SEP> minor
<tb> additionalText <SEP> Alert <SEP> on <SEP> SruSpace <SEP> indicator.
<tb>

TABLE E

<tb>
<tb> supra-gestionnaire <SEP> 17b <SEP> de <SEP> la <SEP> région <SEP> R1
<tb> attributs <SEP> de <SEP> l'alarme <SEP> corrélée <SEP> valeurs <SEP> des <SEP> attributs
<tb> SourceObjectClass <SEP> snmpSystem
<tb> SourceObjectInstance <SEP> snmpSystemId=primaryDB
<tb> eventType <SEP> correlatedProcessingErrorAlarm
<tb> ProbableCause <SEP> softwareError
<tb> severity <SEP> minor
<tb> additionalText <SEP> Alert <SEP> on <SEP> SruSpace <SEP> indicator. <SEP> Area <SEP> B.
<tb>

TABLE F

<tb>
<tb> supra-gestionnaire <SEP> 17d <SEP> de <SEP> la <SEP> région <SEP> R2
<tb> attributs <SEP> d'une <SEP> alarme <SEP> initiale <SEP> valeurs <SEP> des <SEP> attributs
<tb> d'application <SEP> - <SEP>
<tb> SourceObjectClass <SEP> snmpSystem
<tb> SourceObjectInstance <SEP> snmpSystemId=mirorDB
<tb> eventType <SEP> processingErrorAlarm
<tb> ProbableCause <SEP> softwareError
<tb> severity <SEP> major
<tb> additionalText <SEP> Alert <SEP> on <SEP> DatabaseState <SEP> indicator.
<tb>

<Desc/Clms Page number 36>

TABLE G

<tb>
<tb> supra-gestionnaire <SEP> 17d <SEP> de <SEP> la <SEP> région <SEP> R2
<tb> attributs <SEP> valeurs
<tb> d'une <SEP> alarme <SEP> initiale <SEP> d'agent <SEP> des <SEP> attributs
<tb> SourceObjectClass <SEP> snmpSystem
<tb> SourceObjectInstance <SEP> snmpSystemId=mirorDB
<tb> eventType <SEP> equipmentAlarm
<tb> ProbableCause <SEP> inputOutputDeviceError
<tb> severity <SEP> major
<tb> additionalText <SEP> Host <SEP> is <SEP> unreachable.
<tb>

TABLE H

<tb>
<tb> supra-gestionnaire <SEP> 17d <SEP> de <SEP> la <SEP> région <SEP> R2
<tb> attributs <SEP> de <SEP> l'alarme <SEP> corrélée <SEP> valeurs <SEP> des <SEP> attributs
<tb> SourceObjectClass <SEP> snmpSystem
<tb> SourceObjectInstance <SEP> snmpSystemId=mirorDB
<tb> eventType <SEP> correlatedEquipmentAlarm
<tb> ProbableCause <SEP> inputOutputDeviceError
<tb> severity <SEP> major
<tb> additionalText <SEP> Host <SEP> is <SEP> unreachable. <SEP> Area <SEP> C.
<tb>

<Desc/Clms Page number 37>

TABLE I

<tb>
<tb> supra-gestionnaire <SEP> national <SEP> 17c
<tb> attributs <SEP> de <SEP> l'alarme <SEP> corrélée <SEP> valeurs
<tb> à <SEP> partir <SEP> de <SEP> l'alarme <SEP> corrélée <SEP> des
<tb> de <SEP> la <SEP> Table <SEP> H <SEP> et <SEP> réinitialisée <SEP> attributs
<tb> SourceObjectClass <SEP> snmpSystem
<tb> SourceObjectInstance <SEP> snmpSystemId=mirorDB
<tb> eventType <SEP> correlatedEquipmentAlarm
<tb> ProbableCause <SEP> inputOutputDeviceError
<tb> severity <SEP> major
<tb> additionalText <SEP> Host <SEP> is <SEP> unreachable. <SEP> Area <SEP> C.
<tb>

TABLE J

<tb>
<tb> supra-gestionnaire <SEP> national <SEP> 17c
<tb> attributs <SEP> de <SEP> l'alarme <SEP> corrélée <SEP> valeurs
<tb> à <SEP> partir <SEP> de <SEP> l'alarme <SEP> corrélée <SEP> des
<tb> de <SEP> la <SEP> Table <SEP> E <SEP> et <SEP> réinitialisée <SEP> attributs
<tb> SourceObjectClass <SEP> snmpSystem
<tb> SourceObjectInstance <SEP> snmpSystemId=primaryDB
<tb> eventType <SEP> correlatedProcessingErrorAlarm
<tb> ProbableCause <SEP> softwareError
<tb> severity <SEP> critical
<tb> additionalText <SEP> Alert <SEP> on <SEP> SrvSpace <SEP> indicator. <SEP> Area <SEP> B.
<tb>

Claims (8)

Revendications

1. Procédé de corrélation d'alarmes dans un système (10) d'administration hiérarchisée d'au moins une ressource (19a-19c), le système d'administration (10) comprenant au moins un processeur (14), des moyens de mémoire (15), au moins un gestionnaire (17a) recevant d'objets d'au moins ladite ressource (19a, 19b) des premières alarmes initiales (80) et les corrélant pour former des premières alarmes corrélées (81) incluant une marque ("correlated") distinctive des premières alarmes initiales, et au moins un supra-gestionnaire (17b) recevant des secondes alarmes initiales (80) issues d'objets d'au moins ladite ressource (19c) et des premières alarmes corrélées (81) issues d'au moins ledit gestionnaire et les corrélant pour former des secondes alarmes corrélées (82) distinctives des secondes alarmes initiales, caractérisé en ce qu'il comprend dans lesdits moyens de mémoire (15) la modification de la marque des premières alarmes corrélées pour être traitées dans le supra-gestionnaire comme les secondes alarmes initiales.

2. Procédé selon la revendication 1, caractérisé en ce que les premières et secondes alarmes initiales n'étant pas distinctives les unes des autres, la modification est une suppression de la marque incluse dans les premières alarmes corrélées traitées par le supra-gestionnaire.

3. Procédé selon la revendication 1 ou 2, caractérisé en ce que les secondes alarmes corrélées sont distinguées des secondes alarmes initiales par une marque identique ou non à la marque incluse dans les premières alarmes corrélées.

4. Procédé selon l'une des revendications 1 à 3, caractérisé en ce que l'ensemble des alarmes issues de la ressource étant du type défini par la norme ISO, la marque est incluse dans la valeur d'un attribut normalisé nommé "eventType" de ces alarmes.

5. Procédé selon l'une des revendications 1 à 4, caractérisé en ce que la modification de la marque est faite dans le supra-gestionnaire.

6. Système (10) d'administration hiérarchisée d'au moins une ressource (19a-19c), le système d'administration comprenant au moins un processeur (14), des moyens de mémoire (15), au moins un gestionnaire (17a)

<Desc/Clms Page number 39>

recevant d'objets d'au moins ladite ressource (19a, 19b) des premières alarmes initiales (80) et incorporant des moyens de corrélation (63) générateurs de premières alarmes corrélées (81) incluant une marque ("correlated") distinctive des premières alarmes initiales, et au moins un supra-gestionnaire (17b) recevant des secondes alarmes initiales (80) issues d'objets d'au moins ladite ressource (19c) et des premières alarmes corrélées (81) issues d'au moins ledit gestionnaire et incorporant des moyens de corrélation (63) générateurs de secondes alarmes corrélées (82) distinctives des secondes alarmes initiales, caractérisé en ce qu'il comprend dans lesdits moyens de mémoire (15) des moyens (90) pour modifier la marque conformément au procédé défini par l'une des revendications 1 à 5.

7. Système d'administration selon la revendication 6, caractérisé en ce que les moyens de modification (90) sont placés dans un bloc (70) d'au moins un intégrateur d'agents (18c) en liaison avec au moins ladite ressource correspondante (19c).

8. Système (11), tel qu'un système informatique, incluant au moins une ressource (19a-19c) gérée par un système d'administration hiérarchisée (10), caractérisé en ce que le système d'administration est défini par la revendication 6 ou 7.