Performance monitoring for Micro-frontends

[realkosty]

Problem Statement

2 customers are interested in having a solution to measuring performance in micro-frontend architectures.

An acceptable solution would capture each micro-frontend from loading, through rendering to being fully initialized as a parent span (and possibly a custom metric or DDM), making sure that all spans involved in initializing it are captured as child spans. As of today child spans from different micro-frontends would be lost in the "soup" of spans from all other MFEs. An acceptable solution should not require extensive custom instrumentation. A good solution would be easy to configure and work out-of-the box.

Solution Brainstorm

I understand this is not currently possible in v7 due to lack of scope isolation.

A highly manual, complex solution may be possible with custom instrumentation (currently evaluating feasibility).

Related

• [Question/Bug] Can't report Transactions on multiple instances with different DSNs #4185
• uncaughtException: parentSpan.transaction.getDynamicSamplingContext is not a function after upgrading to latest version #7073 (comment)

┆Issue is synchronized with this Jira Improvement by Unito

[AbhiPrasad]

There is no way to make this work in the browser today, are they comfortable with introducing https://www.npmjs.com/package/zone.js as a dependency? Angular themselves are dropping Zone, so it may also not be developed for longer.

Also I don't understand how this makes performance monitoring better - which micro-frontend do you associate with the span that represents the duration of loading JavaScript resource? What about CLS (layout shift) - which micro-frontend should you associate that metric to?

By splitting up telemetry data this way you end up diluting the usefulness of the product IMO.

[realkosty]

Also I don't understand how this makes performance monitoring better - which micro-frontend do you associate with the span that represents the duration of loading JavaScript resource? What about CLS (layout shift) - which micro-frontend should you associate that metric to?

@AbhiPrasad resources, and application-wide metrics like CLS stay in the host transaction of course

By splitting up telemetry data this way you end up diluting the usefulness of the product IMO.

no splitting, but meaningful end to end duration-like metric for each MFE and a span subtree for each MFE

@nanoburd mentioned this may be solved by some new performance model (span-only?) we have in the works

[AbhiPrasad]

Unfortunately we're blocked not just by spans only model but by core browser APIs to enforce parent-child behaviour.

We also have the issue that splitting up spans this way will make associating to profiles and replays much harder (and more confusing), plus distributed tracing will get more complicated as each subtree theoretically gets its own trace to remain truly isolated.

Splitting up a span tree based on microfrontends feels like an artificial boundary, like only looking at a flamegraph based on what modules your team owns. It puts barriers to solving your performance problems and I'd rather avoid introducing that pattern if possible.

At the end of the day automatic instrumentation cannot guarantee attaching it's spans to the correct parent in the browser, and we're a while away till AsyncContext gets accepted and implemented in the browsers. Any current solution for this is going to incur a ton of bundle size cost, increase performance overhead, and still have edge cases where isolation will not work.

[realkosty]

Thank you for the explanation @AbhiPrasad . Looks like I seriously underestimated the complexity of this. Sounds like doing this would be:

1. not possible to implement (as of today) without significantly increasing bundle size
2. even if possible, it comes with major question about its presentation clarity and usefulness in the product. My sense is that you're saying that spans from different MFEs do affect each other - they don't truly happen in isolation, and building a UI that pretends that they are separate only does a disservice to our users.

This said, I still feel like we could do something simpler to improve performance experience for MFE use case.
I understand this is far out, but for the purpose of brainstorming:
Maybe once we have searchable spans, users could set tags on them (event spec already supports that and we use it internally AFAIK). And then they'd be able to filter by module tag in the /performance/summary/spans/ (currently filters only by span's transaction's fields, not span's own)? Or even have a feature to either filter or visually highlight spans with a given tag (from search box) in waterfall graph and aggregate spans. We could then capture "synthetic exceptions" for spans so that spans can be automatically associated with an MFE module using moduleMetadata similar to errors based on the file they originate from? Or is that crazy talk?

[AbhiPrasad]

even if possible, it comes with major question about its presentation clarity and usefulness in the product. My sense is that you're saying that spans from different MFEs do affect each other - they don't truly happen in isolation, and building a UI that pretends that they are separate only does a disservice to our users.

Yes, because at the end of the day, its all JS running on a single process on the main thread - everything has consequences on everything else.

We could then capture "synthetic exceptions" for spans so that spans can be automatically associated with an MFE module using moduleMetadata similar to errors based on the file they originate from

This might be possible, we have some ongoing discussions to do this for queries getsentry/team-sdks#40, but we need to take care of overhead concerns. Generating and parsing error stacktraces is expensive, especially on a per span basis.

We can't easily attach this info to browser/resource spans though because they are generated by the browser, not from user code, and certain async tasks like fetch requests may not even get the correct line of code.

[AbhiPrasad]

I'm going to close this because this is a use case we don't support in the browser SDK atm.

Once support for https://github.com/tc39/proposal-async-context is released across the browsers, we can attempt to fix this again!