Introduction
Modern applications don't fail all at once. They fail gradually.
A payment gateway starts responding slowly. Database latency increases. Inventory checks take longer than expected. Customers begin to experience delays, but traditional monitoring often notices only after users have already been affected.
This challenge inspired me to build PulseGuard, a Java-based observability demo that uses SigNoz and OpenTelemetry to monitor the health of a simulated e-commerce checkout system in real time.
Instead of treating observability as something that only helps developers after an outage, PulseGuard demonstrates how dashboards, traces, metrics, and alerts can help identify problems as they emerge and provide a clear picture of system behavior.
Why I Built PulseGuard
Many monitoring examples focus on CPU, memory, or infrastructure metrics. While these are important, they don't always explain what users are actually experiencing.
I wanted to build a project that answers practical questions such as:
*Is checkout becoming slower?
*Is payment processing failing?
*Are inventory checks causing delays?
*Which request is responsible for increased latency?
*How quickly can an incident be detected?
By combining application telemetry with SigNoz dashboards, PulseGuard turns raw signals into information that is easier to understand and investigate.
Project Architecture
The application simulates a checkout workflow using several Spring Boot services.
Customer Request
│
▼
Checkout Controller
│
▼
Checkout Service
├──────────────┐
▼ ▼
Payment Inventory
Service Service
│
▼
Database Service
│
▼
OpenTelemetry Java Agent
│
▼
OTLP Export
│
▼
SigNoz
├── Traces
├── Metrics
├── Service Overview
├── Dashboards
└── Alerts
Each request automatically generates distributed traces and metrics that are collected by SigNoz.
Technology Stack
The project is intentionally built using widely adopted open-source technologies.
*Java 21
*Spring Boot
*Maven
*OpenTelemetry Java Agent
*SigNoz
*Docker
*WSL
*REST APIs
This stack allows the project to be run locally without requiring cloud infrastructure.
Setting Up SigNoz
The first step was running SigNoz locally using Docker.
Once the containers were healthy, I connected the Java application using the OpenTelemetry Java Agent.
Launching the application required only a few environment variables:
*OTEL_SERVICE_NAME
*OTEL_EXPORTER_OTLP_ENDPOINT
*OTEL_EXPORTER_OTLP_PROTOCOL
After startup, SigNoz automatically detected the pulseguard service.
Seeing the service appear in the dashboard was the first confirmation that telemetry was flowing successfully.
What PulseGuard Monitors
PulseGuard focuses on the complete checkout journey.
Each checkout request generates telemetry that can be explored inside SigNoz.
Important observations include:
*Request latency
*Throughput
*Error percentage
*Request traces
*Endpoint performance
*Overall service health
Rather than relying on log messages alone, every request can be traced through the application.
Understanding Requests with Distributed Tracing
One of my favorite features in SigNoz is distributed tracing.
Instead of seeing only that a request failed, tracing shows:
*Where the request started,
*How long each operation required,
*Which component introduced latency,
*And the complete execution timeline.
This makes debugging significantly easier because the request path is visualized instead of inferred.
Service Overview
After generating traffic, SigNoz automatically populated several useful metrics.
The service overview displayed:
*Latency
*Request Rate
*Apdex
*Error Percentage
*Key Operations
Watching these values update in real time helped verify that telemetry collection was functioning correctly.
Simulating Incidents
PulseGuard also includes endpoints that simulate operational scenarios.
For example:
*checkout requests
*recovery actions
*degraded payment behavior
These simulated events create realistic telemetry that can be inspected using traces and dashboards.
Rather than creating artificial charts, the project generates signals through actual application behavior.
Why SigNoz Stood Out
Several aspects of SigNoz made the experience particularly enjoyable.
Unified Observability
Instead of switching between separate monitoring tools, SigNoz provides:
*metrics,
*traces,
*dashboards,
*logs,
*alerting
within a single interface.
Fast Local Development
Running everything locally with Docker made experimentation easy.
I could modify the application, restart it, generate traffic, and immediately observe the changes.
This shortened the feedback loop considerably.
Excellent OpenTelemetry Support
The OpenTelemetry Java Agent required very little configuration.
Once attached to the application, instrumentation happened automatically, allowing me to focus on understanding the data rather than writing extensive instrumentation code.
Challenges I Encountered
The project wasn't completely straightforward.
Some of the issues I encountered included:
- configuring Docker correctly,
- resolving port conflicts,
- connecting the Java application to the OTLP collector,
- ensuring telemetry reached SigNoz,
- and verifying that the application was properly instrumented.
Each issue provided a better understanding of how observability systems work under the hood.
Lessons Learned
Building PulseGuard taught me that observability is much more than collecting metrics.
Effective observability connects technical information with application behavior.
A latency graph becomes much more useful when it can immediately be connected to the exact request, operation, and execution path responsible for the slowdown.
This combination of metrics, traces, and dashboards enables faster troubleshooting and more informed operational decisions.
Future Improvements
There are several directions I would like to explore next:
- custom business metrics,
- advanced dashboards,
- alert policies,
- anomaly detection,
- AI-assisted incident summaries,
- multi-service architecture,
- Kubernetes deployment,
- and automated recovery workflows.
These additions would make PulseGuard even more representative of production observability systems.
Final Thoughts
PulseGuard started as an experiment to better understand observability, but it quickly became an opportunity to learn how distributed tracing, metrics, and dashboards work together.
Using SigNoz made it possible to move from simply generating telemetry to actually understanding application behavior.
For developers who want to learn modern observability with open-source tools, building a small application and instrumenting it with OpenTelemetry and SigNoz is an excellent hands-on exercise. It demonstrates how meaningful insights can emerge from well-structured telemetry and how observability helps bridge the gap between code and system behavior.
Thank you to the SigNoz team for organizing this hackathon and for making powerful observability tools accessible to the community.
Project: PulseGuard
Built with: Java, Spring Boot, OpenTelemetry, SigNoz, Docker, and Maven etc.
Top comments (0)