[Feature] Ability to Identify Telemetry Items by Micro Frontend Source

[bhaskarmac]

Hi Team,

In micro frontend (MFE) architectures, several independently deployed MFEs can operate on a single host page. Currently, the @microsoft/applicationinsights-web SDK doesn’t offer a straightforward way to determine which telemetry item comes from which MFE when multiple MFEs use the same Application Insights instance.

Problem

1. Telemetry from all MFEs (such as page views, dependencies, custom events, exceptions) is grouped under the same “app,” making it hard to distinguish between sources.
2. This complicates filtering, analysis, and correlation of telemetry for each MFE in Azure Application Insights.
3. Currently, custom telemetry initializers must be added to each MFE to include properties like cloudRoleName or microFrontendName, which can lead to inconsistencies.

Proposal Add native SDK support for identifying telemetry items by their micro frontend source.

Potential solutions include:

1. Letting each MFE configure a cloudRoleName or componentName during SDK setup, applied to all telemetry from that instance.
2. Ensuring the microFrontendName is included in the telemetry envelope for filtering.
3. Allowing auto-collected telemetry (page views, dependencies, AJAX calls) to inherit the microFrontendName.

Benefits

• Easier separation of telemetry for each MFE.
• Simplifies debugging, filtering, and monitoring of MFEs.
• Reduces the need for custom telemetry initializers.

Example Use Case

• A large eCommerce site has MFEs for search, cart, checkout, and profile, all using App Insights SDK on the same page.
• Currently, all telemetry is grouped together.
• Ideally, telemetry from each MFE would be tagged with its name for better isolation of performance and errors.

Looking forward to your feedback on this request.

[hectorhdzg]

@bhaskarmac It is recommended to configure one telemetry instance per connection string for each Micro Frontend (MFE). If centralized data collection is preferred, the telemetry SDK can be instantiated in the shell or main application page and made globally accessible to all MFEs. This setup enables automatic tracking for general telemetry types such as pageView and pageViewPerformance, which do not require MFE-specific identification. For telemetry that is specific to individual MFEs, two approaches are suggested:

Preferred Approach: Disable automatic tracking for telemetry types like Exceptions and Dependencies within each MFE. Instead, manually invoke the appropriate tracking APIs (trackDependency, trackException) from the MFE code. This method provides full control over telemetry properties, allowing you to include identifiers such as roleName, MFE ID, or other relevant metadata.

Alternative Approach: Implement a telemetryInitializer that performs adaptive filtering and enrichment of telemetry data with MFE-specific properties. For this to function effectively, the telemetry must contain identifiable attributes—such as unique dependency URLs or exception stack traces—that can be used to classify the source MFE.

Due to the nature of MFE deployment—where each frontend is rendered as a unified HTML/JavaScript bundle and shares browser-level APIs like XHR/Fetch and exception handling—an out-of-the-box solution for automatic tracking is not feasible in this scenario.