FR2993685A1 - Surveillance d'evenements sur des machines informatiques. - Google Patents

Abstract

L'invention concerne une surveillance d'une ou plusieurs machines informatiques, comportant les étapes : a) collecter un historique (S6) d'événements relatifs à ladite machine, par exemple un ensemble de fichiers descriptifs d'événement, du type fichier de log, b) choisir au moins un type d'événement à surveiller (S4) dans cet historique, c) identifier, dans l'historique, des occurrences de ce type d'événement (S7), d) assigner une valeur de décompte relative aux occurrences de ce type d'événement, sur une durée choisie (S 10), e) répéter l'étape d) pour obtenir une variation dans le temps de la valeur de décompte (S11).

Description

Surveillance d'événements sur des machines informatiques La présente invention concerne une surveillance de machines informatiques, mettant en oeuvre des moyens informatiques.

Les machines informatiques peuvent être par exemple des serveurs en réseau. Dans de telles machines informatiques, des erreurs de fonctionnement (par exemple de connexion dans le cas de serveurs) peuvent intervenir ponctuellement, mais une répétition dans le temps de telles erreurs ponctuelles peut refléter un problème de fonctionnement plus général d'une machine. Par ailleurs, une erreur identique ou de même nature, sur plusieurs machines et dans une même période, peut être symptomatique d'un problème de fonctionnement de l'ensemble des machines (par exemple une attaque sur un réseau commun auxquelles sont connectées les machines). Habituellement, il est possible d'analyser, pour une seule machine et pour un instant (ou une période de donnée courte) des erreurs ou autres événements susceptibles d'intervenir à cet instant, un fichier de type « fichier système » tel qu'un journal d'événements ou « logging » (ou « fichier log » ci-après) qui répertorie de tels événements. Néanmoins, un tel fichier journal ne reflète l'ensemble des événements que sur une période donnée (par exemple une minute) et pour une seule machine. Il est alors difficile d'établir un lien entre les différents événements précités dans le temps ou entre machines. La présente invention vient améliorer la situation.

Elle propose à cet effet un procédé mis en oeuvre par des moyens informatiques, de surveillance d'une ou plusieurs machines informatiques, comportant les étapes : a) collecter un historique d'événements relatifs à ladite machine, b) choisir au moins un type d'événement à surveiller, c) identifier, dans l'historique, des occurrences dudit type d'événement, d) assigner une valeur de décompte relative aux occurrences dudit type d'événement, sur une durée choisie, e) répéter l'étape d) pour obtenir une variation dans le temps de la valeur de décompte. Ainsi, la présente invention permet, pour une machine au moins, d' analyser son fonctionnement dans le temps, d'identifier une récurrence d'erreurs notamment, voire aussi des informations de fonctionnement récurrentes qui ne sont pas nécessairement des erreurs, mais pouvant expliquer un dysfonctionnement plus général de la machine ou d'une pluralité de machines par exemple en réseau. On entend ci-avant par « décompte » un décompte des occurrences liées à un événement spécifique, mais aussi plus généralement une valeur associée à un événement, telle que par exemple une durée totale liée à cet événement (ou une durée moyenne), ou encore à titre d'exemple une valeur de note affectée à un événement (gravité d'une attaque de virus par exemple). Dans une réalisation, l'historique précité, qui est traité aux étapes b) à d), est construit à partir d'une succession de fichiers systèmes de type journaux (fichiers dits de « Logging » en anglais). Par exemple, dans le cas où la machine est un serveur, l'historique précité peut être obtenu à partir d'une succession de fichiers systèmes, du type journal des connexions du serveur. Ainsi, on tire avantage de fichiers existants en les agrégeant successivement pour obtenir les valeurs de décompte précitées à l'étape d).

Par exemple, on peut utiliser un extracteur d'informations (par exemple de type « parseur ») dans des données brutes (ou « RAW DATA ») que délivre la machine, pour former à partir de ces données brutes un fichier journal du type précité. Ensuite, des informations pertinentes issues de plusieurs fichiers systèmes successifs (obtenus sur la période choisie précitée) peuvent être analysées à l'étape c) et un événement particulier, identifié dans ces fichiers systèmes successifs à l'étape c), peut faire l'objet d'un décompte d'occurrences à l'étape d). Dans une réalisation, l'historique peut alors être généré à partir d'une succession de fichiers systèmes et comporter au moins un jeu de données par événement détecté (ou plus généralement par type d'événement détecté). Une telle réalisation permet avantageusement une détection dynamique d'événements présélectionnés à l'étape b), à suivre dans l'analyse de l'étape c) et dont les occurrences sont à comptabiliser à l'étape d). Ainsi, l'historique est construit par la mise en oeuvre d'un traitement informatique au sens de l'invention, à partir d'une succession de fichiers systèmes du type précité.

Dans une réalisation, le jeu de données précité comporte au moins une horodate. Une telle réalisation permet avantageusement d'associer des références temporelles aux événements et à leurs récurrences, pour construire la variation temporelle précitée. Il peut comporter en outre, comme on le verra plus loin, au moins un identifiant de machine et un identifiant par événement (ou type d'événement).

Dans une réalisation, le jeu de données comporte au moins une valeur de comptage relative à un même événement et pour une même machine. Une telle réalisation tire avantage du traitement qu'effectue l'extracteur d'informations précité et permet de simplifier un traitement informatique ultérieur que met en oeuvre la présente invention, d'identification des événements et de comptage de leurs occurrences dans l'historique précité. Ainsi, l'étape d) peut avantageusement comporter le calcul d'un cumul de valeurs de comptage successives sur la durée choisie précitée, pour déterminer la valeur de décompte associée à cette durée. Dans une réalisation, une absence d'événement de type choisi dans l'historique est enregistrée. Une telle réalisation permet avantageusement d'identifier rapidement une telle absence. Par exemple, on peut affecter un code de couleur ou de grisé particulier pour une telle absence d'événement et identifier très rapidement cette absence dans une représentation graphique des occurrences de cet événement en fonction du temps, comme on le verra plus loin en référence à la figure 2.

De manière générale, un outil tel qu'une représentation graphique d'évolution temporelle d'événements du type représenté sur la figure 2 ou la figure 3 permet avantageusement à un homme du métier de l'informatique d'identifier très rapidement des événements et/ou des corrélations intéressantes entre événements et/ou machines. Cet outil, pour un homme du métier dans la maintenance d'un parc de machines informatiques : améliore sensiblement les interprétations des fichiers de logging classiques qu'il peut effectuer habituellement, augmente sa vitesse de réaction face à un dysfonctionnement difficilement détectable autrement, augmente ses connaissances générales relativement à l'impact d'une action qu'il peut effectuer sur une machine du parc, et permet ainsi un « auto-apprentissage » progressif de l'interprétation des représentations graphiques. Dans une réalisation, une valeur de décompte maximum est : déterminée à l'étape e) sur une pluralité d'implémentations de l'étape d) correspondant à une durée globale choisie, et utilisée en tant que valeur de référence, pour une comparaison des décomptes effectués successivement sur la durée globale choisie avec cette valeur de référence. On peut par exemple « normaliser » les décomptes en les divisant tous par ce maximum. Une telle réalisation permet avantageusement d'assigner aux décomptes précités des codes de couleur ou de niveau de gris relatifs pour une période globale donnée, dans la représentation graphique précitée.

Ainsi, à l'issue de l'étape e), il est possible d'établir une représentation graphique des valeurs de décompte successives suivant une échelle temporelle, comme on le verra plus loin en référence aux figures 2 et 3.

Dans une réalisation, la représentation graphique peut comporter des couleurs choisies de pixel (ou des niveaux de gris, bien entendu), qui sont fonction de valeurs de décomptes effectués successivement sur la durée globale précitée, lesdites valeurs étant divisées par la valeur de référence (maximum des décomptes).

Dans une réalisation, on peut assigner une couleur de pixel distincte des couleurs choisies précitées pour désigner une absence d'événement répertoriée. On peut ainsi identifier rapidement absence d'événement particulier dans la représentation graphique, comme indiqué ci-avant. Dans une réalisation, pour une surveillance de plusieurs machines informatiques, les étapes a) à e) peuvent être mises en oeuvre pour chacune des machines. On peut alors établir une représentation graphique des valeurs de décompte successives suivant une échelle temporelle, pour chacune des machines et sur une même représentation graphique. Une telle réalisation permet avantageusement de comparer les comportements respectifs des machines dans le temps et détecter éventuellement un comportement erratique d'une machine par rapport aux autres.

Dans une réalisation, pour une surveillance de plusieurs types d'événement, les étapes a) à e) sont mises en oeuvre pour chacun des types d'événement et on peut alors établir une représentation graphique des valeurs de décompte successives suivant une échelle temporelle, pour chacun des types d'événement et sur une même représentation graphique. Une telle réalisation permet avantageusement de vérifier une corrélation entre certains événements sur de mêmes machines dans le temps, ou au contraire de détecter éventuellement une décorrélation signifiant un comportement erratique d'une machine ou plusieurs machines. La présente invention peut être mise en oeuvre par l'exécution d'un programme informatique dont l'organigramme général peut correspondre par exemple à la figure 1 décrite ci-après. Ainsi, la présente invention vise aussi un tel programme informatique, comportant alors des instructions pour la mise en oeuvre du procédé ci-avant, lorsqu'il est exécuté par un processeur. L'invention peut être mise en oeuvre par un dispositif informatique, comportant des moyens de surveillance d'une ou plusieurs machines informatiques. A ce titre, l'invention vise aussi un tel dispositif (comme l'ordinateur PC par exemple de la figure 4, décrite ci-après), dont les moyens de surveillance précités comportant au moins des moyens pour : a) collecter un historique d'événements relatifs à ladite machine, b) choisir au moins un type d'événement à surveiller, c) identifier, dans l'historique, des occurrences dudit type d'événement, d) assigner une valeur de décompte relative aux occurrences dudit type d'événement, sur une durée choisie, e) répéter l'étape d) pour obtenir une variation dans le temps de la valeur de décompte. D'autres avantages et caractéristiques de l'invention apparaîtront à la lecture de la description détaillée ci-après donnée à titre d'exemple de réalisation possible, aucunement limitatif, et des dessins annexés sur lesquels : la figure 1 illustre les étapes d'un procédé au sens de l'invention, dans un exemple de réalisation non limitatif, la figure 2 est une représentation graphique donnée à titre d'exemple illustratif, pour une surveillance d'une pluralité de machines M1 à M6, la figure 3 est un exemple de représentation graphique, opérée dans le cadre d'une surveillance en temps réel d'une pluralité de serveurs en réseau, la figure 4 illustre schématiquement un dispositif pour la mise en oeuvre de l'invention. On se réfere à la figure 1 sur laquelle une pluralité de machines M1, M2, M3,..., M6, par exemple des serveurs en réseau, transmettent des données brutes (étape S1) à une machine de surveillance mettant en oeuvre une réalisation possible du procédé au sens de l'invention. Ces données brutes sont interprétées par un module logiciel PARS, tel qu'un extracteur d'informations (ou « parser » en anglais), à l'étape S2, pour construire un fichier journal de type « Log » (pour « Logging » en anglais), obtenu à l'étape S3. Plus précisément, un tel fichier est construit à chaque événement particulier (erreur, notamment de connexion, ou toute autre information de fonctionnement de façon générale). Ainsi, il répertorie tous les événements intervenus pour une machine quelconque M1 à M6. Le fonctionnement habituel d'un parser du type précité, pour la construction du fichier journal (dit « fichier de logs »), consiste plus particulièrement à horodater chaque événement, pour chaque machine, et à le répertorier dans un tel fichier de log, en affectant une variable de comptage ou « compteur » à cet événement. Cette variable peut par exemple représenter une durée liée à l'événement (par exemple une attente de réponse de N secondes d'un serveur), ou encore un nombre d'occurrences liées à l'événement (par exemple N tentatives de connexion successivement échouées, ou au contraire réussies), ou autres.

Ainsi, la succession de fichiers de logs formant l'historique des événements obtenu à l'étape S6 de la figure 1, comporte, par exemple : - une horodate HR1, HR2, ..., associée à chaque événement, un identifiant de machine Ml, M2, ..., un identifiant d'événement EV1, EV2, ..., (par exemple des codes d'erreurs de connexion de type http 404, ou au contraire de connexion réussie, par exemple de type http 200, ou autres), un compteur Cl, C2, ..., pour chaque événement et pour chaque machine. Dans le procédé décrit ici, on peut de préférence définir au moins un événement ou un type d'événement EV_T à surveiller en particulier (par exemple tous les événements relatifs à des connexions de serveur réussies selon un code http 200, ou 220, etc.), à l'étape S4. Ainsi, l'événement retenu à l'étape S5 étant l'événement EV1 dans l'exemple représenté, seules les « lignes d'événement » comportant l'identifiant EV1 sont retenues à l'étape S7, dans un exemple de réalisation. Bien entendu, il est possible en variante de « filtrer » l'historique en recherchant plusieurs événements à la fois ou mener la recherche d'événement(s) sur un nombre limité de machines sélectionnées.

La récupération des fichiers de logs (étape S6) et le « filtrage » des fichiers pour la recherche d'événement EV1 sont menés régulièrement, pendant une durée T choisie par exemple pendant une minute à l'étape S8, et on collecte ainsi, toutes les durées T, l'ensemble des fichiers de logs concernant l'événement EV1 dans l'exemple représenté, à l'étape S9. A l'étape S10, on peut avantageusement mettre en oeuvre un module informatique pour : rechercher dans cet ensemble l'événement EV1 intervenu sur une même machine, calculer un cumul des compteurs pour cette machine (C1+C7=C1N pour la machine Ml, C3+C12=C3N pour la machine M3, etc.), et ce, pour une même période TN.

Le module informatique précité peut utiliser à cet effet par exemple une reconnaissance de chaine de caractères pour traiter les lignes de fichiers logs, les regrouper par machine, cumuler leur compteurs, etc. Un tel module informatique permet ainsi de construire l'historique précité. Il peut prendre la forme d'un composant (mémoire judicieusement programmée à l'aide d'un programme informatique au sens de l'invention) et être compris dans un dispositif du type représenté sur la figure 4 décrite plus loin. A cet effet, l'invention vise aussi un tel module informatique. A l'étape S11, on obtient ainsi pour les périodes successives, TN-1, TN, TN+1, etc., une variation dans le temps des compteurs C1N-1, CiN, C1N+1 ; C3N-1, C3N, C3N+1 etc., associés à chaque machine Ml, M3, etc. A cet effet, le module informatique précité peut mettre en forme un fichier informatique, correspondant à l'historique précité, mais aménagé avec les décomptes des valeurs associées aux événements recherchés, comme illustré sur la figure 1 à l'étape S11. Ce fichier informatique peut prendre la forme d'un tableur répertoriant les événements et les décomptes associés à ces événements sur des plages temporelles successives. Par exemple, chaque plage temporelle peut être préalablement choisie (par exemple de quinze minutes). Ainsi, chaque décompte sur une plage temporelle correspond à un cumul de quinze compteurs associés à un événement particulier et figurant dans chaque fichier de logs, si chaque fichier de logs est reçu toutes les minutes typiquement. A l'étape S12, les données de ce fichier sont mises en forme pour élaborer une représentation graphique de ces variations temporelles, par exemple pour chaque machine, comme on le verra plus loin en référence à la figure 2. A cet effet, le module informatique précité, une fois que le fichier des décomptes sur les plages temporelles successives est établi, peut coopérer avec une interface graphique pour élaborer une représentation graphique des valeurs de décompte par plage temporelle, comme illustré sur la figure 2 ou la figure 3. Il peut être avantageux en outre d'enregistrer une absence d'occurrence d'un événement pour une machine donnée : par exemple, pour la machine M2, dans l'exemple de la figure 1, le cumul de valeurs de compteurs est « 0 » (de même pour la machine M4). Ainsi, l'absence d'occurrence est une information que l'on peut enregistrer et qui s'illustre, comme on le verra plus loin en référence à la figure 2, par un code de couleur ou de niveau de gris différent dans une représentation graphique de la variation temporelle précitée. Dans l'exemple de la figure 2, la couleur liée à une absence d'occurrence est noire. En outre, à l'étape S12, on repère le maximum, parmi les cumuls de compteurs associés aux machines, et on procède dans l'exemple décrit à une normalisation du cumul de compteurs par rapport à ce maximum. Ainsi, si, dans l'exemple, pour l'événement EV1 et dans la période TN, le maximum de cumul CiN est repéré pour la machine Ml, tous les cumuls sont divisés par ce maximum. La valeur résultant de cette division, pour la machine M3, est alors CS/CS, dans l'exemple représenté. Il peut être ensuite assigné un code de couleur ou de niveau de gris (par exemple des doubles hachures serrées sur la figure 2) pour la valeur C1N/C1N=1, tandis qu'un code de couleur ou de niveau de gris différent (par exemple des hachures simple ou des périodes représentées en blanc sur la figure 2) est assigné pour des valeurs CS/CS inférieures à 1, selon un dégradé adapté de couleurs ou de niveau de gris de pixels. A titre purement d'exemple illustratif, il peut être prévu, en référence à la figure 2, que : des rapports de cumuls strictement supérieurs à 0 et inférieurs à 1/3, sont représentés en blanc, des rapports de cumuls strictement supérieurs à 1/3 et inférieurs à 2/3, sont représentés par des hachures simples, et des rapports de cumuls strictement supérieurs à 2/3 et inférieurs ou égaux à 1, sont représentés par des doubles hachures. On comprendra ainsi qu'un rapport proche de 0 mais supérieur à 0 est représenté en blanc, tandis qu'un nombre d'occurrences nul est représenté en noir, pour bien distinguer ces deux types de résultats. On obtient ainsi, à l'étape S13, un graphique du type représenté sur la figure 2, sur lequel : l'abscisse est une échelle temporelle, représentant une succession de périodes TN-1, TN, TN+1, etc., l'ordonnée représente, pour chaque machine Ml, ..., M6 : o de premiers cumuls d'occurrences NC liées à un premier type d'événement, ici un nombre de connexions des machines (M1(NC), ..., M6(NC)), et o de seconds cumuls d'occurrences liées à un deuxième type d'événement, ici un nombre d'erreurs (de type « ER1 ») de connexions des machines (M1(ER1), ..., M6(ER1)). Par exemple, le type d'erreur ER1 peut être défini par un cumul des erreurs de type http 4xx (400 et suivantes) et 5xx (500 et suivantes).

D'ailleurs, on comprendra que plusieurs « sous-événements » peuvent être regroupés et cumulés pour suivre un type d'événement général. Par exemple, ici, les décomptes relatifs aux connexions erronées de type 4xx et 5xx peuvent être cumulées pour obtenir la représentation de la figure 2. Toutefois, il peut être conservé dans le fichier à partir duquel est établie la représentation graphique de la figure 2, le détail des décomptes des connexions erronées (par exemple de type 4xx, d'une part, et de type 5xx, d'autre part), pour offrir un meilleur détail sur différents types d'événement à illustrer dans une autre représentation graphique possible. Dans l'exemple de la figure 2, des machines M1 à M6 telles que des serveurs en réseau, permettent à des ordinateurs reliés à ce réseau, de se connecter à des sites distants par exemple. On note alors deux périodes particulières d'activité soutenue T1 et T3, puisque le nombre de connexions NC augmente fortement pour l'ensemble des machines, en moyenne, pendant ces périodes. On remarque une corrélation du nombre d'erreurs de connexion ER1 avec le nombre de connexions NC réalisées, ce qui peut s'expliquer bien entendu par un nombre d'erreurs statistiquement croissant avec le nombre de connexions demandées.

Toutefois, on observe pour la machine M4 un nombre d'erreurs plus important avant la période T2, que pour les autres machines, et ce, y compris dans des plages temporelles à faible nombre de connexions. Cette observation, rapide sur un graphe du type correspondant à la figure 2, permet de diagnostiquer très vite un comportement erratique de la machine M4. La représentation en noir pour la machine M4 (M4(NC)) sur la période T2 signifie que le nombre de connexions est nul sur cette période pour cette machine M4. Cette observation peut être interprétée par exemple par un redémarrage de cette machine sur cette période T2. Bien entendu, le nombre d'erreurs de connexion pour la même période T2 est nul. Cette intervention de redémarrage de la machine M4 a eu pour effet de générer moins d'erreurs de connexion, ce qui s'observe effectivement pour la machine M4 après la période T2, et pendant la période T3 correspondant pourtant à une période de forte activité. Bien entendu, l'exemple de la figure 2 est présenté ici à titre didactique. On peut se référer à la figure 3 présentant un cas réel illustrant le nombre de connexions réussies (http 200) pour un parc d'une pluralité de serveurs (en ordonnées) en fonction du temps (abscisses). Le nombre maximum de connexions réussies est représenté ici en clair et le nombre de connexions réussies est d'autant plus foncé qu'il est décroissant. On relèvera d'ailleurs qu'il est possible de marquer sur la représentation graphique des caractères alphanumériques pour identifier certains événements ou types d'événement associés aux connexions réussies, ce qui permet ainsi d'enrichir encore la représentation graphique.

On remarque sur la figure 3 une période de forte activité correspondant à une zone entourée et portant la référence EV. Toutefois, cette forte activité ne concerne pas tous les serveurs, ce qui témoigne d'un fonctionnement inhomogène entre serveurs. On relèvera sur la figure 3 qu'il est possible en outre d'indiquer sur la représentation graphique le type d'événement suivi (en caractères alphanumériques). Cette information peut être interprétée et traitée par un utilisateur d'un tel graphe, par exemple un gestionnaire administrateur du parc de serveurs, à partir d'un ordinateur PC à sa disposition et relié à ces serveurs en réseau R (comme illustré sur la figure 4). A cet effet, le dispositif PC comporte une interface de communication COM reliée aux machines M1, M2, M3, etc., via le réseau R, ainsi que des moyens physiques tels qu'un processeur 1.1.13 et une mémoire de travail MEM pour construire, selon le procédé de la figure 1, le fichier donnant les valeurs de décompte en fonction des plages temporelles successives, pour chaque machine, et, de là, le graphe de la figure 2 ou de la figure 3. Le dispositif PC peut comporter des connexions à des périphériques tels qu'un écran ECR et/ou une imprimante IMP permettant à un utilisateur de visualiser le graphe, ainsi que des moyens de saisie (tels qu'un clavier par exemple CLA) lui permettant de paramétrer la représentation graphique des événements. L'utilisateur du dispositif PC peut alors intervenir pour reconfigurer une machine, la redémarrer ou autre. Dans une variante plus sophistiquée, le dispositif PC de la figure 4 peut être équipé d'un module informatique de diagnostic d'événements à partir d'une lecture numérique d'un graphe tel que représenté sur la figure 2 ou la figure 3. Outre un diagnostic écrit que peut délivrer un tel dispositif PC, il peut, en complément ou en variante, lancer à destination d'une ou plusieurs machines surveillées, des ordres à exécuter en fonction de la variation temporelle liée à un événement identifié (par exemple une mise à jour de version informatique avec redémarrage du serveur, suite à une détection d'erreurs plus fréquentes que sur les autres serveurs).

Bien entendu, la présente invention ne se limite pas à la forme de réalisation décrite ci-avant à tire d'exemple ; elle s'étend à d'autres variantes. Ainsi, par exemple, le dispositif PC de la figure 4 présenté ci-avant sous la forme d'un ordinateur distant des machines Ml, M2, etc., peut en variante être l'une de ces machines, en tant que machine maître, alors que les autres machines sont esclaves. On a décrit ci-avant un exemple de machines en tant que serveurs. Néanmoins, l'invention s'applique à toute machine susceptible d'être surveillée par des moyens informatiques.

Claims (15)

1. REVENDICATIONS1. Procédé mis en oeuvre par des moyens informatiques, de surveillance d'une ou plusieurs machines informatiques, comportant les étapes : a) collecter un historique (S6) d'événements relatifs à ladite machine, b) choisir au moins un type d'événement à surveiller (S4), c) identifier, dans l'historique, des occurrences dudit type d'événement (S7), d) assigner une valeur de décompte relative aux occurrences dudit type d'événement, sur une durée choisie (S10), e) répéter l'étape d) pour obtenir une variation dans le temps de la valeur de décompte (S11).
2. 2. Procédé selon la revendication 1, dans lequel ledit historique est construit à partir d'une succession de fichiers systèmes de type journaux (LOG).
3. 3. Procédé selon la revendication 2, dans lequel un extracteur d'informations (PARS) de données brutes que délivre la machine génère chaque fichier système (LOG), chaque fichier système comportant au moins un jeu de données par événement détecté.
4. 4. Procédé selon la revendication 3, dans lequel le jeu de données comporte au moins une horodate (HR1).
5. 5. Procédé selon l'une des revendications 3 et 4, dans lequel le jeu de données comporte au moins une valeur de comptage relative à un même événement et pour une même machine (Cl).
6. 6. Procédé selon la revendication 5, dans lequel l'étape d) comporte un cumul (C1N) de valeurs de comptage successives sur ladite durée choisie pour déterminer ladite valeur de décompte.
7. 7. Procédé selon l'une des revendications précédentes, dans lequel une absence d'événement de type choisi dans l'historique est enregistrée. 30
8. 8. Procédé selon l'une des revendications précédentes, dans lequel une valeur de décompte maximum est : déterminée à l'étape e) sur une pluralité d'implémentations de l'étape d) correspondant à une durée globale choisie, et 35 utilisée en tant que valeur de référence, pour une comparaison des décomptes effectués successivement sur ladite durée globale choisie avec ladite valeur de référence.
9. 9. Procédé selon l'une des revendications précédentes, dans lequel, à l'issue de l'étape e), on établit une représentation graphique des valeurs de décompte successives suivant une échelle temporelle (S13).
10. 10. Procédé selon la revendication 9, prise en combinaison avec la revendication 8, dans lequel la représentation graphique comporte des couleurs choisies de pixel, fonction de valeurs de décomptes effectués successivement sur ladite durée globale (TN) et divisées par ladite valeur de référence.
11. 11. Procédé selon la revendication 10, prise en combinaison avec la revendication 7, dans lequel on assigne une couleur de pixel distincte desdites couleurs choisies pour désigner une absence d'événement répertoriée.
12. 12. Procédé selon l'une des revendications 9 à 11, pour une surveillance de plusieurs machines informatiques, dans lequel les étapes a) à e) sont mises en oeuvre pour chacune desdites machines et dans lequel on établit une représentation graphique des valeurs de décompte successives suivant une échelle temporelle, pour chacun desdites machines sur une même représentation graphique.
13. 13. Procédé selon l'une des revendications 9 à 12, pour une surveillance de plusieurs types d'événement, dans lequel les étapes a) à e) sont mises en oeuvre pour chacun des types d'événement et dans lequel on établit une représentation graphique des valeurs de décompte successives suivant une échelle temporelle, pour chacune desdits types d'événement sur une même représentation graphique.
14. 14. Programme informatique, caractérisé en ce qu'il comporte des instructions pour la mise en oeuvre du procédé selon l'une des revendications précédentes, lorsqu'il est exécuté par un processeur.
15. 15. Dispositif informatique, comportant des moyens de surveillance d'une ou plusieurs machines informatiques, lesdits moyens de surveillance (COM, IJP, MEM) comportant au moins des moyens pour : a) collecter un historique d'événements relatifs à ladite machine, b) choisir au moins un type d'événement à surveiller, c) identifier, dans l'historique, des occurrences dudit type d'événement, d) assigner une valeur de décompte relative aux occurrences dudit type d'événement, sur une durée choisie, e) répéter l'étape d) pour obtenir une variation dans le temps de la valeur de décompte.