SigNoz

SigNoz is an open-source observability platform that consolidates application performance monitoring, distributed tracing, log management, metrics dashboards, alerting, and LLM observability into a single unified interface. Built natively on OpenTelemetry, it eliminates the fragmented approach of stitching together Prometheus, Jaeger, Loki, and Grafana by providing correlated telemetry data that lets you jump from a trace to related logs to infrastructure metrics without leaving the tool.

Powered by ClickHouse — the same columnar database used by Uber and Cloudflare — SigNoz delivers fast aggregation queries across billions of log entries and trace spans. The query layer supports a no-code visual builder, PromQL for existing Prometheus workflows, and raw ClickHouse SQL for power users, giving teams full flexibility without lock-in to a proprietary query language.

SigNoz instruments applications through standard OpenTelemetry SDKs across 10+ languages including Go, Python, Java, Node.js, PHP, .NET, Ruby, Elixir, Rust, and Swift. This means your instrumentation code is vendor-neutral and reusable regardless of which backend you switch to in the future. Self-hosted deployments run on Docker Compose for smaller teams or Kubernetes via Helm for production clusters.

The platform ships with LLM observability as a first-class feature, enabling AI engineering teams to track token consumption, monitor prompt latency, measure cost per request, and diagnose production failures in LLM-powered applications. This positions SigNoz ahead of traditional APM tools that have bolted on AI monitoring as an afterthought.

What You Get

• Unified APM with p99 Latency & Apdex - Monitor application performance with out-of-the-box charts for p99/p95 latency, error rate, Apdex scores, and requests per second, with automatic service dependency mapping.
• ClickHouse-Powered Log Management - Ingest, search, and run aggregations on massive log volumes using ClickHouse’s columnar storage, with a visual query builder and instant full-text search across all fields.
• Distributed Tracing with Flamegraphs - Track user requests end-to-end across microservices with Flamegraph and Gantt chart visualizations; click any span to see correlated logs and metrics at that exact timestamp.
• Metrics Dashboards with Formula Queries - Build custom dashboards from infrastructure or application metrics using a drag-and-drop query builder, PromQL, or raw ClickHouse SQL, with formulae for complex derived metrics.
• LLM & AI Application Observability - Monitor LLM calls end-to-end: track token usage, prompt latency, cost per request, and model error rates to optimize AI applications running in production.
• Threshold & Anomaly-Detection Alerts - Create alerts on any telemetry signal — logs, metrics, or traces — with threshold rules or anomaly-detection models, and route notifications to Slack, email, PagerDuty, or webhooks.
• Exceptions Monitoring with Stack Traces - Automatically capture and group exceptions in Python, Java, Ruby, and JavaScript, displaying full stack traces with custom attributes to identify impacted users or deployments.
• OpenTelemetry-Native Ingestion Pipeline - Accept telemetry data from any OTel-compatible source via the SigNoz-maintained OTel Collector fork, with support for semantic conventions, span events, and Opamp-based remote config.

Common Use Cases

• Replacing Datadog or New Relic - A fast-growing startup self-hosts SigNoz on their existing Kubernetes cluster to eliminate a $50k/year Datadog bill while retaining correlated traces, logs, and dashboards.
• Debugging microservice latency regressions - A platform team uses distributed tracing Flamegraphs to pinpoint the exact downstream service causing p99 spikes, then jumps to correlated logs at that span to find the root cause.
• Monitoring LLM application reliability - An AI product team instruments their OpenAI and Anthropic API calls with OTel to track token costs, response times, and error rates across different model versions in production.
• Centralizing polyglot service observability - A fintech company running Java microservices, a Python data pipeline, and a Go API gateway instruments all three with OpenTelemetry SDKs to get unified visibility in one place.
• Kubernetes infrastructure monitoring - A DevOps team ingests node-level CPU, memory, and pod metrics from their K8s cluster, then correlates infrastructure anomalies with application trace errors to diagnose OOM kills.
• Proactive alerting on business metrics - A SaaS team sets up anomaly-detection alerts on checkout funnel error rates derived from trace data, catching regressions before customers report them.

Under The Hood

Architecture

SigNoz is organized as a modular monorepo where the Go backend separates application entry points, reusable library packages, and enterprise extensions into distinct layers enforced by package boundaries. The factory.Registry and factory.ProviderSettings pattern provides consistent dependency injection across more than 50 packages, enabling the community and enterprise editions to swap implementations without conditional logic scattered through business code. Data flows from OpenTelemetry Collector through a telemetry store abstraction into ClickHouse, then through versioned statement builders (currently v5) into a caching-aware querier, and finally out through the Gin API server to the React frontend. The enterprise overlay in the ee/ directory extends core interfaces with licensing, anomaly detection, and advanced authentication — cleanly separated so the community build compiles and ships without any enterprise stubs.

Tech Stack

The backend is written in Go 1.25 using Gin for HTTP routing, ClickHouse Go client v2 for telemetry storage, and a forked SigNoz OpenTelemetry Collector for data ingestion. Prometheus integration enables PromQL support alongside the custom query builder. Redis provides a bucket cache with temporal alignment for time-series queries. The frontend is React 18 with TypeScript, built by Vite, and uses TanStack Table and TanStack Virtual for high-performance data grids, Monaco Editor and CodeMirror for query inputs, and Ant Design tokens for the design system. Authentication supports JWT, OIDC via go-oidc, and SSO with SAML in the enterprise tier. Deployment targets Docker Compose (with ClickHouse and ZooKeeper) or Kubernetes via Helm charts.

Code Quality

The backend has extensive test coverage with dedicated test files across the telemetry statement builders, bucket cache, querier, PromQL parser, and SQL schema migration system. The frontend ships with comprehensive Jest tests covering hooks, utility functions, and data transformation pipelines. A custom typed error package with error codes ensures consistent error propagation throughout Go services rather than raw string errors. TypeScript is configured in strict mode with ESLint custom rules enforcing state governance and import hygiene, plus Knip for dead code detection. The golangci-lint pipeline with custom linting rules enforces structured logging and error-handling standards across all Go packages. Some legacy code remains in the older query-service directory, but the new packages reflect mature engineering discipline.

What Makes It Unique

SigNoz’s most distinctive technical decision is building a fully OpenTelemetry-native stack rather than translating proprietary instrumentation into OTel — your spans, logs, and metrics arrive in native OTel format and are stored without translation, preserving semantic convention metadata that enables cross-signal correlation. The versioned query builder API (v5) abstracts trace, log, and metric aggregations behind a unified statement builder interface, enabling the same UI query builder to target fundamentally different ClickHouse table schemas. The bucket cache implements temporal alignment so cached time-series segments can be stitched together with live data without gaps or overlap artifacts. Adding LLM observability as a first-class pillar — not a plugin — reflects a deliberate product decision that separates SigNoz from traditional APM tools retrofitting AI monitoring as an afterthought.

Self-Hosting

SigNoz uses a split-license model: the core platform outside the ee/ and cmd/enterprise/ directories is released under the MIT license, which allows unlimited commercial use, modification, and redistribution with no copyleft obligations. The enterprise features inside ee/ are covered by a proprietary SigNoz Enterprise License that requires a paid subscription agreement from SigNoz Inc. before using those features in production. For the vast majority of self-hosting use cases — running the observability stack, ingesting telemetry, building dashboards, and configuring alerts — the MIT-licensed community edition is fully sufficient and carries no licensing restrictions.

Operationally, self-hosting SigNoz is a meaningful infrastructure commitment. A production deployment requires running ClickHouse (typically with ZooKeeper for replication), a SigNoz OTel Collector, the query service, and the frontend, all coordinated via Docker Compose or Helm. ClickHouse demands substantial disk I/O and memory for high-cardinality telemetry workloads; the SigNoz documentation recommends at least 8 CPU cores and 16 GB RAM for a moderate production load, with storage scaling proportional to retention period and ingestion volume. Your team is responsible for ClickHouse upgrades, backup strategy, schema migrations, and scaling ClickHouse shards as data grows. The active release cadence (weekly minor releases) means staying current requires a regular upgrade process.

Compared to SigNoz Cloud, self-hosting gives up managed upgrades, built-in high availability, automated backups, and infrastructure scaling. The cloud tier also bundles enterprise features — SSO/SAML authentication, anomaly-detection alerts, audit logs, and role-based access control — that require a paid Enterprise license when self-hosting. SigNoz offers a managed deployment model in your own infrastructure as well, bridging the gap for teams that want data residency without managing ClickHouse themselves. The Slack community and GitHub issues provide support for community users; enterprise SLAs and dedicated support channels require a paid plan.