[lttng-dev] Workflow to view old and current trace data
Hi, long time no see! Consider a system that's recording trace data continuously from a userspace application. A problem is noticed and I'd like to investigate it. What workflow would allow me to view past trace data to analyze the cause of the problem and view current (live) trace data while working on fixing the problem, all the while keeping a continuous record of events (ie. not stopping the trace)? I thought of the following approaches but both seem to have disadvantages: 1) Have one continuous tracing session in normal mode. When a problem is noticed, use lttng-rotate to be able to read old trace data. Start a second tracing session in live mode with the same event rules to view live trace data. IIUC, there's no option to prevent lttng-relayd from writing the traces to disk, so we end up writing two sets of identical traces to disk during the time we want to look at live trace data. 2) Have one tracing session running in live mode all the time. When a problem is noticed, use the viewer on whatever lttng-relayd has flushed to disk to access old trace data (session rotation is not available). Furthermore, this workflow has the disadvantage that the trace data is going through lttng-relayd all the time (which I guess is less efficient than writing it from lttng-consumerd) merely to support the rare case where data needs to be seen live while analyzing a problem. Is there some better approach that I didn't think about? What's your recommendation to support this workflow? I'm comparing lttng to the situation where the userspace application is writing its logs directly to a file. In that case, it's simple to read the file to access old and "live" data. Of course I realize that lttng shines in other areas where simple file writing does not ;) Thank you, -Benjamin ___ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
[lttng-dev] [RFC PATCH lttng-tools] Fix: relayd: Swap endianness of packet index
The packet index in stream_update_index() is meant to be stored
to disk, and therefore is kept in big endian.
Swap its endianness to host endian before using it internally.
Fixes "Fix: relayd: use packet sequence number for rotation position".
Signed-off-by: Mathieu Desnoyers
---
src/bin/lttng-relayd/stream.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/bin/lttng-relayd/stream.c b/src/bin/lttng-relayd/stream.c
index c5bf3759..f9ff5e9a 100644
--- a/src/bin/lttng-relayd/stream.c
+++ b/src/bin/lttng-relayd/stream.c
@@ -1142,7 +1142,8 @@ int stream_update_index(struct relay_stream *stream,
uint64_t net_seq_num,
tracefile_array_file_rotate(stream->tfa, TRACEFILE_ROTATE_READ);
tracefile_array_commit_seq(stream->tfa);
stream->index_received_seqcount++;
- stream->received_packet_seq_num =
index->index_data.packet_seq_num;
+ stream->received_packet_seq_num =
+ be64toh(index->index_data.packet_seq_num);
*flushed = true;
} else if (ret > 0) {
index->total_size = total_size;
--
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] Workflow to view old and current trace data
- On Nov 8, 2019, at 3:49 AM, Benjamin Poirier benjamin.poir...@gmail.com wrote: > Hi, long time no see! > > Consider a system that's recording trace data continuously from a > userspace application. A problem is noticed and I'd like to investigate > it. What workflow would allow me to view past trace data to analyze the > cause of the problem and view current (live) trace data while working on > fixing the problem, all the while keeping a continuous record of events > (ie. not stopping the trace)? > > I thought of the following approaches but both seem to have > disadvantages: > 1) > Have one continuous tracing session in normal mode. When a problem is > noticed, use lttng-rotate to be able to read old trace data. Start a > second tracing session in live mode with the same event rules to view > live trace data. IIUC, there's no option to prevent lttng-relayd from > writing the traces to disk, so we end up writing two sets of identical > traces to disk during the time we want to look at live trace data. > 2) > Have one tracing session running in live mode all the time. When a > problem is noticed, use the viewer on whatever lttng-relayd has flushed > to disk to access old trace data (session rotation is not available). > Furthermore, this workflow has the disadvantage that the trace data is > going through lttng-relayd all the time (which I guess is less efficient > than writing it from lttng-consumerd) merely to support the rare case > where data needs to be seen live while analyzing a problem. > > Is there some better approach that I didn't think about? What's your > recommendation to support this workflow? > > I'm comparing lttng to the situation where the userspace application is > writing its logs directly to a file. In that case, it's simple to read > the file to access old and "live" data. Of course I realize that lttng > shines in other areas where simple file writing does not ;) Why do you need the "live" mode at all ? What do you intend to do with the live stream that cannot be done through notifiers invoked on rotation completion and use size-based or timer-based rotations ? Thanks, Mathieu > > Thank you, > -Benjamin > ___ > lttng-dev mailing list > lttng-dev@lists.lttng.org > https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com ___ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
Re: [lttng-dev] [PATCH lttng-ust] Require automake >= 1.12
Merged into master branch, thanks! Mathieu - On Nov 7, 2019, at 1:48 PM, Michael Jeanson mjean...@efficios.com wrote: > The test suite LOG_DRIVER statement requires that automake >= 1.12 be used > during bootstrap. > > Signed-off-by: Michael Jeanson > --- > configure.ac | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/configure.ac b/configure.ac > index 319cb401..001c4428 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -41,7 +41,7 @@ AC_CONFIG_SRCDIR([include/lttng/tracepoint.h]) > AC_CANONICAL_TARGET > AC_CANONICAL_HOST > > -AM_INIT_AUTOMAKE([1.9 foreign dist-bzip2 no-dist-gzip tar-ustar]) > +AM_INIT_AUTOMAKE([1.12 foreign dist-bzip2 no-dist-gzip tar-ustar]) > AM_MAINTAINER_MODE([enable]) > > # Enable silent rules if available (Introduced in AM 1.11) > -- > 2.17.1 -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com ___ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
Re: [lttng-dev] [PATCH urcu] Require automake >= 1.12
Merged into master branch, thanks! Mathieu - On Nov 7, 2019, at 1:39 PM, Michael Jeanson mjean...@efficios.com wrote: > The test suite LOG_DRIVER statement requires that automake >= 1.12 be used > during bootstrap. > > Signed-off-by: Michael Jeanson > --- > configure.ac | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/configure.ac b/configure.ac > index 1d13ea3..df3fb7c 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -12,7 +12,7 @@ AC_CONFIG_MACRO_DIR([m4]) > AC_CANONICAL_TARGET > AC_CANONICAL_HOST > > -AM_INIT_AUTOMAKE([foreign dist-bzip2 no-dist-gzip nostdinc]) > +AM_INIT_AUTOMAKE([1.12 foreign dist-bzip2 no-dist-gzip nostdinc]) > AM_MAINTAINER_MODE([enable]) > > # Enable silent rules if available (Introduced in AM 1.11) > -- > 2.17.1 -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com ___ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
