Opentelemetry demo app with SigNoz integration
Learning SigNoz APM features by deploying a fully instrumented microservice application (OpenTelemetry demo app).
Context
In a previous setup, I focused on self-hosting SigNoz and enabling auto-instrumentation using the OpenTelemetry Operator.
While this works well for basic visibility, I quickly ran into practical limitations.
For example, when relying only on auto-instrumentation:
- Traces were often flat or poorly scaffolded
- Service relationships were not always clear
- Complex applications (like Nexus or Elasticsearch) introduced friction during setup
In short, I could see data, but I wasn’t really learning APM deeply.
To truly understand an APM platform, you need an application that is designed to be observed, not just auto-instrumented as an afterthought.
That led me to a simple question:
How do the creators of OpenTelemetry and SigNoz themselves test and showcase APM features?
Discovering the OpenTelemetry demo app
The answer already existed.
I stumbled upon the OpenTelemetry Demo Application, also known as Astronomy Shop:
- Repository: https://github.com/open-telemetry/opentelemetry-demo
And honestly — this thing is huge (in a good way).
It’s a realistic microservices-based system, built specifically to:
- Generate traces, metrics, and logs
- Exercise multiple languages and protocols
- Showcase observability patterns end-to-end
Even better, the project provides a well-documented Helm chart for Kubernetes deployments:
- https://github.com/open-telemetry/opentelemetry-helm-charts/tree/main/charts/opentelemetry-demo
SigNoz-specific adaptation
After digging further, I noticed that the SigNoz team already forked and adapted this demo:
- Mainly by adjusting
values.yamlso telemetry is sent to a SigNoz collector
That was the missing piece.
From there, I:
- Improved the configuration
- Removed unnecessary components
- Disabled heavy services
- Optimized the setup to run locally on limited resources
The final environment looks like this:
Multipass → k3s (master + worker) → SigNoz stack → OpenTelemetry Operator → Otel Demo AppAbout the demo stack
The OpenTelemetry demo app intentionally covers a wide technical surface:
- Multiple languages: Java, Go, Node.js
- Message streaming with Kafka
- gRPC-heavy service-to-service communication
- Background load generation
- Realistic failure and latency patterns
Core capabilities
- Kubernetes-native: runs locally or in cloud environments
- Docker support: can also be executed without Kubernetes
- gRPC-first communication between services
- Full OpenTelemetry instrumentation across all services
- Synthetic traffic generation using Locust
Originally, the demo also includes:
- Jaeger
- Prometheus
- Grafana
- OpenSearch
- A bundled OpenTelemetry Collector
But in our case, that’s unnecessary.
Bring your own collector (SigNoz)
Since we already have a self-managed SigNoz stack, we use it as the central telemetry backend.
This setup follows the official Bring Your Own Observability model recommended by the OpenTelemetry Helm charts.
That means:
- SigNoz acts as the collector and backend
- The demo app only emits telemetry
- No duplicate observability stack is deployed
Optimized local deployment
Helm repository setup
Custom values.yaml
This file does two important things:
- Redirects all telemetry to the SigNoz collector
- Disables unnecessary components to reduce resource usage
The goal here is learning APM behavior, not benchmarking cluster capacity. Reducing noise makes the signals much clearer.
Installation
Once deployed, the frontend is accessible via port-forwarding:
Running workloads
After deployment, the cluster runs a clean and focused set of pods:
Observability in SigNoz
This is where things get interesting.
Service discovery
SigNoz immediately detects all emitting services:
Real-time service map
You can visually explore live interactions between services:
APM deep dive
And finally, a full APM overview with latency, errors, and dependencies:
This setup gives you clean, correlated signals: metrics, traces, and logs — all tied back to Kubernetes workloads.
Conclusion
With this setup, we now have:
- A realistic, fully instrumented microservice system
- A clean SigNoz backend
- High-quality telemetry that actually teaches APM concepts
This becomes a foundation environment for learning SigNoz properly — not just installing it.
In upcoming documents, we’ll build on this by focusing on:
- Metrics and query syntax
- Custom dashboards for operations teams
- Alerting strategies
- Query languages and correlations