<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Tue, Nov 20, 2018 at 6:16 PM Jonathan Rajotte-Julien <<a href="mailto:jonathan.rajotte-julien@efficios.com">jonathan.rajotte-julien@efficios.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Patrick,<br>
<br>
> Sure, so given this I cannot use relayd for our purposes. The only other<br>
> option would be to set LTTng to local tracing, which we don't have flash<br>
> for. My hope was that we could somehow stream the CTF records somewhere<br>
> else, over that HTTP proxy, ot be analyzed. As you explained earlier, the<br>
> relayd can be viewed as a FTP server of sorts. So that will most likely not<br>
> work.<br>
<br>
A possibility would be to spare some RAM (not easy I know), mount a tmpfs,<br>
configure the session to output to the tmpfs, use session rotation based on<br>
size, send the data, remove the data, rinse and repeat. Now the question is what<br>
is the amount of tracing data generated and the amount of RAM available.<br>
<br>
> We have RAM for the tracing buffer, no issues there. The tracing buffer is<br>
> just a temporary medium until you get the trace on disc, possibly via<br>
> relayd. Correct?<br>
<br>
Yes.<br>
<br>
The consumerd is responsible for fetching the data from the buffers, then it<br>
output it locally or send it over the network to lttng-relayd.<br>
<br>
You can take a look at the interaction here:<br>
<br>
<a href="https://lttng.org/docs/v2.10/#doc-plumbing" rel="noreferrer" target="_blank">https://lttng.org/docs/v2.10/#doc-plumbing</a></blockquote><div><br></div><div>Is the contents of the RAM buffer already proper CTF records ready to be consumed, or is there some transformation that needs to take place as well? If so, can i find that in some library or is it part of the consumerd code base?</div><div><br></div><div>If i were to read the ring buffer instead of consumerd, then i would perhaps be in a situation where I could stream the ring buffer to another machine over that HTTP proxy? That way I wouldn't need any RAM disc or anything, the data is already stored.<br></div><div><br></div><div>The consumerd logic that reads the ring buffer, is that part of some library i could take advantage of?<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
> <br>
> I interpretted your RAM disc suggestion as a place where I could store the<br>
> trace instead of using flash.<br>
<br>
This was the correct interpretation.<br>
<br>
> <br>
> Perhaps i could have been more clear on the situation as well.<br>
> <br>
> We have LTTng tracing capabilites on our devices. During development we can<br>
> use LTTng on the device and relayd on our dev machines and everything works<br>
> great.<br>
<br>
Glad to hear it.<br></blockquote><div><br></div><div>We're very pleased with LTTng.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> <br>
> In production, the situation is different.<br>
> <br>
> The only means we have of transporting anything from the device is a HTTP<br>
> proxy. We're trying to find a way where we can keep a conitnuous LTTng<br>
> trace on the device, tunnel it through the HTTP proxy and analyze the data<br>
> remotely.<br>
> <br>
> The devices are in the embedded realm, limited amounts of RAM, CPU, and<br>
> flash. This limits what we can do on the device when it comes to storage<br>
> for example.<br>
> <br>
> Hopefully I've made our situation a bit more clear.<br>
> <br>
> Based on our discussion so far, I have to say that LTTng is starting to<br>
> look less and less as a viable way forward for us.<br>
<br>
It would be quite disappointing if you would not be able to reuse the work done<br>
for instrumenting your applications.<br></blockquote><div><br></div><div>Quite so, which is why we're trying so hard to find a viable way forward.</div><div><br></div><div>Regards,</div><div>Patrik<br>
</div></div></div>