Question
What is the OpenTelemetry Astronomy Shop, and why is an entire web shop used to demonstrate observability?
Answer
It is the OpenTelemetry project's official demo: a realistic microservice web shop for telescopes and star charts whose real purpose is to produce traces, metrics and logs worth analysing.
To a visitor it looks like an ordinary online shop: browse the catalogue, fill a cart, check out. The shop itself is beside the point. What matters is what happens behind the page, where more than a dozen services, written in different languages, cooperate to serve every click. That is exactly the kind of system observability exists for, and exactly the kind that is hard to build just for a classroom.
A toy "hello world" service would not show anything interesting. A single request in the Astronomy Shop crosses the frontend, the checkout, payment, shipping, currency and email services, so a trace of it has depth, a slow service has somewhere to hide, and a failure has something to cascade through. Every service is already instrumented with OpenTelemetry, and the demo ships with the backends to look at the data (Jaeger, Prometheus, Grafana, OpenSearch), so the whole pipeline from instrumented code to dashboard can be explored on one laptop with docker compose up.
In a local installation everything sits behind one port: the shop at http://localhost:8080, Grafana at /grafana/, the Jaeger UI at /jaeger/ui/, and Prometheus on port 9090.
Go deeper:
OpenTelemetry Demo documentation — the official overview, including screenshots of each backend.
open-telemetry/opentelemetry-demo on GitHub — the source; the README has the one-command Docker and Kubernetes setups.- Tracetest — Astronomy Shop Demo — installation walkthrough for running the shop locally.
Note saved — thanks!
Question
Which services make up the Astronomy Shop, and what does each of the central ones do?
Answer
Frontend, product catalog, cart and checkout carry the shopping flow; payment, shipping, currency, email and recommendation serve the checkout and the pages around it.
| Service | Job |
|---|---|
| Frontend | The user's entry point: renders the catalogue and cart, starts the checkout, talks to every backend service |
| Product Catalog | Owns the product list (telescopes, star charts, accessories) and hands product data to the frontend |
| Cart | Adds and removes products, changes quantities |
| Checkout | Orchestrates the order: calls payment, shipping, email and currency in turn |
| Payment | Simulates charging the customer, including success, extra latency and failures |
| Shipping | Calculates shipping cost and delivery information |
| Currency | Converts prices into the visitor's currency |
| Sends the order confirmation | |
| Recommendation | Suggests other products; generates extra service-to-service calls |
The services are deliberately written in many different languages (the frontend in TypeScript, checkout in Go, payment in JavaScript, shipping in Rust, currency in C++, recommendation in Python, among others). That is a feature: it shows that OpenTelemetry produces one consistent kind of telemetry no matter which language a service is written in, which is the whole point of a vendor- and language-neutral standard.
Go deeper:
- Microservices — Wikipedia — the architecture style the shop is built in, with its trade-offs.
Note saved — thanks!