OpenTelemetry · Illustrative simulation From “it’s broken” to “here’s why”.
An alert tells you something is broken. A trace tells you why. Set up one slow checkout, press Start, and watch it played both ways.
This goes deeper than From signal to ticket, which shows how alarms become one ticket. Here the question is what happens after the ticket: how fast can the team find the real cause?
What the simulation shows
This piece needs scripts to run. In plain terms, it plays one slow checkout two ways:
- Without traces: an alert fires, then the team checks the services in the checkout path one by one until it reaches the slow one. The more services, and the later the slow one sits in the path, the longer it takes.
- With OpenTelemetry traces: the alert links to one trace that shows every step of the request, and the slow step stands out straight away. Finding the cause takes a few minutes, however many services there are.
Illustrative scenario. Times are examples to show the difference, not a benchmark.
The scenario: a slow checkout. An online store’s checkout gets slow. A request passes through several services, and one of them is the cause. You choose how many services there are, which one is slow and how long your team spends checking each service without traces. Then press Start and watch both lanes run, with no further clicks.
- MTTD: time to detect
- How long until someone or something notices the problem.
- MTTA: time to acknowledge
- How long until a person picks it up.
- MTTI: time to identify the cause
- How long until the team knows what actually went wrong. This is the clock the simulation above measures.
- MTTR: time to restore
- How long until customers are back to normal.
What changed
- One trace ID follows the request across every service.
- Spans show where the time went.
- Attributes show what changed: the version, the query, the retries.
- Logs and metrics link to the same trace.
Why OpenTelemetry
What it is. OpenTelemetry is an open-source, vendor-neutral standard for collecting traces, metrics and logs from your applications. It is a graduated project of the Cloud Native Computing Foundation. What is OpenTelemetry? (OpenTelemetry project, checked Oct 9, 2026)
Instrument once, send anywhere. Most major observability platforms now accept OpenTelemetry data, so you aren’t locked in to one tool. OpenTelemetry’s list of vendors that support it
What it takes.
- Auto-instrumentation for common languages, so you get traces without rewriting code.
- The OpenTelemetry Collector, to receive, process and route the data.
- Passing trace context through every hop, including the API gateway and message queues.
- Consistent naming (semantic conventions), so the same thing has the same name everywhere.
- Sampling, to control cost.
- Adding business attributes, such as cart size or order value, with care to keep personal data out.
The e-commerce angle. Checkout, cart, pricing, payment and third-party calls are exactly where a single trace pays off.
Check your own readiness
Six questions, about a minute. You get a scorecard with steps to fix each gap. Your answers stay in your browser unless you choose to send a project request.
The readiness check needs JavaScript.
Why data quality decides AIOps results: read the AIOps page →
Tie traces to releases: DevOps and observability.
See how alarms become one ticket → · Observability services →
Illustrative simulation. The store, the services, the timings and the minutes shown are invented to explain the idea and are not measured data or a benchmark.