Brevet FR2880443A1 — publié le 20060707

La présente invention concerne un traitement de système informatique, et plus particulièrement la fourniture de journaux d'événements pour des systèmes informa-tiques. Pour les systèmes informatiques, la consignation d'événements fournit un procédé centralisé standard pour enregistrer des événements logiciels et matériels. Un ou plusieurs composants matériels ou logiciels du système sont des "générateurs d'événements", et génèrent et en- voient des messages d'événements à un "consignateur d'événements", lequel enregistre les événements dans une mémoire. Un "visualiseur d'événements" fournit une inter-face utilisateur pour visualiser les événements. Les don-nées d'événements peuvent être de plus exposées et analy- Sées, en utilisant un logiciel d'application sophistiqué pour le traitement de journaux d'événements. Pour un système actif, tel qu'un serveur, la tâche de génération d'un journal d'événements n'est pas une tâche facile, même si un serveur peut générer des mil- liers d'événements en un intervalle de temps court. Pour les serveurs actuels, les événements sont consignés conformément à une norme d'échelle industrielle connue sous le nom de Spécification d'Interface de Traitement de Plate-forme Intelligente (IPMI). La spécification IPMI définit les messages et l'interface système de détecteurs de plate-forme "intelligents", qui sont utilisés pour surveiller les caractéristiques d'état physique du système, telles les températures du processeur et du système, la vitesse du ventila- teur, et les niveaux de tension. Les événements peuvent également être générés par un logiciel. La spécification IPMI établit des lignes de référence standards pour la mise en oeuvre d'un sous-système de surveillance et d'alerte qui a pour objectif d'atteindre "la capacité de gestion toujours disponible" des systèmes serveurs. Selon les enseignements de la présente description, on décrit des systèmes et procédés pour générer et visualiser un journal d'événements. La présente invention est spécialement adaptée lorsque les enregistrements d'événement qui constituent le journal d'événements ont un format prédéterminé ayant un espace de données limité pour les données d'écrivant l'événement. Selon la pré-sente invention, les événements sont "primaires" ou "secondaires". Les événements primaires sont enregistrés en utilisant le format d'enregistrement d'événement classique. Tout événement primaire peut être chaîné à un ou plusieurs événements secondaires. L'événement secondaire est identifié comme tel en utilisant un champ de données de l'enregistrement d'événement. Le champ de données de ou des enregistrements d'événements secondaires contient les données supplémentaires servant à décrire l'événement. Dans un mode de réalisation de la présente invention, le journal d'événements est enregistré conformément à la norme IPMI. L'enregistrement d'un événement secondaire est désigné comme tel dans l'un des champs d'un enregistrement d'événement IPMI, comme dans le champ de type événement. Le champ de données d'un événement secondaire contient les données supplémentaires. Une compréhension plus complète des présents modes de réalisation et avantages de ces derniers peut être acquise en faisant référence à la description qui va suivre faite conjointement avec les dessins annexés, sur lesquels des références numériques analogues indiquent des caractéristiques analogues, et sur lesquels: - la figure 1 illustre un système informatique ayant un consignateur d'événements selon la présente invention, - la figure 2 illustre un exemple d'un journal d'événements ayant uniquement des enregistrements d'événements primaires, et - la figure 3 illustre un exemple d'un journal d'événements ayant à la fois des enregistrements d'événements primaires et secondaires. La figure 1 illustre un système informatique typique 100, qui, dans l'exemple de cette description, est un système serveur. Les concepts décrits ici peuvent être appliqués à tout "système de traitement d'informations" 100 qui conserve un "journal d'événements" 30. Par conséquent, en plus d'un système serveur, le système informatique 100 peut être tout "système de traitement d'informations" qui est programmable en utilisant un langage de programmation informatique évolué. Le système informatique peut également être mis en oeuvre en utilisant un matériel à usage spécifique programmé de manière spécifique. Dans le système informatique 100, le processeur est typiquement un processeur disponible dans le commerce, tel que ceux disponibles auprès des sociétés Intel Corporation, Sun Microsystems, ou Motorola. Le processeur exécute habituellement un système d'exploitation qui peut être, par exemple, tel que ceux disponibles au-près des sociétés Microsoft Corporation, Apple Computer, Sun Microsystems, Palm, Inc. ou d'autres systèmes d'exploitation à base d'UNIX disponibles chez diverses sources. Un "journal d'événements" 30 est défini comme étant un dépôt de données, typiquement une mémoire non-volatile, pour enregistrer des événements système. Il est supposé que le système 100 a un mécanisme de consignation d'événements pour enregistrer les événements (ici BMC 111), et un mécanisme de visualisation d'événements (ici une partie du logiciel de gestion de système 122) pour visualiser le journal d'événements ou autrement y accéder. Lorsque le système informatique 100 est un système serveur, il communique avec un ou plusieurs systèmes clients (non-représentés) dans le but d'échanger des in-formations et d'exécuter des transactions, telles que des transactions de base de données. Ces systèmes communiquent en utilisant un protocole de communication via un réseau. Le serveur 100 peut être, par exemple, un serveur de protocole de transfert de documents hypertextuels (HTTP) qui est configuré pour exécuter des transactions de base de données. Le réseau de communication (non-représenté) peut être un réseau Ethernet, un réseau Fast Ethernet ou un autre type de réseau local ou étendu (LAN Ou WAN), un réseau point-à-point fourni par des services téléphoniques, ou un autre type de réseau de communication ou une combinaison de réseaux. Les consommateurs et les fournisseurs d'informations, également appelés dans la technique systèmes client et serveur, respective- ment, communiquent via le réseau pour échanger des informations. Pour l'exemple de la figure 1, lorsque le maté-riel système 110 est un matériel associé à un système serveur, le matériel peut inclure un processeur connecté à un ou plusieurs dispositifs de mémorisation, tels qu'une unité de disque, via un dispositif de communication, tel qu'un bus. Le matériel informatique 110 peut également inclure un ou plusieurs dispositifs de sortie, tels qu'un moniteur, une imprimante, ou un afficheur gra- phique, ou un dispositif d'impression et un ou plusieurs dispositifs d'entrée, tels qu'un clavier, une souris ou un autre dispositif. Le système 110 a une mémoire pour mémoriser des programmes et des données durant le fonctionnement du système informatique. De plus, le système 110 peut contenir un ou plusieurs dispositifs de communi- cation qui connectent le système informatique 100 à un réseau de communication. Un contrôleur de gestion de carte de base (BMC) 111 est un microcontrôleur qui gère l'interface entre le logiciel de gestion de système 122 et le matériel de gestion de système. Il contrôle les événements, et reçoit et consigne des messages d'événements dans le journal d'événements 30. Le logiciel système 120 comporte des programmes d'application, des utilitaires de système, un interpréteur de commandes, des services de système, le système d'exploitation, et le système BIOS. Un système d'exploitation d'un serveur typique est Windows, un produit de la société Microsoft Corporation. "BIOS" est un acronyme pour système de base d'entrées/sorties, et détermine ce que le système 100 peut exécuter sans accéder à des pro-grammes d'un disque. Par exemple, le système BIOS contient un code de programmation requis pour commander le clavier, l'écran d'affichage, les unités de disque, les communications série, et bon nombre de fonctions variées. Le système BIOS fonctionne également conjointe-ment avec le contrôleur BMC 111 pour consigner des événements système. Les événements sont consignés conformément à la norme IPMI décrite dans la technique antérieure. Spécifiquement, le système BIOS génère des messages d'événements et les envoie au contrôleur BMC 111, qui les enregistre dans le journal d'événements 30. "Le logiciel de gestion de système" 122 est un terme générique utilisé ici pour décrire tout ce qu'une programmation de logiciel fournit le journal d'événements à visualiser, en accédant au journal d'événements 30 et en analysant les données d'événements. La tâche particulière du logiciel de gestion de système 122 qui lit le journal d'événements et délivre un affichage d'événements visualisables est appelée ici le "visualiseur d'événements". Dans l'exemple de la figure 1, le visualiseur d'événements est représenté en bas sur la pile de logiciels. Cependant, la visualisation d'événements peut être en variante effectuée par un logiciel évolué ayant des fonctionnalités de gestion d'événements sophistiquées. Comme interface de niveau matériel, l'interface IPMI 121 se trouve dans la partie basse de la pile typique de logiciels de gestion de système. L'interface IPMI fonctionne indépendamment du système d'exploitation, ce qui permet aux administrateurs système d'accéder aux systèmes et de les restaurer même si le système d'exploitation ne répond pas ou si le système est désactivé. Dans d'autres modes de réalisation, une interface de gestion d'événements autre que l'interface IPMI peut être substituée. La figure 2 est un exemple d'une partie d'un journal d'événements 30 généré en vue d'une visualisation par le visualiseur d'événements 122. Quatre événements ont été enregistrés, par conséquent il y a quatre "enregistrements d'événement". Dans l'exemple de la figure 2, la totalité des quatre enregistrements d'événement concernent des événements primaires. Selon l'interface IPMI, chaque événement est en- registré avec un nombre prédéfini de champs de données. Les champs et les données qui sont disponibles pour être visualisés sont déterminés par le logiciel de consignation et de visualisation d'événements fourni comme partie du logiciel de gestion de système 122. Dans l'exemple de la figure 2, les champs visualisés sont l'identificateur (ID) de générateur 21, le type d'événement 22, le type de lecture 23, et trois champs de données 24. Le champ ID de générateur 21 décrit l'origine de l'événement. Des exemples sont les identificateurs (ID) du BIOS et du contrôleur BMC 111. Si l'événement a été généré par un logiciel, celui-ci est l'identificateur du logiciel. Le champ de type d'événement 22 contient des don-nées qui décrivent le type de déclencheur de l'événement. Il peut également indiquer la classe de l'événement, telle que "seuil devenant haut". Des exemples sont la mémoire, le processeur, critique, constructeur de matériel informatique d'origine (OEM), etc. Le champ de type de lecture d'événement 23 contient des données qui indiquent un état de lecture de capteur. Des exemples sont seuil, discret, générique, ou spécifié OEM. Les champs de données d'un événement 24 sont utilisés pour fournir des informations supplémentaires concernant l'événement. Trois octets de données sont al-loués pour les données d'événement. Le premier octet est prédéfini, laissant uniquement deux octets de données "libres". Une exception existe si l'utilisateur est consigné en tant que OEM, auquel cas, on peut avoir plus de bits disponibles. Pour de nombreux événements, les champs de don-nées d'un événement 24 sont de taille insuffisante pour fournir des informations utiles concernant l'événement. Par exemple, un événement relatif au bus (rapide) PCI Express doit identifier le bus, le numéro de fonctions de dispositif, les registres d'erreur, et les valeurs de ces registres. Comme indiqué par les événements 2 et 4 dans l'exemple de journal d'événements de la figure 2, lorsque les champs de données d'événements 24 fournissent unique-ment deux octets de données "libres", il existe un espace uniquement pour le bus et le numéro de fonction de dispositif. Ces informations n'aident pas à diagnostiquer un problème, du fait qu'elles ne fournissent pas d'informa- tions concernant les registres et leurs contenus. La figure 3 illustre un exemple d'un journal d'événements amélioré 30 selon la présente invention. La figure 3 illustre à la fois des enregistrements d'événements primaires et secondaires. Des procédés et formats classiques sont utilisés pour enregistrer les événements primaires. Cependant, comme illustré, après un événement primaires, un ou plusieurs enregistrements d'événements secondaires peuvent être enregistrés. Un enregistrement d'événement secondaire ne consigne pas un événement "corn- plet" mais plutôt consigne des informations supplémentaires concernant un événement primaire. Dans l'exemple de la figure 3, les événements 1, 2, 3 et 4 sont des événements primaires, et correspondent aux événements du journal d'événements de la figure 2. Les événements 2 et 4 ont des événements secondaires. Les enregistrements d'événement primaire décrivent le dispositif qui a provoqué l'erreur, et sont sui-vis d'un ou de plusieurs événements secondaires. Dans l'exemple de la figure 3, le ou les événements secondaires fournissent des informations concernant un registre comprenant des valeurs d'erreur ou des données d'état. Par conséquent, tout événement primaire peut être suivi séquentiellement par un ou plusieurs événements secondaires. Après un événement primaire, le consignateur d'événements consigne des événements secondaires avec le même identificateur de générateur que l'événement primaire associé. Pour déterminer la fin de la file d'événements, le visualiseur d'événements 122 recherche un autre événe- ment primaire ayant le même identificateur de générateur. Du fait que des événements concurrents peuvent être consignés d'une manière entrelacée, un autre événement primaire ayant un identificateur de générateur différent ne marque pas nécessairement la fin de la file d'événe- ments. Par conséquent, la file d'événement reste "ou- verte" pour la consignation d'événements secondaires supplémentaires, jusqu'à l'apparition d'un nouvel événement primaire émanant du même générateur d'événement. Une valeur dans le champ de type d'événement 22 identifie l'enregistrement en tant qu'enregistrement d'événement secondaire. Cette valeur est appelée ici "l'indicateur d'enregistrement d'événement secondaire". Dans l'exemple de cette description, cette valeur est OxC1 qui provient d'une plage OEM de valeurs dans la norme IPMI. D'autres valeurs peuvent être utilisées. Pour les événements 2 et 4, le consignateur d'événements 111 a consigné les événements secondaires en utilisant un pointeur de registre d'événement (ERP). Une valeur dans le champ de type de lecture d'événement 23 définit le pointeur ERP. Dans l'exemple de cette description, le type de lecture d'événement est Ox7E de la plage de valeurs OEM de la norme IPMI, mais d'autres valeurs peuvent être utilisées. Le pointeur ERP représente un dé-calage de registre de 12 bits dans l'espace fourni par son événement primaire. L'espace de registre peut être de type registre PCI, mémoire, ou entrée/sortie et est dé- terminé par l'événement primaire. Après un événement primaire, on pourrait ne trou-ver aucun événement secondaire ou trouver de nombreux événements secondaires. Dans le journal d'événements 30, des pointeurs ERP apparaissent séquentiellement après l'événement primaire et ont le même identificateur de générateur. Un autre événement primaire ayant le même identificateur de générateur marque la fin de la file de ERP. Ceci garantit que toutes les informations secondaires font l'objet d'un accès et sont visualisées après l'événement primaire correspondant. Divers types d'événements secondaires peuvent être consignés. Les événements particulièrement adaptés 35 pour l'utilisation d'enregistrements d'événements se- condaires sont des événements définissant un espace d'adresses, tels que les événements se rapportant aux bus PCI et PCI Express décrits ci-dessus. Ces événements "d'espace d'adresses" peuvent être implémentés avec des pointeurs ERP comme décrit ci-dessus. Des événements secondaires qui ne se rapportent pas à des espaces d'adresses peuvent utiliser d'autres données dans le champ de type de lecture 23. REVENDICATIONS 1. Procédé de consignation d'événements dans un journal d'événements (30) d'un système informatique (100), caractérisé en ce qu'il comporte les étapes consistant à : enregistrer un enregistrement d'événement primaire pour chaque événement, dans lequel chaque enregistrement d'événement a le même format ayant des champs de données prédéfinis (24), enregistrer un enregistrement d'événement secondaire pour un ou plusieurs des événements, l'événement secondaire étant identifié en tant qu'événement secondaire en utilisant un indicateur d'événement se- condaire prédéterminé écrit dans l'un des champs d'enregistrement d'événement (22), dans lequel les événements sont associés à des générateurs d'événements, chacun ayant un identificateur (ID) de générateur (21), et dans lequel des événements secondaires sont enregistrés pour un événement primaire jusqu'à ce qu'un nouvel événement ayant le même identificateur (ID) de générateur d'événement (21) soit détecté. 2. Procédé selon la revendication 1, caractérisé en ce que le format d'enregistrement d'événement est conforme à la norme IPMI. 3. Procédé selon la revendication 1, caractérisé en ce que l'indicateur d'événement secondaire est écrit dans un champ de type d'événement (22). 4. Procédé selon la revendication 1, caractérisé en ce que l'étape d'enregistrement est répétée pour des événements secondaires supplémentaires pour le même évé- nement primaire. 5. Procédé selon la revendication 1, caractérisé en ce que l'événement est associé à un espace d'adresses. 6. Procédé selon la revendication 5, caractérisé en ce que l'enregistrement d'événement secondaire contient un pointeur vers l'espace d'adresses. 7. Procédé selon la revendication 1, caractérisé en ce que l'événement est associé à un bus système. 8. Procédé selon la revendication 1, caractérisé en ce que le système informatique (100) est un système serveur. 9. Procédé de consignation d'événements d'espace d'adresses dans un journal d'événements (30) d'un système informatique (100), caractérisé en ce qu'il comporte les étapes consistant à : enregistrer un enregistrement d'événement pri- maire pour chaque événement, dans lequel chaque enregistrement d'événement a le même format ayant des champs de données prédéfinis (24), enregistrer un enregistrement d'événement se- condaire pour un ou plusieurs des événements, dans lequel l'étape d'enregistrement est effectuée de sorte que l'événement secondaire est identifié en tant qu'événement secondaire à l'aide d'un indicateur d'événement secondaire prédéterminé écrit dans l'un des champs d'enregistrement d'événement (22), et dans lequel l'enregistrement d'événement secondaire contient de plus un pointeur vers un espace d'adresse associé à l'événement. 10. Procédé selon la revendication 9, caractérisé en ce que le système informatique (100) est un système serveur. 11. Procédé selon la revendication 9, caractérisé en ce que les événements sont associés à des générateurs d'événements, chacun ayant un identificateur de générateur (21), et en ce que les événements secondaires sont enregistrés pour un événement primaire jusqu'à ce qu'un nouvel événement ayant le même identificateur de générateur d'événement (21) soit détecté. 12. Procédé de consignation d'événements d'espace d'adresses dans un journal d'événements (30) d'un système informatique (100) compatible avec le norme IPMI, caractérisé en ce qu'il comporte les étapes consistant à : enregistrer un enregistrement d'événement primaire pour chaque événement, dans lequel chaque enregistrement d'événement a le format IPMI ayant des champs de données prédéfinis (24), enregistrer un enregistrement d'événement secondaire pour un ou plusieurs des événements, dans lequel l'étape d'enregistrement est effec- tuée de sorte que l'événement secondaire est identifié en tant qu'événement secondaire à l'aide d'un indicateur d'événement secondaire prédéterminé écrit dans l'un des champs d'enregistrement d'événement (22), et dans lequel l'enregistrement d'événement se- condaire contient de plus un pointeur vers un espace d'adresses associé à l'événement. 13. Procédé selon la revendication 12, caractérisé en ce que l'indicateur d'événement secondaire est écrit dans le champ de type d'événement (22). 14. Procédé selon la revendication 12, caractérisé en ce que l'événement est associé à un espace d'adresses. 15. Procédé selon la revendication 14, caractérisé en ce que l'enregistrement d'événement secondaire contient un pointeur vers l'espace d'adresses. 16. Procédé selon la revendication 15, caractérisé en ce que le pointeur est écrit dans le champ de type de lecture (23) de l'enregistrement d'événement. 17. Procédé selon la revendication 12, caractéri- sé en ce que les événements sont associés à des générateurs d'événements, chacun ayant un identificateur de générateur (21), et en ce que les événements secondaires sont enregistrés pour un événement primaire jusqu'à ce qu'un nouvel événement ayant le même identificateur de générateur d'événement (21) soit détecté. 18. Système de traitement d'informations, caractérisé en ce qu'il comporte: une plate-forme matérielle (110) ayant au moins 25 un processeur et une mémoire pour exécuter des instructions, un consignateur d'événements (111) opérationnel pour enregistrer des événements associés à la plate-forme matérielle (110), dans lequel le consignateur d'événements {111) enregistre à la fois des événements primaires et secondaires, chaque événement primaire enregistré dans un champ d'enregistrement d'événement ayant un format prédéterminé, et chaque événement secondaire étant enregistré en tant qu'enregistrement d'événement après un événement primaire mais avant tout événement primaire suivant, dans lequel le consignateur d'événements (111) enregistre de plus des événements secondaires en dési- gnant l'événement en tant qu'événement secondaire dans un espace de données prédéterminé du format prédéfini. 19. Système selon la revendication 18, caractérisé en ce que le format prédéfini est le format de la norme IPMI pour les enregistrements d'événements. 20. Système selon la revendication 18, caractérisé en ce que le consignateur d'événements (111) enregistre de plus des événements logiciels.