Complete Solution for Sentry Error and Performance Monitoring in Qiankun Micro‑Frontend Architecture

This article extends a previous solution for handling Sentry error reporting in a Qiankun micro‑frontend setup by adding support for performance (transaction) data, ensuring that both error and performance metrics are sent to the appropriate sub‑application project.

The approach consists of three steps: (1) customize the Sentry transport to intercept outgoing requests; (2) analyze the payload to determine whether it is an error or a performance transaction and then rebuild the target url based on the correct project’s DSN; (3) resend the data using the newly constructed url .

Intercepting the Transport

For Sentry 6.x the transport is created by extending Transports.FetchTransport , while for 7.x a custom fetch transport is built with makeFetchTransport . Both versions inject a fetchImpl that calls sentryFilter to obtain the proper url and options before delegating to the native fetch .

// 6.x version
import { Transports, init } from '@sentry/browser';
import { Integrations } from '@sentry/tracing';

const fetchImpl = (url, options) => {
    const [newUrl, newOptions] = sentryFilter(url, options);
    return originFetch(newUrl, newOptions);
};

class CustomerTransport extends Transports.FetchTransport {
    constructor(options) {
        super(options, fetchImpl);
    }
}

init({
    dsn: 'xxxx',
    enabled: true,
    integrations: [new Integrations.BrowserTracing({idleTimeout: 2000})],
    tracesSampleRate: 1,
    transport: CustomerTransport,
    ... 
});

// 7.x version
import { init, makeFetchTransport } from '@sentry/browser';
import { Integrations } from '@sentry/tracing';

const CustomeTransport = (options) => {
    const fetchImpl = (url, options) => {
        const [newUrl, newOptions] = sentryFilter(url, options);
        return window.fetch(newUrl, newOptions);
    };
    return makeFetchTransport(options, fetchImpl);
};

init({
    dsn: 'xxxx',
    enabled: true,
    integrations: [new Integrations.BrowserTracing({idleTimeout: 2000})],
    tracesSampleRate: 1,
    transport: CustomerTransport,
    ... 
});

Rebuilding URLs

The DSN of each project is used to construct two URLs: one ending with store for error events and another ending with envelope for performance transactions. A PROJECT_CONFIG registry maps project identifiers to their specific errorUrl and performanceUrl as well as predicate functions for routing.

const PROJECT_CONFIG = {
  'project-1': {
    project: 'project-1',
    errorUrl: 'https://sentry.xxx.com/api/1/store/?sentry_key=a&sentry_version=7',
    errorCheck: (url) => url.includes('/project-1/'),
    performanceUrl: 'https://sentry.xxx.com/api/1/envelope/?sentry_key=a&sentry_version=7',
    performanceCheck: (url) => url.includes('/project-1/')
  },
  'project-2': {…},
  ... 
};

Data Distribution

For error events the stack trace is inspected to extract the filename of the failing module; this filename is matched against the errorCheck functions to locate the correct project. For performance data the current pathname is used with performanceCheck . Each filter returns either the rebuilt URL with additional options or the original request unchanged.

const sentryErrorFilter = (url, options) => {…};
const sentryProformanceFilter = (url, options) => {…};

Distinguishing Error vs. Transaction

Sentry marks performance data with type: "transaction" in the payload. The top‑level sentryFilter checks for this marker and delegates to the appropriate filter.

const sentryFilter = (url, options) => {
  const body = options.body || '';
  if (body.includes('"type":"transaction"')) {
    return sentryProformanceFilter(url, options);
  } else {
    return sentryErrorFilter(url, options);
  }
};

By integrating these pieces, developers can reliably route both Sentry error events and performance transactions to the correct micro‑frontend project within a Qiankun environment, simplifying monitoring and analysis across multiple sub‑applications.