Le projet SoftScanner : Comment tracer automatiquement votre front-end ?

Suite à la coopération de trois institutions : le Université de Montpellier, le Centre National de Recherche Scientifique, et la société Berger-Levrault, le projet SoftScanner est en cours. SoftScanner est une approche guidée par le modèle pour la génération automatique de configurations d'ancrage optimales pour les opérations de traçage d'exécution de systèmes logiciels.

Contexte et problème

Les développeurs écrivent des "instructions de journalisation" dans le code source pour extraire des informations utiles liées au comportement du système au moment de l'exécution. Une instruction de journalisation telle que alert/warn consiste généralement en un événement enregistré à l'aide de texte statique et de variables liées au contexte de l'événement (par exemple, warn ("Unable to access hive" + root-path)). Au moment de l'exécution, l'invocation de ces instructions de journalisation génère des journaux qui peuvent être utilisés pour diverses activités de développement/maintenance de logiciels, telles que la correction de bogues, la détection d'anomalies, les résultats d'analyses de tests et la surveillance du système.

En outre, la taille croissante des applications et le besoin grandissant de ces journaux en raison de leur grande utilité conduisent les développeurs à intégrer de grandes quantités d'instructions de journalisation dans leur code source. Par exemple, le serveur OpenSSH contient 3407 instructions de journalisation dans sa base de code. Cette tendance est encore encouragée par la disponibilité d'infrastructures de traitement des logs telles que Splunk et ELK stack qui facilitent l'analyse systématique des fichiers logs collectés.
Une question importante qui s'est posée en rapport avec ce besoin d'enregistrement est la suivante la difficulté d'identifier une correspondance exacte entre la couverture des opérations de traçage et les objectifs de l'exploitation forestière. Une correspondance inexacte se produit dans les cas suivants :

  • Une couverture surdimensionnée. Il peut s'agir d'un nombre surdimensionné d'instructions de traçage exécutées ou d'une quantité surdimensionnée de données collectées.
  • Couverture partielle. La couverture partielle ne renvoie qu'un sous-ensemble de l'ensemble de données nécessaire pour atteindre l'objectif de journalisation. La couverture partielle peut être le résultat d'un ensemble insuffisant d'instructions de traçage ou d'opérations de traçage ne renvoyant qu'un sous-ensemble de l'ensemble de données requis.
  • Couverture incorrecte. Ce type de couverture ne renvoie pas les bonnes données nécessaires (adaptées) pour atteindre l'objectif d'enregistrement fixé. Une couverture peut être mal adaptée par rapport aux instructions de traçage choisies (pas les bonnes instructions) ou par rapport aux données collectées (pas les bonnes données).

Un deuxième problème majeur avec la journalisation est le manque de flexibilité dans la couverture. Par exemple, une couverture mise en place pour satisfaire un objectif est difficile à adapter pour satisfaire un autre objectif (par exemple, si les objectifs initiaux changent ou si les objectifs ne sont pas les mêmes à différentes périodes).
Ces problèmes de journalisation peuvent réduire considérablement l'utilité des journaux et/ou rendre leur utilisation complexe et nécessiter des coûts considérables (expertise humaine, temps de paramétrage, temps d'exploitation, etc.) Par exemple, une couverture surdimensionnée entraîne une détérioration des performances de l'application journalisée ; l'absence d'instructions de journalisation dans des parties critiques du code source peut empêcher les développeurs d'avoir une connaissance suffisante du fonctionnement du système ; une description textuelle trompeuse dans les déclarations de journalisation peut conduire à des décisions erronées de la part des opérateurs du système ; et les grandes quantités d'informations dans les journaux empêcheraient les développeurs d'identifier les informations importantes.

Proposition

Notre objectif pour cette proposition est de définir une approche et un cadre général pour le contrôle du processus d'enregistrement des logiciels. Cela comprend 5 axes :

  • Définition complète de la configuration du traçage
  • Génération statique de configurations optimales de traces d'exécution.
  • Génération dynamique de configurations optimales de traçage en cours d'exécution.
  • Génération de configurations de traces pilotée par le modèle.
  • Interaction via la visualisation pour l'adaptation des configurations de traçage.

Pour ce projet, nous nous concentrerons uniquement sur l'axe 1 : Définition complète de la configuration du traçage.
L'objectif de cet axe est d'automatiser le processus de génération de configurations de traçage à l'exécution en fonction d'un objectif donné. Une configuration de traçage représente une liste de couples constitués d'un type d'instruction de traçage (exemples : warn, info, error, etc.) et d'une position dans le code source où cette instruction doit être ancrée (add). Pour ce faire, il est nécessaire d'identifier les objectifs de traçage de l'exécution et de définir l'ensemble exhaustif des opérations de traçage nécessaires pour satisfaire un ou plusieurs objectifs. Par ensemble exhaustif, on entend ici tous les couples (instruction de traçage, position de traçage) qui permettent de répondre au besoin et sans aucune réduction du nombre de ces couples basée sur des heuristiques/techniques d'optimisation de leur nombre. Cela passe par :

  • La proposition d'un modèle de raffinement des objectifs de traçage. Ce raffinement sera basé sur les modèles de raffinement des fonctionnalités de qualité logicielle proposés dans la littérature comme le modèle ISO/IEC 9126 qui propose de raffiner successivement les fonctionnalités en sous-fonctionnalités, propriétés et métriques. A titre d'exemple, parmi les objectifs à raffiner, on peut citer la détection des incidents de sécurité, l'analyse des anomalies ou le profilage (pour capturer le comportement des utilisateurs).
  • L'association objectif-traçage. Il s'agit de proposer pour chaque sous-configuration de traçage permettant de répondre au besoin d'évaluation (mesure) pour chaque sous-objectif intervenant dans le raffinement d'un objectif global tel que le test ou l'analyse d'anomalie. Une sous-configuration de traçage est un ensemble de données collectées par un ensemble d'opérations de traçage ancrées à des positions déterminées dans le code source.

Il convient de noter que le modèle de raffinement des objectifs de traçage (inspiré du modèle de caractéristiques ISO/IEC 9126) raffine successivement chaque objectif en sous-objectifs jusqu'à un niveau où l'objectif peut être satisfait par un ensemble de données pouvant être extraites par une sous-configuration de traçage. L'ensemble des sous-configurations de traçage définies par raffinement successif d'un objectif de traçage donné constitue la configuration exhaustive à associer à cet objectif.
Quant aux autres axes, ils feront l'objet d'un autre contrat (une thèse a priori).

Plus ...

Retour en haut