SigNoz Deployment on VPS:

SigNoz and Application Configuration

After successfully installing SigNoz, you need to configure access to it and start sending data from your applications. We will also ensure a secure connection to the SigNoz UI via HTTPS.

1. Initial Access to SigNoz UI

By default, the SigNoz UI is available at http://YOUR_IP_ADDRESS:3301. Open it in your browser. Upon first login, you will be prompted to create an administrator account. Set a username and a strong password.

2. Configure HTTPS using Caddy

Using HTTP to access the monitoring dashboard is highly undesirable. We will configure Caddy — an easy-to-use web server with automatic issuance and renewal of Let's Encrypt TLS certificates — to provide HTTPS access.

Preliminary steps:

1. Ensure your domain (e.g., signoz.yourdomain.com) points to your VPS's IP address.
2. Ensure ports 80 (HTTP) and 443 (HTTPS) are open in your UFW (we already opened them in the "Server Preparation" section).

Caddy Installation:

sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-stable.list
sudo apt update
sudo apt install caddy -y # Install Caddy

Caddyfile Configuration:

Create or edit the file /etc/caddy/Caddyfile. Replace signoz.yourdomain.com with your actual domain.

# /etc/caddy/Caddyfile
signoz.yourdomain.com {
    # Automatic issuance and renewal of TLS certificates
    tls {
        # Use your email for Let's Encrypt notifications
        email [email protected]
    }

    # Proxy all requests to SigNoz Frontend
    reverse_proxy localhost:3301 {
        # Add necessary headers for correct operation
        header_up Host {host}
        header_up X-Real-IP {remote_ip}
        header_up X-Forwarded-For {remote_ip}
        header_up X-Forwarded-Proto {scheme}
    }

    # Enable compression (optional, but recommended)
    encode gzip zstd

    # Access logging (optional)
    log {
        output file /var/log/caddy/access.log
        format json
    }
}

Create a directory for Caddy logs:

sudo mkdir -p /var/log/caddy
sudo chown caddy:caddy /var/log/caddy

Restart Caddy:

sudo caddy validate -adapter caddyfile --config /etc/caddy/Caddyfile # Check configuration
sudo systemctl reload caddy # Reload Caddy to apply changes
sudo systemctl enable caddy # Ensure Caddy starts on system boot

Now you can access SigNoz at https://signoz.yourdomain.com.

3. Sending Data to SigNoz using OpenTelemetry

SigNoz actively uses OpenTelemetry (OTel) — an open standard for telemetry collection. To send logs, metrics, and traces from your applications, you will need to integrate the OTel SDK into your code or use the OTel Collector.

Example for Node.js application (basic tracing):

Install the necessary OpenTelemetry packages:

npm install @opentelemetry/sdk-node @opentelemetry/api @opentelemetry/auto-instrumentations-node @opentelemetry/exporter-otlp-proto-http @opentelemetry/sdk-trace-node

Create the file tracing.js:

// tracing.js
const opentelemetry = require('@opentelemetry/sdk-node');
const { getNodeAutoInstrumentations } = require('@opentelemetry/auto-instrumentations-node');
const { OTLPTraceExporter } = require('@opentelemetry/exporter-otlp-proto-http');

const traceExporter = new OTLPTraceExporter({
    url: 'http://localhost:4318/v1/traces', // SigNoz OpenTelemetry Collector address
});

const sdk = new opentelemetry.NodeSDK({
  serviceName: 'my-node-app',
  traceExporter,
  instrumentations: [getNodeAutoInstrumentations()],
});

sdk.start()
  .then(() => console.log('Tracing initialized'))
  .catch((error) => console.error('Error initializing tracing', error));

process.on('SIGTERM', () => {
  sdk.shutdown()
    .then(() => console.log('Tracing terminated'))
    .catch((error) => console.error('Error terminating tracing', error))
    .finally(() => process.exit(0));
});

Run your Node.js application with this file:

node -r ./tracing.js your-app.js

For other programming languages and for sending metrics/logs, the process is similar: use the corresponding OTel SDKs and exporters. The OpenTelemetry Collector in SigNoz by default listens on ports 4317 (gRPC) and 4318 (HTTP) for traces, as well as 4317/4318 for metrics and 4317 for logs. When sending data from your application, specify the address localhost:4318 or localhost:4317, as the OTel Collector runs in the same Docker Compose stack as the SigNoz application itself.

To collect logs from the host or from other containers, you can configure a separate OpenTelemetry Collector or use a Docker log driver that sends logs to SigNoz.

4. Verifying Functionality

After configuring applications and sending data, access the SigNoz UI (https://signoz.yourdomain.com). Navigate to the "Traces", "Metrics", or "Logs" section. You should see incoming data. If there is no data, check:

• SigNoz container logs: docker compose -f ~/signoz/signoz/deploy/docker-compose.yaml logs
• Caddy logs: sudo journalctl -u caddy.service
• Correct OTel SDK configuration in your application.
• Port availability between your application and the SigNoz OTel Collector.

Backups and Maintenance

Backup and regular maintenance are critically important aspects for any production system, especially for a monitoring system that stores valuable data. Loss of telemetry data can lead to the inability to analyze incidents and regressions.

What to Back Up

For SigNoz, the following components need to be backed up:

1. ClickHouse Data: This is the primary storage for all logs, metrics, and traces. It is the largest and most important component.
2. SigNoz Configuration Files: docker-compose.yaml, .env files, any custom OpenTelemetry Collector configurations, or other parameters you might have changed.
3. Caddy Configuration: The /etc/caddy/Caddyfile file and the directory with TLS certificates (usually /var/lib/caddy).

Simple Auto-Backup Script

We will create a simple script that will archive the main configuration files and perform a "hot" backup of ClickHouse data. For storing ClickHouse data, docker exec commands can be used.

Create the file ~/signoz/backup_signoz.sh:

#!/bin/bash

# --- Backup Configuration ---
BACKUP_DIR="/var/backups/signoz_$(date +%Y%m%d%H%M%S)"
SIGNOZ_DEPLOY_PATH="/root/signoz/signoz/deploy" # Path to your SigNoz deploy/ directory
CLICKHOUSE_CONTAINER="signoz-clickhouse" # ClickHouse container name, can be found via docker ps
CLICKHOUSE_DATABASE="signoz" # ClickHouse database name
RETENTION_DAYS=7 # How many days to keep backups

# --- Create backup directory ---
echo "Creating backup directory: $BACKUP_DIR"
sudo mkdir -p "$BACKUP_DIR"
if [ $? -ne 0 ]; then
    echo "Error: Failed to create backup directory. Check permissions."
    exit 1
fi

# --- Backup configuration files ---
echo "Backing up configuration files..."
sudo cp -r "$SIGNOZ_DEPLOY_PATH" "$BACKUP_DIR/signoz_config"
sudo cp /etc/caddy/Caddyfile "$BACKUP_DIR/Caddyfile"
sudo cp -r /var/lib/caddy "$BACKUP_DIR/caddy_data" # Backup Caddy certificates

# --- Backup ClickHouse data ---
echo "Backing up ClickHouse data..."
# ClickHouse supports "hot" backup using the ATTACH TABLE FROM DISK command
# This method copies data from active partitions, which can be resource-intensive
# A more reliable way is to use the clickhouse-backup tool
# For this example, we will dump the schema and important tables
# For a full ClickHouse backup, it is better to use specialized tools:
# https://clickhouse.com/docs/en/operations/backup

# Example: dump database schema
sudo docker exec "$CLICKHOUSE_CONTAINER" clickhouse-client --query="SHOW CREATE DATABASE $CLICKHOUSE_DATABASE" > "$BACKUP_DIR/clickhouse_schema.sql"

# Example: dump data from small but important tables (e.g., metadata)
# This is inefficient for large tables.
# sudo docker exec "$CLICKHOUSE_CONTAINER" clickhouse-client --query="SELECT  FROM signoz.traces ORDER BY timestamp LIMIT 1000 FORMAT CSV" > "$BACKUP_DIR/traces_sample.csv"

# For a full ClickHouse backup, it is recommended to use clickhouse-backup:
# 1. Install clickhouse-backup on the host: https://github.com/Altinity/clickhouse-backup
# 2. Configure it to work with the ClickHouse container.
# Example command with clickhouse-backup:
# sudo clickhouse-backup -c /etc/clickhouse-backup.yaml create --name signoz_full_backup

echo "Archiving backup..."
sudo tar -czvf "$BACKUP_DIR.tar.gz" -C "$(dirname "$BACKUP_DIR")" "$(basename "$BACKUP_DIR")"
if [ $? -ne 0 ]; then
    echo "Error: Failed to archive backup."
    exit 1
fi
sudo rm -rf "$BACKUP_DIR" # Delete temporary directory

echo "Backup successfully created: $BACKUP_DIR.tar.gz"

# --- Delete old backups ---
echo "Deleting old backups (older than $RETENTION_DAYS days)..."
sudo find /var/backups/signoz_ -type f -mtime +"$RETENTION_DAYS" -delete
echo "Completed."

Make the script executable:

chmod +x ~/signoz/backup_signoz.sh

Where to Store Backups

Storing backups on the same server as the original data is extremely risky. If the server fails, you will lose both data and backups. It is recommended to use:

• External S3-compatible storage: Amazon S3, MinIO, Wasabi, Backblaze B2. This is an economical and reliable solution. You can use s3cmd or rclone to upload archives.
• Separate VPS: An inexpensive VPS with a large disk volume, located in a different data center.
• Local NAS/server: If you have your own infrastructure.

For automatic upload to S3, you can add the command aws s3 cp "$BACKUP_DIR.tar.gz" s3://your-backup-bucket/ to the backup script (after configuring AWS CLI).

Automating Backups with Cron

Add a task to Cron so that the script runs regularly (e.g., daily at 3 AM).

sudo crontab -e

Add the following line to the end of the file:

0 3   * /root/signoz/backup_signoz.sh >> /var/log/signoz_backup.log 2>&1

This will run the script every day at 03:00 and record the output to a log file.

Updates: rolling vs maintenance window

Updating SigNoz:

SigNoz is constantly evolving. To update to a new version:

cd ~/signoz/signoz/deploy/
git pull # Get the latest changes from the repository
docker compose -f docker-compose.yaml pull # Download new container images
docker compose -f docker-compose.yaml up -d # Recreate containers with new images
docker image prune -f # Clean up old unused images

It is recommended to perform updates during a "maintenance window" when system load is minimal, as updating may cause temporary unavailability of some SigNoz services. Always read the release notes before updating to be aware of possible breaking changes.

Updating OS and Docker:

Regularly update the operating system and Docker Engine:

sudo apt update && sudo apt upgrade -y
sudo systemctl restart docker # Restart Docker after component updates

These updates are also best performed during a maintenance window, as restarting Docker can stop all running containers for a few seconds.

Troubleshooting + FAQ

Various issues may arise during the deployment and operation of SigNoz. Below are typical questions and their solutions.

1. SigNoz UI is inaccessible via IP address or domain.

What to check:

• Docker container status: Make sure all SigNoz containers are running.

  docker compose -f ~/signoz/signoz/deploy/docker-compose.yaml ps

  All services should be in the running state. If not, check the logs of the problematic container:

  docker compose -f ~/signoz/signoz/deploy/docker-compose.yaml logs signoz-frontend

• Firewall (UFW): Make sure ports 80, 443 (for Caddy), and 3301 (for direct access to SigNoz UI) are open.

  sudo ufw status verbose

• Caddy: If you are using Caddy, check its status and logs.

  sudo systemctl status caddy

  sudo journalctl -u caddy.service

  Make sure your domain correctly resolves to the server's IP address.
• Port conflicts: Check if other services are occupying ports 80, 443, or 3301.

  sudo netstat -tulpn | grep -E "80|443|3301"

How to fix: Restart problematic Docker or Caddy services. Open the necessary ports in UFW. Correct the DNS record for the domain.

2. SigNoz is not receiving logs, metrics, or traces.

What to check:

• OpenTelemetry Collector settings: Make sure the OTel Collector in SigNoz is running and listening on the correct ports.

  docker compose -f ~/signoz/signoz/deploy/docker-compose.yaml logs signoz-otel-collector

• Application settings: Check that your application is correctly configured to send data to the SigNoz OTel Collector (usually http://localhost:4318 or http://localhost:4317 from other containers in the same Docker Compose network).

  curl -v -X POST http://localhost:4318/v1/traces -d '{"resourceSpans":[]}'

  This is a simple test for OTLP endpoint availability.
• Network accessibility: If the application is on a different host, ensure its network can reach the OTel Collector ports on your VPS.
• Application log errors: Check the logs of the application that should be sending telemetry for OTel export errors.

How to fix: Correct the application or OTel Collector configuration. Check network connectivity between components.

3. SigNoz is running slowly or consuming too many resources.

What to check:

• Server resources: Check CPU load, RAM usage, and disk speed on your VPS.

  htop

  df -h

  iostat -x 1 10

• ClickHouse: ClickHouse is the primary resource consumer. Check its logs for errors or warnings.

  docker compose -f ~/signoz/signoz/deploy/docker-compose.yaml logs signoz-clickhouse

• Data volume: Evaluate the volume of incoming data. Your VPS might simply not be able to handle the current load.

How to fix: Increase VPS resources (CPU, RAM, NVMe SSD). Optimize applications to reduce the volume of telemetry sent (e.g., trace sampling). Configure data retention policy in SigNoz for automatic deletion of old data.

4. What is the minimum suitable VPS configuration?

For testing purposes or very small projects (1-2 applications, low data volume), you can start with 2 CPU, 4 GB RAM, and 100 GB NVMe SSD. However, for any serious operation, even for small teams, a minimum of 4 CPU, 8-16 GB RAM, and 200 GB NVMe SSD is recommended for stable operation and the ability to store data for several weeks.

5. What to choose — VPS or dedicated for this task?

The choice between a VPS and a dedicated server depends on the scale and performance requirements. A VPS is suitable for most medium-sized projects (up to 10-20 services, several hundred GB of data per month) due to its flexibility and cost. A dedicated server is necessary for large installations where terabytes of data are processed, maximum ClickHouse performance is required, long-term storage, or strict resource isolation requirements. If in doubt, start with a VPS and scale up to a dedicated server as needs grow.

6. How to update SigNoz to a new version?

To update SigNoz, execute the following commands in the ~/signoz/signoz/deploy/ directory:

git pull                       # Get the latest changes from the SigNoz repository
docker compose -f docker-compose.yaml pull # Download new Docker image versions
docker compose -f docker-compose.yaml up -d # Recreate containers with new images
docker image prune -f          # Clean up unused old Docker images

Always check the official SigNoz documentation for specific update instructions for a particular version, as additional steps may sometimes be required.