 Bonjour tout le monde, je m'appelle Alain Brosseau, j'étais jusqu'à la semaine dernière associée de recherche à l'école polytechnique au laboratoire d'Orsal. Le laboratoire qui fait de la recherche sous Linux pour les systèmes hautement distribués, hautement parallèles, multicore. Un des produits issus de la recherche laboratoire et LT-NG, Linux Trace Toolkit. C'est ce que je vais vous introduire ce soir. C'est un système qui est assez bon niveau. Certains de vous ne pouvez pas être arrêtés. Je vais essayer de vulgariser et de ne pas aller trop dans le détail du noyau Linux. Et on va poursuivre vers la suite. Donc en fait, pourquoi on veut tracer? L'idée que je montre ici, on regarde, c'est une visualization d'usage CPU pour Chrome qui rende un vidéo. Et on voit en fait qu'il y a beaucoup d'usage mémoire, d'usage CPU pour entre autres Exorg. Et on peut remarquer en fait qu'est-ce qui se passe en gardant la trace. Il y a tout le temps des appels à cloc get time. Donc en fait, pour une raison bizarre, Chrome, quand qu'il visualise un vidéo, appelle tout le temps. Il veut tout le temps savoir l'heure. Donc ça explique pourquoi le CPU est tout le temps dans le tapis. Ça serait une optimisation à faire à ce niveau-là en fonction de l'architecture et tout. Donc le traçage permet d'identifier un comportement d'une application. Qu'est-ce qui se passe dans le bas niveau du système d'exploitation? Donc en quelque sorte, le traçage, c'est une forme de log, une forme de journalisation. Donc on a vu au début une façon de journaliser sur Python. Mais c'est une façon qui est un peu plus bas niveau. On veut vraiment avoir les événements bas niveau et à très très haute fréquence. Par exemple, tous les appels système d'exploitation, tous les appels à la base de données, tous les requêtes HTTP. Donc on veut avoir des données vraiment en très grande quantité et très détaillées. C'est un peu une quelque sorte de voir à l'intérieur de ce qui se passe dans son ordi, mais à des endroits extrêmement spécifiques de notre système. Juste pour, ça se basse sur ce qu'on appelle les 13 points. Donc en fait, il faut définir des points de trace particuliers dans notre système. Il peut être esthétique ou dynamique. Bon, en partant, on t'appuie d'avoir des points de trace dans nos enraches dynamiques, dont tout par définition serait dynamique. Mais par exemple, dans le noyau, on va avoir des points de trace à des appels de fonctions très très particuliers. Par exemple, tous les sketch switch, tous les changements d'ordon d'enseur. Et on va avoir un appel, un point de tracage, pour aller noter l'information à ce niveau-là. Les caractéristiques de 13 points, d'un point de trace dans un système. Haute vitesse, une base latence, tu peux pas avoir un impact majeur sur ton système. Si tu veux un point de tracé, tu veux que ton application roule sans être affecté par le système de journalisation. On veut tout le temps noter un temps. Il y a généralement un temps très précis sur le TTNJ. Par exemple, on mesure le temps à la nanose seconde. Donc, le plus précis que tu peux avoir dans ton ordinateur, on mesure le temps à ce niveau-là. Peu importe le point de trace. Donc ça permet de mesurer vraiment des temps très précis. Et en général, on va enregistrer une charge, un payload, un message qui va nous donner une caractéristique du point de trace qui va pouvoir déboguer ce qu'on veut. En général, il y a trois usages pour le tracage. Le premier est l'apprentissage. On s'en sert après le technique dans les cours des systèmes de tracage pour vraiment découvrir comment ça marche sous le capot. Donc, par exemple, la location mémoire, on peut imaginer que quand tu demandes un espace mémoire ton système de tracage est où tu as donné, mais en fait non. En regardant le tracage, on peut vraiment aller voir qu'il va te l'allouer une fois que tu as besoin. Donc c'est un outil qui va être pédagogique. Un outil de débagage. On voit tantôt dans le printemps de Paframan, c'est un serveur qui t'a dit requête, qui sont en langue. Tu sais pas pourquoi. Donc, tu instrumentes ton code et tu permets de voir où, exactement, dans quel appel est-ce que tu le dis? Que dure? C'est-tu le réseau? Est-ce que c'est juste du processing CPU? Donc, c'est un outil pour ça. Et le troisième usage qui est utilisé en certains cas, c'est vraiment faire un enregistrement des événements, des problématiques, et pouvoir tout rejouer par après. Donc, souvent, on t'a pu tuer de déboguer avec les logs-systèmes, mais c'est souvent très, très haut au niveau. Si tu as un système, tu veux vraiment avoir le détail, donc vraiment l'image d'une boîte noire d'un avion, avoir tout le détail d'utiliser les appels-systèmes et pratiquement pouvoir rejouer qu'est-ce qui s'est passé à ce moment-là de ton système pour pouvoir déboguer de façon précise le problème. Donc, qu'est-ce qu'il y a le TTNG? Comme j'ai dit, Lex Linux Trace Toolkit, donc 2.0, donc il y a beaucoup d'historique derrière. Une liste des traceurs système disponibles sur Linux et d'autres systèmes de supportation. Donc, le TT a été inventé en 1999 et est venu pour la deuxième version de l'TTNG, donc nouvelle génération de l'TT Linux Trace Toolkit. Ceux qui font du système, vous êtes vraiment à connaissez un peu Dtrace, puis Dtrace qui est plus sur Solaris, système TAP qui est un peu son équivalent sous Linux. Et on va aussi, Ftrace et Perks sont arrivés par la suite. Et l'année passée, on a décidé de refaire une nouvelle version complète de l'TTNG. 2.0 et cette année, on a fait 3 nouveaux releases avec des fonctionnalités additionnelles qui se sont rajoutées. Pourquoi on a fait l'TTNG 2.0? Si on voulait unifier, on s'est dit en fait la question, comme l'autre présentation, on va venir le traçage à tout le monde, en tout le monde entre guillemets et développeurs, parce que jusqu'à maintenant, le traçage était souvent limité ou utile pour les développeurs noyaux. Donc on veut donner un outil facile d'utilisation pour n'importe quel développeur, développeurs web, un centre de système, développeurs d'applications, desktop, pour avoir un outil vraiment unifié. Donc pour ça, une des fonctionnalités qu'on a, c'est qu'on intègre facilement le traçage noyaux, donc on va les donner du noyaux, mais aussi de l'application, donc de façon transparente, et les corrélés avec ce qui se passe au niveau du système. C'est disponible sur toutes les distributions Linux, donc facilement à baguettes installes sur Debian, Fedora, Yom install, donc on veut faire de ça facile d'utilisation, donc c'est un quelques packages installés, il n'y a pas de compilations noyaux à faire, ça se fait relativement facilement. Ça rôle sur presque toutes les architectures possibles et Onfi a été confirmé cette semaine pour ceux qui ne sont pas familiers, c'est un mini-core d'Intel, donc 230 quelques noyaux-core sur un chip. Donc si vous avez un petit load à rouler, quelques processus à rouler, ça peut être utile. Il y a des efforts qui ont été faits pour le porter à un Android, ça rôle sur FUBSD et Seguin, la partie applicative seulement. Pour vous donner une idée, ça c'est la version facile des commandes, donc présentement, en fait, il faut comprendre que ça s'opère, il y a quelques GUI qui s'en viennent, mais ça reste encore expérimental. Donc qu'est-ce que vous avez à faire pour voir une trace, simplement? On crée une session de traçage, on active, par exemple, le remet, le traçage d'événement noyau, le traçage d'événement d'utilisation applicative, on part, on arrête, on visualise la trace et on détruit la session. C'est ça. Comme je disais, on peut combiner beaucoup de sources, un peu sûr qu'ils ne sont pas trop familiers, le noyau, on part en haut, ça va peut-être faire un familier un peu plus difficilement. Ça peut-être que ça paraît plus difficile. Bon, des points traces statiques, on peut mesurer toutes les appels système. On peut rajouter des probes dynamiques dans le noyau, donc aller chercher des fonctions spécifiques dans le noyau. Par exemple, vous débogez la stack réseau, puis vous voulez monitérer à chaque fois qui décode un paquet TCP en IPv6. Vous pouvez rajouter un point de trace, puis vraiment monitérer à chaque fois des compteurs de performance, parce que sur le matériel moderne, il y a des compteurs de performance pour toutes les fautes de page, donc à chaque fois qu'il essaie d'accéder une page mémoire et qu'elle n'existe pas, ça incrémente un compteur. On peut loguer ces informations-là dans la trace. Au niveau applicatif, on a des points traces statiques, donc il faut les insérer dans le code. On travaille présentement à vos points traces dynamiques. Donc vous avez un binaire, puis vous dire que je vais rajouter les informations à posteriori. Ça s'en vient dans les prochains mois, au cours de la prochaine année, en 2014, ça devrait être là. Même chose pour les points de contexte, avoir le numéro du processus, sur lequel c'est puis on roule, et des éléments de genre. Juste pour vous donner une idée, comment on crée un point de trace. Ça, c'est un petit métal-langage pour créer son point de trace. Donc on a eu un... on définit, c'est quoi, un point, on définit un nom, et on définit une liste d'arguments. Ici, pour l'instant, la format est très... très proche du C, mais on a travaillé sur un format qui va être en grec-amel pour pouvoir définir des formats un peu plus simples, donc juste le nom. J'ai un argument en texte, j'ai un argument en entier, j'ai un argument, etc. Donc il faut avoir des types fixes pour pouvoir préserver la mémoire, l'espace mémoire de façon efficace de la mémoire. Je suis remarqué, en fait, une chose du traçage que je n'ai pas mentionné, quand vous les activez, il n'y a pas d'impact sur le système ou de façon pratiquement c'est pratiquement transparent. Donc, idéalement, comme ça, vous pouvez l'installer, instrumenter vos programmes, le laisser rouler, oh, vous avez un problème, vous le partez, et là, vous allez voir vos données à ce moment-là. Pour donner une idée en C, une fois qu'on a utilisé un point de trace, donc défine notre point de trace, je vais montrer un exemple en Payton, un peu plus loin, ça reste un peu plus pour vous parler. Juste quelques benchmarks, si vous êtes habitué de faire du débagage de certains trucs, juste pour vous donner, vous connaissez l'application Strace pour voir ce qui se passe sur le système. Ici, j'ai juste fait un find, donc trouvé, listé, 100 000 fichiers sur mon système, ça prend 0.5 secondes normalement, alors juste de l'TTNG, rajoute 1 seconde. Si vous rouliez avec Strace, parce que les gens sont habitués de déboguer donc c'est pour montrer vraiment que l'impact est relativement minimum sur votre application, donc vous pouvez tester des trucs en production, traceer des trucs en production, ça devrait fonctionner et pas trop affecter vos performances. C'est un exemple avec un autre application qu'on a, l'TTNG Top. Voir l'impact, le nombre de syscalls que Top fait pour voir, lister l'information de ce qui s'y roule sur le processus sur votre système, puis la même chose avec l'TTNG Top, donc vous pouvez analyser live votre système avec un impact en conmoindre avec le traceur. Une fois qu'on a pris des données, c'est bien le fun, mais ça nous génère énormément de données, une trace de quelques minutes, puis quand on active tout avec quelques applications instrumentées, tout le noyau, peut nous donner quelques gigabytes, quelques gigabytes par minute, par deux minutes, ça fait une donnée, ça fait beaucoup, pour ceux qui aiment faire le dos d'automining, c'est une très belle application pour ça. Mais on a quand même heureusement développé pour voir les données pour analyser notre trace. Au titre de base, un peu plus pour débarguer, puis ceux qui aiment la ligne de command, Label Trace, donc on simplement, on dompe en texte la trace, quand je parlais des timestamps, on voit qui sont quand même très précis, on voit vraiment les temps en deux du appellus système, donc on voit le détail, on voit par exemple, quel appellus système, quelle application roulait lors de l'appellus système, c'était quoi la valeur de retour, c'était quoi les paramètres, etc. Mais c'est beau pour voir rapidement qu'est-ce qu'il y a, mais ça peut être quand même difficile analyser le détail à cet évolution-là. La deuxième application que je vais remonter rapidement tantôt, LT-NJ Top, qui permet, c'est une vue à la top, mais avec beaucoup plus d'informations et qui permet d'aller chercher de revenir dans le temps et rejouer le système en avançant, reculant et en regardant certaines statistiques des processus. LT-TV, qui est une application simple en graphique pour voir la trace, donc on voit des lignes de temps en fonction de l'HCPU ou qu'est-ce que chacun des processus faisait à chaque temps, donc par exemple parce que j'attendais après des données sur le 10, qu'est-ce que j'attendais après me faire appeler, est-ce que j'étais actif sur le CPU, donc c'est genre de choses qu'on peut visualiser. Un peu plus avancé, Linux Tools, un plugin eclipse qu'on appelle TMF, Trace Monitoring Framework. On va faire des analyses un peu plus poussées, donc un peu plus mobilifiée à cause des clips, donc on voit un Instagram, on voit la mingling de temps, mais ça va permettre de faire des vues intéressantes, c'est un peu petit pour l'instant, mais en fait ça c'est, on peut aller chercher toutes les appels de fonction de programme, exemple ici Quake, donc on a les appels, toute la call stack complète dans le temps exactement, donc si vous voulez débrouiller votre programme, aller chercher ça dans le détail, chacune des fonctions, combien de temps on est pris, ça permet d'aller voir l'information de façon extrêmement spécifique. Et deuxième vue experimentale qui a été faite récemment, donc Quake encore, on a la même, dans le milieu, la même call stack, on voit en haut le usage CPU dans le temps, et en bas on voit la location mémoire, donc on peut finalement aller chercher quelle fonction, quel moment pour qui j'ai eu beaucoup de mémoire dans la location mémoire, ça a le rendissement au système, c'était quel appel de fonction qui a fait, quelle application, quel appel de fonction. Donc on peut aller chercher du détail de façon assez détaillée. Python, qu'est-ce qu'on a pour l'instant? Des binding pour le contrôle et l'analyse à bubble trace, donc si vous voulez faire, je vais revenir, et génération 13 points de Python. Nurtissement, c'est tout expérimental expérimental pour l'instant, c'est dans les branches de développement spécifique, donc si vous voulez avoir des fonctionnalités Python, il faut aller chercher le Git, pis il faut checker les branches binding Python, pis là, c'est là qu'on trouve le code. Mais si il y a d'intérêt, vraiment, les développeurs principaux ont moins le temps de tester, mais s'il y a beaucoup de gens qui expriment d'intérêt d'avoir le support Python, ça va migrer vers les branches de développement principal. Donc si ça vous intéresse, si ça vous intéresse, si ça vous utilise, je vous invite à vous faire voir sur notre canal IRC ou sur notre mailing list, et ça devrait rentrer. Donc en détail, un peu petit, mais juste pour donner des techniques Python pour le contrôle, on crée, on importe l'objet TNTG, on crée un domaine pour le noyau, par exemple, on crée un channel, parce qu'on peut avoir plusieurs channels, plusieurs paramètres différents parallèles. On peut aussi avoir plusieurs usagers, par exemple, tu as plusieurs administrateurs de systèmes qui veulent analyser différentes choses en même temps, ils ont tout accès aux routes, mais ils peuvent avoir des sessions de traçage différent, pis qu'ils ne viennent pas se piler les piles les unes sur les autres. Donc on peut faire ça. Donc on crée un événement on crée la trace, on démarre la trace et on arrête et on détruit la trace. Donc on peut contrôler, on peut faire du débagage automatique, un truc qui a été fait, pas que les binding pattern, mais par exemple à chaque fois qu'il y a un core dump, donc un problème d'accès mémoire, on doncle la trace dans un sheet text, donc on peut rejouer, par exemple, la dernière minute du système et aller chercher ça. Au niveau de l'analyse, un peu le même principe, probable trace, bon, la paie est un peu un peu compliqué, mais on crée un contexte, on crée la trace, on crée une terre à terre pour bouger dans la trace et, par exemple, si le code qui est là, c'est surtout pour afficher la trace, mais on peut, par exemple, compter, faire des statistiques, calculer les moyens, des latences, donc si je leur rends avoir un truc très très spécifique de l'information que vous allez chercher, vous pouvez calculer ça, donc avec Eleaternex, vous pouvez aller chercher l'événement, c'est quoi le nom, le timestamp, aller chercher des tips. Donc vous pouvez faire des petits scripts d'analyse rapide que votre information voulait. Un truc qui s'en vient, c'est pas encore fait, je suis en train de le désigner. Donc c'est de générer, finalement, un point de trace par étonne, donc un module par étonne avec tous les points de trace que vous avez défini pour finalement les appeler dans votre application. Présentement, on dépend d'avoir un accessé, donc d'où la nécessité de générer un module compilé. Donc tu génères ça, donc une fois que ça va être fait, t'importes ton module et ton point de trace de cette façon-là. Idéalement, comme projet futur, ça serait de s'intégrer directement dans l'engin Python, puis de façon dynamique, générer des points de trace. C'est un projet un petit peu plus compliqué, mais si vous voulez faire une maîtrise, c'est sûrement quelque chose qui peut s'intéresser à faire au laboratoire, à Polytechnique. Qu'est-ce qui s'en vient, prochainement, le live tracing dans le prochain release, d'ici la fin de l'année, donc pouvoir vraiment analyser une trace, voire la trace que vous êtes analysée du système en temps réel. Donc si vous avez un problème, vous voulez l'interagir, vous allez voir le comportement ça permet de faire des analyses, par exemple de performances puis triggers, il y a des triggers, il y a des problèmes ou des trucs comme ça. Je parle de laboratoire, qu'est-ce qu'on fait de façon plus avancée? Rapidement, l'analyse de dépendance, permet de savoir une ligne de temps, il y a un appel à ce endroit-là. Qu'est-ce que dans la chaîne a provoqué ce délai-là? Puis ça remonte à travers les processus, donc qu'est-ce qui bloque mon prime pattern dans mon serveur à pâches? Tu peux remonter toute la chaîne de l'appel système jusqu'à l'appel de la base de données, jusqu'à revenir à un autre serveur distant, puis vraiment revoir la chaîne au complet. Donc ça permet de voir rapidement du lien du problème. Abstraction, multi-niveau, par exemple on voit des affaires très bonnes niveaux, mais c'est d'abstrales informations. Par exemple ça, c'est un lecteur de fichiers, ça c'est un appel DNS, des éléments comme ça. Dans la ligne qu'on est que je voyais en de couleur, avoir signalement directement au lieu de chacun des événements, synchronisation du temps pour avoir vraiment une meilleure précision sur plusieurs machines, et intégration du traçage hardware. Comme je disais, par exemple ARM, Intel ont des fonctionnalités spécifiques pour faire du traçage par exemple de chacune des instructions sur notre système, donc c'est intégré sur dans la structure d'OTNG, et tracing de cloud, un aspect de recherche juste pour avoir plus de subventions, j'imagine. Mais mais c'est en mode, donc on travaille sur intégrer dans OpenStack par exemple. Donc, petite démo, rapide donc si ça fonctionne bien, on fait vidéo d'une démo rapide. Je montrais le TTNG, le TTNG Top, donc c'est une trace que j'ai pris de Firefox. On voit qu'on peut se promener, donc on rejoue la trace évidemment dans le temps. Donc, comme qu'on utiliserait Top, et on peut voir du temps entre eux, on peut reculer dans le temps, donc on revoit toutes les statistiques précédemment. Donc, si vous vous dites, ah il s'est passé telle chose à tel moment, mais vous la comme 5 secondes et je l'ai manqué, on peut revenir dans le temps de cette façon-là. C'est quand même pratique. On peut trier par processus, par processus, par numéro, par traite, à différents niveaux. Et on peut si on plus loin. Donc, ici je vais, quand j'ai les compteurs de performance, donc Firefox fait beaucoup de miss de branch, donc dans son code, et le prédicteur de branche du processeur, a un certain nombre de comptes. Ici on voit l'AIO, donc toutes accélérées aux disques. Donc on peut voir pour chaque intervalle de secondes c'est quoi les pourcentages d'AIO, le cancer d'AIO, si tu vois des problèmes de réseautique tu peux s'identifier de cet niveau-là. Pour chaque cas des processus, après ça on peut aller voir toutes les fichiers qui sont ouvertes et d'autres détails. Donc c'est une des vues qu'on peut faire une des façons qu'on peut débarguer avec lttng. Souviens l'information du projet lttng, lttng.org, on est sur ERC et on est très disponible pour vous répondre à vos questions. Merci d'avoir regardé.