Open telemetry

Once we accept that the servability must be unified and correlated, the next question becomes obvious. How do we standardize this without forcing customers into a specific monitoring tool? At Adobe Commerce, we made a deliberate choice to adopt OpenTelemetry as our extensibility observability standard. All extensivity modules, eventing, webhooks, and UI SDK, together with the acceleration that we built, check out an integration starter kit, and of course a library that allows you to monitor as built on a builder, and meet now observability data following a single open standard. We choose OpenTelemetry for three main reasons. First, it’s an open industry-wide standard. This allows customers to continue using their existing observability stacks, whatever that’s Datadog, New Relic, Splunk, or any other inside the 62 existing observability packets supported by OpenTelemetry, while unifying all commerce extensivity signals in one place. Second, OpenTelemetry’s observability has a complete system, not an insulated data point. It supports the three signals types that are essential for a robust observability strategy.

Logs, which are foundational for troubleshooting and error analysis. Traces, which are critical for identifying performance degradation across distributed workflows. And metrics, which enable proactive monitoring, alerting, and trend analysis. Each signal answer a different question. Logs tell you what happened. Traces show you where and why it happened. And metrics help you to understand when something is starting to go wrong. And finally, OpenTelemetry provides built-in a standard for correlation across all that signals, allowing you to move seamlessly from a log to a trace, or from a metric, a normal to its raw Gauss analysis. By standardizing OpenTelemetry, we are not just exposing observability data. We are enabling end-to-end operational insights across the entire extensivity ecosystem.