SigNoz

Open-source APM and observability platform

Developer Tools & Git ★ 32.2k stars Medium setup MIT

SigNoz is an open-source application performance monitoring and observability platform built on OpenTelemetry. It unifies metrics, traces, and logs in a single self-hosted tool.

Key features

  • OpenTelemetry native
  • Unified metrics, traces, logs
  • Application performance monitoring
  • Custom dashboards and alerts

Pros & cons

Strengths

  • Metrics traces logs unified
  • OpenTelemetry native
  • Flexible query dashboards

Trade-offs

  • ClickHouse dependency heavy
  • Resource-hungry stack

SigNoz replaces

Last reviewed Aug 26, 2026 · 793 words

The decision you are really making with SigNoz is not "SigNoz or Datadog". It is "one integrated observability app on ClickHouse, or four Grafana-family services stitched together". SigNoz gives you traces, metrics and logs in a single UI with a single query layer, installed from one compose file, at the cost of a 4 GB RAM floor and a ClickHouse instance you now own. The Grafana route gives you Grafana, Prometheus, Loki and Tempo, each lighter alone, each configured separately, and correlated only as well as you wire them. For a team of 2 to 20 engineers who want application traces without becoming a platform team, SigNoz is the faster path. For a homelab that only wants host metrics, it is 3 GB of RAM too many.

OpenTelemetry-native is the feature, not a buzzword

Every other tool in this space bolts OpenTelemetry on. SigNoz was built in 2021 assuming it, which shows in practical ways: the bundled OpenTelemetry Collector is the only ingestion path, so anything that can emit OTLP works with no SigNoz-specific agent. Your app sends to port 4317 (gRPC) or 4318 (HTTP), and the UI is on port 3301. Instrumenting a Python or Node service is the standard OpenTelemetry SDK plus two environment variables:

OTEL_EXPORTER_OTLP_ENDPOINT=http://signoz-host:4318
OTEL_SERVICE_NAME=checkout-api

Because there is no proprietary agent, switching away later costs nothing; the same instrumentation would feed Tempo, Jaeger or a paid vendor. That is a real reason to prefer it over the Datadog agent even before price enters the discussion. The Datadog alternatives page covers the wider field.

ClickHouse is where the 4 GB goes

The catalogue's "resource-hungry stack" warning is about ClickHouse, the columnar database SigNoz stores everything in. ClickHouse is spectacular at the queries observability needs (scan 50 million spans, group by service, p99 by minute) and it earns that speed with memory. On a 4 GB box, the default compose runs but leaves nothing for the workloads you are observing, so put SigNoz on its own VM or a dedicated 8 GB slice. Disk grows with ingestion; a modest 5-service setup writing 100 spans a second will fill about 1 GB a day before compression settles, and ClickHouse compresses well, so budget 30 GB and watch the first month.

Retention is set in the UI per signal (traces, metrics, logs) and defaults to 15 days for traces and logs. Set it before you forget; ClickHouse does not fill the disk gracefully.

Against the Grafana stack, honestly

SigNozGrafana + Prometheus + Loki + Tempo
Services to run4 (UI, query, collector, ClickHouse)4 to 5, each separately configured
Trace-to-log correlationBuilt in, click throughWorks, needs derived fields config
Metrics query languagePromQL and ClickHouse SQLPromQL, LogQL, TraceQL
Host and container metricsVia OTel collector receiversPrometheus exporters, larger ecosystem
Dashboards communitySmallEnormous
RAM floor4 GB1 to 2 GB for metrics only, 4 GB with all four

The Grafana stack wins on the size of its ecosystem and on partial adoption: you can run Prometheus alone for a year and add Loki later. SigNoz wins the moment you actually want traces, because the integrated experience is the product and the Grafana equivalent is four products that behave like four products. The Grafana vs Prometheus comparison on this site explains that split if the names are still blurring together.

The work is instrumentation, not installation

Installing SigNoz is a git clone and docker compose up from the deploy/docker directory; 20 minutes. The months are spent getting your services to emit useful spans: naming them, adding attributes, propagating context across queues and HTTP calls. SigNoz cannot fix a service that emits one span per request with no attributes. Auto-instrumentation gets Python, Java and Node about 70% of the way; the last 30% is a developer adding span.set_attribute("order.id", ...) in the right places. If your team will not do that, you will get a pretty dashboard with shallow data, and Prometheus plus Uptime Kuma would have served you the same.

What I'd do

For a small product team running 3 or more services in production, I'd run SigNoz on a dedicated 8 GB VM, set trace retention to 7 days and metrics to 30, instrument one service end-to-end before touching the others, and give it a quarter before judging. For a homelab, I would not run it; the homelab monitoring guide covers the lighter stack that fits in 512 MB. SigNoz is the best self-hosted answer to "I want what Datadog does" that exists in 2026, and it is only worth its RAM when that is the actual question.

Compare SigNoz

1 head-to-head comparisons.

Similar developer tools & git apps