[lttng-dev] String format based events

[lttng-dev] String format based events

[Jeffrey Chen]

I have a question while reading the lttng documentation. Could anyone answer me? Thanks a lot.

It looks like lttng events are all key-value pairs. Like { my_val1 = 10, my_val2 = "OK" }. Does lttng supports regular string format based events, like Windows ETW. I want a human readable sentences in the event like "My CPU usage is 50 , my memory usage is 100". Of course, I know I could manually construct the string myself and pass the result in one string down to lttng. But, the idea is that, string format is slow. So, Windows ETW does the string formatting only when you read the logs.
For example, if I want to write many "My CPU usage is {0} , my memory usage is {1}" to log. Windows ETW does not write this whole string to log. It only writes the 2 variable values of this trace to the log, and construct back the original string when you are reading the logs.

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lttng.org/pipermail/lttng-dev/attachments/20150617/550bee35/attachment.html>

[lttng-dev] String format based events

[Jeffrey Chen]

I have a question while reading the lttng documentation. Could anyone answer me? Thanks a lot.
It looks like lttng events are all key-value pairs. Like { my_val1 = 10, my_val2 = "OK" }. Does lttng supports regular string format based events, like Windows ETW. I want a human readable sentences in the event like "My CPU usage is 50 , my memory usage is 100". Of course, I know I could manually construct the string myself and pass the result in one string down to lttng. But, the idea is that, string format is slow. So, Windows ETW does the string formatting only when you read the logs.
For example, if I want to write many "My CPU usage is {0} , my memory usage is {1}" to log. Windows ETW does not write this whole string to log. It only writes the 2 variable values of this trace to the log, and construct back the original string when you are reading the logs.

 		 	   		   		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lttng.org/pipermail/lttng-dev/attachments/20150618/01a889a6/attachment-0001.html>

[lttng-dev] String format based events

[Philippe Proulx]

On Wed, Jun 17, 2015 at 7:51 PM, Jeffrey Chen <cpthk at hotmail.com> wrote:
> I have a question while reading the lttng documentation. Could anyone answer
> me? Thanks a lot.
>
> It looks like lttng events are all key-value pairs. Like { my_val1 = 10,
> my_val2 = "OK" }. Does lttng supports regular string format based events,
> like Windows ETW. I want a human readable sentences in the event like "My
> CPU usage is 50 , my memory usage is 100". Of course, I know I could
> manually construct the string myself and pass the result in one string down
> to lttng. But, the idea is that, string format is slow. So, Windows ETW does
> the string formatting only when you read the logs.
> For example, if I want to write many "My CPU usage is {0} , my memory usage
> is {1}" to log. Windows ETW does not write this whole string to log. It only
> writes the 2 variable values of this trace to the log, and construct back
> the original string when you are reading the logs.

Hello Jeffrey!

We (EfficiOS) are currently working on such a feature, which involves
changes to all the following projects:

  * CTF (trace format used by LTTng): allow custom user attributes to
    be assigned to types and events in the trace metadata (this is where
    the format string would go)
  * LTTng-UST: add a macro to be used in tracepoint providers to
    assign a format string to a specific event
  * Babeltrace: upgrade the ctf-text plugin so that it takes into
    account the format string of an event, if available, to print it in a
    custom way

We could also think about a tool, or a Babeltrace input plugin perhaps,
which converts the Windows ETW format to CTF; we would need to
parse the format strings and convert them to our own syntax.

The format string syntax we're intending to use is Python's format()
one [1], or at least a subset of its features. It is very flexible and
allows to name fields, modify them, and place them where you
want, e.g.:

"My field is {field}, which is {field:x} in hex, and also: {other_field}"

Replacement fields may also be empty to be position-based:

"My field is {}, and also: {}"

(you would need exactly two fields here).

[1] https://docs.python.org/3/library/string.html#formatstrings

Phil

>
>
> _______________________________________________
> lttng-dev mailing list
> lttng-dev at lists.lttng.org
> http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
>