DEV Community: KUNTAL GHOSH

PulseGuard: Real-Time Incident Observability with Java, OpenTelemetry & SigNoz

KUNTAL GHOSH — Sat, 25 Jul 2026 14:15:50 +0000

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.

First Time I Self-Hosted SigNoz and Found the Observability Feature I Didn’t Know I Needed

KUNTAL GHOSH — Sat, 18 Jul 2026 10:02:33 +0000

I started this project expecting to explore observability. I ended up discovering how much easier debugging becomes when traces, metrics, and logs are connected in one place.
Observability is one of those topics that can sound complicated when you first encounter it.
You hear terms like:
• Traces
• Metrics
• Logs
• Dashboards
• Alerts
• Open Telemetry
But the real understanding comes when you actually set up an observability platform and send real application data to it.
For this project, I decided to self-host SigNoz and use it as my observability backend.
After exploring its features, one feature stood out to me more than the others:

"Distributed Tracing".

And I quickly understood why.

Getting Started with SigNoz

The first step was to self-host SigNoz instead of simply using a managed observability service.
I wanted to understand what was actually happening behind the scenes.

Once data started appearing in the SigNoz interface, the project became much more interesting.

I was no longer just reading about observability.

I was actually looking at data generated by an application.

Exploring the Main Features

SigNoz brings several important observability features together in one platform.

METRICS
Metrics provide a high-level view of application performance.

For example, I could look at information such as:
• Request counts
• Response times
• Error rates
• Resource usage
• Performance trends
Metrics are useful when I want to understand the overall health of an application.
However, metrics alone do not always tell me exactly what caused a problem.
That is where traces became especially useful.

LOGS
Logs provide detailed information about what happened inside an application.

When something fails, logs can contain useful information such as:

"Request received"
"Database connection started"
"External API called"
"Request failed"

Logs are extremely useful for investigating specific events.

But when an application contains multiple services, reading logs alone can sometimes feel like trying to reconstruct a story from individual pages.

This is where tracing becomes powerful.

The Feature I Liked Most: Distributed Tracing

The feature that impressed me the most was the trace view.

A trace shows the complete journey of a request through an application.

Instead of seeing only:
"Request: 500 ms"

I can investigate what happened during those 500 milliseconds.

For example: ---

Total Request: 500 ms
│
├──> API Request: 500 ms
│ │
│ ├──> Authentication: 20 ms
│ │
│ ├──> Database Query: 80 ms
│ │
│ └──> External API Call: 400 ms

Now the problem becomes obvious.

The external API call is responsible for most of the delay.

Without tracing, I might only know that the application is slow.

With tracing, I can see where the time was actually spent.

That difference is incredibly important.

Why Traces Changed My Debugging Experience

Before exploring tracing, my mental model of debugging was something like this:

                    Something is slow
                            |
                     Check the logs
                            |
                     Check the code
                            |
                    Check the database
                            |
                   Check external services
                            |
                   Try to find the problem

With distributed tracing:

                       Something is slow
                                |
                         Open the trace
                                |
                    Find the slow operation
                                |
                 Investigate the exact component

The second approach is much more efficient.

The trace gives me a timeline of what happened during a request.

I can see:

• When the request started.
• Which operations were called.
• How long each operation took.
• Where errors occurred.
• Which part of the system created a bottleneck.

This makes debugging much less dependent on guessing.

A Small Experiment

To better understand how tracing works, I tested my application while introducing a delay in one operation.

The application became slower.

Instead of trying to guess the reason, I opened the trace in SigNoz.

The slow operation was immediately visible.

That was the moment when the value of distributed tracing became clear to me.

The most important lesson was:
"A slow application response is only a symptom. A trace helps identify the cause."

This is particularly useful for applications that communicate with multiple services, databases, or external APIs.

Traces, Metrics and Logs Together

The real strength of SigNoz is not just one feature.

It is the connection between different types of observability data.

A simplified debugging workflow can look like this:

                              Metric
                                |
                        Something is wrong
                                |
                              Trace
                                |
                   Find the slow or failing operation
                                |
                               Logs
                                |
                      Understand what happened
                                |
                         Dashboard / Alert
                                |
                   Monitor the problem continuously

Each type of data answers a different question.

METRICS
Is something wrong?

TRACES
Where is the problem happening?

LOGS
What exactly happened?

ALERTS
When should someone be notified?

Together, they create a much clearer picture of an application.

What I Learned from Self-Hosting SigNoz

The most valuable part of this experience was not simply clicking through the interface.

Self-hosting SigNoz helped me understand the complete flow:

                   Application
                        |
                  Telemetry Data
                        |
               Observability Backend
                        |
                   Visualization
                        |
                     Analysis

I also understood that observability is not just about collecting data.

The real value comes from being able to connect different pieces of information and use them to understand system behavior.

My Favorite Feature: A Final Verdict

After exploring traces, metrics, logs, dashboards, and alerts, my favorite feature is still Distributed Tracing.

The reason is simple:
"It changes debugging from guessing into investigation."

Instead of asking:
“Why is my application slow?”

I can ask:
“Which exact operation is causing the delay?”

That is a much better question.

For me, the trace view was the feature that made SigNoz feel different from simply looking at application logs or basic monitoring metrics.

Final Thoughts

Self-hosting SigNoz and connecting it to an application gave me a practical introduction to observability.

I started with the goal of exploring a monitoring platform.

I finished with a better understanding of how modern applications can be investigated when something goes wrong.

The feature I liked most was distributed tracing because it provides a visual timeline of a request and helps identify the exact source of delays and failures.

For anyone learning about observability, I think the best way to understand it is not just by reading about traces and metrics.

                         Set up a tool.
                               |
                       Send it real data.
                               |
                  Break something intentionally.
                               |
                Then try to find out why it broke.

     That is when observability really starts to make sense.

What is your favorite observability feature — traces, metrics, logs, dashboards, or alerts??*

== I would love to hear what other developers find most useful.