Re: [lttng-dev] [barectf] Filter trace messages based on log level

[Philippe Proulx via lttng-dev]

On Tue, Oct 6, 2020 at 9:16 AM Owen, Mark (US) via lttng-dev
 wrote:
>
> Hi,
>
> Thank you for your work on barectf!

Thank you for writing, Mark.

I always appreciate getting feedback regarding barectf.

>
> I'm considering using it with our embedded MCUs that run on bare metal
> in conjunction with other devices running embedded Linux. The barectf
> platform back end would primarily be async serial that would be
> consumed by a device running embedded Linux.

barectf seems like a good fit indeed.

>
> Our current home brew trace implementation is limited to a logging a
> log level and a message string. I see great potential in being able to
> use the CTF format to output much more information when events occur
> than just a level and a string. My primary concern with barectf is
> that our current trace implementation allows us to filter out packets
> based on log level. I believe this will be necessary for us not to
> exceed our bandwidth limitation (the serial port may also need to be
> shared for telemetry and command messaging).
>
> My question is, do you think barectf is a good fit for filtering
> packets based on a logging level? If so, where would you suggest
> implementing said filtering (e.g. extending the platform API or use a
> custom API in the specific platform implementation)?
>
> I see that the platform API supports enabling or disabling tracing but
> I am looking for something more granular. Is this something that make
> sense to be implemented in the platform implementation? My initial
> thought is that we would probably need to extend our barectf platform,
> back end implementation to include methods for setting the logging
> filter level.

barectf doesn't directly support dynamic event record filtering
currently.

The current role of a barectf platform is to write closed CTF packets to
some back end (async serial in your case), so this is not where you
would deal with event record filtering at the moment.

Here are two suggestions:

1. Wrap the generated barectf tracing functions at your application
   level to augment them with logging-level-based filtering.

   You can probably do this with preprocessor macros.

2. We can add some dynamic event record filtering feature to the
   upstream barectf project.

   I don't have the details, but, for each tracing function, a callback
   function (part of the platform, maybe) would be called to accept or
   reject the event record.

   EfficiOS offers development services which can help here;
   see .

Hope this helps!

Philippe

>
> Before I moved forward I wanted to get your input. Any guidance you
> could provide here would be very helpful.
>
> Thank you,
>
> Mark Owen

>
>
>
> 
>
> Notice to recipient: This email is meant for only the intended recipient of 
> the transmission, and may be a communication privileged by law, subject to 
> export control restrictions or that otherwise contains proprietary 
> information. If you receive this email by mistake, please notify us 
> immediately by replying to this message and then destroy it and do not 
> review, disclose, copy or distribute it. Thank you in advance for your 
> cooperation.
> ___
> lttng-dev mailing list
> lttng-dev@lists.lttng.org
> https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

[lttng-dev] [barectf] Filter trace messages based on log level

[Owen, Mark (US) via lttng-dev]

Hi,

Thank you for your work on barectf!

I'm considering using it with our embedded MCUs that run on bare metal in
conjunction with other devices running embedded Linux. The barectf platform back
end would primarily be async serial that would be consumed by a device running
embedded Linux.

Our current home brew trace implementation is limited to a logging a log level
and a message string. I see great potential in being able to use the CTF format
to output much more information when events occur than just a level and a
string. My primary concern with barectf is that our current trace implementation
allows us to filter out packets based on log level. I believe this will be
necessary for us not to exceed our bandwidth limitation (the serial port may
also need to be shared for telemetry and command messaging).

My question is, do you think barectf is a good fit for filtering packets based
on a logging level? If so, where would you suggest implementing said filtering
(e.g. extending the platform API or use a custom API in the specific platform
implementation)?

I see that the platform API supports enabling or disabling tracing but I am
looking for something more granular. Is this something that make sense to be
implemented in the platform implementation? My initial thought is that we would
probably need to extend our barectf platform, back end implementation to include
methods for setting the logging filter level.

Before I moved forward I wanted to get your input. Any guidance you could
provide here would be very helpful.

Thank you,

Mark Owen





Notice to recipient: This email is meant for only the intended recipient of the 
transmission, and may be a communication privileged by law, subject to export 
control restrictions or that otherwise contains proprietary information. If you 
receive this email by mistake, please notify us immediately by replying to this 
message and then destroy it and do not review, disclose, copy or distribute it. 
Thank you in advance for your cooperation.
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev