Distributed Logging in Federated Applications, with Sentry

When it comes to distributed applications, Javascript logging gets tricky. What happens when you have multiple teams owning multiple parts of a single page or component? How can you use multiple DSNs in Sentry to send logs to the owning team, not the consuming team where the error occurred?

These are frustrating questions and up until now, I’ve seen no real examples to indicate a solution could work at scale. In this post, I attempt to answer these questions by sharing how to implement distributed logging across applications with Sentry and Webpack’s Module Federation and shed some light on how it could decrease rollback deployment to under 2 seconds.

Observability is key in distributed software leveraging Webpack’s Module Federation.

Setting the stage

I have 3 Next.js applications, they have Federated Routing (no page reloads between zones), the shop app exposes Header, BrokenComponent — then checkout, home apps consume and SSR these federated modules.

Header works, by design. But we built a knowingly broken component to see how one would handle an error thrown due to a bug in another apps exposed module.

In cases like this, the consuming team has little control out of the box, so If it starts erroring — typical sentry logging would just throw the errors to checkout,home because those are the host apps that consume these modules. Errors go to the wrong code owners, the team who owns it shop would never know about these errors without manually checking another team’s project, or through manually being told after the consuming team debugs it

It's pretty hard to offer at-runtime, distributed, modular architecture when there's uhhhhh…. no visibility or a good way to alert teams.

This presents a risk to business since observability and notifying the team who can resolve the problem wouldn’t happen by default with a global…