SigNoz: OpenTelemetry-native APM with metrics, logs, and traces in one

What is SigNoz?

SigNoz is an OpenTelemetry-native all-in-one observability platform. Started in India in 2021, now in version 0.55+ (May 2026), an established player in OSS monitoring and arguably the most serious free alternative to Datadog. Licence: MIT – fully free, no clauses, no open-core limits.

The concept: metrics, logs, and traces in one UI, ingested via the OpenTelemetry protocol (OTLP). Instead of running three separate backends (Prometheus for metrics, Loki for logs, Tempo for traces), SigNoz collects everything in a ClickHouse database and offers a unified query surface. That cuts setup effort drastically – and cross-correlation (trace to log to metric) becomes trivial.

ClickHouse as backend: SigNoz uses ClickHouse, the column-oriented analytics database. That gives logs markedly better performance than Loki (full-text search fast), competitive TSDB performance for metrics, and high scalability for traces. Footprint: clearly bigger than Prometheus (at least 4 GB RAM, 30 GB disk for an SME setup), but one stack replaces three.

OpenTelemetry-first: all inputs go through the OpenTelemetry Collector. The OTLP protocol is an industry standard supported by OpenTelemetry SDKs in 11 languages (Java, Python, Node.js, Go, .NET, Ruby, etc.). Instrumenting applications with OTel makes you vendor-independent – the same code works with SigNoz, Datadog, Jaeger, Tempo, Honeycomb.

May 2026 status: after three years of broad adoption, SigNoz has established itself as a serious player. Commercial cloud variant (signoz.io) with EU region available. Self-host variant runs in production at mid-size SMEs and startups. Compared to Grafana-LGTM stack: SigNoz is more coherent (one UI, one backend) – the Grafana stack is more flexible (every component swappable). Both are serious options.

Why it matters

SigNoz closes a gap the Grafana stack leaves open: unified cross-correlation of metrics, logs, and traces without running 3 separate backends.

SME suitability (May 2026): anyone starting fresh in May 2026 and needing observability immediately has a real alternative to Grafana-LGTM. SigNoz setup via docker-compose is one stack, one frontend, one database. Learning curve is lower – one query syntax (PromQL-like) instead of three (PromQL plus LogQL plus TraceQL). For a 5-person team without dedicated DevOps, the more honest path.

CH DSG fit: self-host on Hetzner Falkenstein works fine. The cloud variant has an EU region (Frankfurt) – data processing agreement with SigNoz Inc. is possible. So fiduciary/law clients can also run compliantly without diving into self-host complexity.

OpenTelemetry strategy: anyone instrumenting new applications in 2026 should pick OTel – vendor-independent, broadly supported, clearly specified. SigNoz takes OTLP natively, without conversion. That makes the application future-proof: a later switch to Datadog or Tempo is possible without code change.

Cross-correlation in one UI: a concrete advantage in daily operations. An alert "API latency P95 over 2s" leads in SigNoz with one click to the logs of the affected service at the same time, then to the trace of a slow request, then to the DB query dominating that trace. The Grafana stack supports this too, but needs three datasources with cross-links – functionally equivalent, but with noticeably more friction.

APM features: SigNoz has classic APM features built in – service map, slowest endpoints, error rate per service, Apdex score. The Grafana stack needs custom dashboards for that. SigNoz delivers out of the box. For teams without deep observability know-how, a real time-saver.

How it works

SigNoz has three main components: the OpenTelemetry Collector (ingestion), ClickHouse (storage), and the query service plus frontend (UI). All run in one docker-compose bundle.

docker-compose.yml sketch (simplified – the official repo provides a complete bundle):

```yaml services: clickhouse: image: clickhouse/clickhouse-server:23.11 volumes: [clickhouse-data:/var/lib/clickhouse] otel-collector: image: signoz/signoz-otel-collector:0.88.0 command: ["--config=/etc/otel-collector-config.yaml"] ports: ["4317:4317", "4318:4318"] query-service: image: signoz/query-service:0.55.0 depends_on: [clickhouse] frontend: image: signoz/frontend:0.55.0 ports: ["3301:3301"] depends_on: [query-service] volumes: clickhouse-data: ```

After startup the UI is reachable at http://server:3301. Create admin account, done.

Data flow: (1) applications send telemetry via OTLP (HTTP or gRPC) to the OTel Collector. (2) The Collector preprocesses (sampling, filtering, enrichment) and writes to ClickHouse. (3) The query service reads from ClickHouse and answers UI requests.

Application instrumentation: typically via an OpenTelemetry SDK. Node.js example:

```javascript const { NodeSDK } = require("@opentelemetry/sdk-node"); const sdk = new NodeSDK({ resource: new Resource({"service.name": "my-api"}), traceExporter: new OTLPTraceExporter({url: "http://signoz:4318/v1/traces"}), }); sdk.start(); ```

After that, HTTP requests, database queries, and external API calls are ingested as traces automatically.

Logs: separately via FluentBit, Vector, or the OTel Collector as log receiver. Logs are linked to trace IDs, so one click in the trace jumps to the matching logs.

Metrics: Prometheus endpoints are scraped via OTel Collector and converted to OTLP. Custom metrics via the OpenTelemetry Metrics SDK. PromQL-like query language in the UI, with an additional builder surface.

Alerts: defined in the UI, based on thresholds or PromQL-like expressions. Receivers: Slack, PagerDuty, webhook, email, Telegram (via webhook bridge).

Setup in 5 steps

1. 01Clone the official SigNoz docker-compose bundle from github.com/SigNoz/signoz, adapt .env with cluster name and region.
2. 02Memory limits in compose: ClickHouse min 4 GB, OTel Collector 1 GB, frontend 256 MB. Reserve at least 6 GB RAM on an SME host.
3. 03docker compose up -d, open UI on port 3301, create admin account, save workspace config.
4. 04Instrument first application: install OpenTelemetry SDK for Node.js/Python/Go, point OTEL_EXPORTER_OTLP_ENDPOINT to SigNoz, verify trace export.
5. 05Configure alerts: threshold alerts on service latency P95, error rate > 5%, Apdex < 0.7 – receivers Telegram webhook or Slack.

When to use SigNoz

SigNoz is the right choice when (a) the setup has microservices or multiple interdependent applications, (b) traces matter (not only metrics), (c) OpenTelemetry is strategic, (d) a unified observability backend is preferred over three separate components.

Concrete cases: a SaaS platform with frontend, API, worker queue, external LLM connection – four services, every request crosses all of them. SigNoz shows the whole path in one trace, including latency per hop. A RAG system with embedding generation, Qdrant query, LLM call – where does the average request spend the most seconds? SigNoz shows it instantly. A fiduciary workflow with n8n, dunning generator, PDF engine, Brevo dispatch – cross-service tracing exposes silent failures.

Also a good pick for teams committing to OpenTelemetry-first. Anyone writing new microservices in 2026 with OTel as standard should evaluate SigNoz rather than Grafana-LGTM – the match is tighter, less conversion needed.

When not to use

SigNoz is the wrong choice when (a) the stack has only one container – overkill, Uptime Kuma is enough, (b) traces are not needed – Prometheus plus Grafana is leaner, (c) ClickHouse maintenance is seen as risk – the database needs a backup strategy and can use a lot of RAM with bad config, (d) the team already has a mature Grafana stack – migration is non-trivial.

Pitfalls: deploying SigNoz without a sampling strategy – at high trace volume the ClickHouse disk explodes. Recommended default: 10% head sampling for production. Running the OTel Collector without memory limits – can fill the host. Using SigNoz Cloud without checking EU region setup – default is US region.

Anti-patterns: running SigNoz and Grafana-LGTM in parallel – use cases overlap, that is confusion without value. Misusing ClickHouse as a general analytics DB – it is optimised for the SigNoz workload, not for general BI queries.

Trade-offs

FAQ

Related topics

Sources

1. SigNoz – Documentation · 2026-05
2. SigNoz – GitHub repository · 2026-04
3. OpenTelemetry – Specification and SDKs · 2026-05
4. SigNoz Cloud – Pricing tiers · 2026-05