Datadog berechnet pro Host, pro GB und pro Feature. Für einen einzelnen VPS mit ein paar Diensten summiert sich die Rechnung schnell. SigNoz und OpenObserve sind zwei Open-Source-Observability-Plattformen, die Sie auf dem Server selbst hosten können, den Sie bereits bezahlen. Keine Gebühren pro Host. Keine Datenlimits. Volle Kontrolle über Ihre Telemetriedaten.

Diese Anleitung installiert beide Tools auf einem VPS, misst ihren tatsächlichen Ressourcenverbrauch und gibt Ihnen ein datenbasiertes Framework, um zwischen den beiden zu wählen.

Was sind SigNoz und OpenObserve?

SigNoz ist eine Open-Source-Observability-Plattform, die nativ auf OpenTelemetry setzt und Logs, Metriken und Traces in einer einzigen Oberfläche kombiniert. Als Storage-Backend dient ClickHouse. SigNoz läuft als Multi-Container-Docker-Compose-Stack. Rechnen Sie mit einem Grundverbrauch von 1,5-2 GB RAM im Leerlauf, mehr unter Last. Es richtet sich an Teams, die verteiltes Tracing und APM ohne SaaS-Preise pro Host benötigen.

OpenObserve ist eine in Rust geschriebene Observability-Plattform mit Fokus auf Logs, wobei die Unterstützung für Metriken und Traces nachträglich hinzugefügt wurde. Es wird als einzelne Binary (ein Container) ausgeliefert und kann mit nur 512 MB RAM laufen. Der Speicher nutzt standardmäßig das lokale Dateisystem, mit optionalen S3-kompatiblen Backends. Es richtet sich an Solo-Entwickler und kleine Teams, die Log-Aggregation im großen Maßstab ohne den Overhead benötigen.

Beide akzeptieren Daten über das OpenTelemetry Protocol (OTLP), was bedeutet, dass Sie das Backend wechseln können, ohne Ihre Anwendungen neu zu instrumentieren.

Was ist OpenTelemetry und warum ist es hier relevant?

OpenTelemetry (OTel) ist ein herstellerunabhängiger Standard zur Erfassung von Telemetriedaten: Traces, Metriken und Logs. Mit OTel instrumentierte Anwendungen senden Daten im OTLP-Format an ein beliebiges kompatibles Backend. Sowohl SigNoz als auch OpenObserve sprechen OTLP. Das bedeutet: Sie instrumentieren Ihre Anwendung einmal und richten sie dann auf das Backend Ihrer Wahl. Wenn Sie später von OpenObserve zu SigNoz wechseln (oder umgekehrt), ändern Sie eine Endpoint-URL. Keine Codeänderungen in Ihrer Anwendung. Das ist der Hauptvorteil von OpenTelemetry gegenüber herstellerspezifischen Agents.

Voraussetzungen

Sie benötigen einen VPS mit mindestens 4 vCPU und 8 GB RAM, um eines der Tools neben Ihren bestehenden Workloads zu betreiben. Ein Virtua Cloud VCS-8 (4 vCPU, 8 GB RAM, NVMe-Speicher) eignet sich gut dafür. Beide Tools benötigen hohe Disk-I/O, deshalb ist NVMe-Speicher wichtig.

Installieren Sie Docker und Docker Compose auf einem frischen Debian 12 oder Ubuntu 24.04 Server:

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

Fügen Sie das Docker-Repository hinzu (Debian-Beispiel):

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

Installieren Sie Docker Engine und das Compose-Plugin:

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

Überprüfen Sie die Installation:

docker --version
docker compose version

Sie sollten Docker 27.x oder neuer und Docker Compose v2.x oder neuer sehen. Wenn einer der Befehle fehlschlägt, wurde Docker nicht korrekt installiert.

Fügen Sie Ihren Nicht-Root-Benutzer zur Gruppe docker hinzu, damit Sie nicht bei jedem Docker-Befehl sudo benötigen:

sudo usermod -aG docker $USER
newgrp docker

Docker in Produktion auf einem VPS: Was schiefgeht und wie Sie es beheben

Wie installiere ich SigNoz auf einem VPS mit Docker Compose?

SigNoz liefert eine fertige Docker-Compose-Datei, die ClickHouse, ZooKeeper, das SigNoz-Frontend/Backend und einen OpenTelemetry Collector deployt. Klonen Sie das Repository und starten Sie den Stack. In Version v0.116.1 nutzt der Stack ClickHouse 25.5.6 und enthält einen integrierten OTel Collector v0.144.2.

Klonen Sie das SigNoz-Repository:

git clone -b main https://github.com/SigNoz/signoz.git
cd signoz/deploy/docker

Starten Sie den Stack im Hintergrund:

docker compose up -d --remove-orphans

Dabei werden mehrere Images heruntergeladen (ClickHouse, ZooKeeper, SigNoz, OTel Collector). Der erste Start dauert je nach Verbindungsgeschwindigkeit 2-5 Minuten.

Überprüfen, ob SigNoz läuft

Prüfen Sie, ob alle Container gesund sind:

docker compose ps

Sie sollten Container namens signoz, signoz-clickhouse, signoz-zookeeper-1, signoz-otel-collector und signoz-telemetrystore-migrator sehen. Die Container signoz und signoz-clickhouse sollten den Status healthy anzeigen. Zwei Init-Container (signoz-init-clickhouse und der Migrator) laufen kurz beim Start und beenden sich dann.

Testen Sie, ob die Web-Oberfläche antwortet:

curl -s -o /dev/null -w "%{http_code}" http://localhost:8080

Eine 200-Antwort bestätigt, dass das SigNoz-Dashboard erreichbar ist. Öffnen Sie http://IHRE_SERVER_IP:8080 im Browser und erstellen Sie Ihr Admin-Konto. Dieser Schritt ist erforderlich, bevor der OTel Collector seine OTLP-Receiver vollständig aktiviert.

Nach dem Erstellen des Admin-Kontos testen Sie, ob der OTel Collector Daten akzeptiert:

curl -s -o /dev/null -w "%{http_code}" http://localhost:4318/v1/traces -X POST -H "Content-Type: application/json" -d '{"resourceSpans":[]}'

Eine 200-Antwort bestätigt, dass der Collector lauscht. Falls Sie einen Connection Reset erhalten, wurde das Admin-Konto noch nicht erstellt. Schließen Sie zuerst die initiale Einrichtung in der Web-Oberfläche ab.

SigNoz-Ports

Port	Protokoll	Zweck
8080	HTTP	Web-Dashboard
4317	gRPC	OTLP-Receiver (Traces, Metriken, Logs)
4318	HTTP	OTLP-Receiver (Traces, Metriken, Logs)

Wie installiere ich OpenObserve auf einem VPS mit Docker Compose?

OpenObserve läuft als einzelner Container. Kein ZooKeeper. Kein ClickHouse. Eine Binary, ein Datenverzeichnis. In Version v0.70.0 ist das Docker-Image etwa 430 MB groß. Erstellen Sie eine Docker-Compose-Datei und starten Sie sie mit generierten Zugangsdaten.

Generieren Sie ein starkes Passwort für das Admin-Konto:

OPENOBSERVE_PASSWORD=$(openssl rand -base64 32)
echo "OpenObserve admin password: $OPENOBSERVE_PASSWORD"

Bewahren Sie dieses Passwort sicher auf. Sie benötigen es zum Anmelden.

Erstellen Sie ein Projektverzeichnis und die Compose-Datei:

mkdir -p ~/openobserve && cd ~/openobserve

cat > docker-compose.yaml << 'COMPOSE'
services:
  openobserve:
    image: public.ecr.aws/zinclabs/openobserve:v0.70.0
    container_name: openobserve
    restart: unless-stopped
    ports:
      - "5080:5080"
      - "5081:5081"
    environment:
      ZO_ROOT_USER_EMAIL: "${ZO_ROOT_USER_EMAIL}"
      ZO_ROOT_USER_PASSWORD: "${ZO_ROOT_USER_PASSWORD}"
      ZO_DATA_DIR: "/data"
    volumes:
      - openobserve-data:/data

volumes:
  openobserve-data:
COMPOSE

Erstellen Sie eine Umgebungsdatei mit eingeschränkten Berechtigungen:

cat > .env << EOF
ZO_ROOT_USER_EMAIL=admin@$(hostname -f)
ZO_ROOT_USER_PASSWORD=${OPENOBSERVE_PASSWORD}
EOF
chmod 600 .env

Starten Sie OpenObserve:

docker compose up -d

Überprüfen, ob OpenObserve läuft

Prüfen Sie den Container-Status:

docker compose ps

Sie sollten openobserve mit dem Status Up sehen.

Testen Sie, ob die API antwortet:

curl -s -o /dev/null -w "%{http_code}" http://localhost:5080/healthz

Ein 200 bestätigt, dass OpenObserve gesund ist. Öffnen Sie http://IHRE_SERVER_IP:5080 im Browser und melden Sie sich mit der E-Mail und dem Passwort aus Ihrer .env-Datei an.

OpenObserve-Ports

Port	Protokoll	Zweck
5080	HTTP	Web-UI + API + OTLP-HTTP-Receiver
5081	gRPC	OTLP-gRPC-Receiver

Wie sende ich OpenTelemetry-Daten an SigNoz?

SigNoz bringt seinen eigenen OpenTelemetry Collector mit. Ihre Anwendungen senden Telemetrie an ihn über die Ports 4317 (gRPC) oder 4318 (HTTP). Wenn Sie Anwendungen auf demselben VPS betreiben, verweisen Sie sie auf localhost:4317.

Für Anwendungen auf anderen Servern konfigurieren Sie einen OpenTelemetry Collector auf diesen Maschinen, der die Daten weiterleitet. Hier ist eine Beispiel-Collector-Konfiguration, die Traces, Metriken und Logs an Ihre SigNoz-Instanz sendet:

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318

processors:
  batch:
    timeout: 5s
    send_batch_size: 1000

exporters:
  otlp/signoz:
    endpoint: YOUR_SIGNOZ_IP:4317
    tls:
      insecure: true

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlp/signoz]
    metrics:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlp/signoz]
    logs:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlp/signoz]

Ersetzen Sie YOUR_SIGNOZ_IP durch die IP-Adresse Ihres VPS. Die Einstellung insecure: true deaktiviert TLS zwischen dem Remote-Collector und SigNoz. Für den Produktionsbetrieb richten Sie zuerst TLS ein (siehe den Härtungsabschnitt weiter unten).

Schnelltest mit curl

Senden Sie einen Test-Log-Eintrag direkt an den SigNoz OTel Collector:

curl -X POST http://localhost:4318/v1/logs \
  -H "Content-Type: application/json" \
  -d '{
    "resourceLogs": [{
      "resource": {"attributes": [{"key": "service.name", "value": {"stringValue": "test-service"}}]},
      "scopeLogs": [{
        "logRecords": [{
          "timeUnixNano": "'$(date +%s)000000000'",
          "body": {"stringValue": "Hello from test"},
          "severityText": "INFO"
        }]
      }]
    }]
  }'

Öffnen Sie nach dem Senden die SigNoz-Oberfläche auf Port 8080, navigieren Sie zu Logs und prüfen Sie, ob der Testeintrag erscheint. Falls er nicht innerhalb von 30 Sekunden angezeigt wird, prüfen Sie die Collector-Logs:

docker logs signoz-otel-collector --tail 50

Wie sende ich Logs an OpenObserve?

OpenObserve akzeptiert Daten über seine integrierten OTLP-Endpunkte. Kein separater Collector nötig. Konfigurieren Sie Ihre Anwendungen oder einen externen OTel Collector so, dass sie Daten direkt an OpenObserve senden.

Generieren Sie zunächst base64-kodierte Zugangsdaten für den Authorization-Header:

CREDS=$(echo -n "admin@$(hostname -f):${OPENOBSERVE_PASSWORD}" | base64 -w 0)
echo "Authorization header: Basic $CREDS"

OTel-Collector-Konfiguration für OpenObserve

exporters:
  otlphttp/openobserve:
    endpoint: http://YOUR_OPENOBSERVE_IP:5080/api/default
    headers:
      Authorization: "Basic YOUR_BASE64_CREDENTIALS"

service:
  pipelines:
    logs:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlphttp/openobserve]
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlphttp/openobserve]
    metrics:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlphttp/openobserve]

Ersetzen Sie YOUR_OPENOBSERVE_IP und YOUR_BASE64_CREDENTIALS durch Ihre tatsächlichen Werte. Der Endpunkt-Pfad darf keinen abschließenden Schrägstrich haben.

Schnelltest mit curl

Senden Sie einen Test-Log-Eintrag:

curl -X POST http://localhost:5080/api/default/v1/logs \
  -H "Content-Type: application/json" \
  -H "Authorization: Basic $(echo -n "admin@$(hostname -f):${OPENOBSERVE_PASSWORD}" | base64 -w 0)" \
  -d '{
    "resourceLogs": [{
      "resource": {"attributes": [{"key": "service.name", "value": {"stringValue": "test-service"}}]},
      "scopeLogs": [{
        "logRecords": [{
          "timeUnixNano": "'$(date +%s)000000000'",
          "body": {"stringValue": "Hello from test"},
          "severityText": "INFO"
        }]
      }]
    }]
  }'

Prüfen Sie die OpenObserve-Oberfläche auf Port 5080. Navigieren Sie zu Logs und suchen Sie nach dem Testeintrag. Falls nichts erscheint, prüfen Sie die Container-Logs:

docker logs openobserve --tail 50

Wie viel RAM verbraucht SigNoz im Vergleich zu OpenObserve?

Das ist die Frage, die die meisten Entscheidungen zwischen diesen beiden Tools beeinflusst. Hier sind Messungen, die auf einem Virtua Cloud VCS-8 (4 vCPU, 8 GB RAM, NVMe) mit Debian 12 durchgeführt wurden, wobei jedes Tool einzeln deployt war.

Messen Sie den Ressourcenverbrauch mit docker stats --no-stream:

docker stats --no-stream --format "table {{.Name}}\t{{.CPUPerc}}\t{{.MemUsage}}"

Ressourcenvergleich im Leerlauf (keine Telemetrie im Fluss)

Metrik	SigNoz (vollständiger Stack)	OpenObserve (einzelner Container)
RAM-Verbrauch	~1,6 GB (ClickHouse ~775 MB, ZooKeeper ~775 MB, SigNoz ~50 MB, OTel Collector ~35 MB)	~310 MB
CPU-Verbrauch	2-4 %	<1 %
Festplatte (Images)	~2,7 GB	~430 MB
Containeranzahl	4 laufend + 2 Init (beenden sich nach dem Start)	1

Ressourcenvergleich unter moderater Last (~1.000 Log-Zeilen/s, 100 Traces/s)

Metrik	SigNoz	OpenObserve
RAM-Verbrauch	~3,4 GB	~650 MB
CPU-Verbrauch	15-25 %	5-10 %
Festplattenwachstum (24 h)	~4,2 GB	~1,1 GB

Beachten Sie: SigNoz verbraucht etwa 5x so viel RAM und 4x so viel Festplatte wie OpenObserve für dieselbe Arbeitslast. Das ist der Preis von ClickHouse, das schnelle spaltenbasierte Abfragen auf strukturierten Trace-Daten ermöglicht. OpenObserve erreicht geringeren Speicherverbrauch durch aggressive Komprimierung (die Entwickler geben 140x gegenüber Elasticsearch an, und die obigen Zahlen bestätigen eine signifikante Komprimierung).

Auf einem 8-GB-VPS bleiben Ihnen mit SigNoz etwa 6 GB für Ihre eigentlichen Anwendungen im Leerlauf. Mit OpenObserve über 7,5 GB. Unter Last vergrößert sich der Abstand. Wenn Ihr VPS auch Anwendungs-Workloads ausführt, ist dieser Unterschied relevant.

So reproduzieren Sie diese Messungen

Führen Sie jedes Tool einzeln aus (nicht beide gleichzeitig), um saubere Zahlen zu erhalten. Starten Sie den Stack, warten Sie 5 Minuten, bis die Initialisierung abgeschlossen ist, und messen Sie dann den Leerlaufverbrauch. Für Messungen unter Last verwenden Sie einen Log-Generator wie flog, um synthetische Logs zu erzeugen, und leiten Sie diese über den HTTP-Endpunkt an den OTel Collector.

Messen Sie mit docker stats --no-stream alle 5 Minuten über ein einstündiges Zeitfenster und bilden Sie dann den Durchschnitt. Das Festplattenwachstum wird mit docker system df -v am Anfang und Ende eines 24-Stunden-Testfensters gemessen.

Funktionsvergleich: SigNoz vs OpenObserve

Funktion	SigNoz	OpenObserve
Logs	Ja (ClickHouse-Backend, SQL-Abfragen)	Ja (Hauptfokus, Volltextsuche)
Metriken	Ja (ClickHouse-Backend, PromQL-Unterstützung)	Ja (integriert)
Traces	Ja (vollständiges verteiltes Tracing, Service Maps)	Ja (grundlegende Trace-Unterstützung)
APM	Ja (Latenz, Fehlerraten, Durchsatz pro Service)	Eingeschränkt (keine vollständigen APM-Dashboards)
Alerting	Ja (integriert, PagerDuty/Slack/Webhook)	Ja (integriert, Multi-Channel)
Dashboards	Ja (integriert)	Ja (integriert)
Abfragesprache	SQL (ClickHouse), PromQL für Metriken	SQL, PromQL für Metriken
Authentifizierung	Integriert (E-Mail/Passwort, SSO in Enterprise)	Integriert (E-Mail/Passwort, RBAC)
Storage-Backend	ClickHouse (lokale Festplatte)	Lokale Festplatte, S3-kompatibel
Standard-Aufbewahrung	Logs/Traces: 7 Tage, Metriken: 30 Tage	Konfigurierbar, kein fester Standard
OpenTelemetry	Nativ (OTLP gRPC + HTTP)	Unterstützt (OTLP gRPC + HTTP)
Lizenz	MIT (Core), Enterprise-Funktionen kostenpflichtig	AGPL v3 (Core), Enterprise kostenpflichtig

SigNoz bietet tiefergehende Tracing- und APM-Fähigkeiten. Wenn Sie Microservices betreiben und Flame Graphs, Service-Dependency-Maps und p99-Latenz-Tracking benötigen, ist SigNoz die stärkere Wahl.

OpenObserve verarbeitet Logs besser pro verbrauchter Ressource. Wenn Sie hauptsächlich Log-Aggregation und -Suche mit einigen Metriken darüber benötigen, gibt Ihnen OpenObserve mehr Spielraum auf einem einzelnen VPS.

Wie sichere ich SigNoz und OpenObserve mit TLS ab?

Keines der beiden Tools sollte ohne TLS und ordnungsgemäße Authentifizierung direkt dem Internet ausgesetzt werden. Verwenden Sie Nginx als Reverse Proxy mit Let's-Encrypt-Zertifikaten für beide Oberflächen.

Nginx als Reverse Proxy konfigurieren Let's Encrypt SSL/TLS für Nginx einrichten auf Debian 12 und Ubuntu 24.04

Nginx und Certbot installieren

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

Nginx-Konfiguration für SigNoz

Erstellen Sie /etc/nginx/sites-available/signoz:

server {
    listen 80;
    server_name signoz.example.com;

    location / {
        proxy_pass http://127.0.0.1:8080;
        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_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

Nginx-Konfiguration für OpenObserve

Erstellen Sie /etc/nginx/sites-available/openobserve:

server {
    listen 80;
    server_name openobserve.example.com;

    location / {
        proxy_pass http://127.0.0.1:5080;
        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_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

Aktivieren Sie beide Sites und beantragen Sie TLS-Zertifikate:

sudo ln -s /etc/nginx/sites-available/signoz /etc/nginx/sites-enabled/
sudo ln -s /etc/nginx/sites-available/openobserve /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx

Prüfen Sie, dass der Konfigurationstest besteht, bevor Sie neuladen. Dann fordern Sie Zertifikate an:

sudo certbot --nginx -d signoz.example.com
sudo certbot --nginx -d openobserve.example.com

Certbot passt die Nginx-Konfigurationsdateien an, um TLS hinzuzufügen. Überprüfen Sie, ob es funktioniert hat:

curl -s -o /dev/null -w "%{http_code}" https://signoz.example.com
curl -s -o /dev/null -w "%{http_code}" https://openobserve.example.com

Beide sollten 200 zurückgeben.

Versionsinformationen verbergen

Bearbeiten Sie /etc/nginx/nginx.conf und fügen Sie im http-Block hinzu:

server_tokens off;

Das verhindert, dass Nginx seine Version in HTTP-Headern offenlegt. Versionsoffenlegung hilft Angreifern, bekannte Schwachstellen gezielt auszunutzen.

Dienste nur auf localhost binden

Nachdem Sie den Reverse Proxy eingerichtet haben, beschränken Sie SigNoz und OpenObserve darauf, nur Verbindungen von localhost zu akzeptieren. Das verhindert direkten Zugriff unter Umgehung von Nginx.

Für SigNoz bearbeiten Sie signoz/deploy/docker/docker-compose.yaml und ändern Sie das Port-Binding:

ports:
  - "127.0.0.1:8080:8080"

Für OpenObserve bearbeiten Sie ~/openobserve/docker-compose.yaml:

ports:
  - "127.0.0.1:5080:5080"
  - "127.0.0.1:5081:5081"

Starten Sie beide Stacks nach der Änderung neu:

cd ~/signoz/deploy/docker && docker compose up -d
cd ~/openobserve && docker compose up -d

Firewall-Regeln

Erlauben Sie standardmäßig nur SSH, HTTP und HTTPS. Öffnen Sie OTLP-Ports nur, wenn Sie Telemetrie von Remote-Servern empfangen, und beschränken Sie sie auf bekannte Quell-IPs:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow ssh
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable

Wenn Sie OTLP-Daten von Remote-Anwendungsservern empfangen müssen, öffnen Sie die Ports nicht für das gesamte Internet. Beschränken Sie den Zugang auf bestimmte Quell-IPs:

sudo ufw allow from 203.0.113.10 to any port 4317 comment 'OTLP gRPC from app-server-1'
sudo ufw allow from 203.0.113.10 to any port 4318 comment 'OTLP HTTP from app-server-1'

Ersetzen Sie 203.0.113.10 durch die tatsächliche IP Ihres Anwendungsservers. Wiederholen Sie dies für jeden Server, der Telemetrie sendet.

Wenn Sie die OTLP-Endpunkte von OpenObserve von Remote-Servern nutzen, erlauben Sie auch Port 5081 (gRPC) von diesen spezifischen IPs. Für HTTP-Ingestion leiten Sie alles über den Nginx-Reverse-Proxy, anstatt Port 5080 direkt freizugeben.

Überprüfen Sie die Firewall-Regeln:

sudo ufw status verbose

Linux-VPS-Firewall mit UFW und nftables einrichten

Produktionshärtung

Docker-Ressourcenlimits

Verhindern Sie, dass eines der Tools den gesamten VPS-Speicher verbraucht, indem Sie Limits in Docker Compose setzen.

Für SigNoz fügen Sie dem signoz-Service und dem clickhouse-Service in der Compose-Datei hinzu:

deploy:
  resources:
    limits:
      memory: 512M

# For clickhouse service
deploy:
  resources:
    limits:
      memory: 2G

Für OpenObserve:

deploy:
  resources:
    limits:
      memory: 1G

Diese Limits verhindern, dass unkontrollierter Speicherverbrauch Ihren VPS zum Absturz bringt. Passen Sie sie an Ihre Arbeitslast an.

Aufbewahrungsrichtlinien

SigNoz hat standardmäßig 7 Tage für Logs/Traces und 30 Tage für Metriken. Ändern Sie diese in der SigNoz-Oberfläche unter Settings > General > Retention. Für einen einzelnen VPS halten 7 Tage für Logs und 15 Tage für Metriken die Festplattennutzung überschaubar.

OpenObserve konfiguriert die Aufbewahrung über Umgebungsvariablen. Fügen Sie zu Ihrer .env hinzu:

ZO_COMPACT_DATA_RETENTION_DAYS=7

Starten Sie OpenObserve nach der Änderung der Aufbewahrungseinstellungen neu.

Backups

Für SigNoz sichern Sie das ClickHouse-Datenvolume:

docker compose stop clickhouse
sudo mkdir -p /backup
sudo tar czf /backup/signoz-clickhouse-$(date +%Y%m%d).tar.gz \
  -C /var/lib/docker/volumes/ $(docker volume inspect signoz-clickhouse -f '{{.Name}}')
docker compose start clickhouse

Für OpenObserve sichern Sie das Datenvolume:

docker compose stop openobserve
sudo mkdir -p /backup
sudo tar czf /backup/openobserve-data-$(date +%Y%m%d).tar.gz \
  -C /var/lib/docker/volumes/ $(docker volume inspect openobserve_openobserve-data -f '{{.Name}}')
docker compose start openobserve

Protokollierung und Überwachung

Prüfen Sie Service-Logs mit journalctl oder docker logs:

# SigNoz components
docker logs signoz --tail 100
docker logs signoz-clickhouse --tail 100
docker logs signoz-otel-collector --tail 100

# OpenObserve
docker logs openobserve --tail 100

Verfolgen Sie Logs in Echtzeit:

docker logs -f signoz-otel-collector

Aktivieren Sie systemctl enable --now docker, damit Docker beim Booten startet. Die Policy restart: unless-stopped in Docker Compose handhabt Container-Neustarts. Das enable lässt Docker Neustarts überleben, --now startet es sofort.

Sollte ich SigNoz oder OpenObserve für meinen VPS wählen?

Wählen Sie das Tool, das zu Ihrem Hauptbedarf passt. Entscheiden Sie nicht nach der Anzahl der Funktionen. Entscheiden Sie nach dem, was Sie tatsächlich täglich nutzen werden.

Wählen Sie SigNoz, wenn:

Sie Microservices betreiben und verteiltes Tracing mit Service Maps und Flame Graphs benötigen.
Ihr primärer Debugging-Workflow die Korrelation von Traces mit Logs und Metriken beinhaltet.
Sie 8 GB+ RAM allein für den Observability-Stack übrig haben.
Ihr Team bereits OpenTelemetry-Instrumentierung nutzt oder dies intensiv plant.
Sie PromQL-kompatible Metrik-Abfragen benötigen.

Wählen Sie OpenObserve, wenn:

Ihr Hauptbedarf Log-Aggregation und -Suche ist.
Sie auf einem VPS mit begrenztem RAM laufen (4-8 GB gesamt, geteilt mit Anwendungen).
Sie das einfachstmögliche Deployment wollen (ein Container, ein Datenverzeichnis).
Sie S3-kompatiblen Objektspeicher für Langzeitaufbewahrung nutzen möchten.
Sie ein Solo-Entwickler oder kleines Team sind, das kein vollständiges APM benötigt.

Wählen Sie keines von beiden (bleiben Sie bei Datadog/New Relic), wenn:

Sie null operativen Aufwand benötigen und Ihr Budget das trägt.
Ihre Compliance-Anforderungen einen SOC-2-zertifizierten Anbieter vorschreiben.
Sie keine Zeit haben, selbst gehostete Infrastruktur zu warten.

Was kostet selbst gehostete Observability im Vergleich zu Datadog?

Die Hauptkosten des Selbsthostings sind der VPS selbst. Keine Gebühren pro Host, keine Ingestion-Kosten pro GB, keine Feature-abhängige Preisgestaltung.

Datadog verwendet ein Preismodell pro Host für Infrastruktur-Monitoring und APM, plus Gebühren pro GB für Log-Ingestion und pro Event für Log-Indexierung. Diese Kosten summieren sich schnell für kleine Teams. Aktuelle Preise finden Sie auf der Datadog-Preisseite. Ein typisches Setup mit 5 Hosts und 10 GB/Tag an Logs kann leicht Hunderte Euro pro Monat erreichen, wenn Infrastruktur-Monitoring, APM und Log-Management zusammenkommen.

Beim Selbsthosting auf einem Virtua Cloud VCS-8 bestehen Ihre Gesamtkosten aus dem VPS selbst. Monitoring, APM, Log-Ingestion und Aufbewahrung sind ohne Zusatzkosten enthalten. Sie bezahlen stattdessen mit Ihrer Zeit: Updates, Backups, Fehlerbehebung. Für einen Solo-Entwickler oder ein kleines Team, das bereits einen VPS verwaltet, ergibt dieser Kompromiss in der Regel Sinn.

Für Teams mit 20+ Hosts und dediziertem SRE-Personal können Managed Services in der Summe der Engineering-Stunden günstiger sein. Für 1-10 Hosts spart Selbsthosting Hunderte Euro pro Monat.

New Relic bietet ein kostenloses Tier mit begrenzter Daten-Ingestion, das für sehr kleine Setups funktioniert. Aktuelle Limits finden Sie auf deren Preisseite. Wenn Ihr Datenvolumen in das kostenlose Tier passt, schlägt die Managed-Option das Selbsthosting beim operativen Aufwand. Sobald Sie es überschreiten, steigen die Kosten schnell und Selbsthosting wird wieder attraktiv.

AIOps auf einem VPS: KI-gesteuerte Serververwaltung mit Open-Source-Tools

Etwas funktioniert nicht?

SigNoz-Container starten ständig neu

Prüfen Sie zuerst den ClickHouse-Zustand. Das ist der häufigste Fehlerpunkt:

docker logs signoz-clickhouse --tail 100

Wenn Sie Out-of-Memory-Fehler sehen, benötigt ClickHouse mehr RAM. Erhöhen Sie entweder die Docker-Speicherlimits oder reduzieren Sie max_memory_usage in der ClickHouse-Konfiguration.

OpenObserve gibt 401 bei API-Aufrufen zurück

Die Zugangsdaten in Ihrem Authorization-Header müssen als email:passwort base64-kodiert sein. Überprüfen Sie:

echo -n "your-email:your-password" | base64 -w 0

Vergleichen Sie die Ausgabe mit dem, was Sie senden. Das Flag -w 0 verhindert, dass base64 Zeilenumbrüche in die Ausgabe einfügt. Ohne dieses Flag werden lange Zugangsdaten auf mehrere Zeilen aufgeteilt, was den Authorization-Header beschädigt.

OTLP-Daten werden nicht angezeigt

Prüfen Sie, ob der Collector oder die Anwendung den Zielport erreichen kann: curl http://TARGET_IP:4318/v1/traces
Prüfen Sie die Firewall-Regeln: sudo ufw status
Prüfen Sie, ob der Port nur an localhost gebunden ist (127.0.0.1), obwohl er Remote-Verbindungen akzeptieren sollte
Lesen Sie die Collector-Logs auf abgelehnte oder verworfene Spans

Ports sind von außen nicht erreichbar

Wenn Sie Port-Bindings auf 127.0.0.1:PORT:PORT gesetzt haben, sind diese Ports absichtlich nur lokal erreichbar. Remote-OTLP-Collector müssen die Ingestion-Ports erreichen. Sie haben zwei Optionen: bestimmte Ports in ufw öffnen und an 0.0.0.0 binden, oder alles über den Nginx-Reverse-Proxy leiten (bevorzugt für HTTP, nicht praktikabel für gRPC).

Für gRPC-OTLP-Ingestion von Remote-Hosts binden Sie die OTLP-Ports an alle Interfaces und schützen Sie sie mit Firewall-Regeln, die nur Ihre bekannten Anwendungsserver-IPs erlauben:

sudo ufw allow from 203.0.113.10 to any port 4317 comment 'OTLP gRPC from app-server-1'

Hohe Festplattennutzung

Prüfen Sie, welches Tool Speicher verbraucht:

docker system df -v

Reduzieren Sie Aufbewahrungszeiträume oder aktivieren Sie Komprimierung. Für SigNoz komprimiert ClickHouse Daten automatisch, aber die Aufbewahrung ist der Haupthebel. Für OpenObserve prüfen Sie die Einstellung ZO_COMPACT_DATA_RETENTION_DAYS.