[lttng-dev] A question on protocols
Jonathan Rajotte-Julien
jonathan.rajotte-julien at efficios.com
Tue Nov 20 12:16:39 EST 2018
Hi Patrick,
> 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.
A possibility would be to spare some RAM (not easy I know), mount a tmpfs,
configure the session to output to the tmpfs, use session rotation based on
size, send the data, remove the data, rinse and repeat. Now the question is what
is the amount of tracing data generated and the amount of RAM available.
> 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?
Yes.
The consumerd is responsible for fetching the data from the buffers, then it
output it locally or send it over the network to lttng-relayd.
You can take a look at the interaction here:
https://lttng.org/docs/v2.10/#doc-plumbing
>
> I interpretted your RAM disc suggestion as a place where I could store the
> trace instead of using flash.
This was the correct interpretation.
>
> Perhaps i could have been more clear on the situation as well.
>
> 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.
Glad to hear it.
>
> In production, the situation is different.
>
> 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.
>
> 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.
>
> Hopefully I've made our situation a bit more clear.
>
> 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.
It would be quite disappointing if you would not be able to reuse the work done
for instrumenting your applications.
Cheers
--
Jonathan Rajotte-Julien
EfficiOS
More information about the lttng-dev
mailing list