DEV Community

Divyansh Raj
Divyansh Raj

Posted on

Self-Hosting SigNoz on Windows: My WSL2 Observability Journey

I'm participating in the Agents of SigNoz hackathon by WeMakeDevs,
and before diving into the main build, I wanted to get hands-on
with SigNoz first. Here's what happened when I self-hosted it
on Windows using WSL2.

Getting WSL2 and Docker Right

The first challenge wasn't SigNoz itself, it was getting Docker
running correctly on Windows. I initially had Docker Desktop
installed, but SigNoz's docs specifically recommend running
Docker natively inside WSL2 instead, because ClickHouse Keeper
(one of SigNoz's components) can crash under Docker Desktop's
virtualization layer on Windows.

So I installed Ubuntu via wsl --install -d Ubuntu, then installed
Docker Engine natively inside that WSL distro using Docker's
official install script. A funny mistake I made along the way:
I accidentally ran commands inside docker-desktop's internal
hidden VM instead of my actual Ubuntu distro, which doesn't even
have curl installed. Once I figured that out and switched to
the right shell, things moved fast.

Installing SigNoz with Foundry

SigNoz recently moved to a new CLI tool called Foundry for
installation (the old docker-compose method is deprecated now).
It's a clean 3-step process:

  1. Install foundryctl
  2. Create a casting.yaml config file
  3. Run foundryctl cast -f casting.yaml

Within a couple of minutes, all 6 containers (ClickHouse,
PostgreSQL, the collector, and the SigNoz UI itself) were up
and healthy.

SigNoz Service Map showing dependencies between checkout, payment, shipping, and other services

My Favorite Feature: The Service Map

Out of everything, the Service Map was the most immediately
useful view. It's a live dependency graph, every service shows
up as a node, and the connections between them are drawn based
on actual traffic. Within seconds I could see how checkout
was the hub connecting payment, shipping, email, accounting,
and fraud-detection, all without reading a single line of code.

For anyone building AI agents, this matters a lot. Agents often
call multiple tools or chain multiple LLM calls, and without a
map like this, you're debugging blind. Seeing the shape of the
system at a glance is half the battle.

Zooming into a single request, like a checkout, the trace
flamegraph breaks it down span by span, showing exactly which
service ate up how much time:

Trace flamegraph showing a checkout request across 94 spans

What's Next

This was just the warm-up. For the actual hackathon build, I'm
instrumenting a WhatsApp-based clinic booking agent I've been
building, an AI receptionist that understands appointment requests,
checks availability, and books slots. With SigNoz wired in, every
step (the LLM call, the database lookup, the WhatsApp reply) will
be fully traceable. No more guessing why an agent got something wrong.

If you're building AI agents and shipping them without observability,
you're flying blind. This weekend convinced me that's not optional
anymore.

Top comments (0)