[lttng-dev] About Lttng trace mode

[XIANG Hao]

Hi, Daniel

	Very clear, thank you very much for the very valuable information.

BR&Thanks
XiangHao



-----Original Message-----
From: Thibault, Daniel [mailto:Daniel.Thibault at drdc-rddc.gc.ca] 
Sent: 2013年11月15日 1:01
To: lttng-dev at lists.lttng.org
Cc: XIANG Hao
Subject: RE: [lttng-dev] About Lttng trace mode

-----Message d'origine-----
Date: Thu, 14 Nov 2013 13:24:16 +0000
From: XIANG Hao <Hao.Xiang at alcatel-sbell.com.cn>

>   Could Lttng support transmit trace to host PC in a "live mode" or "fly mode" now? So as to reduce the buffer size requirement on the target board.
>
>   BTW, I read some material mentioned:
>   The discard mode is used by default. In this mode, new trace data arriving to a full buffer are discarded. In overwrite mode, the oldest trace data in the buffer are discarded.
>   This mode is also known as flight-recorder mode. Note however, that this refers to the internal buffers, not to the trace log storage. The discarding of events is marked in
>   the trace log and can be noticed when the trace is analyzed. In this way the user can interactively adjust his trace settings.
>
>   What is the difference between "internal buffers" and "trace log storage"? Could the trace log storage be located in the host PC?
>   For example: the target board transmit the trace to Host PC via TCP/UDP, and only a very little internal flight-recorder buffer is required in the target device. Is it feasible?

   Live mode is nearly ready; expect it with version 2.4.

   The difference between internal buffers and trace log storage goes like this: the event providers write into a memory buffer (the internal buffers), and at the same time the consumer daemon(s) withdraw event records from the buffer and commit them to permanent storage (trace log storage).  The buffer is broken down into a number of sub-buffers, and each sub-buffer can only be accessed either by the writers (collectively) or by the consumer.  In discard mode, while a sub-buffer is locked for consumer access, should the writers go around the set of sub-buffers and come up behind the consumer, their request to write into the consumer's sub-buffer will be denied, and they will then discard the event they wanted to record.  The "not to the trace log storage" bit is there to clarify that no event record may ever be lost from the trace files once it has been written into them: they can neither be discarded nor overwritten.  (Actually, using the enable-channel tracefile-size and tracefile-count options, you *can* set up an on-disk flight recorder, but that is a different scenario)

   LTTng can already transmit the trace events to a host machine.  Going back to the example of the writers writing into a memory buffer while the consumer withdraws events from it, the consumer can be instructed to transmit the records to a TCP address instead of writing them to local file storage.  At that address, a relay daemon receives the records and writes them to file storage.  Example:

(on the host machine:)
$ lttng-relayd &
(on the traced machine:)
$ lttng create mysession --set-url net://host (enable events and channels, etc.) $ lttng start
(.)
$ lttng destroy

Daniel U. Thibault
Protection des systèmes et contremesures (PSC) | Systems Protection & Countermeasures (SPC) Cyber sécurité pour les missions essentielles (CME) | Mission Critical Cyber Security (MCCS) R & D pour la défense Canada - Valcartier (RDDC Valcartier) | Defence R&D Canada - Valcartier (DRDC Valcartier)
2459 route de la Bravoure
Québec QC  G3J 1X5
CANADA
Vox : (418) 844-4000 x4245
Fax : (418) 844-4538
NAC : 918V QSDJ <http://www.travelgis.com/map.asp?addr=918V%20QSDJ>
Gouvernement du Canada | Government of Canada <http://www.valcartier.drdc-rddc.gc.ca/>