 Bonne matin à tous. Aujourd'hui, je vais vous parler de l'infrastructure efficace et de l'infrastructure large-scale avec le tracé. Je m'appelle Julien Defosé, je travaille sur efficaces. En partant de mon travail, je travaille sur la construction de l'infrastructure de tracé pour l'infrastructure large-scale. Le contenu de l'infrastructure de tracé aujourd'hui, vous verrez une petite overview de l'infrastructure de tracé et de l'infrastructure de l'infrastructure de tracé. On va spécialement focussé sur les outils délicatifs pour les outils de l'infrastructure large-scale et les outils de l'infrastructure de tracé. Et ensuite, on va détailler les deux principaux outils pour ce sujet. Ensuite, on verra comment intégrer l'infrastructure de tracé avec l'infrastructure de l'infrastructure, quelques résultats de performance, un outil pour vous aider comme administrateur du système, des traces réelles et quelques outils d'explication de l'avenir. Le tracé est le processus de récolter l'information en temps sans arrêter le processus. Nous utilisons la tracé comme partie du processus de développement. Aujourd'hui, c'est l'un des points de mon travail, c'est de vous montrer que nous pouvons aussi utiliser la tracé pour monitorer et débarguer l'infrastructure production, pas seulement débarguer dans le phase de développement. Si certains d'entre vous étaient à la table de David ce matin, peut-être que vous verrez un overlap entre les contenus, parce que nous travaillons ensemble sur les mêmes outils, mais cette présentation est plus orientée pour l'infrastructure et les administrateurs du système. Vous devez voir quelques compléments entre les deux présentations. Pour le tracé, nous avons bien sûr beaucoup d'outils alternatifs, donc l'HTNG bien sûr, mais aussi le progrès du système TAP, il y a beaucoup d'outils alternatifs. Aujourd'hui, je vais focussé sur l'HTNG. Donc l'HTNG 2.x, si certains d'entre vous connaissent l'HTNG avant l'HTNG 2.0, c'est tout un nouveau set d'outils et des outils. Le point principal de l'HTNG 2.x, c'est d'avoir l'outil CTF, un format de tracé commune pour écrire le tracé, et une interface commune pour interagir avec le tracé. C'est le tracé de kernel et le tracé d'usage. En même temps, vous pouvez récolter le tracé de kernel et le tracé d'usage et puis combiner les deux tracés durant l'analysation pour voir les résultats synchronisés entre ce qui s'est passé dans le kernel et ce qui s'est passé dans l'application de l'usage. Nous aussi bientôt avons le Java tracé, donc Java va pouvoir produire des événements dans le tracé. Et nous supportons les points de tracé de virtualisation KVM, et nous combinons le tracé entre KVM et Virtual Machine à l'extérieur et à l'intérieur de l'usage. Donc, par design, c'est vraiment le focus d'être un tracé de tracé de l'overhead. C'est la plupart de notre travail, c'est de faire surement que nous pouvons régler le software dans le service de production et évoluer la disruption du système d'opérations et du programme qui est tracé. Pour le tracé de kernel, maintenant, c'est seulement des modules. Donc, nous devons dire ça de nouveau, mais nous n'avons plus besoin de récompiler le kernel. Avant le texte, nous devons appliquer les patches sur le kernel et rébuilder. Maintenant, c'est seulement des modules, et la plupart des détails sont en train d'évoluer les packages pour la chaine. Donc, une petite overview de comment créer le tracé de kernel. Aujourd'hui, je vais mainly focusser sur le tracé de kernel parce que c'est là où nous avons les données de monitoring. Mais bien sûr, si vous voulez avoir des points de tracé custom pour votre application, et puis d'extraire les métriques là-bas, c'est exactement le même processus. C'est comme un exemple, mais n'hésitez pas d'extraire ça pour toutes vos nécessaires. Donc, pour cet exemple, nous avons juste créé un tracé. Nous avons évoqué l'événement de la chaine. Donc, pour chaque événement de la chaine, nous verrons un événement dans le tracé, et nous avons évoqué tous les systèmes pour l'host. La différence entre un tracé STRACE et l'LTTNG, en ce cas, c'est que c'est un tracé systematique. Donc, ce n'est pas traité pour juste un processus. Nous allons tracer tout le système. Quand nous avons évoqué l'événement de la chaine, nous pouvons également évoquer l'événement d'un espace user si nous avons déjà installé l'application avec un tracé de l'espace user. Mais sinon, nous allons juste commencer le tracé. En ce cas, nous attendons deux secondes, commencer le tracé et l'événement. Le tracé devrait déployer un texte de tracé. Je vous montre un exemple juste après. Mais ici, vous pouvez voir que nous avons créé des événements en deux secondes sur ce laptop. C'est un tracé de l'aéroport. Vous devez garder en compte que, lors de la représentation, il y a beaucoup d'informations que nous avons créées. Et puis, quand nous sommes faits avec le tracé, nous avons juste détruit. Si nous ne voulons pas, nous pouvons aussi commencer à continuer le tracé. C'est un exemple. Les trois exemples de le tracé, nous avons créé des événements, ce qui était le tracé de l'événement et le tracé de l'aéroport. Vous pouvez voir ici que nous avons la sistaise, donc le tracé de l'événement. Le processus de l'événement sur le CPU ID3 a créé un tracé de l'événement et vous avez ici les paramètres pour cet événement. Un autre exemple, c'est la main. En bas de la CPU ID3, vous pouvez voir que le processus de l'événement a créé ce file avec ce mode de flammes. Et pour l'événement de skate-switch, nous pouvons voir que sur l'événement de CPU ID1, le task currently going from Swapper 1 to RCE UOS 0. C'est juste un exemple pour vous montrer, mais avec le liste STNG-K, vous pouvez voir tous les événements que vous pouvez enlever pendant le tracement. Et c'est tout l'événement de tracement qui est déjà compilé dans le canon. Donc, si vous n'avez pas besoin de tout ce que vous pouvez faire, avec le module, vous avez juste attaché des probés à l'événement de tracement déjà dans le canon. Donc maintenant, je vais vous concentrer sur l'utilisation de STNG pour l'événement de cloud et l'infrastructure et l'événement de monitoring. Donc, j'ai expérimé 4 milestones et 4 features que je considère vraiment important pour l'infrastructure et l'infrastructure de cloud. Donc, en décembre 2012, nous avons introduit le tracement de streaming. Donc, dans l'exemple précédent, j'ai écrit le tracement sur le disque local. Avec cet événement, nous pouvons maintenant extracter le tracement à une hausse remonte. Donc, à l'intérieur de la STNG-CREATE, vous pouvez ajouter le dash, capital U, et puis un adresse network. Et ça envoie le tracement à cette hausse. Donc, à l'intérieur de l'événement de contrôler le tracement sur le disque local, vous pouvez juste l'extracter et l'enlever de l'autre. Trace file rotation. Donc, dans le mode défaut, quand vous créez un tracement, c'est pour l'éternité. Donc, vous avez créé jusqu'à ce tracement. Vous avez écrit dans un grand tracement. Vous avez continuement appendu le data pour le tracement. Donc, ça peut devenir vraiment énorme. Et si vous voulez utiliser le tracement comme monitoring, peut-être que vous vouliez avoir une tracement session qui s'occupe de la vie du service. Donc, vous ne vouliez absolument pas appender le tracement à ce rate d'événement de génération. Donc, la rotation de tracement est comme en TCP-dump. Vous avez le buffer sur ce bruit et vous avez juste utilisé le tracement quand vous avez fait le tracement. Donc, vous pouvez dire que vous vouliez juste maintenir les derniers 5 gigabytes de tracement. Et après ça, ça commence à évaluer toutes les événements. Puis, récemment, en septembre, nous avons introduit dans l'HG2.3 les snapshots. Donc, les snapshots sont combinés avec ce qu'on appelle le flight recorder. Donc, c'est un tracement qui seulement fonctionne en mémoire. Donc, c'est l'un des événements en mémoire qui n'est jamais écrit sur le disque. Et puis, quand vous voulez, vous pouvez juste demander de créer un snapshot et le tracement s'occupe sur le disque. Donc, on verra un exemple après ça. Et le futur qu'on est currently working on est le tracement de vie. Donc, c'est la capacité de lire le tracement quand il est récordé. Si vous regardez ici, nous devons arrêter le tracement avant de pouvoir lire le tracement. Avec la live streaming, ce n'est plus nécessaire. Donc, vous pouvez juste connecter l'analyseur au processus et vous devez pouvoir lire le tracement quand il est récordé. Donc, l'HTNG a un tour de monitoring. La première chose que je veux vous montrer pour ce sujet est le crash dump. Donc, en utilisant les snapshots que j'ai introduits, nous pouvons maintenant prendre le snapshot de ce qui s'occupe sur le système dans les dernières minutes ou secondes. Ça dépend de l'unité de votre ingréditation, le ring buffer. Donc, par exemple, si vous voulez garder une histoire de 100 MB de data trace en ingréditation, vous pouvez juste créer une session avec ce paramètre. Et puis, sur certains événements, peut-être juste une faute de segmentation ou une alerte de vos idées, ou tout ce que vous voulez, vous pouvez demander de créer un snapshot et de créer un tracement sur le système. Donc, jusqu'à ce que vous créez le snapshot, rien ne se passe. Mais, à l'exception, nous sommes en membre. Mais, quand vous voulez juste faire le snapshot. Nous avons un petit script, c'est corde dump et ender. Donc, vous pouvez juste ajouter ça à la pattern de corps dans le capteur de proxies. Et puis, pour chaque fois que le système veut générer un corde dump, il va créer le script qui va prendre le snapshot. Donc, en addition à avoir votre corde dump, vous pouvez aussi voir ce qui s'occupe sur le système avant et après le moment où le corde dump a été généré. Donc, depuis que c'est le système wide tracer, vous avez le kernel événement que vous avez évolué, mais vous pouvez aussi avoir l'événement de l'usage. Donc, si l'application que vous avez crée a été instrumentée avec lttng-ust, vous aurez aussi vos derniers événements. Donc, peut-être cela va vous aider à détecter ce qu'est le source de la corde. Un exemple rapide de comment créer une session pour le record de flight et le snapshot. Donc, c'est vraiment la même interface qu'avant. Donc, vous avez juste créé une session, mais cette fois-ci, vous ajoutez lttng-snapshot option pour dire à la buffer ring que vous êtes en mode override. Et seulement en memoriaire. Nous ne voulons pas évoluer le tracer quand nous commençons. Nous voulons juste évoluer le tracer en memoriaire. Puis, nous avons juste ajouté les mêmes événements, donc le cap switch et le syscall, juste comme avant. Et puis, nous commençons le tracer. Après cela, le tracer est seulement évolué en memoriaire. Donc, vous pouvez faire quoi que vous voulez. Et puis, quand vous voulez faire un snapshot, vous savez que quelque chose s'occupe sur le système. Peut-être que vous avez détecté l'inusualité latentielle sur le système ou une faute générale ou peut-être un monitoring magnifique qui m'a dit qu'il y avait quelque chose qui s'occupe. Vous avez juste récordé le snapshot. Depending sur le nombre d'événements que vous avez évolué et le nombre d'événements que vous avez configurés, vous aurez un tracer qui va avoir des histoires. Donc, ça dépend, bien sûr, de combien. Parce qu'on est toujours évolué. Vous pouvez prendre autant de snapshots que vous voulez. Donc, vous pouvez voir que pour cette session, c'était le nom de la session, le nombre d'événements que vous avez évolué. Nous avons créé ce folder, mais vous pouvez voir que c'est un système de temps. Donc, vous pouvez juste générer autant de snapshots que vous voulez. Si vous prendrez deux snapshots dans la même période, vous verrez les événements d'évolution. Parce qu'on n'a pas évolué le buffer quand vous récordez. Si vous récordez, la date d'évolution est toujours dans le buffer, vous verrez. Donc, c'est tout pour la session de snapshots et de tracer. Donc, vous pouvez voir comment vous pouvez ajouter pour votre monitoring et pour votre système ID, peut-être, et aussi pour votre cordempre, pour exercer le data. La deuxième partie est le monitoring en temps réel. C'est le tracer live que j'avais parlé avant. C'est pour pouvoir lire le tracer pendant que l'on récorde. Il peut être une session locale ou remotely. Et le seul paramètre différent de la création des sessions normales est la période flash. C'est un timer qui explique le consommateur d'un tracer LCTNG pour placer le tracer à la période définie. Vous pouvez être sûr que vous recevrez, que quelque chose se passe sur votre système. Donc, si vous avez de grandes buffers et des événements de tracer, vous n'avez pas besoin d'attendre que le tracer est complet pour recevoir le data. Vous pouvez juste configurer cette période pour dire que chaque seconde, vous voulez flasher tout ce qui est en mémoire. Pour l'infrastructure, vous voyez que c'est seulement basé sur le TCP. Donc, c'est complètement distribué et peut être n'importe où sur le réseau. Donc, dans cet exemple, je vous montre 3 services avec le R&D LCTNG et ils s'en connectent avec le R&D LCTNG. Ils sont tous envisant leur tracer au processus remote. Donc, ça peut être une de ces machines ou une machine délicatée. Et puis, nous connectons à un de ces sessions. Once we are attached, we start receiving the events either from the start of the trace or from now. So, from the moment you attach to the trace. So, if you have a trace that's running for years or months, you don't need to process the trace from the beginning. You can just start right here. So, once again the commands to create such a session. So, you see that the only main difference in the session creation is the live parameter for the timer. In this case, it's in microsecond. So, in this case, it's 2 seconds. So, every 2 seconds, we want the consumer to flush the data. If data is available in the buffer, you will receive the events. If it's not, you can, that tells you that no data was generated for this period of time. So, you know what's happening on your system. And then you have the dash capital U. So, to tell that you want to send the trace to this address. On this server, you have the htng ready that's listening. So, for now it's the default port, but you can configure it's running and receiving traces for all the servers up there that have a session configured like that. And finally on the viewer machine. So, it can be on your desktop on the sysadmin desktop actually. You can just connect to the real ID with the one viewer. It's an example I show you today, but you can have different viewer for that. It's an open protocol. Just implement the viewer you want and connect to the relay and then you will see all the sessions established and connect to the one you want. From the performance side like I showed you in here and before I told you that in 2 seconds I generated 8000 events on one single laptop. So, you can imagine with this graph that the htng relay can receive a lot of data. So, of course you have to design the monitoring you want. So, you maybe don't want to have all the information I was showing before. And if you want you will probably want to have multiple htng relay so maybe for a set of servers you will have dedicated servers but maybe you will have also UST events. So, user space events for your application generating a lot less of data. So, you have to make sure that the infrastructure you are using can process that amount of data but I'm going to show you what's the impact on a single server with tracing. So, in this benchmark I was using the CIS benchmark and especially the MySQL test. So, it's a test that's doing I don't remember the amount but a lot of read and write request to the MySQL database and it start from 2 trails to 64 trails. So, every time we record harmony, read and write request we could do to the database. So, we'll start by just doing the test on this single machine. So, it's a quad core i7 and then we do the same benchmark with the flight recorder recording a snapshot every 30 seconds and then the streaming trace to the remote server so with the relay and then writing the trace on a dedicated disk. During this test we record the sketch switch events and all the system cores of the machine. So, that's exactly the example I showed you so, that's exactly the same test with these 3 configurations of LTTNG and then the same test with S-Trace attached to the MySQL process. So, just to give you an idea of the performance, maybe you already have used S-Trace in production, you know it works but you also know that it slows down the system quite a bit. That's just a comparison but in mind that for MySQL we are only tracing MySQL with S-Trace with LTTNG we are tracing the whole system. This test runs for 50 minutes and when we are in the configuration where we record the snapshot we generate approximately 7 megabytes of trace and we generate 100 snapshots during the 50 minutes. So, one snapshot in 30 seconds. In the configuration when we use S-Trace at the end we generated 5.4 gigabytes trace with 61 million events and with LTTNG we generated 6.8 gigabytes trace with 257 million events. So, around lots more around 4 times more events generated with LTTNG than with S-Trace because we are tracing the whole system S-Trace only tracing the MySQL process. So, the results are easy to interpret. We have no overhead with this configuration of LTTNG. So, you can see that the curve for no tracing flight recorder streaming and tracing to a dedicated disk so we are not writing the trace on the same disk as the database you can see that we don't have any overhead compared to the baseline. So, you can see that at 64 threads we have around 15,000 requests per second event with this tracing activated. If you compare that to S-Trace that's only tracing MySQL you can see that it's around 9,000 events. Now, if you do the exact same test but we write the trace on disk remember that we generate 5.4 and 6.8 GB trace the performance is a lot worse because we are sharing the database and the trace output So, the first curve the blue curve is the baseline so no tracing that's this one and the yellow curve is the S-Trace and red is LTTNG so you can see that for most of the time S-Trace is more efficient than LTTNG because it's writing lot less events than LTTNG and then starting at 32 threads you can see that the performance doesn't grow even when we double the number of threads that's because the system is saturated you can see that the stem cannot generate any more events but saturated So, that's an example of what we can do with tracing, you can see that if you are in good production conditions so you are writing the trace on a dedicated disk or on the network or just in memory and not too much event it's get switch and system calls you can have LTTNG running on production servers of course that's your case where most of the load is on the disk it's not CPU based test it's really more IO and IO focused this so of course the impact is lot less with tracing if we did a micro benchmark on just the CPU Z you would see a much bigger overhead because for each trace point we have to CPU time to write the event Another example of the performance but in this case it's for virtualization and so in this case we have 2 KVM virtual machines on the same physical host one machine is a Apache web server and the other one just downloads 5 gigabytes file with the W gate we use exactly the same version as before so get switch and system calls and we see absolutely no overhead between the writing the trace and just not doing any tracing so once again it's test that's IO intensive but you also see a lot of CPU usage between the because of the virtualization and the exchange between the two context One example really interesting about the what we can do with such traces in virtualization it's a work done by Mohammed Gubay at Polytechnic in Montreal and I want to show you that because that's more offline trace so you record the trace and then you analyze it but it's really interesting so you can see that in the left column here we have 2 virtual machines we have the QMU with the clone in the first virtual machine we have 2 CPUs and second one we just have 1 CPU the vcpu0 in each virtual machine is pinned to the same physical CPU in the physical machine so they are sharing the same physical processor and this one is around in this first VM we start 2 CPU burn 100% of the CPU and this one only one so 1 CPU burn per CPU so you can see that this one since it's alone not shared you can see that it's running all the time but you can see that the vcpu0 that's sharing the physical same physical CPU is constantly being preempted between the 2 because of the scheduler that's giving cpu time to the 2 processors so that's the kind of example you can quickly see that your system is not maybe running efficiently or at least you have a good idea of what's happening and why sometimes it can be slow if we expand the second machine here so if we list all the processes inside this virtual machine you can see that at the end here we see the CPU burn process and that's the view from inside the virtual machine so we record the trace from inside and from outside from inside the virtual machine you can see that the CPU burn process is running at 100% of the time so you can see that it believes that it's running all the time but if we look up here we see that it's getting preempted but it doesn't know that inside the host you can see that it's running at 100% of the CPU but from the physical CPU perspective from the host you see that actually it's maybe around 50% of the time so you can see quickly what's slowing down your virtual machine next I want to show you the LSTNG top tool so that's to come back more for the track and the virtualization and monitoring track so LSTNG top is a top-like interface to read LSTNG kernel traces we have the CPU usage per process file activity, kprob support per process performance counter display we can navigate in the trace second by second we can pause, come back in time read offline traces so traces that you recorded pour replay on your machine or you can now connect to a remote process attach to a session and interact with read the current session we also have an experimental in memory live tracing but as I said it's experimental it requires out of three LSTNG tools and bubble trace patches so it's not compiled by default but it can work you can easily bypass the network live reading so you just read in memory from the tracer I'm going to show you a quick demo of LSTNG top and the live reading so in this maybe I just in this console I'm inside the virtual machine and I'm going to start recording a trace for this machine and then I'm going to test remotely the the commands I'm going to use are this one, so first create a session, live session so a session that can be read while it's being recorded so we have a timer of 2 seconds so every 2 seconds the consumer will send a packet to the relay to inform if data was generated during the last 2 seconds or if no data and I'm going to send this trace to a remote host for LSTNG top we have a set of events that are required so that's the big list here that's the event we use to generate the state of the system so with the sketch switch you know which CPU which process is running on which CPU but you also need some more information to have for example the state dump of the system so at the beginning of the trace what were the processes enabled already alive on the system what were the file descriptor already open in each process we also want to have the system code in this case it's just for detecting which process opens which file and how many bytes are writing in each file etc and then we need some context so I didn't talk about contexte before but that's just explain information attached to the payload of each packet of each event so for example for each sketch switch you will see all of this information so the PID so the current PID of the process the current PROC name so the name of the binary that's running the thread ID and parent PID of the current process for each event and also we have the support for perf counters so in this case I'm going to record the major faults while untracing so for each process we sample the perf counter and output this information so you can quickly see what's the behavior of your application in regards to this perf counter usually I add more performance counter but in this case it's virtual machine so not all the perf counters are available for us but it will just give you an idea of what's happening and then so we start the trace so let's start that so a lot of output so you can see that all the events were generated all the system calls are going to be traced and these are the contexte we added now on the remote machine so that's just my laptop here but it could be the monitoring station or assist admin desktop you connect to the relay in the near future we'll have the list of the session currently running on this relay for now I'm just attaching to the first one but it's the next feature on the list so I'm just connecting to the relay on localhost and then you see all the processes currently running on the machine you see that the list of the processes just got slowly populated that's because it only records what's happening currently so if the process is not doing anything it doesn't show up in this list for now so that's top like interface so you can navigate inside here you can hit enter to see what's the details of the process so for example the tng consumer you can just enter that you can see the performance counter so in here we have the perf major faults that I activated for now nothing to see we have the IO top so how many bytes are read and written per process and kprob if I added kprob support I'm going just to do update in this machine and we should see quickly you see that HTTP, base it to update all of that are happening on the system right now while I'm doing the update here so if I pause now the display I can come back in time and see what was happening at this time here you have the time step and you can just come back back and forth in time to see what's happening so here you have the base it to see that it just loaded this library HTTP and we should see some dpkg so that just give you an overview of you can just navigate in the trace and see what was happening and then you can un pause and it goes back to reading the trace you can at the time and now I'm going to destroy the trace if we could also read the trace from the host because right now we sent the trace to the relay lady so if we want to read the trace again we could just look at this trace and that's the same trace that we just processed so if somewhere in there you add what you are interested in maybe you add a crash a big latency you can just use that to read the trace you have the time step up here so you know the period of time maybe you just want to know what happened during this particular second maybe you see here you have cron maybe sometimes it's a good case of latency then if you want to dig deeper then you can read the trace in the text dump format maybe or in the tmf tool that's more a graphical tool to help you dig deeper inside the trace but if you prefer the text dump you can also just grab here and look at the timestamp you just detect it before so that's the idea of LCTNG top it can just help to the season main inside the trace you don't even need to connect the trace to the server by SSH you can just connect to your monitoring desk and access the trace while it's being recorded I'm going to show you an example of how to integrate all of that in the monitoring infrastructure so that's just an example but to show you the potential of tracing in production in large scale environments I don't know if you know graphite graphite maybe the monitoring tool in this case it's just a quick display to show you that we ask the graphite to display the last 20 minutes of block events so just with a single request up here you can display what was happening in the last 20 minutes for the blocks and you see in the legend what was the trace point and how many events for each trace point were generated during this period last time so you can combine that with your user space trace you can combine that with other tracing information and just help you pinpoint what was the problem if you detected a problem the future work is to integrate with such tools so graphite is one example but we also have Nagios in mind we want to for example you may be interested in the page faults for one specific application so you could just hook the tracer to extract matrix for only page faults for only one process and just have really low level matrix from large scale and high amount of data for now it's just beta and just example like that but that's definitely need for the future of merging the tracing and debugging and monitoring domain together also we want to filter the trace because 8000 events per second is maybe too much for large scale infrastructure so you want to have a really efficient way to extract data and just the relevant data you don't necessarily want all the system calls on your system maybe you just want the system calls for one or two specific applications and then compute statistics from that or whatever you want then distribute the analysis for now you saw that tng top to do the analysis but in large scale infrastructure we want to have analysis on specific nodes and maybe not on the final step of the chain maybe we have the relay that's going to do aggregate the events and pre-compute the data so we can have a really quick way to access the statistics remote control of the tracer for now it's SSH but that's definitely something that we are working on to connect to a remote tracer and then enable events we also want to have the triggers to on specific event maybe we want to add additional trace points for example you detect latency in one subsystem you might be interested in adding more information to the subsystem to pinpoint exactly where in that system the problem is coming you can be with the snapshot but also start stop the tracer add events to the current running session no entering session so if you want to install it you have packages for most of the distro 4.2 we also have a daily build ppa with lttng top lttng top is not in the default packages but you have the ppa for that or of course from the source the 2.4 release lttng as all of this feature is expected for mid-november so if you have any questions i'm here the live mode you have 2 ways to attach to a live session you can either connect from the start of the trace so you will receive all the trace from the start or you can attach to a session from the moment you send the attach command so you won't see anything before this moment no i should just connect a new viewer to the running session it will start from the moment you are running so if you have 2 viewers connected to the same session you will see the same events of course but if you only one have one viewer you will see from the moment you are starting so if you just connect sometimes you will just have from the moment you are attaching to the session i'm sending the packets not often enough from the consumer to the relay yes but for that you can increase the size of the buffer but that's really the streaming path from the viewer side you won't lose any event because that's the viewer that's requesting data packets from the relay so on this side you won't lose anything in here you saw that it was everyone second but that's the viewer that's requesting data from the relay so in this case you don't miss any events that's just sending events any other question I think we have a track from hardware tracing so maybe that's the part but the idea here is to have a common trace format that's the CTF part I was talking about that's the format we extract data in if the such tracer can output in CTF format with accurate timestamp we could correlate the traces from kernel and user space but the viewer and all the viewer were really focused on the common trace format we have a tool to convert pick up file from pick up file to CTF so you can generate events from pick up file so maybe if this tracer are able to write pick up or CTF directly we could have analysis for that the pick up to CTF it's available and we also have the syslog to CTF also so you could in the same trace match the syslog with the kernel and user space trace all of that in the same interface of course after that if you want to build analysis based on that you have to add the module because we don't know what the events correspond to but that's the work we are doing on a stream not for now but we design the protocol to have two ports so we have one DCP port that's mandatory, that's the control so we don't want to lose any of these events but the data part could be UDP it's not implemented but it was designed to support UDP as well yes all of all of the demo and screenshot I was showing was using HTNG master so it's usable for now it's not yet frozen but it's usable as of now and all of the tools including HTNG top that's not yet distributed but all of that is on the public gate in master branch so if you want to try that have fun and let me feedback you for Java and kernel we don't have the filtering support but yet we want to have that and in user space we have the filters but not yet for kernel or Java but you can it's a GUL interface to export your trace so you could also filter from the application side but not for now and HTNG yes that would be the idea yes yes yes yes yes yes yes yes yes yes I just saw that we only have one minute left so if you want to come after we can continue the questions thank you