Hi Patrick, > 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.
In that case using lttng-relayd yield no advantage unless you are able to have a device running only lttng-relayd and gathering data from other devices and then sending the data via http. > > 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. Not sure I follow here. The whole point of lttng-relayd is to be off the device being traced and to relay trace data using network only (skipping disk). > 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. In all cases you will need some RAM somewhere if using LTTng (and I think any other monitoring/tracing tools) since we need to allocate tracing buffer. > > > > Keep in mind that trace production is normally much more quicker than trace > > reading/analysis. A buffering scheme is mostly always necessary. > > > > Very valid point, I'll for sure keep that in mind. > > 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. If you are unable to "reserve" RAM/network bandwidth and/or use FLASH this is slowly becoming a "you can't have your cake and eat it too" situation. This must be frustrating... > > > > You can also use the --trace-file-size and --trace-file-count to limit the > > disk > > footprint of each live session. Make sure to have enough buffer for live > > reading if still using live. > > > > This isn't an option as our disc is flash based and we'd like to limit the > wear due to collecting metrics. I was under the impression that the lttng-relayd process was on another device. I misunderstood the situation. Cheers -- Jonathan Rajotte-Julien EfficiOS _______________________________________________ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev