Setup and Configuration

Transcript

Up to now, we have talked about why correlation matters and why standardization is critical. In this video, the focus is on how we actually deliver end-to-end observability in practice. Achieving through end-to-end VCV requires more than emitting logs in different places. It requires that every signal from commerce to a builder is emitted in a structured and correlated in a consistent way. This is why we built two complementary building blocks, the Commerce Observability module and the IO-lib telemetry library for App Builder. Together, they ensured that when something happens in commerce, a workbook is executed, an event delivery or an admin UI is interacted, and the execution continues inside App Builder app, all observability signals belong to the same logical flow. This is what turns isolated telemetry in a single continuous execution narrative, spanning platforms, extensivity, and integration. Let’s start with the Commerce Observability module. The module is designed to be configuration-first. As a user, you don’t need to think about where to add logs or how to propagate events. You simply configure which observability signals you want to emit and which observability backends should receive them. From the Adobe Commerce, commerce automatically emits all the required logs, metrics, and traces needed for monitoring extensivity interaction. That includes workbook executions, event subscription, and admin UI interaction. The key point is that commerce already knows the execution context, and it takes responsibility for emitting correlated standardized signals that can be consumed by your observability stack. Now, let’s move to the App Builder side. To extend that same execution context beyond commerce, we introduced IO-Lift telemetry, a library published on NPM. This library allows ESV and solution partners to build app stats, emit logs, metrics, and traces using the tags, and automatically inherit the correlation context coming from Adobe Commerce. That means an App Builder app doesn’t just emit telemetry. It emits telemetry that is natively connected to what happened before in commerce. When you investigate an issue, you can follow the flow from commerce spend to a workgroup, to an App Builder runtime action, and into external services all within the same correlated traces. The resource is a observability model where commerce and a builder are no longer separated worlds. They become part of a single end-to-end operational view.