<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Mon, Nov 19, 2018 at 7:46 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>
> The security between consumerd and relayd isn't an issue as we'd be forced<br>
> to keep both on the device. This because we have no way of transporting the<br>
> consumerd <-> relayd communication over the HTTP proxy, which is our only<br>
> choice. We have already talked to the team in charge of the network paths.<br>
<br>
In that case using lttng-relayd yield no advantage unless you are able to have<br>
a device running only lttng-relayd and gathering data from other devices and<br>
then sending the data via http.<br></blockquote><div><br></div><div>Unfortunately, we're don't have any external device that can run the lttng-relayd component.<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>
> The relayd side have to be on the device. The device has very limited<br>
> amounts of free flash. Even if there were flash available it would wear<br>
> down the flash faster than what we'd like.<br>
<br>
Not sure I follow here. The whole point of lttng-relayd is to be off the device<br>
being traced and to relay trace data using network only (skipping disk).<br></blockquote><div><br></div><div>Sure, so given this I cannot use relayd for our purposes. The only other option would be to set LTTng to local tracing, which we don't have flash for. My hope was that we could somehow stream the CTF records somewhere else, over that HTTP proxy, ot be analyzed. As you explained earlier, the relayd can be viewed as a FTP server of sorts. So that will most likely not work.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> A RAM-based disc might have been a solution if we would have had any<br>
> mentionable amounts of RAM to spare for this. Unfortunately we don't have<br>
> that.<br>
<br>
In all cases you will need some RAM somewhere if using LTTng (and I think any<br>
other monitoring/tracing tools) since we need to allocate tracing buffer.<br></blockquote><div><br></div><div>We have RAM for the tracing buffer, no issues there. The tracing buffer is just a temporary medium until you get the trace on disc, possibly via relayd. Correct?</div><div><br></div><div>I interpretted your RAM disc suggestion as a place where I could store the trace instead of using flash.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> ><br>
> > Keep in mind that trace production is normally much more quicker than trace<br>
> > reading/analysis. A buffering scheme is mostly always necessary.<br>
> ><br>
> <br>
> Very valid point, I'll for sure keep that in mind.<br>
> <br>
> This speaks strongly against replacing relayd with something homebrewed, as<br>
> was the original plan. We'd probably not be able to shuffle the data fast<br>
> enough over the network to keep up with the pace.<br>
<br>
If you are unable to "reserve" RAM/network bandwidth and/or use FLASH this is<br>
slowly becoming a "you can't have your cake and eat it too" situation. This must<br>
be frustrating...<br>
<br>
> ><br>
> > You can also use the --trace-file-size and --trace-file-count to limit the<br>
> > disk<br>
> > footprint of each live session. Make sure to have enough buffer for live<br>
> > reading if still using live.<br>
> ><br>
> <br>
> This isn't an option as our disc is flash based and we'd like to limit the<br>
> wear due to collecting metrics.<br>
<br>
I was under the impression that the lttng-relayd process was on another device.<br>
I misunderstood the situation.<br></blockquote><div><br></div><div>Perhaps i could have been more clear on the situation as well. <br></div><div><br></div><div>We have LTTng tracing capabilites on our devices. During development we can use LTTng on the device and relayd on our dev machines and everything works great.</div><div><br></div><div>In production, the situation is different.</div><div><br></div><div>The only means we have of transporting anything from the device is a HTTP proxy. We're trying to find a way where we can keep a conitnuous LTTng trace on the device, tunnel it through the HTTP proxy and analyze the data remotely.</div><div><br></div><div>The devices are in the embedded realm, limited amounts of RAM, CPU, and flash. This limits what we can do on the device when it comes to storage for example.</div><div><br></div><div>Hopefully I've made our situation a bit more clear.</div><div><br></div><div>Based on our discussion so far, I have to say that LTTng is starting to look less and less as a viable way forward for us.</div><div><br></div><div>Regards,</div><div>Patrik<br></div></div></div>