<div dir="ltr"><br><div class="gmail_quote"><div dir="ltr">On Fri, Nov 16, 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>
On Fri, Nov 16, 2018 at 09:49:52AM +0100, mrx wrote:<br>
> Hi,<br>
> <br>
> I have a need to collect LTTng live-traces from systems with very limited<br>
> RAM<br>
> and flash resources. This tracing will be running continuesly for months<br>
> monitoring our systems. The only way for me to transport those CTF records<br>
> somewhere else is via HTTP proxy. LTTng doesn't seem to have support for<br>
> sending<br>
> over proxies at all. So I think I really have a challenge a head of me, if<br>
> this<br>
> is at all possible.<br>
<br>
VPN through http proxy. Better alternative would be to speak with your sysadmin<br>
and see what you can do. Keep in mind that the protocol between relayd and<br>
consumer is in no way "secure".<br></blockquote><div><br></div><div>The security between consumerd and relayd isn't an issue as we'd be forced to keep both on the device. This because we have no way of transporting the consumerd <-> relayd communication over the HTTP proxy, which is our only choice. We have already talked to the team in charge of the network paths.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> <br>
> The plan is to write my own relayd from which I can then stream the<br>
> received CTF<br>
> records + metadata to where I can analyze them. For this to work I need<br>
> documentation on the protocol between consumerd and relayd. I cannot find<br>
> the<br>
> documentation for this, where can I find it?<br>
<br>
The source code.<br>
<br>
> <br>
> Do you think this is a viable solution?<br>
<br>
Doubt it. But we never know.<br>
<br>
> <br>
> Once I receive the data where I have the possiblity to analyze it. Then I'm<br>
> not<br>
> sure if I'm required to write everything to the file system to be able to<br>
> analyze the data. How would I then rotate the logs on disc so I can clean<br>
> up?<br>
<br>
The 2.11 release will include a new feature for session rotation.<br>
<br>
See this presentation [1] from Jérémie Galarneau explaining how the session rotation<br>
can be used.<br>
<br>
[1] <a href="https://events.linuxfoundation.org/wp-content/uploads/2017/12/Fine-grained-Distributed-Application-Monitoring-Using-LTTng-J%C3%A9r%C3%A9mie-Galarneau-EfficiOS.pdf" rel="noreferrer" target="_blank">https://events.linuxfoundation.org/wp-content/uploads/2017/12/Fine-grained-Distributed-Application-Monitoring-Using-LTTng-J%C3%A9r%C3%A9mie-Galarneau-EfficiOS.pdf</a></blockquote><div><br></div><div>I'll for sure look into this.<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 best for me would be if I didn't have to go via disc at all I think.<br>
> <br>
> Are there any others working on similar solution, if so, how are they<br>
> solving this?<br>
> How would you recommend I solve this?<br>
<br>
I would go for session rotation via relayd (not in live mode) with a daemon<br>
watching for ready-to-consume chunks. You can adjust for the granularity<br>
you need at the target level.<br>
<br>
This could be done close to the target then compress the trace chunks and send them<br>
over http(s) to the monitoring pipeline.<br>
<br>
> <br>
> The reason the current relayd doesn't work for me is two-fold:<br>
> 1. I cannot get relayd to not write down the trace to disc. Can you control<br>
> this at all for live tracing?<br>
<br>
What is the real reason for not writing to disk on the relayd side?<br></blockquote><div><br></div><div>The relayd side have to be on the device. The device has very limited amounts of free flash. Even if there were flash available it would wear down the flash faster than what we'd like.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> 2. I cannot find the documentation for the relayd <-> viewer protocol.<br>
> Where can I find it?<br>
<br>
Source code. The initial design proposal is under doc/ in the lttng-tools tree.<br></blockquote><div><br></div><div>Thanks!<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> <br>
> It might be that storing the traces on disc is a pre-requisite for serving a<br>
> viewer properly. Perhaps it's just something required by relayd based on<br>
> how it works internally. I don't know.<br>
<br>
You can look at relayd as a specialized ftp server. The user is responsible in<br>
managing the lifetime of the traces generated. The live protocol simply allow a<br>
viewer to see the trace as it get received/stored.<br></blockquote><div><br></div><div>That helps in visualizing the different components for me, thanks for that!</div><div><br></div><div>It also clarifies some of the problems we face with using relayd as a solution to our problem.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Nothing prevent you to output on a tmpfs (ramdisk) if hitting the disk is such a<br>
problem.<br></blockquote><div><br></div><div>A RAM-based disc might have been a solution if we would have had any mentionable amounts of RAM to spare for this. Unfortunately we don't have that.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<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></blockquote><div><br></div><div>Very valid point, I'll for sure keep that in mind.</div><div><br></div><div>This speaks strongly against replacing relayd with something homebrewed, as was the original plan. We'd probably not be able to shuffle the data fast enough over the network to keep up with the pace.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
You can also use the --trace-file-size and --trace-file-count to limit the disk<br>
footprint of each live session. Make sure to have enough buffer for live<br>
reading if still using live.<br></blockquote><div><br></div><div>This isn't an option as our disc is flash based and we'd like to limit the wear due to collecting metrics.</div><div><br></div><div>Thanks for your insights, much appreciated.</div><div><br></div><div>// Patrik<br></div></div></div>