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.

DEV Community: KUNTAL GHOSH