microsoft / Microsoft-Performance-Tools-Linux-Android

Linux, Android and Chromium Performance Tools built using the Microsoft Performance Toolkit. Cross-platform .NET Core + WPA GUI
MIT License
316 stars 34 forks source link

LTTng Parsing Library to Use #98

Closed nibanks closed 1 year ago

nibanks commented 1 year ago

I see there are a number of NuGet packages published out of this repo that can possibly be used for LTTng parsing. In MsQuic we use LTTng for our tracing on Linux. We also have a custom WPA plugin, that currently only supports our ETW events (used on Windows). We're looking to add LTTng support to our plugin and were wondering if it's possible/reasonable to consume stuff out of here. Can we do this? What should we use? https://www.nuget.org/packages/Microsoft.Performance.Toolkit.Plugins.LinuxLogParser looks promising.

ivberg commented 1 year ago

Hey @nibanks. Nice to see you are looking at using these parsing libs and library!

We do publish various LTTng plugins on NuGet. https://www.nuget.org/packages?q=Microsoft.Performance.Toolkit.Plugins.LTTng

Currently this is how these NuGet packages map to code:

Here are some options

  1. If MsQuic logs as LTTng on Linux which it sounds like it does. You should automatically get support for displaying MsQuic events in the GenericEvents table and data source. You could add support to LTTngDataExtensions if you wanted to add a specific table or support in this repo.
  2. If you wanted to instead consume these libs and add support for say reading MsQuic events from LTTng in your own code/repo, then you would use the LTTngCds package. Then you would add support similar to LTTngDataExtensions in order to present/display the data.

P.S. The MsQuic data is already like present in the GenericEvent datasource and can be queried like so:

           tableData.QueryOutput<ProcessedEventData<LTTngGenericEvent>>(
                DataOutputPath.ForSource(LTTngConstants.SourceId, LTTngGenericEventDataCooker.Identifier, nameof(LTTngGenericEventDataCooker.Events)))

Both option 1 and 2 would give the same result - it's just where you might want the MsQuic specific parsing logic and views to live code-wise.

Hope that helps but LMK if you have questions

nibanks commented 1 year ago

Thanks a lot @ivberg! I think we'll likely go forward with your (2) above, since we have an abstraction layer in our WPA plugin already that reads MsQuic ETW events and converts them to a general object model that we use in all our charts/graphs. We just need to read LTTng events and convert to the same object model.

We'll likely be in contact if we need anything else, but for now I think this all answers my question. Thanks!