Automatic Performance Instrumentation for MAUI (includes mobile vitals)

[bruno-garcia]

• Performance monitoring for screen loading (Support transaction finishing automatically with 'idle timeout' #1074),
  • Transaction annotations (see spec)
• Mobile Vitals, including app start time instrumentation
  • TTID & TTID for navigating between screens (see: TTID & TTFD for navigating between screens sentry-dart#1780)
  • https://changelog.getsentry.com/announcements/improving-mobile-screen-performance-with-ttid-ttfd
  • Slow and Frozen frames require Delay info: [EPIC] Frames Delay team-mobile#160
• DB queries as span (EF?)
• Automatic HTTP span and trace id propagation (exists in SentryHttpMessageHandler)
• Transactions for UI events (see this)
• Custom measurements API (Q3 goal)

The complete list of modules now lives here:
https://develop.sentry.dev/sdk/telemetry/traces/modules/

[bruno-garcia]

Kotlin Multiplatform version of it:

• feat: custom apm sentry-kotlin-multiplatform#155

[de-preut]

Any updates on these tasks? We would really make use of the 'mobile vitals' in our app

[bruno-garcia]

Hey @de-preut sorry for the late reply. I'd ask @bitsandfoxes and @jamescrosswell , when they are prioritizing it. I'd love to see it land too ;)

[bitsandfoxes]

Having at least mobile vitals would indeed be nice.

[jamescrosswell]

Having at least mobile vitals would indeed be nice.

I'll let you slot it into our priorities board somewhere @bitsandfoxes 👍🏻

[jakircevic]

This would be huge for us. Thanks !

[bruno-garcia]

came up again from a sales led org

[jamescrosswell]

came up again from a sales led org

I've bumped up the priority on this to "Must Have".

@aritchie probably a good one for you to pick up eventually. It probably starts with creating auto transactions for common UI events (like click). I think once we have those, we get tracing on DB requests and outbound HttpRequests for free from the other/separate integrations we have for those things already... but needs testing/verifying.

[samykolahi]

Excellent news if this gets pushed forward.

[bruno-garcia]

There's also a bunch of new features that we got in native Android and iOS as well as Flutter and React Native. Just MAUI is lagging behind.

This issue, and Session Replay are the highest priority features for MAUI now.

[aritchie]

@bruno-garcia @jamescrosswell Thoughts/questions/etc on implementing the features listed.

Including app start time instrumentation

What is the thinking here regarding MAUI? Sentry can't really get involved until setup the MauiProgram. Do we consider startup to the first PageAppearing?

Slow and Frozen frames require Delay info

Frame rate is a value we can capture. Just not sure how we'll record it. The value does seem to bounce around a lot. Thoughts?
dotnet/maui#8876

TTID & TTID for navigating between screens

Should be doable using the MauiEventsBinder by watching Application.PageAppearing & Application.PageDisappearing. "Time to full display" vs "Time to initial display" I'm not sure we can differentiate.

DB queries as span

It isn't advisable for users to use EF on MAUI. Most users from my experience are using one of the following libraries

https://github.com/praeclarum/sqlite-net
https://learn.microsoft.com/en-us/dotnet/standard/data/sqlite/?tabs=net-cli

Both of these libraries could have their corresponding connections wrapped in a Sentry provider. Thoughts?

Automatic HTTP span and trace id propagation (exists in SentryHttpMessageHandler)

This can be accomplished with HTTP client factory, but will require docs on the setup.

https://learn.microsoft.com/en-us/dotnet/architecture/microservices/implement-resilient-applications/use-httpclientfactory-to-implement-resilient-http-requests

Transactions for UI events

This should be fairly straight forward to accomplish. I can start here.

[jamescrosswell]

Sentry can't really get involved until setup the MauiProgram.

Can we read the actual startup time from the Process?

"Time to full display" vs "Time to initial display" I'm not sure we can differentiate.

The distinction between those two seems more relevant for Web applications.... I reckon for MAUI apps we could just store one of these (TTFD perhaps).

It isn't advisable for users to use EF on MAUI. Most users from my experience are using one of the following libraries

https://github.com/praeclarum/sqlite-net
https://learn.microsoft.com/en-us/dotnet/standard/data/sqlite/?tabs=net-cli

Maybe do that in a separate follow up PR - if we do all of these in the same ticket the diff will be huge and hard to review/merge.

But, we might get the second one for free (it's ADO.NET so might be instrumented via DiagnosticSource - would need to experiment to confirm that).

If there was enough demand for the first one, that repo accepts contributions. We could add the instrumentation that we want to capture using the MS Activity classes... and we've got an OpenTelemetry integration that we could use to capture the resulting spans.

This should be fairly straight forward to accomplish. I can start here.

🎉 🙌🏻

[aritchie]

@bruno-garcia @jamescrosswell I did some testing on the two big sqlite mechanisms.

https://www.nuget.org/packages/sqlite-net-pcl - has absolutely zero extensibility points at this time and nothing is marked virtual. There isn't much that can be done here.

https://www.nuget.org/packages/Microsoft.Data.Sqlite - Doesn't have any instrumentation plug points, but we could wrap the sqlconnection and move down the execution graph from there.

I think this particular feature point is something that can be moved to the backlog for a future time. Thoughts?

[bruno-garcia]

@bruno-garcia @jamescrosswell I did some testing on the two big sqlite mechanisms.

nuget.org/packages/sqlite-net-pcl - has absolutely zero extensibility points at this time and nothing is marked virtual. There isn't much that can be done here.

nuget.org/packages/Microsoft.Data.Sqlite - Doesn't have any instrumentation plug points, but we could wrap the sqlconnection and move down the execution graph from there.

I think this particular feature point is something that can be moved to the backlog for a future time. Thoughts?

Lots of other stuff we can do instead then, lets leave Sqlite out for now.

Auto transactions is n1 IMO. Then with that you can add "vitals" (the first 4). Docs here.
And the new stuff, TTFD etc. Under that docs link there's App Start and Screen Load with more details. ALl of that exists in Flutter, React Native, iOS/Android native so lots we can take away from

Meaning: When the app starts as early as we can, we StartTransaction. And when it finishes rendering, we can Finish that, but we don't flush it all yet. Since any StartSpan or StartChild or whatever API creates spans will get spans created onto that transaction. There's the concept of waitForChildren so that we don't flush until the child spans complete. So any async operation started as part of the screen loading (sometimes in an app start, sometime the app was already up so just a transition, taht's important for op and other context) can finish and you don't get a "Screen load transaction" of 10ms that represents loading a spinner only for example.