How to Install SigNoz on Ubuntu 24.04 — Self-Hosted APM & Observability

Production applications fail in ways that logs alone cannot explain. A slow checkout page, a database query that spikes every 30 minutes, a memory leak that only appears under traffic — these problems need distributed tracing, metrics, and logs in one place. SigNoz is an open-source application performance monitoring (APM) platform that gives you all three, built on the open standards of OpenTelemetry and the column-store speed of ClickHouse. This guide walks you through installing SigNoz on an Ubuntu 24.04 VPS, instrumenting real applications, wiring up alerts, and exposing the UI over TLS.

Need a ready-made VPS? The CloudCore Professional plan at EUR 19.99/month is sized perfectly for a self-hosted SigNoz deployment ingesting spans and metrics from a small fleet of services.

Table of Contents

What is SigNoz?

SigNoz is an open-source observability platform that unifies application performance monitoring, distributed tracing, metrics, and log management into a single product. Rather than bolting three separate tools together, SigNoz treats all signal types as first-class citizens and stores them in a shared ClickHouse database, which means you can pivot from a slow trace to the metric that caused it to the log line that exploded — without leaving the UI.

The architecture is deliberately open. SigNoz is built on OpenTelemetry, the vendor-neutral observability standard maintained by the Cloud Native Computing Foundation. Every SDK, every receiver, every exporter you use is portable; if you ever decide to leave SigNoz, your instrumentation keeps working with any other OTel-compatible backend. The storage engine is ClickHouse, the same columnar database that powers Cloudflare, Uber, and Yandex analytics at petabyte scale. For a self-hosted monitoring stack this combination is hard to beat — low ingest cost, fast queries over billions of spans, and no proprietary agent lock-in.

Core features you get out of the box include distributed tracing with flamegraphs and service maps, application metrics (RED: Rate, Errors, Duration) computed automatically from spans, custom metrics dashboards with PromQL-compatible queries, centralized logs with full-text search, exception tracking with stack traces, alerting with Slack/PagerDuty/email integrations, and multi-tenant SSO for team deployments. Services written in Node.js, Python, Go, Java, .NET, Ruby, PHP, Rust, and more can all push data to the same SigNoz instance through the OpenTelemetry Collector.

Why Self-Host SigNoz vs. Datadog or New Relic?

SaaS observability platforms are powerful but expensive. The bill scales with every host, every container, every custom metric, every GB of logs, and every retention day. Below is a realistic comparison for a modest production workload: 10 hosts, 20 services, 50M spans per month, 100 GB of logs, and 30-day retention.

Self-hosting does add operational overhead (disk growth, ClickHouse tuning, upgrades), but on a single VPS the maintenance is small: a git pull and docker compose up -d every couple of months, plus a cron job that prunes old data by adjusting ClickHouse TTLs.

Prerequisites

Before you begin, make sure you have:

• A VPS running Ubuntu 24.04 LTS with root or sudo access
• SSH access to the server
• At least 4 vCPU and 8 GB RAM (the full SigNoz stack runs nine containers including ClickHouse, which is memory-hungry)
• At least 40 GB of free disk space — ClickHouse compresses spans efficiently, but traces add up quickly under production load
• A domain name pointing to the server's IP address (for the TLS reverse proxy step)

Recommended Plan: CloudCore Professional

The full SigNoz stack plus a ClickHouse store that can hold 30 days of traces for a small fleet fits comfortably in our Professional VPS tier:

- 6 vCPU cores

- 12 GB RAM

- 200 GB NVMe SSD

- Unmetered bandwidth

- EUR 19.99/month

This leaves enough headroom for ClickHouse to buffer writes without back-pressuring the OTel Collector during traffic spikes.

Connect to your server:

ssh root@your-server-ip

Step 1: Update System Packages

Start with an up-to-date system. Missing security patches and stale package lists are the number-one cause of Docker installation failures on fresh VPS images.

sudo apt update && sudo apt upgrade -y

If the kernel was updated, reboot:

sudo reboot

Reconnect after a minute and verify the release:

lsb_release -a

Expected output:

Distributor ID: Ubuntu
Description:    Ubuntu 24.04.1 LTS
Release:        24.04
Codename:       noble

Step 2: Install Docker and Docker Compose

SigNoz ships as a Docker Compose stack, so Docker Engine and the Compose plugin are the only runtime dependencies.

Install prerequisites and add Docker's official GPG key:

sudo apt install -y ca-certificates curl gnupg
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | \
  sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg

Add the Docker apt repository:

echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] \
  https://download.docker.com/linux/ubuntu noble stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

Install Docker Engine and the Compose plugin:

sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

Add your user to the docker group so you do not need sudo for every command:

sudo usermod -aG docker $USER
newgrp docker

Verify:

docker --version
docker compose version

Expected output:

Docker version 27.3.1, build ce12230
Docker Compose version v2.29.7

Step 3: Clone the SigNoz Repository

SigNoz distributes its self-hosted stack through the official GitHub repository. Clone it into /opt:

sudo mkdir -p /opt
cd /opt
sudo git clone -b main https://github.com/SigNoz/signoz.git
sudo chown -R $USER:$USER /opt/signoz
cd /opt/signoz/deploy/docker/clickhouse-setup

This directory contains everything the stack needs:

• docker-compose.yaml — the service graph (ClickHouse, Zookeeper, Query Service, Frontend, Alertmanager, OTel Collector, OTel Collector Metrics)
• otel-collector-config.yaml — the OTel Collector pipeline definition
• alertmanager.yml — alert routing rules
• data/ — persistent volume for ClickHouse data (created on first start)

ls -la

Expected output (abbreviated):

-rw-r--r--  docker-compose.yaml
-rw-r--r--  otel-collector-config.yaml
-rw-r--r--  otel-collector-opamp-config.yaml
-rw-r--r--  alertmanager.yml
drwxr-xr-x  clickhouse-config

Step 4: Launch the SigNoz Stack

Start every container in detached mode:

docker compose up -d

The first run pulls roughly 2 GB of images and takes three to five minutes. Expected tail of the output:

[+] Running 9/9
 ✔ Container signoz-zookeeper-1          Started
 ✔ Container signoz-clickhouse           Started
 ✔ Container signoz-alertmanager         Started
 ✔ Container signoz-query-service        Started
 ✔ Container signoz-otel-collector       Started
 ✔ Container signoz-otel-collector-metrics  Started
 ✔ Container signoz-frontend             Started
 ✔ Container signoz-logspout             Started
 ✔ Container signoz-init-clickhouse      Exited (0)

Confirm every container is healthy:

docker compose ps

You should see all containers in running state except init-clickhouse, which runs once to create the schema and exits cleanly.

Check the Query Service logs to make sure it connected to ClickHouse:

docker compose logs query-service --tail 20

You want to see lines like successfully connected to clickhouse and listener started on :8080.

Step 5: Access the SigNoz UI

The frontend is published on port 3301. From your workstation, open:

http://your-server-ip:3301

On the first visit SigNoz will prompt you to create the admin account — name, organization, email, and password. This account is stored in the local SQLite database inside the query service; there is no phoning home.

Once signed in you land on the Services overview page. It will be empty until you point an application at the collector, which we will do next.

The OTel Collector listens on three ports that your applications will use:

• 4317 — OTLP gRPC (preferred for server-to-server)
• 4318 — OTLP HTTP (preferred from browsers or environments that forbid gRPC)
• 8888 — the collector's own Prometheus metrics

sudo ss -tlnp | grep -E '4317|4318|3301'

Step 6: Configure the OpenTelemetry Collector

The OpenTelemetry Collector is the ingest brain of SigNoz. Receivers accept data, processors transform it, and exporters push it to ClickHouse. SigNoz ships a sensible default, but you will want to tune it for your workload.

Open the configuration:

nano /opt/signoz/deploy/docker/clickhouse-setup/otel-collector-config.yaml

A minimal production-ready pipeline looks like this:

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318
  hostmetrics:
    collection_interval: 30s
    scrapers:
      cpu: {}
      memory: {}
      disk: {}
      filesystem: {}
      network: {}
      load: {}
processors:
  batch:
    send_batch_size: 10000
    timeout: 10s
  memory_limiter:
    check_interval: 1s
    limit_mib: 1500
    spike_limit_mib: 512
  resourcedetection:
    detectors: [env, system, docker]
    timeout: 2s
exporters:
  clickhousetraces:
    datasource: tcp://clickhouse:9000/?database=signoz_traces
  clickhousemetricswrite:
    endpoint: tcp://clickhouse:9000/?database=signoz_metrics
  clickhouselogsexporter:
    dsn: tcp://clickhouse:9000/
service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [memory_limiter, batch, resourcedetection]
      exporters: [clickhousetraces]
    metrics:
      receivers: [otlp, hostmetrics]
      processors: [memory_limiter, batch, resourcedetection]
      exporters: [clickhousemetricswrite]
    logs:
      receivers: [otlp]
      processors: [memory_limiter, batch]
      exporters: [clickhouselogsexporter]

Key choices to understand:

• memory_limiter protects the collector from OOM kills under traffic spikes by dropping data before it runs out of heap. Always put it first in every pipeline.
• batch groups spans/metrics/logs before writing. Bigger batches mean fewer ClickHouse writes and much lower CPU.
• resourcedetection auto-populates host.name, os.type, container.id and similar attributes so you do not have to set them in every SDK.
• hostmetrics turns the collector into a node exporter — CPU, disk, network metrics flow into SigNoz without running Prometheus separately.

cd /opt/signoz/deploy/docker/clickhouse-setup
docker compose restart otel-collector

Tail the logs to confirm it started cleanly:

docker compose logs -f otel-collector

Look for Everything is ready. Begin running and processing data.

For more pipeline patterns, the official OTel Collector docs cover sampling, tail-based sampling, Kafka buffering, and secure mTLS between collector tiers.

Step 7: Instrument a Node.js Application

Instrumenting a service is where SigNoz starts to pay off. OpenTelemetry provides drop-in auto-instrumentation for Express, Fastify, NestJS, HTTP, gRPC, PostgreSQL, MySQL, Redis, MongoDB, and dozens of other libraries.

Install the SDK in your Node.js project:

npm install --save @opentelemetry/api \
  @opentelemetry/sdk-node \
  @opentelemetry/auto-instrumentations-node \
  @opentelemetry/exporter-trace-otlp-grpc

Create tracing.js at the project root:

'use strict';
const { NodeSDK } = require('@opentelemetry/sdk-node');
const { OTLPTraceExporter } = require('@opentelemetry/exporter-trace-otlp-grpc');
const { getNodeAutoInstrumentations } = require('@opentelemetry/auto-instrumentations-node');
const { Resource } = require('@opentelemetry/resources');
const { SemanticResourceAttributes } = require('@opentelemetry/semantic-conventions');
const sdk = new NodeSDK({
  resource: new Resource({
    [SemanticResourceAttributes.SERVICE_NAME]: 'checkout-api',
    [SemanticResourceAttributes.DEPLOYMENT_ENVIRONMENT]: 'production',
  }),
  traceExporter: new OTLPTraceExporter({
    url: 'http://your-signoz-host:4317',
  }),
  instrumentations: [getNodeAutoInstrumentations()],
});
sdk.start();

Start the app with the tracer loaded first:

node --require ./tracing.js server.js

Within 30 seconds checkout-api will appear on the SigNoz Services page with live latency, request rate, and error-rate graphs.

Step 8: Instrument a Python Application

For a Django, Flask, or FastAPI project, the zero-code auto-instrumentation is equally easy.

pip install opentelemetry-distro opentelemetry-exporter-otlp
opentelemetry-bootstrap --action=install

Run the app with the OTel launcher:

OTEL_RESOURCE_ATTRIBUTES="service.name=payments-api,deployment.environment=production" \
OTEL_EXPORTER_OTLP_ENDPOINT="http://your-signoz-host:4317" \
OTEL_EXPORTER_OTLP_PROTOCOL="grpc" \
opentelemetry-instrument python manage.py runserver

No code changes required — the launcher patches Django, requests, psycopg2, redis-py, and more at import time. Manual spans are straightforward when you need them:

from opentelemetry import trace
tracer = trace.get_tracer(__name__)
with tracer.start_as_current_span("charge_customer") as span:
    span.set_attribute("customer.id", customer_id)
    span.set_attribute("amount.cents", amount_cents)
    result = stripe_client.charges.create(...)

Step 9: Instrument a Go Application

Go has no runtime monkey-patching, so instrumentation is explicit but still minimal thanks to otelhttp and friends.

go get go.opentelemetry.io/otel \
  go.opentelemetry.io/otel/sdk \
  go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracegrpc \
  go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp

Minimal bootstrap:

func initTracer(ctx context.Context) (*sdktrace.TracerProvider, error) {
    exp, err := otlptracegrpc.New(ctx,
        otlptracegrpc.WithEndpoint("your-signoz-host:4317"),
        otlptracegrpc.WithInsecure(),
    )
    if err != nil { return nil, err }
    tp := sdktrace.NewTracerProvider(
        sdktrace.WithBatcher(exp),
        sdktrace.WithResource(resource.NewWithAttributes(
            semconv.SchemaURL,
            semconv.ServiceName("orders-api"),
            semconv.DeploymentEnvironment("production"),
        )),
    )
    otel.SetTracerProvider(tp)
    return tp, nil
}

Wrap your HTTP handlers with otelhttp.NewHandler(mux, "http-server") and every request becomes a traced span with method, route, status, and duration attributes.

Step 10: Explore Traces, Metrics and Logs

With a few services reporting, the SigNoz UI comes alive.

The Services tab shows each instrumented service with RED metrics (Rate, Errors, Duration) at P50/P95/P99. Click a service to see its endpoint breakdown and a live service map showing upstream/downstream dependencies.

The Traces tab lets you query every span with filters like service.name, http.status_code, duration > 500ms, and free-form attribute filters. Click any trace to open the flamegraph and walk the call stack across services — the span from your React app, through the BFF, into the payments service, out to Stripe, and back.

The Metrics tab speaks a PromQL-compatible query language. A self-hosted SigNoz instance can replace Prometheus for most use cases; if you have existing Prometheus exporters, point them at the collector's prometheus receiver and their scrapes land in the same UI.

The Logs tab surfaces structured logs with sub-second full-text search over billions of rows thanks to ClickHouse. If you are replacing Loki or ELK, the migration is usually just swapping your log shipper's destination — Fluent Bit, Vector, and Logstash all speak OTLP.

Teams that already rely on Grafana can keep it: SigNoz exposes a ClickHouse datasource that Grafana dashboards can query directly, so you do not have to rebuild panels.

Step 11: Exception Tracking

Every unhandled exception that crosses an instrumented span automatically appears under Exceptions. Stack traces, breadcrumbs, and the full trace context are captured — the same workflow you would pay USD 29/month per developer for in Sentry, except the data lives on your VPS and retention is bounded only by disk.

Explicit exception recording inside a span is a one-liner in any SDK. Node.js example:

try {
  await processPayment(order);
} catch (err) {
  const span = trace.getActiveSpan();
  span.recordException(err);
  span.setStatus({ code: SpanStatusCode.ERROR, message: err.message });
  throw err;
}

The Exceptions tab groups by fingerprint so a flood of the same error collapses into one row with a trend graph, last-seen timestamp, and affected service list.

Step 12: Create Alerts

Alerts turn passive telemetry into active pager duty. From the SigNoz sidebar choose Alerts → New Alert.

SigNoz supports three alert types:

• Metric-based — a PromQL query crosses a threshold (e.g. P95 latency > 800ms for 5 minutes)
• Trace-based — error-rate or volume conditions on a span filter
• Log-based — a log query matches more than N times in a window

Each alert routes through Alertmanager. Configure a Slack webhook or PagerDuty integration:

nano /opt/signoz/deploy/docker/clickhouse-setup/alertmanager.yml

Add a receiver:

receivers:
  - name: slack-prod
    slack_configs:
      - api_url: https://hooks.slack.com/services/XXX/YYY/ZZZ
        channel: '#alerts-prod'
        send_resolved: true

Restart Alertmanager:

docker compose restart alertmanager

Step 13: Build Custom Dashboards

The out-of-the-box service dashboards cover 80% of use cases, but you will want business-specific panels — checkout conversion rate, orders per minute, queue depth.

Navigate to Dashboards → New Dashboard. Each panel is a ClickHouse or PromQL query with a chart type (time series, value, bar, pie, table, or gauge). Variables are supported so you can build a single dashboard that filters by service, environment, or region.

Dashboards are JSON documents that you can export and commit to your infra repository — keep them in git next to your Terraform or Ansible code for full reproducibility.

For ClickHouse performance, prefer the aggregated metrics tables (time_series_v4_1day, time_series_v4_6hrs) over raw spans when a panel covers long windows. SigNoz creates these materialized views automatically.

Step 14: Nginx Reverse Proxy with TLS

Exposing the SigNoz UI over plain HTTP on port 3301 is fine for a homelab but unacceptable for anything with customer data. Put Nginx and a Let's Encrypt certificate in front.

Install Nginx and Certbot:

sudo apt install -y nginx certbot python3-certbot-nginx

Point signoz.yourdomain.com at your VPS in your DNS provider, then create the site:

sudo tee /etc/nginx/sites-available/signoz > /dev/null <<'EOF'
server {
    listen 80;
    server_name signoz.yourdomain.com;
    return 301 https://$host$request_uri;
}
server {
    listen 443 ssl http2;
    server_name signoz.yourdomain.com;
    # Certificates added by Certbot
    client_max_body_size 50m;
    proxy_read_timeout 300s;
    proxy_send_timeout 300s;
    # Frontend UI
    location / {
        proxy_pass http://127.0.0.1:3301;
        proxy_http_version 1.1;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}
EOF
sudo ln -s /etc/nginx/sites-available/signoz /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx

Obtain the certificate:

sudo certbot --nginx -d signoz.yourdomain.com

Certbot will auto-renew via the systemd timer it installs. Firewall the raw ports so nobody can bypass Nginx:

sudo ufw allow OpenSSH
sudo ufw allow 'Nginx Full'
sudo ufw deny 3301
sudo ufw deny 4317
sudo ufw deny 4318
sudo ufw enable

If your applications are on other servers and need to send telemetry over the internet, expose 4317 through Nginx as well with TLS and a bearer-token auth_request, or put the entire traffic through a private WireGuard mesh.

Troubleshooting

docker compose logs -f

FAQ

How much disk does SigNoz use per million spans?

With the default ClickHouse schema and ZSTD compression, SigNoz stores roughly 60-90 MB per million spans including all indexes and materialized views. Metrics are even more compact — about 5 MB per million samples. A 200 GB NVMe disk comfortably holds 30 days of traces for a 50-service deployment generating 5M spans/day. When you need more headroom, adjust ClickHouse TTLs to drop raw spans after 7 days while keeping aggregated metrics for 90.

Do I need to run a separate OpenTelemetry Collector per service?

No. The SigNoz stack includes a central collector that is designed to accept traffic from every service in your fleet. For very large deployments (hundreds of services or multi-region) a common pattern is a two-tier collector setup: a lightweight "agent" collector running as a sidecar or per host that forwards to the central SigNoz collector. This gives you local buffering and per-host resource detection without overloading the central pipeline.

Can SigNoz replace Prometheus, Grafana, Jaeger, and Sentry all at once?

For most teams, yes. SigNoz covers Prometheus (metrics with PromQL), Jaeger (distributed traces), Loki/ELK (logs), and Sentry (exception tracking) in a single UI. The main feature that is not 1:1 yet is Grafana's extensive plugin ecosystem — if you need specific Grafana panels (Google Sheets, Redshift, obscure datasources), keep Grafana alongside and let it query SigNoz's ClickHouse as a datasource.

How does ingest performance scale on a single VPS?

On a 6 vCPU / 12 GB VPS, a healthy SigNoz stack comfortably handles around 20,000-30,000 spans per second with 50 ms ingest latency, plus roughly 50,000 metric data points per second and 10,000 log lines per second. Scaling beyond that is usually a matter of either moving ClickHouse to a dedicated node (the stack supports external ClickHouse via an env var) or horizontally sharding the OTel Collector. For context: 20k spans/s is enough to cover a production fleet handling 100M requests/day.

Is SigNoz safe to expose directly to the public internet?

The frontend has authentication, but like any admin UI it should be behind TLS plus ideally IP allow-listing or a VPN. The OTLP receivers on ports 4317/4318 have no authentication in the default config — never expose them directly. The right pattern for remote ingestion is TLS + bearer-token auth through Nginx, or a private network (WireGuard, Tailscale, or your cloud VPC peering). See the Nginx step above for a secure baseline.

How do I upgrade SigNoz without losing data?

All persistent state lives in named Docker volumes (ClickHouse and SQLite for the query service). A safe upgrade is:

cd /opt/signoz
git pull origin main
cd deploy/docker/clickhouse-setup
docker compose pull
docker compose up -d

ClickHouse schema migrations are handled automatically by the init-clickhouse container on startup. Take a ClickHouse volume backup before major version jumps just in case.

Can I use SigNoz Cloud instead of self-hosting?

Yes — SigNoz offers a managed SaaS version with the same feature set. It is a reasonable fit for teams that have no DevOps bandwidth. But once you are paying for it, the math starts to look similar to Datadog; the main value of SigNoz is the open-source, self-hosted model where the only marginal cost is VPS disk and CPU. For a team of 5-20 developers on a single VPS, self-hosting is usually 5-10x cheaper than any SaaS APM.

Next Steps

Now that SigNoz is capturing telemetry from your services, push further:

• Roll out OTel SDKs across every service — uniform instrumentation is what unlocks the real value of distributed tracing. Put service.name and deployment.environment in every bootstrap script.
• Define SLOs in SigNoz — codify your latency and error-rate targets as alerts, and track burn rate so incidents are caught before customers notice.
• Route logs through the collector — switch Fluent Bit or Vector to OTLP output and retire your separate logging stack.
• Adopt tail-based sampling — at high span volume, sample intelligently by keeping 100% of errors and slow traces while dropping a fraction of healthy requests. The OTel Collector has a tail_sampling processor for this.
• Review the SigNoz documentation for advanced topics like SSO integration, multi-tenancy, retention tuning, and high-availability ClickHouse clustering.

Ready to run a production observability stack?

The CloudCore Professional VPS at EUR 19.99/month is the sweet spot for a self-hosted SigNoz deployment: enough RAM for ClickHouse, enough NVMe for a month of traces, and enough CPU headroom to handle a small fleet's ingest without breaking a sweat.

- 6 vCPU / 12 GB RAM / 200 GB NVMe

- Unmetered bandwidth for OTLP ingest

- Daily snapshots of your ClickHouse volume

- EU and North America datacenters for data residency

Deploy Your Monitoring VPS and replace your Datadog bill this afternoon.