I self-hosted SigNoz and fell in love with distributed tracing

Every developer knows the feeling: the app is slow, or something is throwing errors, and you have no idea which part is at fault. Is it the payment service? The database? A slow call to another service three hops away? So you sprinkle print statements everywhere and start guessing.

I wanted a single tool that could show me what's actually happening inside my services — the requests, the timing, the errors — without paying for an expensive SaaS. So I self-hosted SigNoz, an open-source observability platform, sent it real traffic, and clicked around for an afternoon.

By the end of this post you'll know how to run SigNoz yourself, and you'll see the one feature that genuinely won me over: distributed tracing.

Getting it running with Foundry

SigNoz has an installer called Foundry that sets up the whole stack in one shot. Installing it is a single line:

curl -fsSL https://signoz.io/foundry.sh | bash

That gave me the foundryctl CLI. Then I wrote a tiny config file, casting.yaml, describing what I wanted:

apiVersion: v1alpha1
kind: Installation
metadata:
  name: signoz
spec:
  deployment:
    flavor: compose      # run it with Docker Compose
    mode: docker
  mcp:
    spec:
      enabled: true      # also install the MCP server

And deployed it:

foundryctl cast -f casting.yaml

Foundry generated the Docker Compose files, pulled the images, and started everything — about eight containers working together: the SigNoz app and UI, an OpenTelemetry collector to receive data, a ClickHouse database to store it, Postgres for metadata, and an MCP server. It also wrote a casting.yaml.lock so the exact setup is reproducible.

A minute later, the UI was live at http://localhost:8080. I created my admin account on first launch and I was in.

💻 The full casting.yaml, lockfile, and setup are on GitHub: Mrakshaymehta/-agents-of-signoz

![The SigNoz welcome screen after first login]

The SigNoz welcome screen — traces and metrics ingestion showing "active," with an onboarding checklist to guide you.

Giving it some real data

An observability tool is useless with nothing to observe, so I used SigNoz's own OpenTelemetry Demo Lite — a simulated online store made of 14 microservices (frontend, cart, checkout, payment, shipping, recommendation, and more) that continuously generate realistic traffic.

Pointing it at my local SigNoz was just two environment variables so its collector shipped data to my machine:

OTLP_ENDPOINT=host.docker.internal:4317   # my local SigNoz ingestion port
OTLP_INSECURE=true                        # plain gRPC for local / self-hosted

Then docker compose up -d. Within a minute, data was pouring in — hundreds of thousands of spans, logs, and metric samples, all speaking the vendor-neutral OpenTelemetry standard, so I'm not locked into any single tool.

The first thing SigNoz showed me was a health list of every service:

![The APM services list with P99 latency, error rate and throughput]

All 14 services at a glance: P99 latency, error rate, and operations per second. Sort by error rate and the trouble spots jump right out — here payment is sitting at ~6% errors.

This view alone is handy — sort by latency or errors and you instantly know where to look. But the feature that made me sit up was one level deeper.

The part I loved: distributed tracing

Here's the idea. When a customer clicks "Place Order," that single action doesn't hit one service — it ripples across many: the frontend calls checkout, checkout charges payment, arranges shipping, sends a confirmation email, and so on. A trace is the complete story of that one request as it travels through all of them.

The OpenTelemetry docs define a trace simply as "the path of a request through your application." Each individual step in that path — one service doing one unit of work — is called a span. A trace is just a tree of spans.

SigNoz draws this beautifully. I opened a single checkout request and got this:

![A distributed trace shown as a flame graph and waterfall]

One "Place Order" request rendered as a flame graph (top) and a waterfall (bottom): 94 spans across several services, start to finish in 37 milliseconds.

Look at what this one screen tells you:

• The request began at the browser-frontend, went into checkout, which fanned out to payment (the charge), shipping (the quote), and even email (sendOrderConfirmation).
• Every bar is one span, and its width is how long that step took — so you can literally see where the time goes. No guessing.

Clicking any span opens its details, with the real request data attached as OpenTelemetry attributes:

![Span details panel showing OpenTelemetry attributes]

Drilling into the PlaceOrder span: the actual order (worth $446.42), the item count, shipping details, the HTTP method, and the span's timing — all standard OpenTelemetry fields.

And the detail that sealed it for me: from a single span I could jump straight to that span's logs (see the Overview / Events / Logs / Metrics tabs). This is the holy grail of debugging — you spot a slow or failing step in the trace, click, and you're reading the exact log lines for that specific request, not a firehose of everything.

That's the difference between "the app is slow" and "the charge call to the payment service on this order took X ms, and here's its log." One is a shrug; the other is a fix.

A few other things I liked

• It's all OpenTelemetry. SigNoz doesn't use a proprietary agent — it ingests the open OTLP standard. If I ever switch tools, my instrumentation comes with me.
• The service health list (that latency / error-rate / throughput table) is a genuinely useful "morning coffee" dashboard.
• An MCP server ships with it. I connected it to my AI coding assistant so an agent can query this telemetry directly — a neat glimpse of where observability and AI are heading.

Takeaways

Self-hosting SigNoz was genuinely fast — a one-line installer, a tiny config file, and I had a full observability stack running on my laptop with real data flowing through it. If you're a developer who wants real visibility into your services without a SaaS bill, it's well worth an afternoon.

But the trace view is the thing I'll remember. Watching a single click travel across a dozen services, and being able to click into any step and read its logs, turns debugging from guesswork into detective work. That's the feature I'd tell a teammate to try first.

---

AI assistance: I used Claude Code to help run the setup on my machine. Every command and configuration shown here was actually executed and verified and all screenshots are from my own SigNoz instance.

Links: SigNoz · Foundry docs · OpenTelemetry Demo Lite · Full config & repo (GitHub)