Multilayer virtualized systems analysis with kernel tracing

This paper studies interactions between virtual machines and their host through the sharing of resources like physical CPUs. We present an analysis based on kernel tracing that erases the bounds between virtual machines and their host to reduce the multilayer system into a single layer. For this analysis we developed a view that displays a time line for each host's CPU, showing across time which process is running, even if it is from a virtual machine. By using a system of filters, we added the possibility to highlight in this view either traced machines, virtual CPUs or specific processes. This last feature grants the possibility to precisely see on the host where and when a virtual machine's thread is running

Fine-grained preemption analysis for latency investigation across virtual machines

This paper studies the preemption between programs running in different virtual machines on the same computer. One of the current monitoring methods consist of updating the average steal time through collaboration with the hypervisor. However, the average is insufficient to diagnose abnormal latencies in time-sensitive applications. Moreover, the added latency is not directly visible from the virtual machine point of view. The main challenge is to recover the cause of preemption of a task running in a virtual machine, whether it is a task on the host computer or in another virtual machine. We propose a new method to study thread preemption crossing virtual machines boundaries using kernel tracing. The host computer and each monitored virtual machine are traced simultaneously. We developed an efficient and portable trace synchronization method, which is required to account for time offset and drift that occur within each virtual machine. We then devised an algorithm to recover the root cause of preemption between threads at every level. The algorithm successfully detected interactions between multiple competing threads in distinct virtual machines on a multi-core machine

A flexible data-driven approach for execution trace filtering

Execution traces are frequently used to study system run-time behaviour and to detect problems. However, the huge amount of data in an execution trace may complexify its analysis. Moreover, users are not usually interested in all events of a trace, hence the need for a proper filtering approach. Filtering is used to generate an enhanced trace, with a reduced size and complexity, that is easier to analyse. The approach described in this paper allows to define custom filtering patterns, declaratively in XML, to concentrate the analysis on the most important and interesting events. The filtering scenarios include syntaxes to describe various analysis patterns using finite state machines. The patterns range from very simple event filtering to complex multi-level event abstraction, covering various types of synthetic behaviours that can be captured from execution trace data. The paper provides the details on this data-driven filtering approach and some interesting use cases for the trace events generated by the LTTng Linux kernel tracer

A declarative framework for stateful analysis of execution traces

With newer complex multi-core systems, it is important to understand applications’ run-time behaviour to be able to debug their executions, detect possible problems and bottlenecks and finally identify potential root-causes. Execution traces usually contain precise data about applications’ execution, with which analysis and abstraction at multiple levels, they can provide valuable information and insights about the applications’run-time behaviour. However, with multiple abstraction levels, it becomes increasingly difficult to find the exact location of detected performance or security problem. Tracing tools provide various analysis views to help understand these problems. However, these views are not somehow enough to uncover all aspects of the underlying issues. The developer is in fact the one who best knows his application. Therefore, a declarative approach that enables users to specify and build their custom analysis based on their knowledge, requirements and problems can be more useful and effective. In this paper we propose a generic declarative trace analysis framework to analyze, comprehend and visualize execution traces. This enhanced framework builds custom analysis based on a specified modelled state, extracted from a system execution trace and stored in a special purpose database. The proposed solution enables users to first define their different analysis models based on their application and requirements, then visualize these models in many alternate representations (Gantt chart, XY chart, etc.), and finally filter the data to get some highlights or detect some potential patterns. Several sample applications with different operating systems are shown using trace events gathered from Linux and Windows kernel and user-space levels

Multi-scale navigation of large trace data: A survey

Dynamic analysis through execution traces is frequently used to analyze the runtime behavior of software systems. However, tracing long running executions generates voluminous data, which are complicated to analyze and manage. Extracting interesting performance or correctness characteristics out of large traces of data from several processes and threads is a challenging task. Trace abstraction and visualization are potential solutions to alleviate this challenge. Several efforts have been made over the years in many subfields of computer science for trace data collection, maintenance, analysis, and visualization. Many analyses start with an inspection of an overview of the trace, before digging deeper and studying more focused and detailed data. These techniques are common and well supported in geographical information systems, automatically adjusting the level of details depending on the scale. However, most trace visualization tools operate at a single level of representation, which are not adequate to support multilevel analysis. Sophisticated techniques and heuristics are needed to address this problem. Multi-scale (multilevel) visualization with support for zoom and focus operations is an effective way to enable this kind of analysis. Considerable research and several surveys are proposed in the literature in the field of trace visualization. However, multi-scale visualization has yet received little attention. In this paper, we provide a survey and methodological structure for categorizing tools and techniques aiming at multi-scale abstraction and visualization of execution trace data and discuss the requirements and challenges faced to be able to meet evolving user demands

Conception d'un outil de modélisation intégré pour l'indexation et l'analyse de trace

RÉSUMÉ Les simulateurs de vol sont des systèmes composés d'un système logiciel et d'actuateurs mécaniques qui recréés la dynamique d'un vrai vol avec un aéronef et qui sont notamment utilisés par les compagnies de transport aérien pour former leurs futurs pilotes. Ces simulateurs doivent recréer des scénarios de vol permettant d'exécuter des itinéraires réguliers de vol ou de confronter les pilotes à différentes situations d'urgence qui peuvent subvenir lors d'un vrai vol (p. ex., une tempête violente). Puisque les simulateurs de vol ont un impact direct sur la qualité de formation des pilotes, une batterie exhaustive de tests s'impose à chaque fois qu'une nouvelle version d'un simulateur doit être mise en opération. Une bonne partie de ces tests requièrent l'intervention d'un pilote qui stimule le système en réalisant une série d'opérations de contrôle provenant de scénarios de vol préparés par des experts en aéronautique, ce qui est gourmand en temps, en ressources humaines et en ressources financières. La raison de la nécessité de réaliser tous ces tests est que le logiciel en soit est constitué de plusieurs composants de type boîte noire dont le code source n'est pas disponible, ils sont fournis tels quels par les fournisseurs du composant réel d'origine devant être simulé (p. ex., un composant hydraulique d'un aéronef que nous voulons simuler). Puisque nous n'avons pas pas accès au code source, il n'est pas possible lors de la mise-à-jour de l'un de ces composants de savoir quel sera le changement dans le comportement du simulateur. Dans le meilleur des cas, un défaut dans un composant aura un impact local et, dans le pire des cas, il peut nuire à tous les autres composants du simulateur. Il est dans ce cas nécessaire d'utiliser une stratégie de test d'une large granularité couvrant à la fois le fonctionnement des composants eux-mêmes et l'ensemble des fonctionnalités de vol du simulateur afin d'en assurer sa qualité. Dans le cadre de ces tests, afin de réduire le temps requis pour vérifier le bon comportement d'une nouvelle version d'un simulateur, nous proposons dans ce mémoire d'automatiser l'analyse des résultats de test en modélisant le comportement normal du système logiciel en utilisant de l'apprentissage automatique. Un tel modèle tente de recréer le comportement stable du système en bâtissant des règles reliant ses entrées à chacune de ses sorties. Les entrées sont constituées de métriques provenant des contrôles qui stimulent le système et les sorties sont constituées de métriques que nous pouvons observer. Nous produisons donc un modèle initial d'une version fiable du simulateur et nous validons par la suite le bon comportement des versions subséquentes en comparant leur comportement avec celui du modèle initial. Nous cherchons à voir s'il y a un écart trop important avec le modèle initial, ce nous considérons comme étant une déviation. Le but final de notre recherche est de pouvoir appliquer notre méthodologie d'analyse des résultats de test dans l'industrie de la simulation. Afin d'avoir plus de flexibilité dans nos expérimentations, nous commençons d'abord par valider l'approche avec un simulateur plus simple et ouvert. Nous utilisons donc le simulateur de vol à source libre FlightGear comme cas d'étude pour évaluer notre approche de test. Ce simulateur utilise l'engin de vol très populaire JSBsim et la librairie SimGear pour modéliser les aéronefs et simuler leur comportement dynamique dans un environnement de vol. JSBsim est notamment utilisé par la Nasa à des fins de recherche. Nous réalisons d'abord un vol manuel en utilisant des périphériques de contrôle d'un ordinateur tout en enregistrant les données contenues dans le simulateur. Le vol doit être composé de toutes les opérations régulières de pilotage afin que le modèle que l'on en extrait représente fidèlement le comportement normal du simulateur. Nous réalisons par la suite plusieurs répétitions du même vol afin d'identifier des niveaux de seuils robustes pour déterminer au delà de quels écarts un métrique d'une nouvelle version doit être considéré comme déviant par rapport au modèle. Nous élaborons à cet effet cinq scénarios de mutation du comportement de la version initiale de notre simulateur afin de générer différentes versions ayant des métriques qui respectent le comportement normal du sytème ou présentant une déviation du comportement normal reliée à un problème fonctionnel. En sachant d'avance quelles mutations présentent des déviations et avec l'aide d'experts identifiant précisément les métriques qui dévient de leur comportement normal, nous pouvons construire un oracle avec lequel nous évaluons la précision et le rappel de notre approche de détection. En particulier, dans le cadre de notre étude empirique sur FlightGear, nous modifions une version initiale du simulateur en y injectant cinq différentes mutations qui n'ont pas d'impact grave ou qui engendrent des problème fonctionnels avec lesquels nous évaluons notre approche. Les résultats montrent qu'en choisissant des niveaux de seuil initiaux lors d'une première calibration, notre approche peut détecter les métriques ayant des déviations avec un rappel majoritairement de 100% (un seul cas de mutation à 50%) et une précision d'au moins 40%. En ce qui a trait aux mutations ne changeant pas le comportement normal du simulateur, notre approche a un taux de fausses alarmes de 60%. Nous montrons également qu'avec une base de données plus large, il est possible de calibrer notre approche afin d'améliorer sa performance. Avec des niveaux de seuil optimaux qui sont calibrés pour chacune des mutations, nous obtenons un taux de rappel de 100% pour tous les cas, une précision d'au moins 50% pour les versions ayant des problèmes fonctionnels et un taux de fausses alarmes de 0% pour les versions n'ayant pas de problèmes fonctionnels. Afin d'ouvrir la voie pour des améliorations futures, nous utilisons notre méthodologie pour faire une petite expérimentation connexe sur JSBsim afin de détecter les déviations dans les transitions entre les états stables de chacun des métriques. Nous utilisons la même modélisation du simulateur. Les résultats montrent que nous pouvons battre une classification aléatoire des déviations. Cette nouvelle approche n'en n'est qu'à ces débuts et nous sommes convaincu que nous pouvons obtenir des résultats plus significatifs avec de futurs travaux sur le sujet. Nous proposons également dans les améliorations futures de descendre le niveau de granularité de notre modélisation du simulateur au niveau de chacun de ses composants. Cela permettrait d'isoler exactement qu'elle composant présente une déviation, et ainsi trouver la source du problème.----------ABSTRACT Flight simulators are systems composed of software and mechanical actuators used to train crews for real flights. The software is emulating flight dynamics and control systems using components off-the-shelf developed by third parties. For each new version of these components, we do not know what parts of the system is impacted by the change and hence how the change would impact the behaviour of the entire simulator. Hence, given the safety critical nature of flight simulators, an exhaustive set of manual system tests must be performed by a professional pilot. Test experts then rely on the test pilot's feedback and on the analysis of output metrics to assess the correctness of a simulator's behaviour, which consumes time and money, even more these tests must be repeated each time one of the components is updated by its vendor. To automate the analysis of test results from new simulator versions, we propose a machine learning-based approach that first builds a model that mimics the normal behaviour of a simulator by creating rules between its input and output metrics, where input metrics are control data stimulating the system and output metrics are data used to assess the behaviour of the system. We then build a behavioural model of the last-known correctly behaving version of the simulator, to which we compare data from new versions to detect metric deviations. The goal of our research is to first build a model of the simulator, then detect deviations of new simulator versions using that model, and finally develop an automatic approach to flag deviations when there are functional problems Our case study uses the open-source flight simulator Flight Gear, based on the well-known JSBsim flight dynamic engine currently used by the Nasa. Applying our approach, we first drive a manual basic flight using computer peripherals while recording metrics in the simulator. We then use the recorded metrics to build a model of this basic execution scenario. After repeating several times our flight we have enough data to identify robust metric deviation thresholds to determine when a metric in a new version is deviating too far from the model. We generate five different versions of FlightGear by injecting harmless and harmful modifications into the the simulator, then perform again our initial flight multiple times for each of those versions while recording input and output metrics. We rely on experts identifying which output metric should be deviating in each scenario to build an oracle. Using an initial threshold, our approach can detect most of the deviations in problematic versions with a near perfect recall (only one case at 50%) and a reasonable precision of at least 40%. For the versions without harmfull deviations we get a false alarm rate of 60%. By optimizing the threshold for each version, we get a perfect recall of 100%, a precision of at least 50%, and a false alarm rate of 0% for the good behaving versions. To open the path for future work, we perform a case study on JSBsim using a variant of our basic deviation detection approach to detect transient deviations using the same model. Our results show that we can beat a random classification for one kind of deviation, however for other deviations our models do not perform as well. This new approach is just a first step towards transient deviation detection, and we are convinced that we can get better results in future work. We also propose to use finer-grained models for each component to be able to isolate the exact component causing a functional problem

Langage dédié et analyse automatisée pour la détection de patrons au sein de traces d'exécution

RÉSUMÉ La complexité des systèmes informatiques distribués et à plusieurs unités de calcul a introduit de nouvelles classes de problèmes. Ces problèmes sont difficiles à reproduire et leur complexité accrue a suggéré l'introduction de nouvelles méthodes de compréhension des systèmes. L'analyse dynamique, à l'aide de traces d'exécution, permet de comprendre les systèmes à partir de leurs données d'exécution. Les traces d'exécution enregistrent, sous forme d'événements, les informations précises et détaillées de l'exécution du système instrumenté. Pour des systèmes comme le noyau d'exploitation de Linux, le traçage fournit des événements de bas niveau (appels systèmes, fautes de pages). De plus, en quelques secondes, le fichier de trace peut enregistrer des millions d'événements. Des visionneuses de trace, telle que Trace Compass, ont été développées dans le but de fournir des analyses de la trace sous différents angles de vue tels que l’allocation des ressources ou l’usage des unités de calcul, et à un haut niveau d'abstraction. Cependant, au-delà des analyses déjà fournies par les visionneuses, les utilisateurs souhaiteraient pouvoir créer des analyses personnalisées qui représenteraient mieux leurs besoins. Par exemple, un utilisateur pourrait tenter de vérifier si le système a subi une attaque particulière. Il faudrait dans ce cas précis pouvoir appliquer à la trace une analyse spécialisée qui permettrait de vérifier la présence d’une séquence d’événements ou d’informations qui décrit l’attaque recherchée. Il existe donc un besoin quant à la nécessité d'identifier des formes particulières ou de retrouver des séquences d'intérêts au sein de la trace. Ce travail propose l'introduction d'un langage déclaratif utilisant les automates finis pour la description de patrons d'intérêts. Les patrons décrits sont ensuite passés à un analyseur élaboré afin de vérifier et repérer leurs présences au sein de traces d’exécution. L'utilisation de machines à états pour la description des patrons permet de décrire des patrons complexes. Ainsi, la mise en place d'un mécanisme de suivi de l'exécution des patrons a été réalisée. Le langage déclaratif proposé est conçu de façon déclarative en XML. Il permet de représenter avec succès tous les types de patrons rencontrés dans la littérature (patrons de détection d'attaques, patrons de test de programmes, patrons d'évaluation de performance, patrons d'agrégations des événements...). La spécification du langage proposé permet de créer des événements synthétiques qui peuvent être traités par l'analyseur au fur et à mesure qu'ils sont créés. La solution proposée dans ce mémoire devrait être capable de traiter les traces de grandes tailles (500MB et plus); la performance en terme de temps d'extraction des données est donc importante. Nous nous assurons qu'elle est au moins aussi bonne que celle des travaux antérieurs du même genre et que la déviation par rapport à la méthode d'extraction standard de Trace Compass reste acceptable. La solution proposée écrit directement les données sur le disque. Elle n’accumule donc pas d’informations en mémoire. L’analyse en terme d’espace en mémoire est donc négligeable. De plus, nous démontrons l'utilité de l'approche proposée à l'aide d'exemples concrets de cas d'utilisation. Une tentative de découverte de la source d'un défaut de requête Web est présentée ainsi qu'un exemple de détection d'attaque dans le système. Enfin, nous proposons à la fin de notre étude une liste de suggestions pour des améliorations possibles à la solution en termes de description des patrons et de réduction du temps de l’analyse.----------ABSTRACT The complexity of distributed and multi-core systems introduced new classes of problems. These problems could be difficult to reproduce and their increasing complexity has suggested the introduction of new methods of systems comprehension. Dynamic analysis, through execution traces, allows to understand the system behavior from its execution data. The execution traces record, in the form of events, accurate and detailed information about the execution of an instrumented system. For systems like the Linux kernel, tracing provides low level events such as system calls and page faults. Moreover, in a few seconds, the trace file can record millions of events. Visualizers, like Trace Compass, were developed to provide analysis of the trace from different points of view such as ressources allocation and CPU usage, and with a high-level of abstraction. However, beyond the analyses that have been already provided by the visualizers, users would like to be able to create custom analyses that better represent their needs. For example, a user could attempt to verify if the system is under a particular attack. It should then be possible to apply to the trace a specialized analysis that would verify the presence of a sequence of events or information that describes the intended attack. Thus, there is a need to be able to identify patterns or to find predefined sequences of events within the trace. This work proposes the introduction of a declarative automata-based pattern description language. The described patterns are then passed to an analyzer designed to efficiently verify and detect their presence within the execution trace. The use of state machines allows to describe complex patterns. Thus, a mechanism to follow the execution of the patterns has been implemented. The proposed language is designed declaratively in XML. It has successfully represented all the types of pattern found in the literature (security attack patterns, testing patterns, system performance patterns, events aggregation patterns, ...). The language specification allows to create synthetic events that can be processed by the analyzer as they are created. This proposal should be able to process large trace files (1GB or more). Thus, performance in terms of time of data extraction is important. We ensure that this solution is at least as good as previous ones of the same kind and that the deviation from the standard extraction method of Trace Compass remains acceptable. The proposed solution writes the data directly to disk. It therefore does not accumulate information in memory. The analysis in terms of memory space is negligible. In addition, we try to demonstrate the usefulness of our approach with some application test cases. An example of an attempt to find the root cause of a web request defect and an example of attack detection in a system are presented. Finally, we propose at the end of this study a list of suggestions for possible improvements of the solution in terms of the description of patterns and reduction of the time of the analysis

Méthodes efficaces de parallélisation de l'analyse de traces noyau

RÉSUMÉ Les architectures hautement parallèles sont de plus en plus répandues, non seulement dans les systèmes haute-performance, mais aussi dans les ordinateurs grand public. La détection et la résolution de problèmes lors de l’exécution parallèle de logiciels sur ces types de systèmes sont des tâches complexes auxquelles les outils classiques de débogage ne sont pas adaptés. Des études précédentes ont démontré que le traçage s’avère être une solution efficace à la résolution de problèmes dans des systèmes hautement parallèles. Cependant, l’augmentation du nombre d’unités parallèles dans les systèmes tracés cause aussi une augmentation de la quantité de données générées par le traçage. Les architectures distribuées ne font qu’exacerber ce problème puisque chaque nœud peut contenir plusieurs processeurs multicœurs. Les données de trace doivent être analysées par un outil d’analyse de traces afin de pouvoir extraire les métriques importantes qui permettront de résoudre les problèmes. Or, les outils d’analyse de traces disponibles sont conçus de manière à s’exécuter séquentiellement, sans tirer avantage des capacités d’exécution parallèle. Nous nous retrouvons donc face à une différence de plus en plus grande entre la quantité de données produite par le traçage et la vitesse à laquelle ces données peuvent être analysées. La présente recherche a pour but d’explorer l’utilisation du calcul parallèle afin d’accélérer l’analyse de traces. Nous proposons une méthode efficace de parallélisation de l’analyse de traces qui supporte la mise à l’échelle. Nous nous concentrons sur les traces en format CTF générées par le traceur LTTng sur Linux. La solution présentée prend en compte des facteurs clés de la parallélisation efficace, notamment un bon équilibrage de la charge, un minimum de synchronisation et une résolution efficace des dépendances de données. Notre solution se base sur des aspects clés du format de trace CTF afin de créer des charges de travail équilibrées et facilement parallélisables. Nous proposons aussi un algorithme permettant la détection et la résolution de dépendances de données, pendant l’analyse de traces, qui utilise au minimum le verrouillage et la synchronisation entre les fils d’exécution. Nous implémentons trois analyses de traces parallèles à l’aide de cette solution : la première permet de compter les événements d’une trace, la seconde de mesurer le temps CPU utilisé par processus et la troisième de mesurer la quantité de données lues et écrites par processus. Nous utilisons ces analyses afin de mesurer la mise à l’échelle possible de notre solution, en utilisant le concept d’efficacité parallèle. Puisque les traces peuvent être potentiellement très volumineuses, elles ne peuvent être gardées en mémoire et sont donc lues à partir du disque. Afin d’évaluer l’impact de la performance des périphériques de stockages sur notre implémentation parallèle, nous utilisons un programme simulant des charges de travail sur le CPU et sur le disque, typiques de l’analyse de traces. Nous évaluons ensuite la performance de ce programme sur plusieurs types de périphériques de stockage, tels que des disques durs et des disques SSD, afin de démontrer que la performance de l’analyse parallèle de traces n’est pas gravement limitée par les accès au disque, surtout avec des périphériques de stockage modernes. Nous utilisons aussi ce programme afin d’évaluer l’effet d’améliorations futures au décodage de la trace, sur la mise à l’échelle de l’analyse parallèle. Notre solution offre une efficacité parallèle au-dessus de 56% jusqu’à 32 cœurs, lors de l’exécution de l’analyse de traces parallèle, ce qui signifie une accélération de 18 fois par rapport au temps de traitement séquentiel. De plus, les résultats de performance obtenus à partir du programme de simulation confirment que l’efficacité parallèle n’est pas sérieusement affectée par les accès au disque lorsque des périphériques de type SSD sont utilisés. Cette observation tient d’ailleurs même lorsque le décodage de la trace est plus rapide. Certains facteurs qui nuisent à la mise à l’échelle sont dus au modèle séquentiel de la bibliothèque de lecture de traces et peuvent être réglés avec une refonte de celle-ci, tandis que d’autres proviennent de goulots d’étranglement au sein du module de gestion de la mémoire du noyau et pourraient être améliorés ou contournés.----------ABSTRACT Highly parallel computer architectures are now increasingly commonplace, whether in com- mercial or consumer-grade systems. Detecting and solving runtime problems, in software running in a parallel environment, is a complicated task, where classic debugging tools are of little help. Previous research has shown that tracing offers an efficient and scalable way to resolve these problems. However, as the number of parallel units in the traced system increases, so does the amount of data generated in the trace. This problem also compounds when tracing distributed systems, where each individual node may have many-core processors. Trace data has to be analyzed by a trace analysis tool, in order to extract significant metrics which can be used to resolve problems. However, the current trace analysis tools are designed for serial analysis on a single thread. We therefore have an ever widening gap between the amount of data produced in the trace and the speed at which we can analyse this data. This research explores the use of parallel processing in order to accelerate trace analysis. The aim is to develop an efficient and scalable parallel method for analyzing traces. We focus on traces in the CTF format, generated by the LTTng tracer on Linux. We present a solution which takes into account key factors of parallelization, such as good load balancing, low synchronization overhead and an efficient resolution of data dependencies. Our solution uses key aspects of the CTF trace format to create balanced, parallelizable workloads. We also propose an algorithm to detect and resolve data dependencies during trace analysis, with minimal locking and synchronization. Using this solution, we implement three trace analyses (counting events; measuring CPU time per-process; measuring amount of data read and written per-process) which we use in order to assess the scalability in terms of parallel efficiency. Traces, being potentially very large, are not kept entirely in memory and must be read from disk. In order to assess the effect of the speed of storage devices on the parallel implementation of trace analysis, we create a program that simulates the CPU and I/O workloads typical of trace analysis. We then benchmark this program on various storage devices (e.g. HDD, SSD, etc.) in order to show that parallel trace analysis is not seriously hindered by I/O-boundedness problems, especially with modern storage hardware. We also use this program in order to assess the effect of future improvements in trace decoding on the analysis. Our solution shows parallel efficiency above 56% up to 32 cores, when running the parallel trace analyses, which translates to a speedup of 18 times the serial speed. Furthermore, benchmarks on the simulation program confirm that these efficiencies are not seriously affected by disk I/O on solid state devices, even in the case of faster trace decoding. Some factors affecting scalability are found within the serial design of the tracing library and can be fixed by a re-design, while others come from bottlenecks within the memory management unit of the kernel which could be improved or worked around

Nouvelle architecture pour les environnements de développement intégré et traçage de logiciel

La conception et le développement de logiciels requièrent souvent l’utilisation d’un Environnement de Développement Intégré (EDI) pour assister et faciliter le travail des développeurs. Les EDI offrent, à travers une interface graphique, des outils pour l’édition, la compilation et le débogage du code. Cependant, lorsque ces outils ne sont pas adaptés et suffisants pour la détection de défauts de performance sur des logiciels complexes, comme les systèmes distribués, les développeurs se tournent vers des techniques de traçage. Des logiciels appelés traceurs récoltent des informations précises pendant l’exécution du système instrumenté, et les regroupent dans une trace. Une trace peut contenir une quantité importante de données. Des outils spécialisés ont été développés afin d’en automatiser le processus d’analyse et de visualisation. Au fur et à mesure qu’un logiciel grandit et se complexifie, l’utilisation de ces outils d’analyse et de visualisation devient tout aussi importante qu’un débogueur. Néanmoins, ces outils sont complexes, autonomes et difficilement réutilisables dans d’autres systèmes. De plus, ils ne supportent pas les mêmes analyses, les mêmes formats de trace, ni les mêmes cas d’utilisation, ce qui implique que le développeur ait besoin d’installer plusieurs outils pour arriver à ses fins. Dans le cadre de ce projet, nous cherchons donc à résoudre ces problèmes et à intégrer l’analyse et la visualisation de trace non seulement dans les EDI, mais dans tout autre système qui pourrait en bénéficier, tels que les serveurs d’intégration continue ou encore les systèmes de monitorage. Par conséquent, nous proposons une nouvelle architecture logicielle flexible basée sur une approche client-serveur, d’architecture orientée service et multicouche. Notre travail s’étend à l’implémentation de l’architecture du serveur au sein du projet Trace Compass et l’implémentation de l’architecture du client au sein d’un nouveau projet appelé TraceScape. Toutes nos contributions sont disponibles à code source ouvert. Des tests de performance ont été menés afin d’évaluer le surcoût associé à la nouvelle architecture par rapport à la précédente approche, et les résultats indiquent un surcoût acceptable.----------ABSTRACT: Creating software often requires using an Integrated Development Environment (IDE) to help and facilitate the development work. With a simplified user interface, IDEs provide many useful tools such as a code editor, a compiler, and a debugger. Nonetheless, when those tools are not enough to detect performance defects in a large, complex and multithreaded system, developers use tracing techniques. A program called tracer collects accurate information during the execution of an instrumented system. A trace could contain a lot of data, and specialized tools have been developed to analyze traces automatically and show the results in interactive views. As the software grows and becomes more complex, using trace visualization tools must be part of the developer tool environment, like the debugger in the software development process. However, trace visualization tools are sophisticated, standalone and hardly reusable in other systems such as an IDE. Moreover, they have their specific trace format support, specific use cases, and specific trace analyses. Most of the time, developers need to install and use several such tools to fulfill their needs. In this research project, we aim to solve those problems and integrate trace analysis and visualization in tools such as IDEs, monitoring systems or continuous integration systems. Thus, we propose a flexible software architecture based on client-server, service-oriented architecture and layered approaches. We implemented the server architecture in the Trace Compass project and the client architecture in a new project called TraceScape. All of our contributions are available online in open source repositories. We also evaluated our proposed architecture through benchmarks, and the results show that our approach has an acceptable overhead compared to the standalone approach