![[The AI Show Episode 146]: Rise of “AI-First” Companies, AI Job Disruption, GPT-4o Update Gets Rolled Back, How Big Consulting Firms Use AI, and Meta AI App](https://www.marketingaiinstitute.com/hubfs/ep%20146%20cover.png)
.jpg?width=1920&height=1920&fit=bounds&quality=70&format=jpg&auto=webp#)
_Alexey_Kotelnikov_Alamy.jpg?width=1280&auto=webp&quality=80&disable=upscale#)
_Brian_Jackson_Alamy.jpg?width=1280&auto=webp&quality=80&disable=upscale#)
 Stolen 884,000 Credit Card Details on 13 Million Clicks from Users Worldwide.webp?#)
![Roku clarifies how ‘Pause Ads’ work amid issues with some HDR content [U]](https://i0.wp.com/9to5google.com/wp-content/uploads/sites/4/2025/05/roku-pause-ad-1.jpg?resize=1200%2C628&quality=82&strip=all&ssl=1)
![Look at this Chrome Dino figure and its adorable tiny boombox [Gallery]](https://i0.wp.com/9to5google.com/wp-content/uploads/sites/4/2025/05/chrome-dino-youtube-boombox-1.jpg?resize=1200%2C628&quality=82&strip=all&ssl=1)
![Apple Seeds visionOS 2.5 RC to Developers [Download]](https://www.iclarified.com/images/news/97240/97240/97240-640.jpg)
![Apple Seeds tvOS 18.5 RC to Developers [Download]](https://www.iclarified.com/images/news/97243/97243/97243-640.jpg)
If you're working with OpenTelemetry (OTel) and Kubernetes, or looking to get started, having a practical environment to experiment in is invaluable. Setting up observability from scratch can be complex, so leveraging a ready-made, realistic example can significantly speed up the learning process. The official OpenTelemetry "Astronomy Shop" demo is designed precisely for this – it's much more than just a sample application. Think of it as a pre-instrumented, multi-service online store built specifically to help us explore how distributed systems tick (and sometimes break!). It lets you see firsthand how tools like OpenTelemetry can help track down performance bottlenecks or tricky errors in a microservices setup. In this post, I'll walk you through setting up this fantastic demo environment on your own Kubernetes cluster. We'll cover the deployment process and touch on how to connect it to an observability backend so you can actually see the telemetry data (logs, metrics, traces) in action. I'll even share a few practical tips I picked up along the way. By the end, you'll have a working setup perfect for experimenting with OTel and gaining practical insights into application performance. Ready to dive in? What is the Astronomy Shop Demo? So, what exactly is this Astronomy Shop? Imagine a mini e-commerce site selling cool space gear - telescopes, maybe some fancy star charts. But behind the scenes, it's a cleverly designed microservices application. What makes it special for us developers? It's Realistic: It uses different programming languages and communication methods (like gRPC and HTTP), just like many real-world applications. It’s complex enough to feel authentic. It's an Observability Sandbox: The best part? It comes pre-instrumented with OpenTelemetry right out of the box! This means it's already generating logs, metrics, and traces for you to capture and analyze. It's Made for Learning (and Breaking!): You can actually trigger simulated problems (like service errors or slowdowns) and then use observability tools to figure out what went wrong. It’s a safe space to practice troubleshooting distributed systems. [Image 1: The OpenTelemetry Astronomy Shop demo application frontend.] Why Use OpenTelemetry? So, why is OpenTelemetry (OTel) such a big deal in the observability world? At its core, OTel provides a standardized, vendor-neutral way to generate, collect, and export telemetry data – namely traces, metrics, and logs. Think of it as a common language for observability. This standardization is incredibly powerful because it means you're not locked into a specific monitoring vendor's tools or agents. You instrument your code once with OpenTelemetry, and then you can choose (and even switch!) where you want to send that data for analysis. But beyond vendor freedom, OTel is invaluable for several reasons: Understanding Distributed Systems: When you have multiple microservices talking to each other, OTel traces let you visualize the entire journey of a request across those services. This is crucial for understanding dependencies and pinpointing where things slow down. Troubleshooting Proactively: With comprehensive metrics and logs alongside traces, you get a much richer picture of your system's health. This allows you to spot potential issues or anomalies before they cause major outages. Flexibility and Integration: OTel is designed to integrate with a wide array of observability backends – open source tools like Jaeger or Prometheus, cloud provider services, and commercial platforms. This flexibility lets you pick the analysis and visualization tools that best fit your needs. Architecture & Components To understand how we can observe the Astronomy Shop, let's peek under the hood at its architecture. As mentioned, it mimics a real e-commerce site, so it's built as a collection of interconnected microservices. You'll find services for typical functions like: → Frontend UI → User Authentication → Product Catalog → Recommendations → Checkout & Payment → Shipping → ...and several others! [Image 2: The OpenTelemetry Demo's microservice architecture] What makes it particularly useful is that these services are written in different languages (Go, Java, Python, Node.js, etc.) and use different ways to communicate (like HTTP and gRPC), just like you'd find in many real-world companies. When we start looking at telemetry data later, we'll often focus on interactions between key services like the frontend, productcatalogservice, and recommendationservice to see how tracing and metrics help us understand their behavior. Introducing Controlled Bugs for Observability Okay, this is where the Astronomy Shop demo gets really interesting for learning. It doesn't just run smoothly; it's designed to let you intentionally introduce problems in controlled ways! Why? So you can practice using OpenTelemetry data (your traces, metrics,
If you're working with OpenTelemetry (OTel) and Kubernetes, or looking to get started, having a practical environment to experiment in is invaluable. Setting up observability from scratch can be complex, so leveraging a ready-made, realistic example can significantly speed up the learning process. The official OpenTelemetry "Astronomy Shop" demo is designed precisely for this – it's much more than just a sample application.
Think of it as a pre-instrumented, multi-service online store built specifically to help us explore how distributed systems tick (and sometimes break!). It lets you see firsthand how tools like OpenTelemetry can help track down performance bottlenecks or tricky errors in a microservices setup.
In this post, I'll walk you through setting up this fantastic demo environment on your own Kubernetes cluster. We'll cover the deployment process and touch on how to connect it to an observability backend so you can actually see the telemetry data (logs, metrics, traces) in action. I'll even share a few practical tips I picked up along the way.
By the end, you'll have a working setup perfect for experimenting with OTel and gaining practical insights into application performance. Ready to dive in?
What is the Astronomy Shop Demo?
So, what exactly is this Astronomy Shop? Imagine a mini e-commerce site selling cool space gear - telescopes, maybe some fancy star charts. But behind the scenes, it's a cleverly designed microservices application.
What makes it special for us developers?
- It's Realistic: It uses different programming languages and communication methods (like gRPC and HTTP), just like many real-world applications. It’s complex enough to feel authentic.
- It's an Observability Sandbox: The best part? It comes pre-instrumented with OpenTelemetry right out of the box! This means it's already generating logs, metrics, and traces for you to capture and analyze.
- It's Made for Learning (and Breaking!): You can actually trigger simulated problems (like service errors or slowdowns) and then use observability tools to figure out what went wrong. It’s a safe space to practice troubleshooting distributed systems.
[Image 1: The OpenTelemetry Astronomy Shop demo application frontend.]
Why Use OpenTelemetry?
So, why is OpenTelemetry (OTel) such a big deal in the observability world? At its core, OTel provides a standardized, vendor-neutral way to generate, collect, and export telemetry data – namely traces, metrics, and logs. Think of it as a common language for observability.
This standardization is incredibly powerful because it means you're not locked into a specific monitoring vendor's tools or agents. You instrument your code once with OpenTelemetry, and then you can choose (and even switch!) where you want to send that data for analysis.
But beyond vendor freedom, OTel is invaluable for several reasons:
- Understanding Distributed Systems: When you have multiple microservices talking to each other, OTel traces let you visualize the entire journey of a request across those services. This is crucial for understanding dependencies and pinpointing where things slow down.
- Troubleshooting Proactively: With comprehensive metrics and logs alongside traces, you get a much richer picture of your system's health. This allows you to spot potential issues or anomalies before they cause major outages.
- Flexibility and Integration: OTel is designed to integrate with a wide array of observability backends – open source tools like Jaeger or Prometheus, cloud provider services, and commercial platforms. This flexibility lets you pick the analysis and visualization tools that best fit your needs.
Architecture & Components
To understand how we can observe the Astronomy Shop, let's peek under the hood at its architecture. As mentioned, it mimics a real e-commerce site, so it's built as a collection of interconnected microservices.
You'll find services for typical functions like:
→ Frontend UI
→ User Authentication
→ Product Catalog
→ Recommendations
→ Checkout & Payment
→ Shipping
→ ...and several others!
[Image 2: The OpenTelemetry Demo's microservice architecture]
What makes it particularly useful is that these services are written in different languages (Go, Java, Python, Node.js, etc.) and use different ways to communicate (like HTTP and gRPC), just like you'd find in many real-world companies.
When we start looking at telemetry data later, we'll often focus on interactions between key services like the frontend, productcatalogservice, and recommendationservice to see how tracing and metrics help us understand their behavior.
Introducing Controlled Bugs for Observability
Okay, this is where the Astronomy Shop demo gets really interesting for learning. It doesn't just run smoothly; it's designed to let you intentionally introduce problems in controlled ways! Why? So you can practice using OpenTelemetry data (your traces, metrics, and logs) to figure out what's going wrong, just like you would during a real production incident, but without the real-world stress.
The demo includes built-in scenarios to simulate common headaches:
- Memory Leaks: Practice diagnosing memory consumption issues using metrics.
- Specific API Errors: See what happens when certain product lookups start failing.
- Random Service Failures: Observe the impact when critical services like ads or the shopping cart become unreliable.
How does it simulate these issues? The demo cleverly uses feature flags to turn these problems on and off. For instance, there's a flag named recommendationCache that can be used to disrupt the recommendation service. Toggling this flag can put the service into a "broken state" where it might start returning errors or become significantly slower, mimicking real-world failures like timeouts or bad deployments.
[Image 3: The demo includes a UI to manage feature flags for simulating issues.]
The beauty of this setup is that once you have your observability tools connected (which we'll get to!), you can flip one of these flags, watch the telemetry data light up – maybe error rates spike, latency metrics jump, traces show failed requests – and practice your diagnostic skills. It’s like a flight simulator for observability and troubleshooting!
Deploying the Demo on Kubernetes
In this section, we’ll walk you through deploying the demo to an existing Kubernetes cluster using Helm, then integrating it for observability.
Step 1: Installing Helm and Deploying the OpenTelemetry Demo
Alright, let's get the Astronomy Shop running on your Kubernetes cluster! We'll use Helm, which is the standard package manager for Kubernetes. If you haven't used it before or don't have it installed, the official Helm installation guide is the best place to start .
Once you have Helm ready, the first step is to add the official OpenTelemetry Helm repository. Open your terminal and run:
helm repo add open-telemetry https://open-telemetry.github.io/opentelemetry-helm-charts
helm repo update # Ensures you have the latest chart list
Now, you can install the demo chart onto your cluster. This command usually installs the latest version of the chart:
# Replace with your Helm release name
helm install open-telemetry/opentelemetry-demo
