[lttng-dev] A question on protocols
Hi, I have a need to collect LTTng live-traces from systems with very limited RAM and flash resources. This tracing will be running continuesly for months monitoring our systems. The only way for me to transport those CTF records somewhere else is via HTTP proxy. LTTng doesn't seem to have support for sending over proxies at all. So I think I really have a challenge a head of me, if this is at all possible. The plan is to write my own relayd from which I can then stream the received CTF records + metadata to where I can analyze them. For this to work I need documentation on the protocol between consumerd and relayd. I cannot find the documentation for this, where can I find it? Do you think this is a viable solution? Once I receive the data where I have the possiblity to analyze it. Then I'm not sure if I'm required to write everything to the file system to be able to analyze the data. How would I then rotate the logs on disc so I can clean up? The best for me would be if I didn't have to go via disc at all I think. Are there any others working on similar solution, if so, how are they solving this? How would you recommend I solve this? The reason the current relayd doesn't work for me is two-fold: 1. I cannot get relayd to not write down the trace to disc. Can you control this at all for live tracing? 2. I cannot find the documentation for the relayd <-> viewer protocol. Where can I find it? It might be that storing the traces on disc is a pre-requisite for serving a viewer properly. Perhaps it's just something required by relayd based on how it works internally. I don't know. Do you have any suggestions on how to solve this? Any insights and/or feedback would be appreciated. Thanks a lot in advance. Patrik Iselind ___ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
Re: [lttng-dev] A question on protocols
Hi Patrick, On Fri, Nov 16, 2018 at 09:49:52AM +0100, mrx wrote: > Hi, > > I have a need to collect LTTng live-traces from systems with very limited > RAM > and flash resources. This tracing will be running continuesly for months > monitoring our systems. The only way for me to transport those CTF records > somewhere else is via HTTP proxy. LTTng doesn't seem to have support for > sending > over proxies at all. So I think I really have a challenge a head of me, if > this > is at all possible. VPN through http proxy. Better alternative would be to speak with your sysadmin and see what you can do. Keep in mind that the protocol between relayd and consumer is in no way "secure". > > The plan is to write my own relayd from which I can then stream the > received CTF > records + metadata to where I can analyze them. For this to work I need > documentation on the protocol between consumerd and relayd. I cannot find > the > documentation for this, where can I find it? The source code. > > Do you think this is a viable solution? Doubt it. But we never know. > > Once I receive the data where I have the possiblity to analyze it. Then I'm > not > sure if I'm required to write everything to the file system to be able to > analyze the data. How would I then rotate the logs on disc so I can clean > up? The 2.11 release will include a new feature for session rotation. See this presentation [1] from Jérémie Galarneau explaining how the session rotation can be used. [1] https://events.linuxfoundation.org/wp-content/uploads/2017/12/Fine-grained-Distributed-Application-Monitoring-Using-LTTng-J%C3%A9r%C3%A9mie-Galarneau-EfficiOS.pdf > The best for me would be if I didn't have to go via disc at all I think. > > Are there any others working on similar solution, if so, how are they > solving this? > How would you recommend I solve this? I would go for session rotation via relayd (not in live mode) with a daemon watching for ready-to-consume chunks. You can adjust for the granularity you need at the target level. This could be done close to the target then compress the trace chunks and send them over http(s) to the monitoring pipeline. > > The reason the current relayd doesn't work for me is two-fold: > 1. I cannot get relayd to not write down the trace to disc. Can you control > this at all for live tracing? What is the real reason for not writing to disk on the relayd side? > 2. I cannot find the documentation for the relayd <-> viewer protocol. > Where can I find it? Source code. The initial design proposal is under doc/ in the lttng-tools tree. > > It might be that storing the traces on disc is a pre-requisite for serving a > viewer properly. Perhaps it's just something required by relayd based on > how it works internally. I don't know. You can look at relayd as a specialized ftp server. The user is responsible in managing the lifetime of the traces generated. The live protocol simply allow a viewer to see the trace as it get received/stored. Nothing prevent you to output on a tmpfs (ramdisk) if hitting the disk is such a problem. Keep in mind that trace production is normally much more quicker than trace reading/analysis. A buffering scheme is mostly always necessary. 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. Cheers -- Jonathan Rajotte-Julien EfficiOS ___ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
Re: [lttng-dev] [PATCH lttng-tools 2/2] Fix: typo 'convet' -> 'convert'
All four typo fix patches were merged in master and stable-2.11.
Thanks!
Jérémie
On Thu, Nov 15, 2018 at 12:16:37PM -0500, Michael Jeanson wrote:
> Signed-off-by: Michael Jeanson
> ---
> src/common/lttng-elf.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/common/lttng-elf.c b/src/common/lttng-elf.c
> index 52e05f0c6..cb01f7bb7 100644
> --- a/src/common/lttng-elf.c
> +++ b/src/common/lttng-elf.c
> @@ -861,7 +861,7 @@ int lttng_elf_get_symbol_offset(int fd, char *symbol,
> uint64_t *offset)
>*/
> ret = lttng_elf_convert_addr_in_text_to_offset(elf, addr, offset);
> if (ret) {
> - DBG("Cannot convet addr to offset.");
> + DBG("Cannot convert addr to offset.");
> goto free_string_table_data;
> }
>
> --
> 2.17.1
>
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
Re: [lttng-dev] [PATCH lttng-tools 1/2] Fix: Connect timeout arithmetic in inet/inet6 (v4)
Merged all the way back to 2.9.
Thanks!
Jérémie
On Tue, Nov 13, 2018 at 12:12:20PM -0500, Mathieu Desnoyers wrote:
> The nanoseconds part of the timespec struct time_a is not always
> bigger than time_b since it wrap around each seconds.
>
> Use 64-bit arithmetic to perform the difference.
>
> Merge/move duplicated code into utils.c.
>
> This function is really doing two things. Split it into timespec_to_ms()
> and timespec_abs_diff().
>
> Signed-off-by: Mathieu Desnoyers
> ---
> Changes since v1:
> - Use NSEC_PER_SEC constant.
>
> Changes since v2:
> - Move prototypes to time.h.
> - Adapt timespec_to_ms() range check to take into account tv_nsec beyond
> 10-1.
>
> Changes since v3:
> - Use remainer for detection of overflow.
> - set errno to EOVERFLOW in timespec_to_ms.
> ---
> src/common/common.h | 1 +
> src/common/sessiond-comm/inet.c | 27 +++
> src/common/sessiond-comm/inet6.c | 27 +++
> src/common/time.h| 15 +++
> src/common/utils.c | 36
> 5 files changed, 66 insertions(+), 40 deletions(-)
>
> diff --git a/src/common/common.h b/src/common/common.h
> index 41eb0361..9168a245 100644
> --- a/src/common/common.h
> +++ b/src/common/common.h
> @@ -23,5 +23,6 @@
> #include "macros.h"
> #include "runas.h"
> #include "readwrite.h"
> +#include "time.h"
>
> #endif /* _COMMON_H */
> diff --git a/src/common/sessiond-comm/inet.c b/src/common/sessiond-comm/inet.c
> index e0b3e7a9..ac450dbc 100644
> --- a/src/common/sessiond-comm/inet.c
> +++ b/src/common/sessiond-comm/inet.c
> @@ -112,31 +112,13 @@ int connect_no_timeout(struct lttcomm_sock *sock)
> sizeof(sock->sockaddr.addr.sin));
> }
>
> -/*
> - * Return time_a - time_b in milliseconds.
> - */
> -static
> -unsigned long time_diff_ms(struct timespec *time_a,
> - struct timespec *time_b)
> -{
> - time_t sec_diff;
> - long nsec_diff;
> - unsigned long result_ms;
> -
> - sec_diff = time_a->tv_sec - time_b->tv_sec;
> - nsec_diff = time_a->tv_nsec - time_b->tv_nsec;
> -
> - result_ms = sec_diff * MSEC_PER_SEC;
> - result_ms += nsec_diff / NSEC_PER_MSEC;
> - return result_ms;
> -}
> -
> static
> int connect_with_timeout(struct lttcomm_sock *sock)
> {
> unsigned long timeout = lttcomm_get_network_timeout();
> int ret, flags, connect_ret;
> struct timespec orig_time, cur_time;
> + unsigned long diff_ms;
>
> ret = fcntl(sock->fd, F_GETFL, 0);
> if (ret == -1) {
> @@ -217,7 +199,12 @@ int connect_with_timeout(struct lttcomm_sock *sock)
> connect_ret = ret;
> goto error;
> }
> - } while (time_diff_ms(&cur_time, &orig_time) < timeout);
> + if (timespec_to_ms(timespec_abs_diff(cur_time, orig_time),
> &diff_ms) < 0) {
> + ERR("timespec_to_ms input overflows milliseconds
> output");
> + connect_ret = -1;
> + goto error;
> + }
> + } while (diff_ms < timeout);
>
> /* Timeout */
> errno = ETIMEDOUT;
> diff --git a/src/common/sessiond-comm/inet6.c
> b/src/common/sessiond-comm/inet6.c
> index dfb5fc5d..03b6627d 100644
> --- a/src/common/sessiond-comm/inet6.c
> +++ b/src/common/sessiond-comm/inet6.c
> @@ -110,31 +110,13 @@ int connect_no_timeout(struct lttcomm_sock *sock)
> sizeof(sock->sockaddr.addr.sin6));
> }
>
> -/*
> - * Return time_a - time_b in milliseconds.
> - */
> -static
> -unsigned long time_diff_ms(struct timespec *time_a,
> - struct timespec *time_b)
> -{
> - time_t sec_diff;
> - long nsec_diff;
> - unsigned long result_ms;
> -
> - sec_diff = time_a->tv_sec - time_b->tv_sec;
> - nsec_diff = time_a->tv_nsec - time_b->tv_nsec;
> -
> - result_ms = sec_diff * MSEC_PER_SEC;
> - result_ms += nsec_diff / NSEC_PER_MSEC;
> - return result_ms;
> -}
> -
> static
> int connect_with_timeout(struct lttcomm_sock *sock)
> {
> unsigned long timeout = lttcomm_get_network_timeout();
> int ret, flags, connect_ret;
> struct timespec orig_time, cur_time;
> + unsigned long diff_ms;
>
> ret = fcntl(sock->fd, F_GETFL, 0);
> if (ret == -1) {
> @@ -216,7 +198,12 @@ int connect_with_timeout(struct lttcomm_sock *sock)
> connect_ret = ret;
> goto error;
> }
> - } while (time_diff_ms(&cur_time, &orig_time) < timeout);
> + if (timespec_to_ms(timespec_abs_diff(cur_time, orig_time),
> &diff_ms) < 0) {
> + ERR("timespec_to_ms input overflows milliseconds
> output");
> + connect_ret = -1;
> + goto error;
> + }
> + } while (diff_ms < timeout);
>
> /* Timeout */
> errno = ETIMEDOUT;
> diff --git
Re: [lttng-dev] [PATCH lttng-tools 2/2] Fix: max_t/min_t macros are missing cast on input
Merged all the way back to 2.9. Thanks! Jérémie On Tue, Nov 13, 2018 at 12:12:21PM -0500, Mathieu Desnoyers wrote: > The semantic expected from max_t and min_t is to perform the max/min > comparison in the type provided as first parameter. > > Cast the input parameters to the proper type before comparing them, > rather than after. There is no more need to cast the result of the > expression now that both inputs are cast to the right type. > > Signed-off-by: Mathieu Desnoyers > --- > src/common/macros.h | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/src/common/macros.h b/src/common/macros.h > index c521aacd..461202ff 100644 > --- a/src/common/macros.h > +++ b/src/common/macros.h > @@ -72,7 +72,7 @@ void *zmalloc(size_t len) > #endif > > #ifndef max_t > -#define max_t(type, a, b)((type) max(a, b)) > +#define max_t(type, a, b)max((type) a, (type) b) > #endif > > #ifndef min > @@ -80,7 +80,7 @@ void *zmalloc(size_t len) > #endif > > #ifndef min_t > -#define min_t(type, a, b)((type) min(a, b)) > +#define min_t(type, a, b)min((type) a, (type) b) > #endif > > #ifndef LTTNG_PACKED > -- > 2.11.0 > ___ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
