Applications expérimentales

Par construction, le DIG-DAG est une structure stockant toutes les chaînes de causalité observées dans un log. Le fait qu’il soit possible de le construire en ligne laisse envisageable son utilisation pour la prédiction de pannes. Toutefois, nous nous sommes d’abord concentrés sur son utilisation en analyse de causes racines. En particulier, nous avons mis au point un système de requêtes pour extraire des sous-DIG-DAG à partir des spécifications de l’utilisateur. Dans ce chapitre, nous développons les aspects pratiques liés au DIG-DAG et, plus particulièrement, à son utilisation en analyse de causes racines. En section 5.1, nous commençons par expliciter la façon dont les outils de construction et d’exploitation du DIG-DAG présentés dans les chapitres 3 et 4 peuvent être associés à travers une méthodologie pour l’analyse de causes racines. Cette méthodologie est réalisée de bout en bout, c’est-à-dire de l’ingestion du log brut à l’extraction de sous-DIG-DAG succints et interprétables. La section 5.2 présente ensuite des données expérimentales concernant le passage à l’échelle de la structure et la capacité du DIG-DAG à stocker des motifs de causalité pertinents. Dans 5.3, nous concluons par l’application de notre méthodologie de bout en bout pour l’analyse de causes racines à un log réel. Cela nous permet de discuter quantitativement des performances de notre solution.

En particulier, l’ensemble des outils présentés ont été implémentés en Python 3. Outre l’acquisition de données expérimentales, cela nous a notamment permis de collaborer avec certaines business units de Nokia. Par ailleurs, une démo illustrant cette méthodologie a été présentée au 5G Smart Campus Event organisé par Nokia Bell Labs puis plus formellement Cette section décrit une approche utilisant l’ensemble des outils introduits par les sec- tions 3.2 et 4.1 pour l’analyse de bout en bout dans un contexte de recherche de causes racines. Dans ce contexte d’analyse de cause racine, la panne a déjà eu lieu. Par consé- quent, nous pouvons supposer que le log est donné et qu’il n’est pas nécessaire de le trai- ter en ligne (bien que certaines étapes puissent être réalisées à la volée). Dans les para- graphes 5.1.1 à 5.1.3, nous expliquons l’approche générale : le paragraphe 5.1.1 aborde les différents points à prendre en compte lors du chargement du log, la construction du DIG- DAG à partir du log ainsi chargé est traitée dans le paragraphe 5.1.2, le paragraphe 5.1.3 explique alors comment extraire les sous-DIG-DAG appropriés à l’analyse de causes racines grâce à notre outil de requête. Enfin, le paragraphe 5.1.4 présente quant à lui quelques conseils pour aborder des logs trop gros pour que l’analyse passe à l’échelle.La première étape consiste à transformer le log brut en une suite d’événements. Cela in- clut notamment de déterminer l’alphabet, de fixer la période d’activité de chaque événement ainsi que la fenêtre d’observation sur laquelle on souhaite étudier le log.

Toutefois, dans de nombreuses applications, les événements ne sont pas actifs sur un intervalle de temps mais sont déclenchés à un instant donné. Nous appelons ceux-ci des événements ponctuels. Dans ce cas, la relation de causalité potentielle temporelle n’est plus définie. Une façon de résoudre ce problème consiste à définir artificiellement la date man- quante. Celle-ci peut être choisie de plusieurs manières différentes. ), et cette horloge (resp. compteur) est décrémentée au fil du temps (resp. des arrivées d’événements). Lorsque l’un des deux atteint 0, le symbole σ est alors émis, désactivant tous les sommets étiquetés par σ. À chaque fois qu’un sommet est désactivé, son horloge et son compteur sont réinitialisés à 0.Dans certains logs d’alarmes, les temps d’émissions ont lieu à des instants précis. C’est ainsi le cas des KPIs qui sont émis périodiquement (toutes les cinq minutes par exemple comme c’est le cas par défaut de l’outil Cacti [section 1.1.1]). Dans ce cas, afin d’assurer la causalité temporelle, un bon choix serait de définir une période d’activité un peu plus longue que la périodicité des mesures.Par exemple, supposons que l’on veuille extraire des parties du DIG-DAG telles que les arcs indiquent une forte corrélation entre les sommets, c’est-à-dire extraire les motifs les plus vraisemblables permettant d’expliquer une panne. Nous définissons alors un autre système de pondérations à partir des poids des arcs définis en 3.2.4. Soit u un sommet du DIG-DAG et σ ∈ Σ tel que g(u, σ) existe. Définissons le ratio npeutalors être défini pour ne considérer que les sommets qui ont été récemment actifs. De même, il est possible de concentrer son analyse uniquement sur un groupe de machines suspectes.