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.